Which rules belong to which question?
A machine can have beautifully named variables and still injure someone. It can also contain a properly designed safety system and be miserable to maintain. These are different problems. A professional programmer knows which document, discipline, and person can answer each one.
Imagine a small conveyor feeding a guarded cutting station. You have been asked to write its ordinary production sequence. Before opening an editor, draw three boxes: production control, safety functions, and electrical equipment. They interact, but none is a substitute for the others. The production sequence decides when a carton should advance. A safety function addresses a hazardous situation identified by the machine risk assessment. Electrical design addresses matters such as the equipment supplying and controlling that machine. Putting everything in one Boolean expression hides those responsibilities.
This chapter gives you a map, not a declaration that a training program complies with machinery requirements. A browser model is never a safety-rated controller, and passing its exercises does not validate a machine safety function.
Build a standards map before a coding standard
When someone says “follow the standard”, ask which engineering question the standard is meant to answer. A language rule tells you how an expression is defined. A project convention tells a team how to name and organize it. Neither decides whether this machine may restart after a fault clears.
| Question on your desk | Where to look | What you still have to decide |
|---|---|---|
| What does this language construct mean? | The supported IEC 61131-3 edition and target vendor documentation. | Whether the target implements the feature and what its task behavior is. |
| How should the team structure readable software? | An agreed convention informed by PLCopen guidance. | Names, ownership, units, interfaces and a review process for this project. |
| What must happen after a stopped cycle? | The machine behavior and recovery specification. | The physical reconciliation, eligible reset and new-start conditions. |
| What controls an identified hazard? | The machine's safety requirements and applicable engineering standards. | The assessed architecture, implementation and validation. |
The current language publication is IEC 61131-3:2025, edition 4. That does not mean every controller, older training text or browser interpreter supports its whole feature set. Verify target support before selecting instructions. The examples in this book use a deliberately small core; unsupported vendor or advanced language features must not be assumed to run in TryPLC. IEC publication record.
IEC 61131-3 concerns the syntax and semantics of PLC programming languages. It gives us a common language framework; it does not make every program written in Structured Text a safe machine program. PLCopen's introduction to IEC 61131-3 explains that scope.
PLCopen's software construction guidance addresses matters such as naming, comments, coding practices, and program structure. Use it to develop an agreed project convention and review checklist. It is guidance for constructing software, not a machine risk assessment. PLCopen Software Construction Guidelines.
For machinery, other documents address different responsibilities. IEC 60204-1 covers electrical equipment of machines within its stated scope. ISO 13849-1 provides a methodology for designing and integrating safety-related parts of control systems. IEC 62061 addresses the design, integration, and validation of machinery safety-related control systems. Selecting and applying the appropriate requirements needs competent engineering judgment, the actual machine, and applicable local requirements. Consult the current adopted editions and amendments, not an old project folder. IEC 60204-1, ISO 13849-1, IEC 62061.
Keep the resulting project map short enough to use:
| Engineering question | Project evidence | Responsible role |
|---|---|---|
| What hazards exist during operation and intervention? | Machine risk assessment | Assigned machinery safety specialists |
| What must each safety function achieve? | Safety requirements specification | Safety design authority |
| How is electrical equipment designed and verified? | Drawings, calculations, inspection records | Electrical engineering team |
| How is normal sequencing organized? | Functional specification and software design | Controls team |
| How will we prove each requirement? | Verification and validation plans | Assigned reviewers and validators |
The role names vary between organizations. The need for an identified owner does not.
A status bit is information, not the safety function
Suppose the ordinary PLC receives SafetySystemReady. In the production program, this signal may remove permission for a new cycle and drive a diagnostic message. It does not prove that hazardous energy has been controlled. The safety architecture, devices, wiring, diagnostics, software where applicable, and validation establish that function.
For the training conveyor, write the ordinary control contract this way:
If SafetySystemReady becomes false:
withdraw ordinary motion requests;
abandon the current automatic sequence;
show the interrupted product state;
require a separate permitted recovery procedure.
When SafetySystemReady becomes true again:
do not resume automatically;
wait for the defined acknowledgement and new start request.This contract describes production behavior at the interface. It deliberately does not specify safety stopping time, required performance level, safe torque off wiring, or the conditions for entering the guarded area. Those belong to the machine's safety engineering and operating procedures.
Avoid naming an ordinary condition Safe. Names such as ProductionPermission or SafetySystemReadyStatus tell the next person what the value actually represents. The distinction becomes especially important when communications fail: the last received status is not automatically current evidence.
Reset, restart, and recovery are separate decisions
Beginners often use one reset button to clear alarms, restore outputs, and resume the sequence. That is convenient in a demonstration and dangerously ambiguous in a real design.
Give each action a sentence. Acknowledge means the operator has seen the message. Reset means a defined fault latch may clear because its conditions permit that. Restart means a fresh request to perform work. Recovery means establishing a known physical and logical condition after interruption. One button might perform several actions in a particular assessed design, but the software should not accidentally merge them.
Our conveyor has a carton halfway through the cutting station after interruption. Clearing a latch does not tell us where the carton is, whether it was processed, or whether a motion can complete without collision. The recovery instruction needs a product disposition and a verified machine condition. A transition straight back to CUT merely restores a number in memory.
Turn conventions into reviewable rules
A useful local coding standard states decisions that two programmers can apply consistently. For this book's models, use one owner for each actuator request, explicit units in engineering values, enumerated or documented states, and named reasons for inhibited actions. Define task ownership and retained data. Specify what happens when a state value is invalid.
Do not fill the document with preferences that have no practical consequence. Whether a project uses MotorRunRequest or motorRunRequest matters less than whether three routines can write it. Choose a naming style once; spend review time on ownership and behavior.
Record justified exceptions. If a vendor library requires a naming or calling convention, document that boundary rather than wrapping it in confusing aliases simply to satisfy a cosmetic rule. The standard should help readers locate intent.
Try it
A colleague proposes the following comment above an ordinary PLC output:
(* Safety interlock: machine is safe whenever this is FALSE. *)
MotorRun := AutoMode AND StartHeld AND GuardClosed;Write a review note that identifies what can be concluded from the expression, what cannot be concluded, and which documents you need before approving the interface. Then define what should happen to the production sequence when permission disappears and later returns.
Work through the answer
The expression tells us only when this particular software assignment requests the motor to run. It says nothing about another writer, output faults, wiring, contactors, stored energy, stopping distance, sensor integrity, or the assessed safety function. The comment claims more than the code proves.
Request the functional specification, relevant safety requirements and interface definition, electrical drawings, and the assigned validation plan. Ask which subsystem owns guard-related safety behavior and what the ordinary PLC receives from it. Do not solve the uncertainty by adding another AND condition.
For the model, loss of production permission removes ordinary requests and sends the sequence to an interrupted state. Restoration leaves it there. Recovery establishes the carton condition; a fresh start initiates a permitted cycle. This is a clear ordinary-control policy that can be reviewed alongside the actual safety design.
Carry this separation into testing before the machine: tests prove specified behavior within their scope. They do not expand that scope merely because every test is green.