Start of Scan

[Allen Nelson]

Oneshots

In reading the file that MSinclair posted, I read the following:

ONS - The programmed bit address of the instruction is set to inhibit false triggering when the first run-mode scan begins

And with that, I remembered how one-shots became "no-shots".

We had a Panelview with some buttons to set the mode ("Off", "Hand", and "Auto"). I think that each state wrote a value (0,1 or 2), thus setting/resetting a "Hand" and "Auto" bit.

We also had the following code:

    HAND                DO_SOMETHING

-----| |------[ONS}--------( )

Well, while the PLC was in program mode, someone went to the Panelview and changed the mode from AUTO to HAND. The Panelview still had communication, so it set the new bit pattern. When the PLC went back to RUN mode, the prescan SET the ONS bit (even though it was RESET when the PLC was last in RUN).

Since the HAND bit was SET, and the ONS bit was SET, the DO_SOMETHING never fired. So even through the PLC thought that the system was in HAND (and it was), the housekeeping that DO_SOMETHING did never took place, and, well, things weren't as they should have been.

So, one question I have for those who can experiment is, could the same thing happen with a physical, DI-type selector switch? There's alot that happens just as a PLC is getting powered up, and it takes a moment for the PLC to read the backplane to determine status of the inputs (or even for the DI module to detect the voltage and report it to the backplane)

MSinclair's attachment also contained the following

CTU / CTD - The CU/CD bit is set to prevent a false count when the first run-mode scan begins

Again, this has the same properties as the one-shot; that a bit is unaturally set under the assumption that the data table didn't change while the PLC wasn't looking.

 

[Ron Beaufort]

... more prescan questions answered ...

Greetings to all,

Allen asked:

... could the same thing happen with a physical, DI-type selector switch?

if I understand exactly what you’re asking, the answer is “it depends on whether you’re using a PLC-5 ... or if you’re using an SLC-5/04”

I think that my posts #23 and #24 should answer your question ... consider that these posts use the same simple construction that you’ve just posted ... and they also use real-world digital inputs ...

reviewing the test ... if the status of the input (in my example, the Limit Switch ... in your example, the HAND switch) goes from OFF to ON while the processor is powered down ... then when the processor is later powered back up:

if we’re using the ONS in a PLC-5 ... then the output bit (in my example, the Motor ... in your example, the DO_SOMETHING bit) will NOT come ON ...

BUT ...

if we’re using the OSR in an SLC-5/04 ... then the output bit (in my example, the Motor ... in your example, the DO_SOMETHING bit) WILL come ON ...

specifically, the same basic rung construction will give DIFFERENT results depending upon the processor type ...

in other words, if the application that you described in your most recent post had been using an OSR in an SLC-5/04 processor, then you would NOT have had the same problem ... specifically, the DO_SOMETHING bit WOULD have correctly fired on restart ... but since you were using the PLC-5 platform, then the prescan moved a one into the ONS status bit ... and the DO_SOMETHING bit did nothing when the processor started back up ...

this is genuinely weird “now-I’ll-have-to-sleep-with-the-lights-on” type stuff ... I for one am glad that we’re discussing it here in the comfort and safety of the forum rather than over a piece of wrecked machinery ...

and so Allen, I think that I have just answered your most recent question ...

yesterday Allen asked:

But the question is, what happens to oneshots on prescan, when the rung conditions are true on restart? Do they refire?

I realized this morning that I sort of left this previous question only partly answered ...

IF the rung condition (example, the Limit Switch) was ALREADY TRUE when the processor was shut down ... then NO, the one-shot will NOT “refire” when the processor comes back up again ... and this statement will be correct for both the ONS in the PLC-5 ... and for the OSR in the SLC-5/04 ...

venturing a guess as to why you asked this specific question ... earlier I had said that “during prescan the processor executes all of the rungs as false” ... perhaps you interpreted that to mean that it also “scanned the INPUT conditions in front of the one-shot as false” ... in that case, it would be natural to assume that the resulting false condition leading into the one-shot would indeed “reset” the one-shot’s status ... and therefore give us a “refire” of the one-shot the first time that the processor made a regular scan of the rung ...

but actually, the statement “during prescan the processor executes all of the rungs as false” ... should be interpreted to mean that all of the OUTPUTS on the rungs are executed as false ... specifically, during prescan the processor does NOT even look at the conditional side of the rung ... it only looks at the output statements ... examples: the OTE’s, the OTL’s, the MOV’s, the ADD’s, etc. ... specifically, it skips right over the XIC’s, the XIO’s, etc. ...

with all of that in mind ... the answer to your question is NO, the one-shots will NOT refire ... just as long as the input conditions leading up to the one-shots were ALREADY TRUE when the processor was shut down ...

I think that I know what you meant ... but actually your question is slightly ambiguous ... specifically, when you said:

... when the rung conditions are true on restart ...

you failed to mention the condition of the rung conditions at SHUT DOWN time ... and that DOES make a difference to the answer ...

but in any event, I think that I have answered that question also ...

and now ... after sleeping on it ... I’ve decided to follow msinclair’s suggestion ... from now on (well, at least until further notice) I’m going back to my previous way of describing the prescan’s operation ... specifically ...

one of the things that the processor does during this “prescan” is to go through the ENTIRE program once and execute ALL OF THE RUNGS as FALSE ...

but unfortunately this one simple statement does NOT explain such things as why the CTU (Count Up) doesn’t “recount” a TRUE input condition ... specifically, an input condition which had already been TRUE (and therefore already been properly counted once) BEFORE the processor was shut down ... as Allen pointed out yesterday, if a CTU is really and truly “scanned false” then its CU status bit is going to be reset to a zero condition ... and this would definitely lead to another INCORRECT count when the processor started its regular scan and found the counter’s input condition still true ...

and so as Marc Sinclair suggested ... I’m now going to describe the prescan routine along these lines ...

one of the things that the processor does during this “prescan” is to go through the ENTIRE program once and execute ALL OF THE RUNGS as FALSE ...

and it also SETS all counter CU and CD bits to a one condition to prevent false counts ... and ...

and for the PLC-5 ... it also SETS all ONS (One Shot) status bits to a one condition to prevent firing ... just in case a previously false input condition happens to become true while the processor is shut down ... note: it does NOT set the OSR status bits in the SLC-500 platform ...

it also RESETS all TON (Timer On Delay) timers ... specifically, the ACCUMULATOR is reset to zero ... the EN, DN, and TT status bits are all reset to zero ... note: it does NOT reset RTO (Retentive On Delay) timers ...

and so on down through the list of “special cases” for the prescan routine ...

finally ... for those of you who seem to be enjoying this little trip to the dark side of the PLC’s nature ... welcome to my world ...

and for those of you who wish that this weird stuff would all just sort of “go away” ... well, sometimes I too wish that it would ... but it won’t ...