Camera Modbus register address 50000: PLC mapping that works

You have configured the camera's outbound register map, registered its IP address in the PLC master's network configuration utility, and dropped a Modbus read instruction into the ladder. Then you type the camera's register number — 50000, in the case that comes up again and again — into the From Slave Element field, and the editor refuses it.

Sometimes the field takes a 4xxxx number instead and the read returns all zeros while the camera's own results page shows live data. Neither is a camera fault: the register number in the camera manual and the element the read box wants are written in two different conventions. This guide gives you the four ranges the field validates against, the subtraction that converts a camera register into a PLC element, a worked six-register example, and the tests that isolate the fault in ten minutes.

What the refusal is telling you

A Modbus read instruction does not validate against the camera's manual; it validates against the protocol's four data tables. The classic 5-digit convention labels each table with a leading digit and runs each one from 1 to 9999:

50000 matches none of the four. The instruction editor rejects it locally, before a single message leaves the PLC, which is why nothing you change on the camera alters that error. The number is the camera documentation's own label for its results block, not a protocol address; the same map also carries the coordinates the device answers on, a function code and an address.

The protocol's address field is 16 bits, so 65,536 addresses exist per table. Devices that need more than 9,999 words use 6-digit extended addressing, and that helps only when the read instruction documents support for it. A vision result block is a few dozen words at most, so the decision is easy: put the block at holding register 40001 and stay inside the classic ranges. Holding registers are the right table anyway — FC03 reads your results and FC06 or FC16 writes commands back to the camera, which you will want for trigger and part-type selection.

The From Slave Element field wants an element, not a register

Even a legal register number does not go into that field as printed. From Slave Element holds the slave data address in the master PLC's own numbering, and masters fall into two families.

Element-numbered masters take a plain 0-based element: the first holding register, 40001, is element 0. Convert with one subtraction:

Data-table masters take a word address in the PLC's own data table instead, and several PLC families number those words in octal. In one common mapping, slave register 40001 sits at word V0 — and because octal has no digit 8 or 9, the word after V417 is V420. An offset counted in decimal lands in the wrong word, so convert it to octal before typing it.

One boundary case: if the read succeeds but every value is shifted by exactly one register, the two sides disagree about base 1 versus base 0. The camera-side version of that fault is covered in Modbus 40xxx register offsets on a thermal camera.

Worked example: six words of camera results

An illustrative outbound map, of the kind you build on the camera's register page, with the block placed at 40001:

The read instruction: function code 03, From Slave Element 0, length 6 words.

• The cycle counter at 40006 converts as 40006 - 40001 = 5, so element 5. On an octal data-table master the offset is still five words up, written V5.
• A register further along, 40170, converts as 40170 - 40001 = 169. In octal that offset is 2×64 + 5×8 + 1 = 251, so the field takes V251 — typing V169 reads the wrong word.
• The X position spans two registers because a 32-bit value occupies two consecutive 16-bit words, in an order the device chooses. Fix the camera's X output at 3.5 during commissioning: as an IEEE-754 single-precision value, 3.5 is 0x40600000, so the pair on the wire is 16480 and 0. The word order that decodes to 3.5 is yours; the swapped order decodes to almost zero.

If you own the output format, publish one-word integers instead of floats: at 0.01 mm per count a 12.4 mm position becomes the single value 1240, and a signed 16-bit word still covers ±327.67 mm. The address arithmetic for values that must span two registers is worked through on this Modbus address mapping page for floating-point reads.

Tests that isolate the fault

1. Poll the camera from a PC with a Modbus test utility, reads only, at register 40001 with function code 03. If the camera answers with your six words, the slave side is finished and the fault sits in the master's element field.
2. Fix one outbound value — set X to a constant 3.5 — and read the block from the PLC. The element that carries 16480 and 0 proves the offset; move the From Slave Element until that element lands where the ladder expects it.
3. If the PC poll at FC03 fails, try function code 04 at 30001. A device that documents its results as input registers answers there instead, and the element subtraction becomes register - 30001.
4. Open the read instruction's help and check the accepted element range before planning a large map. Instructions limited to the four 5-digit ranges can never reach an extended address, which settles the remap decision on the master side.
5. Treat timeouts as network faults, not register faults. Confirm the route between PLC and camera first — the subnet discipline in reaching a smart camera across a routed network applies to a local cell network too.

The fix, by what you see

The zeros row wastes the most time, because the read looks healthy. If the camera's results page is live and the words do not move, the element is wrong — run the subtraction before touching anything on the camera.

Keeping the mapping fixed

• Print the camera's outbound map page and attach it to the PLC drawing. The element arithmetic only holds while that page holds.
• Have the camera increment one register every inspection cycle, and let the PLC compare consecutive reads. A heartbeat that stops changing catches a wedged camera job far faster than a zero check.
• Write the camera register number into the rung comment next to the read, so element 5 is never re-derived from 40006 by hand again.
• Version the camera job and the register map together. Changing one without the other is how good lines stop without warning.
• When several cameras feed one PLC, size the register space first as in vision coordinate arrays to a PLC over Modbus TCP, and keep the polling on one loop as multiple vision cameras on one PLC shows, so the element mapping is the only thing left to debug.

Choosing the camera side

The device class this exercise assumes is the smart camera or vision sensor: inspection runs on the device, and the results leave as words on the industrial network, with no PC in the loop. Two examples of the class: the MV-SC3050XC-16M-ATN-H, a 5 MP color vision sensor on Fast Ethernet, and the LS-SMC-0063, a 1.6 MP smart camera with a 16 mm lens on GigE. Whatever model you choose, its register map page defines what lands in each word — print it before writing the ladder.

If the camera is a bare area scan camera streaming to a PC, the camera has no register map at all: your PC software is the server, and you define the block yourself. Define it at 40001 with one-word integers and every trap above disappears. The architecture choice itself is covered in sending pass-fail results instead of images, and the same element arithmetic governs every Modbus slave the PLC polls — the Modbus RTU barcode reader example works the identical subtraction, and it applies just as well to a scale or a light controller on the same network. When a discrete signal is enough, wiring a vision sensor's OK/NG output to a PLC removes the register question entirely.

To size the camera before the register fight, start at the camera finder or the configurator. If the mapping needs a second opinion, send the camera's register map page and the read instruction's help page through the contact form and we will mark up both.