Camera works in setup but grey image at runtime

The configuration tool streams live video from the camera, every exposure control behaves, and the moment the robot program calls the vision process it hands back a flat grey frame and an offset of zero. Cells lose whole days this way, because the camera, the cable and the lens all get replaced before anyone looks at the process configuration. The cause is nearly always a single assignment: the vision process has no runtime image source, so at run time it returns an empty buffer instead of a grab. This guide gives the check order, the pixel statistics that separate the possible causes, and the habits that stop the failure coming back.

What a flat grey frame actually is

A sensor never returns a perfectly uniform frame. Cap the lens and you still see read noise; open it and you see scene structure. A frame in which every pixel holds the same mid-tone value is not exposure data — it is a placeholder buffer, handed back by the vision software when the process has no image to deliver.

The fill value is half of full scale, and the arithmetic is your first clue. An 8-bit frame has 2^8 = 256 levels, so an empty buffer reads 256 / 2 = 128 in every pixel. A 10-bit frame reads 1024 / 2 = 512, a 12-bit frame 4096 / 2 = 2048. A frame parked exactly at mid-scale with zero variation across millions of pixels did not pass through a lens.

So commit to the decision: live video in the setup tool plus a uniform mid-grey frame from the program is a process configuration fault, not a camera fault. Fix the image source before touching exposure, gain or wiring.

Check one: the Runtime Image setting

A configurable vision process has two image paths. The setup path feeds the teaching screens: connect a camera once and those screens show live video for as long as the tool is open. The runtime path is what the process grabs when the program calls it, and it is a separate assignment that starts empty. Teaching succeeds on the setup path, the program runs against the runtime path, and the process answers with the empty buffer.

Open the Vision Process Setup screen for the process your program actually calls — the one named in the find call, not the one you taught last — and set Runtime Image to the camera the process must grab from. Save, then run the test from the program itself, never from the tool. The tool proves the camera; the program proves the process.

Check the assignment in every process you create. A new process starts from the same empty default, and a process imported into a new cell binds its image paths to a camera by name or address — when the new cell names its cameras differently, the runtime path comes up empty again.

Read the frame before you change anything

Save the frame the program actually acquired — most processes expose the last image belonging to each vision register — and read two numbers from it: the mean grey value and the standard deviation. Any image tool with a histogram shows both; a three-line script that loads the frame and prints the two values does the same. Then match the signature:

σ is the standard deviation: a healthy scene shows tens of counts, an empty buffer exactly zero.

Worked example: proving which camera answered

Take a two-camera station where both cameras view the same 400 mm belt width. Camera A outputs 2448 × 2048 pixels, so across the belt it samples 2448 / 400 = 6.1 pixels per millimetre. Camera B outputs 1280 × 1024, sampling 1280 / 400 = 3.2 pixels per millimetre.

Put a 60 mm gauge block on the belt and run the program once. In a frame from camera A the block spans 60 × 6.1 = 367 pixels; from camera B it spans 60 × 3.2 = 192 pixels. Measure the block in the saved frame. A span of 367 pixels says the process grabs camera A; 192 says camera B; a frame in which every pixel reads 128 says no camera at all. Ten minutes with a ruler settles what an hour of re-teaching will not.

The calculator does the same arithmetic from your own sensor and field of view, and narrows the finder to cameras with enough pixels for the feature you must measure.

The remaining causes, in order of probability

1. No runtime image assigned. Covered above, and it is the one to fix first: this single setting clears most tool-versus-runtime complaints on its own.
2. Exclusive access: two programs, one camera. A GigE or USB3 camera is owned by one process at a time. If the setup tool keeps its live view open, the runtime host receives a placeholder instead of a frame — the same uniform grey. Close the tool completely and run the program again; if the frame arrives, make closing the live view before runs a cell rule, or route both consumers through one camera service that shares the stream.
3. The process grabs the wrong camera. Multi-camera cells often address cameras by the order they were installed in, and a re-installed camera takes a different position. The gauge-block measurement identifies the source in one run. Assign the camera by its unique device name or address, never by index.
4. Dark, not grey: trigger and light timing. A mean below 10 with almost no variation means the exposure window and the light pulse are out of step. Work through strobe light on but the camera image is black and trigger call versus exposure time; if only the first frame after power-up is dark, read first camera frame dark: exposure settling or light timing. Do not look into the light head to check a strobe: hold a white card in the beam and watch the card, because a full-current pulse is far brighter than its average power suggests.
5. Pixel format mismatch. Structured data with shifted grey or colour values is a format problem, not a source problem — the settings are covered in camera preview shows a gray image: fix the format mismatch. Deep-learning tools produce their own variant of blank grey output; the walkthrough of grey blank image output in a deep-learning vision tool covers that side.
6. Revision mismatch. When the setup tool and the runtime host run different software builds, a process saved on one can arrive on the other without its image binding. Camera configuration revision mismatch: fix no-frame errors and camera SDK build mismatch: diagnose frame timeouts give the checks; pinning one revision across both ends is the fix.

When the usual answer is wrong

You set Runtime Image and the frame is still grey. Three cases remain:

• The statistics changed to snow. A mean of 120-140 with σ of 5-15 and visible noise means the camera now delivers but no light reaches it, and auto gain is lifting the noise floor toward the exposure target. The fault moved from image source to lighting — row three of the table.
• The setup tool went grey too. Ownership flipped the other way: the runtime host now holds the camera and the tool gets nothing. Close every vision application on the cell, power-cycle the camera, reopen the runtime host first. If no host recovers video, the link is at fault — camera connected but no image: check the frame grabber cable wiring.
• The image is good, the offset is still zero. The program reads the vision register before the find has finished. The smart-camera case is covered in smart camera misses first images after load: fix the ready gate, and the same result-valid gating applies to any vision process.

Commissioning habits that stop it returning

• Set Runtime Image in every new process before teaching anything, and re-check it after any clone or import.
• Run the one-frame smoke test from the program, not the tool, with a gauge block in the scene; record the mean and σ on the commissioning sheet.
• Name cameras by station and function, assign them by name in every process, and put the same names on the cell diagram.
• Keep one owner per camera: live view closed during program runs, or a shared stream service.
• Deploy the setup tool and the runtime host at one pinned revision, and write both revisions on the commissioning sheet.

Hardware that removes the split

The failure exists because two environments — a setup tool and a runtime host — each keep their own list of image sources. Two architectures delete that list.

Smart cameras run the inspection on the device: the process you teach is the process that executes, so there is no second image path to leave empty. For a single-station find-and-offset task like the one in this guide, the MV-SC5060XM-08M-WBN, a 6 MP mono smart camera with an M12-mount lens, does the whole job on the camera and answers the program over the network.

Vision controllers keep both environments on one box: you configure the process on the controller and the same controller runs it, so the tool and the runtime cannot drift apart. The MV-VC3301H-128G66 hosts that arrangement on an Intel Core i3 processor with 5+ LAN ports for cameras and PLC traffic.

When the runtime stays on a separate PC, pick the camera in the area scan cameras finder and treat the image-source checklist as part of every deployment. A camera such as the MV-CS200-10UM, a 20 MP USB3 mono model, gives the runtime host one stream to own.

Where to go next

If the frame statistics point at hardware rather than settings, start from the camera finder or the system configurator to match a camera, lens and light to the station. The rest of the systems guides cover the timing, buffering and integration failures that neighbour this one. If the cell still argues after these checks, send the saved frame, its statistics and the process export to applications support and we will work through it with you.