Good Programming Practice: Latches?

[mellis]

Please folks, first it's superstition, now it's disinformation.

S7Guy, the reason the two examples behave differently is simply this. In the AB way of doing things, all addresses referenced by OTE instructions are set to 0 before the first logic scan after a power failure or a change to run mode. AB calls this a prescan. That's it. Period. All memory is retentive, but the prescan specifically resets anything with a OTE instruction regardless if it is executable or not.

Ron Beaufort has some excellent posts covering this.

I guess I am going to have to eat my words from the previous post. Apparently we need to state in capital letters "YES, YOU NEED TO UNDERSTAND HOW THE PLC ACTUALLY WORKS".

 

[mellis]

This can be avoided by making a standard set of logic and passing in parameters and/or by using indirect addressing and FOR loops.

Help me to understand what you are talking about here. I'm thinking we are not on the same page at all but I'm happy to learn a new method.

In the first example, each valves logic had an XIC instruction for each sequence and step that commanded it to open or close. This was perceived as a "neccessity for troubleshooting". I don't agree with it, but that was the idea. The problem is that it is difficult to maintain and easy to make mistakes in maintaining the code through sequence changes.

No light is going on for me on how passing parameters or indirect addressing will improve the situation or be simpler than using OTLs to command the valves. Please elaborate.

 

[S7Guy]

S7Guy, the reason the two examples behave differently is simply this. In the AB way of doing things, all addresses referenced by OTE instructions are set to 0 before the first logic scan after a power failure or a change to run mode. AB calls this a prescan. That's it. Period. All memory is retentive, but the prescan specifically resets anything with a OTE instruction regardless if it is executable or not.

That's very interesting, but it's also scary. How does it handle indirectly-addressed bits that were set dynamically before the power down? Does it keep a dynamic list of them in the CPU, i.e. these bits were set by a latch and these were set by a seal the last time they were evaluated?

 

[mellis]

No, it's really very simple. It keeps no special lists, there is nothing special about a bit set by a latch instruction. What it does is simply run through the entire program without executing it and every place it finds an OTE instruction, it sets the associated address to 0. Once you know how it works, it is easy to understand and predict what the action will be.

If you have an OTE instruction using indirect addressing, I would expect it to set the address it evaluates to based on current data to 0. I would not expect it to have any clue as to what range of values have been used in the past. Caveat: I don't have the ability to test this right now, but I would be very surprised if it behaved differently.

 

[Ron Beaufort]

if it bleeds, we can kill it ...

well, my goodness ...

first of all, let me say that MOST of the recent questions could be answered by carefully viewing the series of videos available from the Sample Lessons page of my website ... video number 11 is actually the one that specifically covers the "Retentive" instructions – but I'll absolutely GUARANTEE that the material it contains will make a LOT more sense to most people if they would watch the entire series all the way through IN ORDER ...

there are also some very helpful ideas in those two links that I provided way back in Post #9 of this thread ...

anyway ...

I'm pretty sure that in Post #42 jstolaruk didn't mean that ALL of those rungs should be used at the same time ... more likely he intended to show a side-by-side comparison of the two programming approaches ...

but then again, since the stone has been turned (so to speak) let's go ahead and run through a quick analysis of the "program" shown in the figure below ... once again, this is NOT a recommended way to write the program – just a simplified attempt to look under the hood of the PLC and try to get a handle on the confusion ...

notice the figure attached below ... I've included a "truth table" to show the four possible conditions of the two field inputs X and Y – and the resulting status of a real-world field output device ... many (MOST?) people confuse the relationships between the output INSTRUCTIONS in the rungs - and the BIT/BOXES in the processor's memory – and the output DEVICES located in the field ... to cut down as much as possible on that sort of confusion, I've decided to replace the internal bit B3/1 in jstolaruk's original program with a real-world output device – a LAMP ...

and so ... what follows is a SIMPLIFIED breakdown of what's going on as the processor executes the rungs ...

CONDITION A ... on rung 0000, the XIC for Y is FALSE ... the OTE writes a ZERO into the lamp's bit/box ... on rung 0001, the XIC for X is FALSE ... the OTL does nothing ... on rung 0002, the XIC for Y is FALSE ... the OTU does nothing ... so at the end of each pass through the ladders, the bit/box for the lamp contains a status of ZERO ... in condition A, the LAMP device in the field will be turned OFF ...

CONDITION B ... on rung 0000, the XIC for Y is TRUE ... but the XIC for X and the XIC for the lamp are both FALSE ... the OTE writes a ZERO into the lamp's bit/box ... on rung 0001, the XIC for X is FALSE ... the OTL does nothing ... on rung 0002, the XIC for Y is TRUE ... the OTU writes a ZERO into the lamp's bit/box ... so at the end of each pass through the ladders, the bit/box for the lamp contains a status of ZERO ... in condition B, the LAMP device in the field will be turned OFF ...

CONDITION C ... on rung 0000, the XIC for Y is FALSE ... the OTE writes a ZERO into the lamp's bit/box ... on rung 0001, the XIC for X is TRUE ... the OTL writes a ONE into the lamp's bit/box ... on rung 0002, the XIC for Y is FALSE ... the OTU does nothing ... so at the end of each pass through the ladders, the bit/box for the lamp contains a status of ONE ... in condition C, the LAMP device in the field will be turned ON ...

CONDITION D ... on rung 0000, the XIC for Y is TRUE ... the XIC for X is TRUE ... the OTE writes a ONE into the lamp's bit/box ... on rung 0001, the XIC for X is TRUE ... the OTL writes a ONE into the lamp's bit/box ... on rung 0002, the XIC for Y is TRUE ... the OTU writes a ZERO into the lamp's bit/box ... so at the end of each pass through the ladders, the bit/box for the lamp contains a status of ZERO ... in condition D, the LAMP device in the field will be turned OFF ...

summary: condition C (highlighted) is the only setup that will "turn on" the LAMP in the field ... and incidentally, condition C is the setup shown in the figure below ...

disclaimer: the description above is intended for Allen-Bradley processors in the PLC-5, SLC-500, and MicroLogix platforms ... the description would be DIFFERENT for a ControlLogix or CompactLogix system ... as for Siemens, etc. – well I have ZERO experience with those – so I'll leave that subject open for discussion ...

and finally:

Ron Beaufort has some excellent posts covering this.

thank you, mellis ... I appreciate the kind compliment ...

party on, folks ...

 

[Ron Beaufort]

from the "show and tell" box ...

and incidentally, here's a snapshot of a "latching" relay that works pretty much the way the OTL and OTU instructions do in an Allen-Bradley ... specifically, there's one coil to "latch" the contacts – and another separate coil to "unlatch" ... the two sections are mechanically linked together ...

 

[rootboy]

Can ypu expand on this? I did not think older ab controllers had asynchronous i/o only contrologix? Or am i missing something?

Have I used the wrong terminology?

The old PLC-2 by default would receive its inputs anywhere in the program scan. It came as quite the surprise the first time I worked on a PLC-2. I was used to the GE Series Six where the inputs were updated at the beginning of the scan.

 

[kolyur]

I have been reading this thread with interest, as I usually do with the "latches are great vs. latches are evil" threads that pop up every so often. I have been programming for about 10 years and my ladder logic knowledge is mainly self-taught, so I don't have the benefit (or burden, I suppose) of these old-school "superstitions" concerning OTL/OTU coils. The result? I use latches quite frequently. I am well aware of the intricacies of OTE vs. OTL/OTU, and latching coils are just better suited for sequential logic, which is the bulk of my work. I remain unconvinced by all the arguments I have read against them.

My usual method for programming a sequence is as follows:
1. Use an integer register to store the current sequence step. Use increments of 10 to allow for addition of steps later on.
2. Steps 0-99 are for initialization after power-up or E-stop recovery. Step 0 always zeros all outputs that may have been latched. Step 100 is the idle state after initialization. Step 200 is the start of the main sequence, and when the sequence is finished it returns to step 100.
3. As the main sequence progresses, real-world outputs are latched and unlatched at the proper steps.

A common mantra I hear in this thread is that real-world outputs shouldn't be latched, although I haven't heard any good reasons why not. To me, it improves the code readability. I like my sequences to be chronological--I can look down through the sequence steps and see when devices are turning on and off. So my question to all the non-latchers out there is: how do you handle output control during a sequence? For a large sequence, I may have output devices that need to be energized during multiple, non-consecutive steps. The only way I can see to do this without latches would be to put the OTE coils elsewhere in the program with combinations of GRT, LES, EQU logic to activate them according to the active step. It seems to me that this would make the program much more difficult to troubleshoot. Sure, now I can see all the conditions that make a certain output true, but how do I know what Step 267 is unless I'm simultaneously looking at the sequence logic? My laptop screen just isn't that big.

Not trying to be argumentative here, just want to understand the opposing views.

 

[mellis]

My usual method for programming a sequence is as follows:
1. Use an integer register to store the current sequence step. Use increments of 10 to allow for addition of steps later on.
2. Steps 0-99 are for initialization after power-up or E-stop recovery. Step 0 always zeros all outputs that may have been latched. Step 100 is the idle state after initialization. Step 200 is the start of the main sequence, and when the sequence is finished it returns to step 100.
3. As the main sequence progresses, real-world outputs are latched and unlatched at the proper steps.

A common mantra I hear in this thread is that real-world outputs shouldn't be latched, although I haven't heard any good reasons why not. To me, it improves the code readability. I like my sequences to be chronological--I can look down through the sequence steps and see when devices are turning on and off. So my question to all the non-latchers out there is: how do you handle output control during a sequence? For a large sequence, I may have output devices that need to be energized during multiple, non-consecutive steps. The only way I can see to do this without latches would be to put the OTE coils elsewhere in the program with combinations of GRT, LES, EQU logic to activate them according to the active step. It seems to me that this would make the program much more difficult to troubleshoot. Sure, now I can see all the conditions that make a certain output true, but how do I know what Step 267 is unless I'm simultaneously looking at the sequence logic? My laptop screen just isn't that big.

Not trying to be argumentative here, just want to understand the opposing views.

We're pretty much on the same page here. I do things a little differently, but the basic ideas are similar.

I don't OTL or OTU real world outputs normally. But that is because the sequence isn't the only thing that can control the outputs in the systems I work on. The operators can open and close valves from the screen when a sequence is not running. So, I need another layer of logic between the sequencer and the real I/O. I also do interlocking there, usually two levels. One that can be bypassed with sufficient access level, and one that can't. Real safety interlocks are done in hardware.

What I do instead is OTL command bits to this "device level" logic from the sequence. I could use 1 bit and OTL it for open and OTU it for closed, but I prefer to use 2 bits and OTL one for open and one for closed. The "device level" logic takes care of OTUing the bits after it has responded to the command.

 

[Ron Beaufort]

Greetings kolyur ...

I like my sequences to be chronological--I can look down through the sequence steps and see when devices are turning on and off. So my question to all the non-latchers out there is: how do you handle output control during a sequence? For a large sequence, I may have output devices that need to be energized during multiple, non-consecutive steps.

the "textbook" answer to your question runs something like this:

suppose that we have a ladder program of 100 rungs (just to have a number for discussion) ... suppose that we have 4 "steps" in our machine sequence ... suppose that each step requires 25 rungs of logic ...

now suppose that we have a particular real-world output device (for example a MOTOR) that needs to be turned ON in step 1 and step 3 – but must be turned OFF in steps 2 and 4 ...

beginning programmers will often write "top to bottom" programming step by step through all of the sequence steps ... so then ... if the MOTOR is controlled by an OTE located within the code section for step 1, we might have an "issue" when we get around to programming step 3 ...

basically the problem is this: if we already have the MOTOR controlled by an OTE up in step 1, putting another OTE for the MOTOR down in step 3 is going to be a "double-coil" arrangement that will NOT work the way we want it too ...

now some programmers work around this by using a LATCH and UNLATCH arrangement for the MOTOR in step 1 – and then another LATCH and UNLATCH arrangement for the MOTOR in step 3 ... and this WILL work ...

note: it will certainly "work" ok in normal day-to-day operation – but the programmer MUST consider that the MOTOR might unexpectedly start back up again after a power failure, etc. ...

and to answer your specific question:

another perfectly valid programming method is to assign an internal "marker" bit for each step that needs the MOTOR turned on ...

suppose that we assign B3/11 as "Step 1 needs MOTOR to be ON" ...

suppose that we assign B3/13 as "Step 3 needs MOTOR to be ON" ...

now then ... at the bitter end of our ladder logic (often in a separate subroutine file for "cleaness") we can easily "map" the status of those internal bits to control each of our real-world output devices ... an example figure is show below ...

a couple of BIG TICKET advantages to this method are worth mentioning ...

(1) maintenance technicians love this approach because they're often just trying to figure out why a certain "output" device won't run ... the "output mapping" area gives them a quick index into all of the output field devices – and from there it usually takes only a quick cross-reference or "find all" search to track down what step in the logic is causing the problem ...

(2) in cases where an output module's circuit is "blown" and can't control the output, it's easy for a technician to move the field wiring over to an unused terminal – and then easily "remap" the control over to the new output address ...

but the BIGGEST advantage (from a programmer's viewpoint) is that the control for the MOTOR can be easily separated into the various "steps" where it's needed without having to mix and convolute the logic from one sequential step into another ...

finally for now (almost out of typing time) there is NOTHING inherently good or bad about LATCHES and UNLATCHES – and there is also NOTHING wrong with using "seal-in" rungs instead ... the BIG – BIG – BIG idea is that a program written with ONE method will often react DIFFERENTLY and UNEXPECTEDLY from a program written with the other method when the PLC first starts-up or resumes operation after a power cycle ... once the programmer understands the operational differences and PROPERLY IMPLEMENTS the safety aspects, then I personally have ZERO problem with either method ...

what I see as the biggest problem is that many programmers have never been taught the differences in operation – and they simply regard the use (or disuse) of LATCHES as purely a "dealer's choice" design issue ...

the point I've constantly been trying to make is that there's a LOT more to using LATCHES vs. SEAL-INS than having "simpler rungs" and improving "ease of reading" ...

 

[kolyur]

Wow Ron, either you can type like a madman or have some serious copy/paste skills... thanks for the detailed response. It sounds like you and mellis have the same suggestion--use a separate "layer" of internal bits to track when specific outputs should be on, and map them to the actual output points in a different location.

another perfectly valid programming method is to assign an internal "marker" bit for each step that needs the MOTOR turned on ...

suppose that we assign B3/11 as "Step 1 needs MOTOR to be ON" ...

suppose that we assign B3/13 as "Step 3 needs MOTOR to be ON" ...

now then ... at the bitter end of our ladder logic (often in a separate subroutine file for "cleaness") we can easily "map" the status of those internal bits to control each of our real-world output devices ...

I gather from your explanation that these marker bits are used with OTE coils inside the sequence (thus a different bit for each output on each step where it is activated). This could get very unwieldy if you have large numbers of outputs controlled from a single sequence. A 10-step sequence controlling 10 outputs would require up to 100 marker bits depending on where the outputs are energized.

My current project has over 500 PLC outputs, many of which are part of sequences. It seems to me that introducing an additional level of control, plus the mapping subroutine, would create a significant amount of overhead and I frankly don't see much value in it.

(1) maintenance technicians love this approach because they're often just trying to figure out why a certain "output" device won't run ... the "output mapping" area gives them a quick index into all of the output field devices – and from there it usually takes only a quick cross-reference or "find all" search to track down what step in the logic is causing the problem ...

I see your point here, if that is how a tech has been trained to troubleshoot a problem. However, I would contend that a Find All search on the latched output in any of its locations would be just as useful to someone who understands how latches work.

(2) in cases where an output module's circuit is "blown" and can't control the output, it's easy for a technician to move the field wiring over to an unused terminal – and then easily "remap" the control over to the new output address ...

Doing a Find and Replace All with the output's address would be just as simple, unless you are restricted to online editing.

but the BIGGEST advantage (from a programmer's viewpoint) is that the control for the MOTOR can be easily separated into the various "steps" where it's needed without having to mix and convolute the logic from one sequential step into another ...

I agree there is an advantage to this, but it comes at a cost.

I don't OTL or OTU real world outputs normally. But that is because the sequence isn't the only thing that can control the outputs in the systems I work on. The operators can open and close valves from the screen when a sequence is not running. So, I need another layer of logic between the sequencer and the real I/O. I also do interlocking there, usually two levels. One that can be bypassed with sufficient access level, and one that can't.

I do have this issue as well; in my case there is a "manual" mode where an authorized person can activate certain outputs from an HMI. How I handle this is--don't have a heart attack--I directly toggle the PLC outputs from the HMI program. I feel comfortable doing this because:
1. Machine safety is all hardwired of course, so there is no personnel safety issue.
2. Most outputs that need manual control are already controlled using latches within the sequences, so there is no extra PLC logic required (well almost... see #3). For outputs controlled with OTEs, I either use an internal "marker" bit as was suggested or use JMP/LBL instructions to bypass the relevant logic so the HMI has control when necessary.
3. I use permissives and interlocks as needed in the ladder logic and HMI program so that an operator cannot access the manual controls if the machine is not in a proper state.