Coordinate a cell

A one-scan pulse that works inside one task is a poor default contract between independently scheduled machines. The receiver may never observe it. Persistent request and acknowledgement states make the exchange visible, but they do not remove every failure. A reconnect can expose old values. A reset can erase remembered ownership. Before reusing the interface, write what identifies a transaction and how both parties reconcile a part after interruption.

The space between two machines needs an owner

A conveyor feeds a robot station. The conveyor programmer says, “I send when the robot is ready.” The robot programmer says, “I become ready when a part arrives.” Both programs are reasonable in isolation. Together they wait forever.

Cell coordination begins with a shared sequence, not with a collection of Boolean signals. Draw the physical transfer region and decide who owns it at each stage. Identify what proves a part is present, what proves it has left, and what happens if the evidence disagrees.

Ordinary production handshakes coordinate work. They do not replace the separately designed safety interfaces between machines. A robot's production-ready bit is not a protective permission to enter its workspace.

Design a conversation that can survive delay

For a one-part transfer, use this illustrative conversation:

The reservation matters. A receiver that says ready for one scan, then gives its space to another source, has broken the agreement. Readiness is an invitation; acceptance creates an obligation for a particular transfer.

Each side owns its outgoing fields. The sender writes the offer; the receiver writes acceptance and receipt. Neither side resets the other's variables over the network. That rule makes disconnected and delayed communication much easier to reason about.

Put identity beside the Boolean

With only Done = TRUE, a sender cannot tell whether it refers to today's part or the previous transfer. Add an identifier and define its lifecycle. An acknowledgement is useful only when its identifier matches the active offer and the communication data is fresh.

This ST excerpt illustrates the sender's acceptance condition. It assumes a coherent received snapshot and a documented session and identifier policy. It is not a complete transfer program.

OfferAccepted := PeerHealthy
    AND ReceiverAccepted
    AND (ReceiverTransferId = ActiveTransferId)
    AND (ReceiverSessionId = ExpectedReceiverSessionId);

TransferConfirmed := PeerHealthy
    AND ReceiverReceived
    AND (ReceiverTransferId = ActiveTransferId)
    AND (ReceiverSessionId = ExpectedReceiverSessionId)
    AND NOT SenderPartPresent;

Both expressions reject results from an unexpected receiver session. More fundamentally, choose departure and arrival evidence that actually support the physical transfer. A sensor can be blocked by debris, and one part can bridge two sensors. The agreement needs a fault path for contradictory observations.

Sequence identifiers eventually wrap, and controllers restart. A session identity or explicit resynchronisation prevents an old result from matching a new operation by accident. Do not depend on a counter being “large enough forever” without calculating its lifetime and documenting restart behaviour.

Timeouts detect uncertainty

The sender starts a belt after acceptance. The receiver's arrival sensor becomes true, but the network fails before confirmation reaches the sender. A timeout now means “the transfer result is unknown.” It does not prove the part stayed upstream.

A blind retry may send a second part into an occupied station. Enter recovery, preserve the active transfer identity and show the observed sensor states. After communication returns, reconcile the receiver's stored result and the physical evidence before issuing another transfer.

Some operations are naturally repeatable without additional physical effect; moving a data field to the same value may be harmless. Moving another carton is not. Design duplicate handling around the action, not merely the packet.

The communication chapter explains freshness and duplicate commands. Here those abstract ideas meet a physical object that cannot be rolled back like a text edit.

Prevent resource deadlock deliberately

Two stations share a robot and a test fixture. Station A reserves the robot and waits for the fixture. Station B reserves the fixture and waits for the robot. Every resource is owned, every station is waiting, and no timer setting can make both agreements true.

One solution is a fixed acquisition order: every operation requests the fixture before the robot. Another is a coordinator that grants the required resource set together. A third releases partial reservations and retries under a fairness policy. Choose a model appropriate to the equipment; do not allow each station to invent its own order.

Also consider starvation. A high-rate station can continuously win the robot while a slower station waits indefinitely. A fair queue, age-based policy or production priority with a maximum wait can make that behaviour explicit. Measure waiting time separately from processing time so the bottleneck remains visible.

Calculate capacity before blaming the code

Suppose a robot needs six seconds to load a fixture and six seconds to unload it. The fixture tests for eighteen seconds after loading. If the robot can work elsewhere during testing, its occupancy per part is twelve seconds, while the fixture's simple load-test-unload cycle is thirty seconds.

A single fixture therefore limits ideal output to two parts per minute before other delays. Making the robot program 10% faster cannot turn that fixture into a ten-part-per-minute station. Multiple fixtures may allow overlap, but the shared robot's total service demand then becomes another constraint.

Use a timeline showing resource ownership. Place loading, testing, unloading and travel intervals on it. This exposes where overlap is physically possible and where it would require two machines to occupy the same space. Optimisation starts with that model, not with removing every wait instruction.

Try it

Two infeed conveyors share one receiving position. Both see ReceiverReady = TRUE and begin moving in the same scan. Propose a handshake that prevents the collision without relying on one conveyor being slightly faster.

Work through the answer

Give the receiving position a single reservation owner. Each conveyor submits an offer with its identity and transfer ID. The receiver or cell coordinator selects one offer according to an explicit arbitration rule and publishes acceptance addressed only to that source and transfer. Only the accepted sender may begin the ordinary transfer sequence.

Hold that reservation until completion or controlled recovery, not merely until the ready sensor changes. The unaccepted sender continues waiting and can display its reason. Test simultaneous offers, disappearance of the winning sender, receiver restart and a part arriving without an accepted offer. Each test checks the agreement at its weakest boundary.

For broader equipment and procedure organisation, ISA88's scope provides useful terminology. This particular handshake is an original teaching design; using the terminology does not make it a certified implementation of any standard.