Logix5000 - Unconditional Output behaviour when Faulted

lambles

Member
Join Date
Aug 2003
Location
South Australia
Posts
20
Hi all,
This may or may not be a simple question. Another programmer has used a single OTE instruction on a rung with no other conditions to be permanently ON...internal bit, not real output to a card.
This bit is then monitored via message read from another PLC as a comms OK bit (irrelevant to this question)
I have twice deliberately caused a major fault to see what happens with this output. First occasion it stayed ON despite the ladder rails going from green to grey and obviously not scanning the file. The second time (same major fault) the output turn OFF, again ladder rails grey, not scanning.

Question....what would the expected behaviour be for this output when the processor faults (or even put to Program mode I suppose)

Stay ON? Turn OFF? Random/non-deterministic?

Thanks in advance. I can provide screenshots if necessary.
 
Last edited:
An internal bit should stay on if programmed with an unconditional OTE. That is assuming a couple of things:
1. the rung was actually scanned after prescan before the fault occurred.
2. Nothing else in the logic is writing to it.
3. No external devices are writing to it via a communication channel.

I may have missed something... but that is what I would expect.
 
This bit is then monitored via message read from another PLC as a comms OK bit (irrelevant to this question)

are you SURE that statement is "irrelevant" ???

naturally we can't tell for sure without seeing more of the system ... but ... having the bit being written ON by an unconditional OTE doesn't seem like a meaningful way to insure that the communications link is OK ... in other words, there might be more going on here than you've discovered so far ...

I'm just GUESSING - but I'd bet (pocket change only) that the "other" PLC is sending a message to write the bit OFF - and then using another message to read the bit and see if it comes back ON again when the OTE gets scanned ...

that's not a common way of checking for healthy communications - but (again - I'm just GUESSING) it would seem to make more sense than just checking to see if the bit is ON - ON - ON ...

and one more thing to explore ... besides using an MSG (Message) instruction - the bit might be manipulated by the other processor using the Produced and Consumed tags method ... that wouldn't show up in the logic ...

good luck with your project ...
 
To expand on what Ron wrote...

One way I have implemented a "PLC Heartbeat" status in the past is program a timer that runs based on an internal bit, call it "A". The next rung simply turns bit "A" on.

The other PLC writes bit "A" off every 5 seconds. If the timer times out at 10 seconds, the communication has failed.

I usually set this up on both ends of the communication link. This will work properly if the PLC is in program mode, powered off, or faulted since it requires an action that only happens if the PLC is running.
 
When a Logix PLC exits run mode - be that because it encounters a major fault, or you switch it to remote program mode, or you switch the key switch to program mode, or any other reason - all tags stay exactly as they are. The only exception is some physical outputs, which can be configured to go to a certain state on fault.

Before the PLC goes back to run mode, it will perform a "pre-scan", in which any tag that is written to using an OTE in the code* will be set to zero.

*provided that the routine containing that OTE is accessible, i.e. the routine is called by a JSR at some point

So, if you have an unconditional OTE in the code, your tag will be off for just the briefest of instants between the prescan resetting the bit, and the first "normal" scan of the PLC turning it back on. With no other factors at play, this will obviously not work for a "comms failure" detection setup.

The most common way of doing comms failure checks is a heartbeat - as others have mentioned above, you can use a bit that toggles on and off at a set frequency, or an integer that keeps incrementing (and eventually rolls over back to zero). In your other PLC, you monitor the on/off or incrementing value, and if it stops for too long, you flag a comms alarm.

If both PLC's are Logix platform PLC's, then there's an easier way. Create a UDT where the data type of the first element is CONNECTION_STATUS. This contains two BOOL's - RunMode and ConnectionFaulted. If you now set up produced/consumed tags between your two PLC's using an instance of this UDT, the "RunMode" and "ConnectionFaulted" tags will be continuously updated even if both PLC's are not in run mode. Not only can you immediately diagnose a comms fault, but you can tell the difference between the PLC faulting, and a cable being unplugged from your ethernet switch.
 
*provided that the routine containing that OTE is accessible, i.e. the routine is called by a JSR at some point
Unscheduled programs as well as routines that are not called are covered by the prescan. All OTEs will be turned off no matter where they are.
 
Unscheduled programs as well as routines that are not called are covered by the prescan. All OTEs will be turned off no matter where they are.

That is true of SLC/MicroLogix/PLC5 processors, but not of CompactLogix or ControlLogix processors.

I haven't tested it personally, but Ron Beaufort gives quite a thorough rundown of this topic in this post, and I've not caught him being wrong yet ;)
 
That is true of SLC/MicroLogix/PLC5 processors, but not of CompactLogix or ControlLogix processors.

I haven't tested it personally, but Ron Beaufort gives quite a thorough rundown of this topic in this post, and I've not caught him being wrong yet ;)

I stand corrected. That's what I get for assuming the CLX would work like the older processors. I just tested it on a ver 24 L72. Prescan doesn't scan a program that is inhibited, or a routine that does not have an associated JSR.
 
Just to "officially" verify the "unscheduled programs" side of things and allay any doubts that Ron, or anyone may have had, or still has on the matter...

456860 - What is Controller Prescan?
Access Level: TechConnect

A "small" excerpt from the above...

Copyright: Rockwell Automation Technote Article - 456860 said:
...Prescan does not occur for a program when:

the program becomes scheduled while the controller is running
the program is unscheduled when the controller enters Run mode...

But then, if we are to trust, implicitly, Rockwell's advice, what are we to make of this very "pertinent to the topic" technote article?...

43379 - ControlLogix: Behavior of prescan operation on non retentive outputs
Access Level: TechConnect

...of which I feel I must also take an excerpt from...

Copyright: Rockwell Automation Technote Article - 43379 said:
...Like all Allen Bradley PLC's have always been from day one, the ControlLogix processor performs a "prescan" operation...where every rung in every scheduled program file is scanned like it is false...

Well, if we take "all" to mean "all", and "always" to mean "always"; we know, to the contrary, that the Logix 500 controllers perform a prescan on all subroutines, regardless of whether a program subroutine was scheduled (JSR), or not. So the above statement would not be technically correct. I feel though, that the above is just another case of someone running away with themselves by adding in a couple of good old "all" and "always" absolutes, without carefully thinking about it - yes, absolutely.

Anyhoot,

I've also previously posted the following info on the "best practice" options for implementing a "Heartbeat" communications monitor between similar or dissimilar RA controller platforms...

Heart Beat

While I've replied to others in the past outlining just the Produce/Consume heartbeat method to use between two Logix 5000 controllers, as described by ASF above, I feel it important here to provide info on the heartbeat method for, or between, both platforms. This is because, while our friend lambles' opening post is titled: "Logix5000 - Unconditional Output behaviour when Faulted"; they have not stated whether the other controller is of the Logix 500 or Logix 5000 platform.

This may suggest it is a Logix 500 controller...

lambles said:
...This bit is then monitored via message read from another PLC as a comms OK bit...

...but it could also be a Logix 5000 controller.

If it is a Logix 500 controller then Produce/Consume could not be in play here and it would have to be messaging that is writing to this boolean tag, if that is the case. This would also mean there is tag mapping in place. If it is a Logix 500 controller then you can check if there are any tags mapped to Logix 500 style addressing by going to the drop down menu in RSLogix 5000/Logix Designer...

Logic>Map PLC/SLC Messages...

Here you can view the list of mapped tags, if any exist. You may even see your boolean tag in the list which is assigned to the OTE on the unconditional rung. But again, that is all based on the other controller being a Logix 500 controller.

I would agree that there is likely more at play here than just the unconditional rung. Out of curiosity, I wonder what is the tagname for the boolean tag assigned to the OTE instruction on this rung and also, do you have access to the other controller's project file?

Regards,
George
 
Last edited:
describing the PRESCAN operation gives quite a bit of trouble to just about everyone ...

consider the following part of the Technote Article quote given in post #9 ...

every rung in every scheduled program file is scanned like it is false

well - that's not exactly correct ...

one specific example would be a rung containing a CTU (Count Up) instruction ...

a FALSE execution of the rung would cause the counter's CU (Count Up) bit to be written to a value of ZERO ... that doesn't happen ...

instead, the PRESCAN operation writes a value of ONE to the CU bit ...

according to my experiments, the following CTU description taken from the Logix5000 Controllers General Instructions manual is accurate ...
.

prescan_ctu.jpg
 
Last edited:
We need to break it down some more...

Ron,

I think we can agree that whoever wrote that article worded it poorly or else they just do not understand the intricacies of the prescan the way that we do.

But, from my understanding of it, for Logix 5000 processors, the prescan does scan, within scheduled programs, each rung, or at least instruction, as if it is false. The fact that the CTU instruction, and other instructions that are handled differently by the prescan, are not executed upon during prescan as though the rung is false, is not because the rung is not scanned as false, but because they are specifically told to "do something else" during prescan and ignore the false rung condition, or true condition. As we know, the CTU instruction, in particular, is instructed to set the .CU (Count Up) bit true during prescan to prevent invalid increments during the first program scan. For this reason the CTU instruction is given special treatment during prescan.

But, just because it is special, it does not mean it has exclusive ownership of the entire rung and its condition during prescan. I do not think we can refer to the scanning of an entire rung as true or false with regard to one instruction during prescan.

When the prescan scans a rung with a CTU instruction, there will, in most cases, be other instructions on the same rung. Those other instructions, according to their prescan definitions, will require the rung to be scanned as though it is false in order to accomplish their prescan tasks. This necessity to be scanned as if false will often be contrary to the fact that their actual rung-condition-in is true at the instance that prescan is performed. So the prescan must intentionally, and deliberately, scan the rung, or execute the instruction, as if false.

I keep using "or" there. That's because I have another way to look at this situation, but I might leave that until later.

Example:

There could, for instance, be an XIC instruction before the CTU instruction which is incrementing it. There could also be an OTE instruction after the CTU instruction which set true when the XIC instruction is true.

Prescan of this rung:

When the prescan reaches this rung, let's say the XIC instruction is already set false. The prescan does not operate upon the XIC instruction. So the XIC instruction's rung-condition-out is false. If it were true, it would remain as such as the prescan has no effect on the XIC instruction.

The prescan then moves on to the CTU instruction. Its rung-condition-in is now also false from the XIC instruction. If it were true from the XIC instruction then the prescan would normally be told to ignore any true rung conditions and execute the next instruction as if its rung-condition-in is false. But, in our example, the rung-condition-in is already false from the XIC instruction. However, the prescan identifies that it is a CTU instruction and so ignores the false rung-condition-in and sets the .CU bit to true. If the rung-condition-in to the CTU instruction happened to be true from the XIC instruction, the prescan would still actually ignore it. The setting of the .CU bit is a special case during prescan and will always be set by the prescan, and not by the rung-condition-in status. The prescan then, by definition, sets the CTU instruction rung-condition-out to false.

The prescan then moves on to the OTE instruction. Its rung-condition-in is false from the CTU instruction. But, again, the prescan does not care either way. Even if the preceding instruction rung-condition-out happened to be true, the prescan will still, as defined, execute the OTE instruction as if has a false rung-condition-in and set its address bit false.

To further point this out - we can delete the CTU instruction, and leave just the XIC instruction and OTE instruction. If the XIC instruction is true at the instance that the prescan scans this rung, then it's rung-condition-out will be true. This means that the OTE instruction rung-condition-in will also be true. But, the prescan, by definition, must execute the OTE instruction as if it is false, and set its address bit false.

Now for the "...other way to look at this..." that I mentioned earlier...

Having explained the above in that manner, and while it may make a lot of sense (does it?), in trying to break this down some more; how I actually prefer to look at it is this way...

The prescan is not executed at the rung level, but more at the instruction level. In other words, the prescan has a predefined set of rules for each instruction. It will scan the rungs, yes, but this is just to find those instructions. Once it finds an instruction it checks its predefined rule for that instruction and executes that rule upon it. It ignores the rung conditions around it. Even when the rung conditions suit the task the prescan wants to perform. So, technically, the rungs, themselves, are neither scanned as true, or false.

So, from that perspective, it would not be technically true for the author to state that...

"every rung in every scheduled program file is scanned like it is false...

...more, they should state...

"...every instruction in every scheduled program is executed using its predefined prescan rule...

I am not saying that I am definitively right on all that, but that is my understanding of how it works.

Regards,
George
 
Thanks for all the replies,

Disregarding Prescan and Heartbeat discussion, my take out from this is that the unconditional OTE will (should) stay High when the PLC processor has a major fault.
 
Thanks for all the replies,

Disregarding Prescan and Heartbeat discussion, my take out from this is that the unconditional OTE will (should) stay High when the PLC processor has a major fault.

It will only go low if something writes it low, and if the host controller has major faulted, then it can only be being written low externally.......

.... unless there's a Fault Routine programmed that turns it off ???
 

Similar Topics

I'm a Siemens person, and this is one of my first AB programs. The customer wants everything programmed in Ladder. I have a lot of data (3...
Replies
14
Views
161
Good day everyone. if you have a logic for 3 pumps (lead/lag/off), would you please email it to me? I really appreciate it!
Replies
7
Views
157
Maybe this is just not possible, or maybe I am doing something wrong. Background; I have a data array of over 1500 products. For sorting I...
Replies
6
Views
727
Hello everyone, I'm currently using RS Logix5000 software for machine programming with this Rockwell PLC using the Structured Text method. The...
Replies
19
Views
1,951
I am sure this has been asked/done but couldn't find anything. I need to count how many times a motor has started in the last 24 hours at any...
Replies
13
Views
1,320
Back
Top Bottom