Whew! Well I’m glad you set me straight now before years of agony resulted from my misconception.
I appreciate your humor - but it is quite common to have “seasoned” technicians arrive in my classes with the following attitude:
“OK ... I’ve got 10 years of PLC experience behind me ... this five-day class starts at the basic beginner level ... that means I’ll have at least two or three days of slack before the “green” guys catch up ... I’ll just kick back and take it easy until Thursday or so ... then MAYBE I’ll start to pick up a few things ... I’d better take a book to read” ...
then first thing Monday morning we start getting into how the screen can lie to us - and many other things along those lines ... there have been SEVERAL cases where the “experienced” guy has literally slammed his book down against the desk and then paced around the room - and finally demanded, “Do you mean to tell me that I’ve been misunderstanding this stuff for 10 years?” ... now I certainly don’t want to start a fight - and he’s scaring the children ... so as calmly as I can, I say something like, “No, sir, I’m not TELLING you anything. I’m just programming a few simple rungs - with a couple of simple switches - and a couple of simple lamp bulbs ... all I’m asking you to do is use your experience to tell me whether the lamps are going to be ON, or OFF, or FLICKERING.” ... after the guy settles down and starts to really listen to what I’m teaching him, then he usually becomes a model student ... you’ll hear things like, “so THAT’S why we couldn’t get machine #2 to run” ... and “NOW I see why I couldn’t use a force in that situation” ... and so on and on ... read through the student comments on my website and you’ll find case after case where “experienced” technicians have had their eyes opened by learning the “basic” concepts that we’re talking about here ...
so it’s OK to laugh - but to a frustrated technician who’s trying to get a machine back in operation, these are NOT humorous topics ...
It seems that asking you to expand could sound ridiculous, however, that is what I must do. Further down the rabbit hole ...
actually there’s quite a bit that I’ve been forced to leave out ... and I know that SOUNDS like what I’m teaching is very complicated - but it’s not really ... all of this material normally takes less than ten minutes of explanation in a classroom with a couple of hands-on demonstrations ... but we’ll do the best that we can over the forum ...
What if anything are the implications of addressing an OTE as an Output(O:3/0), in this case would the output have power as long as the OTL and OTU were green (1 in O:3/0)?
your question is more complicated to answer than I have time to type - but my distinguished colleague robertmee has done an excellent job in his post ... the only thing “un-good” about his explanation is that he doesn’t draw an obvious distinction between the “BIT” (which is a box in the processor’s data table) and the output “DEVICE” (which is located in the field) ... that is an extremely common way of looking at things ... and it works well enough in MOST cases ... the “problem” surfaces when we’re dealing with a machine which is NOT functioning correctly ... in other words, when we’re actually TROUBLESHOOTING a system, the distinction between a “bit” and a “device” in the field may become “NOT trivial” matters ...
side trip: suppose that the plant’s technicians have been working for quite awhile on a machine that they are unable to repair ... the boss finally calls in reinforcements - an expensive outside contractor ... (a “guru” so to speak) ... the guy goes online with the processor and, sure enough, in ten minutes he’s pinpointed the problem ... now the question: what secret knowledge does the guru possess that allows him to succeed where the merely talented and experienced plant technicians failed? ... in many cases, the answer is that he fully understands the difference between the “bits” and the “devices” in the field ... specifically, they are NOT one and the same thing ...
Also, can you speak further of these LIES?
certainly ... here’s a quick demonstration along the lines of those that I use in my classes ...
first, notice that in the LEFT panel the switch I:2/0 is turned ON ... but in the RIGHT panel the switch is turned OFF ... notice that there are FOUR actual output addresses being used - O:6/0 through O:6/3 ... and here is a chart showing what ACTUALLY happens in the FIELD ... try this yourself with a spare system and you should be able to duplicate the results ... (notice that we’re using an SLC-500 system here ... you can get different results with a PLC-5 or a ControlLogix system) ...
Left Panel
------------
I:2/0 = ON
O:6/0 = ON
O:6/1 = ON
O:6/2 = OFF
O:6/3 = ON
Right Panel
------------
I:2/0 = OFF
O:6/0 = OFF
O:6/1 = ON
O:6/2 = OFF
O:6/3 = ON
IMPORTANT: remember that the chart above shows the ACTUAL conditions of the devices IN THE FIELD ... specifically, these are NOT necessarily the status of the bits in the processor’s DATA TABLE ... and THAT’S what we’re trying to demonstrate ...
compare the two panels side by side and notice that the screen is clearly LYING to us from time to time ... for one specific example: the actual ON/OFF conditions of the output devices IN THE FIELD for outputs 1, 2, and 3 NEVER CHANGE regardless of the green highlights shown on the controlling rungs ... now THAT’S a clear-cut case of LYING no matter how you slice it ... and we could go on - but I think that I’ve made my point ...
specifically, if ALL that you consider is the “green highlighting” on the screen while you’re troubleshooting, then there are going to be some cases where your conclusions will be WRONG ... how embarrassing could it be for a “guru” to show up - and have him nail a problem in ten minutes that you’d been working on for hours? ...
How can we monitor these latches to be confident that we are witnessing their current state?
a better way to phrase that question would be: “How can we monitor these BITS to be confident that we are witnessing their current state?”
this is one of the most reliable methods ...
notice that I’ve used “floating point” variables - and NOT integers ... the integers will quickly overflow and could cause a processor fault ... the floating point variables won’t do that ...
here the value of F8:1 is increasing like crazy - because the bit/box for O:6/0 contains a ONE each time the XIC on rung 0001 is scanned ... therefore the ADD gets executed with TRUE logic - and increases the value of F8:1 on each scan ... the fact that the XIC is NOT highlighted with green is totally meaningless ... the “add test” tells the truth ... the screen lies ...
on the other hand, the value of F8:2 is NOT increasing at all - because the bit/box for O:6/0 contains a ZERO each time the XIC on rung 0003 is scanned ... therefore the ADD gets executed with FALSE logic on each scan - and does NOT increase the value of F8:2 ...
the “trick” is that the OTE in rung 0000 always writes a ONE into the bit/box BEFORE the XIC on rung 0001 looks in the bit/box for a ONE ...
then the OTU on rung 0002 always writes a ZERO into the bit/box BEFORE the XIC on rung 0003 looks in the bit/box for a ONE ...
so the bit/box is rapidly flip/flopping between a state of ONE and a state of ZERO during each and every scan ...
the actual output device for bit/box O:6/0 - located in the field - remains OFF ... that’s because only the “last” value stored in the bit/box is sent to the output module at the end of the ladder logic ...
PS Edit ... if you haven't seen the Email Quizzes that I have on my website, you might find them interesting ... they cover subjects like this in quite a bit of detail ... look in the "Sample Lessons" area ...