A camera that returns its inspection result as a plain TCP string — JSON or comma-separated text over a socket — does not speak the FX5U's native MC protocol (SLMP), so the register-mapping route is closed. The FX5U still handles the job with its built-in Ethernet port, three socket instructions and some parsing ladder; no extra module and no PC sit in between. This guide is for the controls engineer wiring that first link. You will choose between raw-socket ladder and the pre-defined protocol, plan addresses and ports, write the open-trigger-receive sequence, size the receive buffer with real arithmetic, and prove the link before production.
Choose the path before you write any ladder
Answer one question first: can the camera speak a PLC-native protocol? If its communications manual lists SLMP, MC protocol or Modbus TCP, stop — you map result registers and poll instead of writing sockets. If it only offers EtherNet/IP, that is a heavier, module-based integration on the PLC side. The raw-TCP path in this guide covers the common middle case: the camera accepts a socket and streams one text line per inspection.
Whatever the transport, carry results over it — pass/fail flags, coordinates, judgment codes — never images. The reasoning is in Vision system to PLC: send pass-fail results, not images. And if the camera and PLC can agree on a simple shared protocol, the trigger-and-result pattern in Smart camera to PLC over TCP: trigger and pass/fail is less ladder than this one; come here when the camera's only output is its own text format.
| Situation | Path | What you write |
|---|---|---|
| Camera lists SLMP, MC or Modbus TCP | Native protocol mapping | A register map and a poll — no sockets |
| Fixed format, one command, one answer | Pre-defined protocol | Define the message and delimiter once, call one instruction per exchange |
| Any raw TCP camera, variable formats | SP1 socket ladder | Open, send, receive and parse — this guide |
| Camera offers EtherNet/IP only | EtherNet/IP integration | Module and tag mapping on the PLC side |
What you need on the bench
- The FX5U CPU: its built-in Ethernet port runs the socket instructions, so nothing extra slots beside it.
- The camera configured for its raw TCP output: the port number and message format come from its communications manual.
- A PC with the FX5 ladder programming software, and a small Ethernet switch.
- Reserved devices: a connection number, target IP and port words, a send buffer if the camera expects a trigger command, and a receive buffer sized in the worked example below.
On the camera side, vision sensors fit this pattern well: they inspect on the device and publish one text line per result. Two current options:
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Interface
- Fast Ethernet
- Resolution
- 5 MP
The MV-SCB007EC-12S-WBN pairs a 1.6 MP color sensor with a fixed 12 mm lens and manual focus on a Fast Ethernet port — the compact pick for a single station. The MV-SC3050XC-16M-ATN-H steps up to 5 MP color with a global shutter, also over Fast Ethernet, when the inspection needs the extra resolution.
Plan the addresses and decide who dials
Put the PLC and camera on one subnet nothing else shares — for example PLC 192.168.10.10, camera 192.168.10.20, mask 255.255.255.0 — and let the camera listen on a fixed TCP port, say 5000, set in its own configuration. Run the link on its own switch, not the office network.
Make the FX5U the client. It dials the camera's address and port with a client (active) open, which keeps the port assignment explicit and gives each connection number exactly one camera. Let the PLC listen passively only when the camera insists on dialing out; the trade-offs are the same as for any network device, laid out in TCP client or listener: match your network barcode reader to your host.
The ladder sequence: open, trigger, receive
- Reserve and fill the connection data: connection number 1, the camera's IP and port in the word devices the instruction reads, and the receive count worked out in the next section.
- On a rising start bit, call SP1.SOCOPEN for connection 1 as a client open. The connection's completion device turns on when the socket is established; the error state means address, port or wiring needs a look. Guard the call so an already-open connection is never opened twice.
- If the camera waits for a command, store the trigger text — for example TRIG followed by CR and LF — as two ASCII characters per word in a send buffer, and send it with SSEND the moment the part is in position. Free-running cameras that just publish results skip this step.
- Call SRECV for the connection every scan, pointed at the receive buffer and its maximum word count. When data arrives, the instruction stores it and the received byte count lands in the device you assigned.
- When the byte count is greater than zero and the line terminator is present, run the parse, consume the values, and reset the request for the next shot. Give the path a timeout of 2 to 3 s — several inspection cycles' worth at typical vision rates — so one missed shot does not trip the link.
- At production stop, close the connection with the matching SP1 close instruction and re-open on the next start. A timeout branch that closes and re-opens after a cable fault keeps the cell running without an operator.
Worked example: sizing the receive buffer for a 38-byte JSON result line
Inputs, and where each comes from:
- Message format — a realistic line in the JSON style these cameras publish:
{"Judge":"OK","X":123.45,"Y":-67.89}, which is 36 characters. You fix the format with the camera at commissioning; the example assumes this one. - Terminator — CR plus LF, 2 bytes, appended by the camera to each line.
- Storage rule — the FX5U holds ASCII and UTF-8 bytes two per word in buffer devices.
Rule in words: total bytes equal characters plus terminator bytes; receive words equal total bytes divided by two, rounded up.
Set the SRECV receive count to 32 words. A full line then reports 38 bytes received, with headroom for a longer judgment code or an extra coordinate pair.
Decision, with the threshold: any result string up to 64 bytes (32 words) runs on this path with no change to the buffer. Past that, raise the count or move the message definition into the pre-defined protocol, which sizes and delimits the message itself. Beyond roughly 256 bytes per message — many fields, several parts — the PLC-side parse gets clumsy, and that is the signal to move vision onto a controller instead.
The coordinates parse the same way in every format: the six ASCII digits 123.45 convert to binary and multiply by 100, giving 12345 as hundredths of a millimeter in a data register; the motion program scales back on use.
Parse the string into registers and hand it off
Find the delimiters first — commas, quotes or the CR LF — then convert each numeric field from its ASCII digits with the FX5U's ASCII-to-binary conversion instruction, scale it (×100 in the example above), and move it to the register the motion or reject program consumes. Set a data-valid bit for one scan so downstream logic sees each result exactly once, and clear the buffer words before the next receive so stale characters cannot leak into a new parse — the same discipline as for storing ASCII barcode strings in PLC memory. If a robot or a second controller wants the outcome, hand over coordinates and judgment through a register handshake, the pattern in Send vision coordinates to a PLC through a register handshake.
Count bytes, not characters, whenever the format can carry UTF-8 beyond plain ASCII: one multi-byte character shifts every delimiter behind it. The byte-level workings of FX5U ASCII and UTF-8 sockets are walked through in the FX5U Ethernet TCP socket communication with UTF-8 ASCII protocols reference.
When the socket ladder is the wrong tool
Three cases argue against hand-written sockets:
- Fixed message format, one command, one answer. Define the send message, receive message, delimiter and timeout once in the pre-defined protocol support the FX5U ships with, then run each exchange with a single instruction call. The format lives in one definition instead of scattered compare runs, and the receive length is managed by the protocol rather than your ladder.
- The camera offers Modbus TCP or SLMP natively. Map registers and poll — no parsing at all — and when several cameras converge on one CPU, follow the one-poll-loop pattern in Multiple vision cameras on Modbus TCP: one PLC CPU, one poll loop.
- Many cameras, heavy parsing or AI-based checks. Put a vision controller between camera and PLC: it runs the inspections and hands the FX5U clean results over Modbus TCP, as walked through in Vision controller Modbus communication: a PLC integration guide.
Two controllers sized for that middle role:
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
The MV-VC3301H-128G66 runs its vision software on an Intel Core i3 with 8 GB of memory and a 128 GB SSD; five-plus LAN ports leave room for the cameras and the PLC link, and four built-in light channels drive the illumination as well.
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
The MV-VC2140-128G40-1T is the compact step: Intel N-series processor, 8 GB of memory, a 128 GB SSD plus a 1 TB HDD for image logs, 3-4 LAN ports and four built-in light channels.
Prove the link before production
- Ping the camera from the engineering PC, then from the PLC, before any ladder runs.
- Force an inspection and watch the received-byte-count device live: a constant zero means the camera is not publishing (wrong port, or a camera that dials out instead of listening); a stuck partial count means a missing terminator.
- Send a test line from the camera's own test utility, or from a PC terminal, and confirm the parser returns the expected registers — the parse should not care where the bytes came from.
- Pull the Ethernet cable mid-run and watch the ladder take the timeout branch, close and re-open without an operator.
- Fire ten results in quick succession and confirm there is no concatenation: one line consumed per receive, buffer cleared between them.
- Log the byte count over a shift: a count that creeps upward means the message format on the camera side changed.
If you are still choosing hardware for either end of the link, start at the smart cameras and vision controllers categories, or step through the configurator below. More wiring patterns for PLC links are collected on the systems topic page, and when a build needs a second opinion, the contact page reaches us directly.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Do I need an extra Ethernet module on the FX5U for raw TCP sockets?
No. The FX5U's built-in Ethernet port runs the socket instructions itself, so the raw-TCP path adds no hardware and takes no module slot. A module only enters the picture when you choose an industrial protocol such as EtherNet/IP on the PLC side, which is a different and heavier integration than the plain TCP sockets this approach uses.
Should the FX5U be the TCP client or the server?
Make it the client whenever the camera allows it: the PLC dials the camera's fixed address and port, so the port assignment is explicit and each connection number belongs to one camera. Let the PLC listen passively only when the camera insists on dialing out — then the camera owns the retry behavior, and the PLC must handle a connection that arrives and drops at any time.
What happens if the camera sends a second result before the PLC reads the first?
TCP queues it, so the next receive returns both lines joined together, and a parser expecting one terminator reads the joined text as one corrupt message. Prevent it at the source: publish a result only after a trigger, or poll faster than the camera completes inspections. In the ladder, consume exactly one line per receive and clear buffer leftovers before the next shot.
How fast is FX5U socket communication with a camera in practice?
The exchange itself costs single-digit milliseconds on a switched Ethernet link: the socket write, the receive and the parse together span a few scan times of the FX5U. The camera's inspection time — exposure, processing, transfer — dominates the cycle at tens to hundreds of milliseconds, so the socket path almost never sets the pace of the application.
Can one FX5U keep sockets open to two cameras at once?
Yes. Each connection number you open is its own socket, so two cameras can stay linked and be polled in turn in the same scan. Give every connection its own receive buffer and result registers so a fast camera cannot overwrite a slow one, and stagger the receive calls across the scan. Confirm the connection-count limit for your CPU in the FX5U Ethernet manual before planning a larger cell.