Modbus decides cobot compatibility: force torque sensors and cameras

A force-torque sensor and a wrist camera both bolt to the flange, and both can look equally portable in a catalog. They are not. When the cell is copied onto a second collaborative arm from another maker, one of the two usually travels and the other stays behind. The difference is decided by two things you can check before anyone spends money: the protocol the device speaks, and the place its software runs. The two checks below, plus a worked Modbus RTU sizing example, tell you what travels, what gets rebuilt, and which parts turn the next arm swap into a calibration day instead of a re-purchase.

The two questions that decide compatibility

Ask them in this order. First: what protocol does the device speak to the outside world? A sensor that behaves as a Modbus RTU slave exposes plain data registers to any matching master — the robot controller, the PLC, or a vision controller — regardless of who built the arm. Second: where does the device's software run? A wrist camera whose locate, path-teaching and hand-guiding functions are delivered as a plug-in inside one robot brand's controller has nowhere to run on any other brand. The head mounts fine; the intelligence stays behind.

The working rule follows directly. Protocol decides whether data travels; software residence decides whether features travel. Applied to the two devices engineers ask about most:

The sensor keeps its value across brands. The camera usually does not, unless its maker's compatibility list names the new controller generation.

Why the wrist camera stays behind

One widely used wrist camera family for collaborative arms ships its vision as controller software: the head contributes a global-shutter image, while calibration, part location, path teaching and hand-guiding all execute inside that robot brand's application environment. Compatibility is published per controller generation, and a camera certified for one family's line can drop off the list when the next generation appears — the same failure pattern as a camera that only works with a newer controller, running in reverse.

Move that head to another brand's arm and what remains is an uncalibrated image source. Every locate model, every taught path and the hand-guiding convenience stay on the old controller. One maker publishes per-generation setup and compatibility notes for its wrist camera; the wrist camera setup and compatibility reference shows what such a list looks like, and it is worth reading before a move rather than after.

If portability matters, buy the inspection intelligence outside the robot. A smart camera with its own runtime needs only Ethernet and power from the cell, and any controller, PLC or PC can be its master; the smart cameras page filters them by resolution, shutter and mount. For wrist or near-part mounting, the compact GigE models with onboard inspection are the usual pick:

Where the task needs heavier algorithms or a larger sensor, an X86-platform camera that accepts C-mount lenses runs its own software on a bigger canvas:

Either camera triggers over Ethernet or a discrete input, so the handoff does not depend on the robot brand; one pattern is a remote snapshot trigger over TCP, no teach pendant involved.

Why the Modbus force torque sensor travels

A force-torque sensor built as a Modbus RTU slave is a different story. Its registers hold the six components — Fx, Fy, Fz and the three torques — and any master that speaks the protocol can read them: the robot controller, the PLC, or a vision controller on the same line. Where the receiving side has no serial port, an RTU-to-TCP gateway terminates the serial line and re-publishes the same registers on Ethernet, so the stream reaches any device that can master Modbus TCP.

What does not travel is the vendor layer above the protocol. Guided search paths, hand-guiding and insertion routines sold with a sensor family are usually software on the robot side; on a new controller you either use that controller's own force functions or write your own loop against the register stream. Deep integration — placing the external sensor inside the controller's force-control loop — means writing a plug-in against that controller's development environment, and that work is controller-specific by construction. A controller-side force sensor search configuration example shows how much of a force routine can live inside one brand's controller software.

The same protocol question decides smaller wrist devices too. Distance and presence sensors on collaborative arms choose between IO-Link, Modbus and move-until wiring; this cobot sensor protocol comparison lays out the trade-offs, and the deciding question is the same: which side has to run software?

Sizing the Modbus RTU stream for a six-axis sensor at 115200 baud

This is the calculation to run before promising a force-controlled move on the new controller.

Inputs, and where each comes from:

• One sample is six 32-bit IEEE 754 floats — Fx, Fy, Fz, Tx, Ty, Tz. Each float crosses Modbus as two 16-bit registers, so one sample occupies 12 registers.
• Reading registers costs one request frame of 8 bytes and one response frame of 5 bytes plus 24 data bytes, from the Modbus RTU frame layout.
• The port runs at 115200 baud, 8N1 — 10 bits per byte. That is the top rate industrial serial devices commonly accept; the sensor manual lists the range it supports.
• Modbus RTU demands 1.75 ms of line silence between frames at rates above 19200 baud, a fixed value in the specification.

The rule in words: line time per poll equals total bits divided by port speed; the minimum cycle is that line time plus the silence; a poll period is safe while the cycle stays near or under half of it.

The arithmetic:

• Total frame bytes: 8 + 29 = 37 bytes, which is 37 × 10 = 370 bits at 8N1.
• Line time: 370 ÷ 115,200 bit/s = 3.2 ms.
• Minimum cycle: 3.2 + 1.75 = 4.96 ms, call it 5 ms.
• Register check: 12 registers sits far below the 125 a single Modbus read may carry, so one request fetches all six values. Splitting them into six single-register reads would repeat the 37-byte exchange six times and multiply the line time by six.

The decision: at a 10 ms poll period (100 Hz), the line is busy 4.96 ÷ 10 ≈ 50 % of the time — comfortable, with margin for one retry. At a 4 ms period the 4.96 ms minimum cycle already exceeds the budget, so RTU cannot carry it at any framing trick. That is the threshold: if the receiving loop wants updates every 4 ms or faster, route the sensor through the gateway's Modbus TCP side. The same 37 bytes occupy 100 Mbps Ethernet for (37 × 8) ÷ 100,000,000 ≈ 3 µs of wire time, and the limit becomes the software loop rather than the wire.

Port speed scales the line time directly. At 38400 baud the exchange takes 370 ÷ 38,400 ≈ 9.6 ms, and a 10 ms stream no longer fits; every halving of the rate doubles the line time and halves the stream rate you can promise.

What a vision controller adds to the chain

Something in the cell has to be the Modbus master, hold the register map, and hand results to the robot and the PLC. A vision controller does all three on one box: it reads the sensor stream over its LAN ports or an attached gateway, runs the inspection application, and publishes results to the PLC in register form — the vision controller Modbus communication guide walks through that exchange. Built-in light channels drive the inspection lights from the same box, so the light controller is not another device to integrate.

The controller classes below cover the common cell sizes, from a single camera plus gateway to multi-camera stations:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

When the camera rides on the arm, a model with PoE camera ports feeds it power and image data over one cable, which is one less line to route along the arm. If the same cell also inspects parts between picks, plan trigger, exposure and handoff as a single timed cycle; the collaborative robot vision inspection planning guide breaks that cycle into its stages.

Checks before you order

Run this list per device, before the purchase order rather than after the first fault:

1. Protocol role. Write down which device is slave and which is master on each link. A Modbus slave speaks only when polled, so something must poll it.
2. Serial facts. RS-485 versus RS-232, connector style and supply voltage come from the sensor documentation, and the gateway must match all three.
3. Register map and word order. Get the holding-register list, and check the float word order against a known force before trusting the stream.
4. Port speed and parity. Both ends must agree; the sizing above assumed the top common rate, and a slower port shrinks the margin fast.
5. Software residence. For each guided feature in use, note where it runs. Anything inside the robot-brand plug-in gets rebuilt on a new controller.
6. Port count and power. Count the Ethernet devices — gateway, camera, PLC — and pick a controller class with a spare port; decide PoE versus a separate supply at the wrist.
7. Trigger and calibration path. Decide what fires the snapshot and how the camera-to-robot transform will be rebuilt on the new arm; camera-to-robot calibration without vendor tools holds across brands because it needs only an image and the robot pose.

When the usual answer is wrong

Not every wrist device follows the plug-in pattern. Some cameras attach through the robot maker's own camera port and are then ordinary controller peripherals; their compatibility question is answered by that controller's option list, not by protocol. Some sensors skip Modbus and speak vendor TCP or ASCII frames — that still ports, provided the message format is published and the receiving side has a socket client, so check the format before assuming the stream will flow.

A fixed camera also beats a wrist camera outright in many cells. If one station inspects one known position, mounting the camera over the station removes the robot from the compatibility question entirely. Where several viewpoints are unavoidable, multiple snapshot positions from one wrist camera is the pattern to copy.

The bottom line

Keeping a force-torque sensor through a cobot change: plan on it working. Order a gateway if the new side lacks a serial Modbus master, budget the guided-routine rewrite, and check word order on the first live torque.

Keeping a wrist camera through a cobot change: plan on it not working unless the maker's list names the new controller generation. Either re-buy within the same family, or move the inspection to a smart camera with its own runtime and take the robot brand out of the camera question.

Specifying a new cell meant to survive an arm change: choose devices whose intelligence sits outside the controller — Modbus sensors, standalone smart cameras, a vision controller as the hub. Then the next swap is a calibration day, not a re-purchase. More integration patterns sit on the systems guides page, and if you want a chain checked before ordering, send the register map, the controller model and the camera list through the contact page or start in the system configurator.