Question about AB latched bit commands OTL/OTU

Why is it that I can use multiple instances of an otl for a bit.... and the code works just as I planned it, yet... I can't use multiple instances of the OTU?
Just had a client had a problem bringing an RTO online.. and the problem was that there were 2 instances of the otu command for the said bit.. the last occurrence of the otu in the logic is the controlling otu.. that is the only one that could unlatch the bit.
The otu that was earlier in the logic was true, and should have unlatched the bit.. but it didn't. I learned this lesson years ago, and it's interesting to find it in someone else's code.
But it got me thinking.. in my temp avg logic I use multiple otl's without a problem (though I only have one occurrence of the otu).
Is this a concious decision on the part of Rockwell, or is it a bug?


Regards,
Russ Friend

I have never seen this type error. I have used multiple OTU's all the time and, assuming there is no intervening enabled OTL, they all work correctly at all times even if a later OTU is not enabled. You may wish to re-analyse the situation.

that could be a possibility, but the otu rungs were only a few rungs apart... and the one rung was true all the way across...yet.. the otu was still low... it was a slc 5/03... don't know if it might need a firmware upgrade or not.
A few weeks ago I ran across a 5/03 that wouldn't allow indirect addressing.. had to use a sql instead... so.. I don't know...


Regards,
Russ

Russ Can you post a screen shot of the rungs in question?
I don't have an answer but maybe the code will help somebody here see the problem?

Is RTO Regenerative Thermal Oxidizer?

But it got me thinking.. in my temp avg logic I use multiple otl's without a problem (though I only have one occurrence of the otu).

Click to expand...

How quirky!! I do the exact opposite.....I use several instances of an OTU, but only ever have one OTL for that address....Don't ask why, just always have!!


Doesn't help with your problem though...........

Put a dummy output bit in a branch around that first OTU. Either just an OTE, or a latch. If the logic is really all going true prior to the OTU, then your latch bit will most definately reset.

If it isn't, maybe you have the rungs disabled with a JMP? or an MCR? or something is turning the bit right back on.

I agree with Bernie. You can use as many OTU and OTL instructions as you want (though you should document them well!). The behavior that you describe is typical of OTE instructions (double coiling), but not the OTU/OTL instructions.

Marc


PS: If you are looking at OTU and OTL instructions, you should search for some of the discussions/debates about when to use/not use them. Search for "latch" and "Set/Reset" - there are at least three very detailed threads . . .

I think Bernies right as well.. after reading Bernie's reply I went back and looked closely at the logic..
What I found was that there are 2 supply fans that can run... either together, or seperately... when they run together a bit goes high... when they run seperately this bit is supposed to unlatch and go low...
For some reason the original programmer set up the logic so that when both are selected to run... both fan run bits go high, but only when fan 2 was selected by itself did the 'both fans selected' bit unlatch (it was missing for when fan 1 was selected).
I made the adjustments.. and added another fan 1 rung that was missing (it was there for fan 2 only). Now things look pretty good...


Thanks,
Russ

Russ said:

... and the one rung was true all the way across...yet.. the otu was still low...

Click to expand...

If the OTU instruction is not highlighted, then the bit is off and the OTU has done its job.
If you ever see the rung true and the OTU highlighted, then you may have some debugging to do.