So, this is an odd one. I got called out to look at a KRC2 system (KSS 5.6.8) running PalletTech 3.5.3, which began smashing into obstructions in the work cell without warning. Since this system has run for years without many issues, this was odd to say the least. The collision was consistent -- that is, resetting the robot and re-starting from home would result in the robot running off path and colliding with the same obstruction, the same way, every time.
This problem was resolved by doing a Restore All of a known good archive. This means that lost mastering, or mechanical issues, are very unlikely to be the root cause. And the programs in this robot have not been modified for years.
So, the obvious answer would appear to be that someone altered one (or more) of the Palletizing positions. But video surveillance of the area reveals that no one went near the teach pendant near the time the robot started colliding. And it was running perfectly immediately before -- there was no shift change, or plant blackout, or anything else, in between.
This has happened a few times over the past 6 months, and each time, doing a Restore All has fixed the problem. But the easy answer (someone tampering with the program positions) seems to be ruled out by the video surveillance evidence.
Now, I don't have any hands-on experience with PalletTech, so I'm wondering if there are any "remote" exploits for altering the palletizing positions on the fly? It looks like PalletEdit is purely for offline use, and this robot isn't on a computer network, so I don't see how any remote edits on the C:\PATTERNS directory would be feasible (as an aside, if one of these files was altered, would the robot have to be rebooted to get the change to take effect, or would it be immediate?). And I'm not finding any code in the robot backup that would allow the cell PLC to remotely adjust the palletizing positions during production.
So, all the "easy" answers are pretty much ruled out. But it's hard to imagine a file corruption issue that would only affect the palletizing positions in the robot, and not cause other faults (compilation errors, boot failures, etc). Anyone got an idea that I've overlooked?