An HMI panel displays pictures that were part of the project when it was downloaded, so a camera capture taken while the panel runs cannot arrive over the control link and appear on screen. Send the inspection result as a Modbus TCP register value, and put the pixels on a screen that is designed to take runtime images.
An HMI panel can only show pictures that were part of its project when that project was built on the engineering PC and downloaded. A camera capture that happens while the panel is running cannot arrive over the control link and appear on screen, because the link carries register and tag values, not files. That is why every attempt to pipe a vision camera's photo straight into an operator panel stalls at the same place, and a different driver does not change it. The workable design is two paths: a 16-bit result code to the panel, which selects among images already packed into the project, and the pixels themselves to a screen that is built to take runtime images. This page shows where panel pictures live, counts what the register path would take, and gives the decision for each case.
Where the panel's pictures actually live
Two paths reach an operator panel, and pictures ride only one of them.
The project path runs at development time. You lay out the screens on the engineering PC, import the images as project assets, compile, and download the finished runtime project to the panel over USB or Ethernet. Vendor documentation for these panels treats the panel's own image files and firmware the same way: files installed from the engineering PC. When the panel runs, it draws on what was packed into it.
The data path runs while the panel operates. The panel polls a PLC, a controller or the vision PC through a driver, most often Modbus TCP or Modbus RTU, and exchanges values: registers, coils, tags. The driver's job is device communications. A driver written for a vision package, where one exists, carries values in exactly the same way.
A photo taken during runtime is neither. It comes into existence as a file on the vision PC after the download has finished, so the panel has no project asset to draw and no documented intake to receive it. The check that matters: if your panel model documents an image-receive or file-display function, that named function in its manual is the path. In the usual setup, the driver has no such function.
A panel's web server is no way around this either: it serves the panel's own screens to a browser, and an HMI web server is not a web client for camera displays takes that distinction apart. If a picture path already exists in your cell and the complaint is only that a still image refreshes late, that is a timing job, covered in how to refresh a camera still image on an operator display.
What the Modbus link can carry
Modbus TCP uses TCP port 502, the port assigned to the protocol. One Modbus register is 16 bits, so one value runs 0 to 65535. That is enough for everything the panel needs from an inspection:
- A trigger. The panel or the PLC writes 1 to a trigger register to start a capture and 0 to clear it.
- A result. Map 0 to idle, 1 to capture in progress, 2 to pass, 3 to fail, and higher numbers to defect classes.
- Counts. Pass counts, fail counts and cycle counts, one register each.
Poll the result register every 1 s. One register read once a second is one transaction per second, a light load on the link and quick enough for an operator to see the change. When you need several flags at once, pack them into one status word; displaying 16 PLC input and output bits on one screen shows the pattern.
If the result code arrives late or updates slowly on the panel, the cause is usually the poll settings, and fixing Modbus TCP data slow to update on an HMI panel walks through them.
Example: counting the registers one 640 x 480 capture needs
The inputs:
- 640 x 480 pixels at 8 bits per pixel, grayscale: a typical small mono camera frame, taken as a typical case for a machine-vision capture.
- 16 bits, that is 2 bytes, per Modbus register, and at most 123 registers in one write request: both limits come from the Modbus application protocol specification.
- The link is Modbus TCP on TCP port 502.
The rule in words: pixels times bytes per pixel gives the frame in bytes; divide by 2 bytes per register to get registers; divide by 123 registers per request and round up.
The arithmetic:
- 640 x 480 = 307,200 pixels
- 307,200 pixels x 1 byte = 307,200 bytes
- 307,200 / 2 = 153,600 registers
- 153,600 / 123 = 1,248.8, so 1,249 write requests for one still frame, the last request part full
What moves the count: bytes per pixel and resolution scale it directly. An RGB frame at 3 bytes per pixel is 921,600 bytes, 460,800 registers, 3,747 requests. Doubling each side quadruples it: 1280 x 960 grayscale is 614,400 registers, 4,996 requests.
The result: one frame costs at least 1,249 request-and-response round trips, and the count assumes the bytes had somewhere to go. They do not. The panel holds no runtime image object for the driver to fill, so a completed transfer still draws nothing.
The decision: if the picture changes with every capture, no setting on the register path moves it. One 16-bit value per capture travels the Modbus link; the pixels take a different screen.
What to build instead
Pick by what the operator actually needs to see:
| Operator needs to see | Where the picture lives | What the link carries |
|---|---|---|
| A fixed set of outcomes: pass, fail, jam, material low | Images packed into the panel project at development; the result register selects which one shows | One 16-bit result code |
| The actual new capture, every cycle | A screen at the cell with a documented runtime image input, fed by a PC or player designed to receive or pull each new file | One trigger register and one result register; the pixels take the other path |
| The result and counts only | Panel text, lamps and counters, all project objects | Two or three registers |
The first and third rows are ordinary HMI work and need nothing new. The second row is what most camera projects turn out to need: the panel stays as it is, and a second screen takes the pictures. If the cell also wants a board for pass counts, quality notices and shift targets, a small signage display fed by its own player takes that fixed content, and small player hardware for an offline image loop covers the hardware choice.
Recommendation: Carry the result, not the picture, to the HMI panel: one Modbus TCP holding register, selecting among images already packed into the project at development. Add the second screen only when the operator must see the actual capture, and commission that screen with a capture made after the project was downloaded.
Testing the two paths apart
Test the data path and the picture path as separate checks, because each can look fine while the other is missing.
- Trigger a capture and watch the result register. It moves from 1 to 2 while the screen shows nothing new: the data path works, and the picture question stays open.
- Show an image that was packed into the project at development. It renders, so the project asset is in place.
- The runtime image endpoint passes when a capture created after the download appears on it, and appears again after you restart that endpoint. An image loaded before the download tests the project path, not the runtime one.
Write down what passed: the panel model, the project revision, the link type and the image delivery method. That list is what the next technician needs to reproduce the working setup.
Questions
Does a firmware or project update let a panel receive camera images?
Firmware and panel images are themselves installed from the engineering PC, the same direction the project travels. An update changes what the panel does with its own assets; it does not open a runtime intake for another device's files. If a specific model gains a documented image-receive or file-display function, the manual names that function exactly, and that name is what to build against.
Can one 16-bit register carry part of the picture?
It cannot carry pixels. One register is one number from 0 to 65535, while a single 640 x 480 grayscale frame is 307,200 bytes, which the worked example counts out to 1,249 write requests. A register does carry useful numbers around the picture: a result code, a defect class anywhere in 65,536 classes, the row that failed, or a capture counter.
What if the vision PC and the panel have no protocol in common?
Modbus TCP or Modbus RTU is the usual common ground, because many controllers and vision packages speak one of them, but both endpoints must implement the same mode and the register map must be defined at both ends, never guessed. If neither endpoint offers a shared protocol, the standard route is a small gateway or controller that speaks to each side in a protocol it supports.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.