A PLC and an HMI rarely fail at the communication protocol itself. They fail at the seams: an I/O list that changed after the panel was drawn, a tag name that means one thing in the controller and another on the screen, and no agreed way to say when the machine has actually stopped. Reviewing the interface before the first wiring means turning the controller program, the screen, and the machine behaviour into one description that both suppliers can sign off on.
Start from the control boundary, not from the communication port
Before choosing Modbus, EtherNet/IP, PROFINET or a vendor-specific driver, list what crosses the boundary. For PowerDe machines that boundary usually includes the safety devices and the interlocks, the operator's right to start and stop, the recipe or mode the plant wants to keep on the screen, and the maintenance data someone will eventually ask for. Every item on that list needs an owner: does the PLC make the decision, does the HMI only display it, or does the HMI send a command that the controller has to validate? An interface review that only covers register addresses tends to leave the safety and authority questions unasked.
The practical output of this step is a two-column document. On one side are the signals the controller already handles, such as motor running, fault, ready, and the state of each guard. On the other side are the actions the operator expects to control from the panel, such as start, stop, mode change, and a reset that must not clear a fault until the cause is gone. Anything that appears in the second column but has no matching controller behaviour is an open item, and it is cheaper to resolve on paper than in commissioning.
Agree the tag list, the data types, and the units
Ask for the PLC tag list with the data type, the address, the engineering unit, and the scaling used inside the controller. A temperature written in tenths of a degree and read as degrees appears on screen as a plausible but wrong number. A boolean array packed into a word needs a documented bit order, because the HMI project and the controller project are often built by different people at different times.
Two details cause most rework. First, who owns the name of the tag. If the controller uses addresses or abbreviated names with no description, the screen ends up with labels that only the original programmer understands. Second, who owns the alarm and status texts. If the controller returns a fault code and the HMI translates it locally, the code table must exist somewhere and be versioned, otherwise a new machine revision produces messages that no longer match.
Match the interface to how the equipment is actually operated
Cleaning duty changes what the panel has to show. A cleaning equipment line that runs steam, hot water and vacuum functions in sequence needs the operator to see which function is active, which step is next, and what has to be true before a cycle may be released — water supply, tank level, heater state, and the state of any interlock. A screen that only shows a start button and a fault lamp cannot tell an operator why a cycle will not start.
Buyers should describe the operating pattern the panel has to support. Continuous operation, timed dosing, a batch that follows a recipe, and a manual jog mode for maintenance all need different screen structures and different permission levels. When the equipment is supplied as fixed steam cleaning machine installed at a fixed station, the plant usually also wants running hours and service prompts held where maintenance can read them. Where the machine moves between bays, the panel and the cabling arrangement have to be reviewed together with the interface, because a connection that works on a bench may not survive daily unplugging at a service point. The site lists several working-voltage variants, so confirm the supply voltage of the delivered unit against the panel specification rather than assuming one value applies across the range.
For equipment with driving style steam cleaner formats and battery variants, the interface also has to answer where charge status and battery protection states are shown and who stops the machine when a protection trips. The product pages for these machines list leakage, short-circuit, high-temperature, high-voltage and water-shortage protection. Each of those needs a defined behaviour on the panel: what the operator sees, what is allowed to restart the machine, and whether the fault is logged.
Confirm the electrical and network side of the interface
The physical review is short but has no exceptions. Supply voltage at the panel, not on a nameplate elsewhere. Earthing and shielding plan for the communication cable. Cable route relative to drives and heating elements, since high-power heating circuits and encoder or analog signals should not share a tight bundle. Addressing plan if the controller sits on a plant network, including who assigns the address and what happens when the machine is moved to another network segment. If the interface passes through a gateway or protocol converter, the converter's scan rate and any limit on the number of registers it will poll both belong in the review.
Write the acceptance tests for the interface itself
The interface should have its own test list, agreed before shipment and run during the factory or site acceptance. At minimum: remove the water supply and confirm the screen states the reason in words the operator can act on. Trip an interlock and confirm the machine stops and the fault text identifies the device. Change a setpoint on the panel and confirm the value reaches the controller and survives a power cycle where it should. Read a trend or running-hour record and confirm it is populated. Interrupt the communication link and confirm what the HMI displays, and what the controller does with the process.
Ask both suppliers to state what they consider the handover point. A useful definition is a signed tag list, a screen that matches that list, a fault text table, and a completed acceptance record for the tests above. That is also the document set to keep for the next machine or the next line, because the second installation is where an interface description earns its cost.
