A small-batch production plan is where control work usually goes wrong. On a prototype line the PLC program, the HMI screens and the wiring are all done by the same two or three engineers, so nobody writes anything down. The moment the same line has to be repeated, or handed to a maintenance shift, or re-quoted for a second customer, every undocumented decision becomes a rebuild. The plan below is the set of items we ask our own integration team to lock before the first panel is wired.
1. The machine state model, drawn before any ladder is written
Small batches fail more often on state confusion than on motion faults. Write down every state the machine can sit in — power-off, homing, ready, cycle running, paused, fault, maintenance mode — and state which transitions are allowed. Then decide, on paper, what the HMI shows in each state and who is permitted to leave that state. In our automated production line work we keep this as one page that the electrician, the programmer and the customer all sign; it removes the argument later about whether a guard door should reset a cycle or hold it.
2. An I/O list that carries the HMI address, not just the terminal
A conventional I/O list stops at the wire number. For a small run it should go one column further: the tag name in the PLC and the object the HMI reads or writes. A sensor that only exists in the ladder and never appears on a screen becomes invisible to the operator, and an invisible signal cannot be diagnosed from the front panel. Every field instrument, safety device and axis should appear in that same row with its address, its units and its fault behaviour.
3. Recipe structure and the boundary of operator authority
Small-batch lines change product more often than they change hardware, so the recipe design matters more than the cycle logic. Define the recipe record completely: which parameters are inside it, how many recipes the HMI stores, where the master copy lives, and what happens to a recipe when the HMI loses power. Then fix the authority split — which values an operator may edit on the floor, which are engineer-level, and which are locked at the factory. Getting this wrong is the single most common cause of a batch that ran against the wrong settings and was scrapped after the fact.
4. Alarms as a numbered document
Alarm text should be produced as a table before the screens are built, with a stable number, a plain-language cause, and the recovery action for each entry. Alarms written casually inside the PLC project tend to be vague — a single "fault" bit covering six different problems. On a small batch line staffed by general technicians rather than controls engineers, the alarm text is effectively the maintenance manual. Where a fault requires physical access to the panel, that page belongs in the same document. The checklist then doubles as the exit criteria for factory acceptance, and it is the document an integrated engineering team signs off against.
5. Communication layout and what happens on a link failure
Write the network map: node addresses, which device is master, scan rate for each object, and the timeout each device uses when its partner stops answering. A small-batch line often mixes a newer PLC with an older drive or a third-party vision station, and the failure mode nobody specified is a dropped cable. If the drive keeps running while the PLC has lost it, that is a machine safety issue, not a data issue. Record the intended behaviour for every link loss before commissioning.
6. Safety chain and its interaction with the screens
The safety chain must be defined independently of the HMI. E-stops, guard interlocks and light curtains should stop motion without depending on a screen state, and the HMI should only report why a stop occurred. This sounds obvious and is routinely broken when a customer asks for a "bypass for setup" button. Decide early whether such a function exists, what safety rating it carries, and who is authorised to use it.
7. Version control and the change log
For a batch of six identical machines, the PLC program and the HMI project are as serialised as the hardware. Fix a naming rule for both files, require the program version and build date to display on the HMI diagnostics page, and keep one change log shared by the two projects. Without it, you will be debugging a machine whose screen was updated three weeks ago and whose PLC was not.
8. The commissioning script and the spares list
Write the acceptance sequence as a checklist: cold start, homing, dry cycle, single-piece cycle at reduced speed, full cycle, and a forced-fault pass in which each alarm is actually triggered and confirmed on screen. Alongside it, list the spares that a small run genuinely needs — HMI, PLC CPU, the field instruments most exposed to damage, and the specific cable assemblies rather than cable by the metre. On a batch of a few units, one failed HMI with a six-week lead time stops the whole delivery.
Where PowerDe fits
Shenzhen PowerDe Automation Precision Equipment works on the equipment and integration side of this: customised and non-standard automation equipment, process equipment, and integrated cleaning equipment platforms built as complete machines rather than as parts. The same plan applies to a self-contained unit — its state model, recipe set and alarm table are written before the panel is drawn, and the cleaning equipment series is delivered with that documentation attached.
If the line you are planning is small but the documentation has to survive handover, the practical question is which of those eight items your current plan actually contains. Anything missing is not a paperwork gap; it is work that will be repeated on the shop floor at your cost.
