Use Do-more native Ethernet remote I/O when the application needs remote modules to behave like local I/O, including system-configuration visibility and CTRIO integration. Use Modbus when an HMI or field-device connection does not require that native I/O model. Before migration, separately evaluate memory, removable-media logging, communications ports, analog capacity, and remote-I/O failure behavior; the evidence does not support assuming feature parity across Do-more hardware platforms.
Distinguish Native Remote I/O from ERM Operation
| Capability | ERM behavior described | Do-more native remote I/O |
|---|---|---|
| Data model | Paints remote I/O into memory | Remote I/O is presented essentially like local I/O |
| Configuration | No Do-more-based configuration was identified | Configured through the system configuration |
| Base visibility | No visibility into base contents was identified | Provides visibility and native integration |
| CTRIO support | No CTRIO support was identified | Supports CTRIO structures and instructions |
The native implementation depends primarily on the Do-more CPU. The evidence also identifies updated EBC100 firmware with adjustments intended to assist CPU operation, but no fundamental change in EBC100 functionality. A CTRIO firmware update was demonstrated while the module remained installed in a remote base. Treat both CPU and EBC100 firmware compatibility as commissioning checks; the evidence does not provide the required firmware revisions.
Select the Communications Architecture
A reported C-more integration was less direct through K-Sequence than through a DirectLogic controller, while the transparent Modbus slave configuration provided a workable alternative. Another application used two communications ports to communicate with two Sure servos and five rectifiers. The Do-more implementation removed legacy time-sharing logic that had sequenced access to a single port.
- List each HMI, servo, rectifier, and remote I/O base, including its required protocol and physical port.
- Use transparent Modbus slave operation for the C-more connection when K-Sequence integration creates avoidable configuration friction.
- Assign independent device groups to separate ports where the hardware and application support it, then remove obsolete port-sharing sequence logic.
- Use native Ethernet remote I/O when system-configuration visibility or CTRIO structures and instructions are required.
Do not infer that the built-in Ethernet port supports every legacy Ethernet function. Confirm the selected Do-more CPU, EBC100 firmware, remote modules, and engineering-software version as a tested system.
Structure Programs for Maintainability
Do-more programs and tasks support modular application construction, and table indexing was reported as easier to configure than on a DL205. The design decision is whether each code unit represents an independent behavior or a sequence step.
| Application structure | Supported design direction | Review point |
|---|---|---|
| Independent behaviors | Use programs and tasks | Avoid an excessive collection of small units connected only through RUN and ENTASK commands |
| Sequential behavior | Evaluate stages | Keep the operating sequence visible instead of distributing it across task-control calls |
Before handoff, use project search and navigation to trace every RUN and ENTASK relationship. Verify that each program, task, or stage has a defined entry condition, completion condition, and ownership of shared data. These documentation checks address the observed maintainability risk without assuming undocumented software behavior.
Configure Remote-I/O Failure Handling
Remote-I/O loss requires an application-specific decision. Holding the last state can preserve a continuous process during a brief interruption but can leave hazardous outputs energized. Turning all outputs off can terminate the process immediately and may create a different hazard. The described Do-more approach treats a declared remote failure with the same severity as a local failure: fatal.
Two configurable layers determine when that failure is declared:
- Set the EBC link-monitor interval to define how long communication may be absent before the EBC shuts down its outputs.
- Configure CPU timeouts and/or retries to define how long the failure persists before the CPU logs out the remote device and enters a fatal condition.
- Test loss and restoration of communications under controlled conditions, recording output behavior at the EBC shutdown point and the CPU fatal point.
No safe universal timeout is established by the evidence. Derive both settings from the machine risk assessment, permitted process interruption, actuator behavior, and independent safety functions. Do not rely on a proposed delay value as a validated setting.
Check Platform Fit and Version Scope
A successful migration from a large 260-based application showed that Do-more can reduce communications sequencing and simplify table access. Other reported applications exposed platform-selection constraints: memory capacity, logging to a USB memory stick, analog capacity, and the availability of specialized I/O. Check these requirements before selecting a controller rather than assuming that greater processing or built-in Ethernet resolves every application need.
Do-more Designer 2.11 adds features across Do-more PLCs identified as BRX, 205, Terminator, and Simulator. The evidence specifically lists BX-P-OPCUA and BX-P-SPARK as BRX pluggable option modules, a BX-P-USB-C programming-port module, ENCRYPT and DECRYPT instructions using the Ascon-128 cipher, enhanced C-more tag export, diagnostic tools for the new OPC UA and Sparkplug B modules, and a keyboard-shortcut listing. Do not extend BRX-specific module availability to the other Do-more platforms without checking the applicable hardware documentation.
Verify the Commissioned System
- Confirm that every remote base and module appears in system configuration with the expected base contents.
- Exercise CTRIO structures and instructions when CTRIO modules are installed remotely.
- Test each HMI and field-device path independently, including the selected Modbus connection and every assigned communications port.
- Trace program, task, stage, RUN, and ENTASK relationships using project navigation.
- Interrupt remote-I/O communications under controlled conditions and verify the configured EBC shutdown and CPU fatal responses.
- Confirm that memory, logging, analog I/O, and programming-port requirements are satisfied by the selected hardware rather than by Do-more Designer 2.11 features alone.
FAQ
What is the difference between Do-more native remote I/O and ERM?
ERM was described as painting I/O into memory without Do-more configuration, base visibility, or CTRIO support. Native remote I/O is configured in system configuration, behaves essentially like local I/O, and supports CTRIO structures and instructions.
How do I connect a C-more HMI to a Do-more PLC when K-Sequence is difficult?
Configure the Do-more controller as a transparent Modbus slave and map the required HMI data. Verify reads and writes from the C-more before placing the connection in service.
How should Do-more remote I/O react to a communication loss?
Coordinate the configurable EBC link monitor with the CPU timeout and retry behavior, then test both the EBC output shutdown and CPU fatal response. Select the timing from the machine risk assessment; the evidence provides no universal safe delay.