Robot conveyor integration needs a clear answer to four questions: may the robot place a carton, who owns the transfer, how is completion confirmed and what happens if the sequence stops? A communications connection is only the transport for those decisions.
The worksheet below describes a generic normal-control handoff. Its signal names are illustrative. It is not executable control logic, a safety circuit or documentation of KRONA’s supported interfaces.
Define the receiving boundary
Identify the robot placement area and the conveyor section that receives the carton. Record transfer height, gaps, carton orientation and the point at which the conveyor takes responsibility for moving the box onwards.
A programmable logic controller, or PLC, can coordinate equipment states in an application. Agree which controller owns the receiving sequence, how the robot receives permissions and which system confirms carton arrival.
Use the handoff layout guide for physical fit. This checklist develops the sequence once that receiving boundary is defined.
Document a complete normal sequence
- Reserve the receiverThe robot requests a transfer and the receiver grants an agreed placement opportunity.
- Transfer the cartonThe robot completes the agreed placement while the receiver follows its defined sequence.
- Confirm and releaseBoth systems reconcile completion before clearing the transaction for the next carton.
Specify how a grant remains valid during transfer. A momentary “ready” observation before movement does not, by itself, reserve the destination. The agreed design must cover changes in receiver availability while a carton is already being handled.
Decide whether completion means the carton has been placed, detected by the receiver or moved beyond the handoff. These are different events. Define one transaction boundary and how duplicate or missing confirmations are reconciled.
Use a state and ownership table
| State or event | Normal-control question | Responsibility to agree |
|---|---|---|
| Waiting for receiver | Is a placement opportunity available for this carton? | Receiver reports availability; application defines waiting behaviour |
| Transfer granted | Is the opportunity reserved until the agreed completion? | Both systems track the same transaction |
| Carton placed | What sensing confirms placement and tool release? | Robot and receiver document their own evidence |
| Transfer complete | What clears the transaction for the next carton? | Sequence owner reconciles both systems’ states |
| Receiver full | How is new work withheld and an in-progress transfer handled? | Approved application design defines the response |
| Failed pick or release | Where is the carton and which state remains active? | Recovery owner establishes the actual physical condition |
| Timeout or lost communication | How are uncertain transactions reconciled? | Defined fault handling and authorised recovery procedure |
Keep ordinary process signals separate from protective and emergency functions. Normal PLC messages are not a substitute for the complete installation’s assessed safety design.
Specify the communications interface separately
Record the supported protocol, data layout, update behaviour, connection supervision and controller responsibilities. Define signal meanings, units, valid states and any transaction identifiers. Obtain the supplier’s actual documentation before implementing the exchange.
Universal Robots’ EtherNet/IP guide illustrates how one manufacturer documents a particular robot-PLC connection. That reference establishes neither KRONA compatibility nor a universal method for other controllers.
KRONA’s public product description does not specify a PROFINET, EtherNet/IP, PLC or warehouse-management interface. Treat each as a requirement to confirm for the client project.
Test faults as well as successful transfers
Agree application-level acceptance scenarios for a full receiver, failed pickup, incomplete release, blocked sensor and interrupted communications. Have the responsible team carry out these tests under the installation’s approved commissioning procedure.
For each event, record the observed carton position, robot/tool condition, receiving state, fault indication and recovery ownership. A reset alone should not be interpreted as evidence that the physical process has completed.
Include recovery time and remaining operator work in the pilot acceptance scorecard. A fast normal sequence can still create long operational delays when exceptions are poorly defined.
Keep receiving records separate from the local handshake
A completed transfer can establish that a carton has reached the receiver without establishing its inventory identity or acceptance. Assign stock posting, unreadable labels and quantity corrections to the receiving-system owner. The WMS receiving guide supplies a separate event and reconciliation worksheet for those decisions.
Send an interface brief with the client enquiry
Provide the conveyor layout, carton mix, available receiver capacity, controller details and proposed ownership table. Identify which interface requirements are confirmed and which need supplier review.
KRONA U1 can transfer eligible unloaded cartons to a conveyor or pallets. Discuss the client’s handoff so the physical receiver, interface scope and acceptance process can be reviewed together. Keep the EOAT confirmation requirements in the same project brief.
- system integration
- container unloading
- end of arm tooling
KRONA U1 unloads boxes from containers onto pallets or conveyors and also loads containers with boxes from pallets or conveyors. Explore KRONA U1 →
Discuss your receiving-line interfaces