Redocumenting an existing PLC 5 program

G

Thread Starter

Grady Hart

I have recently inherited a number of Allen-Bradley PLC5 systems that have programs without memory mapping or flow charts for them. Need suggestions on how to document the program best.

The program was originally written for an AB PLC2-30. When the application was rewritten for the PLC5, it was not structured at all. In other words, the program was all contained in one file.

I would like to document the program and rearrange it to make it easier to follow. My management is also asking for a 'flowchart' of the program.

Any help out here 'in controlnerd' land?

Thanks.
 
M

Michael Griffin

The PLC5 program is likely contained in one file because the PLC2/30 program was like that. Whoever did the work likely did a literal translation. If I recall correctly, the PLC2/30 only allowed one subroutine. You will probably however find that there is some structure in the form of the ordering of the rungs.

If the original program followed the normal convention of the time, related rungs would be grouped together. You may be able to draw lines across a print out the program at various points, and then lift these sections directly into subroutines. Breaking the program up into smaller pieces will make it easier to follow. If you are going to do more rewriting than this, then you might as well rewrite the entire program from scratch.

As to how to do a "flow chart", I would suggest that if the process follows a regular sequence then draw an SFC (grafcet) chart. The chart will give people a good overview of what the machine does. Don't try to use the chart to document the state of each and every input or output, as it is likely that people will over time make minor changes to the program without updating the chart.

You can easily draw an SFC using the drawing features of most word processors (its just boxes and lines after all). Its easier to do it in a word processor than doing it in CAD, because you can add additional pages of text and tables while keeping it all in one document.

If the real problem that your management is trying to address is excessive downtime on the machine, I would suggest following this up with adding a small inexpensive MMI panel or text display to show alarm messages to assist in diagnosing faults. It is likely that the reason people need to read the program frequently is because they are using the programming software to try to find out which input the machine is waiting for whenever they have a fault.
 
Fire the person who converted it, or the management who did not know but unfortunately you are mostlt out of luck and must manually decipher it.

Dave
 
B

Bob Peterson

I can't tell you how many times I have run across similar situations.

Reverse engineering them is relatively easy if you know how the machine works and have the time.
 
J

Jeremy Pollard

Start with the IO then output addresses as best you can .. then group rungs as best you can.. problem lies in scan related positioning of rungs since this type of programming allows for insertion of unrelated code and is relying on program position ..

Then try and ID data table files words bit in that order..

Just need to be careful!!

And good luck - never fun

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579
 
G
Thanks for the affirmation of my opinions. Sometimes it helps to check one's own sanity.

Regards,

Grady
 
Top