Deep dive · Conveyors
Conveyors from different vendors behave differently, and many have decision nodes where the hardware scans a handling unit and asks the control system where next?. openWCS answers that from a vendor-neutral topology graph it owns — not a black box buried in the PLC.
How it works
The conveyor network is modelled as a graph of nodes (scanners, diverts, merges, segments) and directed edges. Each node carries its own hardware address, so the WCS knows exactly which device it is talking to.
Every decision point is a node with a hardware address; edges define where a unit can travel and at what cost. The whole layout is data, not firmware.
When a node scans a handling unit and reports its barcode + location, the WCS computes the shortest path to the unit's required target and replies with the next hop — live, per scan.
A unit can have several required targets in a particular sequence (e.g. scale → label → induct). The route plan walks them in order, recomputing after each.
Looping configurations have a maximum number of handling units allowed in the loop. Per-loop limits trigger HOLD or divert to an OVERFLOW target so the loop never jams.
Admins lay the conveyors out as they physically run — in a 2D top-down plan and a 3D layout editor — and drop named function points (scan, divert, merge) on them. openWCS infers the routing graph from that geometry; no hand-drawn connections.
Point the sniffer at defined source IPs and openWCS listens to scan telegrams, inferring nodes, edges and targets from real traffic to bootstrap or verify the topology.
Drop named function points onto a conveyor — scanners, diverts, merges, ASRS in/out ports — and openWCS turns the physical layout into the routing graph automatically, so the graph never drifts from the floor plan.
At a glance
conveyor node ──(scan: barcode @ node)──► openWCS flow-orchestrator
│ route plan: targets in sequence
│ shortest-path next-hop
│ loop check ─► HOLD / OVERFLOW
conveyor node ◄──────(next hop)───────────┘
│
└─ topology learned from sniffed scan traffic on allowed IPs
Self-learning
Most conveyor topologies are documented once, then drift as lanes are re-routed and devices are swapped. Instead of trusting a stale drawing, openWCS can learn the graph from the telegrams the hardware is already emitting — turning every scan into evidence about how the network is actually wired.
The discovery sniffer is pointed at a defined allow-list of source IPs — the PLCs and scan controllers you trust. It only ingests telegrams from those endpoints, so it never picks up unrelated network chatter.
Every PLC / scan controller on the allow-list is seeded as an endpoint in the graph. The address it reports from becomes a node's hardware address, so the learned topology already knows which physical device each node is.
Each distinct scan location that appears in the traffic becomes a candidate node. Repeated sightings confirm it; one-off noise stays low-confidence until it is seen again.
By tracking the same handling unit across consecutive scans, openWCS infers a directed edge between the two nodes — the physical path the unit just travelled — and builds up the graph from observed transitions.
Nodes where units consistently leave the network — induct points, drop lanes, ship doors — surface as candidate targets, so the destinations the routing layer needs are discovered too, not hand-listed.
The learned graph is a proposal an admin reviews in the same visual editor — accept it to bootstrap a greenfield site, or diff it against the live topology to catch drift on an existing one.
Open & vendor-neutral
The routing logic is open source and runs behind a uniform device contract, so adding a vendor means an adapter — not a rewrite.