Vision app will not start: camera not found at startup

A vision application that refuses to start is rarely broken software. The app starts, asks the network for its cameras, receives no answer, and reports exactly that. The fix is a short ordered check: power, cable, subnet, visibility in a generic viewer, then two application settings — the number-of-cameras value and the camera serial numbers. This guide walks that order with the IP arithmetic for the subnet test, the setting that silently disables camera search, and the network faults that imitate a dead camera. It applies to GigE area scan cameras, Ethernet smart cameras and any vendor application that stores a camera list. Work through it once and you will prove which single item failed instead of swapping hardware at random.

Is the app broken, or is the camera just not visible?

In most startup failures the application is fine and the camera is simply not visible on the network, so prove visibility before touching software settings: no camera in any viewer means a network or power problem, not an app problem.

Any GigE Vision viewer lists a compliant camera, and camera vendors ship a viewer with their SDK; smart camera tools carry a device tree that does the same job. If the viewer lists the camera, power and network are good and the fault sits in the application's configuration. If the viewer also finds nothing, stop editing the app and work the power and network steps first.

Applications differ in their screens, but they all find cameras the same way: the transport layer sends a discovery request out of one network adapter and waits for replies. No reply, and the app reports no camera in whatever wording it uses. When the viewer and the app disagree, the disagreement narrows the fault to two places, covered next. If discovery itself never completes, the GenTL transport layer startup guide walks that layer.

Should you power-cycle the camera first?

Yes, once, at the start: a full power cycle clears a camera stuck after a power dip or a half-negotiated link, and it costs one minute. Repeated cycling without checking anything else wastes the outage.

Power the camera fully down — not a software reconnect — wait a few seconds, and power it again. Then confirm the physical layer: the camera's status LED shows power, and the link LED at both the camera end and the switch or PC end shows the Ethernet connection. The cable must land on the same network as the computer running the app; a camera moved to a bench switch over a weekend passes every later test and still never appears. A camera data cable with locking connectors holds that link where vibration works plugs loose:

Is the camera on the same subnet as the computer?

The camera and the network adapter it plugs into must sit on one subnet; with mask 255.255.255.0 that means the first three number groups match. A camera on 192.168.10.23 will never be found by a PC on 192.168.1.50.

Discovery is a broadcast, and a broadcast stops at the subnet boundary. The mask decides that boundary, so the test is one line of arithmetic per side:

Take a PC whose adapter holds 192.168.1.50 with mask 255.255.255.0, and a camera fresh out of its box on 192.168.10.23 with the same mask:

• PC side: 192.168.1.50 AND 255.255.255.0 = 192.168.1.0
• Camera side: 192.168.10.23 AND 255.255.255.0 = 192.168.10.0
• 192.168.1.0 does not equal 192.168.10.0, so no reply ever crosses, no matter how often the app restarts.

The fix works from either end: set the camera to a free address on the PC's network, for example 192.168.1.23 with the same mask, or move the adapter. Camera tools and viewers assign this address for you; once it is set, ping it — ping 192.168.1.23 — and a reply proves the path. The static IP setup walkthrough covers the assignment screens, and the same mismatch is the first thing the smart camera connection checklist rules out on Ethernet smart cameras.

One more host-side item: the operating system's firewall can silently drop the discovery packets. Allow the viewer and the application on the camera's adapter, and on a production network do it through your IT policy rather than by switching the firewall off. Any GigE area scan camera follows the same rule once the subnet is right:

Why does the camera show in a viewer but not in the app?

Two causes: another program holds the camera open with exclusive control, or the app is configured to look for zero cameras. Close every other vision tool, then check the app's system configuration before blaming the camera.

GigE Vision cameras serve one controlling application at a time. A viewer left open, a second copy of the app, or an SDK demo from last week's testing holds that slot, and the app then fails to open a camera it can plainly see. Close them all — on a shared PC, check what else enumerates cameras at login. The full failure pattern and its fixes are in GigE camera open fails in a second tool: exclusive control.

If nothing else holds the camera, the remaining difference between a camera the viewer sees and a camera the app misses is configuration inside the app itself, and one setting causes most of it.

What should the number-of-cameras setting be?

Set it to the number of cameras you actually wired, and it must be greater than zero for the app to look at all. A three-camera station reads 3; a value of 0 makes the app start and find nothing.

Vendor applications store a camera count in a system settings or system configuration screen, usually one menu below the main window. The value tells the app how many devices to expect before it declares itself ready. On zero it expects none: the app starts, reports no cameras, and looks exactly like a broken install while every camera sits on the network working.

Match the wired count in both directions. Set 3 with two cameras wired and the app can block forever waiting for the third; set 1 with three wired and two cameras stream to nobody. The count is not a guess either — how many cameras an inspection needs follows the face coverage you must see, so the number in the settings box should trace back to that plan.

Why does the app need the camera serial number?

Because the serial number binds a configuration to one physical camera, and log messages identify devices by serial number. Enter it before saving settings; a missing serial leaves the app scanning for a camera it cannot name.

The serial is printed on the camera label and listed by any viewer that finds the device:

With several identical cameras on one station, the serial entries keep exposure, trigger and mounting assignments glued to the right physical device across restarts. Swap two cables and the app still opens the camera it was told to open, by serial. USB stations add a twist: identical cameras can enumerate under the same name, and selecting by port fixes it — the method is in two identical USB cameras: same name, open one by port. Smart cameras enumerate over Ethernet like anything else on the subnet:

After entering serials, save the settings and restart the application. Apps that read their camera list only at startup will not see a corrected entry until they restart, which is why save-and-restart is one action, not two.

What network faults look like a dead camera?

Three, in order of likelihood: a duplicate IP address on the network, a firewall blocking discovery, and two network adapters in the PC on the same subnet. Each fails differently, and each has a one-minute test.

Duplicate addresses come from cloning a station or reusing an address list. Two devices answering one address produce inconsistent discovery — sometimes one camera appears, sometimes the other, and the app fails at what looks like random. Power the cameras one at a time and ping the address after each; two replies to one address is your fault found. Give every camera a unique address, in use or not.

A firewall that drops discovery packets looks like an empty network. The test is to allow the viewer and the app on the camera's adapter and rediscover; if the camera appears, keep the rule and move on.

A PC with two adapters on the same subnet can hang the vision software or hide cameras from it entirely, because discovery leaves through the wrong adapter. The symptoms and the split are covered in vision software hang: two adapters on the same subnet. Stations with many cameras have their own startup pattern, where enumeration races itself — see camera discovery startup contention in multi-camera systems. And when the failure appears only with several sensors connected, isolate the sync fault before replacing anything, as camera open fails only with multiple sensors demonstrates.

What order do you check in?

Work from power outward to the app: supply, link, subnet, viewer, exclusive control, count, serial, restart. That order finds the fault in under fifteen minutes on a bench and needs no extra hardware.

1. Power the camera fully off and back on; confirm its status LED.
2. Confirm the Ethernet link at both ends, on the same network as the PC.
3. Run the subnet arithmetic above; fix the address, then ping it.
4. Open a generic viewer; the camera must appear there before anything else.
5. Close every other tool that could hold the camera.
6. Set number of cameras to the wired count — never zero.
7. Enter each camera's serial number exactly as the viewer lists it.
8. Save the settings, restart the app, and confirm it opens each camera by serial.

If all eight pass and the app still refuses to start, the fault is app-side: pull its log, note which serial the last message names, and take that plus your viewer screenshot to the vendor's support channel or to ours through the contact page. If the outage is your reason to re-spec the station instead, start from the camera finder or the configurator's camera step, and keep the checklist above taped inside the cabinet door.