Robot vision cell control architecture for palletizing

A palletizing cell fails in its controls more often than in the robot arm. When conveyor release, inspection routing, printing and recipe selection have no single owner, a healthy robot still palletizes the wrong carton or loses a rejected one. This guide gives you the division of labor that works, the handshake that carries it, the arithmetic behind the inspection deadline, and an offline test plan you can run before the robot is delivered. The worked example uses a 900 mm trigger-to-diverter run at 300 mm/s with product arriving at 5 items/s; put your own numbers into the same formulas. For camera-to-robot geometry and cell layout, start with the 3D palletizing integration guide.

Give every function one owner

Three controllers, three jobs, plus one that stands apart. The robot controller executes motion and gripper sequences. The PLC owns production sequencing: conveyor admission, reject routing, print release, pallet exchange and operator commands. The vision controller triggers, inspects and reports. A safety controller, on separate validated hardware, owns protective stops and access. Assign every output and every state transition to exactly one of them, and write the assignment into the specification before any program exists.

Keep the signal classes apart. A robot ready bit is production status, never permission for a person to enter the workspace. ISO 13849-1 requires every safety function to reach the Performance Level set by your risk assessment, from PL a to PL e, and an ordinary PLC program cannot carry that duty. ISO 10218 places the integrated cell's protective measures with the integrator, so safety belongs in the architecture from day one, not after commissioning.

Separate recipe data from sequence and motion

A palletizing project contains three deliverables with three owners. Recipe data names the product: identity, layer-pattern revision, permitted gripper configuration, destination. The motion application turns that data into approach paths, place sequences and search limits in the robot controller. The cell sequence - admission, inspection routing, printing, pallet exchange - stays in the PLC. A saved palletizing configuration is recipe data; loading it executes nothing on a conveyor or a printer.

For a line running five products, write five approved recipes over one cell sequence, not five programs. Recipe values stay revision-stamped and controlled; the sequence never changes per product. List the runtime options and licenses each deliverable needs in the specification, and take software, manuals and example projects from the manufacturer or its distributors only.

Write each interface as a transaction

One pass bit cannot run a cell with product in flight. At 5 items/s, fifteen cartons sit between the trigger and the diverter, and a bit carries no identity, no revision and no completion state. Move records:

Define the write order and the acknowledgment. A receiver acts only on complete records - use the protocol's atomic transfer or a sequence-controlled handshake - and define duplicate behavior in the contract. When a completion acknowledgment is lost and the sender repeats the command, the receiver returns the stored result; it never picks or prints a second time. The PLC communication guide works this discipline through Modbus registers: connectivity assigns no ownership.

Budget the inspection-to-diverter deadline

Start the clock at a physical event, the trigger sensor's rising edge, and stop it when the diverter must be in position. For a constant-speed belt:

Everything the cell does inside that window adds up:

Worked example, one infeed: d = 900 mm and v = 300 mm/s.

Two point five six seconds of slack is comfortable. Keep it that way by measuring the worst case with image logging on and every camera in the cell streaming; the average is a status figure, not an acceptance limit. At 5 items/s the 3.00 s window holds 5 x 3 = 15 products in flight, so size the tracking queue above that count: fifteen in flight, plus burst arrivals, plus retained fault records points to a 32-deep queue. Track position by encoder count, never by elapsed time - at 300 mm/s a 50 ms timing error already misroutes by 15 mm. The frame-to-result matching guide applies the same discipline inside the vision pipeline.

Hardware sized to the role

Parts follow from roles, not from connector counts. The three below map one-to-one onto the architecture above.

Vision controller

The inspection role needs a controller that triggers cameras, drives lights, runs the check and reports to the PLC. The MV-VC2140-128G40-1T fills that role: an Intel N-series (N97) processor, 8 GB of memory, a 128 GB SSD with a 1 TB HDD for image archiving, 3-4 LAN ports to separate camera and plant networks, 2 USB 3 ports, and 4 built-in light channels that drive illumination without a separate lighting controller.

When the cell grows past one infeed, higher series in the vision controllers range add PoE camera ports and 8-channel light control; the controller selection guide walks that trade-off. Throughput comes from measured cycle times on your images, never from port counts.

Camera

The camera's job on a moving belt is a sharp, triggered frame. Global shutter removes the row-by-row skew a rolling shutter adds at 300 mm/s, and exposure still has to stop motion: at that speed a 0.1 ms exposure smears 0.03 mm, so budget the strobe as well as the shutter. The MV-CU020-90GC pairs a global shutter with a GigE Vision interface for exactly this job.

GigE Vision standardizes discovery, streaming and control over Ethernet, so camera and controller interoperate whatever the mix of makers; the standard governs the link, and cell ownership stays with the transaction design above. Widen the search in area scan cameras or the camera finder, then close it with a trial on your real defects under your lighting.

Cabling

A camera mounted on a moving gantry needs flex-rated cable with locked connectors. The LS-CBL-0199 is a high-flex GigE camera cable with screw locks built for that route.

Match connector gender and pinout to the camera before ordering, and keep trigger lines out of the data bundle. Route the rest through data and I/O cables in the accessories finder.

Operator states and pallet exchange

Run the cell on a short, explicit state list: stopped, preparing, ready, running, stopping, faulted. The PLC owns every transition; the HMI only requests. A start press is a request carrying a command identifier - pressing it twice creates one transaction, not two.

A recipe changeover is a sequence, not a register write:

1. Request a production stop and close product admission.
2. Complete or explicitly disposition every tracked product.
3. Bring the robot to a defined state and resolve the half-built pallet.
4. Check recipe and revision across every participating device.
5. Acknowledge the active recipe before accepting the next start request.

Step 5 is where trigger races live: a trigger that fires before the recipe acknowledgment is confirmed captures images under the old revision. The PLC trigger race guide shows the interlock that prevents it.

Track alternating pallet stations as independent machines with five states each: unavailable, empty confirmed, filling, complete, awaiting exchange. A completed pallet says nothing about its neighbor; admit product only against a station in the filling state. Where an operator swaps pallets within reach of the robot, access is a safety question with its own validation, not a software interlock. A stack-height sensor is a process input with declared search limits and fault behavior - never a personnel-protection device.

Test the interfaces offline, before the robot arrives

1. Freeze the responsibility diagram: every output, transition and reset has one named owner.
2. Write the interface contract: records, valid transitions, acknowledgment timing, restart behavior.
3. Build simulators for camera, printer, conveyor sensors and robot, each answering the real protocol.
4. Run every recipe end to end: pick, print, pallet completion, destination changeover.
5. Inject faults: delay, duplicate, reorder and drop messages within the contract's rules.
6. Check motion in the robot maker's simulation environment: paths, reach, sequence.
7. Package the deliverables: software versions, options and licenses, recipe revisions, deployment steps.

Then make the count matter. Run 1,000 simulated product transactions with faults injected and count missing identities, duplicate actions, wrong destinations and unresolved records; the acceptance number for all four is zero. Portability is part of the test: export the project package, reopen it on a second machine by the manual's import procedure, and make every referenced path resolve. Real camera latency, gripper behavior, stopping distance and safety-function performance are measured on the installed cell under controlled commissioning conditions.

Prove failure behavior, not only the happy path

Log every event with session identity, product identity, recipe revision, command state and timestamps from one time master. Unsynchronized clocks misattribute misses: a 200 ms offset between PLC and vision logs is enough to blame the wrong device. Accept the cell against recorded limits - every inspection answered inside its budget, every queue drained, zero unresolved records - and file the numbers, not an operator's impression.

When to skip the separate PLC

Skip it when the cell is genuinely compact: one conveyor, one camera, one printer, a short sequence, and maintainers who will own one combined program. Robot-controller background logic then runs the peripherals, provided measured peripheral response holds under full motion load - test that with the robot at 100% speed, not idle.

Add the PLC when conveyors and printing must keep running while the robot is taught, when a second machine shares production states, or when maintenance splits between a controls team and a motion team. Both arrangements answer to the same safety design: ISO 13849-1 grades the function, not the box, and neither architecture exempts the cell from validation.

Specify it, then order

• Every output and production transition has exactly one named owner.
• Product identity survives inspection, rejection, printing and picking.
• Recipe changes carry acknowledgment and work-in-progress rules.
• Timing budgets hold measured worst cases plus actuator response.
• Restart reconciles outstanding products and commands against the cell.
• Pallet availability and operator access are separate questions with separate answers.
• Runtime options, licenses and deployment files are listed before purchase.
• Camera, controller and cable compatibility is checked per model, not per port count.

Send the package - responsibility diagram, belt speed, product spacing, defect list and interface record layout - through application support, and the reply returns a matched camera, controller, light and cable list with the timing budget recomputed against your distances. More systems-level guidance sits on the systems topic page.