RX3I Ghost Rung Occurence - Possible Corruption?

Hi everyone, had an odd occurence happen and wondering if its ever happened to anyone else in their field. Programming a GE RX3I with Quickpanel+. There is a stop button on the HMI tied to a momentary memory bit %M419. This stop button triggers multiple rung breaks and system stops throughout the program. It has been working fine for weeks. I recently added a new output to an area of the program and downloaded it touching no other pre-existing areas and suddenly when I press the stop button, it works in a few areas of the code and just refuses to read in other rungs. I can literally press the button and watch and certain rungs show the %M419 momentary input activate and the others just do not see it.

If I program a bypass in another area or overwrite that stop area, things read just fine, put it back...it does not work. I'm starting to wonder if memory corruption is a real situation here or not. Especially considering I did not change any of the original calls or stop functions...just downloaded a new edit elsewhere for myself and suddenly some rungs do not see the button activation (or pressing of it), and others do. Anyone ever witnessed anything like it?

I would hate to have to rewrite due to corruption...but starting to think this may be the case. Perhaps wiping the CPU memory entirely and a fresh download is possibly worthwhile.

First guess is somewhere between the existing code and your new check there is an UNLATCH of the stop bit from the HMI. That is commonly done even with momentary PB's on a HMI in case it gets 'stuck'

What I would do is in the beginning of the program check if the Stop PB is pressed and have it turn on another memory bit, then use that bit for your code later.

+1 what Aabeck said about unlatching bits set by the HMI.
Are there any program blocks that don't get called when %M419 is true?
Are there any WORD or INT variables addressed to either %M408 or %416 or DWORD, DINT, or REAL variables addressed to %M392, %M400, %M408, or %M416? Moving a zero into any of those would turn %M419 off.
My experience with memory corruption is that when it occurs, the PLC goes into a fault state and the program stops.

It look clear to me
"HMI tied to a momentary memory bit %M419"
M419 is resetting before the ladder scan is complete
in most HMI's a momentary button will automatically reset a bit after a given delay check the manual for the details.
change the HMI stop button to a latched bit
Stop buttons should be latched anyway and reset when the start button is activated

Thanks for the advice. I'll be back at it tomorrow morning. I'll run through the variable list to see if there are any doubles or expanded memory areas that are potentially causes for an overwrite or different state.

I have been having to rewrite many areas of this program from the start as much of it was not proper. I did not agree with the stop button being momentary either, feels safer as a latch as Gary pointed out. Will probably go in early tomorrow and rewrite the stop areas as a latch resetting with a system start or system ready latch.

Good to know memory corruption would possibly shut it down as well, does not seem to be the case if still running without diagnostic issues or shut down. Should be able to work it out tomorrow but if anything really odd continues to happen, I'll let you guys know my findings. Thank you!

As a closing follow up for others, there were no memory overlaps or extended data types interfering. The momentary blinking as the program grew in scan time as Gary eluded to seems to have been the suspect issue.

I reprogrammed the system stop to a latch as it should be and all is well. This ended up requiring an entire restructuring of manual operations due to how they used the system stop but it was designed wrong from the get go in my opinion. Everything is up and running with all the proper interlocks and safety features it should have between JOG, manual, and automatic functions. Good times on the horizons!

Thanks for getting back to us on this to many time we never hear back and are always wondering about it

I find it odd that a momentary HMI PB would be on at the beginning of a scan, but not later in the scan. Sometimes it should turn ON mid-scan if it wrote directly to the tag.

Also, the momentary ON time would have to be shorter than the scan time of the program. Since scan times can be 0.02 or less that would be a very short duration, and if the scan time is the normally default momentary ON time of .500 second it should be on for 15 to 20 scans at least.

I am not saying the Stop PB should have been momentary, just about timing of one.