Vision camera EDS file and EtherNet/IP assembly mapping

Both sides ping, the EtherNet/IP connection shows open, and the tags stay empty — no results in the PLC, no trigger reaching the camera. The link is only the carrier: data moves once the camera's EDS file is installed in the PLC network tool and the two I/O assemblies are mapped. This guide covers that step end to end for a vision camera or a camera-plus-controller system on a PLC scanner: enabling the protocol on the camera, installing the EDS, choosing the connection points, mapping originator-to-target and target-to-originator bytes, verifying each direction, and finishing with named tags.

What you need before you start

Four things, and the fourth is the one people skip:

• A camera whose communication options list EtherNet/IP, plus that camera's PC software installed on a laptop — the EDS file normally ships inside its installation folder.
• A PLC with an EtherNet/IP scanner, with its engineering tool open. The tool carries the network configurator and the EDS registration utility.
• Two static addresses on one subnet. Example: PLC 192.168.250.1, camera 192.168.250.10. The subnet values are yours; what matters is that neither device draws an address from a pool.
• A port decision. Cameras with two Ethernet ports usually restrict industrial protocols to the primary port, so decide which port carries the vision laptop and which carries the PLC before you address anything.

For the vision side, smart cameras hold the job and the PLC-facing protocol in one address. The MV-SC5060XM-08M-WBN is a smart camera with a GigE interface, a rolling shutter and an 8 mm M12-mount lens; the MV-SC3050XC-16M-ATN-H is a 5 MP vision sensor with a Fast Ethernet interface and a global shutter:

When the processing belongs on a PC, an area scan camera feeds a vision controller, and the controller holds the PLC-facing side and the lighting. The MV-VC3301H-128G66 pairs an Intel Core i3 processor with 8 GB of memory and 4 built-in light channels.

Step 1: Enable EtherNet/IP on the camera

1. Open the camera's setup software and connect, then disconnect from the running job. Several vision tools refuse communication changes while a job is live, and some refuse them while any client is connected.
2. Find the industrial-communications settings — usually an industrial-Ethernet or protocol utilities menu in the setup software.
3. Select EtherNet/IP on the port that carries factory-floor protocols. On a two-port camera that is normally the primary port.
4. Enable inputs and outputs, one checkbox each. A connection that opens with both assemblies empty is the classic symptom of skipping this.
5. Apply, and restart the camera when prompted. The protocol binds to the port at startup, not on apply.

Step 2: Install the EDS file in the PLC tool

The EDS (Electronic Data Sheet) tells the PLC tool what the camera is: its identity, the assembly object (class 0x04) instances it publishes as connection points, the byte size of each, and the electronic keying values the scanner compares when the connection opens. Without it you can hand-build a connection, but you lose the sizes and the keying data — the two things that make the connection survive.

1. Open the EDS registration utility inside the PLC engineering software.
2. Register the EDS file, or the whole directory of EDS files when the tool offers that option. Camera suites ship several files — base device plus accessory variants — and registering the directory installs them together.
3. Confirm the tool lists the camera under its own name. A device that only appears as a generic adapter means the file did not register.

If the tool cannot find the file, look first in the installation folder of the camera's PC software, then in the camera vendor's support download area under industrial communications. The install-and-configure flow is the same on any EtherNet/IP device; another EDS file and assembly configuration walkthrough shows the same path on a different device class.

Step 3: Add the camera and set the connection

1. In the network configurator, add the camera from the EDS list under its own name, not as a generic EtherNet/IP adapter. The generic path works until keying or a size change bites.
2. Set the camera's IP address to the static address from your plan.
3. Pick the connection points: one originator-to-target (O→T) instance — PLC to camera — and one target-to-originator (T→O) instance — camera to PLC. Each lists a size in bytes. Copy both sizes; you need them in step 4.
4. Set the request packet interval (RPI) per direction: 10 ms both ways when the PLC triggers every part, 20 ms when the PLC only reads results. The bandwidth cost is trivial either way — the arithmetic is in step 4 — so choose by latency, not by load.
5. Leave electronic keying on the EDS defaults. If the connection is refused on keying, fix the installed EDS version rather than loosening keying; the diagnosis of EtherNet/IP keying and timeout faults covers that repair.

Some devices declare one direction empty. That is a legal assembly configuration, not a fault; assembly mapping with zero-length I/O on one side walks that case.

Step 4: Map the assemblies as raw byte arrays first

Map both directions as plain byte arrays — Byte[n] tags in the PLC — before any structure touches them. A byte array cannot be wrong about sizes or offsets; a structure can. Once the raw path works, step 6 gives the bytes names.

This example uses a typical results-plus-trigger camera. The sizes below are the example's EDS values; substitute yours.

T→O, camera to PLC, 46 bytes:

• 2 bytes status and heartbeat, 2 bytes result code, 12 bytes numeric results, 30 bytes ASCII data
• 2 + 2 + 12 + 30 = 46 → map as Byte[46]

O→T, PLC to camera, 8 bytes:

• 2 bytes trigger and control bits, 2 bytes command, 4 bytes parameters
• 2 + 2 + 4 = 8 → map as Byte[8]

At a 10 ms RPI the connection updates 100 times per second in each direction, and each update carries the whole assembly. 77 kbit/s is under 0.1 % of a 100 Mbit/s port, so dozens of cameras fit one subnet before bandwidth becomes a conversation.

The 5 ms exposure and 25 ms processing belong to this example job; the two RPI terms are yours. That is the decision: 10 ms per direction, because each direction delivers at most one update per RPI, and a PLC scan of a few milliseconds cannot act on anything faster.

CIP carries 16- and 32-bit values least-significant byte first; the camera's own data map is the authority for element order and meaning. The same mapping logic, with different payload types, is shown in byte-mapping vision results to a robot over EtherNet/IP and the implicit I/O assembly mapping used by code readers.

Step 5: Verify each direction

1. Download the configuration and go online. The connection opens clean, with no keying or timeout faults.
2. Watch the first two bytes of Byte[46]. The heartbeat in the status word changes value at every RPI; a live connection with a frozen status word means you mapped the wrong instance.
3. Force the trigger bit in Byte[8] for one PLC scan. The camera's job runs, and its own result view shows a new inspection record.
4. Compare the result code and the ASCII bytes in Byte[46] against the camera software's display for the same part. They must match byte for byte.
5. Run a known bad part. The result code changes and the PLC logic sees the difference — that is the point of the whole exercise.

Step 6: Give the bytes names

1. Build a user-defined type from the camera's data map: status word, result code, the numeric results with their real types, the string.
2. Overlay the structure on the same 46 bytes that Byte[46] reads. Do not map a second connection.
3. Keep Byte[46] and Byte[8] in the project. After any camera firmware update or job change that touches the data map, re-check the raw arrays before trusting the names.

For a picture of what a finished EDS-exposed register map looks like, this EDS register map example from a robot controller shows one end to end.

Where this setup goes wrong

• Connection opens, then times out and reopens: keying mismatch or an RPI the camera will not serve. The diagnosis of EtherNet/IP keying and timeout faults handles this family.
• Protocol settings will not save: the job was still live, or a client was still connected. Disconnect first.
• Assemblies full of zeros: inputs and outputs were not both enabled on the camera, or the two sizes were swapped between directions.
• Results unreadable after a job update: element offsets shifted. Back to the raw array, compare, rebuild the structure.
• Expecting images in the tags: a 5 MP frame is several megabytes; the T→O assembly carries tens of bytes. The live image travels on the camera's own stream — what actually displays live from a smart camera on a PLC HMI covers that path.
• Triggering from the camera's UI while the line runs: the PLC should own the trigger through the O→T assembly, the same argument as triggering a decode from a PLC tag instead of a button.
• The device has no EDS at all: do not hand-build connection points for production. Use explicit messages or raw TCP sockets to the PLC.

Handover checklist

• EtherNet/IP enabled on the correct port; inputs and outputs both on; camera restarted after the change
• EDS registered from the camera vendor's file; device added under its own name
• O→T and T→O sizes copied from the EDS; both directions mapped as raw byte arrays
• RPI 10 ms both directions for per-part triggering; 20 ms if the PLC only reads results
• Status word toggles at the RPI; a forced trigger runs the job; a good part and a bad part read differently in the PLC
• Structure overlaid on the raw arrays; raw arrays kept for the next data-map change

Pick the camera side in the camera finder, or start at the camera step of the configurator below and take the lens, light and controller with it.