ControlLogix: Dead Rung Block?

This is a vendor-supplied application. VFD start is being held up by a very simple rung that begins with two EQU blocks in parallel (an OR condition), followed by an XIC then an OTE. The OTE needs to be ON to start the VFD. Going online, I see the XIC is ON (GREEN), both EQUs are testing for zero, and all values in the block are zero, so both should be true, yet the output is not energized. I can toggle the output, the VFD starts, and the toggled output does not get overridden. There is also a Timer in parallel to the OTE at the end of this rung that never runs.

Looks like two dead (or non-executing) EQU blocks? Ever seen that? Tried uploading the application - thinking maybe what was in memory differed (somehow) from the app I was viewing, but this rung is there. Also checked to be sure the "Source B", which is a Literal ZERO, was not an "O" (if that's even possible). Finally, checked to be sure that the OTE wasn't somehow getting overwritten by another instruction (even through an alias), but there's none of that.

It just looks like two EQU blocks that are not executing...

It sounds like either the routine is not being called by a JSR or the rung is in a JMP/LBL, preventing it from being scanned

Did you do a cross reference of OTE?
May be there's an OTU

There are a dozen ways to disable code.

In addition to what dmroeder said, the rung could be be between a pair of MCR blocks; there is a TND above the rungs that's enabled; in a Routine in an Event task that is not active, or any type of Task not scheduled; in a Program that has been Inhibited.

It could also be that the values that you are monitoring are "true" for 90% of the code scan, but are false when that particular rung is scanned. Never completely rely on "green" contacts as a debugging tool. A green power rail is even less reliable; it only means the PLC is running, not that the ladder is being scanned.

Good luck.

I can toggle the output, the VFD starts, and the toggled output does not get overridden.

Click to expand...

This indicates that the routine itself is not being called, or the section of code is being skipped over in some other way. You're correct that if the rung was solving to False, you could not toggle the output and have it not be set False the next scan.

Look for a JSR that calls the routine (I cross-reference the Routine in the Controller Organizer) and look for any JMP/LBL instructions in the routine.

dmroeder said:

It sounds like either the routine is not being called by a JSR or the rung is in a JMP/LBL, preventing it from being scanned

Click to expand...

Forgot to mention that. No. The "Main" routine reads three I/O points (PSLs) to energize three OTEs, then on the next rung calls a VALVE routine, then the next rung it calls this routine. There are no conditions on either of these JSR rungs. Just the JSR.

tarik1978 said:

Did you do a cross reference of OTE?
May be there's an OTU

Click to expand...

Sure did! Three XIC's, one XIO, and this lone OTE that won't energize.

Ken Roach:

JSR clearly calls the routine from Main. No problem there. And there aren't any JMPs or LBLs, either.

Aardwizz:

Ohhhhh .... there's a "TND" on rung #2 all by itself! That'll short-circuit the rest of the routine, right? Didn't even notice that (or realize what it could do)!

That's weird! LOTS of code in this routine being bypassed! Crazy!

Thanks to everyone for (apparently) solving this mystery!

Colt Hero said:

Ohhhhh .... there's a "TND" on rung #2 all by itself! That'll short-circuit the rest of the routine, right? Didn't even notice that (or realize what it could do)!

That's weird! LOTS of code in this routine being bypassed! Crazy!

Click to expand...

Colt Hero said:

This is a vendor-supplied application.

Click to expand...

Perhaps time to change your vendor ???