Pressing the robot GUI stop button halts the running program before program-resident logic can reliably send a final stop command. Move stop detection and external-device shutdown into an external daemon that monitors robot program state independently.
Why the in-program command does not execute
The attempted call set_runstate_configurable_digital_output_to_value(5, 3) does not provide an execution window after the GUI stop action. Once the program receives the stop command, no subsequent command inside that stopped program can be relied upon to execute.
The available evidence does not define the arguments or intended behavior of this function, so do not infer that it reports the GUI button state. The decisive constraint is execution context: logic inside the program cannot react after that same program has halted.
Select an independent monitoring path
| Method | Supported use | Constraint |
|---|---|---|
| External daemon with Dashboard Server | Monitor whether the program is running and stop the external device independently. | The evidence does not provide Dashboard Server commands or message formats. |
| External daemon with RTE stream | Read streamed robot data on port 30003 at 125 Hz. |
The daemon must decode the required program-state field; its layout is not supplied. |
| Java installation or program node | May read robot data within the URCap. | Real-time-capable work can share the GUI thread and degrade GUI performance. |
An external daemon is the preferred architecture because its lifecycle is separate from the stopped robot program and it avoids placing continuous data handling on the GUI thread.
Implement the external stop path
- Keep the existing XML-RPC application interface in the external daemon.
- Add a robot-state input using either the Dashboard Server or the RTE stream on port
30003. - Read the program-running state outside the robot program. The RTE connection streams at
125 Hz, so consume incoming records instead of issuing a polling request for each update. - Detect the transition from running to not running in the daemon.
- When that transition occurs, send the external device's stop command from the daemon rather than from the halted URCap program.
The evidence asks whether a daemon can use two different addresses but does not answer it. Treat that as an implementation-specific networking question: confirm whether the existing daemon can maintain separate endpoints or whether both interfaces must be exposed through one process before selecting the connection layout.
Verify stop-command delivery
Start the application, confirm that the daemon observes the running state, and then press the GUI stop button. Verify that the daemon detects the running-to-stopped transition and sends the external stop command even though the URCap program has halted. Also confirm that continuous state processing does not run in the Java GUI thread if it causes interface responsiveness problems.
FAQ
Can a URCap send a command after the GUI stop button is pressed?
No reliable in-program execution remains after the program is told to stop. Send the command from an independently running daemon.
Which port can monitor Universal Robots program state?
The cited RTE interface uses port 30003 and streams data at 125 Hz. The receiver must read and decode that stream.
Should robot-state monitoring run in a Java program node?
It may be possible, but continuous real-time processing can share the GUI thread and affect GUI performance. An external daemon is preferable for this monitoring and shutdown path.
