Why the data-transfer relation fails
The compilation error “has more than one data-transfer relationship” occurs because two object variables are connected as writers to the same system-tree output. The project cannot resolve which source owns that destination. Do not connect the START and STOP programs independently to one output channel.
| Element | Required role |
|---|---|
| START button | Issue a set request |
| STOP button | Issue a reset request |
| RS trigger | Store the commanded state |
| System output | Receive data from the single trigger result |
Implement a single-writer START/STOP command
Use one RS trigger as the state owner. Route the START event to its set input and the STOP event to its reset input. Connect only the trigger result to the system output: a reset trigger selects one output value, while a set trigger selects the other.
- Replace the two competing output connections with one connection from the RS trigger result.
- Configure START to generate the set request and STOP to generate the reset request.
- Add rising-edge detection at the trigger inputs when button signals are held across multiple program scans.
- Compile the project and confirm that the multiple-data-transfer-relation error is absent.
- Press START and STOP separately and verify that the output changes to the corresponding value.
The evidence does not identify whether the available RS block gives set or reset priority when both requests are active. Check that behavior in the selected block and test simultaneous requests before commissioning.
Use event requests instead of maintained buttons
Use ordinary momentary buttons rather than fixed buttons. A fixed button retains its button-variable value until released, so it is unsuitable as the sole indication of the commanded machine state. Drive the visual indication from the RS trigger result instead.
A supported alternative to wiring the button state directly into the trigger is to configure the button event to set a request parameter to true, consume that request in the program, and then reset it to false. This avoids dependence on press duration and was identified as particularly relevant to controllers using the MS4D runtime. Rising-edge detectors provide another way to turn a sustained input into a single request.
Retain and verify the commanded state
Enable the parameter property labeled “Save” for the state that must survive a runtime restart. Retain the RS state or the parameter used to reconstruct it, while preserving a single writer to the system output.
Restart the runtime and verify that the last commanded value is restored. The evidence confirms the Save property as the retention mechanism but does not define its behavior for power loss, application replacement, or an ungraceful shutdown; validate each required restart condition on the target system.
FAQ
Why does the compiler report more than one data-transfer relationship?
Two variables are writing to the same output channel. Replace them with one RS trigger and connect only its result to the destination.
How do I make a START/STOP value survive a runtime restart?
Enable the parameter’s “Save” property, restart the runtime, and confirm that the last value returns. Test power-loss behavior separately because it is not defined by the available evidence.
Should START and STOP use fixed HMI buttons?
No. Use momentary buttons to generate set and reset requests, then animate both buttons from the stored RS trigger state so the display shows the active command.