Fix a stuck CANbus Status bus load reading in CODESYS

Why does the CODESYS CANbus Status tab show the same bus load on two different buses?

Because a constant value is not a measurement: 16% on two buses that read 55% and 40% on a sniffer means the load field is not derived from the traffic on either bus, so you verify the tab first and then compute the load yourself.

A 39-point gap on one bus and a 24-point gap on the other, produced by one frozen value, is the signature of a field nobody is updating. Sort what you see before touching any configuration, because each pattern has its own next step:

The sniffer readouts are checkable: they change with traffic you generate, and they can be rebuilt from the frame counter. The tab's constant survives neither test, which is why the calculation becomes the trusted source.

Is the Status tab reading live traffic?

Watch the tab for 5 s while you disconnect one node or stop one cyclic transmitter: any field that moves proves the tab is live, and a tab that never moves means the diagnostics are not refreshing at all.

1. Log in to the runtime and start the application; confirm the application state reads Running before you open the tab.
2. Open the CANbus device and its Status tab; confirm the bus state field reports an operational state, not a blank or initial one. CODESYS integrates configurators, protocol stacks and diagnostics for classic fieldbuses such as CANopen, and this tab belongs to that diagnostics layer.
3. Change the traffic in a way you can see: pull one node off the connector, or stop one cyclic transmitter for 10 s.
4. Re-read the tab. Any moving field means the tab is live and the load figure is the one outlier; keep checking. Nothing moving at all means the diagnostics are dead, and the calculation section is your answer.

Read the tab only with the application in Running; with the application stopped there is nothing fresh to display. Node state and guard timing are neighbouring subjects with their own behaviour, covered in CODESYS CANopen node status and guard timer explained.

Does the configured baud rate match the physical bus?

The bit rate set on each CANbus device in the project must equal the rate the network runs at; a mismatch fills the bus with error frames, drifts nodes toward error-passive, and makes every load figure on that bus meaningless, whatever tool produces it.

A device set for 250 kbit/s on a 500 kbit/s network is not merely slow; it loses arbitration and acknowledgement from the first frames it transmits. Read the value from each CANbus device in the project, read the rate set in the sniffer, and make them identical per bus. Confirm the mapping too: the CANbus device bound to the connector you measure must be the one whose tab and parameters you are reading. A swapped mapping cannot explain two identical values, but it will corrupt every comparison you build on top of it.

Why do two tools disagree on bus load?

Tools differ on stuff bits, the 3-bit interframe space and error frames, so two honest measurements of one bus sit a few percentage points apart; they cannot sit 24 to 39 points apart while the frame counter shows thousands of frames per second.

Validate the reference before you build on it. Attach the sniffer at the same bit rate, run it listen-only so it observes the bus without transmitting, and confirm its counters are complete; troubleshooting PCAN Explorer 5 missing CAN messages is the walkthrough for that check. Then rebuild its load figure by hand from its own frame counter, with the formula in the next section. If your calculation reproduces the sniffer readouts, the reference is sound. If it lands near the tab's constant instead, the sniffer's readout and its own counter disagree; recheck its bit-rate and channel settings before you trust either number.

How do you calculate CAN bus load yourself?

Bus load is bits on the wire per second divided by the bit rate, so load % = 100 × frames per second × bits per frame ÷ bit rate; a standard frame carries 47 + 8n bits and an extended frame 67 + 8n, with n the number of data bytes.

The bit counts come from the frame layout: start-of-frame, identifier and control fields, data, CRC, acknowledgement, end-of-frame, plus the 3-bit interframe space after the frame.

Bit stuffing pushes the number up. After five consecutive bits of the same polarity, the transmitter inserts one opposite bit, from start-of-frame through the CRC sequence. A standard frame carries 34 + 8n stuffable bits, an extended frame 54 + 8n, and worst-case stuffing adds floor((stuffable − 1) ÷ 4) bits. With 8 data bytes that is floor(97 ÷ 4) = 24 extra bits, taking a full standard frame from 111 to 135 bits. Compute the load both ways: the true figure sits between the two, and a sound reference tool lands inside that band.

For the frame count, use the sniffer's statistics window averaged over 10 s, or count inside the application, starting from the CANBus Example library in the CODESYS store and the raw frame receive your runtime package documents. Then prove the result: stop one transmitter and confirm your calculated load falls by that node's contribution while the tab's value stays frozen.

How does a bus load example work out at 500 kbit/s?

Scenario: bus 1 at 500 kbit/s carries 2,300 standard frames per second with 8 data bytes each, and the sniffer's load readout says 55%; the arithmetic brackets that reading between 51.1% and 62.1%, while 16% would need only about 720 frames per second.

Step through it:

1. Bits per frame: 47 + 8 × 8 = 111.
2. Traffic: 2,300 × 111 = 255,300 bits per second.
3. Load with no stuffing: 100 × 255,300 ÷ 500,000 = 51.1%.
4. Stuffing worst case: stuffable bits 34 + 64 = 98, extra bits floor(97 ÷ 4) = 24, frame length 111 + 24 = 135 bits.
5. Load with worst-case stuffing: 100 × (2,300 × 135) ÷ 500,000 = 62.1%.

The sniffer's 55% sits inside the 51.1% to 62.1% band, so the reference tool and the arithmetic agree: bus 1 is genuinely just over half full. Now test the tab's claim. 16% of 500,000 is 80,000 bits per second, which at 111 bits per frame is 80,000 ÷ 111 = 720 frames per second. The counter reads 2,300, more than three times that number, so the tab is not describing this bus.

The decision out of the example: quote 51% to 62% as bus 1's real load, plan capacity on the mid-point with the band as the uncertainty, and treat the Status tab load field as absent until a runtime update fills it.

How much bus load is too much to plan on?

Keep planned classic CAN load below about 70%: above that, a low-priority frame can lose arbitration again and again as higher-priority traffic stacks up, deadlines start to slip, and the margin for burst traffic disappears.

Turn the ceiling into a decision with the same formula. Suppose a new transmitter sends 100 standard frames per second with 4 data bytes: each frame carries 47 + 32 = 79 bits, so the addition is 100 × 79 = 7,900 bits per second, worth 100 × 7,900 ÷ 500,000 = 1.6 percentage points at 500 kbit/s. On the 40% bus that lands near 41.6%, a comfortable margin under the ceiling. On the 55% bus it lands near 56.6%, still under the ceiling but with less room; if that bus already carries deadline traffic, shorten the message's data, stretch its cycle, or hang it on the other bus.

Recommendation: When the Status tab shows one constant value on buses whose traffic you can prove differs, stop reading that field: confirm the tab is live, match the bit rates, validate the sniffer, then trust a load figure you compute from frame counts, and keep planned load below 70% with extra margin on buses that carry cyclic I/O. Report the dead statistic to the runtime vendor with the runtime version, and prove any updated build on a bench unit before it reaches a production panel.

A bus load figure is controller-side data. If the floor also needs live numbers on a wall, that is a separate job: start from shop-floor signage and plan an offline sensor status display for your shop floor.

Questions