This depends on what is being changed and why. If it is timers counters and integers, then just maybe there is a difference in production set up between shifts. If logic is being changed, then you should look closely at the changes, and determine why the change might have been made.
I'm not sure I'd want to write code that would deliberately fault a processor. There are way to many safety issues, not to mention production issues involved. Teamwork is by far the best approach.
I've seen changes made to cover for a limit switch in a bad location, or a sensor that is not in stock. These changes should raise flags on your part, to solve a greater problem, not to start a tiff with maintenance.
Finally, I have seen very few perfect programs. I have seen great programs that functioned better than 99% of the time, but the less than 1% error caused great grief. Nagging minor issues can mean real production loss over a shift. Many control techs tend to look for problems with mechanicals, production and anywhere else before looking at the controls. I tend to doubt my controls and look for a better solution. Even if the program functions fine under normal conditions, try to remember that normal conditions are only temporary, and good controls can handle many out of the norm conditions.
I don't like using passwords, but have. I have also written code to change variables back to a known set of good numbers. I have even written code to change as operators change, much the same way you would change for different products. I have also seen other tricks to preserve a set of variables. This sould be the last resort.
