Insignificant mistake

I'm not being critical, but the illustration on the chapter 6 (PLC timing) shows the input active during the first input cycle, but the text says that it is not active. For clarity, I'd put the start of the input after the input scan time is completed. I know that some PLC's work as shown (snapshotting the inputs, then scanning them), but not all of them do so, especially the older PLC's, which functioned similar to the old PC's language interpreters.

http://www.plcs.net/chapters/respdetails6.htm

Nice site, by the way.

I disagree. The input is ON during the first scan, but notice that it doesn't turn ON until AFTER the PLC has finished scanning the inputs (the IN segment of the scan). Here's the diagram for easier reference...



what older PLCs don't use this method?...

beerchug

-Eric

I meant the illustration at the very bottom of the page. On that one, the input goes high before the scan time is completed. In fact, it is nearly on when the scan time starts. I'd include the diagram if I knew how.

Sorry for the ambiguity.

I think that Phil is trying to show the absolute worst case where the input in question is the very first one updated, or at least on the first input module to be updated. In the case shown, the actual input changes state a nanosecond after the PLC reads the input module that it's wired to.

Regardless of the method that any particular PLC uses to get data from the input modules to the input table, the example is trying to show a physical input changing state just after the last chance to have that state represented in the current ladder logic evaluation.

ancient PLCs

Eric,

The Sy/Max family, from Square D, had models that did not use "snapshots". These PLCs read and updated I/O as each line was solved. The immediate writing of outputs provided a very fast response (you could program the same logic and output multiple times to effectively shorten the scan time). Immediate reading of inputs caused problems if an input changed state (i.e. on-off-on) during a scan.

Thanks for the info Jim... I never got to 'play' with any Square D PLCs...

Now that we're talking about the same diagram. This one:

I think Steve has provided a good explanation of what Phil was trying to show about the input update delay...

beerchug