Using Ignition V7.3.8. Gateway Windows 7 pro, and two clients connected. Both clients touch screen PCs. gateway connected to only 1 Contrologix.
One screen has a Start and Stop Momentary pushbuttons used to start and stop a process. Start bit is a BOOL to PLC, stop bit is a BOOL to PLC. Classic start/stop circuit being used in PLC.
When start or stop button is pressed, the dashed moving box appears around the pushbutton for about 1 second. Probably the default scan class.
Received a phone call from the customer that their plant would not start. After pulling teeth through troubleshooting blind , customer stated that the Stop pushbutton still had the dashed moving box around it. This would make sense as I told the customer it appears if the stop bit is stuck ON preventing the start/stop circuit from working.
Is this a known issue corrected in future Vision revisions? If not, then I need to add unlatch logic in PLC to prevent this happening again. Unfortunately for me , this is an out of town job that is a 5 hour round trip drive.
Yes. But that would be a toggle buton. This is a momentary.
Operator pushes stop and leaves. Next shift another operator tries to start, not realizing the Stop is latched on and then the phone calls start when equipment does not start up.
Fella, I know itâs a momentary. But the theory stays the same.
Momentaries write a value when theyâre pressed, another value when released. OPC doesnât care what type of button it is, just what values itâs trying to write. If thereâs an OPC hiccup during the release of the button-- and oddly enough, things like that really do happen, then there wonât be a change of state back. But another press should repeat the process (write the pressed value, then the unpressed value).
In my opinion, youâd be better off using the One-Shot button and confirming the button press in the PLC code. This way you KNOW that the PLC got the changed value and reset the value back to normal state.
I donât like to use the momentary buttons for the very reason you posted, youâre never 100% sure the bit change went all the way through to the PLC or it didnât get stuck in some state, and if itâs a critical stop or start situation you want to be 100% sure it made it. Think about what would happen if there was an emergency and operators couldnât shut the system down because a start bit was latched on in the PLC code, not good⌠Just my $.02
I would definitely agree with Doug here - I much prefer to set the bit in SCADA, then action it and clear it in the PLC. As Doug says this also has the advantage of confirming to the operator that the PLC saw and reset the value.
I have used a momentary type button before with a touch screen to control the movement of a hoist - the hoist moved when the operator kept their finger on the button and stopped when they released it. Iâm not sure if Iâd be keen to do this again - I did this when I was young and foolish but then it has been working reliably for over 12 years
Any kind of emergency stops should of course be hardwired external to the PLCâŚ
I hate using latched logic in the PLC. Makes the program unpredictable after a power failure.
I have seen a similiar problem to the one I stated in OP when a bit latches ON. Back in the days when we used to write our own SCADA using VB, any time a momentary button was mouse clicked and if the cursor was moved away from the button while still holding the mouse click and released, the bit would remained latched.
I will put PLC code to unlatch the momentary bit once the necessary PLC action has been performed.
You can just put the Stop on its own line, inverted with a one-shot (edge trigger) to a coil, and put a one-shot after the Start on on the motor circuit line. Then the worst thing that will happen is the operator may have to hit the button twice. He/she will just think they missed the button.
Thanks for the suggestion, but seems like an awful lot of work for a feature that works without issues on WonderWare. On this application I also have 2 WW stations using the same type of touch screen with quite a few momentary buttons for Start/Stop. In the 7 years since I installed them , never has a momentary bit latched ON.
Believe me I love Ignition, but this is an area of concern for me. I should not have to jump through hoops to make simple momentary bits reliable.
Weâve had this happen w/ both Wonderware(9.5) and iFix(4.5 and 5.0) at the Plant. Havenât had it happen yet w/ Ignition but it wonât surprise me if/when it does.
In iFix, It seems to be more common w/ DO blocks than w/ DR blocks. I suspect because the DR blocks read the state as well as write it.
On the Wonderware side we actually figured out it was due to the SCADA comms being unscheduled, When the network(controlnet) gets particularly busy sometimes the âresetâ signal just gets dropped.
[quote=âDravikâ]Weâve had this happen w/ both Wonderware(9.5) and iFix(4.5 and 5.0) at the Plant. Havenât had it happen yet w/ Ignition but it wonât surprise me if/when it does.
In iFix, It seems to be more common w/ DO blocks than w/ DR blocks. I suspect because the DR blocks read the state as well as write it.
On the Wonderware side we actually figured out it was due to the SCADA comms being unscheduled, When the network(controlnet) gets particularly busy sometimes the âresetâ signal just gets dropped.[/quote]
Thanks for that.
In my case communications is always Ethernet . This application is a private network with two Clgx and 4 SCADA stations with two WW pointing to one Clgx and two Ignition pointing to the other Ckgx.
In your case, the NUT ( Network Update Time ) may need to be inscreased to allow more idle time for unscheduled connections.
Can you explain what you mean by the use of latched logic in the PLC making the program unpredictable after a power failure?
What Iâve always done is use the SCADA to set a bit high, which the PLC uses to put itself into another state - the SCADA takes no more part after this. If the PLC power fails, when it restarts it will be in some default state - the user will have to reissue the command before anything runs.
Can you explain what you mean by the use of latched logic in the PLC making the program unpredictable after a power failure?
What Iâve always done is use the SCADA to set a bit high, which the PLC uses to put itself into another state - the SCADA takes no more part after this. If the PLC power fails, when it restarts it will be in some default state - the user will have to reissue the command before anything runs.[/quote]
Simple,
the last thing you want to happen after a power failure is equipment to start back up due to a latched bit that starts some part of the process.
After a power failure, i always make sure the process is in a safe idle state requiring an operator initiated restart.
Ok guys, so first of all it will always be true that without any PLC logic, a momentary button implemented in a software system will be open for the potential for latching on.
The reasons for this should be obvious: a âsoftâ momentary button isnât a physical switch, itâs two separate write commands. It isnât hard to concoct a situation where the second write command doesnât happen: power down the entire scada system and boom - latched bit. Given this, the advice earlier in the thread about avoiding momentary buttons is good advice.
That said, I think it is certainly fair to say that under normal conditions, momentary buttons should just work. That is: we shouldnât hide behind a general âmomentaries are badâ advice to skirt around the real issue here, which is that there seems to be a race-condition affecting the momentary button.
We think we have this narrowed down (like all race conditions, itâs tricky to pin-point because itâs hard to verify 100% that youâve fixed the issue if you canât reliably reproduce it). Weâll re-work the section in question for 7.5.5 and Iâll post back here when progress is made on this ticket.
[quote=âCarl.Gouldâ]Ok guys, so first of all it will always be true that without any PLC logic, a momentary button implemented in a software system will be open for the potential for latching on.
The reasons for this should be obvious: a âsoftâ momentary button isnât a physical switch, itâs two separate write commands. It isnât hard to concoct a situation where the second write command doesnât happen: power down the entire scada system and boom - latched bit. Given this, the advice earlier in the thread about avoiding momentary buttons is good advice.
That said, I think it is certainly fair to say that under normal conditions, momentary buttons should just work. That is: we shouldnât hide behind a general âmomentaries are badâ advice to skirt around the real issue here, which is that there seems to be a race-condition affecting the momentary button.
We think we have this narrowed down (like all race conditions, itâs tricky to pin-point because itâs hard to verify 100% that youâve fixed the issue if you canât reliably reproduce it). Weâll re-work the section in question for 7.5.5 and Iâll post back here when progress is made on this ticket.[/quote]
Carl,
the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.
the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.[/quote]
I donât even know how to respond to this. I hope you were being sarcastic.
If not, please just trust me that you arenât fully appreciating the complexity involved here. The problem here isnât quite so âsimpleâ, in fact, it isnât even a problem with the momentary button at all (which does indeed act like a momentary button that you so aptly described). Our current hunch is that the problem lies in a race condition in some Gateway-side logic that is under rare circumstances reversing the order of two OPC write commands.
the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.[/quote]
I donât even know how to respond to this. I hope you were being sarcastic.
If not, please just trust me that you arenât fully appreciating the complexity involved here. The problem here isnât quite so âsimpleâ, in fact, it isnât even a problem with the momentary button at all (which does indeed act like a momentary button that you so aptly described). Our current hunch is that the problem lies in a race condition in some Gateway-side logic that is under rare circumstances reversing the order of two OPC write commands.[/quote]
Sorry Carl if you thought my post was sarcastic, that was not the intention. I thought I had a defintion of the solution to the problem. We all know in software, first you need to identify and replicate the problem, then define a solution, then implement and test that solution.
You must understand that it is we the users of your product that get the panic phone calls from end users when the product does not behave in a way that it was intended. It is me, the user of your product that must absorb the cost of a warranty trip to job site for something that has happend completely out of my control.
I definitely agree with your point on identifying and replicating the problem. This is a tricky one indeed, as most race conditions are! Weâll keep you posted on the progress of this issue. For the time-being, you may want to use the aforementioned workaround using one-shot buttons or something similar.
