Buyer's Guide
CAN Arbitration Changes Which Industrial AI Inputs Arrive First
A sequence of successful CAN frames does not establish that an industrial AI consumer received every required input by its deadline. Identifier priority can shape which pending messages complete first. Compare a data offer against the required message set and delivered input evidence, rather than infer complete or fair delivery from an aggregate frame count and nominal bus bit rate.
Read priority at the arbitration point
When classical CAN nodes begin transmitting together at a valid start, arbitration resolves their competition without corrupting the winning frame. For standard 11-bit data frames, the lower binary identifier has higher priority. At the first differing identifier bit, dominant 0 prevails over recessive 1. A transmitter sending 1 but observing 0 stops; the winner continues. The waiting message must contend again at a later opportunity.
Priority follows binary ordering, rather than a count of zero bits or a random-backoff draw. An identifier also does not automatically identify a physical source or define the payload's meaning; the applicable message definitions must supply those associations.
This explanation uses the selected arbitration material in Texas Instruments' SLOA101B application report, originally dated August 2002 and revised May 2016. The case concerns same-format classical standard 11-bit data frames. It does not extend the historical report into a current CAN FD, CAN XL or mixed-format specification.
References: [TC]
CAN2: identify the two contenders
CAN2 is a fictional, untimed comparison on a supported, error-free bus with exactly two sources. The supplied message definitions associate source A's messages with identifier 0x120 and source B's message with 0x123. Those associations are premises, not node addresses inferred from the identifiers. Every message is a classical standard 11-bit data frame carrying eight payload bytes; the other arbitration-format attributes are the same.
A1 and B1 are ready to contend at the same valid start. After A1 completes, a separate A2 is stipulated ready before the next valid start, while B1 remains pending. Nothing is overwritten or dropped. There is no other traffic. These premises deliberately leave controller queue selection and elapsed time outside the comparison.
A1, A2 and B1 label messages. The example supplies no payload interpretation, measurement timestamps or evidence that A1 and A2 represent independent physical observations.
Follow two completions without assuming a turn for B
The 11-bit representation of 0x120 is 00100100000. For 0x123 it is 00100100011. Numbering identifier bits from bit 10 at the most significant end to bit 0 at the least significant end, the first difference is at bit 1: A sends 0 and B sends 1. The identifiers have matched through bit 2. A1 wins at that difference and continues to completion; B1 stops transmitting and remains pending under the example's assumptions.
At the next valid start, the stipulated A2 and the still-pending B1 contend. Their identifiers have the same ordering as before, so A2 wins. Waiting through A1 has not given B1 a turn ahead of the newly ready higher-priority message. The first two completed frames are A1 and A2.
Their completed payload total is 8 + 8 = 16 bytes, all associated with A. No B1 payload has completed in this prefix. Counting attempted transmissions would answer a different question from counting completed frames.
If no new higher-priority message is ready at a later opportunity, B1 can then win under the stated conditions. Its absence from the first two completions therefore does not demonstrate loss. Conversely, two A completions establish neither a fair share for B nor a latest completion time. The example supplies no timing, traffic rate, utilization percentage or starvation threshold.
References: [TC]
Read the 16 bytes against the required input
Suppose an industrial AI consumer requires an input from both A and B before making a particular evaluation. CAN2's two-frame prefix does not contain that required pair, even though it contains two successful frames and 16 payload bytes. A second A frame cannot stand in for the absent B frame merely because the total byte count looks sufficient.
The input requirement matters. A task requiring only the supplied A messages could find this prefix useful. A task requiring B still has an unresolved input. Neither conclusion requires declaring the bus faulty: the example's supported bus and successful winning frames coexist with incomplete coverage of the stipulated pair.
Because CAN2 assigns no times, it cannot establish whether B1 meets or misses a real deadline. A deadline claim needs evidence relating the required message to the consumer's actual receipt and use of it. A nominal bus bit rate describes no such relationship by itself.
Keep the missing-input state visible. The appointed application owner should specify how the consumer handles an absent or late required input. Reusing an older B value or inserting zero would introduce an additional application decision; neither result follows from observing A1 and A2.
Compare offers at the consumer's actual input
Consider two fictional offers. Offer Record supplies a recording of successful frames, an aggregate frame count and a nominal bus bit rate. Offer Coverage also identifies the required input messages, explains their priority relationships under competing offered traffic, and provides evidence of what reaches the intended consumer. These descriptions represent different evidence packages, not reported product results.
Record can be a useful recording service when that is the agreed deliverable. For a requirement that includes B before a consumer deadline, its aggregate statistics leave the decisive question open. Coverage makes that question assessable, but the fuller description alone is no proof of acceptable delivery.
Have the appointed device or integration provider connect the actual message definitions to the proposed feed: which identifiers and message types supply the required inputs, how their payloads are interpreted, and which source associations apply. Then require an explanation of the competing offered traffic and relevant controller behavior, including whether a required pending message can be replaced or discarded before transmission. CAN2's no-drop premise must not silently become a claim about the offered equipment.
Connect the delivery evidence to the same equipment, operating conditions and required message set. Establish what each timestamp denotes: source observation, completed bus reception, gateway recording or consumer receipt. A recording timestamp with no defined position in that path cannot settle a consumer deadline or input freshness. Identify any later feed stage that filters, retains or replaces messages before the consumer receives them.
The positive decision is to select a defined coverage commitment whose supporting evidence matches the consumer's required inputs and timing conditions. If the evidence establishes only successful recording, assess it as that deliverable and assign the remaining coverage decision to its responsible owner. Neither incomplete evidence nor CAN2 proves that a particular product is incompatible with the task.
Keep arbitration, retention and interpretation separate
The related Ethernet scheduling guide concerns service among queues at one output. CAN2 instead follows distributed contention between simultaneous bus transmitters. Its two completions are not a deficit-credit calculation or an allocation of equal byte service.
The OPC UA guide addresses observations and changes that survive sampling, filtering, queues and publication. B1 in CAN2 has not been discarded from such a queue: it is explicitly still pending. Replacing this premise with a retention-loss story would explain a different mechanism.
Once a payload arrives, its meaning remains another question. The Modbus guide shows why delivered words need an applicable application definition. That distinction complements the CAN message-definition requirement without supplying a CAN payload map. Keep each piece of evidence attached to the decision it can answer.
Bring a separate IT cabling need to its physical scope
If the customer-selected equipment project separately requires supported physical IT cabling, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed fiber and copper installation, endpoint labels and connection records. Use the related project inquiry with a nonconfidential equipment and connection outline, approved routes, material-supply responsibilities and required handoff records to discuss scope, requirements and availability.
CAN fieldbus integration, controller configuration and industrial-control or AI application acceptance remain with the appointed technical providers. The inquiry here concerns the separately needed physical IT installation package.
References: [L1]
Primary sources
- [TC] Texas Instruments - Introduction to the Controller Area Network (CAN), SLOA101BChecked 2026-10-21. August 2002, revised May 2016; selected identifier-priority material in section 3.1.1 and nondestructive arbitration in section 4.1, including Figure 5. Used only for the stated classical 11-bit data-frame case.
- [L1] Leviathan Systems - Structured Cabling & Fiber InstallationChecked 2026-10-21. Agreed physical IT fiber and copper installation, endpoint identification and connection records. Useful when the selected equipment project has a separate physical cabling requirement.