An acquisition call fails with Invalid Session ID. Traced deeper, the chain also reports an invalid file name for the camera — while another program on the same PC shows live images from that same camera. If you are rewriting or porting vision code, especially off a legacy IEEE 1394 stack, this is the fault pattern you are standing in. This guide gives the diagnostic order that resolves it almost every time: prove the camera images in the configuration tool, confirm the session reference is opened and wired, then match the camera string to the name the active driver actually enumerated. You finish with a cause-test-fix table, a migration path with the bandwidth arithmetic, and a short checklist.
What the error text is really telling you
A session ID is a handle. The open call creates it, every grab, attribute write and close call consumes it, and it dies when the session closes. Invalid Session ID means the value you passed was never returned by a successful open in this process: the open was skipped, the open failed and its error went unwired, or the reference was lost between the open and the failing call. The current driver in that ecosystem (NI-IMAQdx) words the same fault as "Invalid camera session".
The second message, an invalid file name for the camera, is the same fault seen from the other end. The API asked the driver for a camera by name and the driver holds no camera under that name. Two messages, one root: a handle that does not resolve.
The rule that carries the whole diagnosis: a camera identifier is scoped to the driver that enumerated it. The same physical camera can be img0 under one driver and cam0 under another, and code built on the first driver will reject the second string every time.
First test: grab an image in the configuration tool
Open the vendor configuration tool — MAX in the LabVIEW/IMAQ ecosystem — and run a continuous grab. This gate decides everything downstream.
- The tool shows an image: camera, cable and driver binding are good, and the fault sits in your session handling or name string. Work causes 1, 2 and 4 below.
- The tool shows no image: no application on that driver will see the camera. Fix the binding first (cause 3), then retest.
The classic picture: the tool lists the camera as img0 and cannot grab, while a program running on a different driver grabs fine. That combination points at the driver binding before you read a line of code. If the tool lists no camera at all, start instead from camera detected but cannot be opened: fix the capture pipeline.
Cause 1: the session was never opened
Check this first; it needs no hardware fault at all. A default or zero reference fed to a grab produces exactly Invalid Session ID.
Test: put an indicator on the session reference immediately after the open call, and wire the open call's error output somewhere visible. A zero reference or an error in the cluster means the failing call never had a valid input.
Fix: structure the code as open, use, close — the session reference wired through every call in between, the error chain wired so a failed open stops execution instead of feeding a default value onward. One session per camera per process. The same skeleton for a DLL-based SDK is laid out in call a camera SDK DLL from LabVIEW: callbacks, buffers and snap.
Cause 2: the camera name does not match the enumeration
The string must equal what the active driver enumerated — prefix, digits, case. To the driver, img0 and cam0 are different cameras.
Test: read the enumerated name in the configuration tool and compare it with the string in your code, character for character. Copy it across; do not retype it.
Fix: change the string in the program, not the camera name in the tool. Renaming inside the tool can throw "bad camera file", because the name is bound to a camera description file the driver loads — here an .iid pointer file that names an .icd description. When the pointer goes stale, delete the .iid file on disk or repoint it to the correct .icd and let the tool regenerate the entry. If names shift between reboots, read frame grabber interface name mismatch: fix bad interface errors.
Cause 3: two drivers claim the same camera
Legacy IEEE 1394 stacks allow a vendor acquisition driver and a generic bus driver to sit on the same port. In the LabVIEW world this was routine: one program on the IMAQ1394 calls, another on the plain IMAQ calls, both pointed at the same camera. "The camera ID is the same in both programs" proves nothing, because each driver enumerates independently.
Test: in the configuration tool, find the driver assignment for the device, switch it to the driver the failing code uses, and try the grab again.
Fix: set the active driver to the one your code's API needs. Accept the trade-off — the other program may stop working, because it needs the other binding. The durable decision on these stacks: rebuild the second program on the same API as the working one, or migrate the camera, which the next section sizes up.
Cause 4: a stale session from an earlier run
An open that never closed — a crashed run, an aborted stop, a missing close on the error path — holds the device. The next open fails, and the failure surfaces downstream as an invalid session.
Test: restart the process, or the whole PC if the driver is stubborn. If the error clears after a restart and returns after some hours of running, you have a lifecycle leak, not a naming fault.
Fix: close the session on every path, error paths included, and keep one session open for the application's lifetime rather than opening per frame. Two write-ups cover the pattern in depth: camera open close cycles leak handles: keep one session open and camera still held by another process: release GigE control.
Cause, test and fix at a glance
| Fault | Fastest test | Fix |
|---|---|---|
| Session never opened | Indicator on the reference after open; check its error output | Open, use, close; one session per camera |
| Name mismatch | Compare the code string with the tool's enumerated name | Use the enumerated string; repair stale .iid to .icd pointers |
| Wrong driver bound | Continuous grab in the configuration tool | Set the active driver the API needs; expect the other program to break |
| Stale session held | Restart the process | Close on every path; one long-lived session |
Migrate: when the 1394 stack is the real problem
If cause 3 is your verdict, patching bindings only keeps a dying stack alive. IEEE 1394a tops out at 400 Mbit/s on the bus, about 50 MB/s, the cameras are long past end of life, and the dual-driver conflict you just diagnosed is structural. GigE Vision replaces it with standard Ethernet, one standard driver class and a unique serial-based name per camera, so the name-versus-driver fault class effectively disappears. USB3 Vision covers short runs where cable reach does not matter.
Size the link before picking a camera. Illustrative inputs: a 2 MP mono camera, 8-bit output, 25 fps.
That is 40% of a GigE link's 125 MB/s raw capacity, comfortable once protocol overhead takes its share. A 5 MP camera at 30 fps needs 5 MB × 30 = 150 MB/s ≈ 1.2 Gbit/s, which overruns GigE — that camera calls for 2.5GigE or 10GigE. Decision rule: keep pixels × bytes per pixel × frame rate under roughly 100 MB/s per 1 Gbit/s link; past that, step the interface up along with the camera.
For a straight swap the resolution ladder looks like this:
| Specification | MV-CU020-90GC | MV-CT0MG0060/R/NN/NN | MV-CS200-10GC |
|---|---|---|---|
| Sensor type | CMOS, global shutter | CMOS, rolling shutter | CMOS, rolling shutter |
| Sensor model | GMAX4002 | Sony IMX178 | Sony® IMX183 |
| Pixel size | 4 μm × 4 μm | 2.4 μm × 2.4 μm | 2.4 μm × 2.4 μm |
| Sensor size | 1/1.7" | 1/1.8" | 1" |
| Resolution | 2048 × 1200 | 3072 × 2048 | 5472 × 3648 |
| Max. frame rate | 49 fps @ 2048 × 1200 Bayer GB 8 | 19.5 fps @ 3072 × 2048 Mono 8 | 5.9 fps @ 5472 × 3648 |
| Dynamic range | 66.9 dB | 71.3 dB | 65.5 dB |
| SNR | 40.8 dB | 41.3 dB | 41.5 dB |
| Gain | 0 dB to 11.1 dB | 0 dB to 24 dB | 0 dB to 24 dB |
| Exposure time | 4 μs to 10 sec | 25 μs to 3.1 sec | 46 μs to 2.5 sec |
| Exposure mode | Off/Once/Continuous exposure mode | Off/Once/Continuous exposure mode, supports Rolling and Global Reset | Off/Once/Continuous exposure auto, supports Timed and Trigger Width exposure mode, and Rolling and Global Reset sensor shutter mode |
| Pixel format | Bayer GB 8/10/10Packed/12/12Packed | Mono 8/10/10Packed/12/12Packed | Mono 8/10/12, Bayer GB 8/10/10p/12/12p, YUV422Packed, YUV422_YUYV_Packed, RGB 8, BGR 8 |
| Price | $309.00 | $909.00 | $739.00 |
All 3 share: Binning Supports 1 × 1, 2 × 2, 4 × 4; Lens mount C-mount; Humidity 20% RH to 95% RH (no condensation); Compatibility GigE Vision V2.0, GenICam; Certification CE, RoHS, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.
A 2.5 MP global-shutter sensor suits moving parts and tight fields; the 6 MP class is the general inspection default; a 20 MP sensor covers a wide field in a single exposure. For a retired legacy-bus inspection camera, the 6 MP class is where most swaps land:
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 6-10 MP
Cabling is standard Ethernet. The 3 m high-flex GigE cable with screw locks suits a drag-chain move. For static runs, Cat5e or better carries a GigE segment up to 100 m. Power can ride the same cable when the port supplies POE — the MV-GE2002P is a dual-port PoE NIC built for that job.
- Interface
- GigE
- Ports
- 2 ports
Browse area scan cameras filtered to GigE, pick the cable from cables and the card from frame grabbers, or open the camera finder. The system configurator chains camera, lens, light and controller in one pass.
When the session error is a symptom of something else
Three cases where the fixes above will not hold:
- The open succeeds and sessions die mid-run: that is a teardown or buffer-lifetime bug, not a naming fault — vision DLL fails after program stop: fix the teardown.
- The camera layer never loads and the session error is only the first visible symptom: check the driver bitness against your environment — LabVIEW camera DLL load error: check the bitness first.
- Two identical cameras enumerate under one name and each open grabs the wrong device: open by port, not by name — two identical USB cameras: same name, open one by port. Multi-camera hosts should also give each camera its own acquisition object: multiple GenTL cameras in one process: one acquisition object each.
Checks before you touch the code again
- The configuration tool grabs an image on the same driver the failing code uses.
- The open call returns a non-zero session reference with a clean error cluster before any grab runs.
- The camera string in code matches the enumerated name character for character.
- Selecting the camera raises no camera-file errors in the tool.
- A restart clears the fault once, and your close calls run on error paths so it stays cleared.
- Only one program on the PC opens the camera at a time.
If the stack keeps fighting you after these checks, take the part list to the system configurator or raise it with us on the contact page. More fixes in this family sit under the systems topic.
Questions
Why does the same camera ID work in one program and fail in another?
Because each acquisition driver keeps its own enumeration table. A program on one driver resolves img0; a program on a different driver, looking at the same physical camera, gets cam0 or nothing, and reports an invalid name. The identifier is scoped to the driver, not to the camera. List the device from each program's own API before trusting any string, and remember that a name created in the configuration tool exists only for the driver that tool controls.
What does a bad camera file error mean when I rename a camera?
The driver loads a camera description file for the name you select, in this ecosystem an .iid pointer file that names an .icd description. Renaming to a string with no matching file fails with bad camera file. Delete the stale .iid on disk or repoint it to the correct .icd, restart the tool so the entry regenerates, then copy the resulting name into code. Back up the working description files first; a file that grabs today is worth more than a tidy name.
How do I find the exact camera name to pass to the open call?
Open the vendor configuration tool, or list devices through the API your code actually calls, and copy the string character for character, including prefix, digits and case. The enumerated identifier is not interchangeable between drivers, so never substitute one prefix for another. On USB3 Vision and GigE Vision cameras the name is serial-based and unique per device, so a mismatch there almost always means a typo or the wrong interface instance selected, not a driver conflict.
Should I close the camera session between frames?
No. Open once at start-up, wire that reference through every call, and close once at shutdown plus on error paths. Opening and closing per frame adds latency, invites handle leaks, and an unclosed session after a crash holds the camera so the next open fails. If the fault vanishes after a restart and returns later, a leaked session, not the name string, is your cause.
Is it worth replacing an IEEE 1394 camera over this error?
When the configuration tool cannot grab an image because two drivers fight over the port, migration is the durable fix. A GigE Vision camera carries a unique serial-based name through one standard driver class, reaches 100 m on a copper segment, and removes the 400 Mbit/s bus ceiling. Budget one PoE port per camera and keep the pixel rate under about 100 MB/s per 1 Gbit/s link.