Embedded vision system project setup: target discovery checklist

You built the project, opened the target tree, and the embedded controller you need to deploy to is simply not there — no target, no folder, nothing to select. On a new embedded vision system project setup this is one of the most common first-day faults, and it is almost never a broken controller. It is a software gate, a power or link fault, a subnet your engineering PC cannot reach, or a missing runtime on the target itself. This checklist walks those four gates in the order that finds the fault fastest, gives the test for each, and shows the subnet arithmetic with real numbers. By the end you will know which gate is yours and what to change.

Why is the embedded target missing from the project device tree?

Because one of four gates has failed: the development software you installed does not support that controller generation, the controller is unpowered or has no link, your engineering PC and the controller are not on a mutually reachable subnet, or the vision runtime is not yet installed on the target. Each gate hides the symptoms of the gates after it. Software that does not know the controller cannot list it, powered or not. A controller with no link cannot be asked anything, and a subnet fault looks identical to a power fault from behind a keyboard. Test in this fixed order, because two of the four gates take only a link light and a ping:

• Software support — the module set on the engineering PC must match the controller generation; the checks in smart camera software compatibility apply to embedded targets too.
• Power and link — link LEDs at both ends, then a ping to the controller's static address.
• Subnet reachability — controller and engineering PC on one shared, reachable network; vision software hang: two adapters on the same subnet is the classic trap here.
• Runtime on the target — the vision runtime engine present before deployment; a deploy that stops part-way points to vision project controller mapping: diagnose transfer failures.

Does your installed software support that controller?

This is the first gate to clear: the module set on your engineering PC — real-time support, the vision library, the application builder — must be the generation the controller's firmware was released for, or the target type is silently omitted from the tree. Omitted, not shown-and-failing: that is why nothing you change on the network makes any difference. The authority is the support table in the controller's release notes, which names a minimum module version and a tested range for each firmware release. A development environment one major version newer than the tested range drops targets just as effectively as one version older.

Tool choice follows the target, not the other way round — embedded tool selection starts with target and build support. When the hardware you inherited is not on any supported list, adding it becomes a target integration project of its own, the route described for a third-party PC/104 target in an embedded development environment.

Is the controller powered and answering on the network?

Check the physical layer before anything else: a link light on both ends, then a ping to the controller's static IP. A controller that answers ping but shows no target has failed the software or runtime gate. No ping at all is a power, cable or addressing fault. Look at the ports before you reopen software: link LED at the controller and at the switch, activity flicker, and the controller's status indicator settled after boot. A ping reply means power, cable and addressing are all good — skip to the software or runtime gates. No reply means stop debugging software: swap the cable, move to another port, measure the supply.

If the controller powers its cameras through PoE ports, the cameras enumerate after the controller finishes booting. A camera missing in the first minute after power-up can simply be late rather than broken. What to confirm on the port itself is in does my camera support PoE.

Which subnet does the target have to be on?

On the same subnet as the network adapter that will talk to it: each camera and the controller port it connects through must share one subnet. Discovery across a router needs a configured route, because broadcast discovery stops at the router. First bring-up therefore belongs on one flat network: the engineering PC's adapter, the controller port and every camera behind that port on the same subnet. Unicast discovery to a known address can cross a routed link later, once a gateway is on the path.

Worked example: your engineering PC adapter is set to 192.168.21.203 with mask 255.255.255.0. That adapter lives on the 192.168.21.0/24 network, which holds 2^8 − 2 = 254 usable addresses, 192.168.21.1 through 192.168.21.254. Assign the controller 192.168.21.10 and the first camera 192.168.21.40 — both inside the range, neither sitting on the broadcast address 192.168.21.255 — and a rescan finds both. A camera still holding a factory address outside 192.168.21.x is invisible to this adapter however healthy it is: give it an address in range with the maker's IP configuration tool, or add a route to its current subnet. Keep any second adapter, for example the office link on 192.168.100.x/24, on its own subnet — two of your adapters in one subnet lets the operating system answer discovery out of the wrong interface.

One port rule completes this gate: GigE Vision discovery runs on UDP 3958 (GVCP). A host firewall on a public profile drops inbound UDP by default, so the device stays invisible while ping still works. Allow inbound UDP 3958 for the vision software before concluding the device is at fault.

Controllers that group their ports make the plan explicit. The MV-SVC2506-16G60-128G splits traffic by design: 4 camera GigE ports, 1 configuration GigE port and 1 communication GigE port, so cameras, your engineering PC and the PLC each land on a network of their own.

For keeping each camera on its port across reboots, assigning cameras to ports reliably in a multi-camera system covers the ordering rules.

Does the vision runtime have to be installed first?

Yes: the controller needs the vision runtime engine installed on it before a project will deploy, and on some stacks before the target even shows its vision features. A target that pings fine but refuses the project is telling you exactly that. The runtime is a separate install that lives on the controller, matched to the generation of the vision library on the engineering PC: the module on the PC compiles, the runtime on the target executes. Installing it after a failed deploy usually clears the fault in one pass. Deploying again and again against a missing runtime only fills the log.

The vision controllers line spans small cells to multi-camera lines. A compact model like the MV-VC2140-128G40-1T runs that runtime with an Intel N-series processor, 8 GB of memory and 3-4 LAN ports for a small cell.

How do you bring the target online, step by step?

Work the eight steps below in order without skipping any of them. The first step that fails names the blocking gate, and everything after that step stays unreliable until the gate is cleared.

1. Record the versions: controller firmware, development environment, real-time module, vision library, application builder. Compare them against the controller's support table before touching hardware.
2. Power the controller and let it finish booting; confirm link lights at the controller and the switch.
3. Set the engineering PC adapter to the target's subnet — in the example above, 192.168.21.203 with mask 255.255.255.0.
4. Ping the controller's static address, 192.168.21.10 in the example. No reply: fix cable, port or power before any software work.
5. Allow inbound UDP 3958 for the vision software in the host firewall, on every network profile.
6. Rescan the target tree. The embedded entry appears once steps 1 to 5 are clear.
7. Install or update the vision runtime on the target, then deploy a blank project and read the deployment log to the end.
8. Add cameras one port group at a time, assigning each a static address inside that group's range — 192.168.21.40 first in the example.

The sequence is finished when three things hold at once: the target appears without a rescan, a blank project deploys with a clean log, and a live image arrives from one camera per port group. The mistakes that undo it are short: two adapters in one subnet; the PLC sharing the camera subnet; a firewall profile that flipped to public when the PC docked on another network.

What if the controller is up but the cameras are missing?

Then the fault is downstream of the target: the camera subnet, the camera power, or the discovery port. The same three tests apply — ping the camera, check its power source, and confirm UDP 3958 is open end to end. Each port group is its own subnet, so test one group at a time. A camera that pings but will not enumerate has moved past networking into firmware and tooling. A camera that does not ping is an address, cable or power question, with the PoE checks from the power gate first.

On the camera side, a GigE area scan camera like the MV-CU020-90GC — 2.5 MP, color, C-mount — takes its address from the port group it lands in. A smart camera like the LS-SMC-0063 — 1.6 MP, 60 fps — carries the inspection inside its own housing and answers on a single address.

The camera finder filters by interface and resolution while the camera list is still open.

When is the missing target the wrong problem?

When the device you actually need to reach is a smart camera or a sensor that runs its own inspection, the project-on-a-controller pattern is unnecessary. Connect to that device's own interface instead of hunting for a target folder. Three cases, three decisions:

• Several cameras, heavy processing, results to a PLC: keep the embedded controller pattern, and let the controller's support table set your software versions before anything else is bought or installed.
• One fixed inspection, results to the PLC: put the inspection on a smart camera and skip the controller project entirely. Passing those results onward is its own task, covered in smart camera results as control data, and the live image question in what actually displays live in a PLC HMI.
• Analog cameras already on the station: an embedded controller with grabber support is one route, and decode or upgrade for an analog camera on an embedded vision controller lays out both.

What belongs on the bench checklist before the next station?

Four lines prevent almost every repeat: a written version manifest for firmware, runtime and development modules; a one-page IP plan per port group; a firewall rule allowing inbound UDP 3958; and a power-up order note that brings the controller up before the cameras. Run the list at every new station and after every update:

• Version manifest — firmware, runtime, real-time and vision modules, dated. An update on the engineering PC can drop target support without an error message; the machine vision software upgrade validation checklist is the fuller procedure.
• IP plan, one page per port group — subnet, mask, controller address, camera block, PLC range. Address collisions and unknown factory defaults are invisible until they stop the line.
• Firewall rule for inbound UDP 3958 — discovery dies quietly when a network profile flips, and the rule must cover every profile.
• Power-up order note — controller first, cameras second. PoE cameras enumerate late and get misread as faults when the order is reversed.

When the parts list is settled, the system configurator walks camera, lens, light and controller in one pass. If a target still refuses to appear after all four gates, send the version manifest and the IP plan to the applications desk — that pair of documents is what shortens the answer.