Start of Scan

Where does a PLC start up? I thought on powerup the PLC did a self test and some overhead then moved on to reading the inputs. When talking to one of my peers he thought that it powered up and read the inputs. Who is correct. Does it differ from one brand to another?


Thanks

dear sir bery

i have nice answ to you

I can't say that I know all PLC's... I know several and there are differences between them - slight, but none the less, there are differences.

In general, the processor "Start-Up" routine certainly does begin with a housecleaning. This is true for all PLC's and standard computers. This is the "Boot-Up" procedure.

After verifying the integrity of the processor, then certain "working areas", and the communication channels (as in, Everybody Ready?") the processor begins to "run".

Inputs are read and recorded.
The program is executed.
Then Update the Outputs.
A little "self-checking" and then back to reading Inputs.

Meanwhile, Interrupts, Cyclic and Analog Routines grab their time as required.

"Interrupts" are always monitored and serviced immediately.

The "Cyclic" and "Analog" routines grab control of the processor according to their specified schedules and for their specified durations.

There is a hierarchy of order for the various processes.

Whatever time is left is given back to the program.

When power is first applied the PLC goes through a self test. If it does not pass this, it will fault before it gets to the program scan.
If the powerup is successful it will continue as shown above.

I'm sure I have seen this somewhere before, but I could not locate any documentation describing initial powerup of the processor.

You are absolutely right, Kim.

In terms of a PLC or a typical PC, the processor MUST verify its own environment before it attempts to begin processing. That is typically a BIOS function.

I don't know of any processors with a built-in BIOS... doesn't mean there ain't any, I just don't know of any.

This does NOT mean that ALL processors follow this scheme... after all, a BIOS is typically a separate, physical and logical entity.

Someone can easily throw together a "STAMP" which does NOT include any housekeeping at all! If the designer chooses NOT to include any housekeeping, then NO housekeeping is included! It's that simple!

I'm pretty damned sure that neither an Intel, nor a Motorola, nor an AMD processor checks its own environment (that is, the rhelm of its control) unless there is something to tell it to do so.

If the processor can easily detect that something major is wrong, then why should it not do so? PLC's do so.

After all, we are talking about possibly killing someone! Certainly a large portion of the PLC controlled environments in the world are potential man-killers or, at least, maimers.

... but don't forget "prescan" ...

Greetings to all,

first the bad news: this topic is just a little bit beyond a “beginner” stage discussion ...
now the good news: there is nothing here that a beginner won’t be able to understand ...

well, everything that’s been posted so far in this thread is right on target ... but no one has mentioned “prescan” yet ... so I’ll do my best ... now I’m not sure about other brands of PLC’s but here’s the basic idea behind the Allen-Bradley’s “startup” routine ... at least as far as “prescan” is concerned ...

before we get too deep into this, let me say that the “scan” chart provided by elhagan IS accurate ... but that chart is showing how the processor “starts” each NORMAL scan ... important point: the chart is only accurate AFTER the processor has finished its “prescan” routine ... THEN the chart is correct ... what the chart does NOT show is what happens when the processor VERY FIRST starts up ... just BEFORE the first “normal” scan ... and this is what I think Beryl is specifically interested in ... in other words, suppose that we “power down” the processor ... and then we “power it back up” ... what happens first? ... what happens next? ... then what happens after that? ...

now some people will tell you “just don’t worry about it” ... or “it all happens so fast that we can’t understand it” ... but then again, sometimes we absolutely MUST worry about it ... because sometimes things act really WEIRD when the system is first turned on ... the specific “real world” example given below comes from a frustrated customer’s “please help me” call ... he had been fighting this particular problem all day without success ... true, his program was a lot more complicated than the one I’m posting ... I’ve simplified it down to a few rungs so that we can concentrate on the major points ... but to this customer’s mind, what he was seeing the processor do - just “didn’t make sense at all” ... stay tuned ...

disclaimer: there are some minor (but important) differences between “prescan” for the PLC-5 family and for the SLC-500 family ... this discussion uses an SLC-5/04 processor as an example ... but in this specific discussion, either processor family would give the same results ...

Beryl asked:

Where does a PLC start up? I thought on powerup the PLC did a self test and some overhead then moved on to reading the inputs.

Click to expand...

when the processor first “starts up” it does all of the “housekeeping” things that the previous responders have mentioned ... but next it does NOT start scanning the program rungs ... and it also does NOT examine the status of the inputs ... at least not yet anyways ... why not? ... because before it actually starts “scanning” the program and trying to control things, it’s going to do a “prescan” of the program ... and yes, this is done mostly for safety reasons ...

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 ...

first notice that I said “ONE of the things” ... there is more to this subject than I’ll have time to cover in one or two posts ... next, notice that I said “ALL of the rungs” ... specifically, that includes rungs that are located in Ladder Files that are no longer “used” in the program ... specifically, EVEN in cases where the JSR (Jump to Subroutine) which “calls” the Ladder File has been disabled or even totally removed ... so that’s the tricky part ... usually when we disable or remove the JSR, then we normally expect that the affected Ladder File will no longer be scanned ... specifically, we expect that it will no longer have ANY effect on the operation of our program ... and normally it doesn’t ... but then again, there’s that little-known “prescan” thing which occasionally gives some quite confusing results ... stay tuned ...

for example, suppose that we PREVIOUSLY had a simple rung to control our Recirculation Pump ...

[attachment]

(just ignore the branch for awhile ... we’ll talk about that later) ... here in Ladder File 3, we were using a simple maintained contact switch to turn the pump off or on ... and we used to have a JSR rung located back in Ladder File 2 which “called” this Ladder File 3 ... life was simple and everything worked fine ... then one day the boss decided that he didn’t like the switch any more ... now he wants us to control the pump with momentary contact push buttons ... this should be a very simple task for people of our caliber ...

now we could have simply modified our existing rung to incorporate the new buttons ... we COULD have ... and we SHOULD have ... but we didn’t ... instead, we simply deleted the JSR rung from Ladder File 2 ... and we left this old “unused” rung stored away in Ladder File 3 ... we even changed the file’s name to “junk” so that future programmers wouldn’t be confused ... now keep in mind, we’ve totally deleted the JSR rung ... so there is NO WAY that this old rung will EVER be scanned again ... right? ... so it will have NO EFFECT on the operation of our program ... right? ... wrong! ... there’s that sneaky little “prescan” thing that I’m building up to ... stay tuned ...

on to the next post ...

... "prescan" continued ...

here we see the new rungs that the boss requested ... we’ve decided to use Latch and Unlatch instructions to control the pump ... specifically, we will NOT use the “seal-in” approach to keep our pump running once the start button has been released ... and that’s because ... if the pump is running ... and then the processor gets “shut down” for any reason ... then it’s important that our Recirculation Pump comes right back up in the “running” mode whenever the processor is finally turned back on again ... a seal-in rung construction won’t satisfy this requirement ... but a “latch/unlatch” construction will ... well, usually it will ... stay tuned ...

[attachment]

now there’s nothing wrong with the basic ideas behind this programming approach ... this SHOULD work fine ... and it does (up to a point) ... we push the start button and the pump comes on and it stays on when the start button is released ... then we push the stop button and the pump goes off and it stays off when the stop button is released ... we test it repeatedly ... the boss tests it too ... and he smiles ... BUT ...

what happens when we leave the pump running ... and then we power down the processor ... and then we power the processor back up again? ...... we’d EXPECT that the pump should come right back up running again ... that’s the whole idea behind using the Latch and Unlatch instructions anyway ... they’re supposed to be “retentive” ... meaning that they “retain” their on or off status even when the processor is powered down and then is subsequently powered back up ...

but it just doesn’t work that way ... when we leave the pump running and then cycle the power off and back on again, the pump does NOT come back on ... bummer ... the boss is very disappointed ... and we’re very confused ... this thing SHOULD work ... so why doesn’t it? ...

and now we’re finally ready to talk about “prescan” ... remember that I said earlier that one of the things that the processor does during “prescan” is to go through the ENTIRE program and EXECUTE ALL OF THE RUNGS AS FALSE ... and THAT’S what is causing the problem here ... remember that old “unused” rung back in Ladder File 3? ... the one that we just KNEW would NEVER EVER get executed again? ... well, the truth is that the processor DOES still execute that old “unused” rung ... but ONLY once AT START UP ... and that happens EVEN THOUGH we have totally removed the JSR which previously “called” Ladder File 3 ... MAJOR POINT: the rung in that old “junk” file still gets executed once each and every time that the processor first starts up again ... just once ... during “prescan” ...

now think about this ... just WHAT does the OTE (Output Energize) instruction at the end of that rung actually do when the processor executes it with false logic? ... answer: it does exactly what ALL of the OTE instructions ALWAYS do whenever they’re executed with false logic ... specifically, it goes over to its “addressed” bit and it writes a 0 (zero) in there ... and in this case the addressed bit is the bit for our Recirculation Pump ... oops! ... writing a 0 into that bit has EXACTLY the same effect as using an “unlatch” to turn the pump off ... incidentally, I put that “bypass” branch around the input in the “unused” rung just to prove a point ... it doesn’t make any difference what condition the rung’s inputs are actually in during the “prescan” ... because during “prescan” the processor will ALWAYS execute the rung as if its inputs were false ... specifically, even an “unconditional” rung with an OTE at the end would have exactly the same effect ...

so a simple solution to our problem: delete the old unused rung in Ladder File 3 ... problem solved ... now the latch and unlatch rungs control the pump just the way we always wanted them to ... the boss is happy again ...

and another item ... you don’t have to actually “power down” the processor to force it to do a “prescan” ... it will do the same “prescan” routine even if you simply go from the Program mode into the Run mode ...

finally ... after the “prescan” routine has been completed, then the processor sends the off or on status of the bits from the output image table over to the output modules ... then it does some housekeeping ... then it updates the input image table ... then it solves the rungs in the ladders ... then it sends the output image table over to the output modules ... and then it goes around again ... and again ... and again ... pretty much just like the other responders said it does ... and just like elhagan’s chart shows ...

Great response Ron, Ive learnt something new yet again!

very clever man ron

thanx for your time ron you are very clever man

First Scan

With GE Fanuc & Mitsubishi there is a system bit only on during first scan you can use for setup & lockout at startup, Siemens has a subroutine that only runs once at startup.

Thanks

Ron,
Thanks. You understood my question and confirmed what I thought was what happened plus a little I didn't know.

Anyone know if Omron does the same/similar thing?

Ron:

Thank you very very much for that clearly explained answer. It was a great education for me and many others I'm sure.

Greg H

Ron:

I just tried the logic on RSEmulate 500 Version 5.00.05.05 and thought you might find this interesting. It appears as though when using RSEmulate, that the processor does not go through a prescan.

Kim

FYI,
Here is the same question from an OMRON perspective.
Click Here

Tested RSEmulate a little further.
If you use the program Ron has shown, the bit in file 3 does not turn off during prescan. But if you use the logic as follows, when going from Program mode to Run mode O:6/0 does turn off.
Very confusing.