well, I don't want to start a fight ... but ...
Greetings Gerry,
back in post #5 I made the following statement:
... with a PLC-5 all of the inputs (“I:___” addresses) are read from the field ONCE at the very start of the scan ... the values in those bits won’t change (unless you program something really weird) all the way through the processor’s execution of the ladder program ... and then finally the outputs (“O:___” addresses) are written to the field ONCE at the very end of the scan ...
and then you came along in post #15 and contradicted me when you said:
Only if it's Local I/O. Remote I/O is asynchronous.
now no offense intended, but honestly I’m still convinced that I’m right ... and that you’re wrong ... and here are some of the reasons why I feel that way ... first of all, in the official book:
PLC-5 Enhanced and Ethernet Controllers - User Manual
on page 6-3 [Adobe Reader page 70 of 325] we find the following note:
... channel 1B continually scans the ... racks in its scan list and places the data in the remote I/O buffer in the processor. The processor updates its own buffer and the I/O image table. During housekeeping, the two buffers are updated by exchanging the input and output data with each other.
and then on page 6-11 [Adobe Reader page 78 of 325] we find this chart ...
[attachment]
please consider this note which I’ve highlighted:
The remote I/O scan is independent of and asynchronous to the program scan.
and this is the part, Gerry, that I think is confusing you ... the point is that yes, the remote I/O IS being scanned asynchronously to the processor’s scan of the ladder logic program ... BUT ... (and here’s the tricky part) during that period while the processor is scanning the ladder logic program, the remote I/O is only moved into and out of the “remote I/O BUFFER” ... it is NOT moved into and out of the “input IMAGE TABLE” and the “output IMAGE TABLE” as you apparently believe ... specifically, this “remote I/O buffer” is completely separate from the processor’s “image tables” which are constantly being accessed while the ladder logic program is being executed ...
continuing on ...
we also see this note which I’ve highlighted:
During housekeeping: Data exchange between the I/O image table, the processor-resident rack, and the remote I/O buffer occurs.
notice specifically the statement “during housekeeping” ... that “housekeeping” piece of the puzzle is a brief ONCE PER SCAN window ...
and then the book seems to confuse the issue with this note – circled in red:
Remember that the I/O scanner is constantly updating the remote I/O buffer asynchronously to the program scan.
at first glance this statement certainly seems to bear out what you were saying, Gerry ... and quite possibly this is also confusing you ... but take another look at the phrase that I’ve underlined in red ... it’s only the “remote I/O BUFFER” that’s being updated constantly ... NOT the processor’s “input image table” and the “output image table” ... and that’s where my statement and your statement are completely at odds ...
to nail this all down, I think that you’re confusing the processor’s “image tables” (input and output) with the completely separate “remote I/O buffer” ... the “image tables” contain the data which we see when we monitor the PLC’s “inputs” and “outputs” ... and the data on these two tables is the data that the processor “looks at” and “writes to” as it executes the ladder logic program ...
so here in a nutshell is what goes on in a PLC-5 system which uses both local and remote I/O ... that loop on the left side of the figure shows that the remote I/O is indeed being continuously updated asynchronously to the processor’s scan of the ladder logic ... that much I certainly don’t dispute ... BUT ... during the processor’s trip through the ladder logic program, the data in the “remote I/O buffer” remains completely isolated from the processor’s ladder logic ... finally, during that brief ONCE PER SCAN window labeled “housekeeping” on the separate loop at the right of the figure, the two loops “communicate” and exchange their remote I/O data with each other ...
and that’s why I’m still firmly convinced that my earlier statement is completely correct ... specifically, with a PLC-5 system, the values in the bits with “I:___” addresses will not change all the way through the processor’s execution of the ladder program ... and my statement holds true whether the “I:___” addresses are associated with LOCAL inputs – or with REMOTE inputs ...
and by the same token, the outputs are also handled only once per scan ... regardless of whether they are LOCAL outputs or REMOTE outputs ...
now for completeness, let me mention this: it IS possible to change the rule I posted by programming in something like an IIN (Immediate Input) instruction ... or by “hijacking” the status of an input bit by writing to it with something like an OTE ... and there are other ways ... but that’s getting into the “really weird” programming that I mentioned in my original statement ... and it certainly does not pertain to any difference between (as you suggested) “local I/O” and “remote I/O” ...
now ... if you’re anything like I am and don’t trust everything that you read in the books, here is a little experiment to prove that what I’m saying is correct ... suppose that I program the spare PLC-5/30 on my desk with the “double-coil program from hell” ... specifically, I put in sixteen rungs ... and each rung controls “O:032/0” with an OTE ... then I condition the first rung with an XIC for “B3/0” ... but I condition the second rung with an XIO for “B3/0” ... and then I continue that alternating XIC/XIO pattern all the way down through all sixteen rungs ... of course, address “O:032/0” is located on a remote I/O unit ... and so now the stage is set ...
next I place the processor in the run mode and watch the LED on the remote I/O unit ... whenever the “last rung” in the program is TRUE, then the LED for “O:032/0” lights solid on ... and whenever the “last rung” in the program is FALSE, then the LED for “O:032/0” goes completely off ...
now the point, Gerry, is this ... IF (I repeat IF) you happened to be correct, then the LED would be expected to “flicker” every once in awhile ... because ... since the status of “O:032/0” on the “output image table” is continuously being flip/flopped by the alternating “on/off” rungs, then it would be only a matter of time before the asynchronous “remote I/O” update (that you’re suggesting) would affect the field output ... and the LED would occasionally flicker briefly between on and off ...
but that doesn’t happen ... specifically, the LED is either always completely on ... or always completely off ... (depending on the status of “B3/0”) ... but specifically, the LED never flickers ...
in short, this “REMOTE” I/O bit functions in PRECISELY the same way that a “LOCAL” I/O bit functions ... the “update” difference between “local I/O” and “remote I/O” that you suggested simply does NOT exist ...
and that means that I was right ... and you were wrong ... the experiment that I’ve just detailed should prove this point to your satisfaction if you want to try it yourself ...
and incidentally ... if you’ve got your heart set on seeing the LED flicker, just program an IOT (Immediate Output) rung about halfway through the program ... you can use this instruction to force an “immediate” update DURING the ladder logic scan ... but to make the LED flicker, you’ll have to insert the IOT right after a rung which drives “O:032/0” to the opposite status produced by the “last rung” of the program ...
now ... as for the other processor platforms which you brought into the discussion ...
The 1774 (PLC-1) was asynch (all remote I/O)
PLC-2 introduced synchronous I/O, but only for local. remote I/O is asynch.
PLC-3 is asynch (all remote I/O)
PLC-5/250 is asynch ( all remote)
ControlLogix is asynch (even for local I/O).
I’m perfectly willing to defer to your opinion on these ... personally I’ve led a very sheltered life and I’ve never worked on the 1774 (PLC-1) ... or the PLC-2 ... or the PLC-3 ... or the PLC-5/250 ... so if you say that these platforms use asynchronous I/O, then I have no reason to disbelieve you ...
but then again, since I didn’t include any of these other platforms in my original statement about the PLC-5 scan cycle, I feel no need to discuss them further ...
for the benefit of our less-experienced readers I will say this: despite its “PLC-5” model number, the PLC-5/250 that Gerry mentioned is NOT one of the “regular” PLC-5 processors that I included in my original statement ... this is a “special” type of system called a “pyramid integrator” ... if you’ll refer to
this link you’ll see that the PLC-5/250 doesn’t even support “I:___” or “O:___” addresses at all ... (note the “N/A” entries on the chart) ... and since my original statement specifically mentioned the PLC-5’s “I:___” and “O:___” addresses, then I clearly had no intention of dragging the special PLC-5/250 into this particular conversation ...
so in closing, Gerry, please take another look at the evidence ... and run the experiment I mentioned if you need to ... and then let me know if I’ve changed your mind about this ... or perhaps I’m missing something? ... if so, please point it out ... personally, I’m always ready to learn something new ... and I don’t mind admitting an error whenever I’ve been proved wrong ...
anyway ... in my humble opinion, my original statement was completely correct ... and your contradiction was wrong ...
the defense rests, your honor ...