Use automation tools to observe and prove conditions, not to experiment on production code.
What to understand
The first maintenance skill in a PLC is not programming. It is navigating safely: finding the controller, identifying online/offline status, viewing inputs/outputs, and understanding the sequence around the fault.
Start by turning the idea into an observable question. What should the machine, component, person, or process be doing at this moment, and what evidence would prove that it is doing it? Defining normal first gives your troubleshooting a reference point and prevents you from reacting to the first unusual thing you notice.
How to apply it
Use the HMI alarm history and PLC state as evidence. Compare the physical machine to the logical conditions instead of assuming one side is correct.
Apply the idea one boundary at a time. Confirm one condition, record what you learned, and only then move to the next point in the chain. This makes your work easier to explain and greatly reduces the temptation to swap parts or change several variables at once.
What good work looks like
Online edits, forces, bypasses, and downloaded programs can create serious risk. Follow the site’s authorization and backup process exactly.
Good maintenance work leaves a trail of evidence. Measurements, alarm times, verified states, photos where permitted, and clear work-order notes let another technician understand why you made the repair and whether the same failure mechanism returns later.
Field scenario
A machine will not cycle after a guard is closed. The PLC shows the guard input true, but a “reset required” memory bit is still false because the reset button has not been pressed after the safety circuit was restored. No hardware is failed; you simply learn the intended restart sequence.
After the immediate repair, capture the point in the sequence where the expected condition was lost and what evidence proved the cause. That small discipline turns a one-time fix into knowledge the whole maintenance team can reuse.
Field checklist
Common mistakes to avoid
Downloading the wrong project to a controller
Clearing faults before recording them
Assuming an HMI message is the root cause
Using forces as a permanent repair
Ask yourself: If this machine failed again on the next shift, what information could I leave behind that would make the next diagnosis faster and safer?
90-day action
Before moving on, choose one task from this chapter and perform it during normal work. Record what you learned in your plant notebook. The value of the first 90 days comes from turning concepts into repeatable behavior, not from reading alone.
CHAPTER 14