Camera plugins on a robot controller are the one piece of cell software that can stop the controller from starting when you remove them carelessly. Camera makers publish exact uninstall procedures because the failure is real: on one cobot family, a wrist-mounted camera plugin uninstalled out of order left controllers dead at a black screen on power-up, and recovery meant reloading the controller software from service media. This guide gives you the order that keeps the controller booting — stop the camera process first, run the uninstall the vendor's note describes, remove the plugin from the controller's active list, restart the pendant software, and only then cycle power. It also lists the checks to make first, the proof that it worked, the mistakes that cause the no-boot, and the port arithmetic for moving the inspection off the pendant entirely.
Why removal in the wrong order stops the boot
The pendant software keeps a list of active plugins and loads every entry in it at power-up. A camera plugin usually has two parts: the plugin the pendant loads, and a vision server process that talks to the camera over USB or Ethernet. Uninstalling is therefore two operations — unregistering the plugin from the active list, and removing the server software and its files. Done out of order, the controller boots, reaches a half-removed entry, and stops before the operator screen appears. That is the black screen.
The makers whose plugins caused this now print the button-by-button order in their manuals. Treat that order as part of the cell design, not as a suggestion. The same start-up discipline governs the rest of the stack: a camera that is not enumerated cleanly at power-up fails discovery for a different reason, which we cover in GigE camera not discovered on startup: fix the boot order. And if the controller boots but your trained models are gone after a restart, that is configuration loss rather than plugin removal — see Missing vision models after restart: fix and validate.
What to have in hand before you start
- The vendor's uninstall note for your exact plugin version and controller software version, open next to the pendant. Button names and screen names differ between controller generations; the note is the authority.
- A backup or export of the robot program and installation, proven restorable. The uninstall should not touch programs, but you do not prove that on a production cell.
- The reinstall media and installer, if a reinstall is planned. Keep the old installer until the new combination has run a full shift.
- One pinned version pair: match the plugin to the pendant software version and change one at a time. Edge inference device crashes: fix with SDK version pinning shows why a pinned pair beats a floating mix on any embedded vision host.
The uninstall order, step by step
- Put the cell in its documented safe state: no program running, nobody inside the safeguarded space.
- On the pendant, open the camera's own screen — the entry the plugin adds under the installation menu — and go to its dashboard tab. Press the stop-camera control and wait until the status reads stopped. Never uninstall over a running camera process; it is the same rule as in your own code, where you stop acquisition before you close the device, as in USB camera timeout on reopen: stop acquisition before you close. A dashboard you can watch for that stopped status is the same pattern as Vision software dashboard: camera monitoring for every application.
- Run the uninstall control on that dashboard tab if the vendor's note includes one; it removes the vision server software while the plugin can still supervise the process. Remove the USB storage device only at the step the note lists, and never while the server runs from it.
- Open the controller settings, then the system screen that lists installed plugins. Select the camera plugin in the active list and press the remove control. This is the step that unregisters the plugin; it is not a file deletion.
- Restart the pendant software when the screen asks. Wait for a clean reload with the plugin gone from the list.
- Power the controller down and back up. Confirm it reaches the operator screen with no camera entry left.
- If you are reinstalling a newer version, work from the vendor's install note: format the USB stick as it specifies, place the plugin file and the vision-system folder at the root as it shows, and expect the exact prompts it lists. One maker's release note states that a popup error (CH-104) part-way through installing its 1.6.3 software is a required side effect, not a fault — read the note before you judge any popup.
- Run a test program and one full production cycle before you call the line ready.
The order is the same one your integration code follows when it shuts a camera down: streams stop first, the device closes last. Camera SDK hangs on exit: shut down streams in the right order is the reference version of that idea.
Checks that prove the uninstall took
- Clean boot to the operator screen, twice in a row.
- The camera plugin absent from the active list, and no camera entry left under the installation menu.
- The robot program runs and the PLC handshake cycles end to end. If your cell hands results to a robot or PLC, Vision picking restart handshake: images arrive but picks stop is the reference when the handshake itself misbehaves after any software change.
- No unknown-device entries on the USB bus if the camera was USB; no camera address answering on the network if it was Ethernet.
Five mistakes that end in a no-boot
- Deleting the plugin's folder in a file browser instead of unregistering it in the settings screen — the active list still names it at power-up.
- Uninstalling while the camera process still runs from its dashboard.
- Skipping the pendant restart and pulling power instead, so the runtime never finishes writing its state.
- Pulling a USB stick or license dongle the vendor's note says must stay connected.
- Upgrading the controller software with the plugin still active instead of using the maker's combined update-and-uninstall note.
If a plugin refuses to load after a clean reinstall, run the diagnostic order in Hand-eye calibration plugin load failure: diagnostic steps before you suspect the camera hardware.
If it is already too late
A black screen at power-up means the failure has happened; stop power-cycling, because it fixes nothing and risks the storage. Recovery is a reload of the controller software from the robot maker's service media, following its service documentation, then a restore of the programs and a re-validation cycle. Budget most of a shift. For the diagnosis sequence on a controller that will not start, troubleshooting a no-boot condition on an industrial controller walks the checks in order, and reloading system software on a robot controller shows what the reload step looks like on an older generation. Once the controller software is back, reinstall the camera plugin by its documented procedure before the cell returns to production.
Moving the inspection off the pendant instead
Often the uninstall is not maintenance — it is the first half of a relocation. A wrist-mounted camera plugin makes sense for presence checks and simple guidance; once the job grows to a dedicated station, the pendant should carry no vision at all. Two placements cover it. A smart camera runs the whole inspection on the device: the MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm M12-mount lens on GigE and needs no plugin and no controller software on the robot side.
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
For multi-camera stations with light control, a vision controller takes the processing instead: it speaks to the cameras over its own LAN ports, drives the lights from built-in channels, and hands results to the robot over the existing handshake. Browse the vision controllers or the shop's camera finder to see the range.
Worked example: LAN port budget for a one-camera cell
The inputs: the cell keeps one stationary GigE camera where the wrist camera used to be, plus the PLC handshake link and one engineering-access link — three Ethernet links in total. That is the typical post-removal case; the port counts come from the controllers' printed data.
The rule: one link per device, count them all, and keep at least one LAN port spare. When the link count reaches the port count, the next camera forces a controller swap, so that is the moment to step up a class.
The arithmetic: three links against a four-port block leaves 4 − 3 = 1 spare, so a 3-4 LAN port controller fits the single-camera cell. Adding a second camera gives 3 + 1 = 4 links against 4 ports — zero spare, threshold hit. The 5+ LAN port class restores the margin: 5 − 4 = 1 spare.
The decision: order the 3-4-port class for a single-camera station; step to the 5+ class the moment a second camera is on the plan. The MV-VC2140-128G40-1T is the 3-4 LAN port option, with 4 built-in light channels for the station's illumination. The MV-VC3301H-128G66 and MV-VC5525-256G70-NN carry 5+ LAN ports; the MV-VC5525-256G70-NN adds PoE camera ports and 8 built-in light channels.
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
Pre-uninstall checklist
- Uninstall note open, matched to the exact plugin and pendant software versions.
- Program and installation backup exported and proven restorable.
- Camera stopped on its own dashboard; status reads stopped before anything else moves.
- Media and dongle policy known: what stays in, what comes out, and at which step.
- Restart-to-clean-boot window scheduled; cell clear, lockout applied.
- Reinstall media prepared to the note, only if a reinstall is planned.
- Post-uninstall proof planned: clean boot twice, program run, handshake cycled.
If the relocation grows into a full re-scope of the cell, Scoping a machine vision system before you call an integrator keeps the specification honest before anyone quotes it.
Where to go next
If you are taking vision off the pendant for good, start from the smart cameras for on-device inspection or the vision controllers above for multi-camera stations, then configure a system and we will size the ports and light channels with you. For multi-line quotes, request a quote — include the camera count and the handshake type, and the port arithmetic above becomes an order in one pass.
Questions
Why does removing a vision plugin stop a robot controller from booting?
The pendant software loads every plugin named in its active list at power-up. If the plugin's files or process were removed while the registration stayed live, the runtime reaches that entry, cannot resolve it, and halts before the operator screen draws. Camera makers published exact uninstall procedures precisely because of this failure; recovery is a controller-software reload from service media, not a quick file fix.
Can I just delete the camera plugin's folder from controller storage?
No. The controller trusts the active-plugin list, not the folder tree. Uninstalling through the settings screen unregisters the plugin and removes its files in the order the vendor tested; deleting files by hand leaves a live registration pointing at nothing, which is the recipe for a controller that never boots. Use the settings screen, every time.
Do the USB stick and license dongle stay plugged in after the uninstall?
Follow the vendor's note exactly. Some camera systems run their vision server from the stick or a dongle, and their instructions state that neither should be pulled even after installation completes; removing either is among the causes of the failed boot. Reformat install media only at the step where the note says to, on a PC, never in the controller.
The pendant shows an error code part-way through a plugin install — is that the no-boot bug?
Usually the opposite. At least one camera maker's release note states that a popup error (CH-104) during the install of its 1.6.3 software is a required side effect of the update, and to continue. Read the release note for your exact version before you judge any popup; treating a documented side effect as a fault and aborting mid-install is its own way to corrupt the controller software.
Where should the vision run if it no longer belongs on the pendant?
Simple presence, code and guidance checks belong on a smart camera that runs them on-device. Multi-camera stations, light control and cycle-time-heavy processing belong on a vision controller with several LAN ports and built-in light channels, handing results to the robot over the existing handshake. The port-budget example in the guide is the sizing check; the robot then carries no vision software at all.



