Station.Cameras.Add gives an unknown error: init first

You compiled an SDK example that adds a camera to a station, started the simulator, created a new station, and the line that should register the camera died with a bare "unknown error". Other examples from the same SDK run fine in the same session, so the install, the references and the license are not the problem. The fault is in the order of your calls. This guide ranks the four causes behind an unknown error at station.Cameras.Add, gives you a test for each, and works the fix that settles most cases: run the add after the station has finished loading, inside a catch block that logs what the generic message hides.

Make the error talk before you change anything

An SDK reports a failed add as one generic code because every cause funnels through the same collection method; the details sit in the exception the SDK caught on your behalf. Catch it yourself and log the whole object, not just the message:

try
{
    station.Cameras.Add(myCam);   // the example's own station and camera objects
}
catch (Exception ex)
{
    Log(ex.ToString());           // Log stands for the logging call your project uses
}

ex.ToString() prints the call stack plus every inner exception, and the inner text names the real fault: a message about the camera name points to a name conflict, one about the model or its emulation points to an unsupported simulated camera, and one that complains the object is not ready points to initialization. Run this once before you try any fix; it turns the rest of the work from guesswork into reading.

Cause 1: the station is still loading when you add

The most common cause, and the one a fresh-station failure points at first. Your code runs the moment the station object exists, but existing is not ready: the camera collection is served by the station controller, and the controller registers its camera list during loading. An add that arrives before that finishes is rejected, and the rejection reaches you as the generic unknown error.

The test takes a minute: run the same add from a button or menu command after the station has visibly finished loading. If the delayed add succeeds, the cause is proven. The fix is to move the call: run it from the handler of the event your SDK raises when station loading completes (each station SDK documents one; look on the station or controller class), or run it after your connect or open call has returned successfully.

Loading order bites elsewhere too: camera configuration lost after a job load is the same fault family on the configuration side, and the cure is the same - respect the sequence the object model expects.

Cause 2: a camera name the station already holds

Station object models key their camera collection by name, so a second add under a name the station already holds fails on the spot. This reaches a fresh station when the example hard-codes a camera name and you run it twice, or when the station template already contains a camera with that name. Test: change the name to something unique and rerun. Fix: set a unique name before the add call, or take the generated name if your SDK offers one.

Cause 3: the simulator does not emulate that model

A station simulator emulates a fixed set of camera models. Ask it to add a camera whose model sits outside that set, and the add fails no matter how correct your order is. The GUI hands you the list: whatever the simulator's own camera menu offers is what the add accepts. Test: add a model from that list with the same code. If it succeeds while your model fails, you have the answer. Fix: debug the example against an emulated model, keep the call sequence untouched, and swap in the physical camera once the add and the property reads work. Simulation proves your code's structure, not the sensor.

Worked example: the add that fails at station creation

The inputs, and where each comes from:

• The failing line is station.Cameras.Add(myCam);, executed right after the example creates the new station (your setup).
• Other examples run in the same session, so the toolchain and licensing are sound (your setup).
• The polling budget is a starting point, not an SDK constant: check readiness every 100 ms, cap at 50 checks.

The rule in words: an add lands only after the station controller finishes loading, which the SDK signals with its load-complete event; everything before that event is rejected as unknown. The sequence that works:

1. Create or open the station, and subscribe to the load-complete event before the load starts, so the handler cannot miss it.
2. Inside the handler, run the add in a try/catch and write two timestamps to one log: event fired, add attempted.
3. Read the log: the add must come second.
4. If your SDK exposes no event, poll instead: 50 checks × 100 ms = 5,000 ms = 5 s of budget, then log and stop. If a large layout needs longer, raise the cap to 100 checks (10 s); do not shorten the interval, because 100 ms is already fast enough not to slow setup down.
5. Decision threshold: an add that still fails when the log shows the loaded event first is not an ordering fault - read the inner exception from the same log and move to the name and model causes.

The same order on a physical camera

Once the logic works you swap the emulated camera for hardware, and the rule travels with you: bring the interface up, let the camera enumerate, then configure, then acquire - never the reverse. The failures that look like this one at that stage are ordering failures again: camera emulator timeouts after run mode is the hardware-side twin of this fault, and a flaky test on leftover settings shows why every run should start from a known state.

Pick the camera from the area scan cameras category - the camera finder filters by interface, resolution and shutter. Run it on one of the vision controllers.

Size the controller by LAN port count for the cameras you will run and by built-in light channels; the category filters list both, and the camera step of the configurator walks the camera choice in order. When a state works in setup but fails at run time on hardware, locate that works in teach but fails at run time covers the snapshot-versus-stream version of that gap.

Prevention checklist

• Hook the add to the load-complete event, never to the code that creates the station.
• No event in your SDK? Poll the loaded state every 100 ms with a cap of 50 checks, then log and stop.
• Wrap every add in a try/catch and log the full exception, inner exceptions included.
• Set a unique camera name before the add; never run the unmodified example twice into one station.
• Emulate a model from the simulator's own list until the add and the property reads succeed.
• Keep the sequence when you move to hardware: connect and enumerate first, configure second, acquire last.
• Log the loaded and add timestamps together from day one; their order in the log is the diagnosis.

The decision, case by case: the add succeeds only after loading finishes - fix the hook (cause 1). The inner exception names a conflict on the camera name - rename before the add (cause 2). Only one model fails - emulate a listed model until the logic is proven, then swap hardware (cause 3). Every path starts the same way: catch, log, read. More fixes in this family sit on the systems topic page, and if the fault survives the swap to a real camera, send the log through the contact page - free expert support comes with every order.