Ladder Logic 103: More on Program Organization

Today’s post covers a bit more on program organization and layout. A reader posted a question on a previous post “Ladder Logic 204: Auto Sequences”:

“I’m still really new to the field and have yet to create my own program from scratch (currently maintain other programs that have already been written). For creating a new program, I’m stuck on organization of the logical layout as compared to the physical layout of the machine. In other posts, you talk of having a hierarchy of Machine > Zone > Cells… and in one of your Automation Cycle posts, you suggest that a single Cell can have multiple Work Cycles (ie. Part Load, Process1, Process2, Unload, etc.)… In the ladder layout pictured on this post, would u consider the Main Program to be at the Zone Level or the Machine level? Do you know of any examples on the web that show how these different labels can be applied to a machine (ie a machine layout with each area labeled as Zone > Cell > Work Cycle)?”

This is a really good question and provides an opportunity for me to elaborate a bit on the subject. Thanks Neb!

 The layout to the left is the one used in the example discussed in the previous post. Disclaimer: as Gordon mentioned and as discussed in Ladder Logic 206: Scanning, the b_Inputs/c_Outputs/d_AutoSequence rungs are not in the best order. They should be listed as b_Inputs/c_AutoSequence(s)/d_Outputs! In this example, all of the sequences would be considered as “cell” level. There are no zones in this particular example.

If I were to use multiple sequences in a particular cell, they might be listed as “c1_AutoSequence1, c2_AutoSequence2, c3_….” etc. The sequences might control separate elements of a machine within a cell or one sequence might be divided into several “sub-sequences”. Sometimes due to the complexity of a cell there might be a sequence that actually sequences sequencers!

An example of this might be a sequence that controls a device that communicates with ASCII characters to the PLC. I often write sequences that parse letters to create bit-level commands. In this case, there might be sequences named “c1_AutoSeq_DeviceMaster, c2_AutoSeq_ReadData, c3_AutoSeq_DeviceOperate,” and “c4_AutoSeq_WriteData”. The DeviceMaster sequence would then start ReadData, wait for the data and convert it to bits, perform whatever operation is required in DeviceOperate, wait for the operation to complete, write to the device in WriteData, wait for confirmation that the device has received the information, and end the DeviceMaster sequence.

There may also be c5, c6 and c7 sequences that would control different mechanisms within the cell. This depends on how your cells are assigned. If there are too many sequences within a cell there is a good chance that the cell could have been divided into further cells.

Now to the question about zones: typically I use zones as a logical division of groups of cells. I put all of my mechanism-operating auto sequences within the cells. The main reason I have found for dividing a machine into zones is if the groups of cells operate autonomously. A zone then can almost be thought of as a separate machine. Often zones will each have their own safety circuits so that if a guard door opens it only shuts down the zone (or group of cells) that is behind the set of doors. Because of this, within the Main Task there may be programs called Zone_1, Zone_2, etc. Within the programs may be Input, Output and Fault routines along with routines that link to all of the cells assigned to the zone. Often data acquisition or productivity information may also be gathered at the zone level. The inputs and outputs would generally only be those that affect all of the cells such as safety or indication I/O. Perhaps a zone would also have a HMI that only controls devices within the zone, HMI bit mapping could also then be contained in the Zone program and routines.

There are no hard and fast rules for the organization of PLC programs. This particular method is one that is used by several large machine builders, but there are several other widely used organizational techniques. To me, the most important aspect of program organization is to make a machine easy to troubleshoot and modify. Last week I mentioned another large machine building company that uses a different technique and seems to have a different philosophy about programming. They have a large support staff and would probably rather not have customers doing significant modification to their programs (that’s how it appears anyway; their stuff seems purposely cryptic). That doesn’t necessarily make them wrong (yes it does).

The week after next I will be teaching a couple of PLC classes in the Raleigh-Durham area of North Carolina. These classes are through another company and cover the basics of PLC programming using a specific platform which I will mention in my post at the end of this month. I have considered teaching a non-platform-specific class on advanced PLC programming that covers topics such as program organization, but the logistics of how to do it are stumping me right now. There are several platforms I could probably use to do it, but I may simply wait until some company wants me to customize a class to their brand of PLC.

If you are interested in formal training on some automation topic including PLC programming please let me know. For standard classes I am working through a particular company, but if the topic you want to cover isn’t provided by this company or others I would be interested in setting something up. More on this company in a later post; I would like to have taught one class for them before mentioning specifics. This company will be my topic on September 29, 2013. Stay tuned for more!