Camera connection after a power cycle: re-init in the robot program

A robot cell that runs cleanly all week loses its camera on the first cycle after every power-down. The pose request fails, an operator switches to manual mode, opens the installation panel, refreshes the vision plugin, and the same program runs without issue until the next outage. The error behind it names 127.0.0.1 and a port, not the camera. This guide is for whoever owns that cell: what the error means, why a power cycle causes it, and the program-start change that makes the first cycle after any restart recover on its own.

What the refused connection is telling you

The camera-pose program node does not talk to the camera. It posts an XML-RPC request to a small service the vision plugin runs on the robot controller itself, at loopback address 127.0.0.1, TCP port 33004. The full signature reads:

Failed to connect to 127.0.0.1 port 33004 Connection refused

"Connection refused" has one meaning on any TCP stack: nothing was listening on that port at that moment. The camera, its lens, its cable and its calibration can all be healthy. The plugin's local service simply is not up yet.

That also explains the green indicator. The connection status in the installation panel shows the result of the last successful handshake, and it re-evaluates only when you open the panel or press refresh. It is a stored state, not a live probe of port 33004. The refresh button works because pressing it re-opens the local service and re-binds the port, which is exactly the action the program should perform for itself.

The error text also names the node and the line where the request was issued; in one field case, the camera-pose node at line 99. That location is where the call failed, not where the fault lives.

If your link drops while the program is running instead, that is a different failure with a different fix: see fixing intermittent XML-RPC vision server drops.

Why a power cycle breaks it

A controller boot is a sequence, and the program can start before it finishes:

1. Controller operating system.
2. Robot runtime.
3. Plugins, including the vision plugin.
4. The plugin's local service binding 127.0.0.1:33004.
5. The camera link, when the camera draws power from the controller.

An auto-started or operator-started program can reach the camera-pose node while step 4 has not happened yet. The request hits a port with no listener and comes back refused. Anything that restarts the plugin without a full boot, such as a plugin update, a controller restart or a service crash, reproduces the same signature.

Cameras powered from the controller widen that window, because the camera itself has to re-link after power returns. Controllers with PoE camera ports, such as the MV-VC5525-256G70-NN, switch camera power with their own power state, so the camera re-links only once the controller is up.

What you need

• Edit access to the robot program, on the pendant or offline.
• The vision plugin's initialize or open-connection program node: the program-level equivalent of the installation panel's refresh action. Every vision plugin exposes some form of it; the node name varies by plugin.
• A fault routine that stops the cell cleanly with a message.
• Your logged error signature: host 127.0.0.1, port 33004, the node name and the line number.

If the camera is a smart camera that runs its inspection on the device and serves results over Fast Ethernet, such as the MV-SC3050XC-16M-ATN-H, the same cold-start behavior applies to the camera's own address after it regains power.

The fix: re-open the camera at program start

1. Open the main program, the one the cell runs after every power-up, not a subroutine.
2. Insert the initialize node at the very top, before the first node that requests a result and before any motion that depends on a pose.
3. Wrap it in a retry: attempt the initialize, wait a fixed interval on failure, and repeat up to a fixed attempt count.
4. On success, fall through. The pose request that follows now finds a listener on the port.
5. On final failure, jump to the fault routine: stop, write the error to the log, and request no pose from a dead service.
6. Leave the manual refresh in the installation panel for commissioning and troubleshooting only.
7. Record the node and its line in the cell documentation, so maintenance finds it without reading the whole program.

The retry costs nothing when the link is already up: a single loopback call succeeds on the first attempt.

Worked example: first cycle after a weekend power-down

Inputs, all from the cell:

• Retry attempts: 5.
• Retry interval: 2 s.
• The camera-pose node sits at line 99, the point that threw the refused connection.

Rule: the service either binds inside the retry window or it does not.

Arithmetic: 5 × 2 s = 10 s of worst-case delay added to the first cycle. If the service binds during attempt three, the delay is 4 s. If the controller was never powered down, the delay is one successful local call and the cycle time does not move.

Decision: with a 10 s budget, the first part after any power event runs unattended, and a service that has not bound within 10 s is a fault, not a slow boot. Compare that with the manual path, where an operator leaves automatic mode, opens the installation panel, refreshes and restarts, once per power event. The program node is worth adding the first time an operator has to walk over.

How to verify the fix

Three tests, in order:

1. Warm start. Start the program on a live cell. The first initialize succeeds and the cycle time is unchanged.
2. Cold start. Power the controller down, power it up, and start the program in automatic the way production does. The first part runs and the log shows one recovery.
3. Dead camera. Switch the camera off, then start the program. The retries exhaust in 10 s, the cell stops on the fault routine, and no motion runs on a missing pose.

Write the initialize result to the controller log in every test, so a recovery months later shows up as data instead of a mystery. For a camera that dies while the program is running rather than at start, add camera disconnect detection without stopping the program.

When it is not the cold start

• Refresh does not fix it, or the failure also happens in manual mode. The plugin's local service is crashing or the plugin build is broken. Startup bugs of exactly this class have shipped in camera plugins and were fixed in the following release, so after any plugin update, re-run the cold-start test before trusting it. Plugin upgrades have also arrived with program formats the previous plugin could not load; plan the rebuild in the new node structure before upgrading, not after.
• The request times out instead of being refused. Something answered, but the far side never returned. Check the camera's address and subnet first; a camera that fell back to a link-local address produces this pattern. See opening a GigE camera on a link-local address.
• A USB camera that has power but is not detected is a different link layer with its own checks: USB link checks after a cable swap.
• The initialize node itself fails on every start, warm or cold. That is a start-sequence problem in the vision system, not a power-cycle problem: fixing a camera failed-to-initialize error.

Make every start a known-good start

Program-start re-init covers the controller reboot, because program start always follows boot. Three habits complete it:

• Do the inspection once at program start and save the pose for the cycle; running the camera inspection once at program start covers where that call belongs.
• Bring the vision system up without an operator after a controller boot with auto-starting the vision system at robot controller boot.
• After a robot fault mid-run, shake hands again before the next result request; re-handshaking the vision job at cycle start gives the sequence.

Power events clear state well beyond the vision link. On the PLC side, program changes lost after a power cycle is the same class of failure. Robot controllers also differ in whether a restarted cycle re-enters the main program at all; returning to the main program on cycle start covers that setting.

If you are building the cell rather than patching it, one host simplifies all of this. A compact vision controller such as the MV-VC3301H-128G66 drives its lights from 4 built-in channels, so cameras, lights and processing share the same power state and boot order, and the retry rule has a single target.

Checklist before you sign it off

• Initialize node at the top of the main program, ahead of the first result request.
• Retry wrapper in place: fixed attempts, fixed interval, fault routine on final failure.
• Cold-start test passed in automatic mode, with the recovery visible in the log.
• Dead-camera test faults cleanly, with no motion on a missing pose.
• Plugin version and the node's line number recorded in the cell documentation.

When the camera side needs more than a program fix, the smart cameras and vision controllers ranges cover the hardware, and the contact page reaches our applications team for the integration question.