A PLC program is written once and modified for years. Best practices aim for whoever comes later to understand it: structure by equipment and reusable blocks, consistent names, a safe state on fault, defined operating modes, useful comments, and versioned backups.
Short answer
A PLC program is written once and modified for years, almost always by people other than its author and under production pressure. Best practices have a single goal: that whoever opens it at three in the morning with a machine down understands what is happening and what can be touched without risk. They come down to structure, names, faults, modes, documentation, and change control. These are general engineering criteria, applicable to any brand and to any of the IEC 61131-3 languages. Structured Text syntax (IF, CASE, FOR) and examples are in Structured Text (ST) for PLCs.
1. Structure: from general to specific
A readable program has layers:
| Layer | Content | Common language |
|---|---|---|
| Inputs and outputs | Reading field signals, filtering, and scaling; writing outputs | Ladder or text |
| Equipment | One function block per equipment type (motor, valve, pump, transmitter) | Text, blocks, or ladder |
| Sequences | Process states and transitions | SFC or CASE |
| Modes and operational safety | Manual, automatic, maintenance, stop, and restart | Text or ladder |
| Communications | Exchange with HMI, SCADA, and other PLCs | Manufacturer blocks |
Separating signal reading from the logic keeps a terminal change from forcing you to touch ten places: you modify the input layer and the rest stays the same. And putting output writing in a single place prevents two parts of the program from fighting over the same output.
2. One block per equipment type
A motor’s logic always has the same parts: start command, stop, protection, contactor feedback, supervision time, alarm, and status. It is written once as a function block (see function block diagram), and each motor in the plant is an instance. The advantages are concrete: a correction is made once, the tests are done once, and the HMI and SCADA reuse the same data set (addressing and data types).
Illustrative example: the 15 kW motor block
Assumed data: 15 kW, 400 V motor, rated current on the order of 28 A, contactor with an auxiliary feedback contact.
| Block element | Description |
|---|---|
| Inputs | Start, stop, overload healthy, contactor feedback, automatic/manual mode, measured current |
| Outputs | Command to the contactor, motor running, fault, warning |
| Internal logic | Start seal-in, lockout on fault, feedback supervision |
| Discrepancy fault | Command active without feedback, after an assumed time of 1 s |
| Overcurrent warning | Measured current above a configurable percentage of rated |
| Status | Stopped, starting, running, faulted |
With this block, an MCC of forty motors is forty instances with their parameters. Low-voltage motor protection stays in its own device; the block only monitors and signals.
3. Names and conventions
- A name says what it is and where it is:
P101_START, notM23. - The same convention in the program, schematic, HMI, and cable list.
- Uniform uppercase, lowercase, and separators.
- Prefixes that indicate type (input, output, parameter, state) if the environment does not show it.
- Avoid abbreviations only the author knows.
4. Faults: designing the safe path
Each piece of equipment must have a defined response to a fault and the state it takes:
- Stop inputs and protections normally closed, so that a broken wire shows up as a trip (see ladder).
- Feedback on every command: the contactor closed or the actuator reached its position; if not, a fault is declared after a time.
- Analog signals with a range: below the minimum valid value, broken wire; the value is flagged invalid instead of being used.
- Output state on PLC stop, decided by process.
- Communication failure with equipment that governs critical variables: safe value or last valid value, with an alarm.
- Manual reset after a major fault: the machine does not continue on its own.
Personnel protection is not solved in a standard program; it is solved with safety circuits and devices that comply with the applicable standards.
5. Operating modes
Manual, automatic, maintenance, and local usually coexist. You must define who is in charge in each mode, which interlocks remain active in manual (almost all the protection ones), and how to move from one mode to another bumplessly. A field selector that contradicts the program without the program knowing is a classic cause of accidents and confusion.
6. Comments and documentation
Comment the purpose, the decisions, and the assumptions: “waits until the level exceeds the limit because the sensor oscillates while filling”. Deliver with the program:
- a signal list with address, symbol, description, and drawing;
- a functional description of each sequence and mode;
- a cause-and-effect matrix for alarms and trips;
- a communications diagram and data maps;
- a record of settings (times, limits, scales).
That documentation is also what client and quality audits ask for. See substation SCADA and HMI for the supervision side.
7. Change control and backups
- Program backup before each modification, with date and version.
- Change log: what, who, when, why.
- The program in the controller matches the official backup; it is compared before and after.
- Copies outside the equipment, in a protected place.
- Access to the controller with a password and per-person accounts, as part of industrial cybersecurity.
- Forces are logged and removed.
Reviewing a program before commissioning
A program is reviewed the way a drawing is reviewed. A peer review, with a short list, catches most defects before energizing:
| Aspect | Review question |
|---|---|
| Outputs | Is each one written in a single place? |
| Safety | Do protections and stops depend on hardwired normally closed contacts? |
| Faults | What does each piece of equipment do on lost signal, communication down, or missing feedback? |
| Startup | What happens when power returns and when going from stop to run? |
| Times | Do the values correspond to process measurements? |
| Modes | Which interlocks remain active in manual? |
| Data | Do the types and ranges hold the maximum possible value? |
| Documentation | Does the program match the signal list and the drawings? |
The review is recorded, and closed observations remain as evidence. In projects with an audited client, that record is part of the control system file.
When to refactor
A program that has been in service for years accumulates patches. It is worth tidying when a simple modification forces you to touch many places, when nobody dares to change a part, or when faults repeat from the same cause. Refactoring is done in parts, with a prior backup, tests before and after, and during a planned outage. First the repeated logic is extracted into blocks, then names are unified, and finally dead logic is cleaned out. A program that can be tidied without changing its behavior is a sign that it was well structured from the start.
Common mistakes
- A single giant program with no structure.
- Logic copied and pasted per piece of equipment, with small differences.
- Outputs written in several places.
- Magic numbers instead of named constants.
- No feedback supervision, and faults discovered through the process.
- Modifying the program online without a backup.
- Comments that repeat the code or that went out of date.
- Forgotten forces.
- Shared passwords or ones unchanged since installation.
- Documentation that does not match the program in service.
Checklist
- Layered program, with a single write per output.
- Function blocks per equipment type.
- Naming convention written and applied.
- Safe state defined for each piece of equipment and for PLC stop.
- Supervision of feedback and analog signals.
- Operating modes defined and tested.
- Signal list, functional description, and cause-and-effect matrix up to date.
- Versioned backup and change log.
- Passwords and accounts managed.
- Fault tests documented.
Frequently asked technical questions
- How long should the supervision time be? It depends on the equipment: its real response time is measured in the field and a margin is set over that value.
- Can the same blocks be used in different projects? Yes, with a versioned, tested library of your own.
- Is a programming standard necessary? It is advisable to have one per company or per project, even if brief.
- How is a new block tested? In simulation, with all its fault cases, before using it in the field; see PLC simulation and tools.
How we help
A well-structured, well-documented program makes commissioning shorter and audits easier. At Tiza Group we do the control engineering, prepare the test protocols, and leave the system ready to operate with traceable documentation. See engineering design and studies and testing and commissioning, or write to us through contact.
Related guides
- IEC 62443 in substations
- Interlocking: mechanical and electrical
- PLC brand equivalents: concepts and names
- Intelligent MCC: CENTERLINE 2100, SIVACON S8, MNS, Okken
- PLCs in Substations: Uses, IEC 61131-3 and Testing
References
- IEC 61131-3, program structure (paid standard).
- Hugh Jack, Automating Manufacturing Systems with PLCs (CC BY-NC-SA 3.0 US).
- Siemens SCE, training documents (account required).
- PLCopen, style guides and best practices.
Frequently asked questions
Why structure the program in blocks per piece of equipment?
Because the logic of a motor, a valve, or a pump is written and tested once, and reused for every piece of equipment. It is corrected in one place and applied to all, and the program grows without becoming a single unmanageable block.
How many comments should a program have?
Those that explain the purpose and the decisions, not those that repeat what the code already says. A useful comment answers why it was done that way or what process condition requires it.
How are changes documented in a program in service?
With a change log (date, author, reason, version), a backup of the program before each modification, and an update of the drawings and the signal list. It is also an audit requirement.
Is forcing inputs or outputs bad practice?
Forcing is useful for controlled tests, but a force forgotten in service is a risk, because the program stops following the real signal. It is logged, authorized, and removed when finished.