Replace a camera and keep its original camera number

A camera dies on an eight-camera line, the software has called the cameras cam0 through cam7 since commissioning, and the replacement you just plugged in came up as cam8. Before you touch a single reference in your plant software, know this: in nearly every vision software package the camera name is an entry in the configuration tool's device list, not a property of the sensor, so you can give the new camera the old number in a few clicks. This guide walks the full swap: what to record first, why detection hands out the next free index, the rename itself, and the checks that prove the new cam3 before the line runs again. The same workflow covers GigE, USB3, Camera Link and CoaXPress systems.

Why the replacement arrives as cam8

Camera names are rows in a device list that your vision software keeps. At commissioning you named the eight cameras cam0 to cam7, and every program, recipe and database row references those strings. When cam3 disappears from the bus and a replacement appears, the software runs its detection pass and hands the newest device the lowest index not in use: cam8. Nothing is broken. The replacement works; it just answers to a name no program expects.

Numbering follows detection order, not connector position, which is why a re-plugged camera can land on a different index than before. That is the same problem assigning cameras to ports reliably in a multi-camera system solves at commissioning, and it is worth doing there so the device list and the panel wiring agree.

What you need before you start

• The old identity: the name (cam3), the interface, and the connector or frame-grabber port it used. Read it off your commissioning sheet, or off the device list while the failed camera is still connected.
• A replacement with the same interface and a close sensor class. The area scan cameras page shows the interface, mount and resolution filters that matter here.
• Access to the configuration tool's device list — the panel that shows every detected camera with its name.
• A stopped machine and your site's lockout applied.

The swap, step by step

1. Record the old identity. Note the name, the interface and the port. If the failed camera never got a name, note the slot it feeds in your program instead — that slot is what the rename has to satisfy.
2. Swap the hardware. Lock out, remove the failed camera, and install the replacement on the same cable and connector. Keeping the same port is half the job done.
3. Power up and open the device list. Refresh detection. The new camera appears under the next free index — cam8 in our eight-camera example.
4. Identify which physical camera it is. Cover the replacement's lens with your hand or blank its light for a second and watch which feed goes dark. On eight identical cameras this step is not optional.
5. Rename the new device. Right-click the camera in the device list and choose the rename command. Type the old name exactly: cam3, same case, no trailing spaces. If the dead cam3 entry is still in the list, retire or delete it first, then rename the replacement.
6. Save and reopen. Close the tool so it writes the device list, reopen it, and confirm the replacement now answers to cam3.
7. Re-enter the per-camera settings. Trigger line, exposure and gain ride with the device entry, and the replacement starts in free run, so set the per-camera hardware trigger configuration before anything moves.
8. Run one part and watch it land in the cam3 feed of your software, with the right orientation and focus.
9. Update the commissioning sheet with the new serial number under cam3, so the next swap starts from records that are true.

Prove the swap before you release the line

A name fixed is not a line ready. Run three checks, in this order.

Static image. Same field of view, same orientation, same focus position as the failed camera. If the replacement carries a different sensor, re-check focus and the ROI corners first, because those move first.

Trigger. Fire 100 trigger pulses and confirm 100 frames arrive, one per pulse, with no free-run frames between them.

Bandwidth and soak. This check matters most when the replacement is a different model. Take the LS-CMR-0166, a 12 MP USB3 camera that delivers its full 4000 × 3000 px frame at 30 fps, and check the stream against the link before you trust it:

A USB 3.0 port carries at most about 4 Gbit/s of payload after encoding, so the stream fits with 28% to spare: (4 − 2.88) / 4 = 28%. The same stream would overrun a 1 Gbit/s GigE link, so on GigE you would trim pixels, frame rate or bit depth until the numbers clear. Then soak it: at 30 fps, a 60-second run is 30 × 60 = 1,800 frames, and the pass mark is zero dropped and zero partially written.

Choosing a replacement that drops in

Match three things, in this order.

1. Interface. GigE to GigE, USB3 to USB3, so the port map, cabling and bandwidth plan survive untouched. If the failed camera was powered over its Ethernet port, confirm the replacement supports PoE as well — the PoE check to run before you buy takes two minutes. If you are choosing an interface for the next build rather than this swap, the GigE, USB3, Camera Link and CoaXPress comparison lays out the trade-offs.
2. Sensor class. Keep resolution and sensor format close so the lens, focus position and ROI carry over unchanged.
3. Mount. C-mount to C-mount. Every adapter ring you add moves the sensor back and shifts the focus position.

Where the exact model is gone, the cleanest substitution is a sibling that shares the sensor and differs only in the interface. On a 20 MP, 1" IMX183 class camera, the MV-CS200-10GC is the GigE colour version and the MV-CS200-10UM the USB3.0 mono version, both on C-mount — pick the one that matches the failed camera's cable plant and its mono or colour requirement.

When the cameras run through a frame grabber, the connector is part of the identity: the card's ports are numbered in hardware, and software typically maps port to camera name at detection. Note the failed camera's port before you pull it. If the card itself is the part that failed, start at the frame grabbers page — the replacement card's ports come back numbered as before, and the camera names still follow your device list.

When renaming is not enough

Some tools bind configuration to the serial number or the MAC address rather than the name. A rename is then cosmetic, and the supported path is the tool's persistent-identity or device-alias feature, which maps the old serial to the new camera once and keeps the settings attached. If your software offers neither, hold one name-to-device mapping table in your own code and change one row per swap instead of hunting references through every program.

Other cases you will meet on the bench:

• The replacement never appears in the list. On GigE this is usually an IP or subnet problem, not a dead port; work the enumeration chain for a GigE Vision camera that is not detected before you condemn hardware.
• The tool rejects the name you type. When identifiers are set from code, the value has to match the device's allowed set exactly — the GenICam enumeration invalid value guide shows how to read the valid entries before writing.
• Rename fails while the device is busy. A camera is owned by one client at a time; close the acquisition program first, per the one-camera-per-process rule.
• Every USB camera reports the same identity. The fixes live in USB port IDs that read the same on every camera and in opening one of two identical USB cameras by port.
• A network rename collides with another device. Renaming on the network has its own conflict cases; the smart camera network name guide covers them.

Make the next swap a five-minute job

A swap goes fast when the records exist. Keep at every station:

• a commissioning sheet per camera: name, interface, connector or frame-grabber port, serial, lens, trigger line, and the program slots it feeds;
• a spare camera with the same interface kept in the maintenance cabinet, so a swap never turns into a redesign;
• camera names labelled at the panel and at the connector, matching the device list;
• a screenshot of the detection list from commissioning, so you know which index each connector earned.

With those four records, the failure that opened this guide is a 15-minute job: swap hardware, rename cam8 to cam3, run 1,800 soak frames, release. Without them it is an afternoon of archaeology, and the archaeology is how mislabeled cameras end up shipping good parts as rejects.

When the shelf forces a different interface or sensor class, treat the change as a re-commissioning instead of a rename: size the new camera, re-do the port assignment, and expect to touch the recipes that reference the old model.

To have us spec a drop-in replacement for a failed camera, send the old model, the device list and a panel photo through the contact page. More diagnosis like this sits on the systems topic page.