Alright then, I’ll do that. It’s a bit disappointing because in normal operation this is happening VERY often (~2% of the time). It’s a relatively low-power panel PC I’m running my gateway on. It seems more prone to freezes/glitches than previous machines so maybe this is just one of them.
I have a beta of the Ethernet/IP module with the reliable Momentary I/O Button component available here. The embedded user manual has a few paragraphs on how to use it.
Unfortunately, I can confirm and replicate this issue on 7.9.7, with either no min/max hold time or default times. It takes an average of 30-60 button presses before it latches on, but it consistently does. And as mentioned earlier, it seems to be a race condition caused by clicking the button at an erratic pace. I am using a standard momentary button component within a template.
I would hope this issue could be resolved… either that, or perhaps the momentary button should not be an offering at all?
Phil, thanks for your contribution…. I will DL and take a look at it.
I'll be issuing a new beta shortly -- found some bugs. /-:
To whom it may concern…
I have experimented with different settings on the Scan Class associated with my Momentary button template. After several failed attempts, I finally copied the Default Scan Class (Direct, 1000ms, Subscribed) and checked the option for ‘OPC Read After Write’. In testing, I have (as yet) been unable to cause the bit to latch after well over a thousand mouse clicks whereas I was able to easily cause a latch after just a few dozen clicks without the OPC Read After Write option selected.
Perhaps a workaround, perhaps just a coincidence? If used make sure you are in a test bed and not a live environment. We are using for pre-FAT at the moment, so we will have a much better grasp of the work-ability after another week or so of testing… but, so far, so good.
Interesting. The failure to write when not checking is far more common that even I thought.
You are still vulnerable to any of these, and to gateway-plc comms failure at the OPC level.
Hmm, yes, I see the problem there. Could I mitigate those special factors by coding the PLC to monitor the gateway via a handshake ping to the client and act accordingly? Well… except for window closure. I guess I could do that on an internalFrameClosing script.
I can't think of any way to do that. I wrote the module's reliable button with a ping from the client because it is the client that must affirmatively indicate that it is still pressing the button. And the gateway must affirmatively indicate to the PLC that a client is still pressing the button, which is really easy with an I/O protocol, and really difficult with any TCP-based protocol.
Thank you for the input. Very much appreciated!
Use the one-shot button when interacting with the PLC, works very well, just remember to unlatch the bit, set by ignition, when the PLC recieved it.
Having the PLC unlatch a bit set by Ignition is my normal design pattern. But It doesn’t work for jog buttons or similar hold-button-to-move operations.
A new version of the Ethernet/IP module with the reliable momentary pushbutton is now available here. Fixed some gnarly bugs, and not just in the pushbutton code.
After two weeks of FAT testing, I can confirm not a single latched bit from the dozens of momentary buttons after many hundreds of presses. These buttons are for controlling servo and hydraulic movements in manual mode, so HMI latch / PLC unlatch coding is not really a viable option.
I am facing this same issue with 7.5.6 version. Here in my case, I have made a container with two momentary button(start and stop) and each of them are hidden to one other when PLC latches the run bit. (This means, when blower is not running it shows the START button and when the blower is running it shows the STOP button). Problem here is the START button gets latched in the program.
Since this project was created in an older version, I recreated this on 7.5.6, but the problem still exists. Is there a solution with out editing the PLC. I hate to give a timer based unlatch button for each motor starter rung in PLC. I would like to solve with ignition, if there is any solution available.
We've had some issues with Ignition tags latching ON, while the PLC set the bit to OFF.
In our case, a bit would be set with a one-shot button (the button would show "writing..." as text).
The PLC would then reset the bit after 100ms, but occasionally, the button would hang on "writing...". I was never able to do 10 writes in a row, without hanging.
Starting the Designer, and looking at the tag browser, we could see the tag was still ON. But when using the OPC client, the tag was OFF. Clicking the bit in the tag browser did reset it in the GUI.
We've found the problem was with the "Read After Write" setting. Disabling that setting makes the button work correctly, albeit somewhat slower.
This is the setting with which we can reproduce the problem reliably.
My theory is that the forced read was fast enough to see the bit in an ON state. But was followed immediately by a regular polling read reading an OFF state. Both reads were send more or less in parallel to the server, where the OFF message seems to have overtaken the ON message.
As the last message was showing an ON, and no new changes happened in the PLC so no subscription updates occured, the tag remained in an ON state.
Notice that the scan rate is larger, but in the same order of magnitude as the reset time by the PLC. AFAICS, this helped in creating almost simultaneous messages overtaking each other.
Given how the "read after write" setting is only useful when Ignition and the PLC write to the same bit (in different states), but it can cause Ignition to hang on the wrong bit, I don't really understand why that setting is useful, or when it should be used.
This does show some extra dangers with "one shot" button, and that not only the "momentary" button has a possibility to hang.
Yeah, I no longer use this design pattern, if I can avoid it. I use incrementing handshakes in (8-bit registers where available) to signal events. The PLC keeps a copy of the last value to compare for changes. This approach does not require writing the same memory location from two different directions. If you only allow any given PLC register or bit to be written from one direction, a race isn't possible.
Carl. I have 7.5.6 , but this problem still exists in that too.
So there is no proper solution in place for this?
Correct. This method is now in a live system and there has been no reports of latching after many thousands of clicks. Of course, as mentioned previously, there is always the possibility of latching if gateway > plc coms are interrupted.
If its a communication issue between PLC and gateway, why don it happens for all momentary buttons that I have. I have several of momentary buttons and it happens only for three of them. Also, I have a fiber optic communication between my gateway server and the PLC node.
So, there could be something else.I tired to compare with the other momentary button that don’t have any issues, everything seems to be same. I re-created another momentary button and it does same.
I am not an expert in this, but some of the question that arises, is it possible to make another property to reset its value back to original with in a certain time, say 1000 ms or so… Don’t know, if its a stupid thinking…