Deploy custom code to a smart camera: match SDK and firmware versions

You wrote the inspection program on the bench PC, it passes every saved image, and the smart camera still refuses to appear as a deployment target. That symptom is rarely a network fault or a broken camera. The PC-side SDK and the camera firmware are sitting on different release lines, and a development environment lists as deployable only the targets whose runtime its installed driver recognises. This walkthrough gives you the version rule, the steps to align a driver and a firmware, the way to package every dependency so the program runs on the camera and not just on your PC, and the checks that prove the deployment before you wire the trigger. It applies whenever you deploy custom code to a smart camera, and again when a vision controller takes over multi-camera work.

The version rule that decides whether the camera appears

A smart camera runs two halves of one software system. The PC half is the SDK and driver package your development environment builds against. The camera half is the firmware and runtime image the device boots. Discovery is the handshake between them: the environment asks its installed driver which remote targets it can manage, and the driver answers only for devices running a runtime from the release line it was built for. Ping, the camera's web page and the vendor utility will happily talk to a camera on the wrong line; the deployment target list is the one view that enforces the pair.

So the decision is an equality test on the first two version numbers, major and minor, on both sides:

Worked example, with example numbers rather than a real release pair. Your project builds against driver 4.7.2, so the PC line is (4, 7). Camera A reports firmware 4.7.9, line (4, 7): major 4 equals 4, minor 7 equals 7, and the target appears. Camera B reports firmware 4.3.1, line (4, 3): major 4 equals 4 but minor 7 does not equal 3, so camera B stays invisible to the project no matter how many times you refresh. Moving camera B to the 4.7 firmware line fixes it without touching the PC. Rebuilding the project against the 4.3 driver fixes it the other way. Change one side at a time, and read the version back from the device after every change.

The same drift returns later as a runtime fault: a camera and driver that were aligned on day one start failing detection after someone updates one of them. Camera firmware version mismatch: fix detection failures safely is that symptom's repair path, and 3D camera header version mismatch: fix firmware and SDK alignment is the same rule for 3D sensors.

Manufacturers keep archived driver and SDK releases on their portals for exactly this realignment. The walkthrough on downloading an archived SDK release for an embedded board shows the usual path when the download page only offers the newest version.

What you need

• The development PC, with the IDE version your project actually uses.
• The SDK and driver installer for that IDE version, from the same release line as the camera firmware you will run.
• The camera firmware package for that line, plus the manufacturer's updater utility.
• Camera and PC on one subnet, with the camera at a known IP address.
• The source project and every dependency it resolves on the bench PC.
• A golden part, or a folder of known-good and known-bad images, for the final proof.

Two IDE versions on one PC are common in maintenance work; step 4 below covers them.

Align the versions step by step

1. Read the camera's firmware version from the vendor utility or the camera's own status page, and write it down as major.minor.
2. Read the driver and SDK version from the installed-programs list or the installer name, and write it down as major.minor.
3. If the lines differ, decide which side moves. A project already validated against one driver line usually moves the camera: flash the firmware package from that line. A legacy camera that no longer receives firmware moves the PC instead: install the driver release built for the camera's line.
4. If the PC hosts two IDE versions, re-run the driver installer and add project support for the older one. An installer registers support for the environments it finds at install time, which is why a second, older IDE often shows no target entry until you re-run it.
5. Reboot the camera after a firmware change, then read the version back from the utility. Trust the device's answer, not the last file you flashed.
6. Refresh the target list in the IDE. The camera should now appear under remote targets or devices; add it to the project so the deployment commands appear.

If the versions match and the entry is still missing, the driver package itself is damaged or half-installed. Camera driver package not configured: restore camera detection covers that repair.

Networking hides targets too. GigE Vision discovery runs as UDP broadcasts on port 3956, so a host firewall that filters subnet broadcast, or a second network card on a different subnet, hides every camera regardless of version.

Python stacks add one more pair: the GenICam package and the interpreter. GenICam Python package not found: match your interpreter applies the same rule one layer up.

Build the distribution with every dependency

A program on the bench PC resolves its libraries from that PC. The camera has no bench PC, so the package you deploy must carry everything.

1. Create the project in the IDE and add the camera as its target.
2. Add the main program, every subprogram it calls, and the libraries, model files and calibration files those subprograms need. Do not list dependencies from memory; use the environment's save-for-distribution or build command so it collects them.
3. Name the package after its version pair, for example inspection_47.zip built for driver line 4.7 / firmware line 4.7. The deployed file then records its own compatibility on the device.
4. Run the built package on the bench PC against the same driver line before pushing it. A build that fails on the bench fails on the camera, with less feedback.
5. Check the camera's storage budget. The runtime, your package and any logged images share one device; smart camera program storage and offline editing explained covers what the device keeps and what it drops on reboot.

Where the stack is containerised, pin the SDK version in the image itself. Pinning one SDK version in a Docker build is the same discipline applied at build time, and SDK version pinning on edge inference devices shows the crash pattern when nobody pins it.

Deploy and prove it on the camera

1. Deploy the package to the camera target from the project, then set the deployed program to run at startup.
2. Reboot the camera and confirm the startup indicator: a running status output, a heartbeat line, or the first result string.
3. Trigger the deployment the way the line will: hardware trigger in, result out. Starting an inspection automatically from a custom program covers the handshake once the program runs.
4. Run the golden-part proof. We hold a deployment until it passes 20 consecutive known-good parts and rejects every known-bad part, because 20 consecutive passes catch the dependency and storage faults that single shots miss.
5. Time the cycle against the line's takt. A program that inspects correctly but misses every third part at production speed is not deployed; it is late.
6. Archive the rollback pair: the previous firmware package and the previous program build. A bad realignment then costs minutes, not a day.

Mistakes that cost a day each

• Updating the camera firmware alone because the updater offered a new version, then losing the target until the pair is realigned.
• Deploying a package whose libraries resolved on the development PC; it starts on the camera and stops at the first missing dependency.
• One driver support pass on a two-IDE PC; the older environment never sees the target and the blame lands on the camera.
• A host firewall or a VLAN filtering subnet broadcast, blamed on versions instead of networking.
• A driver package built for the wrong architecture or operating system; the installer succeeds and the target never appears.

Where the program should run: camera or controller

Commit with takt time and camera count. Measure the algorithm's per-image time on the target hardware and compare it with the takt, less the share owed to trigger and I/O.

For the common case, one view, one program, one trigger line, a smart camera is the right and simplest target to keep version-paired. The camera finder filters them by interface, resolution and shutter. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with a GigE interface, a 1/2.4" rolling-shutter sensor and an M12 mount, which fits the single-view workflow described above.

Heavier on-camera code wants compute headroom on the device itself. The LS-SMC-0017 is an X86-platform smart camera with an 8.8 MP global-shutter sensor in a 1" format and a C-mount, so the same deployed-program workflow runs with room for larger models.

The same version pairing governs the rest of automation: deploying model-generated code to a PLC succeeds only when the generator and the controller firmware line agree, which is the test you just learned. When the inspection outgrows one camera, move the program to a vision controller and pin one SDK line for every camera on it. The MV-VC3301H-128G66 pairs an Intel Core i3 processor with 8 GB of memory, 5+ LAN ports and 4 built-in light-controller channels, and includes a VM6200Pro license.

Deployment checklist

Before you deploy:

• Driver major.minor and firmware major.minor read from the devices and written into the project notes.
• Dependency list produced by the build command, not from memory.
• Golden part set staged where the camera program can load it.
• Rollback pair archived: previous firmware package and previous program build.

After it runs:

• Startup run confirmed from a cold reboot.
• 20 consecutive passes on known-good parts, rejection of every known-bad part.
• Cycle time at or below 80 percent of takt, so trigger, I/O and jitter keep their share.
• Deployed package name carrying the version pair it was built against.

Pick the hardware from the smart cameras category, compare vision controllers for multi-camera lines, or start at the system configurator and work from the camera out. If a target still hides after the version pair matches, the contact page reaches our applications team, and the systems guides cover the integration steps around the deployment.