Studio 5000, OTE switching on and off even input is steady.

[BCZ116]

Hello guys, please let me ask if you have experience the same situation like this. Inputs are steady but the outputs OTE are switching off and on. I have tried to check all routines but failed to locate which one is causing this problem. If I can upload the video, you can see that its going on and off, causing the valves to not work sometimes.

Thank you.

 

[jstolaruk]

Something other piece of code or external connection is "stepping" on it. If if still escapes you, upload it and one if us will find it.

 

[plvlce]

Yes, most likely cause is that either something else is writing to the OTE or the XIC bits, or you have some other form of logic conditioning such as an MCR.

Start by doing a cross-reference on the OTE and XIC and looking for destructive bit references. Is the XIC bit coming from a local input or an external connection?

Is it only a single output you are seeing the issue with? If not, is there any common factor in outputs affected (eg all outputs coming from inputs that are on a specific card)?

 

[Aardwizz]

Chances are that your T51_YV_xxx's are AOIs which control the valves. Your "AutoC" and "ManC" bits are intended to be set by the code, and then reset by the AOI, just as they would be if commanded from an HMI. It would probably work better if instead of OTE you used OTL.

This technique allows the valve to be commanded independently from multiple sequences, or steps within a sequence -- SFCA and SFCD for instance. Using OTEs means the last rung wins, resetting a bit that desired to be set by an earlier rung. The "twinkling" of these bits is quite common in these kind of structures.

 

[BCZ116]

Yes this is an AOI. If i cross reference ManC, only 2 elements will show. Only one OTE which is blinking and one from AOI. Please see attached photo.

I have checked the logic for the AOI and I am wondering why at Rung 24 (HMI COMMAND RESETS), there is no XIC in input side and the OTUs, which includes ManC, are connected directly like this. Maybe this is the cause, it is unlaching all the time. And I cant edit this AOI logic. Photo is also attached. Thank you.

 

[Aardwizz]

I am wondering why at Rung 24 (HMI COMMAND RESETS), there is no XIC in input side and the OTUs, which includes ManC, are connected directly like this. Maybe this is the cause, it is unlaching all the time.

There's no need for an XIC before the OTU. By scan order, all the actions ManC needed to perform (setting ManS and resetting AutoS) were taken care of above. This rung is just clean-up housekeeping so that, when the next command comes in, it acts on it.
Note that the rung says, "HMI Command Resets". It is likely that the original intent (and perhaps current execution) is to have the HMI set the Auto and Man Commands to put the valve in the Auto or Man State (or rather, Auto or Not Auto). What the sequence is doing, as I stated above, is to act like an HMI pushbutton, sending a value of 1 to the "Valve Controller" which then clears the bit.

If that function still exists, on some valve pupup on the HMI, then your OTE coils are going to screw up the HMI. The HMI operator could potentially push the MAN button, setting ManC. But that '1' in ManC could hit your OTE when the sequence isn't running, and thus get reset so that when it hits the AOI, there is no '1' from the operator to go into ManS. Or they might successfully go into Man, but hitting the Auto button would hit the OTE and he wouldn't be able to go back to Auto -- only the PLC can do that.

Again, you'd be better off using OTL's in the logic in your first post rather than OTEs for this reason. They'll still twinkle, but it'll be clearer why -- that logic will set the bit; the AOI will reset it.


I am at a loss to understand why you have any ManC coils in your first post. The Auto state has the valve listen to a "AutoCtrlC" bit (rungs 9&10, since AutoCtrlS = AutoCtrlC) while the Not Auto state listens to OpenC and CloseC commands. I would expect your logic would be a lot cleaner if you have a single AutoCtrlC OTE (not a series of OTL / OTUs in this case -- that would be really poor programming) to say when the automatic sequence(s) want YV-xxx to be open (and closed otherwise).

Perhaps you plan to use a bunch of OpenC and CloseC commands. But again, if you do, those are going to act like "HMI commands" -- set by the sender; reset by the receiver.

And I cant edit this AOI logic.

Two possible reasons for this:
A) the original programmer didn't want to get blamed if someone edited his master code, breaking every other valve in attempt to "fix" one, and so password protected the AOI, allowing "Look, but don't touch".
B) you're trying to edit the AOI while online. AOIs can only be edited offline and then compiled and downloaded to the processor. (Most likely).