Start of Scan

[rsdoran]

As ususal I am confused

Not about bios though, that part I understand....something has to tell the cpu what to do and how, then it can do what is needed.

This prescan is kinda spooky and doesnt make sense...why is it needed and why used?

Even if you use the examples offered...on startup why would an output be on? JSR or not...if the rung isnt used and the device is not ON..cant be on if machine is OFF..can it? Outputs are retentive in the prescan?

You are correct, this is not for a beginner...it makes no sense.

Why of all the AB plc courses I have taken NOONE has EVER mentioned a PRESCAN? I or whatever company I have worked for have spent 1000's to learn AB systems...of all those courses NEVER ONCE was a PRE-SCAN mentioned.

I am not a beginner and I am not good at plc programming, I have always thought I had a good understanding of the concept though. This places factors in place that dont make sense and go against most of what I have learned.

I will read this post a hundred times or more AND will look for data at AB to verify it...nothing personal just my way to know.

I have dealt with computers (not programming) since the early 80's. I have taken test after test for A+ etc that is specific to hardware. CPU's, any brand/make/model, usually go thru the same routine on startup...use some form of bios (we all know that means basic input output system?) to start the use a program loaded into some form of prom...or maybe ram/hdd. The memory device is unimportant past the rom that holds bios, after that can be any storage device.

AB has a routine after bios that does a prescan and sets outputs accordingly...then scans?

WHY?

Do any other brands do this?
Again...WHY

 

[kamenges]

I think it has to do with consistency. It would drive me straight to the tavern if my machine did something different every time I went through a program-to-run transition. Its action would be based purely on the luck of the draw of where the processor was in it's scan when the keyswitch was turned.
Now a case could be made for 'Why not turn all non-retentive bits off and let nature takes it's course?'. You have me there. I would expect that action to be just as consistent.

Keith

 

[Allen Nelson]

Re: As ususal I am confused

This prescan is kinda spooky and doesnt make sense...why is it needed and why used?

The why has to do with safety, and the following logic:

     START         STOP        MOTOR

-----| |-----+-----| |----------( )

             |

    MOTOR    |

-----| |-----+

If the PLC did not do a pre-scan, then a motor that was running when the power failed would IMMEDIATELY start when the power came back on. People can get seriously booboo'ed from that.

Since PLCs are/were "relay replacements", and since relay coils would unseal (or "evaluate as false") when there was no power, the pre-scan must function the same way. I don't know whether it's true of all PLC brands, but I'm not sure I'd want to buy a PLC that didn't reset coils on a prescan.

Why of all the AB plc courses I have taken NOONE has EVER mentioned a PRESCAN? I or whatever company I have worked for have spent 1000's to learn AB systems...of all those courses NEVER ONCE was a PRE-SCAN mentioned.

I only had one AB PLC course, taught be a distributer, but they DID mention prescan. It was quick, and in passing, but it was there.

What wasn't mentioned (because they probably didn't know), was that non-executed subroutines are also pre-scanned.

Again, it makes sense to do this, if you think about it.

Especially in the AB PLC-5, there are lots of different ways to execute a subroutine, not just with a JSR. You can set up Main Control Program (MCP) files (up to 16). You can set up STIs, DIIs, and Fault Routines, any of which could use seal-in logic that would be bad. A "clever" programmer could even have code to dynamically change the MCPs (I've never seen it, but that doesn't mean it's not out there).

Let's say that, in Ron's example, instead of deleting the JSR, you just put an "ALWAYS_OFF" bit as a rung condition. How is the PLC supposed to differentiate between this and a "regular" rung condition that just happens to be false on pre-scan.

So the BIOS programmers just took the easy way, and had EVERY rung scanned, without doing a search for how that rung was used in the program.

---

Ron Beaufort:

You've done your usual top-notch/overkill job on pre-scan and coils. How about continuing the lesson and describe how prescan affects timers, counters and one-shots?

With timers, I know that, since they are evaluated as false, a TON will reset the ACC, and clear the DN, EN, and TT bits. What about an RTO? (I don't have a processor handy, otherwise I'd post the answer myself).

Counters use an internal bit to "know" that the rung conditions were true last scan in order to prevent then from counting this scan while the rung stayed true. But if they are evaluated as FALSE for one pre-scan, does that mean that they will increment on the first scan?

I ran into a situation once where one-shots became, essentially no-shots, because of resetting during pre-scan. I don't remember if those were ONS/OSR one-shots, or some kind of logic that had been writen (using integers and "AND"s "OR"s and "NOT"s). But the question is, what happens to oneshots on prescan, when the rung conditions are true on restart? Do they refire?

Inquiring minds want to know.

 

[Peter Nachtwey]

In the beginning ... before prescan.

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

Beryl, you are right in a simplistic way and each PLC initialization routine is different.

Think about this:

The PLC has its own operating system with stacks and memory spaces that must be initialized. The PLC should do a checksum on its own firmware just to make sure it is still intact.

When does the hardware get initialized? The CPU on the PLC itself has hardware timers, I/O, the back plane interface chip, interrupt controllers, and even the serial port.

How does the PLC know what cards are in each slot? Many PLCs do a quick scan of the slots that make sure the cards match the last configuration.

What about program verification? This can be done with a simple checksum.

More sophisticated PLCs support intelligent I/O modules and these need initializing too. When do the parameters get downloaded to a M02AE in a Control Logix.

Watch the PLC lights when you turn one on. Notice that there is usually a delay between turning the PLC on and when the ready light turns on. A lot happens during this time.

 

[msinclair]

Have a look at: 1785-6.5.12 November 1998 (AB Enhanced and Ethernet PLC-5 Programmable Controller User Manual)

The troubleshooting chapter gives some detail about the differences in behavior for various instructions during the pre-scan. I've attached an excerpt of the two relevant pages.

Marc

 

[Ron Beaufort]

... more fun with "prescan" ...

Greetings to all,

well, it looks like I kind of stirred up the “prescan” pot ... I’ll follow up on as many comments and questions as I can ...

Kim Gold said:

It appears as though when using RSEmulate, that the processor does not go through a prescan.

I don’t have time to go into much detail but you’re BASICALLY right ... on the other hand, the emulator software DOES do a prescan ... so in that respect you are in error ... BUT the emulator’s prescan routine is not exactly the same as a real-world processor’s prescan ... that’s why I’m always a little bit suspicious of people who say: “you don’t really need a processor to learn PLC’s ... you can do everything with just the emulator software” ... that’s not always true ... you can do a LOT ... but you can’t do it all ...

Kim Gold also said:

But if you use the logic as follows, when going from Program mode to Run mode O:6/0 does turn off. Very confusing.

Please don’t take offense, Kim ... but this should NOT be confusing ... the logic that you posted is commonly called a “seal-in” rung construction ... it’s also called a “holding” rung... or a “start/stop” rung ... and some people even call it a “latch-in” rung ... I’m personally ok with any of those terms EXCEPT for the “latch-in” ... that’s because we DO HAVE latches in the PLC ... but this ain’t them ... anyway, in my second post I made a point of saying:

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

true story along these lines: once upon a time, I was helping a couple of junior engineers learn how to write some programs ... during one of my demonstrations I set up a “seal-in” rung to control a SAW ... and a set of “latch” and “unlatch” rungs to control a PRESS ... this was all done with safe “lab equipment” by the way ... we pushed both start buttons and got the machines running ... then I simulated a total plant power failure by turning off all of the electrical power to the entire system ... we imagined that during the power failure, some of the operators took a notion to work on the machinery ... guess what happens when the power comes back on ... when those two young engineers saw the PRESS come right back up running they looked at each other and turned two shades of pale ... then they told me:

old Sam back at the plant told us not to bother using seal-in rungs ... the latch construction is so much easier because you don’t have to worry with the branches ... we’ve been programming machines for almost two years using nothing but latches to maintain our cycles ... we had NO idea that there was a difference in the ways these things would affect a start-up routine ... now we’ve got to go back over all of our previous programs and make sure that we haven’t programmed any safety issues in there

now hold on EVERYBODY ... I know that I’m going to get some flack for this ... so let me try to head it off before it gets started ... yes, your machine SHOULD have real-world interlocks ... and your equipment SHOULD be designed to require a manual intervention before it actually starts back up ... and the operators SHOULD use lock-out/tag-out procedures ... and the sun SHOULD always shine in Georgia ...

but my point here is simply this:

there are safety related DIFFERENCES between the seal-in type of rung construction and the latch-in type of rung construction ... we all need to be aware of those differences and understand how they can affect the systems that we work with ...

now if anybody wants to argue with THAT statement, party on ...

 

[Ron Beaufort]

... and yet another "prescan" post ...

rsdoran said:

Even if you use the examples offered...on startup why would an output be on?

first of all ... on startup an output might be ON because we purposefully “latched” its bit ON in our program ... and here’s why I used the Recirculation Pump for my example ... suppose that this particular recirculation pump is necessary to keep our nuclear reactor cool ... now if we were to foolishly use the seal-in approach to program its control, then every time the plant power flickered, we’d need to remember to go over and press the start button to bring the pump back on again ... but the latches are “retentive” ... they “retain” their ON status when the processor is power-cycled ... so a latched-on construction would definitely be a better way to program our recirculation pump ...

and please, folks, don’t jump on my case about how to REALLY control a nuclear power plant ... we all know that I’m just trying to come up with some interesting examples to illustrate these programming concepts ...

a basically true story ... suppose that a customer has programmed his lumber mill using seal-in rungs to help the processor “remember” where the logs are located ... so when a log moves past Limit Switch A, he seals-in bit B3/22 ... this means there is a log in position A ... when the log moves past Limit Switch B, he unseals bit B3/22 ... this means that Position A is empty and ready for the hydraulic ram to feed in another log ... now suppose that the ram has just shoved a log into Position A ... so bit B3/22 is set (1) ... but then the power to the plant flickers ... what happens to B3/22? ... since he’s using a seal-in rung construction, B3/22 gets reset (0) during prescan ... oops! ... the PLC thinks that Position A is empty ... the hydraulic ram shoves in an extra log and does about $4,000 damage to the saw ...

this would have been a good place to have used a latched-in type rung construction ...

back to rsdoran’s question ...

JSR or not...if the rung isnt used and the device is not ON..cant be on if machine is OFF..can it?

I’m not 100% sure that I understand what you’re asking ... but I am 100% sure that you do know your way around PLC’s ... regardless of that, I’m going to take the liberty of answering your question in very basic terms ... even if you personally don’t need this level of detail, then I’m sure that there are some readers out there who will ...

first let’s make sure that we all know that there is a BIG difference between the “device” ... meaning the actual electrical equipment out in the field ... and the “bit” ... which is really just a “box” inside the processor’s memory ... now consider my prescan example ... we ended up with three rungs of interest ... one rung had an OTL (Output Latch) instruction for bit O:6/0 ... another rung had an OTU (Output Unlatch) instruction for bit O:6/0 ... the third rung had an OTE (Output Energize) instruction for bit O:6/0 ... keep in mind that there is ONLY ONE bit (that is, one BOX) with the address O:6/0 ... if you want to see the bit (in other words, the BOX) with the address O:6/0, then go to the output data table and find it ... you’ll see that the bit contains either a one (1) or a zero (0) ... now let’s think about that word “instruction” that I’m using ... the word literally means that we (the programmers) are issuing an INSTRUCTION in order to tell the PLC (that little man inside the processor) what we want him to do for us ...

soapbox time:

here is a very popular MISconception: that little ----( )- doodad thingy at the end of the rung is a “bit” ... friends and neighbors, that is the WRONG way to look at this ... the little ----( )- doodad thingy at the end of the rung is NOT a “bit” ... actually it is an “INSTRUCTION” which tells the processor what we want him to do TO THE BIT ... when the processor scans (or “reads”) the instruction, then the processor jolly well goes and does just EXACTLY what the instruction tells him to do ... now in our example there IS a bit involved ... bit O:6/0 ... but that bit is NOT located at the end of the rung ... instead the actual bit is located back inside the processor’s memory ... it is literally and actually a little BOX that can hold either a one or a zero ...

now let’s look at the logic of the prescan example again ... making sure that we use this perception of program “instructions” which manipulate a “bit/box” back inside the processor’s memory ...

the LATCH rung literally says: “if the conditions are TRUE, then go put a ONE in the bit/box” ... else if the conditions are FALSE, then do NOTHING ...

the UNLATCH rung literally says: “if the conditions are TRUE, then go put a ZERO in the bit/box” ... else if the conditions are FALSE, then do NOTHING ...

the regular old everyday OTE rung literally says: “if the conditions are TRUE, then go put a ONE in the bit/box” ... else if the conditions are FALSE, then go put a ZERO in the bit/box” ...

now in my prescan example, the third (OTE) rung was NOT BEING USED ... specifically, that particular rung was located in an old “junk” subroutine which was NEVER EVER intended to be scanned by the processor ...

now the fact that the RUNG was not being used does NOT mean that the DEVICE (the Recirculation Pump out in the field) was not being used ... and the fact that the RUNG was not being used does NOT mean that the BIT (the little O:6/0 box in the processor’s memory) was not being used ... what the fact that the RUNG was not being used DOES mean is that the processor was NEVER EVER expected to read that little OTE instruction again ...

but we can still use the O:6/0 bit/box ... we can certainly use the Latch instruction to tell the processor to go put a one into that box ... and we can certainly use the Unlatch instruction to tell the processor to go put a zero into that box ... and at the end of the processor’s scan, whatever (either a one or a zero) that happens to be in that O:6/0 bit/box will be sent over the PLC’s backplane to the output module ... if a one gets sent to the output module, then the output module will turn the DEVICE (the recirculation pump) ON ... if a zero gets sent to the output module, then the output module will turn the DEVICE (the recirculation pump) OFF ...

and that’s what happens in the day-to-day execution of our program ... specifically, we use the OTL (Output Latch) rung to turn the Pump ON ... we use the OTU (Output Unlatch) rung to turn the Pump OFF ... and we do NOT use the OTE (Output Energize) rung at all ... it just lurks there ... lying in wait ... looking for a chance to confuse us ...

now suppose that this is a normal workday and that we’ve got the Pump running ... so bit/box O:6/0 must contain a one ... the Latch rung is false ... so it is NOT affecting the bit/box right now ... the Unlatch rung is false ... so it is NOT affecting the bit/box right now ... the old Output Energize rung back in “junk” file 3 is not even a part of the picture ... the processor isn’t even concerned with it at all ... it certainly does NOT affect the bit/box right now ...

now suppose that the processor is powered down ... while the power remains off, what do you suspect is stored in bit/box O:6/0? ... answer: there is still a ONE stored in that bit/box ... the processor’s battery power maintains that bit/box in its current status ... and it’s still there ... and it’s still there ... and it’s still there ... but then all of a sudden the power comes back on ... the processor wakes up and does that confusing “prescan” routine ...

let’s consider what happens to our three rungs during prescan ... the prescan does not affect the Latch rung ... so nothing happens to the status of bit/box O:6/0 yet ... so we’ve still got a one in there ...

next, the prescan does not affect the Unlatch rung ... so nothing happens to the status of bit/box O:6/0 yet ... so we’ve still got a one in there ...

finally, the prescan DOES affect the Output Energize rung ... BINGO! ... just because it’s an OTE instruction, during prescan the processor goes to the bit/box and it puts a zero into it ... it changes the status of bit/box O:6/0 ... EVEN THOUGH the Ladder File 3 has NO JSR to “call” it ... during prescan the processor still finds that “unused” OTE back there in our old “junk” file ... and so NOW all of sudden we’ve got a zero stored in our O:6/0 bit/box ... so now we’re at the end of the scan ... and look what gets sent over the backplane to the output module ... a zero ... and that turns the device (the Pump out in the field) OFF ...

rsdoran said:

I will read this post a hundred times or more AND will look for data at AB to verify it...nothing personal just my way to know.

no personal offense taken ... but may I make a friendly suggestion? ... don’t take my word for any of this ... or AB’s word either for that matter ... instead run your own experiments ... now that the “prescan” genie is out of the bottle, you’ll eventually come up with all sorts of questions to ask and answer ...

 

[Ron Beaufort]

... on to Allen's comments ...

Allen said:

Counters use an internal bit to "know" that the rung conditions were true last scan in order to prevent then from counting this scan while the rung stayed true. But if they are evaluated as FALSE for one pre-scan, does that mean that they will increment on the first scan?

darn it, Allen, now you’ve forced me to rethink what I was SURE was a perfectly valid way of expressing the “prescan” operation ...

NO! ... if the input to a CTU (Count Up) counter is left “true” then the counter will NOT increment when the processor starts scanning again ... that means that my simple “prescan executes ALL rungs as FALSE” rule won’t work here ...

and that means that “prescan” is even more complicated than even I imagined ... there MUST be separate rules for OTE’s and CTU’s and TON’s and RTO’s ... rats ... just when I thought it was safe to go back in the water ...

I’ll do some experiments and get back to you ... but I’ve got a feeling that you’ll have it all posted before I get finished ...

Allen also said:

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

that one I DO know the answer to ... it depends ... are we using the ONS (One Shot) in a PLC-5? ... or its close counterpart, the OSR (One Shot Rising) in an SLC? ... take a look at this PLC-5 program ...

[attachment]

answer to the question: the Motor will NOT come on ... the ONS will NOT refire ... that’s because the PLC-5’s prescan goes to the ONS’s bit and puts a one in its bit/box ... so when the processor does its first regular scan, it finds the switch is true ... then it sees the one in the ONS's bit/box and thinks “ok, the ONS has already been fired” ... so the ONS evaluates as false ... so no true logic reaches the Motor Latch instruction ... and the Motor stays OFF ...

on to the next post ...

 

[Ron Beaufort]

... last in a series ...

now in this case, we’re using an SLC-5/04 processor ... the rung construction is exactly the same ... except that the SLC family doesn’t have an ONS instruction like the PLC-5 family ... so we’re using the closest thing available ... the OSR ...
[attachment]
answer to the question: here the Motor WILL come on ... the OSR WILL refire ... that’s because the SLC-5/04’s prescan does NOT affect the OSR’s bit/box ... so when the processor does its first regular scan, it finds the switch is true ... then it sees the preexisting zero in the OSR’s bit/box and thinks “ok, the OSR has NOT already been fired” ... so the OSR evaluates as true ... so it fires one scan of True logic ... and Latches the Motor’s bit ON ... and the Motor DOES come ON ...

the major point here is that we can have two seemingly identical programs for Allen-Bradley processors ... one for a PLC-5 and another for an SLC-500 ... and yet we can have two different results after a processor shut down ...

 

[msinclair]

Ron,

I agree with your statement that all rungs during prescan are scanned as false (and I think it is the best starting point to understand the prescan). The exceptions come from the special behavior of various instructions during the prescan (see the file I attached to my last post).

With respect to the CTU/CTD - the CU/CD bit is set to prevent a false count.

With respect to ONS - the programmed bit is set to prevent false triggering.

With respect to OSR - the programmed bit is cleared as is the output bit.

Marc

PS: Of course, I can only find documentation for the PLC5 series, so the SLC . . .

 

[Ron Beaufort]

... so that's where I got that line ...

Bless you, Marc,

for making this so readily available ... I thought I was going to have to stay up all night trying to find it ...

quote from the Allen-Bradley book linked in msinclair’s post ...

The prescan function is an intermediate scan between the transition from program to run modes, during which all rungs are scanned as false.

I knew that I had read this somewhere but it’s been years ago, and I’d forgotten where I’d seen it ... since then, I’ve always assumed (gosh, I hate that word) that I understood just exactly how prescan works ... then along came Allen Nelson asking those probing questions about the prescan’s effect on the counter ...

anyway ... based on a few quick experiments that I’ve just run, I’d say that the book’s “all rungs are scanned as false” statement is incorrect ... there’s more to prescan than that ...

I’m reminded of what a very wise man once said:

“If the simplest things don’t confuse you, then you obviously don’t know enough about them.”

 

[PhilipW]

Absolutely gripping!! Thanks guys, this is one of the best threads I have read in ages.

Without wanting to detract for an instant the relevance and importance of this topic, it does on the other hand remind me of why I prefer to use state based logic these days.

By and large I drive most of my machines via a state logic format that does not directly use latches or sealed in style rungs to drive the outputs.

On power up the state engine is always reset to zero, the output is driven OFF or ON as I require, and I never need to worry about pre-scan issues.

It also reminds me of why I try to avoid ONS and OSR's like the plague, cos there is enough to be thinking about when cooking up some logic, without having to remember obscure details of their pre-scan behaviour. I almost always find there are more elegant ways to organise code than using one shots.

All up though I very much appreciate this discussion and I can see why it has cranked more than a few handles.

 

[Terry Woods]

In a PLC (computer), there ain't no such thing as a "Latch" or "Unlatch", in the hardware sense.

Anyone that thinks there is such a thing, doesn't understand the separation between software and hardware.

In Ladder...
Latch (in AB speak) = SET (in computer speak)
Unlatch (in AB speak) = RESET (in computer speak)

SET and RESET are NOT Hardware Functions! They are logical functions within software, and software only.

BTW, Ron, your "all outputs evaluated as if false" test does not apply in TI (Siemens 505).

 

[rsdoran]

Terry you are one of the most eloquent here.

And one of the more knowledgeable.

Where in ALL this discussion did you get the impression that ANYONE did NOT know that AB nomenclature for latch/unlatch was not the same as SET/RESET in KOYO nomenclature?

hmmm...why did I say KOYO nomenclature? 3 or the major plc maker used KOYO to produce their plc's and software...SET and RESET was their term for the AB latch/unlatch and or vice versa...both copied Modicon to some extent. NOTE: 20 years ago companies could not use same hardware or terms in software overall (some were generic).

Personally this prescan stuff is spooky...I have always thought that when a machine was powered off all outputs were false...unless there was a retentive or physical latching factor.

I still believe that in most cases outputs will go false on power loss UNLESS you have established a reason for them to be TRUE on power-up.

I will experiment with this.

 

[BobB]

Jay Anthony answered Beryl about Omron start up process here Omron Start Up
I fail to understand the logic of not using OSRs etc I am afraid. Generally speaking all PLCs go through a similar routine on start up. One can use this to advantage. For example, use the first scan flag to move data into a non-retentive data area, clear a retentive data area, etc etc.
I have used the first scan flag to set a bit and then start a timer. When the timer times out, reset the bit and commence normal program operation. All you have to do is place the N/C form of the start up bit in front of any rung you do not wish to act upon until the timer times out. Particularly useful when waiting for remote networks, machines etc to stabilise when powered up before running your program.
Some areas in PLCs are memory retentive and others are not. The retentive areas can be used to "remember" where the machine was when powered down, for example.
Some PLCs have fixed retentive areas and others, such as Mitsubishi and, if my memory serves me correctly, Siemens where the retenticve area has to be set up. There are plusses and minuses for both ways of doing things.
beerchug