Multiple controllers can access the same E1 I/O, but unrestricted configuration and output writes create deterministic ownership problems. Use one controller as the configuration and output owner, allow other controllers to read I/O, and exchange supervisory commands through the scratchpad when both strategies need influence.
Separate Access from Ownership
| Operation | Observed behavior | Engineering decision |
|---|---|---|
| Read an input or output | Either controller can read the point. | Permit reads where required. |
| Write an output | Either controller can write, but the last write determines the output state. | Assign one output owner. |
| Configure the E1 | Each controller sends its configuration when it boots or starts. | Keep configurations identical or prevent competing configuration ownership. |
| Access from both controllers at high frequency | Either controller may time out or report that its first attempt failed. | Reduce competing direct traffic and monitor controller messages. |
Control the Configuration Conflict
If both projects define the E1 as an E1 device, each controller can send I/O points, PID loops, event reactions, and other configured items to the brain. The last controller to send its configuration establishes the active configuration. If the projects differ, the controller that configured the brain first can then operate against a configuration it did not expect.
Maintain matching E1 configurations in both projects if both must configure the device. One reported workflow is to finish the PAC R I/O configuration, export it, and import it into the PAC S project. Treat messages about PID items already being configured as evidence of overlapping ownership; verify that the resulting configuration matches the designated master project.
Prevent Competing Output Writes
Do not let independent strategies continuously command the same output. Because the last write wins, conflicting logic can make a digital output alternate states or make an analog-controlled device repeatedly speed up and slow down. Reading from both controllers does not create this conflict; competing writes do.
- Designate the R1 or S1 as the master for E1 configuration and output commands.
- Use the second controller primarily for I/O monitoring.
- If the second controller needs control authority, pass its request through peer-to-peer scratchpad data and resolve priority, permissives, and final output state in the master strategy.
- Restart each controller separately and confirm that the E1 configuration remains correct after either controller sends its project configuration.
- Exercise competing command conditions and verify that only the master strategy writes the physical output.
Choose Direct E1 or Generic MMP Access
Direct E1 definitions expose the I/O to both projects but require synchronized configurations. A reported alternative is to configure the secondary controller connection as generic MMP and use built-in commands to access the scratchpad. This supports supervisory data exchange without making both strategies independent owners of the same physical output.
The evidence does not establish REST behavior for this arrangement. Prefer the demonstrated scratchpad approach when the goal is coordinated sub-control, and validate controller message logs for configuration warnings, timeouts, or first-attempt failures during simultaneous traffic.
FAQ
Can two controllers read the same E1 I/O?
Yes. Both controllers can read input and output points, provided their device configurations correctly describe the E1.
What happens when two controllers write the same E1 output?
The last controller to write determines the output state. Assign one controller as the output owner or arbitrate commands in the master through the scratchpad.
Why does an E1 configuration change after a controller restart?
Each controller sends its configuration when it boots or starts, so the last configuration sent becomes active. Keep both projects synchronized or give only one controller configuration ownership.