When a machine builder or plant engineer signs off on an automated cell, the PLC program and the HMI screens are usually demonstrated together in a short walkthrough. Everything moves, a button is pressed, a screen responds, and the equipment looks finished. What that walkthrough does not show is what happens after eight hours of production, after a network cable is pulled, or after an operator touches a screen during a fault. A structured test that records data while the PLC and the HMI are exercised together is what turns a working demo into equipment you can accept, and later defend if something misbehaves in the field.
This guide lists the data to capture during integration testing of a PLC and HMI system, using the categories an equipment supplier and a buyer can both agree on before the equipment leaves the workshop.
Before the test: the reference data you record once
Most disputed acceptance results come from not having the baseline written down. Collect and date-stamp the following before any functional test begins, so every later result is measured against a fixed reference instead of a memory.
- PLC model, firmware version, HMI model and runtime version, and the communication path between them (integrated port, fieldbus, or industrial Ethernet)
- The tag list or variable table, with the unit for each value, so a screen reading is traceable to one PLC address rather than to a display format
- I/O assignment sheet, including which inputs are safety-related and which are information only
- The functional description or sequence chart for each machine mode, and the alarm list with the intended cause text
- Machine setpoints that matter to production: cycle time, pressure, temperature, flow, and position values taken from the design requirements rather than from what the machine happens to do on the day
If you are buying automation from a supplier, ask for these as deliverables in the order. Suppliers that build the control design in-house hand them over as part of the project; manufacturing automation services that include mechanical, electrical and control design normally produce the electrical schematic, the PLC and HMI program and the test report in one package, which removes the version mismatch that appears when control programming is split across three contractors.
1. Control function data: every command, one direction at a time
For each HMI control element, record the command sent, the PLC response time, and the resulting output state. Test the command from the HMI, then from the local control station if one exists, then from the maintenance screen. Differences between those three paths are common and are usually found only when the same command is repeated from each place.
Write down, for each function: the operator action, the expected machine behaviour, the observed behaviour, and the time between the screen press and the output changing. Where an actuator has travel time, note the nominal value separately from the measured one, so a slow valve is not confused with a slow communication path.
2. Interlock and safety data: prove what must not happen
Functional testing proves that the machine does what it should. Interlock testing proves that it refuses what it should not. Record one row per interlock, not one row per machine function.
For each guard input, light curtain, pressure switch, level switch and emergency stop, capture the trigger method, whether the machine stopped, whether the HMI displayed a message, whether the message named the real cause, and whether the machine could restart without a deliberate reset. Also record the state of any device that must stay de-energised while the interlock is active.
Test the same interlock from the HMI with a bypass or maintenance screen if one exists, and record whether the bypass is visible to the operator and whether it is logged. This is the single most useful line of data for later troubleshooting, because a hidden bypass is invisible in normal production and only appears when a fault occurs on the customer's line.
3. Process value data: what the HMI displays versus what the PLC holds
Place a test instrument or a reference gauge at the measurement point and compare three numbers for each critical value: the reference reading, the value in the PLC register, and the value on the HMI. Record the deviation for each, and the units at each stage.
For equipment with heated or pressurised circuits, this comparison matters most, because scaling errors and unit-conversion errors in the HMI picture can look plausible on screen while the PLC is controlling to a different number. Check each value at three points in its range: low, working setpoint, and near the upper limit. Then check the alarm threshold: raise the value in a controlled way and record the value at which the PLC alarm fires and the value the HMI reports at that instant.
Where a machine specification is published to a buyer, keep the accepted value from this test in the same document as the acceptance record, so the figure quoted later matches the figure measured. If a supplier's product page and its parameter section name or number a value differently, do not lock in that number in your own documents until the supplier confirms which one the control system actually uses.
4. HMI feedback and response data
Operators judge the machine by the screen, so measure the screen as a machine part. For each important screen, record the time to open it, the time for displayed values to refresh after they change in the PLC, and the time for a button press to be accepted.
Then record the negative cases: what the screen shows when a command is rejected, whether a pressed button gives any confirmation at all, whether an out-of-range setpoint can be entered, and whether the language, units and text on each screen match the operator's actual site. For an HMI that will be used with gloves or in a wet area, note whether small touch targets and long text strings are readable and pressable in the real installation position.
5. Alarm and event data: one record per event, with time
Force each alarm, one by one, and record: the condition you created, whether the PLC logged it, whether the HMI displayed it, whether the text identified the cause or only the symptom, whether the alarm time-stamped correctly, and what the machine did as a result. Then clear the alarm and record whether the machine returned to the correct state or lost its position, counters or recipe.
For any machine that will be handed to production staff, ask for the alarm list to be exported as part of the delivery. A list you can search is worth far more during a night-shift fault than screenshots of screens.
6. Communication and power-loss data
These are the tests most often skipped because they are awkward, and they are the ones that produce the most confusing field failures. For each, record the PLC behaviour and the HMI behaviour separately:
- Break the communication link for a few seconds: does the HMI show that data is stale, or does it keep showing the last value as if it were live?
- Restore the link: does the HMI resume automatically, and are values and alarms correct afterwards?
- Power down the HMI while the PLC keeps running: does the machine keep running, and does it stop if the design says it should?
- Power down the whole panel and restore it: which values survive (retentive data, recipes, counters, maintenance counters), and does the machine return to a safe state rather than mid-cycle?
The power-loss rows are also where you confirm the machine state an operator inherits on the next shift, which is a frequent source of scrapped batches.
7. Recipe, mode and permission data
If the machine holds recipes or parameter sets, record what is stored in them, who can write to them, and what happens when a recipe is loaded mid-cycle. Test that an operator-level login cannot change a maintenance parameter, and record whether every parameter change is recorded with a user level and time. For a machine that several shifts operate, an unlogged parameter change is the reason faults cannot be traced to a cause later.
8. Continuous-run data: the category that catches most integration faults
Run the machine through repeated cycles and record cycle time, any stop, any alarm, and any HMI hang over the whole period rather than on one cycle. Watch for values that drift, screens that become slow to respond after hours of operation, memory or buffer errors, and faults that only appear at a specific point in the sequence.
Repeated start-stop testing belongs in the same pass, because faults in state transitions show up only when the machine is cycled rather than run continuously. This is the category that maps directly to hardware testing for automation equipment, where the control layer is checked as part of the whole machine: PLC and HMI function, sensors and actuators, safety interlocks, continuous operation, and the factory test plan that production staff can repeat after delivery.
9. Traceability data: so a later fault can be traced back
Alongside the measurements, keep the paperwork that lets you reconstruct the test. Record the program version actually running during the test, not the version intended to be running; the same applies to the HMI project file and any sensor or drive configuration. Log every change made during commissioning with date, reason and who made it, and record which tests were repeated after each change.
Ask for the deliverables as a set: the test plan, the record forms, the problem list with causes and retest confirmation, and the pass or fail criteria for each test item. A supplier that only hands over a program and a machine gives you no way to prove a later fault was not caused by an undocumented change.
What to hand over to the production team
Integration testing is finished when the people running the machine can act on the results without the commissioning engineer. The handover set should include the alarm list with cause and first action for each alarm, the pass or fail limits for the values that matter to quality, the accepted cycle time, the factory or acceptance test items your own team can repeat, and the contact route for a control fault. If the buyer is also validating a prototype or a machine that came from a design change, a supplier who can run the tests and then adjust the control logic closes the loop instead of leaving a problem list sitting unresolved.
A short checklist before you sign the acceptance sheet
- Reference values and program versions recorded before testing, with dates
- Each interlock tested individually, with HMI message and restart behaviour recorded
- Critical values compared at three points in range across gauge, PLC and HMI
- Alarm thresholds triggered, and the value at which each fires recorded
- Communication loss, HMI power loss and total power loss tested, with recovery behaviour recorded
- Recipe, permission and parameter-change logging checked
- Continuous-run and repeated start-stop results kept as full-period records, not single cycles
- Test plan, record forms, problem list and acceptance criteria delivered as documents
If you need the control layer verified as part of the whole machine rather than on its own, or you are preparing a prototype or a modified machine for small-batch production, send us the machine description, the current control setup and the faults you are most worried about, and we will propose the test items, the record forms and the acceptance criteria to go with them.
