Legacy vision cameras without OPC server: get results over FTP and TCP

You are standardizing the plant on OPC UA, the modern cameras snap in, and a shelf of older smart cameras cannot: their firmware predates the job-server generation that carries an OPC server. The sensors still inspect well — what they lack is the protocol, not the capability. The integration that holds up is a gateway: one process that pushes job files over FTP, toggles online mode and reads results over a plain TCP socket, then serves all of it to the PLC as OPC UA. Old and new cameras share one tag namespace. This guide walks the decision points, the interface details, the build steps and the timeout and sizing numbers, and says when buying current smart cameras beats gatewaying.

How do you know the camera will never get an OPC server?

Check the firmware ceiling before anything else: in the example line the newest package is firmware 2.7 on 4 MB of flash, that generation has no job server, and the OPC server ships with the job server — so no upgrade path exists and the gateway is the answer.

Firmware for this generation is no longer locked behind a support subscription, so the check costs an hour: pull the newest package for the exact model from the maker's site and read its release notes. Two outcomes, one decision:

• The newest firmware lists the job server and an OPC server. Upgrade every unit, enjoy the cheapest integration you will ever do, and stop here.
• The newest firmware still has neither, as on the 4 MB flash generation capped at 2.7. Stop chasing firmware; the flash is the hard wall, and the OPC UA stack plus its certificates has nowhere to live.

One hour of release-note reading settles upgrade versus gateway. Never buy more of a model on the promise of future firmware — buy it for what the newest package already does.

What interface does the legacy camera actually give you?

Two channels: an FTP server on TCP port 21 for job files and failed-part images, plus one plain TCP socket — its port number is printed in the camera's integration guide — that carries online mode, triggers and results as short ASCII messages.

The FTP side behaves like any embedded FTP server: the control connection runs on port 21 and every transfer opens a separate data connection. Put the camera in passive mode and expect it to pick a high port for each transfer; a firewall that allows only port 21 will break every push. The TCP side is a text protocol over one connection: you send the command that sets online mode, you send a trigger, and the camera answers with a result line you split on the delimiter its guide defines. Nothing here is exotic — it is the same pattern as triggering a smart camera over TCP with ASCII commands and reading results.

Should the gateway or the camera own the connection?

The gateway connects out as a TCP client to the camera's listening socket, the control channel takes one client at a time, so the socket gets exactly one owner — and that owner is the same process that serves OPC UA to your PLC.

Give the PLC no legacy code at all. It writes a tag or calls a method on the gateway; the gateway sends the camera's ASCII command; the answer lands in an OPC UA variable on the same socket. If your plant has no OPC UA at all, skip the wrapper and let the PLC speak TCP straight to the cameras: connecting to a vision camera over TCP, client versus server setup and smart camera to PLC over TCP for trigger and pass/fail cover that simpler path. With a modern OPC UA fleet already running, the whole point is that the PLC cannot tell which cameras are old.

How do you build the FTP and TCP gateway?

About a day of work on a fanless vision controller, in nine steps: baseline the camera, host the gateway, write the FTP push, own the TCP socket, expose OPC UA, set watchdogs, prove it, harden it.

1. Baseline one camera. Fixed IP, an FTP account that works from a laptop, one manual job download and one manual online-mode toggle from a terminal. You want a known-good reference before any code exists.
2. Pick the host. A vision controllers box in the cell is the right shape: fanless, mounted with the machine, and already talking to cameras. On Linux, a headless vision server install keeps the footprint small.
3. Write the job push. FTP connect, login, passive mode, upload the job file, quit. Count the round trips the session needs — the timeout math below uses that number.
4. Write the control client. Connect, send the online-mode command, then hold the socket open and read result lines as they arrive. On loss, retry after 1 s, then every 5 s.
5. Add the trigger path. The PLC writes a tag or calls a method; the gateway sends the trigger command on the open socket; the reply becomes a variable update.
6. Expose OPC UA. One subtree per camera — Pass, result values, JobName, SocketState, LastResultMs — mapped exactly like the modern fleet (next section).
7. Set watchdogs. Receive timeout at three times the slowest inspection cycle; on timeout mark that camera's variables bad quality and start the reconnect backoff.
8. Prove it. Known-good and known-bad parts through the cell, then a soak with a result counter. An 8-hour run at one part per second must log 8 × 3,600 × 1 = 28,800 results. Pull the camera cable mid-soak: tags go bad within the timeout and recover when the cable returns.
9. Harden it. Turn off every service the gateway does not need — disabling a legacy FTP server on a real-time Linux controller is the pattern — and keep camera credentials in the controller's credential store, never in the job file.

Two vision controllers that fit this job:

The MV-VC3301H-128G66 carries 5+ LAN ports, 8 GB of memory and an Intel Core i3 — plenty for a line's worth of sockets and one OPC UA server. When the same box must also power and strobe the modern fleet, the MV-VC5525-256G70-NN steps up to 32 GB of memory, PoE camera ports and 8 built-in light channels.

How long does a job push and a result take?

Fast enough to ignore: a 250 kB job file pushes over FTP in roughly 40 ms on a 100 Mbit/s link, and a trigger-to-result round trip adds about 65 ms, most of it the camera's own 60 ms inspection cycle.

Worked example, numbers from a typical cell:

• Job push. 250 kB × 8 = 2,000 kbit. Assume 60 Mbit/s of real FTP throughput on a 100 Mbit/s link: 2,000 / 60,000 ≈ 0.033 s. The session makes about eight round trips (login, passive negotiation, transfer, quit) at 1 ms each ≈ 8 ms. Total ≈ 41 ms. Push jobs at every changeover, freely.
• Result round trip. A 30-byte trigger plus a 120-byte reply is 1,200 bits, which is 12 µs of wire time at 100 Mbit/s — noise. The camera dominates: 60 ms of exposure and processing plus about 2 ms of network and gateway handling ≈ 65 ms end to end.
• Timeout. The slowest job on the line takes 900 ms, so 3 × 900 = 2,700 ms; set the receive timeout to 3,000 ms.
• Idle load. Fourteen cameras polled once a second at 200 bytes each is 14 × 200 = 2,800 B/s ≈ 22 kbit/s, about 0.02% of the link.

The decision these numbers hand you: job changes are effectively free, results arrive at line rate, and the FTP/TCP path costs nothing against a native OPC camera on the same cell.

How do you map legacy results into your OPC UA namespace?

Map them exactly like the modern ones — same variables, same trigger method, same per-camera subtree — so ns=2;s=Line1.Cam07.Pass and ns=2;s=Line1.Cam14.Pass differ only in name, and the PLC program never branches on camera age.

Per camera, expose five nodes: Pass as a Boolean, the numeric and string results the job produces, JobName as a string, SocketState as Connected / Reconnecting / Bad, and LastResultMs as the round-trip figure — your drift alarm. Add one Trigger method, or a Boolean tag the gateway edges. When the socket is down, set bad quality on the variables instead of writing False: a disconnected camera must not read as a failing part.

The modern half of the namespace is covered in reading smart camera results over OPC UA into your control system. If your SCADA layer prefers calling methods and displaying what they return, calling OPC UA methods and showing results in an operator display walks the same trigger-as-method pattern. Images ride the FTP channel: the camera drops failed-part files, the gateway copies them to a share and publishes the path as a tag; what actually displays live in a PLC HMI sets honest expectations about refresh. When you specify new hardware into the same scheme, selecting PLC-triggered cameras for FTP image records covers the camera-side settings.

What breaks first with legacy cameras?

Passive FTP through a firewall breaks first, then a second client stealing the control socket, then a stale job after a power cut — usually in that order, all within the first week.

1. Logins succeed, pushes fail. The control connection on port 21 works, but the firewall blocks the high data port passive mode negotiates. Put the gateway on the camera VLAN, or open that passive port range on that segment only.
2. The gateway loses the socket. A laptop or an old test script is still connected, and the channel takes one client. One owner, always — the note above is the whole fix.
3. The camera runs the wrong job after a power cut. It boots the job in its flash; the startup push in the tip above is the fix. Belt and braces: compare the job name the camera reports against JobName on every reconnect.
4. Logins stop working entirely. The FTP account changed or was lost. Recover through the maker's documented reset for the device — there is no legitimate shortcut — then set a fresh account and store it once.
5. Flash wear. Every job push writes the camera's flash. Push at changeover only; the arithmetic sits in the FAQ.

When is replacing the camera the better call?

Below five cameras of a model, replace them; five or more, gateway them — and replace regardless once spares are gone or the inspection outgrows the old sensor's resolution.

The gateway is two to three days of build, wiring and soak. Across a fleet of ten that cost disappears; on one oddball sensor it never does. Three replacement triggers, hardest first:

• No spares, no repairs. A failed unit with no spare ends the debate. Buy current smart cameras and migrate the job.
• The inspection changed. Smaller features, new defects or a bigger field make resolution and optics the limit, not the protocol. Rework the application on a current sensor, or as a build from area scan cameras, a lens and a light — the camera finder filters on those axes. For old frame-grabber-era units, legacy camera driver setup says when revival is realistic.
• The count is small. Fewer than five units of a model: the per-camera engineering outweighs the per-camera hardware saving.

The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm focal length lens on GigE — the class of sensor you migrate a legacy job onto when the fleet shrinks.

Before you commit either way, confirm:

• Newest firmware for the exact model read, feature list checked for a job server — one hour that settles upgrade versus gateway.
• One camera baselined by hand: FTP login, job push, online mode, one result line captured.
• A host with a free port on every camera VLAN.
• Receive timeout at three times the slowest cycle, tested by pulling the cable.
• Result count over an 8-hour soak equal to the parts the line counted.

Tell us the camera count, models and VLAN plan and we will size the gateway and its host with you on the contact page.