You have four cameras on the switch, the PLC pings every one of them, and the network diagram even shows them as nodes. Then you drag the first camera onto the PLC to create its tag set and nothing loads: the drag is refused, or the parameters page comes up empty. In most cells this is not a network fault. It is a memory-area limit on the PLC side, and it has a number attached. This walkthrough sizes a tag set in bytes and words, picks the memory area that will actually hold several cameras, and takes the implicit I/O connection through to a verified, repeating trigger.
Why won't the tag set add to the PLC?
Because the destination cannot hold it: an implicit I/O tag set needs one contiguous block of words in a single memory area, and the area the tool fills in by default — CIO — rarely has a long enough free run once several cameras are counted.
The add step runs two checks before it builds anything. The connection size must match an assembly the camera's EDS file declares, and the destination area must show that many free words in one unbroken run at the address you gave it. Fail either check and nothing loads.
The failure reaches you in one of two messages. The drag of the camera onto the PLC is refused with "Since it has not valid connection information, it cannot execute." Double-clicking the camera instead reports that no settable parameters exist. Both point at the same root: no connection with a size the PLC accepts has been placed in an area that can hold it.
If the tool cannot see the camera at all, stop here — that is an addressing fault, covered in smart camera not connecting: fix IP and subnet mismatches. The rest of this walkthrough assumes the camera answers and the connection is the part that fails.
How many bytes and words does a tag set need?
Add the input and output assembly bytes, then halve: one camera with full custom blocks measured at 332 bytes of output and 280 bytes of input needs 612 bytes, which is 306 words of PLC memory.
The output assembly is what the PLC sends: trigger bit, job or program number, reset. The input assembly is what comes back: judgement words, error codes, busy and done bits. Blocks that expose everything the camera can report run to hundreds of bytes per direction; a set trimmed to what your ladder actually reads runs to tens.
Odd sizes round up: a 33-byte assembly occupies 17 words.
Each direction of each connection travels as one UDP packet, so an implicit connection tops out near 1,500 bytes per direction. At 280 to 332 bytes per direction, camera sets sit far below that ceiling — the constraint that bites is PLC memory, not packet size.
Keep, when you trim: one trigger word, the judgement words you branch on, one error-code word, and the status word carrying the run and done bits. Everything else — per-region statistics, floats nobody displays, unused light commands — is word count you pay for on every camera, in every direction.
Which memory area should the cameras use: CIO, W or DM?
Map camera implicit I/O to W or DM words — W for a clean mid-size block, DM when the cell grows past a few thousand words — and leave CIO for the rack's own I/O.
CIO is shared ground. Basic I/O takes its words from the bottom of the area, and every bus unit and special I/O unit in the rack claims a fixed block of its own inside the same area. Those reservations never move, so the longest free contiguous run shrinks as the machine grows — which is exactly when you add cameras. W has nothing reserved inside it: a free run you see there is genuinely free. DM runs to 32,768 words, D00000 to D32767, and holds through a power cycle, so a layout you document once stays put. H works too but is usually spoken for by the program; an EM bank, where the CPU has one, is the overflow for very large sets.
A value you need only occasionally does not deserve tag-set space: between triggers, an explicit message can read DM directly, and the CIP message structure for DM memory access shows the field layout that reaches it.
How many cameras fit before the tag set fails?
Four cameras with full 306-word sets need 1,224 contiguous words; the same four cameras trimmed to 18 words each need 72 — both fit W or DM, and only the trimmed set fits a leftover CIO run on a populated rack.
Worked example, four cameras, full blocks:
- Output, PLC to camera: 332 bytes × 4 = 1,328 bytes = 664 words
- Input, camera to PLC: 280 bytes × 4 = 1,120 bytes = 560 words
- Total: 1,224 words in one unbroken run. In CIO that lands on top of the rack's reserved blocks; in W or DM it is one line in the drawing.
The same cell, trimmed to what the ladder reads:
- Output: 4 bytes × 4 = 16 bytes = 8 words
- Input: 32 bytes × 4 = 128 bytes = 64 words
- Total: 72 words for the whole cell.
Packet check, per connection: the largest direction is 332 bytes, far inside the 1,500-byte packet ceiling, so no single camera connection is the blocker at these sizes.
Set the refresh interval against the camera's frame rate. At 60 fps a camera rewrites its results every 16.7 ms (1,000 ÷ 60), so 20 ms is the useful floor for the connection's refresh — a 5 ms setting reads the same result more than three times before it changes.
The far end can be any vision sensor or smart camera; the limits you just sized sit on the PLC side, not on the camera model. Start the imaging side in the smart cameras range.
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Interface
- GigE
- Resolution
- 6-10 MP
Why does the tool say the camera has no valid connection information?
Because the EDS has not declared a connection the PLC can size: the drag only works from connection parameters the EDS file defines, so an unregistered or generic EDS leaves both the drag and the parameters page empty.
An EDS file states the device's identity and I/O capability to the network tool. Register the one from the camera's setup package and the connection-size fields appear; the drag then builds the implicit link instead of refusing it. Some tools expose the same fields under the device's properties page rather than the double-click dialog, so look there before concluding the file is bad.
If the EDS declares full-size assemblies and the PLC still refuses, shrink the declared connection at the camera first — pick the smaller assembly, or trim the configured output and input in the camera's own software — then rebuild the tag set to match. How the assembly instance lands in ladder is the same mapping a code reader uses, walked through in mapping a barcode reader's implicit I/O assembly; the PLC-side steps are in master–slave I/O tag mapping in the PLC programming software.
How do I check the connection once it loads?
Trigger one camera and watch its first input word change — the run bit settles high and the result word updates on every trigger, which proves the whole path from tag set to ladder.
- Go online and open the connection status view: every camera should show an established connection. One that cycles into timeout is a keying or assembly-instance fault, not memory — vision camera on EtherNet/IP: PLC keying and timeout faults covers that fix.
- Force camera 1's trigger bit in its output word; the busy and done bits in its input word should toggle within one refresh period.
- Present a known bad part: the judgement word must change value, not just the done bit.
- Repeat per camera, one at a time, so a missing result names the connection to fix.
- Power-cycle the switch once; connections should re-establish without re-adding anything.
Once the words sit in W or DM, anything on the network can read them — vision sensor results to an HMI: implicit or explicit sorts out which route the HMI should take.
How do I keep the next camera from failing the same way?
Reserve a fixed DM block per camera before you wire it — 512 words each, starting at D20000 and stepping 512 — so camera five drops into pre-cleared memory instead of fighting CIO leftovers.
Five checks keep the next commissioning quiet:
- Byte-count the tag set from the camera's declared assemblies, halve to words, and add margin.
- Write each camera's start word, word count and refresh interval into the electrical drawing.
- Name one tag set per camera after its station, so swapping one camera never touches the others' blocks.
- Keep strobe commands off the camera connection: lighting runs from a controller's own outputs, not from camera output words.
- Re-run the count after any camera firmware update — assembly sizes can change with a feature release.
That lighting controller comes from the light controllers range, sized to the strobe channels you actually switch.
- Output
- Constant voltage 24 V
- Channels
- 4 channels
- Control
- Digital
Every added camera is one more cable to the switch as well — the cables range covers the runs.
- Type
- Code Reader Cables
Size camera five before you order it: run the cell through the system configurator, or send the assembly sizes and CPU model through the contact page and we will lay out the word map with you.
Inspection on the device, no PC
350 models · from $169.00Kérdések
Can I split one camera's tag set across two memory areas?
No. One implicit connection maps to one contiguous block in one area — the tool will not build a connection whose words straddle CIO and W. If the block does not fit, move the whole set to a bigger area or trim the tags; splitting the set is not something the connection supports.
Do bit results really cost a whole word each?
Only if you map them that way. Declared as separate booleans, each result rounds up to a full word; declared as bits inside a shared word, sixteen booleans pack into one word. A camera reporting eight pass/fail results drops from eight words to one just by packing them as bits.
Does a bigger tag set slow the PLC scan?
Barely. The network side refreshes the words in the background at the interval you set, and the ladder only spends scan time on words it actually references. The real costs of a big tag set are memory, packet size and the add failure you are fixing — not scan time.
What if the tag set still will not add after moving to W or DM?
Then the limit is the connection size, not the area. Check that the assembly the EDS declares matches what the camera is configured to send, and that the total implicit bytes stay within the scanner's connection budget. Shrinking the declared connection on the camera side and rebuilding the tag set clears most remaining refusals.
Should trigger bits and result words share one tag set?
Yes. One tag set per camera carrying both directions keeps the trigger and its result in one block, so the ladder reads a single station per scan. Splitting them across two connections doubles the connection count and makes timing at short refresh intervals much harder to reason about.