Technician role in troubleshooting

You can help to troubleshoot by implementing a good alarm/message system (I have seen many package units with only an alarm indicating a problem "PLC FAILURE") and asking for well documented applications (software and hardware, good tag naming, etc) and if you feel more comfortable by using a particular programming language (because it's used in other parts in your plant or you have staff able to understand it) go for it if reasonable. Maybe a batch sequence could be better implemented and understood by using GRAFCET better than Function Blocks and if you don't know GRAFCET, you'll need to learn it.

About HMI, I've seen many times that engineering ask us to completely replicate in detail in an operation graphics the interlock implemented in a SIS. When an unexpected trip happened, nobody knows how it works the S-R flip flop they had in front or many doubts appears about AND and OR logic function. So, it's obvious they need some training, they need to know that outside there a lot of things that probably will fail before the code/function block/ladder in the control system, usually they quickly discard the problem on field and go to the code.

If the problems requires it, your technician must dig into your code in order to solve the problem. The question is, who and to where? If a pump doesn't start, probably your field operator is able to do some basic checking and solve a % of the problems if not, they ask help to the specialist (electrician, instruments, mechanical, control if an interlock is involved). With control system is the same: if you have a good alarm system it will warn you if the problem is related to a condition in the process (i.e. you have not reached enough temperature for your next step in the process) or a breakdown (i.e. instrument failure) if not, and you receive a bizarre error code or random behaviour, you will need to call to the specialist.