AMR Material Handoffs: PLC Logic That Proves the Load Has Moved
The completion bit is high. Has the pallet actually left?
Consider an illustrative commissioning incident. A mobile robot docks at a conveyor, its rollers start, and the station reports completion. The fleet controller prepares the next movement. However, the receiving photoeye has detected only the leading edge of the pallet. The trailing runners still rest on the robot.
Every message arrived. The conveyor ran. The destination sensor changed state. Yet departure would separate two machines while one load still bridges them. The defect sits in the meaning of “complete”: the application accepted evidence of arrival as evidence of full transfer.
A dependable AMR PLC handshake authorizes each action from current evidence, verifies the resulting material position, and releases the equipment only when its departure conditions are satisfied. An autonomous mobile robot, or AMR, and a programmable logic controller, or PLC, must agree on more than a start command and a done bit.
For a transfer to be physically complete, the intended load must reach its defined destination condition, leave the source as required, and clear the shared transfer interface. The application must also preserve a trustworthy outcome for the current cycle. Physical completion, permission to depart, and acceptance of the business transaction are separate decisions.
This article develops a proposed station control pattern around those decisions. Its state names, signal examples, and test matrices are engineering design aids, not a prescribed vendor protocol. The opening incident is hypothetical; it is not a reported customer failure.
Define the handoff around load custody
Start with a specific transport action: one identified pallet moving from one robot deck to one receiving conveyor zone. Specify which equipment supports the pallet before, during, and after movement. Then identify who can authorize motion and who can confirm the final condition.
That makes an AMR material handoff a controlled change in load custody. Custody here means responsibility for supporting, retaining, locating, and accounting for the material. It does not imply that a database transaction and a mechanical movement happen atomically.
The receiving PLC should not infer that the robot is empty solely because its own photoeye is occupied. The robot should not infer that the pallet is secure solely because its deck sensor has cleared. Each observation answers a narrower question. Completion requires an application-specific combination of observations and a plausible transition history.
Before programming, agree on the following conditions:
- The permitted load type, direction, orientation, and source and destination identities.
- The receiving position and support condition that constitute successful delivery.
- The geometry that must be clear before either machine can separate.
- The controller responsible for authorizing the transfer and evaluating its outcome.
- The response when evidence is missing, contradictory, or no longer current.
An AMR transfer station should have an explicit capacity model. A single receiving position normally needs one exclusive owner during the active handoff. A station with multiple independently controlled zones can support more than one reservation, provided that the shared mechanical interface remains protected against conflicting use.
Make every state earn its next transition
The following sequence describes an outbound transfer from robot to station. Reverse transfer requires its own source and destination conditions. A station coordinator, implemented in an agreed local controller, evaluates the combined evidence while each equipment controller retains responsibility for its own actuators.
| State | Required evidence | Meaning for upstream systems |
|---|---|---|
| Available | The interface is enabled, its physical occupancy is known, and no incompatible reservation exists. | The station can consider a request; no movement has been authorized. |
| Reserved | The station accepts a specific robot, load, direction, and transfer cycle. | Capacity is allocated to that cycle. |
| Arrived | The expected robot reaches the approach or docking location. | Travel has progressed; material transfer remains pending. |
| Dock confirmed | Transfer alignment, standstill, required engagement, and matching station identity are established. | The physical interface is connected or positioned for the next checks. |
| Transfer permitted | Source load, destination capacity, relevant process conditions, and required safety permissions are valid. | This cycle may begin its defined handling action. |
| Transferring | The action has started and its observed progress matches the permitted sequence. | The load may occupy the shared interface; separation is inhibited. |
| Physically verified | Destination support and position, source clearance, and interface clearance meet the completion definition. | The material movement is complete, subject to outcome recording. |
| Outcome recorded | The current cycle result is retained and available for acknowledged delivery upstream. | The confirmed physical result can be reconciled without repeating motion. |
| Released | Departure conditions are verified; the robot clears the shared interface and occupancy is updated. | The reservation can close and the station can reassess availability. |
| Held or unknown | A required condition fails or the physical state cannot be established. | Normal progression is blocked pending defined recovery. |
Business acknowledgement may follow physical release when the approved architecture retains the outcome durably and permits that ordering. Other applications require acknowledgement before release. Make this a deliberate policy. Waiting for an enterprise response is not inherently necessary for mechanical clearance, and an enterprise response does not establish mechanical clearance.
Reservation expiry cannot erase physical occupancy
A reservation that expires before docking may be cancelled after checking that approach authority has been withdrawn. Once a load enters the interface, a timer must not make that space available to another robot. The coordinator must preserve the occupied or uncertain condition until the equipment state is resolved.
Reset must lead through reconciliation
A fault reset acknowledges a fault condition; it does not prove that a pallet moved. Following a controller restart, the station should reconstruct its condition from retained cycle information and fresh equipment observations. Initializing all bits to zero must not be interpreted as evidence of an empty station.
Mechanical alignment remains a prerequisite. The separate guide to AMR precision docking and autonomous charging examines that subject. Here, the additional requirement is to prove what happened to the material after alignment was achieved.
Give each PLC signal an owner and a lifetime
A useful robot conveyor handshake is a shared definition of behavior, not simply a list of Boolean tags. For every field, document the writer, consumers, update behavior, validity conditions, acknowledgement rule, and response to loss of communication.
The following signal dictionary is illustrative. Actual implementations may use discrete I/O, a fieldbus data structure, controller messages, or a dedicated station interface.
| Field or signal | Authoritative writer | Meaning and validity |
|---|---|---|
| Cycle reference and session generation | Designated cycle coordinator | Identifies this transfer and distinguishes it from cycles accepted before a controller restart. |
| Reservation accepted | Station coordinator | Accepts the specified robot, direction, and load for the specified station position. |
| Dock confirmed | Defined docking subsystem | Reports verified engagement or alignment; becomes invalid if the required conditions are lost. |
| Source occupied / destination available | Respective equipment controllers | Reports validated process observations for the selected transfer positions. |
| Transfer permit / action active | Coordinator / executing controllers | Separates permission to start from evidence that the requested action is executing. |
| Physical result and result sequence | Designated result evaluator | Identifies the verified outcome for this cycle; remains available until acknowledged. |
| Departure permitted | Defined interface coordinator | Confirms the configured separation conditions; does not substitute for the robot's movement permissions. |
| Fault, state quality, and channel health | Each relevant controller | Allows consumers to distinguish valid process data from unavailable or uncertain observations. |
Keep the request coherent
A request containing a new destination and an old transfer direction is not a valid request. Publish related fields as one coherent application snapshot, using mechanisms appropriate to the controller platform. Copying live fields individually across several scans can otherwise create a combination that no sender intended.
Rockwell Automation's controller handshaking application note specifically addresses buffered data exchange to avoid mixing old and new data. Applying that principle to station requests is an engineering design choice; the note is not a complete robot transfer specification.
Make completion survive a missed message
Do not expose completion only as a pulse shorter than the consumer's possible observation interval. Retain a cycle-specific result until it is acknowledged. A repeated request for the same accepted cycle should return its current status or retained result, rather than start another mechanical transfer.
For a discrete implementation, define the request, acknowledgement, request-clear, and acknowledgement-clear sequence explicitly. Also define startup synchronization and stuck-signal detection. A four-phase sequence alone cannot distinguish every retained-bit or restart failure without additional state checks.
Separate data quality from an unchanged value
OPC UA's DataValue definition includes status information and source and server timestamps. These provide useful context when that interface is used. However, an unchanged value can legitimately retain an older source timestamp. Channel health and freshness must be evaluated against the configured update behavior, not by assuming every old timestamp means a failed sensor.
Prove clearance as well as presence
Reliable AMR load detection begins with a drawing of what each sensor can and cannot observe. Mark the beam positions, pallet runners, openings, overhang, receiving stop, and gap between conveyors. Check the complete family of authorized loads rather than one convenient commissioning pallet.
Before movement: establish a credible starting condition
Confirm the expected source occupancy and destination capacity. Where load identity matters, connect the observed identity to the current cycle. A readable label proves identification, not full mechanical support. Conversely, a presence sensor proves neither identity nor suitability for the receiving fixture.
Validate relevant alignment and height conditions under the actual payload. A deck that lines up when empty may behave differently under load. Software should consume the defined docking result, while commissioning establishes whether that result represents the required mechanical condition.
During movement: evaluate the sequence
Both source and destination sensors may be active while a long pallet crosses the gap. Both may briefly be inactive when the load passes through a sensing blind zone. Neither combination has a universal meaning. Interpret it using sensor placement, direction, the previous state, and the permitted progress window.
Likewise, motor operation is evidence of an actuator command or response, not proof of load movement. Slippage, a blocked runner, or a detached coupling can separate those facts. The diagnostic design should distinguish lack of physical progress from lack of communication.
After movement: establish support and separation
Completion checks should establish that the load occupies the intended receiving position, has cleared the source as required, and no longer bridges the equipment. Couplers, bridges, lift elements, or retaining devices must also reach their required departure conditions.
Appropriate AMR transfer interlocks enforce these dependencies. Their exact sensing architecture depends on the handling mechanism and risk assessment. Adding several copies of the same poorly positioned sensor does not necessarily eliminate the underlying blind spot.
Resolve interrupted transfers from physical evidence
An AMR transfer timeout means that a defined expectation was not met within its allowed interval. It does not tell the controller whether the load remained at the source, reached the destination, or stopped between them.
Use separate monitoring windows for reservation response, docking confirmation, motion progress, completion verification, and result acknowledgement. Derive each from the equipment behavior, communication design, and validated operating envelope. Extending one global timer can conceal the fault while lengthening the time spent in an uncertain state.
| Observed physical condition | Robot or PLC state | Business state | Required decision |
|---|---|---|---|
| Load remains fully at the source | Transfer never started | Pending | Revalidate conditions; a bounded retry may be permitted if no physical action occurred. |
| Load spans robot and station | Timeout, fault, or connection lost | Pending or unknown | Maintain the defined containment condition and block separation; use the approved partial-transfer recovery. |
| Load remains on the robot | Complete reported | Complete or awaiting posting | Treat as false completion; inhibit normal release and investigate the evidence that asserted success. |
| Load is verified at the destination | Physical result retained | Pending because acknowledgement was lost | Recover or resend the result for the same cycle; do not repeat the transfer. |
| Receiving zone contains an unexpected load | Reservation appears valid | Expected load elsewhere | Block the handoff and reconcile identity and occupancy before granting a new permit. |
| Position or support cannot be established | States conflict after restart | Any state | Hold the affected interface; require fresh evidence and authorized recovery before resuming. |
Define what may retry automatically
A communication retry and a mechanical retry are different operations. Reading status again or resending a retained result can be appropriate without moving anything. Reversing rollers, repeating a lift, or pulling a robot away changes the physical situation and requires its own validated conditions.
Automatic physical recovery should be restricted to explicitly supported situations with known load position, valid permissions, bounded attempts, and observable success criteria. An unknown or partially supported load should not trigger a generic “retry three times” rule.
If manual intervention is required, record the recovered load location, current equipment condition, authorizing role, and disposition of the interrupted cycle. The operator interface should display why progression is blocked and what evidence is needed, rather than offering an unexplained force-complete button.
Broader service restoration is covered in the site's mobile robot failure recovery framework. At the station boundary, the immediate objective is narrower: restore a trustworthy physical state before allowing another handoff.
Adapt the handshake to the receiving equipment
AMR conveyor integration cannot be specified entirely through network compatibility. Deck height, load support, pallet retention, and transfer geometry determine which control states can be proved. Industrial Kinetics lists local controls, presence and position sensing, alignment features, and retention options among its AMR interface conveyor capabilities. These are interacting parts of the interface.
| Endpoint | Evidence that matters | Common design mistake |
|---|---|---|
| Powered conveyor | Compatible direction and motion, destination capacity, final load position, and clearance across the gap. | Treating the first receiving photoeye transition as full delivery. |
| Lift or lifting platform | Correct elevation, alignment, support condition, and required retention or mechanical engagement. | Treating a lift-position switch as proof that the load is properly supported. |
| Rack or passive stand | Correct location, fixture availability, seating or support, and withdrawal clearance. | Using arrival coordinates as the sole evidence of successful placement. |
| Automatic door | Access permission, verified opening, protected passage, and confirmed clearance before closure. | Treating a door-open command as proof of a usable opening. |
| Elevator | Correct landing, access state, occupancy, robot entry or exit confirmation, and travel coordination. | Releasing a landing or cabin from an estimated travel time alone. |
A door normally controls access, and an elevator normally transports the loaded robot between levels. Neither necessarily transfers custody of the payload. Their handshakes belong in the journey, but should not manufacture a material-delivered event unless a separate, verified handoff actually occurs.
The same custody and clearance questions apply to AGV conveyor transfer. Following a fixed route does not establish that a pallet has crossed an equipment boundary. Vehicle navigation architecture and station transfer evidence solve different parts of the application.
The communication medium also varies. MiR describes infrared communication between Interroll's conveyor top module and its docking station. This illustrates a local interface option. It does not remove the need to define signal meaning, fault behavior, or the safety architecture of the complete installation.
Keep process permission and safety permission distinct
A normal PLC tag named Ready, Clear, or Safe is not automatically a safety-rated function. Process sequencing decides whether an operation is logically appropriate. Safety-related controls must achieve the risk reduction required for the actual machinery and application.
ISO 3691-4:2023 addresses safety requirements and verification for driverless industrial trucks and their systems, including AMRs and AGVs. Its scope should not be interpreted as prescribing the illustrative tag names or state table in this article.
The application design must address hazards at the combined interface, including crushing, trapping, unexpected conveyor motion, loss of load support, and access during recovery. Assign responsibility for evaluating the robot, top module, station, and their interaction. Component-level approvals alone do not describe every combined operating condition.
The response to interruption must match that design. Abruptly removing all power, immediately reversing a conveyor, or releasing a retaining device is not a universal safe response. Required stopping, support, retention, isolation, and restart behavior must be established and validated for the equipment involved.
Commission the failure paths, then measure the service
AMR station commissioning should connect the functional specification to observable behavior at the installed interface. Name an owner for the combined transfer sequence, with contributions from the robot, top-module, station-control, safety, and operations teams. Otherwise, each supplier can demonstrate a correct subsystem while the handoff remains unproven.
Challenge the transitions that can mislead the controller
Run controlled tests against the released configuration and authorized load range. Fault injection involving moving equipment needs an approved method and appropriate protective measures. The objective is to expose incorrect assumptions without creating an uncontrolled physical event.
- Occupied destination: request a transfer when the receiving position is already occupied. Verify that a reservation or old ready signal cannot authorize conflicting movement.
- Early detection: use an authorized load whose leading edge reaches the destination sensor before its trailing edge clears the robot. Verify that completion remains withheld.
- Interrupted progress: introduce an approved simulated fault during transfer. Verify the defined response, retained occupancy, and controlled recovery route.
- Lost result acknowledgement: interrupt the reporting path after verified delivery. Verify that reconciliation closes the same cycle without another mechanical transfer.
- Controller restart: restart through the approved test procedure at selected states. Verify that retained commands or default values cannot falsely reopen the interface.
- Load and direction variation: test representative pallet geometry, payload, transfer direction, and station combinations within the authorized envelope.
For every case, preserve the cycle reference, software and parameter versions, relevant signal trace, physical observations, expected response, actual response, and defect disposition. Where traces come from different controllers, establish timestamp alignment or another reliable method of reconstructing event order.
The existing AMR site acceptance evidence matrix provides the wider release framework. The station-specific addition is a demonstrable chain from each completion or departure decision to its physical evidence.
Use metrics whose denominators reveal failures
| Measure | Definition | Required interpretation |
|---|---|---|
| First-pass transfer success | Eligible cycles reaching verified completion without a retry or manual intervention, divided by all eligible initiated cycles. | Define eligibility and cancellations before testing; retain failed and unfinished cycles in the accounting. |
| False-completion rate | Completion assertions contradicted by independent physical verification, divided by all completion assertions evaluated. | Record detection coverage and operating conditions; zero observed events does not establish zero risk. |
| P95 handoff time | The 95th percentile of elapsed time from accepted docking confirmation to departure permission for completed cycles. | Report failed and unfinished cycles separately, plus station type, load mix, and sample count. |
| Recovery performance | Time from detected interruption to a reconciled, authorized operating condition, grouped by fault type. | Distinguish data-only reconciliation from recovery requiring physical intervention. |
For an illustrative calculation, suppose 200 eligible cycles are initiated. Of these, 190 complete on the first attempt, six complete after an automatic retry, and four need manual recovery. First-pass success is 190 divided by 200, or 95%. Reporting 196 successful automatic outcomes as “first-pass success” would conceal the retries.
Those numbers explain the metric; they are not a recommended acceptance threshold or plant benchmark. Set thresholds from the required service, load variability, consequences of failure, and agreed test coverage. Report time spent waiting for a station separately from the handoff interval so that a fast transfer cannot hide a long approach queue.
Control changes after acceptance
A moved photoeye, new pallet type, altered roller speed, replacement top module, or revised timeout can invalidate earlier evidence. Link such changes to affected test cases. Retesting only the nominal sequence is insufficient when the change alters a completion boundary or recovery assumption.
Focused FAQ
What should an AMR PLC handshake prove?
An AMR PLC handshake should establish that the correct equipment is participating in the current cycle, prerequisites permit movement, the material reaches its defined destination condition, and the interface can be released. A request acknowledgement proves receipt or acceptance, depending on its definition; it does not prove physical delivery.
Can a destination photoeye confirm transfer completion?
Only when its validated sensing arrangement and the other required evidence establish the complete delivery condition. A leading edge reaching one beam may leave much of the pallet on the source. Consider source clearance, receiving position, support, interface geometry, and the observed sequence together.
What happens if communication fails halfway through a transfer?
The equipment follows its defined interruption response while preserving the occupied or uncertain interface state. Recovery then establishes load position and equipment condition before authorizing movement. A timeout alone cannot justify departure, a new reservation, or an automatic mechanical retry.
Must the robot wait for the WMS before leaving?
Not in every architecture. Departure can be permitted after verified physical clearance and durable outcome recording if the approved process allows asynchronous business acknowledgement. Applications with stricter transaction requirements may hold the robot. The required ordering must be specified rather than inferred from a generic completion bit.
Can conveyors, lifts, and racks share the same handshake?
They can share common concepts such as reservation, permission, verified outcome, and release. Their physical predicates differ. Conveyor clearance, lift support, and rack seating require different evidence and recovery actions, so a common interface still needs equipment-specific validation.
What is the most revealing acceptance question?
Ask the supplier to demonstrate what prevents departure when software reports success but the required physical clearance is absent. Then ask what prevents a second movement when the first delivery is physically complete but its acknowledgement is missing. Together, those cases test both false completion and unnecessary repeat handling.
#AMRPLCHandshake #AMRConveyorIntegration #MaterialHandoff #PLCProgramming #LoadDetection #TransferInterlocks #StationCommissioning #IndustrialAutomation
