Why Does ncReadNet.vi Require OR gate 0x20000000 With Extended Arbitration IDs?

Updated Apr 8, 2019

Reported In


  • NI-CAN

Issue Details

To transmit CAN extended ID (29bits) frame in NI-CAN, why does ncWriteNet.vi require OR-ing 0x20000000 like below?
I refer to example named Transmit Receive same port.vi.



The binary representation for 0x20000000 is 0010 followed by 28 zeros, where the extended arbitration ID consists of 29 bits. The 30th bit is relevant because it tells the NI-CAN driver that the arbitration specification is to have extended form (29 bits) as opposed to standard form (11 bits). Moreover, it makes sense to require a distinction between extended and standard arbitration ID's in some way, as otherwise, the driver would not know whether to use standard or extended format for an ID such as hex 1. That is, 1 can be represented with either 11 or 29 bits, but the driver must know how many bits to include in the actual frame which is written to the CAN bus. Theoretically, this distinction would not be required for arbitration values greater than or equal to 2^11, since such values cannot be represented by 11 bits.

For consistency, the implementation choice, in this case, was to require that a 30th bit is set to 1 when specifying extended (29 bit) arbitration IDs, which resolves standard vs extended frames and explains the OR-ing with 0x20000000 seen in shipping examples. The operation described here is noted in the NI-CAN Hardware and Software Manual on page 11-70.

Also linked below are CAN Transmit and Receive VIs which handle extended arbitration IDs. The Transmit Receive Same Port.vi in the Example Finder can also do this.