RSLogix OTL instruction (Output Latch)

[ebolbol]

Hello wizards,

This is a typical alarm rung in our plant, for some reason, no matter what I do, I can not drive the horn bit. And no alarm is able to drive the audible horn. Usually OTL's are easy to toggle on and off even if they are being written into, but not in this case. Could there be a MSG instruction somewhere remotely keeping the horn tag always false? Perhaps there is also a OTU instruction in the same program (Output Unlatch)thats killing it before it has a chance to change states? Lost here...

 

[Volvagia720]

A few things to try.

Do a search for all instances of HORN_ACT. Make sure that there is no OTL, OTE, or something else modifying it.

Try running the code without the oneshot.

Make sure the ladder is being called with a JSR from the main routine.

 

[James Mcquade]

the speed is to fast to see a toggle in regards to your logic.
is the logic in fact true on this rung? the logic might be off on this rung and the same conditions be turned on elsewhere.

also check to make sure the oneshot is not used twice.

regards,
james

 

[Ron Beaufort]

so you can't even "toggle" the Horn on? ...

besides the other suggestions that you've already been given, do a Right-Click on the Horn's OTL ... select the Cross-Reference tool from the popup menu ... look for items that have a "Y" (for "Yes") in the "Destructive" column ...

 

[ebolbol]

Volvagia720,

thanks for the reply. I've done the cross ref and search does not appear anything else is modifying it... also, yes it is being called out in the JSR. have not tried it without the one-shot though but I will.



James Mcquade,

thanks for the reply, the rung you see is in alarm mode and all OTL's are latched in with the exception of the horn. Even when I try to toggle it manually which you should be able to do with OTL's it does not budge. I will check the one-shot however, good thing to check. thanks


Ron Beaufort,

thanks for the reply... I've tried exactly what you said... cant find anything that would inhibit me from toggling the horn.

 

[daba]

Ron Beaufort,

thanks for the reply... I've tried exactly what you said... cant find anything that would inhibit me from toggling the horn.

What cross-references came up that had "Y" in the destructive column ? (apart from the OTL on that rung).

Nothing will "inhibit" the RSLogix toggle command, it will do exactly as it is told, but there may be logic that reverts the state of the bit back to where it was - so you don't see (or hear) it.

Chances are that you have many alarm rungs, and all of them want to turn the horn on. Has one of them been programmed with an OTE by mistake ?

 

[daba]

Incidentally, since we are using ControlLogix, we can dispense with the output branching. The pic shows 2 rungs of code, your original, and a modified version that uses less instructions (less memory usage), and executes faster. Both rungs function the same way.

The mnemonic editing of these rungs shows that the first uses 18 instructions (highlighted in red), and the second uses only 10. That's quite a considerable saving, and worth doing on "large" projects, e.g when you have hundreds, or thousands, of alarms.

BST XIC LO_Level_Low NXB XIC LO_Level_Low_Alarm XIO HMI_Reset BND BST OTE LO_Level_Low_Alarm NXB OTL ALARM_ACT NXB ONS ONS[17] BST OTL HORN_ACT NXB OTL BEACON_ACT BND BND

BST XIC LO_Level_Low NXB XIC LO_Level_Low_Alarm XIO HMI_Reset BND OTE LO_Level_Low_Alarm OTL ALARM_ACT ONS ONS[17] OTL HORN_ACT OTL BEACON_ACT

 

[ebolbol]

daba,

I recognize your username, you have provided me with great help in the past and I appreciate it. I will try your method above in future alarm logic to see how it functions. (definitely different) you are correct in saying there are many alarm rungs in the program. When I cross ref, tons of destructives show up, as they should, since they are all similar alarm rungs. I have tried many ways to AFI all the OTU's, and even have taken entire routines out of JSR from being called to see if I can toggle the bit....nope! will not budge... I have disconnected all the remote controllers that are tied in to this particular controller incase they are writing into this tag, and still no go... One thing about OTL's is no matter what is writing into them, you should be able to latch and unlatch it.... nope! not this one. I will chekc for OTE's and will send a screen capture of the cross ref....

 

[mike_dr]

the important OTU that should not be energized is the horn_act since it will definitely override the OTL horn_act. So you need to cross ref the HORN_ACT not OTU. If you AFI/disable that rung, you can toggle horn_act and assuming that bit is directly tied to the output, you will hear the audible horn

 

[daba]

ebolbol, this shouldn't be so difficult to find now that you have isolated the plc from external comms....

1. Have you tried toggling the bit with the controller in Program mode ?

If you have, and it toggles OK, then clearly it is the running program that is putting it back again. If it does not toglle OK, and the controller is isolated from all comms, then you have a strange fault indeed !!

2. When you generate the cross-reference, you can either....

a> double-click the "Destructive" column header to sort the display (you may need to do it twice to get the "Y"s to the top). Now look down the left-hand column at the instructions, looking for OTU's and OTE's.

b> double-click the Instruction column to sort by instruction mnemonic, this will group any OTE's first, then OTL's, then OTU's

Either way, it's OTU's and OTE's you will be interested in.

If you find any of these,go to the rung where they exist, and see if the rung is TRUE for OTU's or FALSE for OTE's.....

Either one of these conditions will write the bit off again after you have toggled it.

If you get no success, can you post the .ACD or L5K export file (you will have to Zip it first, forum rule), and we can take a look for you.

PS : don't "AFI" any rung with an OTE of the bit, that will just create the very scenario you are encountering.

PPS : you said..

.... One thing about OTL's is no matter what is writing into them, you should be able to latch and unlatch it.... nope! not this one....

That statement is not correct. You need to realise that you are NOT toggling the OTL. An OTL is an instruction that writes a "1" into the tag address on the instruction when the rung is TRUE. Similarly, an OTU is an instruction that writes a "0" into the tag address on the instruction when the rung is TRUE. An OTE, on the other hand, will write a "1" or a "0" into the tag address on the instruction when the rung is TRUE or FALSE.

The toggle from RSLogix5000 simply reads the state of the bit, and writes the opposite state. If the code puts it back again, then there is a good chance of not seeing the bit change state

So your statement is incorrect, if the rung that has an OTL on it is TRUE, then you can toggle the bit off, but the rung will write it back on again.

 

[Ron Beaufort]

post the entire ACD file if you can ... if the ACD file is too large (even when zipped) try doing a File/Save As operation – and save the file as an L5K type ... this should be MUCH smaller ... zip the L5K file and post that ...

but if you can't post your entire project – please at least post a screen shot of the Cross Reference for your "problem bit" ...

it could be something else "destructive" controlling the bit besides OTU and OTE instructions ... especially in "alarm" type programs, AND, OR, and XOR instructions are commonly use – and they can write into the bit too ... also MOV and COP instructions, etc. ...

post what you can ... we're trying to help – but we need more to work with ...

 

[brstilson]

There's got to be some kind of instruction like an unlatch writing a 0 into that tag somewhere. It could be an OTU or an OTE. Remember the OTE instruction is not a relay and still "does something" when the rung is "false." You're not dealing with coils, you're dealing with program instructions. I'm not sure about the Logix platform, but I do know in the SLC platform an unlatch instruction will always supersede a latch instruction. Since your OTL is on a one-shot, it's only evaluating it once every time the rung status changes. In the meantime, that tag is "fair game" for the rest of the program.

 

[daba]

There's got to be some kind of instruction like an unlatch writing a 0 into that tag somewhere. It could be an OTU or an OTE. Remember the OTE instruction is not a relay and still "does something" when the rung is "false." You're not dealing with coils, you're dealing with program instructions. I'm not sure about the Logix platform, but I do know in the SLC platform an unlatch instruction will always supersede a latch instruction. Since your OTL is on a one-shot, it's only evaluating it once every time the rung status changes. In the meantime, that tag is "fair game" for the rest of the program.

I most strongly disagree with your statement highlighted - it is wrong, and could possibly lead you into troubles if you believe it to be true.

I will apologise in advance if I have misunderstood your meaning, but I do not want others to use or believe that notion.

An SLC processor, like any other Allen-Bradley processor, does NOT, and CAN NOT have any preferential judgement on which instruction should have priority. It does NOT "store" any flag or status that says it has executed an OTU, so that it can ignore any subsequent OTL instructions. So it is WRONG to say that an OTU will always supersede an OTL.

The processor will doggedly work it's way through the program code, file-by-file, rung-by-rung, instruction-by-instruction, executing each instruction with absolutely NO regard for what it has already executed.

It is entirely up to the programmer to arrange his instructions in the order in which he wants them. It will always be a case of "last one wins" when the addressed bit is evaluated by an XIC or XIO, or transferred to output modules.

 

[ebolbol]

daba

Ron Beaufort

brstilson (thank you!!!)

mike_dr (thank you!!!)

hope I got everybody on the gratitude and appreciation list. thanks tons for spending valuable time on this. I may not be at your level in RSLogix, but I'm pretty handy in corss-reffing and drilling down... I don't see a single thing in cross ref that would cause this... I would love to post the entire project, but I think company's get strange about that... I dont even know who I would ask? however, attached, you will find the main routine in addition to the [ENTIRE] cross reference results.

 

[daba]

check your PM, ebolbol