mashva (Customer) asked a question.
I know that this topic is rather vague but I would like to get an idea how some of you have tackled the idea of program revisions and maintaining some sort of organization or traceability.
In my job, we only design equipment/programs for in-house builds so we don't typically have many requirements (oh, who am I kidding....there are NO requirements). But my co-worker's and I have expressed a desire to be more standardized in our approach to designing and maintaining code. We see a lot of benefit here if for no other reason other than making it easier on ourselves if and when we have to work on previously written code.
One of the ways I envision to be straightforward enough would be though the nomenclature of our filenames. I'll give an example format:
MachineID (Date) [Version] Description.ext
ULPVac(2020-04-22)[2.1]Fixed_early_termination.ckp
Machine ID / name : Short and sweet
Date: YYYY-MM-DD format selected for proper sorting
Version: Could be numeric or characters or some combination thereof
Description: Something that describes what the gist of the changes were
Ext: self explanatory, but could mirror the rest of the file name if the change also required modification to auxiliary code such as an HMI
There is a lot to be said in just version numbering schemes, I know.
Do any of you have any experience with systems that you either liked or disliked? Any particular reasons you would like to give would be greatly appreciated!
Hi Mashva,
I have always just used the machine ID and version. Major versions would jump significantly, minor versions would increment by 1. The date is usually picked up in the saved file.
As for the description of the change, I put this on the first line in that part of the program.
Example:
MachineID100.ckp -
Next version - MachineID101.ckp
Major Version Change: - MachineID201.ckp
etc.
HMI program will be the same name and version of the PLC program.
These are kept on a network server that is backed up daily.
Regards,
Garry
Thanks, Gary.
I like it -- its short and sweet.
What would differentiate a minor vs major change? We've discussed that here as well. A sequence change, adding or disabling a feature -- those seem like obvious major revisions.
Minor revisions might be something like a data change? For instance, if we needed to increase a preset for a timer that we can do from dataview etc. Although, that makes a tough generalization because a dwell for a controlled process, while not a significant change in PLC logic, could make for significant quality difference.
Thanks again for the discussion!
That is exactly correct for minor and major changes. I like to think of the major changes to the PLC program not the process. So your dwell time change would be a minor PLC change. The logic for the dwell is already established.
Programming in a robust data logging would be a major change.
Regards,
Garry
BTW,
I have used this program versioning going back to 1990. That is why allot of the names had to be short.
If it works, don't break it! I've had filename length issues with some modern systems as well. It was either CLICK or CMORE micro (I can't remember exactly) that would truncate the filename when you pull it out.
At my previous job we would version it like Garry said. We serviced multiple locations so we added a location code also. Another thing we did was create a text file with the same name as the program that had notes on what changed and saved it in the same directories we saved the project. This saved a lot of time when someone asked "When was that change made?". We could quickly go to the txt files and see what changed. (because last week usually ended up being a few months ago) This is an extra step and does require everyone keep good notes and include in the text document, but really made researching changes more efficient and like anything else after doing it a for a bit it becomes a habit.
Good luck!
We don't have a "standard" here. But one of my concerns is exactly this. Even if we all buy in, initially, not remembering to do it every time is where it can become less than useful. Maybe you are right if we can keep it up through repetition it will be become second nature.
Depending on the language, I've used comments in the first line or rung to do general descriptions of program revisions. In the Galil motion controllers we have here, file name doesn't even come with the program when you read it out. So, I will put a comment on the first line that IS the filename that I will save locally. At least, then, for me, I will know which version I'm working with in the machine. HOWEVER, this doesn't guarantee that someone else (or even myself, previously) didn't connect to this machine and then NOT follow my convention.
Thanks for the response!
Do-more PLCs have a built-in Project Notes mechanism that you can easily enter notes in the Download Project to PLC dialog box. It's right there, right when you are writing your project to the PLC:
Every time you enter something in that field, it prepends that entry to the PLC Notes file, along with the current PLC user session's user name and date/time stamp. By prepending, the most recent notes are at the top, making it easy to see what was done most recently.
It gets saved with the project file on disk and in the PLC. You can print it out with your ladder logic, or look at it from this dialog (just hit the Project Notes Editor button):
Note the user name and download time stamp that automatically got added to the download entry note.
That's interesting!
Related to this topic is major events that occur to a Do-more PLC are logged internally by the PLC, e.g. clearing the PLC, PROGRAM/RUN mode changes, downloads, changes to I/O configuration after power-up, etc. Date/Time stamp is recorded, along with the logged in user if it was an event performed by a user via communications. PLC->System Information menu item, select Event Logs tab.
While not exactly project management details, it is helpful information.
The PLC event logging mechanism is also available via ladder logic via the STREAMOUT instruction using the UserLog device (vs. a serial port), and you provide it a string that you generated the customized log text via the STRPRINT instruction.