Choosing the controller by label alone usually fails. A hardware PLC is not automatically available because it uses a dedicated box, and a SoftPLC is not automatically scalable because it runs in software. The number that matters is whether the complete control path meets its timing deadline, preserves required state, survives the cabinet environment, and can be restored by the available maintenance team.
Wrong fixes and hidden limits
The first wrong fix is selecting a traditional PLC solely to avoid software complexity. That choice can push database access, vision, motion, SCADA, robot interfaces, and cloud communication into separate devices. The controller remains familiar, but device count, interfaces, backups, and failure boundaries multiply.
The opposite mistake is selecting a SoftPLC solely for “easy scaling.” Physical expansion still requires I/O, wiring, fieldbus capacity, power, cabinet space, commissioning, and machine testing. Software modularity can reduce application effort, but it cannot remove physical integration work.
A third mistake is rejecting SoftPLCs because retained values supposedly disappear at every power loss. CODESYS-based systems can store retain and persistent data. The engineering question is where that data is committed, how frequently it is written, what happens during abrupt power loss, and how restoration is tested.
Virtualizing the controller without assigning ownership also fails. A virtual machine adds a hypervisor, host hardware, shared resources, networking, operating procedures, cybersecurity controls, and IT change management to the control path. Each layer needs an availability target and a named recovery owner.
Availability as an architectural property
A control platform fails when a required action misses its deadline, an input or output path becomes unavailable, required state cannot be recovered, or personnel cannot restore operation within the plant’s recovery target. This is timing, stored energy, heat, and maintainability—not a contest between hardware and software labels.
A dedicated PLC concentrates the runtime, memory, communications, and diagnostics in an appliance designed for control service. That produces a smaller administrative surface and often matches plants whose technicians, spares, and programming standards already center on a popular local PLC family.
A PC-based SoftPLC can consolidate control with CNC, HMI, databases, vision, robot communications, SCADA, and MQTT workloads. It also supports software structures such as dynamic memory allocation, properties, methods, interfaces, and inheritance. Those tools can make a complex machine easier to partition, reuse, and test, but they also make software architecture and resource isolation part of the control design.
Hardwired I/O remains valid where a direct electrical interconnection provides the clearest failure behavior or where a separate programmable layer adds no useful function. The selection boundary may therefore exist within one machine: software-defined coordination above direct field-level signals.
Quantities that decide the platform
The controller must be evaluated as an end-to-end path from input transition to output response. Average CPU load is not enough. Worst-case execution time, scheduling jitter, bus delay, storage behavior, and recovery time determine whether the system remains controllable.
| Quantity | Selection limit | Where to read or measure it |
|---|---|---|
| Control response | Must remain below the process deadline under worst-case workload | Runtime task statistics and timestamped I/O test |
| Task jitter | Must stay within the motion or process tolerance | Controller scheduler diagnostics |
| Fieldbus delay | Input, network, and output delays must fit the response budget | Bus diagnostics and packet or I/O timestamps |
| CPU and memory headroom | Must absorb peak HMI, vision, database, communications, and control demand | Runtime and operating-system performance counters |
| Current and thermal load | Must remain within the power-supply and enclosure cooling design | Device datasheets, measured current, and cabinet temperature records |
| Persistent state | Required values must survive the specified shutdown and power-loss cases | Runtime retention configuration and power-cycle test |
| Recovery time | Restore must finish inside the production recovery target | Timed bare-metal, image, project, and configuration restore |
| Support coverage | Qualified people and replacement parts must be reachable during the operating window | Plant staffing, supplier channels, and spare-parts records |
Thermal margin deserves the same attention as scan time. A PC executing several consolidated workloads may reduce cabinet device count, yet its processor, storage, power conversion, and cooling path still reject heat into the enclosure. Measure current and temperature during peak workload rather than using idle values.
Platform selection procedure
- Define the process deadline. Identify the slowest acceptable input-to-output response, motion update behavior, and production recovery time. Separate deterministic control tasks from supervisory functions.
- Map every required workload. List logic, distributed I/O, fieldbuses, CNC axes, robot links, vision, HMI, SCADA, databases, and MQTT or other external data exchange. Mark which workloads must share data with low latency.
- Draw failure boundaries. For each controller, PC, virtual host, switch, storage device, and I/O station, record what stops when it fails. Consolidation reduces interfaces but can increase the effect of one host failure.
- Specify state retention. Classify values as recalculated, retained, persistent, recipe-controlled, or externally stored. Define the valid startup value and recovery action for every state that affects motion, product tracking, or process continuation.
- Allocate timing and resources. Assign control tasks their deadlines and reserve CPU, memory, network, and storage capacity for peak concurrent operation. Treat operating-system maintenance and cybersecurity activity as loads and change events.
- Score lifecycle fit. Compare local skills, spare availability, licensing, backup method, restore time, change control, and expected machine support life. Familiarity has measurable value when it shortens diagnosis and recovery.
- Prototype the riskiest path. Test the highest-axis, highest-I/O, most communication-heavy, or most state-dependent operating mode before standardizing the platform.
Backup, restart, and ownership
A disk image can simplify recovery of a PC-based controller, but an image is useful only when it contains the correct runtime, licenses, drivers, fieldbus configuration, application, and persistent data—or when those items have a documented restoration sequence. Store the controller project separately so application changes remain traceable.
Define the startup sequence after normal shutdown, abrupt power removal, storage replacement, and network loss. The controller must distinguish safe initialization from valid continuation. Retained data that is internally consistent but belongs to the previous product or machine state can be more hazardous than cleared data.
For virtual deployments, assign control of host patching, snapshots, resource allocation, network changes, failover, and recovery testing. IT and OT responsibilities must meet at a written change boundary. A technically capable runtime can still have poor availability when an infrastructure change bypasses control-system validation.
Verification under production conditions
- Run the maximum credible combination of control, motion, visualization, database, vision, and communication workloads.
- Record worst-case task execution, jitter, bus health, CPU load, memory use, storage activity, cabinet current, and temperature.
- Interrupt power using the installation’s approved test method, then verify retained and persistent values against the defined startup state.
- Disconnect relevant networks and I/O segments one at a time. Confirm diagnostics identify the failed boundary and outputs enter the designed state.
- Restore to replacement hardware or a clean virtual target from the controlled backup. Time the complete recovery and verify licenses, communications, I/O mapping, recipes, and application revision.
- Have the personnel expected to support the machine perform the diagnosis and restore using plant documentation.
Accept the platform only when the measured worst-case results stay inside the process limits and the recovery exercise meets the plant target. For simple machines, either approach may pass; the local support network can then be the deciding constraint. For machines combining extensive motion, data, visualization, and mixed communications, consolidation may remove enough interfaces to justify the additional software layers.
FAQ
How do I choose between a SoftPLC and a hardware PLC?
Compare worst-case control timing, failure boundaries, retained-state behavior, restore time, local skills, and spare availability. Choose the architecture that passes measured production-load and recovery tests.
How do I verify SoftPLC data survives a power loss?
Classify the required values, configure them as retain or persistent data in the runtime, remove power using the approved test method, and compare the restarted values with the defined startup state. Also test storage replacement and backup restoration.
How do I test SoftPLC real-time performance?
Run peak concurrent workloads and record worst-case task execution, scheduler jitter, and end-to-end I/O response. Average processor utilization cannot prove that every control deadline is met.
How do I manage a SoftPLC running in a virtual machine?
Assign ownership for the host, hypervisor, networking, patching, resource reservations, backups, and recovery. Validate every infrastructure change against control timing, communications, state retention, and restart behavior.
When should I stop troubleshooting and contact support?
Stop when task deadlines, retained-state behavior, licensing, fieldbus recovery, or runtime faults remain outside the documented configuration after a clean restore and controlled test. Preserve diagnostics, runtime logs, hardware details, workload measurements, and the exact reproduction sequence, then escalate through the manufacturer’s official support channel.