Display a camera image on a VGA output from a vision controller

A vision controller acquires, processes and decides at the line, and its monitor output — the VGA or HDMI port on the box — is the natural place to show the operator what the camera sees. Many machine-vision SDKs hide that path: acquisition works, but no function is obviously named 'send image to VGA'. The route below works on any vision controller: bind a display window to the operator's monitor, draw the inspected frame once per cycle, and budget the redraw so inspection keeps its full rate.

What do you need before you start?

You need four things: a controller with a monitor output, a camera the controller can reach, your SDK's display-window function, and a monitor cabled to that output — any 60 Hz panel works, and no frame grabber is involved.

• A controller with a monitor connection. A vision controller is a fanless x86 computer; it drives a monitor the way any PC does, through the connector its data sheet lists — VGA on legacy units, HDMI or DisplayPort on current models.
• A camera on that controller. GigE and USB3 models both work; choose from the area scan cameras in the camera finder.
• The SDK's display-window function. Every machine-vision library has one: an object that holds an image for drawing, with parameters for size and screen position.
• A monitor and a cable. A 60 Hz office-grade panel is enough — a 30 fps source cannot use more.

If you are still choosing the box itself, compare models by camera-port count, PoE and memory first. For a single-camera station, the compact VC2100 class carries 8 GB of memory, two USB 3 ports and four built-in light channels, with the display loop riding along:

How do you route the image to the VGA output?

Create one display window in your program, place it on the second monitor's screen coordinates, and draw the latest judged image into it once per cycle — the operating system sends whatever that window holds to the VGA monitor on its own.

1. Cable the operator monitor to the controller's second display connector. In the operating system's display settings, confirm that two monitors appear and set the operator monitor to its native resolution.
2. In your program, create the display window at the size you want to show — 1024 × 768 pixels is a comfortable operator size — rather than at full sensor size.
3. Move the window onto the second output by giving it screen coordinates past the primary monitor's edge. With a 1920-pixel-wide primary display, the second monitor's top-left corner sits at x = 1920, y = 0; the mechanics are in display window size and screen position.
4. At the end of each inspection cycle, draw the frame you just judged into that window: the processed image with its overlays, not a fresh grab.
5. Stamp verdict text on top in the same window, following text overlay on a live camera image without altering the frame.
6. Create the window once and keep it for the life of the program. Rebuilding it every cycle burns milliseconds and makes the display flicker.

This routes the image through the controller's own graphics path. If the picture must appear on a screen no vision program drives — a second PC's monitor, for instance — that is a different problem, solved in live camera display on a second monitor without a frame grabber.

Which frame should you draw, and when?

Draw the exact frame your verdict came from, once per inspection cycle: at 30 fps the cycle repeats every 33.3 ms, so one draw per cycle already updates the monitor 30 times a second — more than the five to ten updates a person needs to follow the line.

A five-stage pipeline offers five tempting draw points, one after each processing step; resist them, because the next two sections put numbers on what that costs. Keep acquisition continuous so a fresh frame is always waiting when the cycle ends — the pattern is in continuous camera acquisition mode for live image loops — and accept the resulting display lag as one fixed term in the image-based control latency budget: 33.3 ms at a 30 fps cycle, before the monitor's own refresh.

How much redraw time does the monitor give you?

A 60 Hz monitor rewrites the screen every 16.7 ms — 1000 ms divided by 60 — but that is not your deadline: the draw only has to fit in the spare time your inspection cycle leaves, which at 30 fps and 18 ms of processing is 15.3 ms.

The monitor's 16.7 ms matters only if you promise 60 updates per second, which no inspection line needs. Your real deadline is t_spare; if it goes negative, frames queue and the cycle rate drops. The draw does not have to synchronize with the refresh either — the operating system composites whatever the window holds at each rewrite, so a draw that lands mid-interval still appears on the next one. A display is one more consumer on the same budget, and when acquisition already outruns processing, the arithmetic in fixing the frame rate gap when acquisition outruns processing keeps it affordable.

What does drawing a full frame actually cost?

Drawing costs time in proportion to pixels: a 4000 × 3000 8-bit frame is 12 MB — 12,000,000 pixels at one byte — while an 800 × 600 region of interest is 0.48 MB, 25 times less data to move, so crop to what the operator needs before you draw.

The example camera is a 12 MP USB3 model delivering 4000 × 3000 at 30 fps:

Scaling is not free even so: 4000 ÷ 1024 ≈ 3.9, so every full-frame draw reduces the image almost four times horizontally. Cropping removes that work too, because the ROI lands in the window one to one. If draws stay slow after cropping, the renderer is the suspect — walk through diagnosing slow GPU image processing.

How do you keep drawing from slowing the inspection loop?

Keep the draw off the processing deadline: one draw call at the end of each cycle, into a buffer you already own, with overlays updated in place — on the example numbers that leaves a 9.3 ms margin in every 33.3 ms cycle.

• Draw at the end of the cycle, after the verdict exists. Nothing earlier in the pipeline needs a screen.
• Reuse the display buffer across cycles; per-frame allocation shows up later as random stalls, as explained in reusing image buffers instead of per-frame allocation.
• Update overlays in place instead of rebuilding the scene; the approach in updating overlay graphics every frame at full preview rate applies unchanged.
• Leave the camera thread alone. The display reads finished buffers; it never touches the acquisition path.

How do you verify the image really reaches the VGA output?

Watch three things in order: the operating system lists the monitor, the window actually lands on it, and the drawn content advances at your cycle rate — a counter printed in the corner should reach 1,800 counts in one minute at a 30 fps inspection rate.

1. Displays. The operating system's display settings list the operator monitor, with its native resolution selected.
2. Counter. Print a cycle counter in the window corner and let it run for a minute: the count must equal your inspection rate in cycles per second. Anything lower means the draw or the processing has eaten the margin.
3. Freeze test. Cover the lens: the window must hold the last judged frame, not go black — proof that you draw the inspected image rather than re-grabbing.
4. Sync test. Watch a verdict flip. Text and image must change in the same redraw; a gap between them means the draw uses a newer frame than the verdict — the FAQ below has the fix.
5. Evidence. Save the annotated image each cycle so you can reconstruct exactly what the operator saw; the loop in saving annotated inspection images in a processing loop adds no extra pass.

When should the image go to an HMI instead?

When the operator only needs the verdict and an occasional image, send the result, not the stream, to the HMI, and keep the VGA output for the live view: ten verdict images per second at 12 MB each is 120 MB/s, so thumbnail before you transfer.

The controller's monitor serves the operator standing at the station. The control room needs something else: verdicts, counts and archived images. Send those over the controller's communication link to the PLC or HMI — a worked path for showing camera images on an HMI through a PLC starts from the same one-image-per-verdict rule.

Where the line itself is harsh — washdown, dust, constant wiping — a sealed industrial panel PC replaces the loose monitor and its cable at the station.

Growing the station changes only the width of the same budget. Pick the controller by camera ports and PoE first:

To match cameras to the ports you choose, start at the camera step of the configurator:

More on displays, buffers and loop latency sits on the systems topic page. If your station mixes unusual outputs — a portrait monitor, a projector, a PLC-driven HMI — tell the applications team what the station looks like.