Duplicate Destructive bits used EVERYWHERE!

I'm teaching non-stop this week (twelve-hour days) so I haven't had time to follow this thread at all ... but here's a tip that might help you guys along the way ...

Rockwell actually does a pretty good (I'm tempted to say "excellent") job in RSLogix5000 of describing how each instruction operates during PRESCAN ...

for a couple of quick examples: just put your cursor on an OTE – OTU – OTL – CTU – ONS – etc. and hit the F1 key for the online help feature ... scroll down to the "Execution" section and see how the instruction is intended to work during the PRESCAN operation ...

party on ...
.

prescan_ote.PNG
 
Last edited:
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.

There is no misconception within this choir...Been there done that...If I only had a dime for each time I forgot the Main JSR...:D

Again:

If a functional system goes down when running, upon power-up the prescan will reset all relevant (functional) state dependent instructions such as OTEs, TONs, ONSRs, etc.; this will provide a 'safe' state for the operation commencement....

The code which does not get scanned does not matter...It didn't do anything prior to power-down hence will not do anything after the power-up...

Someone here was not aware of this fact...Now he is and probably understands why...

Do you think we've derailed the OP's thread enough yet...
Yes, we have derailed this thread..Mea Culpa...:oops:...:D
 
There is no misconception within this choir...Been there done that...If I only had a dime for each time I forgot the Main JSR...:D

Again:

If a functional system goes down when running, upon power-up the prescan will reset all relevant (functional) state dependent instructions such as OTEs, TONs, ONSRs, etc.; this will provide a 'safe' state for the operation commencement....

The code which does not get scanned does not matter...It didn't do anything prior to power-down hence will not do anything after the power-up...

Someone here was not aware of this fact...Now he is and probably understands why...


Yes, we have derailed this thread..Mea Culpa...:oops:...:D

Okay, gotcha (I think) - you're saying that the OTE's in uncalled routines will not reset their associated BOOL tags, but that's irrelevant because if the routine isn't called, that logic isn't doing anything anyways. Have I read you right?

Although I have once seen a motor that would just never stop running - the only way they could get it to stop was the e/stop. Turns out that someone had accidentally deleted the OTE to that output online while the motor was running, so the output just stayed on permanently and whenever the e/stop circuit was healthy, the motor ran. The same thing could in theory happen if you delete the JSR to your subroutine, or copy the rung with the OTE into an uncalled subroutine. Then you have an unsafe state that prescan won't fix.

But then, at that point, you can probably safely blame the programmer rather than the PLC and it's prescan philosophy. A careless programmer could just as easily create a similar "unsafe" situation by using OTL and OTU instructions to control the motor starter instead of an OTE. As someone's signature here says, "that's the beauty of PLC's. They don't have emotions, they just run code."
 
Okay, gotcha (I think) - you're saying that the OTE's in uncalled routines will not reset their associated BOOL tags, but that's irrelevant because if the routine isn't called, that logic isn't doing anything anyways. Have I read you right?

Yep... 4 X 4...:D
 
This is a retentive flip flop. I use this almost exact code structure a lot.

I like to keep the HMI as dumb as possible (especially with FTViewME as it is quite possible the devil).

This flip flop is very dependable and is battle proven.
 
Yep... 4 X 4...:D

No. Logic called, say, in a setup, or recipe subroutine by an operator is scanned once. Outputs are set. They are NOT reset on power up.

If you want things in a default state on power up, do it yourself. Don't rely on the processor to fix it for you.

That said, I never use OTE's for persistent states anyway, that is what latches are for.
 
If you want things in a default state on power up, do it yourself. Don't rely on the processor to fix it for you.

I agree since I always use the S:FS extensively throughout my applications.

That being said, I am still comforted by the fact that the Logix CPUs reset all 'to be scanned continuously' OTEs, TONs, ONSRs, etc. upon a power-up prescan...:D
 
No. Logic called, say, in a setup, or recipe subroutine by an operator is scanned once. Outputs are set. They are NOT reset on power up.

If you want things in a default state on power up, do it yourself. Don't rely on the processor to fix it for you.

That said, I never use OTE's for persistent states anyway, that is what latches are for.

That highlighted statement is incorrect....

Let's put this discussion to bed. I have written, and tested, aa application to test whether OTE bits are, or not reset on power-up.

The application consists of 4 identical tasks -

Continuous Task
Periodic Task
Event Task triggered by an EVENT Instruction (which incidentally does not exist)
Event Task triggered by a Consumed Tag data-change

In each task I have one program with the following Routines -

MainRoutine (assigned as the Main Routine)
FaultRoutine (assigned as the Program Fault Routine
CalledByJSR_True (a subroutine whose calling JSR is unconditional)
CalledByJSR_False (a subroutine whose calling JSR follows an AFI)
No_JSR m(a subroutine that has no JSR or FOR to call it) *EDIT
CalledByFOR (a subroutine called by a FOR Instruction)

Each Routine has an unconditional OTE which would, if executed, turn ON an appropriately named TestBit in a UDT I created.

Now I'm only testing what the Pre-Scan does, so I don't want any "OTE" code executed. To achieve this, I deliberately fault the processor on Rung 0 of the MainTask, MainProgram, MainRoutine by MOVing a negative number into a timer's preset, then executing a TON instruction.

This will immediately Fault the processor, the FaultRoutine will be executed, which has a TND as the first rung.

To test what the pre-scan does to all my OTE's, I first put the processor into Program mode, then set all the "TestBits" on in my UDT tags. (Picture 1).

I then put the processor into Run mode, which you can see from picture 2 faults the processor. Now no code has executed, except for my MOV and the bad Timer, we can see from picture 2 which of my OTE's have been turned OFF by the Pre-Scan.

Lo and behold, everything has been reset, except for the OTE in a routine that has no calling mechanism.

Picture_1.jpg Picture_2.jpg
 
I had forgotten to include "Inhibited" Programs, and "Unscheduled" Programs...

My subsequent tests on those categories reveal that the Pre-Scan does not reset the OTE's at all...

So there's a warning here for when you are working on live equipment...

I feel I ought to emphasize thefollowing statements...

If you un-inhibit a program, it will not have been pre-scanned, so its outputs may be left on from before it was inhibited.


If you re-schedule a program, it will not have been pre-scanned, so its outputs may be left on from before it was unscheduled.

*EDIT* Also - If you add a JSR to a subroutine that you had previously removed, any pre-scans on that routine will not reset OTE's,
so its outputs may be left on from before the JSR was deleted.

ALL of those operations can be done while the processor is operating in RUN mode !!


Picture3.jpg Picture4.jpg
 
Last edited:
I'm glad that I opened up a discussion here, that's you guys for all your thoughts on this

The definitive conclusion is that the "pre-scan" will be effective (i.e. turning off OTE bits, resetting TONs etc.), on any logic that the controller could possibly execute with the current configuration.

My previous (loud) post highlights how that pre-scan can be circumnavigated, and is intended to be a safety warning....
 
Thanks daba. An extremely thorough and informative experiment. Think I'll save this post for the next time this discussion comes up :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,880
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