A request to customise a control package rarely arrives as a list of hardware changes. It usually arrives as an operating complaint: an operator cannot follow the sequence, a maintenance technician cannot find a fault without opening the cabinet, a changeover takes longer than it should, an interlock has been bypassed because the machine will not restart otherwise, a recipe is re-entered at every shift because nothing holds it. Each of those complaints lands somewhere specific in the design of the programmable logic controller, usually shortened to PLC, and of the human machine interface, usually shortened to HMI, and each one pushes that design in a different direction. The result is that customization does not add screens to a control system; it changes how the inputs are arranged, how faults are described, where the operator is allowed to intervene, and how the machine can be stopped and restarted safely.
This article looks at what a buyer should expect a PLC and HMI package to absorb when the machine is customised, using the control layer as it appears on this site: a PLC paired with an HMI as one designed package, delivered together with automation lines, non-standard equipment and engineering services.
Customisation starts in the machine, not on the screen
Before any design question about screens can be answered, the physical changes have to be written down. Customisation on real projects usually takes one of the following forms, and each one has a different consequence for the control package:
A new station or module bolted onto an existing cell adds devices that were not in the original input and output plan. The design question is whether the new module is treated as part of the existing sequence, so the operator sees one flow with more steps, or as a separate unit with its own start and stop, its own faults and its own screen. Both are workable. Choosing the wrong one produces a machine that an operator can only run by remembering which part is which.
A change to the product being handled changes what the machine must detect and reject, which sensors are trusted, and which dimensions are worth measuring and displaying. A product change that only alters the tooling still changes the control design, because the conditions under which the machine declares a good part have moved.
A change to the shift pattern or the staffing changes who is allowed to clear a fault, who may change a setting, and whether the machine needs to be operable by someone who has never seen it before. A machine run by its designer needs a very different set of screens from a machine run by rotating operators across three shifts. The first fact a control design needs is therefore the staffing one, and on a customization enquiry it is the fact most often left unstated.
A change to the surrounding line or to the upstream and downstream equipment changes handshaking, the conditions for a ready signal, and what the machine does when the neighbour stops. This is the category most often under-specified, because the physical interface is obvious and the signal agreement is not.
A new record-keeping or traceability demand rarely changes the mechanics at all, and almost always changes the control package more than any mechanical change, because it decides what the machine must store, what has to be entered by a person, and what has to be handed off to another system.
A buyer who sends only a mechanical drawing with a customisation request answers the first question and none of the others. The control design follows from the operating facts.
How the control layer is built: one designed package, and where it does not belong
The automated production line solutions section presents the control layer as a PLC and an HMI designed as one package, and lists automation lines and the factory-scale line solution shown on that page. The PLC is the part that holds the sequence and the interlocks; the HMI is the part that presents states, prompts and settings to a person. They are quoted and delivered together because a screen can only display what the program is written to know, and a program's structure is judged by the people who have to stand in front of it. The non-standard equipment listing sits alongside it, and that is where most customization work of this kind actually begins. The same order of work applies on the product development side: a development enquiry settles what the equipment should do first, and the control package is one of its later outputs, whereas a customization enquiry on a machine that already exists starts from a settled sequence and works out what has to change in it. Confusing the two produces a control package specified before the process has been decided, which is the most expensive order in which these jobs can be done. Either way the pair is designed and quoted as one item, and a buyer should expect the proposal to say so.
It is worth being equally clear about where this pair does not belong. A control package does not decide what the machine does to the product; it executes a process that has been settled somewhere else, on the machine itself and in the process trial that preceded it. That distinction matters for non-standard equipment in particular, and it is the single point at which integration design and a customization decision part company. On custom-built equipment the process is often new to everyone involved. If the process has not been proven on the actual material, a control package can be built to a design that will have to be rewritten, because the sequence it faithfully runs is the sequence nobody intended. Customisation of the control layer should follow the point at which the process itself is fixed, and a project schedule should say so explicitly.
How customisation changes the structure of the program
The first thing customisation affects is not a feature, it is the arrangement of the program. A few decisions carry most of the consequences.
Modes, and how many of them the machine really needs. Manual, semi-automatic, automatic, setup, cleaning, maintenance and jog are not decorative options. Each mode is a different permission set: what may be commanded, what is interlocked out, and what the screen is allowed to show. Every customisation that adds an operating situation asks whether it is a mode or a step inside an existing mode. Add modes carelessly and the machine ends up with six modes that overlap, and no operator can predict which one it is in.
States, and the words the site will use for them. A machine that is stopped, a machine that is idle, a machine that is paused at a handoff and a machine that is faulted are four different conditions, and an operator who is shown one word for all four will not be able to describe a problem on the telephone. Customised sequences make this worse, because more intermediate conditions exist. The design decision is how many state names the machine publishes and what each one means; that vocabulary then has to appear on every screen, in every manual and in the support line.
Interlocks, and who may override them. A customisation that removes a guard, moves a sensor or changes an access route usually changes an interlock. The design question is never only whether the interlock stays; it is what the machine does when the interlock is true while a cycle is already running, and whether the machine offers a sanctioned way through the situation. A machine that offers no sanctioned route gets one improvised by the operator.
Recipes, and what counts as a parameter. Customising for a family of products usually means recipe handling: a set of settings stored under a name and recalled together. Two design decisions follow, and both are commonly decided late. First, what belongs inside a recipe, and what stays as a machine-level setting that no recipe may change. Second, who is allowed to write to a recipe, and whether the machine keeps the previous version of a recipe it accepted. Both decisions are cheap to settle at the design stage and expensive to retrofit, because they involve access levels on the screen as well as the program.
Recovery. A machine that has stopped mid-cycle has to decide what it does next. Some customised processes can resume where they stopped; others must unload, clean and restart, because a partially processed part cannot be safely continued. This is a design decision the buyer has to make, not the integrator, because it depends on what a ruined part costs and what a scrapped part costs.
How customisation changes the screens
The HMI is where customization becomes visible, and it is also where the cheapest and most damaging mistakes are made. The following changes follow directly from the operating facts listed earlier.
The main screen reflects the sequence, not the hardware. On customised equipment the main screen should follow the order in which the machine does its work, so that an operator reading it can predict what happens next. A main screen drawn around the hardware layout is easier for the person who built the machine and harder for the person who runs it. Customised machines with added stations need this most, because the added station is exactly the part an operator has not yet learned.
Faults arrive as sentences, not as codes. A fault list of unreadable identifiers moves diagnosis into a paper table or into the habit of calling for help. Customised machines fail in ways that the standard machine never did, so a fault message has to say where the machine noticed the problem, what it was expecting, and what the operator is permitted to do about it. The number of messages the program generates and the wording of each one is a design deliverable, and it should be reviewed as text before wiring begins.
Access levels follow the staffing fact. If a machine is customised so that an operator may clear jams and change a setting, then the machine needs levels, and the levels have to match the people who will actually be issued them. If nobody on site maintains the machine beyond routine operation, an engineering screen behind a password is a screen nobody will ever open, which means the settings behind it will be changed by phone instruction instead.
Where information has to be entered, on purpose. Some customisations exist because the record has to be made at the machine: a batch identifier, a shift, an operator, a reason for a stoppage, a confirmation that a check was done. Each field added to a screen is a task the operator performs many times a day, so the design has to answer why that field exists, who reads it afterwards, and what happens to the machine when it is left blank.
Physical conditions that never appear in a specification. Gloves, distance, ambient light, noise, available floor area, whether the panel can be reached with the doors open, and whether the panel is on the operator's side or the maintenance side all change the layout of a screen and the size of its touch targets. A customisation that changes where the operator stands changes the screen. Buyers who commission a machine without walking the position it will be operated from almost always discover this after delivery.
What the physical design absorbs
Control design is not only software. Customising the machine changes the cabinet and the field wiring, and these changes are quoted, so a buyer should expect them to appear in the proposal rather than arrive as an extra:
Added devices mean added terminals, added cable, added routing and sometimes a different cabinet or a second one. Where the added equipment is supplied by someone else, the boundary between the two wiring scopes has to be written down and drawn, not assumed. Where an added module sits far from the cabinet, the method of connecting it is a design decision with a cost attached.
Spare capacity for inputs and outputs is a decision, not a habit. A customised machine that is likely to be extended again in a year or two is cheaper to extend if the capacity and the physical space were reserved at the design stage. Ask what has been left, and where.
The panel's position relative to the guarding and the access routes has to survive the customisation. A screen that becomes unreachable once the new infeed is fitted is a change that has to be made on site, at the worst possible moment.
Anything the machine is asked to record or hand to another system has to be agreed as a data interface before construction starts, including who owns the clock the records are stamped with. Disagreements about a clock are the most common reason records from two pieces of equipment cannot be put side by side afterwards. The non-standard automation equipment route is where a buyer is most likely to be told that a repositioned screen, an extra cabinet or a change to the guarding is straightforward. It is straightforward only once the wiring boundary and the access route have been drawn, and those drawings are the reason the request should go in as text rather than as a conversation.
The steam cleaning equipment testing route listed under engineering services makes the same point outside the control field. A test programme asks for measurements of the working conditions equipment is expected to meet, which is precisely the kind of agreement a control design needs before anyone can judge whether it has been built correctly: what the machine is being asked to detect, and under what conditions it has to detect it reliably. Customising the control package extends that agreement into places the machine was not previously required to look, because new states have to be detected, new permission boundaries have to be enforced, and new data has to be recorded somewhere. The more of that agreement exists as a written document before the cabinet is built, the less of it has to be invented on site afterwards.
Where the machine meets the rest of the plant
One part of the title deserves a separate section. Customisation changes the design of the integration as much as it changes the design of the controller. The point where the machine's control meets a warehouse system, a laboratory system, a line controller or a record-keeping system is where customised equipment most often stalls, because the interface was written for the standard machine's data, not for the data the customised version produces. Fields that used to be optional become necessary. A record keyed on a product code becomes a record keyed on a product code and a variant. A machine that used to report "complete" now has to report which of three completion states it reached, and the system on the other end of that wire has to be told as well. The two halves of that conversation are usually owned by two different suppliers, and the customisation is exactly what forces them to agree. Put that agreement in writing before the design is signed, and name who is responsible for each side of it.
What customisation does not change: the handover
A customised control package is handed over in the same documents, and those documents are the part of the job most often deferred. Before signing a design, a buyer should expect to see the following named, and should expect them to be written in the language the site uses:
A description of each mode, each state and each interlock, with the permission set for each. A list of every fault the machine can raise, with its wording. A list of every setting the machine publishes, with who may change it. A wiring and terminal schedule covering the added equipment and the agreed boundary. A statement of what has been left as spare input, output and physical capacity. A written recovery rule for a machine stopped mid-cycle. A record of which version of the program and which version of the screen design are on the machine, and where the copy of both is held.
Customisation multiplies the value of that last item. A control package that has been changed three times and never recorded is a machine nobody can support, whoever built it.
A short review you can run before the design is signed
Put the person who will run the machine, the person who will maintain it, and the person who owns the schedule in one room, and take the design in this order. Name every operating situation the customised machine will be asked to handle, and say which mode it belongs to. For each situation, ask what the operator sees, what the operator is allowed to do, and what the machine does if it is stopped halfway through. Ask what happens when the machine next to it stops. Ask what the machine records, who reads it and what happens if it is not entered. Ask what will be added to this machine in the next two years and whether the design leaves room for it. Ask what the fault list says, out loud, and whether anyone in the room can act on it without a telephone call.
Every question in that list is about customisation, and none of them is about equipment selection. That is the point. Customisation pushes a control package towards the way the buyer actually works: more states to name, more permissions to divide, more text to write, more physical routing to plan, and a much heavier obligation to document. A buyer who supplies those operating facts at the design stage gets a control package that absorbs the customisation. A buyer who supplies only a machine drawing gets a control package that works and is unusable, and finds out which during commissioning.
Where this connects on this site
PowerDe's pages present the control layer inside automation lines and non-standard equipment, and present engineering as a staged route, with development, testing, manufacturing automation and a steam cleaning enquiry route listed side by side. If a customization request is already at the point where the process is settled and the operating facts are known, those facts are what should be sent: the machine's sequence, the shift pattern, who maintains it, what it must record, what will be added later, and what a ruined part costs. That is what allows a PLC and HMI package to be designed as one package, and it is what shortens the argument afterwards.
