Programming instructions

[JeffKiper 9]

I just started a job that will require me to write plc code. I have several years of code troubleshooting and maintenance. I understand that there is a need for every instruction but I have heard of large corp. having standard programming practices or instructions to use and not to use. Has anyone else ever ran across any of these or have a set to start with?

[gravitar 3]

I'm sure some corporations have written specs that are that specific, but I can tell you that the Big 3 don't! I've never been made aware of any instructions that are "off limits".

[JeffKiper 9]

Gravitar I had thought at least one of them would have a setup. I came from a company that NO SQL, SQO. They stated that these instructions where too complicated for the average electrician. I tried too use that a fuel for training. Notice that I do not work there anymore. Thanks for the reply.

[paulengr 44]

There are certain things that I try to avoid. SQI/SQO is definitely one of them. I try to keep OTL/OTU close to each other or else logically organized so that you don't have to search all over the darned program. I try NOT to have multiple MCP's unless they are distinctly different systems. I try NOT to use MCR zones (they are not a replacement for a real E-Stop, and debugging them can be very confusing). I try TO use AFI'd out COP type instructions to specifically document when I use indirect addressing tables. I try TO use AFI'd out JSR's to an STI or PII. I try to use pretty much nothing but "global" things and JSR's off to multiple subroutines to break the program up into logical ladders. I try NOT to use conditions on JSR's as again...this tends to make the code confusing. For certain types of programs, structured text and SFC's make sense. For the vast majority, stay away. I try to avoid use of ONS excessively. You CAN write an entire program without a single ONS by judicious use of hold bits and such, but the general rule I follow is to avoid ONS unless it makes sense to have one and that is the cleanest way to write the code. I try to use strength reduction whenever appropriate. CPT N7:0 0 is just plain sloppy. So is CPT N7:0 N7:0+1. The specific instructions (CLR, MOV, ADD, SUB, MUL, etc.) are not only more clear but unless it makes sense to use CPT (when you are trying to do more than 2 operations in a single expression), I avoid using it. I try to use strictly "read" type MSG's instructions whenever possible. Whenever not possible, again I use an AFI'd block memory operation just to document what's going on to someone that doesn't have time to search all the PLC's to figure it out. I try to specifically document the MSG instruction directly in the MGx:y comment so that someone can read what is going on without opening up all the MSG instructions to decode it.

[paulengr 44]

I would also suggest sticking with "level" as opposed to "transition" logic. I forgot the exact terms but the two forms of logic for controlling an output can be best illustrated by the difference between an OTE and OTL/OTU logic. Imagine the classic "start/stop" push button circuit controlling a starter. With OTL/OTU-based logic, the instructions for the start/stop circuit would be: XIC StartPB OTL Starter XIC StopPB OTU Starter Now, for OTE-based logic it gets a lot more complicated because you have to add "holding" or "sealing" latch type logic. By itself, this example is no big deal. Where it comes into play is that it creates "implicit" as opposed to "explicit" state. The state of the output with OTL/OTU logic is not immediately visible in the logic...it depends on past history. With OTE-based logic, the output state is determined during every scan. Where this matters is in troubleshooting and debugging. With the "implicit" type of logic, how and why a particular output got to the state that it is currently in is not visible. With the explicit type, even if it isn't obvious what triggered the holding logic, it is still obvious that the holding logic is active.

[patb63 0]

paulengr- I read this thread browsing through the forum and I have a question for you. Can you give me an example of what you meant when you said you avoid using the ONS instruction by using "hold" bits? We use the ONS instruction quite a bit sometimes and I'm curious as to your method of avoiding them. Thanks.

[paulengr 44]

Sure...here's a simple example of what drives me crazy with ONS logic: Say we're controlling a variable speed device, say a pump or an actuator (hydraulic or pneumatic). The output signal is an integer telling it how fast to go. If you need smooth control, it gets implemented either via the inertia of the device or the control loop in the device. In the PLC, you may have something like this: If event A happens, then (ONS) set output=speed A If event B happens, then (ONS) set output=speed B If event C happens, then (ONS) set output=speed C This works, and it essentially means that the output becomes something of a "stored state" because no particular rung is ever "live" except for a single scan. However, it is difficult to troubleshoot because except for a single scan, each of the rungs is effectively "dead". So you have to sort of sleuth out the "last active" rung. Troubleshooting these can be a nightmare because the history of events (what order did event A, B, and C happen in) is more important than the current state of the system. The easiest way to fix this one is to drop the one-shots. The latching example I gave is another example of this, and sometimes similar logic uses one shots (in this case, "output=true" is a generic term...supply your own interpretation). If startPB then (ONS) output=true if stopPB then (ONS) output=false You can convert it to "sealing" or "latching" type logic by using the classic "holding" circuit for start/stop push buttons as follows: If (startPB=true or output=true) and (not stopPB) then output=true In this bit of logic, the start push button triggers the rung to go true and then the "holding" or "latching" branch (output=true) maintains the output until it is released by the second condition. You can use this exact same sort of logic to implement your own one shots, too... If (start condition or <latch bit>=true) and (not start condition) then <latch bit>=true

[patb63 0]

I follow what you're saying and I agree. Our use of the ONS instruction is a little different. We use it to only give us one instance of an event happening.....usually when a photoeye gets blocked, we only want to perform operations on the leading edge of the carton (i.e. starting to track it down a conveyor, increment counts, etc.) Thanks for your input...did I just make a pun?!?!?!?!