With serial communications the only thing I can think of that would be causing the PLC to miss the turn-off would be that the message to write the zero is getting lost. One thing that could cause that is if the PanelMate has to generate such a large number of read and write requests that occasionally a buffer overflows and some data requests get lost.
A PanelMate (and most other HMIs) will request from the PLC whatever data it needs to keep the displayed screen updated. It will also request from the PLC whatever it needs to update any alarms that have been defined.
If the person who designed the screens for this application was careful, he minimized the communications overhead by placing all the data that the PanelMate needs in consecutive addresses in the PLC. All too often application designers dont bother.
If one screen has a mixture of I, O, B3, and N7 addresses, that's a minimum of four transactions to refresh it. One read request for each memory type. If the addresses are widely separated, each memory type might required multiple read transactions. If there are a lot of alarms defined, that gets added to the burden. Too often, I see applications where just about every tag has alarm conditions attached to it. It seems like the designer figured it's better to have an alarm and not need it than to need an alrm and not have it. It aint necessarily so.
In short, if you take a closer look at the application, you may find that there are some things you can do to minimize the chances of stuck pushbuttons.