Scratching my Head Latch Unlatch issue

I have a machine with a ControlLogix Processor. The program was
converted from a PLC5. In 1 section in rung 1 is a piece of logic
with an (U) unlatch output bit. During the issue this rung appears to stay false.
In rung 7 is logic and is always in the true state. it has the (L) latch output.
Rung 8 has logic that appears to be always true and it also has a (U)
unlatch output. My issue is randomly and very quickly the Latch is
toggling on. Can this arrangement of the 2 (U) unlatch bits cause this
issue. The only way I could see this was on a trend it is so fast
and random.

Christoph said:

I have a machine with a ControlLogix Processor. The program was
converted from a PLC5. In 1 section in rung 1 is a piece of logic
with an (U) unlatch output bit. During the issue this rung appears to stay false.
In rung 7 is logic and is always in the true state. it has the (L) latch output.
Rung 8 has logic that appears to be always true and it also has a (U)
unlatch output. My issue is randomly and very quickly the Latch is
toggling on. Can this arrangement of the 2 (U) unlatch bits cause this
issue. The only way I could see this was on a trend it is so fast
and random.

Click to expand...

Print or save the logic to a pdf and post here.
It's hard to answer your question without seeing it but the issue you are describing has to do to the logic not written incorrectly.
Different PLC platforms work differently and a line for line logic conversion does not guarantee the program will work correctly on the new processor.

Could be related to the asynchronous I/O scan of the CLX.

Be careful when describing if the rung appears to be true or false. Don't base what you are seeing on the output status of latches. Base it on the logic ahead. A rung could be false but the output may be latched on.

First, understand that when the Unlatch instruction is "true" it will not be highlighted. The Unlatch writes a "0" to it's tag which turns the physical output off so it will not be highlighted in logic.

Also, when the Unlatch is "false" it does nothing. It does not write a "1" or a "0". Whatever data was in the tag remains unchanged.

Now reverse that operation for the Latch.

The fact that the Unlatch doesn't highlight when it is true causes lots of confusion. Remember the Unlatch turns your output off. When it is off it should not be highlighted. I always tell people to forget whether it is an OTU, OTL, or OTE. If it is a "1" then it is highlighted. If it is a "0" it does not highlight. The type of instruction doesn't matter.

The action you are seeing is not unusual. Remember that the PLC solves logic rung by rung. So if Rung #7 is True it will turn on the output bit via the OTL. If rung #8 is True it will turn off the output bit via the OTU. So, for that time in between, the output bit was on. Your screen update might randomly occur between those two rungs and show the output in an On state.

The question becomes, is your phyiscal output being affected or is this merely an issue of what you are seeing on-screen.

OG

It is logically toggling as it is used elsewhere, in a reference calculation for an E/P
and I can see the air pressure start to surge just for a fraction of a second!

So then you need to modify the logic where the OTL is. Add the conditions from your OTU rung.

For example lets say you have:
if input A is on then latch output x.
if input B is on the unlatch output x.

Modify it to:
If input A is on and if input B is off then latch output x.

OG

her are 2 pdf's

So rung #1 is false and isn't doing anything.
Rung #6 is turning the output bit on.
Rung #7 is turning the output bit off.

So every scan the bit is toggling on at the end of rung 6 and then off again at the end of rung 7.

If you have Periodic tasks or Event tasks in your system, they can interrupt the scan and go execute other logic. That interrupt could occur between those two rungs.

We can't see the remainder of rung #7. Can you post another pic of rung #7 where we can see all of it.

Also ideally a view that show what you have under the Tasks folder. Particularly where this routine is located.

OG

In Contrologix I believe that communications is handled asynchronously to the scan also. Your device inquiry (for display) concerning the state may be arriving between the two rungs.

I would create a trend and include all unlatch conditions and the RWD_B3[7].1 bit. You won't be able to see short changes (less then a few 100 ms) in the editor but you might be able to see them in a trend.

I have done that already and I do see RWD_B3(7)1 toggle
I branched the Unlatch output and put in a OTE. I then placed an examine off in the beginning of rung 6. this seem to have cured my issue.

Doug-P said:

Could be related to the asynchronous I/O scan of the CLX.

Click to expand...

The bit in question is internal. The asynch I/O update wouldn't matter here.

bernie_carlton said:

In Contrologix I believe that communications is handled asynchronously to the scan also. Your device inquiry (for display) concerning the state may be arriving between the two rungs.

Click to expand...

That was my thought too. The issue he is seeing is that something else is being triggered by this blip in the data. Which leads me to believe there is an interrupt occurring.

OG

The programs affected are in an interrupt. and there is a second interrupt also.

Originally posted by Christoph:

The programs affected are in an interrupt. and there is a second interrupt also.

Click to expand...

And there is your answer. Very occasionally, just by dumb luck, the interrupt will trigger after the latch is executed but before the unlatch is executed. The Logix control engine will interrupt the execution of the active rung as soon as the interrupt occurs and jump to the interrupt task assuming that the interrupting task is a higher priority than the interrupted task. So, very occasionally, the interrupting task will see the bit set even though logically you wouldn't think it would.

When the program was converted from the PLC5 original, the code that is seeing the bit high was likely not in an STI or they would have seen the same thing previously. The code was likely called from the main body of the program.

Keith