Message retry design is a quiet but critical layer in parcel hub control systems. In a courier sorting hub, the Warehouse Control System (WCS) and programmable logic controllers (PLCs) exchange thousands of mission-critical messages per hour: induction commands, divert instructions, seal requests, and status confirmations. Networks lose packets, PLC scan cycles lag, switch buffers overflow, and a message that should take eight milliseconds can occasionally take eight seconds. Retry logic exists to absorb these transient uncertainties without stalling the sortation process. However, retries also create their own failure modes. An unacknowledged message may have actually been executed; a repeated command may cause a double divert; a persistent retry loop may mask a configuration error rather than a network hiccup. This article explains the operating principles of message retry design in courier hub controls, defines the boundaries between WCS responsibility and PLC responsibility, and provides practical guidance for controls teams, maintenance engineers, and sortation operators who must interpret retry behaviour under live production pressure.
Operating Context of Message Retry #
Parcel hubs are high-rate, distributed systems. Induction lines feed parcels onto cross-belt sorters, tilt-tray loops, or sliding-shoe diverters at rates that can exceed two parcels per second per induction point. Communication between the WCS and a PLC is often carried over industrial Ethernet networks with managed switches, but also over serial lines, fieldbus segments, or remote I/O racks depending on the site and OEM architecture. Every segment introduces latency, buffering, and the possibility of loss.
Two message families dominate hub communications:
- Command messages: actions the WCS asks the PLC to perform, such as releasing a parcel from an induction station, diverting a parcel to a destination chute, or closing a merge gate.
- Status messages: observations the PLC reports back, such as a photocell detecting a parcel, a scale providing a weight, or a divert actuator confirming its position.
Retry design applies mainly to command messages. Status messages are event-driven and generally are not retried; if the WCS misses a status event, it must recover by querying current state. Command retries, in contrast, are engineered because a lost command has direct physical and financial consequences: a parcel goes to the wrong destination, a bin is skipped, or an induction release never happens.
Industrial networks cannot guarantee exactly-once delivery in the same way a database transaction can. A network may deliver a message zero times, one time, or several times. Retry logic converts an unreliable channel into an at-least-once semantic: the sender will keep trying until it receives confirmation. The counterpart of at-least-once is idempotency: the receiver must be able to process the same logical command more than once without causing a double physical action. This pairing, at-least-once delivery plus idempotent execution, is the foundation of message retry design in parcel hubs.
The Basic Retry Loop #
A typical retry loop works as follows. The WCS builds a command message, assigns it a unique message identity, and sends it to the PLC. At the same time, the WCS starts a timeout timer. The PLC receives the message, validates it, and responds with an acknowledgement (ACK) or a negative acknowledgement (NACK). If the WCS receives an ACK before the timer expires, the message is considered delivered and the retry loop closes. If the timer expires first, the WCS sends the same message again after a short delay.
The delay is rarely a fixed constant. Most systems use a backoff schedule: a first retry after 200 milliseconds, a second after 500 milliseconds, a third after 1.5 seconds, possibly with random jitter to prevent multiple WCS threads from retrying in lockstep. The number of retries is bounded by a retry budget, typically three to five attempts for a fast-moving parcel mission. Exceeding the budget moves the mission into an exception state, which is an alert to operators rather than a silent infinite loop.
Critical distinction: an ACK means message received and syntactically accepted, not necessarily action executed. A well-designed PLC sends a separate status message when the physical action completes. Confusing the two is one of the most common sources of misplaced retries, as covered later in the interpretation errors section.
NACKs require a different treatment. A NACK usually indicates a rejection based on application-level validation: the parcel ID is unknown, the destination cell does not exist, or the requested bin is in a fault state. Retrying a NACK is almost always wrong. The retry loop should terminate immediately and the WCS should reassign or escalate the mission, because the message will never succeed no matter how many times it is repeated.
Hub Boundaries and Responsibility Handoff #
Every retry design implies a boundary between who plans and who executes. In a typical courier hub, the WCS is the mission planner. It knows the destination of a parcel, the path through the sortation system, the expected timing at diverts, and the final dispatch lane. The PLC is the executing coordinator at the physical layer. It tracks parcel presence on photoeyes, controls divert actuators, monitors motor drives, and enforces interlock conditions with adjacent equipment.
When the WCS sends an induction release command, responsibility passes from the WCS to the PLC at the moment the ACK is received by the WCS. After that moment, the PLC is the authoritative source of physical truth. If the PLC receives a release command but the induction belt is blocked by a preceding parcel, the PLC should hold the release until the interlock clears, and it should report the final outcome to the WCS. The WCS should not assume that a missing ACK means the release has not happened.
The reverse boundary applies to status reporting. Once the PLC detects a parcel at a specific cell, the WCS updates its mission state, and from that moment the WCS owns the next routing decision. A failure to receive status does not justify resending a command that has already been executed; it justifies a state query, such as asking the PLC for the current position of the parcel or for the status of the divert actuator. This distinction prevents the classic failure where a lost ACK causes a duplicate divert command and a parcel is pushed into the wrong chute a second time.
Retry State Model and Duplicate Risks #
Good retry design is a state machine. The WCS and PLC should each maintain explicit lifecycle states for every command message. A representative WCS-side model looks like this:
- In Preparation: the WCS is building the command and validating destination data.
- In Flight: the message has been handed to the transport layer but no ACK has arrived.
- Acknowledged Pending Execution: the PLC accepted the command; the WCS waits for the execution-status message.
- Executed: the PLC reported the action completed; the mission advances to the next step.
- Rejected: the PLC returned a NACK for application-level reasons; retries stop.
- Timed Out: the retry budget was exhausted without ACK; the mission is flagged for operator review.
Duplicate risk lives in the transition between In Flight and Acknowledged. If the ACK is lost, the WCS retries, and the PLC receives the same command a second time. The PLC must recognise the duplicate. The standard technique is an idempotency key embedded in the message, typically the parcel ID or a mission sequence number issued by the WCS. The PLC stores the last processed key for each command source and silently re-acknowledges a duplicate without performing the physical action a second time.
This idempotency store must survive PLC restarts or be reconstructed carefully. If the PLC loses its record of processed keys, a retry after restart can trigger a second physical action. Some architectures clear the processed-key list only when the WCS confirms it has received the execution status, which is safe because at that point the retry loop is closed. Others persist the last keys to a non-volatile memory area, accepting a small window of uncertainty around power loss.
Observable Symptoms in Daily Hub Operations #
Retry failures rarely announce themselves as “retry failures.” They appear as operational symptoms that maintenance and controls teams must learn to recognise:
- Duplicate induction: a parcel is detected twice at the same induction point, or the same parcel ID appears twice in the WCS tracking table, causing the WCS to count two parcels when only one physically exists.
- Double divert or overshoot: a parcel is pushed toward a destination chute, then a retried command pushes a following parcel or the same parcel again, leaving an unexpected parcel in a dead zone between sortation cells.
- Ghost exceptions: the WCS shows “no ACK for mission 3456” while the PLC log shows the command executed successfully; the discrepancy is later reconciled manually.
- Conveyor stalls at merging sections: a merge gate does not receive its release command, the WCS retries, but the retry timeout window is longer than the inter-arrival time of parcels, causing a gap in the merge flow.
- Dispatch lane misalignment: the PLC has sealed a dispatch trailer, but the WCS never received the seal confirmation, so the WCS leaves the lane in an “in progress” state and blocks the next trailer.
- Retry storms after network maintenance: an unplugged fibre or a restarted switch causes hundreds of commands to time out at once; when the link returns, the WCS floods the PLC with a backlog of retries, and the PLC spends its scan cycles discarding stale messages.
These symptoms are often intermittent, which makes them hard to reproduce in a test environment. The evidence capture practices below are essential for diagnosis.
Evidence Collection and Diagnostic Table #
Diagnosing retry problems requires correlated evidence from at least three sources: the WCS log, the PLC log, and a network capture. Timestamps must be synchronised, ideally via NTP, because a 500-millisecond difference in clock skew can turn a healthy retry into an apparent protocol violation. The table below presents common retry-related symptoms, their typical retry signatures, evidence to collect, and the interpretation errors that frequently mislead engineers.
| Observable Symptom | Typical Retry Signature | Evidence to Capture | Common Misread |
|---|---|---|---|
| Repeat command packets on the network | Same sequence number with increasing retry counter; no ACK visible in the capture | Port mirror captures, WCS timestamps, PLC message-log timestamps | “The PLC is ignoring us” when in fact the network path is dropping or delaying packets before they reach the PLC |
| Double divert or double induction | Command was ACKed on the first attempt, but the ACK was lost; a retry arrived after execution | Photoeye event sequence, divert actuator signal timestamps, ACK capture, WCS retry counter | “The PLC double-executed” when the PLC correctly performed the same command twice because the retry was not filtered |
| Slow sortation at one cell only | Multiple timeouts followed by eventual success; latency histogram shows a tail | PLC scan-time trend, network switch error counters, CPU load graphs, message timestamps | “The conveyor speed is wrong” when the culprit is a congested switch or an overloaded PLC communication task |
| Exception storm after PLC restart | Messages rejected with unknown-sequence or duplicate-key errors immediately after reboot | PLC boot log, WCS session log, sequence number ranges before and after restart | “The configuration was corrupted” when the real cause is a reset sequence-number space colliding with retained WCS retries |
| Intermittent duplicate parcel scans | No retry on the command side; a status message was delivered twice | Scanner read events, WCS deduplication flags, PLC output timestamp of the status | “A retry is causing this”
Related Parcel Operations Guides #Updated on August 25, 2026 |
