Aug 17, 2026Control Panels
Why Control Panel Startup Problems Happen More Often Than Buyers Expect
Control panel startup problems often come from field wiring, communication, default settings, documentation, and scope gaps. Strong FAT and interface checks reduce commissioning delays.
A control panel can pass FAT, arrive on site without visible damage, power up normally, and still cause trouble during commissioning.
That does not necessarily mean the control panel manufacturer built a bad panel.
Factory testing proves what can be verified inside the supplier's workshop. The startup adds conditions that were not fully present there: actual motors, sensors, field cables, SCADA networks, site power, equipment addresses, and the final operating sequence.
This is why the more useful question for an OEM buyer is not
Did the control panel pass FAT?
It is:
Did the FAT verify enough of the real site interface to make startup predictable?
Most control panel startup problems can be traced to a relatively small group of interface issues: field wiring, communication configuration, equipment parameters, documentation, and unclear responsibility between the OEM control panel supplier and the site team.
Control Panel Startup Problem Decision Matrix
When a panel works in the workshop but not after installation, this is where I would start looking.
Startup Symptom | Likely Area to Check | What Should Have Been Confirmed Before Shipment |
|---|---|---|
The sensor or actuator does not respond correctly. | Field wiring / I/O assignment | Final I/O list and terminal plan |
PLC communicates with some devices but not others. | Network settings / register map | Protocol, address, and register verification |
Motor or VFD trips on first start | The technician protection parameters | Motor nameplate data and project settings |
The technician cannot trace the fault quickly. | Documentation | Final as-built schematic and released software version |
The panel works, but the complete machine sequence does not. | Scope / interface responsibility | Supplier-site responsibility matrix |
FAT passed, but SAT reveals multiple small issues | Incomplete interface testing | FAT scope based on real site conditions |
The important distinction is that these problems often exist between systems, rather than inside one component.
A PLC can be programmed correctly and still receive the wrong field signal. A VFD can be healthy and still contain parameters that do not match the connected motor. A Modbus network can show an active connection while PLC and SCADA are reading different addresses.
That is why startup risk should be reviewed as an integration problem.
1. Field Wiring Does Not Match the Panel Assumption
The control panel is normally built from an approved electrical schematic and I/O list.
The site, however, may have continued changing after those documents were issued.
A level transmitter is replaced with another model. A limit switch changes from normally open to normally closed. Field cables are terminated differently from the original terminal schedule. An OEM modifies a machine sensor, but the latest revision never reaches the panel builder.
When startup begins, both sides may believe they followed the correct drawing.
They simply followed different revisions.
This is particularly common in custom OEM control panel projects, because the panel builder is often manufacturing the electrical system while another company is completing the machine or process equipment.
A stronger pre-shipment review should therefore confirm the final:
- field-device list;
- I/O allocation;
- terminal numbers;
- signal type;
- instrument power requirements;
- interface drawing.
Where practical, critical signals should be simulated during FAT using the same signal type expected on site.
The purpose is not to reproduce the entire plant in the workshop. It is to reduce the number of assumptions that remain when the panel reaches site.
2. Communication Can Be Connected Without Actually Working
One of the more frustrating commissioning situations is when every device appears connected but the data is wrong.
The Ethernet cable is plugged in. Network LEDs are active. The HMI may even show that the device is online.
Yet the PLC cannot read the required values.
The problem may be a wrong Modbus slave address, register offset, byte order, IP configuration, baud rate, or device mapping.
A simple bench communication test does not always expose this if the PLC control panel was tested with temporary devices or generic registers.
For projects involving PLC, HMI, VFD, remote I/O, or SCADA integration, FAT should verify the actual communication requirement where project information is available.
That means checking more than whether two devices can establish a connection.
The engineer should confirm that the PLC can read and write the project-specific data points that the final system will use.
For an OEM buyer comparing control panel suppliers, this is worth asking explicitly:
Will you test the actual communication map during FAT, or only confirm network connectivity?
Those are very different levels of verification.
3. Default Parameters Become Site Problems
A VFD arriving with factory-default parameters may power up perfectly.
That does not mean it is ready to operate the motor.
Motor voltage, rated current, frequency, control mode, acceleration time, deceleration time, minimum speed, maximum speed, and protection settings may all need to match the application.
The same applies to:
- electronic overloads;
- protection relays;
- temperature controllers;
- smart circuit breakers;
- instruments;
- communication devices.
Leaving all configuration to the site can sometimes be intentional, especially when process conditions are not yet known.
The problem is when nobody clearly owns that task.
The panel builder assumes the commissioning engineer will set the VFD. The site electrician assumes the VFD control panel manufacturer already configured it. The motor trips during startup, and both sides begin troubleshooting equipment that may simply contain unfinished settings.
A good pre-shipment record should therefore distinguish between:
parameters already configured and verified, and
parameters intentionally left for site commissioning.
That small distinction prevents a surprising amount of confusion.
4. Documentation Can Turn a Small Fault Into a Long Delay
When everything works, nobody pays much attention to the as-built drawing.
When something does not start, it becomes one of the most important documents on site.
Suppose a technician sees that one PLC input remains off.
With an accurate schematic and I/O list, the circuit can be followed from the PLC channel to the terminal and then into the field.
If the drawing shows the panel as it was designed three weeks earlier rather than as it was finally built, troubleshooting becomes much slower.
The technician now has to determine whether the problem is in the field device, cable, terminal, PLC input, or documentation.
For a custom electrical control panel, the shipping package should therefore include the final documentation actually matching the panel that left the workshop.
At minimum, buyers should confirm the availability of:
- as-built electrical schematic;
- final I/O list;
- alarm and interlock list where applicable;
- PLC program version;
- HMI program version;
- VFD parameter record where configured;
- network or communication settings.
This is not paperwork for the sake of documentation.
It is part of the commissioning toolset.
5. Some Startup Problems Are Really Scope Problems
The most expensive commissioning arguments often begin with a sentence such as
“We thought your scope included that.”
The control panel supplier may have been responsible for the PLC and HMI programming but not SCADA integration.
The OEM may have expected the panel builder to configure the entire communication network.
The panel manufacturer may have assumed the site team would provide motor and instrument parameters.
Nobody necessarily made a technical mistake.
The interface was simply never defined clearly enough.
For this reason, a commercial quotation for a custom control panel project should make the project boundary visible.
For example:
Item | Panel Supplier | OEM / Site |
|---|---|---|
Panel internal wiring | ✓ | |
PLC program | ✓ | |
HMI program | ✓ | |
Field cabling | | ✓ |
Instrument installation | | ✓ |
Motor data before FAT | | ✓ |
VFD parameter setup | Defined by project | Defined by project |
SCADA integration | Defined by project | Defined by project |
FAT | ✓ | Buyer witness, if required |
SAT / site commissioning | As quoted | Site coordination |
This table is commercially useful because it reduces the risk of purchasing a low quotation whose missing engineering responsibility only becomes visible during commissioning.
A Representative Startup Case: “The Panel Worked at FAT”
An OEM machine project had already passed FAT before shipment.
The PLC sequence worked, the HMI screens were complete, and the VFDs responded correctly during the workshop test.
At the site, the machine powered up normally, but automatic operation could not begin because one permissive remained missing.
The first suspicion was the PLC program.
The logic was checked and behaved exactly as designed. The field sensor was then tested and also worked correctly.
The problem appeared when the commissioning engineer compared the PLC I/O list with the actual terminal wiring.
During final machine assembly, the sensor type and terminal assignment had been changed. The panel documentation available on site still reflected the earlier interface revision.
There was nothing complicated about the eventual correction.
What consumed the commissioning time was finding the disagreement between the machine wiring, control panel terminal assignment, and documentation.
After that review, the FAT process was changed.
The final interface signals were checked against the released I/O list before shipment, and the as-built documents were verified against the physical panel before the cabinet was packed.
The lesson was not that FAT had failed.
The FAT had tested the panel.
What had been missing was verification of the interface the panel would meet after delivery.
FAT and SAT Solve Different Problems
Buyers sometimes expect FAT to eliminate every startup problem.
It cannot.
Factory acceptance testing should verify the control panel before shipment, including its internal wiring, programmed functions, alarms, interlocks, and interfaces that can reasonably be simulated.
Site acceptance testing verifies the installed system after the panel is connected to actual field devices, motors, utilities, and networks.
A strong OEM project uses the two tests together.
The better the interface is defined before FAT, the fewer surprises SAT has to uncover.
This matters particularly when sourcing an OEM control panel from China, because correcting a ten-minute workshop issue after international shipment can become a much more expensive site problem.
The commercial value of FAT is therefore not simply that the buyer receives a test video.
It is that problems are deliberately moved from the commissioning site back to the panel shop, where they are easier and cheaper to correct.
What Buyers Should Ask a Control Panel Supplier Before Ordering
When comparing custom control panel manufacturers, do not compare only the enclosure, PLC brand, and component BOM.
Ask how the supplier handles startup risk.
Useful questions include:
- What interfaces will be verified during FAT?
- Will the final I/O list be checked against the physical wiring?
- Will PLC-to-HMI/VFD communication be tested using the actual project mapping?
- Which device parameters will be configured before shipment?
- Which settings must still be completed at the site?
- Will the final as-built drawings match the shipped panel?
- Are PLC, HMI, and VFD backups included?
- Who is responsible for SCADA, field wiring, and SAT?
- Is remote or on-site commissioning support available?
A supplier who can answer these questions clearly is giving you more than an electrical cabinet quotation.
They are showing how they intend to get the panel from FAT to a successful startup.
Common Mistakes
❌ Treating a FAT video as proof that the complete machine will start without additional site integration.
❌ Approving the I/O list early in the project and never reconciling it with later field changes.
❌ Checking that communication is “online” without verifying the actual registers or data points.
❌ Shipping VFDs and protection devices with unfinished parameters without identifying who will configure them.
❌ Packing an old schematic instead of the final as-built drawing.
❌ Comparing OEM control panel quotations without checking whether FAT, documentation, parameter setup, and commissioning support are included.
Engineering Takeaway
Control panel startup problems happen more often than buyers expect because the panel is only one part of the final operating system.
The workshop controls the panel.
The startup introduces the machine, field wiring, motors, sensors, network, operators, and site conditions.
The best way to reduce commissioning delay is therefore not to ask for more testing in general. It is to identify the interfaces most likely to change between panel build and startup, then verify those interfaces before shipment.
A good custom control panel supplier should help the buyer close that gap before the cabinet is crated.
Need an OEM Control Panel That Is Ready for Startup, Not Just Shipment?
If you are sourcing a PLC control panel, VFD control panel, machine control cabinet, or custom OEM control panel from China, send UniRegal your electrical schematic, I/O list, equipment list, and commissioning requirements.
We can review the panel scope, FAT requirements, field interfaces, communication mapping, parameter setup, and as-built documentation before production, then match the project to a suitable panel-building source in our Foshan network.
The objective is simple: identify as many startup problems as possible while the panel is still on the workshop bench—not after your commissioning team is waiting beside the machine.
Send Your Control Panel Drawing for a Technical & Commercial Review
Related guides
Send us your panel spec.
Tell us the PLC, I/O, and field devices, and we will scope a panel with the test and document discipline that prevents startup delays—built in, not promised. Submit your requirements.