An EtherNet/IP vision camera that reports I/O not responding, then Code 16#0116 Electronic Keying Mismatch, then Code 16#0204 Connection Request Error once you disable keying, is reporting two faults on two different layers in a fixed order. The keying fault is an identity problem at connection set-up. The timeout is a timing problem in the cyclic I/O connection itself. This walkthrough is for controls engineers wiring vision sensors and smart cameras into a PLC's EtherNet/IP tree. You will update the correct firmware, decide keying with the trade-off in mind, set a requested packet interval that holds, and prove the connection under production load.
Why does the PLC report the camera's I/O as not responding?
Nine times out of ten the camera is reachable but the PLC's cyclic I/O connection to it will not hold: first an identity mismatch at connection set-up (Code 16#0116), then a requested packet interval faster than the camera's built-in adapter can service (Code 16#0204).
The two warning marks — one on the Ethernet module, one on the camera — arrive in that order for a reason. Code 16#0116 stops the connection during set-up, before any cyclic data is negotiated, so no timing change can clear it. Once identity passes, the surviving fault sits in the run-time layer, where only packet rate and network path matter.
Rank the causes before you touch a setting:
- Bridge module firmware older than the camera's current EDS revision — shows up as Code 16#0116.
- Requested packet interval faster than the adapter services it — shows up as Code 16#0204.
- Network path: subnet mismatch, packet filters, a fallen link speed — shows up as Code 16#0204 or as no response at all.
Read the exact code in the module properties and let it route you: 16#0116 sends you to firmware and the EDS, 16#0204 sends you to RPI and the network. A successful ping proves less than it seems, because connection set-up relies on broadcast discovery rather than ICMP. Confirm that camera and PLC share one subnet before changing anything else.
What does Code 16#0116 electronic keying mismatch compare?
Code 16#0116 means the major or minor revision in your configured module profile does not match the revision the camera reports when the PLC tries to connect: electronic keying compares vendor ID, product type, product code and revision, one attribute at a time.
The family includes Code 16#0114, where product code or vendor ID mismatches and the profile probably belongs to a different device altogether. A revision fault like 16#0116 is subtler: right model, wrong vintage. Either the profile predates a camera firmware update that bumped the reported minor revision, or the PLC-side bridge firmware predates the embedded-EDS support that lets the controller software read the device's identity directly during set-up.
Bridge firmware is therefore the first move, not a last resort. Release notes for one widely deployed bridge revision list embedded-EDS support as the headline change, and integrators repeatedly report that a flash cleared connection faults that looked like camera problems. Bring the bridge current first, then re-create the module profile so it is built from the device's live identity rather than a stored file.
Should I disable electronic keying on the camera's module profile?
Yes — for a network vision device, disable keying in the module profile once the connection is proven, and manage identity by procedure instead: keying on Ethernet modules re-checks identity at every connect, and a routine camera firmware update changes the revision and faults an otherwise healthy cell.
Work in this order: bring the bridge firmware current, re-register the camera's EDS so the profile matches the live device, prove the connection with keying still enabled, then set keying to disabled and write the identity into the change record. Disabling keying removes the revision tripwire permanently — which is exactly the protection you are trading away, as the note below spells out.
Why did the bridge firmware update clear the keying fault but not the timeout?
Because the two faults live on different layers: the firmware update fixed identity (16#0116 is a set-up check), while Code 16#0204 is a run-time timing failure — the connection is now allowed, but the camera's built-in adapter cannot return I/O packets at the rate you asked for.
The story repeats across integrations: the flash removes the mismatch error, the timeout error stays, and the firmware update gets blamed as the wrong fix. It was half the fix. Expect the second fault and read it as timing, which routes you to one setting — RPI — rather than back to the addresses you already checked. The error text says it plainly: connection request timed out.
What RPI should a vision camera run at on EtherNet/IP?
Set the requested packet interval (RPI) to 10 ms or slower, starting at the safe 20 ms value recommended below, because integration references place the floor for these adapters at 10 ms, and anything faster lets the camera miss its expected packet interval until the PLC kills the connection with Code 16#0204.
RPI is how often the PLC asks the adapter for an I/O packet. The adapter must deliver one at least every RPI multiplied by the connection's timeout multiplier, or the PLC faults the connection:
Here t_result is the camera's own result period — 1000 ms divided by its inspection rate — and t_jitter is the slack you leave for load spikes.
Worked example, a camera inspecting 30 parts per second:
- t_result = 1000 ms ÷ 30 ≈ 33 ms
- RPI 5 ms with M 4: T_expected = 5 × 4 = 20 ms, shorter than the 33 ms result period, so the adapter misses its window and the PLC drops the connection with Code 16#0204
- RPI 10 ms with M 4: T_expected = 10 × 4 = 40 ms, which beats 33 ms by only 7 ms — it holds, but with little room
- RPI 20 ms with M 4: T_expected = 20 × 4 = 80 ms, about 2.4× the result period — comfortable
Start at the 20 ms value from the example and approach 10 ms only when a measured cycle time demands it. A faster sensor does not move the floor: the LS-SMC-0063 runs 1.6 MP at 60 fps over GigE. At 60 fps a result lands about every 17 ms, still far inside an 80 ms connection window. Throughput sanity check: a 1,000 parts-per-minute line delivers 60,000 ÷ 1,000 = 60 ms per part, so this starting RPI returns three result updates for every part.
How do I prove the connection holds before releasing the line?
Run the cell at full production rate for at least 30 minutes with the module fault table open — a corrected RPI shows zero Code 16#0204 occurrences across thousands of I/O packets, while a marginal one faults within the first few hundred cycles.
At that starting interval the soak exchanges 1,800 s × 50 packets/s = 90,000 I/O packets, deep enough to expose a marginal window. While it runs, check three things:
- Results land in the PLC data table at the part rate and match the image the camera itself shows in the HMI.
- Pulling and restoring the camera's Ethernet cable yields one clean fault and one clean recovery, not a connection that never comes back.
- Both ports hold full link speed — a port that falls back to 100 Mbit re-opens packet-size and bandwidth faults.
If the soak still faults, the survivors are physical. Packet filters that pass ping but drop the cyclic UDP path are a known trigger of Code 16#0204 — the same family of IP and firewall mistakes that block lighting controllers on Ethernet. Put the camera on the PLC's subnet with a managed switch running IGMP snooping between them, because multicast I/O floods an unmanaged switch.
Line-side staff watch those results on an HMI rather than at the camera's own tool, which is where industrial panel PCs usually sit.
When is a vision controller a better PLC endpoint than the camera?
When the PLC needs more than one pass/fail word — multi-camera cells, recipes, traceability data — put the cameras on a vision controller and let the PLC talk to the controller: it absorbs the camera-side timing entirely, and the PLC link carries stable result data instead of riding on each camera's adapter.
You tune one connection instead of one per camera, and the cameras attach to the controller's own LAN ports on a subnet separate from the plant network. Keep the heavy image processing off the PLC — a PLC realistically handles only lightweight image processing — and if your cameras speak GenICam rather than EtherNet/IP, the same camera-to-controller-over-Ethernet pattern applies, with the controller as the collection point.
The MV-VC3301H-128G66 is the small end of this pattern, with 5 or more LAN ports, 4 built-in light-output channels, 8 GB of memory and an Intel Core i3 processor.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Smart cameras stay in the cell wherever one camera, one part, one result is the entire job — the two below are the sensor class this whole setup applies to:
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Interface
- GigE
- Resolution
- Up to 3 MP
If your cell is drifting toward several cameras feeding one PLC word each, start comparisons in the vision controllers category, and message the team through the contact page when you want the camera/controller split sized for your layout.
What do I check before the next camera integration?
Budget ten minutes of checklist time before you power up: firmware current on bridge and camera, EDS re-registered after any update, keying disabled with identity recorded, RPI set to the safe starting value, timeout multiplier chosen deliberately, and a managed switch between PLC and camera.
- Bridge firmware at the latest revision — embedded-EDS support removes a whole class of Code 16#0116 faults.
- Camera firmware and EDS updated together — one without the other recreates the revision mismatch.
- Keying disabled, with vendor ID, product code and revision recorded — identity becomes a procedure instead of a check.
- RPI at the safe starting value from the worked example, never below the 10 ms floor — this is the setting that prevents Code 16#0204.
- Timeout multiplier chosen on purpose — it sets how fast a dead adapter is detected.
- Managed switch with IGMP snooping between PLC and camera — multicast I/O stays off segments that do not need it.
- A 30-minute full-rate soak before release — 90,000 packets at that RPI, enough to expose a marginal window.
Work the list top to bottom at integration time and neither of the two faults above reaches your commissioning report.
Questions
Can I poll vision results faster than 10 ms if my line runs faster?
Almost never. A 1,000 parts-per-minute line delivers a part every 60 ms, so a starting RPI already provides three result updates per part. Push below 10 ms and the camera's adapter starts missing its expected packet interval, which is what triggers Code 16#0204. If a cycle genuinely needs faster updates, move the handshake to a vision controller rather than raising RPI past the camera's floor.
Does the camera still need its EDS file when keying is disabled?
Yes. The PLC builds the module profile from the EDS whether or not keying checks it at connect time. Keep the EDS matched to the camera's firmware version and re-register it after every update; newer bridge firmware can also read the EDS embedded in the device, which removes most stale-file mismatches.
Why does the camera run fine in its own software but fault on the PLC?
The camera maker's tool talks to the camera over explicit messages on TCP, which are patient and one-at-a-time. The PLC's I/O connection is cyclic UDP with a hard expected packet interval. A tool that works therefore proves the IP settings are right and points the diagnosis squarely at RPI and the I/O path.
Can a firewall or router between PLC and camera cause Code 16#0204?
Yes. Packet filters that pass ping but block the UDP I/O path are a documented cause of Code 16#0204, because the explicit connection succeeds while cyclic I/O silently dies. Keep the camera on the PLC's own subnet with just a managed switch between them; a router with filtering has no job there.
Which timeout multiplier should I pick for a vision camera connection?
The standard choices are 4, 8, 16 and 32, and they multiply the RPI into the effective watchdog. At a 20 ms RPI, a multiplier of 4 detects a dead camera in about 80 ms, while 32 stretches the same detection to 640 ms — roughly ten missed parts on a 60 ms cycle. Use 4 unless electrical noise causes false trips.