ControlLogix Rung True but No Output


Solving when a ControlLogix Rung is True but No Output

It’s frustrating when a ControlLogix Rung True but you have No Output. In this section we’ll go over the causes for this, and how to correct them. It’s important that the processor is just doing what it’s told. We just need to find out why it’s keeping the output off. There are several things that can cause this. It’s important to realize that the opposite could be true as well. You might have an output that is ON even though the logic appears to be shutting it off.

Keep in mind, that I am just explaining the causes of this. I’m not recommending that you change any logic, toggle bits, do any forcing, or change the processor mode unless you know what you are doing, and there is no danger.

Program Mode (or Offline)

Obviously, you need to be online to see the updates, but if the processor is in program mode, or “RemProg”, it is not scanning logic. Additionally, if you check the properties of your output module under the I/O tree, you will find the configuration. It’s very likely that all real world outputs will shut off if the processor is in program mode. In fact it’s dangerous to hold last state or turn outputs on while in program mode. This is because no logic is executing to shut the output back off. In some cases, there is a use for leaving outputs on, or holding the last state. Most of the time though, they will be OFF.

Logic Interference

It’s possible that you could have used the same bit twice as the output in the program. In this case, other logic is interfering. Only one “destructive” instruction should usually be writing to the output. “Destructive” means that an instruction has the ability to change the value of a tag. You will find this through a cross reference to determine if this is the case. It happens a lot! The logic interfering with your output could be anywhere in the program. I’ll show an example below. The top rung writes the value of 1 to C, however, a fraction of a microsecond later, it shuts C back off.

Right click the tag “C”, and go to cross-reference. You will find that there are two destructive instructions in your logic.

Subroutine Not Executing

It’s possible that the routine in which you are viewing the logic is not executing. Remember, for any subroutine to execute, we have to have a JSR in the program somewhere to cause it to execute. Additionally, the JSR must be true. You will usually find these in the Main Routine.

Now let’s look at the Mainroutine

Here, you can see that I have a JSR, but it isn’t finalized. Once I finalize the JSR statement, it will execute, and the processor will solve the logic.

One Shots (ControlLogix Rung True but No Output)

For One-Shots, this is probably normal operation. Let’s look at a rung with a one shot in it.

The purpose of the one shot is to allow the output “C” to come on for one scan. Likely it triggers a seal or latch somewhere else in your logic. To make C go true again, A has to drop out then make. However, you never will see C go true. Its only on for one scan only. You can read up on one-shots here.

MCR Zones

MCR is a “Master Control Reset”. With these zones there are two MCR instructions. One at the top of the zone to mark the beginning, and one at the bottom to mark the end. If the first MCR instruction for the zone is false, then all logic in the zone is evaluated as false.

In order to get C to energize, B must go true.

Jump and Labels (ControlLogix Rung True but No Output)

It makes for messy logic, but sometimes programs will have jumps with labels. This causes the processor to skip over some logic. If the JMP instruction before our rung, and the label is after it, then the processor is not solving logic. Let’s look at an example.

As you can see, we are jumping over the rung, and even though the XIC instruction is true, our output is still off. For the processor to start solving logic, we must shut off B.

Online Edits Not Finalized

If you are changing logic, don’t forget that you need to accept, and test your edits before your new logic becomes active. Look at your vertical power rails. By default, the power rails should be green. If your power rail skips over any rungs, and they are marked with an i or I, then you haven’t yet accepted and tested your edits. Here is an example of an edit that is not being tested.

Be sure of your edits, then you can follow through with your online edit.

If you come up with any other reasons this might happen, please comment below!

For more information, visit the ControlLogix Cagegory Page!

— Ricky Bryce

Leave a comment

Your email address will not be published. Required fields are marked *