I was looking for some other things on here regarding a how to question, and ran into all these push button being stuck on PLC. I under stand why it is happening and how it can be left in the on state if disconnected from SCADA with bad luck. So now, I am a little paranoid.
So lets say that the HMI on button does stay stuck like the image above, when the connection comes back from SCADA will it zero out the HMI on button ? If not, ever time they hit the start button it will restart.
the 2nd line has another example of moving some number into another register, I have put a one shot In case it also gets stuck, same question applies to this one.
From reading all the posts, it seems to me to make an array of HMI_PB’s maybe of 100. they will all be momentary PB’s coming from SCADA, if any one is left on maybe for 5 secs, I can clear them on the PLC using CLR function.
Note: not saying ignition has a issue, I would still apply this to all software SCADA’s
Alex, we can reset this from PLC, but I am looking for any other button can be used instead of momentary in ignition with out additional logic in PLC. Same as what you described the classic PLC start and stop.
We don’t use momentary or pulse style commands from HMI to control motors, but translating from things we use one shot commands from HMI for, this style hasn’t give us problems (YMMV):
Incidentally, we use a one-shot condition in PLC code for physical start/stop button inputs and add fault indication for if one of them gets stuck on (physical buttons get stuck too–more than HMI buttons if HMI buttons are programmed appropriately).
EDIT: By one shot commands in first paragraph, I mean they’re executed and then done. We don’t use one shot or momentary buttons at all in the HMI.
I think you mean "every time they hit the stop button"?
The SCADA will most likely not zero out the HMI button when the connection comes back (or whatever other issues caused the bit to become latched).
Add an OTU instruction for the HMI_ON_PB in line or on a branch with the Motor OTE. This will prevent the Button from being latched on from the SCADA.
It is always better for the SCADA to only set the bit (or I suppose reset if one insists on being obtuse), and then the PLC takes care of the other operation. This is true regardless of the button type (One-Shot, Momentary, or Maintained).
And although this is most often related to a communications issue that is not the only cause. For instance, Rockwell's RSView32 will produce this occasionally if the user clicks the button and then drags the mouse off of the button before releasing.
So it is best to just write the program in the PLC in such a way that SCADA set bits will not become latched longer than intended. Once the bit has been processed and the intended process initiated the bit should be reset.
So since everybody says do not use momentary button form Ignition, which is used then ?
The Idea of OTU is good, when the Logic is not using no Latch, sadly I am doing SCADA to a program that has lots of
them. So I can only come up with the same idea of monitoring the HMI tags that control with some sort statement that does the following in logic:
IF you gateway connection is lost,
THEN clear all check HMI tags that are true and clear
OR if gate way connection is lost THEN also check for HMI tags are true and clear.
I just think this kind of apllyies to all SCADA?HMI
You can use repeating signaling at a fast pace with a little bit of PLC code to handle the secure release of many bits in an array. See this comment for a suggestion:
Hello Alex…[quote=“alex.cordova.ee, post:5, topic:21468”]
I just think this kind of apllyies to all SCADA?HMI
[/quote]
Although all SCADA/HMI are susceptible to a momentary bit “latch lapse” under certain conditions, testing has shown that Ignition seems to be prone to this anomaly in all conditions at a rather alarming rate (no pun intended). You may find THIS thread interesting. It has a workaround that at least evens the field for Ignition with other direct comm protocols.
In any case… taking preventive measures, such as outlined by pturmel, to mitigate all conditions will always be the best course of action.
