Machine vision development without a camera: emulation options

The camera emulator that used to live in the options menu of integrated robot vision tools is gone from current releases. The vendor's answer now is the vision software package itself, which carries its own emulator, and in practice that changes little: most of a vision application never needed a live device on the network. Three routes keep development moving with no camera on the bench — replaying a saved image set into your tools, pointing acquisition code at a virtual network camera, and commissioning the whole cell in simulation. This explainer marks where each route stops working, sizes a golden-sample set with the arithmetic shown, and ends with the one-day validation pass that closes the gap before release.

Where the built-in emulator went

Older releases of integrated vision options shipped a camera emulator inside the same menu tree as the camera configuration, so a station could be programmed with nothing on the network. Current releases removed that entry, and the expectation is that the vision package — the program that already hosts the inspection tools — provides the emulator instead. That software is a free download from its maker's own site, which is the only place to take it from.

The move is an inconvenience, not a blocker. Existing projects keep working; only the entry point moved. One trap survives the migration: an emulator that stops after a pixel-format change is a known software fault with a fix, so treat a crash there as a tool problem, not a signal to order hardware early. The diagnosis is in emulator crashes after pixel-format changes.

Three routes and when each one wins

Pick the route by where your project risk sits:

The order is the decision. A pattern-matching project with images already in hand starts producing tuned tools the same day on route 1. A project whose risk is the acquisition layer — discovery, bandwidth, register writes from the control code — goes to the virtual camera first. A project whose risk is cycle time and robot interaction goes to simulation, with replayed decisions standing in for the camera. New stations normally use all three in that order.

Route 1: replay a golden-sample set

A golden-sample set is a folder of frames that spans the part's real variation, captured once and reused everywhere. Build it from the target camera if one exists anywhere — a sister line, a demo unit, sample images from the sensor maker — and otherwise from any camera with the same pixel count, because thresholds tuned at one resolution drift when the image is resampled. Keep the files at native sensor resolution: no viewer rescaling, no recompression.

Capture the boundary, not the easy cases. Clean passes, clear fails, and the uncomfortable middle: defects at the tolerance limit, parts at the edge of the fixture, the worst lighting the station will see. When the tools load the files, the bytes must be decoded to pixel data in the right format before anything else runs — the loading pitfalls are covered in image bytes versus pixel data and pixel-format checks on converted images.

Worked example: sizing a 450-frame set for a 12 MP camera

The case: a new presence-and-defect check, images supplied by a 12 MP USB3 camera, and a request to state the storage budget before anyone orders hardware.

Inputs:

• Source camera: the LS-CMR-0166, printing 4000 × 3000 pixels at 30 fps.
• Pixel format: Mono8, one byte per pixel. State the assumption; a colour Bayer format triples it.
• Capture length: 15 seconds across several parts.
• Regression subset: 60 frames kept labelled for re-testing.

The rule in words: frame size is pixels times bytes per pixel; frame count is frame rate times seconds; set size is frame size times frame count.

The arithmetic: 4000 × 3000 = 12,000,000 pixels, and at one byte each that is 12 MB per frame. At 30 fps, a 15-second capture is 30 × 15 = 450 frames. The full set is then 450 × 12 MB = 5,400 MB, call it 5.4 GB. The labelled subset is 60 × 12 MB = 720 MB.

Decision: treat 2 GB as the line. At or above it, the set lives on the development workstation under version control with an index of filenames, never on removable media; below it, a network share is workable. Book the review pass against the 60-frame subset, not the full 450.

Route 2: a virtual camera on the network

A virtual camera is a program on your network that answers discovery like a device and exposes the register map a real camera would. One open simulator design works as a state machine serving a simulated camera memory that any GigE Vision client can read and write — exactly what your acquisition code does on day one.

That is what this route buys: interface faults surface with no hardware. Discovery and IP configuration, packet size set before acquisition starts, and runtime register access from your control code are all testable against the virtual device. What it cannot buy is image realism: the frames are synthetic or replayed, so sensor noise, glare and exposure behaviour stay untested.

If your acquisition code runs inside a virtual machine, the bridge to hardware has its own steps — USB camera passthrough into an emulated machine covers handing a physical camera to the guest OS on the day the bench unit arrives.

Route 3: commission the cell in simulation

Virtual commissioning is the practice of testing and validating a manufacturing cell before physical commissioning, and it is standard on new robot stations. The robot, fixtures and handshake logic run in the simulator while the camera's decision is played in from your replayed frames, so cycle time, reach and reject handling are exercised end to end. On the controls side, PLC emulation for machine upgrade testing runs the same trick for the ladder logic.

Matching the replay set to the sensor you will buy

Replay development transfers only if the emulated image matches the target sensor's geometry: same pixel count, same aspect ratio, and a shutter type that fits the motion — global for moving parts, rolling acceptable for stationary ones. A set built at 4000 × 3000 covers both 12 MP candidates below, and it says nothing about which one meets the cycle time.

The same 12 MP IMX226 sensor ships on GigE at 9 fps and on USB3 at 30 fps:

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

At 9 fps a frame arrives every 111 ms; at 30 fps, every 33 ms. Emulation cannot reproduce that difference, so the interface choice is a live-bench decision made with real parts and the area scan camera finder.

For stand-alone stations, smart cameras fold the lens and light into the device. Their projects import saved images the same way, with the added limit that the built-in light source can only be tuned against the real part.

What emulation cannot prove

Exposure and gain: auto-exposure behaviour on a real part under real lighting has no offline substitute, and the settings a camera applies at startup deserve an explicit check — see automatic iris, exposure and gain control and the startup trap in auto-exposure upper limit not applied.

Focus and optics: no replayed frame tells you whether the lens resolves your smallest feature at the working distance.

Calibration: the pixel-to-millimetre scale must come from the real camera on the real fixture. When the camera or robot changes later, recalibrate rather than reuse — vision calibration recovery after camera or robot changes covers what to redo.

Timing: trigger latency and bandwidth under load appear only with a device streaming.

The one-day live validation pass

Reserve one shift, with parts, and close every physical item in it:

1. Wire the camera and set the GigE packet size before acquisition starts.
2. Check the pixel format the camera applies by default; a mono default where colour is expected is a common first-run surprise, covered in GigE camera shows no color image.
3. Fix exposure and gain manually with the limits recorded, so the camera cannot renegotiate them at power-up.
4. Re-run the 60-frame regression subset through the deployed tool and compare every pass or fail label against the offline run.
5. Measure cycle time at the target frame rate with the cell running, not just the camera.
6. Record the camera firmware version so the deployment is reproducible — the firmware update workflow covers the approval-to-readback loop.

If a label flips, tune lighting or exposure first; the algorithm is usually innocent. On the software side, camera acquisition software compatibility settles how the stream lands in your stack.

Two starting points for the bench: a 20 MP USB3 camera for high-detail checks, or a 1.6 MP smart camera with a 16 mm lens for stand-alone stations:

Where the validated application runs

The last move is from workstation to station. Most stations land on area scan cameras feeding a vision controller that hosts the streams and drives the lighting: the MV-VC3301H-128G66 brings 5+ LAN ports, 4 built-in light channels and 8 GB of memory, which is enough for a multi-camera GigE station.

Smart-camera projects skip the controller entirely: the application runs on the device itself.

Checks before you order hardware

• Replay set at the target sensor's native pixel count, files uncompressed or losslessly stored.
• Shutter type chosen for the motion: global for moving parts.
• Lens mount available for the focal length the working distance needs.
• Interface headroom: the frame rate you validated fits the cable length and the controller ports.
• One shift booked for the live validation pass, with parts.
• The labelled regression subset exported with its expected verdicts.

Start the parts list in the system configurator, beginning at the camera step:

If the station is still being scoped, scoping a machine vision system before you call an integrator is the right previous step, and the systems topic page collects related pages. Questions about matching a replay set to a sensor go to the contact page.