Control Network Capacity: Inspection Points and Early Warning Signs

Control networks in warehouse settings are not simply data pathways; they are shared timing infrastructure. When capacity is discussed, most teams talk about bandwidth, link speed, or the number of connected devices. In practice, the first signs of capacity shortage appear as erratic scans, delayed acknowledgements, missed barcode reads, or small gaps in a motor controller’s heartbeat. This article describes inspection points and early warning signs for control network capacity. It is written for warehouse operators, maintenance engineers, and controls teams who need a calm, evidence-based approach to diagnosing network-related issues without assuming the network is at fault. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over any general guidance offered here.

Capacity in Warehouse Control Networks #

Capacity in a control network is not one number. It is the combination of raw link bandwidth, the packet-per-second rate a switch can process, buffer depth on each port, and the repeatability of transfer delay from one device to another. A warehouse control network frequently carries time-sensitive traffic from programmable controllers, variable-frequency drives, motor starters, RFID readers, barcode scanners, AGV and AMR interfaces, wireless client devices, and supervisory systems. These devices expect to exchange small cyclic messages on a fixed schedule. When any resource inside the path gets close to its limit, delivery timing becomes irregular.

The interaction between components matters as much as the components themselves. A switch may show low average utilisation while its port buffer is overwhelmed for a few milliseconds. A wireless access point may have a strong signal while its radio is constantly retrying because of contention with nearby units. An AGV controller may report a “communication timeout” when the actual issue is a time alignment mismatch between two event records that arrived through different paths. For these reasons, capacity inspection must look beyond link speed and include the behaviour of traffic under momentary load.

What Consumes Capacity and Why It Matters #

Control network traffic can be grouped into a few broad types. Cyclic I/O traffic is small, frequent, and deterministic. It includes controller-to-remote-I/O messages, drive status words, and safety-related telegrams that repeat every few milliseconds. Event data is larger and less frequent. It includes barcode scans, AGV position reports, condition-monitoring results, alarms, and order-status messages transmitted to a host when something occurs. File transfer and management traffic is rarely time-critical, but it can cause short bursts when a configuration upload, firmware update, or remote-desktop session starts.

Wireless traffic adds another layer. Client devices on AGVs, turret trucks, and hand-held scanners periodically disassociate from one access point and roam to another. Roaming generates authentication, association, and address-resolution frames. In a dense layout with many access points, these management frames consume airtime even while ordinary data rates remain low. Time alignment introduces its own burden. When event records are timestamped on different devices, the receiving system relies on a common time reference. If network delay varies widely, timestamps remain accurate but the order in which records arrive can differ from the order in which they occurred. This is not a hardware failure, but it is a capacity symptom.

Inspection Point: Switch Ports and Physical Links #

Physical layer faults are the most common source of intermittent control network problems. They are also the easiest to inspect if you have access to switch port statistics. The goal is not to become a network specialist; it is to collect counters over a defined period and compare them with the same period in a healthy state.

During inspection, log the link speed and duplex on every important port. A port that has renegotiated to a lower speed can create a bottleneck that shows up only under full conveyor load. Also inspect the health of optical connections if the warehouse spine is fibre based. Dust, contamination, and bent pigtails are invisible to most software counters until the run becomes marginal and drops packets under vibration.

Inspection Point: Wireless Link Margins #

Wireless links in a warehouse are rarely stable by nature. Racking, metal shelving, shrink-wrap, passing lift trucks, and moving AGVs all change the radio environment. The first signs of a capacity problem are often not low signal strength but rising retry rates and uneven latency. A client may report an excellent received signal strength indicator while still suffering because the access point radio is saturated with other traffic.

When inspecting a wireless link, an established sequence is useful. Check the client’s receive level and the corresponding access point’s client signal-to-noise ratio. Then examine the retry percentage on both sides. A retry rate that climbs during peak activity, even before signal level falls, indicates airtime congestion rather than a coverage gap. Then look at the channel utilisation on the access point radio. In dense deployments, all radios may be on the same channel, and a nearby autonomous device or camera stream can occupy most of the available airtime.

Roaming is another capacity factor. A lift truck moving from one aisle to another may attempt a fast transition between access points. If the network is already congested with management frames, roaming can take longer than the vehicle controller’s expected timeout. Observing repeated roaming failures at a specific aisle end is an early warning sign. Also count how many clients are associated with each radio; a single radio with a long client list and moderate traffic can behave worse than a lightly loaded radio serving fewer clients.

Inspection Point: Traffic Pattern and Burst Behaviour #

Average utilisation hides the most relevant capacity warning signs. A warehouse network link that carries 20 percent average load can still fail frequently if that load arrives in sub-millisecond bursts. For example, a group of barcode scanners may send results only when a parcel passes a certain point. If many scanners complete near the same time, a small switch port receives a short but intense flood of frames. Some are queued, some are discarded, and the scanner application sees a timeout. The average utilisation remains unremarkable.

To inspect burst behaviour, you need data over a short time window. Many managed switches provide a utilisation histogram or an interface counter that records the maximum number of frames per second. If your site allows port mirroring on a non-safety-critical interface, you can also capture traffic for a minute during a known peak and review the packet size distribution. Control networks tend to produce many small frames around 64 to 128 bytes in length. A switch that can forward a high total bit rate may still be overwhelmed by a very high frame rate.

Time alignment is closely tied to burst behaviour. When a burst temporarily saturates a switch queue, event records from that moment arrive late. The receiving software then has to decide whether to store them with their original timestamps or with the arrival time. If records arrive late in a scattered order, downstream systems may incorrectly process them as out of sequence. The early warning sign is a growing discrepancy between device timestamps and arrival time in the middleware logs, even when every individual message is intact.

Early Warning Signs in Operations #

Operators often notice capacity issues before the controls team sees a counter. These symptoms are not proof of a network problem, but they justify a structured inspection:

• Intermittent conveyor pauses with no corresponding mechanical fault. The drive receives a command late, or a status reply arrives after the controller’s watchdog expired.
• Barcode and scanner timeouts that occur only at peak throughput. A scanner may retry internally and later report a success, masking the issue.
• AGV or AMR position corrections that appear as small jumps. The vehicle controller may briefly lose confidence in the network and auto-correct its speed.
• HMI screens that become sluggish for one or two seconds, then recover. Screen refreshes compete with cyclic I/O for switch buffer space.
• Alarm storms with no corresponding process event. Multiple devices fail their heartbeat at the same moment, producing a burst of alarms.
• Occasional duplicate or out-of-order event records in the warehouse control system. Retries and late arrivals cause this even though no application error is logged.
• Increased watchdog faults on remote I/O blocks that have no pattern tied to a specific machine cycle.

When one of these occurrences appears, the immediate reaction is usually to replace a cable, swap a switch, or restart a controller. Instead