ABB PC SDK P-Start: Why Restart Only Warm/Cold Starts

Start Modes and the Memory Each One Clears

A controller restart is a memory operation before it is anything else. The mode you pick decides which regions of controller storage survive the reboot, and that is why RobotStudio offers a menu of modes while the PC SDK restart method offers two. The number that matters is not the reboot time; it is which of three regions gets wiped: the volatile execution state, the RAPID program memory, and the system configuration.

The PC SDK restart call takes a start-mode enumeration that contains only the warm and cold entries. Passing anything else is not a runtime error you can trap; the option simply does not exist in the public API. RobotStudio reaches the other modes through an internal interface that is not published, so a PC application cannot borrow it. The behaviour is by design, not a bug in a particular SDK release, and there is no documented plan that changes it.

Why a Remote P-Start Is Requested at All

A P-Start is the surgical option: it throws away everything in program memory, including modules loaded ad hoc, unsaved edits, stale program pointers and persistent-variable state that has drifted from its declared initial value, while leaving I/O, motion and communication configuration untouched. Fleet-management PC applications want it after pushing a new RAPID release, because it guarantees the controller reloads exactly the module set named in the automatic-loading configuration and nothing else. A warm start does not give that guarantee, and a cold start gives far more than that, taking configuration with it.

This is memory, not logic. If the goal is only to reload a specific module set, the program-memory wipe is a means, not the end, and that opens a second route that stays inside the public API.

Candidate Approaches Compared

Rule out D immediately: it wipes configuration and turns a remote maintenance task into a commissioning task. C is the fallback when nothing else is available but does not satisfy the requirement. The real decision is between A and B.

Choose A when the actual requirement is "the controller runs release N of my modules after the restart". The PC SDK can unload the modules it knows about, transfer new files to the controller file system, load them, and issue a warm start. What it cannot do is remove modules or state it does not know about.

Choose B when the requirement is the guarantee itself: program memory must be empty before reload, regardless of what an operator or another application put there. That is the only remote route to a genuine P-Start, and it is the recommended one for fleet tooling.

Recommended Design: Signal-Driven FlexPendant SDK Listener

The listener is a FlexPendant SDK application with no visible view. It subscribes to one digital signal, and when that signal goes high it requests a P-Start through the FlexPendant SDK, which does expose the restart modes the PC SDK hides. The PC application then needs only what it already has: signal write access through the PC SDK.

1. Define a dedicated signal in the controller I/O configuration on every target robot. A virtual signal with no physical device is sufficient; the signal exists only as a mailbox between the PC application and the listener. Give it a name that no cell program will ever write.
2. Confirm both options are present on every controller: the PC Interface option for the PC SDK connection and the FlexPendant Interface option for the listener. Read the installed option list in the controller system properties; a missing option produces silent non-function, not a fault code.
3. Write the listener. On startup it registers for change events on the signal. On a rising edge it checks that no RAPID task is executing, then issues the P-Start request. Do not issue the restart while a task is running; the controller will refuse or, depending on state, abort motion in a way that leaves the cell needing manual recovery.
4. Handshake before the restart. Have the listener write a second signal, or a persistent RAPID variable the PC can read, acknowledging that the request was received and accepted. Without this, the PC application cannot distinguish "restart in progress" from "listener not running".
5. Deploy the listener to each controller and add it to the list of applications that start with the FlexPendant, so it survives a power cycle. Version it with the RAPID release; a RobotWare upgrade can require a rebuild of FlexPendant SDK applications.
6. In the PC application, set the request signal, wait for the acknowledge, drop the PC SDK connection deliberately, then poll for the controller to come back. The connection will be torn down by the restart regardless; handling it explicitly avoids an exception mid-sequence.
7. After reconnect, clear the request signal from the PC side if the I/O configuration does not reset it on restart, otherwise the next listener start sees a stale high level and fires immediately.

Request mastership of the controller from the PC side before writing the signal if the signal's access level requires it, and release it once the acknowledge arrives. Holding mastership across the restart guarantees a stale handle after reconnect.

Verification After the Restart

1. Read the event log through the PC SDK after reconnect. The restart entry states the mode that was executed; a warm start where a P-Start was requested means the listener fired the wrong call or never fired and something else rebooted the controller.
2. Enumerate the loaded modules in every RAPID task. The list must match the automatic-loading configuration exactly. An extra module means program memory was not cleared.
3. Check the program pointer state. After a genuine P-Start the pointer is not set until the main routine is selected; a pointer already positioned inside a routine indicates the previous execution state survived.
4. Read a persistent variable that is known to change during production and compare it with its declared initial value. Survival of the production value means a warm start occurred.
5. Confirm the configuration survived: I/O signals resolve, tool and work-object data load, and the controller reports the same system name as before. Loss of configuration means a cold start or an I-Start was executed instead.

Recurring Pitfalls

• Unsaved RAPID modules. A P-Start discards them without a prompt when triggered programmatically. Have the PC application save or back up all modified modules before setting the request signal, or accept the loss as policy and document it.
• Listener absent on one robot. The PC side sees only a signal that goes high and nothing else. Implement the acknowledge handshake with a timeout and treat a timeout as a hard failure for that controller rather than proceeding to the next step.
• Signal written by cell logic. If the request signal shares a name pattern with production I/O, a mistaken cross-connection will restart the controller mid-cycle. Keep the signal outside any cross-connection and outside any RAPID module that production can edit.
• Restart during execution. The listener must gate on execution state. A restart request during motion is the one place where this workaround can cause physical damage.
• Expecting the PC SDK to grow the mode list. Do not design around a future release adding P-Start to the restart enumeration. Build the listener now and remove it later if the API changes.

Stop and escalate to ABB Robotics support through the official channel when the listener issues the P-Start but the event log shows a different mode, when the FlexPendant SDK restart request is rejected on a controller where the options are confirmed present, or when a RobotWare upgrade breaks the listener and the rebuild does not resolve it. Provide the RobotWare version, the installed option list, and the event log extract covering the restart.

FAQ