Duplicate Destructive bits used EVERYWHERE!

I was not aware that AB PLC's would do that, what is needed for the processer to "decide" that a bit should be turned off on the first scan?

Because that's how the manufacturer decided its products will operate; it is a safe approach for starting up a PLC controlled system:

"...On power-up, the controller prescans logic to initialize instructions. The
controller resets all state-based instructions, such as outputs (OTE) and timers
(TON)...."
 
Disadvantages:
Takes up twice the space on the HMI.

I usually stack the buttons on top of each other and give them visibility animations. There's not really an instance when the machine will be "ON" and need to be turned on again, so displaying the BTTN doesn't serve much purpose.
 
I was not aware that AB PLC's would do that, what is needed for the processer to "decide" that a bit should be turned off on the first scan?

Nifty part of AB controllers. OTEs will always be in a "0" state on first scan, so any XIC holding on an output with the output address will power up in an off state. Latched outputs, on the other hand, will remain in a state of "1" if the machine loses power while they are latched on iirc. Depending on the application, knowing the difference is rather useful!
 
Because that's how the manufacturer decided its products will operate; it is a safe approach for starting up a PLC controlled system:

"...On power-up, the controller prescans logic to initialize instructions. The
controller resets all state-based instructions, such as outputs (OTE) and timers
(TON)...."

If and Only If the routine is scanned during prescan. So it doesn't apply to routines not called.

And in any event, if I want something to be in a certain state on powerup, I will always put an direct command to set it properly in my own initialize routine.
 
The line between genius and bat-***** insane is a thin one, and I'm not sure which side of the line this technique sits on. One half of me goes "oh my god, that's not how you do things! Why would you abuse ladder logic like that!", and the other half of me goes "actually, that's quite a clever way of doing it, even if it IS unconventional".

The original question was about what we thought about using duplicate destructive ONS bits. It seems that most people don't like seeing duplicate ONS bits. I don't like them because they generate warnings. I wouldn't change it, but if I was writing from scratch, I'd do it different.

Base on what the code does and the way it its coded, what seems to be the function required of the code, and thus what conditions limit how it is coded?

1) The HMI toggles a Pushbutton Bit, and the PLC resets this bit and toggles a Toggle Bit.
2) Because a second ONS was used, I assume that A one shot bit is needed elsewhere in the code when the pushbutton is pressed. If the one shot isn't needed, the duplicate ONS wouldn't be needed.
3) Since OTL and OTU were used, I assume that the toggle state must be maintained during power cycles/PLC restarts, and thus logic latching the toggle bit using an OTE isn't appropriate.
4) It should be short and simple.


Toggle1.png


This code would get rid of the duplicate destructive bit warnings, but could confuse the Bubbas with the PB needing to be both ON and OFF to prevent the Toggle bit from latching.
 
Last edited:
I usually stack the buttons on top of each other and give them visibility animations. There's not really an instance when the machine will be "ON" and need to be turned on again, so displaying the BTTN doesn't serve much purpose.

If you stack two buttons on top of each other then what's the point of having two buttons? Why not just one maintained button with 2 states? I've found the same thing on another HMI in our plant. I was assuming that the original intention of doing it was to have two buttons
 
If you stack two buttons on top of each other then what's the point of having two buttons? Why not just one maintained button with 2 states? I've found the same thing on another HMI in our plant. I was assuming that the original intention of doing it was to have two buttons

I should have specified, "in instances where space is an issue".

Even in instances where latched/maintained buttons would make more sense, I usually use momentary buttons with that logic layout just out of force of habit. :rolleyes:
 
I believe Logix controllers do not execute logic during pre-scan.

Logix controllers do execute logic during the first-scan.

Depends on how you define "execute logic".

Ron Beaufort give a pretty good explanation of it in this post. The long and short of it is, on a Logix-class PLC (not SLC, or MicroLogix), every bit associated with an OTE tag will be set to zero during the prescan, but only if the OTE is in a routine that has some way of theoretically being called (i.e. a JSR in a routine that also has some way of being called).

The pre-scan also resets any non-retentive timers, and a few other things. So you can call that "executing logic" or something else, but whichever way you go, I can promise you if you hang around long enough someone will disagree with your semantics ;)
 
Depends on how you define "execute logic".

The original quote (..."Prescan differs from first scan in that the controller does not execute logic during prescan. The controller executes logic during first scan...") is from Page 36 of Publication 1756-RM094C-EN-P - June 2007 -Logix5000 Controllers Design Considerations

I believe there is a difference between 'pre-scan' and 'first-scan'.

During pre-scan, input values are not current and outputs are not written.

After the power-up pre-scan the first-scan will follow and execute the implemented logic.

According to the UM, the power-up Pre-scan does not relate to any implemented logic regarding all state-based (non-retentive?) instructions (OTEs, TONs, ONSRs etc.); they are all reset no matter if the routines they are placed within are programatically 'called-up' or not.

Ron's example refers to OTLs and OTUs which do not fall within the above category- they are retentive by design and if they are placed within routines programmed to be scanned will retain their states.
 
Last edited:
dmargineau said:
The power-up Pre-scan does not relate to any implemented logic regarding all state-based (non-retentive?) instructions (OTEs, TONs, ONSRs etc.); they are all reset no matter if the routines they are placed within are programatically 'called-up' or not.

This is not quite correct. In a Logix-class PLC (again, not SLC/Micrologix), if you have an OTE on a rung anywhere, the pre-scan will set the associated BOOL tag to zero - but only if that rung is in a routine that has some way of being called.

If the OTE is in a routine that is called by an unconditional JSR, the bit will be turned off during prescan.

If the OTE is in a routine that is called by an JSR that may or may not be executed depending on the state of preceding logic, the bit will be turned off during prescan.

If the OTE is in a routine that is called by an JSR which cannot possibly be executed because it is preceded by an AFI or similar always-false logic, the bit will be turned off during prescan.

But, if the OTE is in a routine to which no JSR or other path exists, the bit will not be acted upon in any way during prescan.

The same, of course, applies if there is no path to the routine containing the JSR to your routine with the OTE. By which I mean, if you have an OTE in SBR_03, and SBR_03 is called by an unconditional JSR in SBR_02, but there is no JSR or other means of executing SBR_02, then likewise, your OTE will not be set to zero during prescan.
 
Other than that, you're right in that there is definitely a difference between pre-scan and first scan. And you're right about not "executing logic" in the sense of evaluating all the instructions during pre-scan. I'm just cautious about how I word it because there is still an evaluation of the logic to the extent that it's required to determine what is and is not reset to what values. Definitely not "executing logic" in the traditional sense, but still more than just a blanket "reset and reinitialize" with no concern for any user program.

But in any case, it looks like Rockwell agrees with your terminology, no matter what I think ;)
 
But in any case, it looks like Rockwell agrees with your terminology, no matter what I think ;)

...:D...but not the other way around...:unsure:...(myself agreeing with Rockwell that is!)

Anyway, if an OTE or TON is placed within a routine which is not being called-up within a Program the pre-scan does not need to worry about their 'last states' since they will be 'reset' as soon as taken out of the scan.

So, the statement that all OTEs and TONs will be reset during a power-up prescan is true no matter if said instructions' routines are called-up within a Program or not...Hmmm...Isn't it?...:unsure:
 
So, the statement that all OTEs and TONs will be reset during a power-up prescan is true no matter if said instructions' routines are called-up within a Program or not...Hmmm...Isn't it?...:unsure:

No. It's a common misconception that OTE's only hold "on" while they're actively being scanned. It's not the case. Try not to think of an OTE as a relay coil - as much as that's how all of us probably learned, that's not actually the case.

With a relay coil, if the power is cut to it because you turn the panel off (shut the PLC down) or simply pick it up and put it on the shelf (put it in an unused routine), then yes, a physical relay coil will turn off.

But an OTE is not a relay coil. Nor is it a bit. An OTE is an instruction, with two functions, that acts on a single BOOL.

The two functions:
1. If the OTE is executed with a TRUE rung-in condition: set the associated BOOL to 1
2. If the OTE is executed with a FALSE rung-in condition: set the associated BOOL to 0
(obviously, prescan is a special case, but I think we've covered that).
The BOOL itself is not linked to the OTE. Well, I mean, it is, because you've created the OTE instruction and told it to act on that particular BOOL tag. But the BOOL just sits there being either one or zero, indefinitely, unless the OTE (or some other instruction) acts on it to make it something else.

Try it out - if you have an OTE addressing a coil that is turned on, cut-and-paste it (online) into a routine that's not called. Once it's in that routine, you can manipulate the preceding logic however you want - even delete the lot and replace it with just an AFI and your OTE - and the OTE will stay "green" because the BOOL tag is still set to 1. The only way the OTE can set it back to zero, is if the OTE is scanned with a false rung-in condition - and the OTE is not being scanned any more.

I've seen the same thing with indirect addressing. I had an array of UDT's controlling a bank of 8 valves, which fed into 8 silos. I wrote the following line of code (more or less):
Code:
|   Seq_Start          InfeedValve[SelectedSilo].Open
|------| |--------------------------(  )----------------|
...the idea being that whatever silo was selected when the sequence started, the corresponding infeed valve would open. The problem was that sometimes they would change the silo partway through the process. Let's say you start with Silo #1. So My logic effectively becomes OTE InfeedValve[1].Open. So InfeedValve[1].Open - the BOOL tag - is set to 1. But now, if they change to Silo 2, my logic becomes OTE InfeedValve[2].Open. So InfeedValve[2].Open - again, the BOOL tag - is set to 1. But what happened to BOOL tag InfeedValve[1].Open? Nothing. All of a sudden, it has no OTE addressing it in any capacity. So, it'll just sit there being a 1 until some logic comes along to change it. And now I have two valves open.

The "relay coil" analogy is great for getting your head around it to start with, but when you get into fine detail, it can trip you up :)
 
Do you think we've derailed the OP's thread enough yet, or should we continue on down the rabbit hole a little further? :D
 

Similar Topics

Hello, I have a project to upgrade a compactlogix CPU. The CPU that is currently in use is v15, and the new CPU is going to be v33. I have...
Replies
3
Views
1,881
Hello all, Stupid newbie question... Just making sure, a bit constantly flipping, and it is reference by 2 OTE in different ladders, that is...
Replies
9
Views
1,674
I've spent three days trying to figure out why my assembly cell is blowing past a step in the logic. While adding blocking bits I noticed the...
Replies
7
Views
3,412
Hi all, Is anything wrong with the hypothetical logic attached? We make a machines that can have 1 of 2 air valve stacks. I would like the...
Replies
11
Views
3,506
Hi all, Got a question regarding the duplicate destructive bit warnings generated when I use InOut tags on my add-on instructions. Most of my...
Replies
0
Views
2,734
Back
Top Bottom