RSLogix OTL instruction (Output Latch)

[ebolbol]

I posted a better image of the cross ref... first one was grainy and not legible...

daba... what is PM?

 

[Lancie1]

I suspect that ONS(37) is the culprit that is keeping the Horn from Latching. Once the rung has been true at one time, that ONS will not allow the horn to be latched on again until the rung goes false. As soon as you try to manaully toggle the horn on, the ONS sets it back to "0". If you first forced off the Lube Oil Level Low and toggled the HMI Reset pushbutton bit, then you might be able to turn on the horn bit. Get rid of that latching horn and you will not need a ONS.

I don't think I have ever used a One-Shot in relation to an alarm circuit. Neither would I use a latching relay to hold a darned horn on while everyone holds their hands over their ears. Use an OTE and a timed on-off bit to cycle the horn on 0.6 seconds, off 1 second.

The ONS instruction is an input instruction that makes the rung true for one program scan upon a false-to-true transition of the conditions preceding the ONS instruction on the rung.

Use the ONS instruction to start events that are triggered by a pushbutton, such as pulling values from thumbwheel switches or freezing rapidly displayed LED values.

You must enter a bit address for the bit. Use either a binary file or integer file address.

Note: During pre-scan, the bit address is set to inhibit false triggering when the program scan begins.
Rockwell Software

 

[dbh6]

@ ebolbol as many have already mentioned, try taking out that ONS[37] and see what happens, if the issue still persists, this is just a suggestion but from what you posted on the Main.jpg image two preceding conditions unlatch the horn, either the SCP_ESD_RESET or the HMI_RESET. I'm wondering if that HMI_RESET bit is always SET, meaning when your program scan comes back around to your main routine it unlatches the Horn_Act bit every time, check and see the status of the HMI_RESET bit and also if it is being unlatched somewhere, this of course depends on the setting of that HMI_RESET bit if it is a set from the HMI you would need logic to reset it, but ifs its set for momentary from HMI the HMI unlatches it for you. Again this is just a suggestion, i know that the HMI_Reset bit is not even lit up green to indicate that bit box is a 1, but its worth a shot.

 

[dbh6]

I suspect that ONS(37) is the culprit that is keeping the Horn from Latching. Once the rung has been true at one time, that ONS will not allow the horn to be latched on again until the rung goes false. As soon as you try to manaully toggle the horn on, the ONS sets it back to "0". If you first forced off the Lube Oil Level Low and toggled the HMI Reset pushbutton bit, then you might be able to turn on the horn bit. Get rid of that latching horn and you will not need a ONS.

agree with this post, you have to also keep in mind that since you have and ONS[37] followed by the OTL for one scan the OTL will be "on" because of the ONS[37] then will stay "on" even though the ONS has fired because when a preceding condition to an OTL is false, the OTL does nothing, it will be in the last state that it was in, then when the OTU unlatches it it will reset and it will stay that way. If you tried to toggle it as lancie 1 has stated the ONS will keep over writting it to 0, but again as lancie has stated If you first forced off the Lube Oil Level Low and toggled the HMI Reset pushbutton bit, then you might be able to turn on the horn bit, what that essentially does is drive the ONS from a false to true transition so your ONS[37] will fire, and as long as you don't give an OTU command the horn should latch on.

 

[daba]

I suspect that ONS(37) is the culprit that is keeping the Horn from Latching. Once the rung has been true at one time, that ONS will not allow the horn to be latched on again until the rung goes false. As soon as you try to manaully toggle the horn on, the ONS sets it back to "0". If you first forced off the Lube Oil Level Low and toggled the HMI Reset pushbutton bit, then you might be able to turn on the horn bit. Get rid of that latching horn and you will not need a ONS.

agree with this post, you have to also keep in mind that since you have and ONS[37] followed by the OTL for one scan the OTL will be "on" because of the ONS[37] then will stay "on" even though the ONS has fired because when a preceding condition to an OTL is false, the OTL does nothing, it will be in the last state that it was in, then when the OTU unlatches it it will reset and it will stay that way. If you tried to toggle it as lancie 1 has stated the ONS will keep over writting it to 0, but again as lancie has stated If you first forced off the Lube Oil Level Low and toggled the HMI Reset pushbutton bit, then you might be able to turn on the horn bit, what that essentially does is drive the ONS from a false to true transition so your ONS[37] will fire, and as long as you don't give an OTU command the horn should latch on.

The ONS is not the problem here, the instruction following the ONS is an OTL, and an OTL cannot write a "0" into the HORN_ACT tag.

Given.... static conditions, and no new input transitions, the OP was not able to toggle HORN_ACT to the ON state... ergo, something else is driving it back to a "0".

Suggestions of removing the ONS are inappropriate, the ONS is needed in the way the application signals new alarms only, and i can see nothing wrong with the way HORN and BEACON are controlled in this logic.

 

[ebolbol]

Thanks each and every one of you for taking the time. daba resolved my problem. In a nutshell, there was an OTE being driven from a remote plc message instruction. I have attached the screenshot for every one to see.

So as long as the OTE was tied to the remote bit, its value was being written into and kept at "0"... and when I AFI'd the suspect rung, I just added to my problems of always keeping the HORN_ACT bit false... when I deleted the suspect rung, my problem went away.

daba, does that pretty much explain it?

 

[daba]

Yep !

Although removing the rungs is removing the remote silencing of the Horn - something which may annoy the operators.

I have suggested that you leave the second rung with OTU HORN_ACT in place, that one is not a problem rung and will function just fine, even though the bit coming from CT3 is false, the OTU will not unlatch HORN_ACT.

What is needed is an investigation of CT3, to see what is the intended function of rung 205. I suspect it is a "Remote Alarm Ack", as there is similar code above it coming from other PLCs, and it should possibly be unlatching BEACON_ACT (and possibly HORN_ACT as well, to silence the noisy thing.

 

[dbh6]

Glad you guys resolved the problem, however i just want to clear something up. My post above was based on the assumption (hate that word), that their was seen to have written to the Horn_Act bit, now if their is a MSG instruction involved that the Horn_Act bit is being remotely written to then thats a different story. @ daba, you are indeed right in that the OTL cannot write a 0, however i may have worded it incorrectly as i was on the road. I know that the "ONS is needed in the way the application signals new alarms only" but since we are trying to figure out what is causing the Horn_Act to a value of 0, i don't see any harm in taking it out ONLY for troubleshooting purposes, as putting it back in would be easy. Would i write an alarm logic like this no, but their is probably a reason for it. Otherwise glad you found the issue.

 

[dbh6]

just curious though did the "routine" with the MSG bit writing to the Horn_Act OTE come before or after the "routine" with the Horn_Act OTL??

 

[daba]

just curious though did the "routine" with the MSG bit writing to the Horn_Act OTE come before or after the "routine" with the Horn_Act OTL??

It wouldn't matter either way, sooner or later after RSLogix5000 toggled it, the rung would be scanned and turn HORN_ACT off again.

The fact of the matter is that the toggle command would have worked, nothing stops RSlogix doing so, but some {short} time later the code would have put it back again. Now since RSLinx access time could be 0.5 seconds or even worse, then it would probably never ever have read that tag with it set to a "1".

I was quite confident that there would either be a false rung with an OTE of the tag, or a true rung with an OTU of the tag.

On the subject of HORN_ACT being written by another controller, you cannot specify a single BOOL tag as the destination for a message, the minimum allocation for data-transfer by MSG is a SINT, so I had discounted that notion.

As for previous suggestions that a MOV, an XOR, or some other instruction could reset HORN_ACT, I had discounted most of those also, since they also need an "integer" or REAL data-type as their destination.

Sure, there are some instructions that can specify a single BOOL tag as a destination element, not forgetting of course that HORN_ACT could be an Output Parameter of an Add-On Instruction, but in reality they would have shown up in the "destructive" column of the cross-reference.

The fact that ebolbol's pictures did not show the OTE that I quickly found in the .ACD file he sent me, was that he took his screen-shots from an out-of-date, offline copy of the code... I believe he has learned a valuable lesson from this, namely, do not assume anything..

 

[ebolbol]

dbh6,

Thansk for taking your time. To answer you question, the OTE driven by MSG inst. is at the very bottom of a Routine called "Communication" that lives under a Program called "MainProgram" that is in a Task called "MainTask"

As for the HORN_ACT OTL's, they are in completely different routines and under a different program and task. If you scroll up to my post from April 26th, 2013, 05:39 PM you can see where they live. As far as what comes first in the directory tree, I'd say the task that has the OTL's

 

[Lancie1]

This all demonstrate the problems of lataching on any Horn Alarm output. I had many nights to ponder why anyone would do this while a malfunctioning part in the process casued an irritating earth-rattling 100 dB horn to be latched on repeatedly, forcing the operator to have to drop whatever he was doing and run for the Acknowledge button.

If the alarm had been a simple OTE output, then when the alarm condition goes away after the process has time to stabilize, as happens about 95% of the time, then the horn would simply have went away.

Maybe there are a very few cases when the alarm must be latched on for some reason (to create an alarm record where that is necessary), but in many years of late night troubleshooting involving loud horns, those cases amount to about 1% of the total.

Alarm horn latches are mostly created by people who have never had to live with one.

 

[ebolbol]

Lancie1,

I hear you man! fortunately though, our so called horn is a much more tolerable warble tone that does not deafen you. Around here, we don't even call it the HORN, we call it the "audible alarm". It's tied to everything... Been that way for years. Besides, the logic that you see has been programmed by a controls outfit that has done all of our controls upgrades. In all honesty, it has not been terrible. Until of course this last go around where CT3 came into the picture and locked out the audible. All programmers are different but all the good ones produce the same good results.

 

[Phrog30]

Just FYI for next time, you should have received a duplicate destructive bit reference warning message when you perform a verify routine or verify controller within RSLogix5000, at least the version(s) I use. This option can be turned off/on in options.

 

[daba]

Just FYI for next time, you should have received a duplicate destructive bit reference warning message when you perform a verify routine or verify controller within RSLogix5000, at least the version(s) I use. This option can be turned off/on in options.

So right !

Although I rarely use this verification, since it flags up so many instances in a program that performs as designed, it can be hard to see the wood from the trees.

I always rely on the "destructive" cross-reference entries and look for something that shouldn't be there by design.