Rules for software evision

Hi all,

I'd like to know which is the most common system used to assign the revision code to a software project after an update.

Can you give me some examples

Thanks in advance

cagliostro said:

Hi all,

I'd like to know which is the most common system used to assign the revision code to a software project after an update.

Can you give me some examples

Thanks in advance

Click to expand...

I don't know about other vendors, but if you start changing filenames with Allen-Bradley projects you can get into all sorts of bother.

Most people I know just go by the windows date/time of the file to determine latest revision.

In the RSLogix500 software, you can add a "Revision Text" description each time you save the project.

I've also seen a "Revision" number stored in a data register or tag in the PLC, which has to be updated manually.

I do version 1.0, 1.1, 1.2 and so on for software changes and I would do 2.0,3.0,4.0 for major changes like installing a different brand or model of drive adding a piece of equipment to a existing line,etc.

Everyone has their own method so no real right or wrong just keep it consistant and organized. IMHO it's a good idea to make a word document or similar explaining how you revision system works so others can follow it easily if need be.

I also always include the date and a word docuement explaining all the changes. Word document has version and date info in the header.I made this document in pdf format also just in case. In some cases .txt files are even a good idea.

I wish Rockwell would do the revision notes in logix 5000 like it was in 5/500 Daba.

As Daba said I typically don't change the plc file name but the name of the folder it sits in. I document the revision number in the header of the program itself so if it was in the wrong folder for some reason you would need to open it to read the rev #

The Plc Kid said:

I wish Rockwell would do the revision notes in logix 5000 like it was in 5/500 Daba.

Click to expand...

I used to use those (on the 5/500) but nobody else look at them.

We just added the new date to the file name.

Mickey we use them like religion here for 5/500 programs.

I really wish 5000 had that option. Now that you can store comments in the processor this addition would be great.

I use "save as" with a incrementing extension of "Vxx" on the filename every morning no matter what the software is. Crude but effective and every once in a while it saves my but.

We do the majority of our work in oil and gas around here in ladder. We tried having at txt file that was the 5000 version of revision notes but having it as a seperate file was a pain a d often didn't get updated. We started adding a Structured Text file into each program that we don't actually scan although we still /* and end with one too so 5000 sees it as do umentation and not structured text. Seems to get updated more regularly even if its only to say "went online to check values for FWKO PID. No changes were made." We also always add our date, programmer's name, company and contact info for future programmers as well.

Still would be better if it was built into the save like 500.


Kraken Fan #69

daba said:

I don't know about other vendors, but if you start changing filenames with Allen-Bradley projects you can get into all sorts of bother.

Click to expand...

Daba,
Can you elaborate more on this?
I don't want to hijack this thread, but I notice issues when a project is saved in a different directory from where it was opened. Can become quite frustrating & confusing.

daba said:

I don't know about other vendors, but if you start changing filenames with Allen-Bradley projects you can get into all sorts of bother.

Click to expand...

I'd also like to hear other's thoughts about this. I've discovered that, on very rare occasions, RSLogix 500 will refuse to do an upload from a PLC to an existing file, even if the processor names match. It's very frustrating since the only option at that point is to upload to a blank file, then merge the documentation (PITA). However... the problem never seems to occur as long as the filename matches the processor name. So, I try to use that naming convention on RSS files and then use the name of the containing folder to provide a more descriptive title and/or revision.

I haven't experienced Daba's problems though I don't change the processor name - changing directories can get a little messy but not an issue if you've been through the learning curve.

lostcontrol said:

Daba,
Can you elaborate more on this?
I don't want to hijack this thread, but I notice issues when a project is saved in a different directory from where it was opened. Can become quite frustrating & confusing.

Click to expand...

I'd imagine he means something like changing it offline. I've never had a problem changing a file name as long as I was online with the processor or downloaded the changed program to the processor.

A simple "Go Online" selection will browse your set directory for matching files and processor names, choose a correct file if it finds it, or display a list of all the files with that processor name for you to select. Being that I learned on RSLogix 500, I never try to connect to a processor with a file that I have changed offline without downloading first. Step 7 being able to connect with mismatched files was a completely new idea to me. I work with some people who learned on Step 7 and they kept asking me how do you do a file compare on RSLogix. I didn't understand the need because RSLogix doesn't work that way.

As far as revision changes, I don't bother doing rev changes if I just make minor bug fixes. If I do a significant change to the process, I attach an incremental "_REV#" to the end of the file name and in the RSLogix 500 revision notes I put the date and what I changed, and why I changed.

when changing an i/o point, timer, data amount, we typically leave the name the same.

when something changes the code we back up the original program and save it under todays date. press1-A0-4-16-13
the machine name is press1. the rev is A0 and of course the date.

the program will then be named press1-A1-4-16-13.
make the changes and confirm they work.
write the changes into the log book and notify the supervisor, line supervisor, maiuntenance, and maintenance foreman of the changes.

if the machine fails, clear out the machine and reload the old code.

everyone does things differently, see what the company standard is or help establish a routine.

regards,
james