Try checking the system variable $BACKGROUND
Bummer. I found that same thread, so made the suggestion.
Do you have 2 robots of a similar model?
A trick I use sometimes to find System Variables is using a comparison software (I use WinMerge) to compare ASCII backups of a Sysvars.sv (Sysvars.va is the ascii version). look for the differences, and maybe get lucky finding the Variable.
I had something like this happen on a job years ago. There was a double mapped bit on the DOs and the UOs. The DO wanted the bit low, but the UO wanted it high. The UO bit was "program running". UO almost always 'won'. However, going into background edit was enough to make the UO hickup for a few scans, and then DO would force the bit low, and then the PLC would promptly abort the program, since it thought the robot aborted.
Its a long shot, but look for double mapped bits to the UOPs.
Yep. Normally that is fine, as long as you don't use DO[1-20] for anything. If you try to set a DO, the UOs will set it back, and when you have two tasks fighting for control, and the PLC monitoring those bits, what I detailed in my previous post can happen.
Still unclear, what the background edit has with holding the running program execution.
