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.
1 Like
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.
1 Like
. 
Carl,
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.
Regards,
SP
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?
Disclaimer: I donāt recommend this control method. That said, if I understand @sbrannenās posts correctly, he posted a solution above that worked in his application that may work for yours.
2 Likes
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.
1 Like
Steve,
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ā¦
Did you actually try the solution above? The issue we have (sort of) resolved is the issue of intermittent latching... in the neighborhood of 30-60 clicks there will only be a single latch of the PLC bit. If you are getting constant latching, then your issue is probably somewhere else.
As you were...
Steve
steve,
As you mentioned, I was trying to select the 'OPC Read after write for the scan class that are associated with this momentary button. But I don't see this option under my scan class editor.
Is it same as OPC Data mode selection, where I have tow options as subscription and Read.
Is it the one needs to be changed to Read?
I don't have a tag editor as shown in Sander Deryckere post
Your version of Ignition appears to not have the settings you need. It is ancient. At least try v7.5.14 if you cannot upgrade beyond that. But seriously, if you need highly reliable momentary pushbutton behavior, you will have to implement repeat signaling code in both Ignition and in the PLC to cover all of the cases.
1 Like
Perhaps you didn't grasp the core of the problem -- it isn't Ignition, it is the nature of request-response protocols. This problems exists in every product I've ever used over my 30 years in this business, with every brand of PLC and every brand of HMI. If they used a request-response protocol. Serial, ethernet, DH+, Siemens, Modicon, Allen-Bradley, and others. Even tag access over mixed technologies like DeviceNet and ControlNet. Didn't matter. All showed this problem. Products that implement the specific PLC's I/O protocol can be trusted with momentary buttons. Nothing else.
Products like Ignition that consolidate PLC traffic to a gateway, and then all HMI traffic goes through that gateway, do suffer from a higher chance of losing a release event, as there is another link in the communication chain compared to the direct connection of simple HMIs. And yes, there are corner cases that lose a release like closing a window while a button is pressed. But read the documentation for direct HMIs like AB's Panelview -- there are warnings about using momentary buttons over non-deterministic (I/O) protocols.
For an SLC, the only deterministic protocols supported directly are classic AB-RIO, DeviceNet (as an I/O slave, not tag access), and Profibus (the latter via third parties). Use one of those with a direct HMI for absolutely reliable touchscreen pushbuttons. Use a direct ethernet HMI for almost as reliable pushbuttons. Use repeating signalling with corresponding PLC code timeouts with anything else. Ignition or not.
There is nothing for IA to fix in Ignition.
7 Likes
A signalling approach to consider to minimize the PLC code required:
- Allocate a PLC array tag / file with enough integers to cover all of the momentary button bits you need for your application, plus two more for transmit counter/comparison at the end. Do not create Ignition tags for these PLC tags.
- Create a script module in Ignition that holds an array of timestamps for the number of bits needed, plus a persistent counter in a module global. Write two functions:
- A message handler that takes a bit number and sets the corresponding timestamp to some number of milliseconds in the future. 150ms or so.
- A gateway timer event function that loops through all of the timestamps, treating all in the past as 0 and all in the future as 1, packing the results bitwise into integers, appends the incremented counter, and writes them all to the PLC in a single system.opc.writeValues() call. Does not write to the last register in the array/file. Call every 100ms or so.
- Write a few rungs in the PLC to check the last integer against the second to last, run a timer while equal, then copy the Ignition counter to the last register. If/when the timer expires, 200ms or so, (broken comms), fill the array with zeros.
- In a client window, create a timer component with a 100ms period. In its actionPerformed method, use system.util.sendMessage() with a specific bit number.
- In the same client window, create a momentary button for that bit and bind its value to the timer componentās enabled property. Do not bind it to any tag.
Create as many timer/PB pairs as needed, up to the capacity of the PLC array (less the last two words), each with their own bit numbers. Use the corresponding bit in the PLC as a reliable normally-open PB.
Any lost messages, lost OPC writes, or Client GUI freezes will yield a zero bit in the PLC.
2 Likes