AB PLC5 latch/unlatch again!

[chappy62]

Another very basic question.

I have read ALL of Ron Beaufort's latch/unlatch comments and full blown explainations I could find on this board.
I thought I understood the concept until yesterday when I talked with another engineer at work.

Here is what I think I have read repeatedly on this board:
Rung has continuity so latch instruction is true. Set the address in memory of the latch instruction with a "1".
Rung does not have continuity so latch instruction is false make no change to the address of the latch instruction.
Rung has continuity so unlatch instruction is true. Clear the address in memory of the unlatch instruction IE: put a 0 there.
Rung does not have continuity so unlatch instruction is false, make no change to the address of the latch instruction.
Last instruction to write to the memory address wins.

Have I missed something? The conversation yesterday was "just because the latch and unlatch instruction for the same address in memory was highlighted in green in the running program does not necessarily indicate that there is a "1" in that location.

If the latch/unlatch pair show as true IE; highlighted in green in RSLogix I thiught this would indicate that a "1" was in this memory location.

Of course I believed the opposite would follow that if there was a "0" in the address that the latch/unlatch pair would not be highlighted.

Can anyone enlighten a newbie? Thanks

 

[Operaghost]

You are correct in that a "1" will result in the highlighted latch/unlatch and a "0" will show them non-highlighted. I did not see the thread you mentioned but I will look for it.OG

 

[Ron Beaufort]

slightly beyond the basics ...

Greetings chappy62,



you didn’t post a copy of your program - but I think that I understand what you’re describing ... based on my interpretation of your statements:

Rung has continuity so latch instruction is true. Set the address in memory of the latch instruction with a "1".

the statement above is perfect ...

Rung does not have continuity so latch instruction is false make no change to the address of the latch instruction.

the statement above is perfect ...

Rung has continuity so unlatch instruction is true. Clear the address in memory of the unlatch instruction IE: put a 0 there.

the statement above is perfect ...

Rung does not have continuity so unlatch instruction is false, make no change to the address of the latch instruction.

the statement above is perfect ...

Last instruction to write to the memory address wins.

the statement above needs some work ... see below ...

The conversation yesterday was "just because the latch and unlatch instruction for the same address in memory was highlighted in green in the running program does not necessarily indicate that there is a "1" in that location.

the statement above is correct ... let’s also look at the converse in a paraphrase ...

just because the latch and unlatch instruction for the same address in memory was NOT highlighted in green in the running program does not necessarily indicate that there is a "0" in that location.

the statement above is correct ...



here’s the tricky part ... question: WHO is painting the green on your display screen? ... big hint: it is NOT the processor who is doing this ... answer: it’s the RSLogix software who decides (as best it can) whether or not to highlight the instructions in green ... next question: how does the software obtain the information that it needs in order to make its “to-highlight-or-not-to-highlight” decisions? ... answer: the information comes over some type of communications cable between your computer and the processor ...



secret handshake: no matter how fast the communications is set up (baud rate, etc.), the information reflected on your programming screen is NEVER completely “real-time” ... specifically, the status information cannot possibly change rung-by-rung as quickly as the processor can execute the ladder logic ... therefore (and here’s the trick) it follows that the “highlighted” or “not highlighted” status which you see on the screen cannot be fully trusted as the final authority on whether a memory location (bit) actually contains a “1” or a “0” at any one point in the ladder logic scan ...



my former students will tell you that a significant portion of our week-long “troubleshooting” class is spent in dispelling and disproving all of the students’ prior misconceptions about how to CORRECTLY interpret those highlighted/not-highlighted indications on the screen during a troubleshooting session ... in other words, you are CERTAINLY not alone in being confused by this effect ...



below is an example program from a PLC-5 that should help you nail this particular idea down ... you might want to duplicate this in a spare system to experiment with on your own ...

in the unconditional Rung 0000, the ADD instruction increments the value of F8:0 by one each time the processor scans this rung ...

in Rung 0001, the OTL instruction writes a “1” into the bit/box B3/0 ...



in Rung 0002, the XIC instruction sees the “1” in the bit/box and so the processor evaluates the XIC as “true” ... the ADD instruction increments the value of F8:1 by one each time the processor scans this rung ...



in Rung 0003, the OTU instruction writes a “0” into the bit/box B3/0 ...



in Rung 0004, the XIC instruction does not see a “1” in the bit/box and so the processor evaluates the XIC as “false” ... the ADD instruction does NOT increment the value of F8:2 when the processor scans this rung ...

the major idea is that the status of the bit/box B3/0 is indeed toggling back and forth between “1” and “0” each and every time that the processor scans the program ... but ... the instructions for B3/0 are NOT rapidly being updated from a “highlighted” to a “non-highlighted” state on the screen ... simple reason: the screen cannot possibly be updated over the communication cable fast enough for the “highlighted” status to be kept completely current ...



going one step further ... with most communications setups, the PLC-5 family will cause “erratic” highlighting in a situation like the one that I’ve shown above ... in other words, if you duplicate the program shown above and stare at its operation long enough, the you WILL probably see the instructions for B3/0 all “highlight” in green from time to time ... it will only be a brief flicker so you’ll have to watch closely ... and it’s a random thing ... you might have to stare at it for seconds, minutes, hours, or even days ... the basic idea is that with most communications setups, the PLC-5 processor communicates with the programming software at RANDOM POINTS within the ladder logic scan ... so in the program above, there is a small “window of opportunity” after Rung 0001 and before Rung 0003 where the status of bit/box B3/0 is indeed a “1” - and the instructions will indeed highlight in green if that “1” status happens to be communicated to your programming station ... if you want to experiment with this “random update” effect, try putting a number of extra “do nothing” rungs between Rung 0001 and Rung 0003 ... that will increase the “1” status time slot and load the dice for more “flicker” chances to occur ...



now if you put the same test program into a processor from the SLC-500 family, chances are that you will NEVER see the green highlight flicker on ... that’s because with most communications setups, these smaller processors always communicate at the very end of the ladder scan ... therefore, the intermediate “1” status, which does indeed occur on each and every scan, never gets a chance to affect the “not highlighted” display on the screen ...



I hope this helps ... if you still have questions, please post again ...

 

[bornwild]

Sorry for resurrected this thread .Btw Thanks Ron. Today at work i had latch and unlatch both on(green) at the same time. Which one should i trust?. The program is that if there is error it will latch and if i press reset button it will unlatch. I don't know which one to trust.

 

[Mickey]

Sorry for resurrected this thread .Btw Thanks Ron. Today at work i had latch and unlatch both on(green) at the same time. Which one should i trust?. The program is that if there is error it will latch and if i press reset button it will unlatch. I don't know which one to trust.

The green highlight reflects the state of the data table ( bit box as Ron calls it). If the data table is "1" then the address with the OTL and OTU
is going to be green ( highlighted). If the data table is "0" then the address with the OTL and OTU is not going to be highlighted even if the rung with the OTU instruction is true the address will not be highlighted. That's because the data table is"0".

So believe the data table.

I'm sure Ron(others) will be along to give a much better(clearer) explanation.

 

[bernie_carlton]

In my interpretation based on using the programming packages the status of rung conditional instructions (those before the final column) are highlighted to show the truth status of the conditional instruction. The single bit output instructions are highlighted to show the truth status of the actual bit.

BUT, the information RSLogix used to decide what to highlight is that which existed at the time the communication with the processor for that particular piece of information took place. As far as I know the communication cannot ask for the status of data AT A PARTICULAR POINT IN THE SCAN. In processors where all communication takes place between scans this at least has some degree of certainty - the status show is that which was true at the end of a particular scan.

But now that processors are coming out (note the ControlLogix line) where I/O updates and communications are being handled by separate CPUs it can be anyone's guess when it comes to exactly what the status of data was at a particular scan point.

 

[Ron Beaufort]

Today at work i had latch and unlatch both on(green) at the same time. Which one should i trust?.

do you want the honest truth? ... you can't FULLY trust the green on either one of them ... but that's getting pretty deep – so let's take this one step at a time ...

here's the "beginner level" answer I think you're asking for ... if both the Latch and the Unlatch instructions were green, then there was a ONE status in the bit/box on the data table ... assuming (gosh, I hate that word) that everything else was "normal" – then the bit/box was "latched" on ...

now let's go beyond the beginner level ... first things first ...

the PLC processor (the "brains" of the system) does NOT go through your program painting things green for you ... the PLC processor NEVER does that ... the only thing that decides whether things should be highlighted green or not is the RSLogix SOFTWARE running on your computer ... the software makes its "best guess" on what should be painted green based on the information that it has available in its data files ...

that is an INCREDIBLY IMPORTANT concept – so do not take my word for it ... instead perform the following experiment to prove it to yourself ... you can try this with any of the RSLogix software packages (5, 500, or 5000) and get exactly the same results ...

write a new "test" program with just two rungs as shown in the figure below ... don't even download the program to a processor ... IMPORTANT! ... this will PROVE that the PLC processor does not paint things green – simply because we're doing this experiment OFFLINE with NO processor anywhere in the system ...

first go to the address of LAMP_E on the data table ... this is a "bit" or in other words, a "box" which can hold either a ONE or a ZERO ...

secret handshake: don't make this any harder than it is ... specifically, do NOT say that the bit/box will be "high or low" – or that it will be "true or false" – or that it will be "set or reset" – or any of the other fancy words that people use to describe what is really a VERY simple concept ... the BEST way is to simply say: "there is a ONE in the bit/box" or "there is a ZERO in the bit/box" ... that's exactly what you're going to see when you monitor the data table – but for some strange reason, people feel compelled to make this stuff complicated ...

now with the program entered, try the following three steps – do each step several times – in any order that you like ...

(1) right-click the bit/box on the data table and then "toggle the bit" ...

(2) right-click the OTL (Latch) instruction in the program and then "toggle the bit" ...

(3) right-click the OTU (Unlatch) instruction in the program and then "toggle the bit" ...

here's what you'll see happen on your screen ...

every time that you "toggle the bit" (regardless of where you right-click) the status of the bit/box will be reversed from ONE to ZERO - or vice versa - from ZERO to ONE ...

and ...

whenever the bit/box contains a ONE – the Latch and the Unlatch instructions will BOTH be highlighted in green on your screen ...

there are THREE important concepts being demonstrated here ...

concept (1) ... it does NOT matter WHERE you are when you "toggle the bit" – the results are always identical ... specifically, you are NOT (I repeat: you are NOT) actually toggling the Latch or the Unlatch INSTRUCTIONS in your program ... instead, you are ALWAYS toggling only the BIT/BOX located in the data table ... more specifically, when you right-click on any of the INSTRUCTIONS in the program, the ONLY piece of the puzzle that you are actually making use of is the ADDRESS printed over the instruction ... in this example, you're using the address "LAMP_E" – to point/aim the toggling operation at the bit/box with that same address ...

concept (2) ... the Latch and the Unlatch instructions do NOT get highlighted in green because they are "active" ... in other words, they do NOT get highlighted in green because they are "doing their thing" ... the ONLY reason that the Latch and the Unlatch instructions get highlighted in green is BECAUSE THE RSLOGIX SOFTWARE SEES A ONE IN THE BIT/BOX ... at the nuts-and-bolts level, this means that whenever you see any Latch instruction for any specific address highlighted in green, then any Unlatch instruction for that same address will ALSO be highlighted in green ... (I think that this applies directly to the question that you asked) ...

concept (3) ... it is NOT the PLC processor (I repeat: NOT the processor) who is painting/highlighting things green on the screen for your viewing pleasure ... this is now a proven fact, because we are not even using a PLC processor for this experiment ... specifically, we're still OFFLINE – and therefore NOT even communicating with a PLC processor at this point of the proceedings ...

[continued in the next post] ...

 

[Ron Beaufort]

now let's go further – this time with an ONLINE experiment ...

suppose that we wire up two Normally-Open pushbuttons to an Allen-Bradley PLC ... you can use any of the following hardware platforms and get the same results ... any SLC-500, any MicroLogix, any PLC-5, any ControlLogix, or any CompactLogix ... we'll call one pushbutton "SWITCH_B" - and call the other pushbutton "SWITCH_D" ... (remember that both are to be connected as Normally-Open in the field wiring) ...

now download the program shown below to the processor and go to the Run mode ...

here's what you'll see on your screen ...

(1) whenever SWITCH_B is being pressed and held, the value of F8:1 will be steadily increasing ... here is the reason ... on each pass through the ladder logic, the OTL Latch instruction on Rung 0000 is being executed with TRUE logic ... this tells the PLC processor to "GO WRITE A ONE" into the bit/box for LAMP_E ... then on Rung 0001, the XIC instruction tells the PLC processor to "GO LOOK FOR A ONE" in the bit/box for LAMP_E ... the processor DOES find a ONE in the bit/box – so the XIC is evaluated as TRUE ... the processor then executes the ADD instruction with TRUE logic – which increments/increases the value stored at F8:1 ...

(2) whenever SWITCH_D is being pressed and held, the value of F8:2 will "freeze" and will NOT increase ... here is the reason ... on each pass through the ladder logic, the OTU Unlatch instruction on Rung 0002 is being executed with TRUE logic ... this tells the PLC processor to "GO WRITE A ZERO" into the bit/box for LAMP_E ... then on Rung 0003, the XIC instruction tells the PLC processor to "GO LOOK FOR A ONE" in the bit/box for LAMP_E ... the processor does NOT find a ONE in the bit/box – so the XIC is evaluated as FALSE ... the processor then executes the ADD instruction with FALSE logic – which does NOT increment/increase the value stored at F8:2 ...

(3) whenever SWITCH_B and SWITCH_D are BOTH being pressed and held, the value of F8:1 will be steadily increasing – and the value of F8:2 will "freeze" and will NOT increase ... these results – and the reasons for them - are EXACTLY the same as the reasons given just above ... at the nuts-and-bolts level, this means that at the top part of the program, the bit/box for LAMP_E contains a status of ONE – but at the bottom part of the program, the bit/box for LAMP_E contains a status of ZERO ... some (many? ... most?) beginners are thoroughly confused by this – and ask the question: "But how can LAMP_E be ON and OFF at the same time?" ... the correct answer is that LAMP_E (the device in the field) is NOT on and off at the same time ... but ... the bit/box for LAMP_E is indeed rapidly cycling between a status of ONE and a status of ZERO ... what accounts for most of the confusion is that many people do not distinguish between: (a) the bit/box for LAMP_E on the data table ... and (b) the instructions for LAMP_E located in the ladder logic ... and (c) the actual device LAMP_E located out in the field ... ALL of these are associated with LAMP_E in one way or another – but all of these are definitely NOT the same thing ...

many people who work with PLCs day-in and day-out are doomed to remain at the "beginner level" simply because they fail to realize some of these concepts ... they've been taught (incorrectly) that the OTL or the OTU or the OTE instructions "ARE" the "outputs" ... in short, they leave the bit/boxes out of the picture – and try to find some type of direct relationship between the instructions in the program – and the devices in the field ... this approach CAN work up to a point – but ONLY as long as you stay with beginner-level problems ... there are MANY problems out in the real world which can NOT be solved by looking at the ladder logic this way ...

suggestion: continue to play (I mean "work") with the simple little experiment shown below and see how much you can learn about what's actually happening at each and every stage of the ladder logic scan ... if you come up with any further questions, feel free to post them here ...

going further ... now for the "green on the screen" indications ...

this gets a little more complicated because it depends on which hardware/software system you're using ... tell us which specific one you're up against, and we'll go from there ... here is the basic idea to get you started ...

in general, the RSLogix500 software only updates the screen indications for the bit/box and for the "green on the screen" highlights at the very END of the ladder scan ... on the other hand, the RSLogix5 and the RSLogix5000 software packages generally can update the screen indications for the bit/box and for the "green on the screen" highlights at ANY POINT within the ladder scan ... so with these packages it's quite possible to see a confusing random "flicker" on the screen from time to time ...

so ... sometimes it's possible to have a ONE status stored in the bit/box EVEN THOUGH the screen clearly shows a ZERO status there – and even though the Latch and the Unlatch instructions might appear as UN-highlighted on the screen display ... (again, this is beyond the beginner-level) ...

all of this points out why the ADD "tester" rungs I've demonstrated are so important to nailing down exactly what's going on inside the PLC processor RUNG-BY-RUNG ... these types of techniques can tell you things that the screen indications simply can NOT reveal ... secret handshake: remember that ALL screen indications MUST come through some sort of communications link (usually a cable) ... that means that there is ALWAYS a bottleneck between what's happening inside the PLC processor – and what you are able to see on your computer screen ... (that's why I started out by saying that you can't really trust any of the screen indications) ...

for even more fun (and education) try reversing the order of the Latch and the Unlatch rungs in your program ... specifically, put the Unlatch rung above the Latch rung ... then see what happens when you press and hold both of the pushbuttons ... quick question: does it make any difference in operation when the top-to-bottom rung order is reversed – and if so, could one arrangement be considered more "fail safe" than the other? ...

at this point I think that I've answered your question ... but if not, please post again and include a screen shot of your own program and tell us what's still confusing you ... I'll be glad to try again ...

finally ... if you're not familiar with the "GO LOOK FOR A ONE" type explanations I've used above, then I highly recommend that you watch the eleven YouTube videos that I have posted on the Sample Lessons page of my website ... be sure to watch ALL OF THEM IN NUMBER ORDER to get the best results ... they are meant to be one continuous lesson – but we had to chop them up to make them fit within the ten-minute YouTube restrictions ...

I've been told by several people whose opinion I respect that within the next three to five years, all PLC classes will be taught using the approach that I've detailed in those videos ... instructors who are still trying to teach using the same old incorrect "green-on-the-screen-means-power-flow" explanations and the confusing "switches-and-coils" analogies are now being called to task by their students who have seen my "preview lesson" videos – and are suddenly demanding more-accurate explanations ...

I hope that you find this helpful ...

 

[Mickey]

I'm sure Ron(others) will be along to give a much better(clearer) explanation.

See, I told you so.

 

[Ron Beaufort]

well, my explanation is certainly longer – but I'm not sure whether it's any "better" or "clearer" ...

I'd been typing along on this between cutting the grass and other weekend chores ... once I had it all written, I decided to go ahead and post it even though my distinguished colleagues Mickey and Bernie had already answered the basic question ...

party on ...

 

[bornwild]

Thanks a ton Ron. I am going to bookmark this page

 

[daba]

I think more people get confused over these issues because they make the mistake of thinking the addressed bit is a "latched bit".

It is not in any way a "latched bit" - it is simply a memory location that the PLC can turn on and off, using any of the 3 instructions OTE, OTL, and OTU.

Simplifying the already stated...

OTE will write a 1 or 0 to the bit address according to the current rung logic continuity state.
OTL will write a 1 to the bit address when the rung evaluates as TRUE. It will never write a 0.
OTU will write a 0 to the bit address when the rung evaluates as TRUE. It will never write a 1.

Many programmers use combinations of all 3 instructions on the same bit address for various reasons, and IMHO there is nothing wrong with that usage.

 

[bornwild]

That means that there are two data tables one in the program (rslogix) and one in the processor .Also, what happens when we toggle the bit

 

[Ron Beaufort]

That means that there are two data tables one in the program (rslogix) and one in the processor

no, there is only ONE data table ... it's physically located in the PLC processor ...

possible cause for confusion:

when you are OFFLINE (not communicating with the PLC processor) then what you see on your screen is just a copy of the "real" data table ... you can toggle the bits in this "offline copy" data table if you want to – but what you do there will have NOTHING to do with what's going on inside the "real" data table located inside the processor ...

the ladder logic program just tells the PLC processor what to DO with the data table ... (examples: GO LOOK FOR A ONE ... or GO WRITE A ONE ... etc.) ...

Also, what happens when we toggle the bit

anytime that we "toggle a bit" we reverse/change/swap the status of the bit/box ...

specifically, if the status of the bit/box happens to be a ONE and we "toggle the bit" - then the status of the bit/box will become a ZERO ...

vice versa ...

if the status of the bit/box happens to be a ZERO and we "toggle the bit" - then the status of the bit/box will become a ONE ...

so ... did you watch those videos? ... pay careful attention to the part that defines the differences between "bits" and "instructions" ... based on what you're posting, it looks like that distinction is what's confusing you ...

 

[Ron Beaufort]

I've tried to answer your question above ... but I'll be honest, I have no idea what is prompting you to make the following statement:

That means that there are two data tables one in the program (rslogix) and one in the processor

if you'll tell us what you mean by that, then maybe we can help you understand what's really going on ... there is nothing that has been posted which indicates "that there are two data tables" involved in this ...

somehow you're misunderstanding us - but we're not sure how or why ...

for clarity, let's concentrate on being in an ONLINE state - specifically, we ARE communicating with the PLC processor ...