Good vs bad PLC programming

A PLC program is written once and read hundreds of times: during commissioning, at every breakdown and with every change, often in the middle of the night with the line stopped. That is why a good program is not just one that works, but one that any technician can understand and troubleshoot quickly. The difference between a good programmer and a bad one is hardly ever about knowing obscure instructions: it is about order, names, alarms and respect for whoever comes next.

What sets them apart

Structure: everything in its place

OB1 should read like a table of contents: it calls the blocks for each part of the machine in a logical order. A common structure:

• Blocks by station or by function: whoever is looking for a fault in the gripping station knows where to look.
• One block per type of equipment: a “Motor” FB with its start, stop, overload relay and alarms, called once for each motor. If it is improved, they are all improved.
• Sequences with steps: each step of the machine is a numbered step with its condition to move on. The current step is shown on the HMI, so the operator or the technician can see at once which step the machine is stuck in.

Names and comments

A well-chosen name saves a comment. Simple rules that work:

• Say what it is and where: Conveyor2_Infeed_Sensor rather than S12.
• For logic states, a name that answers yes or no: Gripper_Closed, Door_Closed.
• Put units on quantities: Pressure_bar, Blow_Time_ms.
• Be consistent: the same language and the same style throughout the program.

Comments should explain the why, not repeat what is already visible. “Turns the output on” adds nothing; “Wait 500 ms so the gripper finishes closing before lifting” does.

Alarms that help

The alarm is the first thing the technician sees when the machine stops. A good alarm says what happened, where, and what to check: “Station 2 gripper not closed within 2 s: check sensor B23 and air pressure”.

The key tool is motion monitoring: every time a movement is commanded, a timer checks that the end-position sensor arrives in time. If it does not, a specific alarm is raised instead of the machine sitting there waiting with no explanation:

// The gripper must close in less than 2 s
#T_Close(IN := "Gripper_Close" AND NOT "Gripper_Closed", PT := T#2s);
IF #T_Close.Q THEN
    "Alarm_Gripper_Not_Closing" := TRUE;
END_IF;

It also helps to record which was the first alarm: when something fails, others usually follow, and the one that matters is the first.

Parameters without magic numbers

A “3000” in the middle of the program says nothing: milliseconds? parts? revolutions? Times, setpoints and limits go in a parameter data block, with a name, units and a comment. That way they are adjusted in one place, even from the HMI, without touching the logic.

Operating modes and start-up

• Clear modes: manual (each movement on its own, with its logic interlocks) and automatic (the full sequence). Changing mode must be safe and predictable.
• Home position: before starting in automatic, the machine checks that it is in its home position, or takes it there with a homing cycle.
• After a power cut, the machine does not start by itself. Starting is always a deliberate action by the operator.
• Safety does not depend on the standard program: emergency stops, doors and light curtains are handled by safety circuits or safety PLCs. The standard program monitors them to show messages and stop in an orderly way, but it does not replace them.

Respect the scan cycle

A good programmer does not wait inside loops, does not write the same output in two places, uses edges where they are needed and gives each timer and each edge its own memory. These are the mistakes you already saw in the scan cycle topic, and they are the ones that waste the most time during commissioning.

Versions and changes

• Save a copy of the project before and after every change, with the date and a description of what was changed and why.
• Online changes with the machine running are made carefully, tested and written down. “I’ll leave it like this for now” ends up being permanent.
• Before touching anything, compare the program in the PLC with the one on the computer: if they do not match, someone has made changes without saving them to the project.

Test before you get to the machine

With a PLC simulator, such as PLCSIM for Siemens, a good part of the logic can be tested in the office: sequences, alarms and fault cases. Every bug found in the office is one hour less of machine downtime during commissioning.

Mistakes that give away a bad programmer

• Variables with no names, or names that say nothing.
• A single “general fault” alarm.
• Movements without time monitoring: the machine just stands there without saying why.
• Code copied and pasted for each piece of equipment, with small differences nobody remembers.
• Magic numbers scattered through the program.
• Safety handled only by the standard program.
• Changes with no backup and no record.

Summary

• A program is written so that someone else can understand it and troubleshoot it quickly.
• Structure by function and station; reusable blocks with one instance per piece of equipment.
• Names that say what each thing is, with units; comments that explain the why.
• Specific alarms, with time monitoring of every movement.
• Named parameters in a data block, not loose numbers.
• Backups and a record of every change, and simulation tests before commissioning.

Test what you have learned

34 practical questions with explained answers. Free, no sign-up.

Start the test