Push NG images from a vision system to an HMI over FTP

When a vision sensor rejects a part and the HMI shows only a red stack light, maintenance chases phantom failures: was it the part, the fixture or the sensor? Put the NG (reject) image on the screen and the argument ends — the technician sees what the camera saw. The push that makes this work uses hardware you already own: start the FTP server built into the HMI, log in with a named user, overwrite a placeholder image inside the runtime, and force a screen change so the new picture actually appears. The sequence below worked end to end on a bench: one vision sensor, one HMI, one switch.

What you need

Retrofits need little that is not already on the machine:

• A vision system whose software saves images to an FTP server. The FTP destination lives in the software's image-output settings; whether a given camera has it is a software feature, so read the feature list before planning the job.
• An HMI with a built-in FTP server. On many terminals it runs as a system service in the operating-system layer — on Windows CE terminals, a service inside the Control Panel.
• Rights to create a user account on the HMI.
• Camera and HMI cabled to one switch, in one subnet.
• A placeholder image displayed on the machine's NG screen.
• A PLC bit or an HMI script that can change screens.

The sensor side stays untouched: the camera keeps judging parts, and the FTP push is a file copy riding the network after each NG. If you are speccing a new station instead of retrofitting one, start at the smart cameras category and shortlist by interface and resolution.

Step 1. Start the FTP server on the HMI and create a named user

1. From the HMI's utility menu, enter the operating-system environment — on a Windows CE terminal, this opens the Control Panel.
2. Open Services and find FTP Server. Green means it is running; click it once if it is stopped.
3. Create a user account in the terminal's user-account settings — the working bench setup added an NTLM-type user — and add that account to the FTP server's user list.
4. Keep the user name and password at hand: the vision side needs them exactly as typed.

Expect anonymous access to fail. On the bench, the connection test still returned a failed-to-login error with anonymous logins and uploads allowed and the authentication option switched off; creating the named user and typing its credentials on the vision side turned the next test green. Terminal families hide the server in different menus: displaying vision camera images on the HMI walks the server settings for one common panel, and an FTP image-transfer setup on another HMI platform shows the same three pieces — server, user, default directory — in a different layout.

Step 2. One subnet, then the login test

1. Cable camera and HMI to the same switch and give both addresses in one subnet; on the bench, both sat in 192.168.100.0/24.
2. In the vision software's FTP destination, enter the HMI's IP address, port 21 (the FTP control-port default) and the named user's credentials.
3. Run the connection test before configuring any file path.

A failed test with correct credentials is almost always the user list on the terminal, not the wiring — fix the login before anything else. If the camera still carries its out-of-box address, change a camera IP address and update tools stuck on the default clears that first.

Step 3. Overwrite a placeholder image inside the runtime

The trick that avoids all HMI scripting: the screen's image object reads a file that ships inside the runtime project. If the camera's upload overwrites that file, the screen shows the NG picture with no logic added on the HMI side.

1. Place a placeholder image in the runtime project and show it in an image object on the NG screen. Note its exact file name; the bench build used a tree graphic named Tree.
2. On the vision side, set the FTP folder destination to Images and the file name to the placeholder's exact name.
3. On the HMI's FTP server configuration, set the default directory to \Temp~MER.00. The runtime unpacks into that temp folder, and the vision system refuses the tilde character in a destination folder name — the server-side default directory is the only clean way to reach it.
4. Test the path by hand: copy any image file under the placeholder's name into that folder, re-open the screen, and confirm it displays before the camera enters the picture.

Step 4. Refresh with a screen change

The catch: an image object reads its file when the screen opens, not while it sits on display. The overwritten picture shows up only after the HMI leaves that screen and returns, so do not leave the refresh to the operator — drive it.

1. Give the NG screen a partner; the machine's normal screen works.
2. When the vision system's NG bit sets, pulse a PLC bit that switches the HMI to the NG screen, hold it there 1-2 s, then switch back.
3. Each re-entry makes the image object re-read the file, so the newest NG image appears and the two-screen cycle reads as a live update.

Worked example: transfer time for a 5 MP NG image over Fast Ethernet

Inputs, with sources: a 2,592 × 1,944 colour image (a 5 MP sensor, a common inspection resolution); 3 bytes per pixel (24-bit colour); JPEG at about 10:1, a typical ratio for saved inspection images; a 100 Mbit/s Fast Ethernet link, an interface many vision sensors carry; and an effective FTP throughput of about 8 MB/s, derived below.

Arithmetic, step by step:

• Raw image: 2,592 × 1,944 = 5,038,848 px; × 3 B = 15,116,544 B ≈ 15.1 MB.
• JPEG: 15.1 MB ÷ 10 ≈ 1.5 MB.
• Throughput: 100 Mbit/s ÷ 8 = 12.5 MB/s of line rate; derated to about 65 % for protocol overhead: 12.5 × 0.65 ≈ 8 MB/s.
• Transfer: 1.5 MB ÷ 8 MB/s ≈ 0.19 s; add the 0.1-0.3 s FTP connect-and-login exchange for about 0.3-0.5 s per push.

Decision: at one NG every 5 s the push occupies 0.2 of every 5 seconds — about 4 % of the link — so NG-only uploads ride Fast Ethernet without disturbing camera traffic. Two thresholds change the answer. Beyond roughly 2 pushes per second (3 MB/s against the 8 MB/s available), or with uncompressed files — the 15.1 MB bitmap would take about 1.9 s — move to GigE, where the same 1.5 MB JPEG clears in about 20 ms (1.5 MB ÷ 80 MB/s).

Where the method stops

Four boundaries, each structural rather than a tuning problem:

• One slot. The file always holds the most recent NG; there is no history to scroll. An archive needs unique file names built by the vision software itself — configuring dynamic FTP file names from a vision system into a PLC-based line covers that extension.
• One camera per file name. A second vision system needs its own placeholder and its own screen object, or the uploads overwrite each other.
• Clear text. FTP carries the password unencrypted, so keep camera, controller and HMI inside the machine's isolated cell network, not reachable from the office LAN.
• One image at a time. An operator who must browse or compare failures needs a PC-based viewer or the vision software's own display; this push answers one question — what did the camera see on that reject.

The limitation is general: what an HMI can show from a smart camera at any moment is a design choice, and smart camera image in a PLC HMI: what actually displays live walks the live-view options that sit beside this file-based push. If the request grows into a wider retrofit — several stations, image archives, traceability — scoping a machine vision system before you call an integrator sets the boundary lines before anyone quotes.

Vision-side hardware that can push the file

If the camera's own software has no FTP destination, move the application to hardware that does: a vision controller is an industrial computer with camera ports, so the inspection software and the FTP push run on the same machine and the HMI is another device on its LAN.

For a single-camera station, the MV-VC3301H-128G66 ships with the VM6200Pro vision software license included, which puts the inspection and the FTP push on a single box by default.

Cells with several cameras fit the MV-VC5525-256G70-NN better: PoE camera ports power the cameras over their data cables, 5+ LAN ports reach the HMI and the plant network, and 32 GB of memory leaves room for image buffering.

The camera end needs nothing special — any camera that hands the inspection software an image can sit behind this push. Starting from zero, the camera finder filters the range by interface, resolution and shutter.

Checks before you roll it out

• Connection test passes with the named user before any path is configured.
• The hand-copied placeholder test shows a swapped image after a screen re-open — it proves path and file name before the camera joins.
• A real NG lands inside the cycle budget: about 0.3-0.5 s for a 5 MP JPEG on Fast Ethernet.
• The PLC screen-change bit fires on NG and returns on its timer without latching.
• Good parts upload nothing — watch the folder's modified time or the FTP log for one full shift.
• One power cycle: FTP service, user account and default directory all return after a terminal reboot.
• The FTP port answers only on the machine cell network.

Where to go next

Retrofit first, buy later: this push usually costs an afternoon, not a project. When you do spec new hardware, configure the system from camera to controller, or send the camera model and HMI type through the contact page. The systems topic page collects the neighbouring guides on runtime parameters, recipe selection and display control.