Help with using Extended CAN Frames

[QRP]

Could someone please help me understand how to use the CAN IDE extend frames in Labview. I have some code using the LAWICEL CANUSB DLL that I need to convert over to use the NI-CAN hardware in Labview. The current CANUSB code is setting up a can message with the following code. I am using 29bit message IDs for my application.

CMD_ID_LENGTH=5;

CANMSG_EXTENDED=0x80;

can_msg.data = data_frame;

can_msg.id = command_id | (((UInt32)id) << CMD_ID_LENGTH);

can_msg.len = CAN_DATA_LENGTH;

can_msg.flags = (byte)(flags | LAWICEL.CANMSG_EXTENDED);

My question is would ORing the 29 bit command ID with 0x20000000 net the same result as above when writing a frame in Labview using the NI-CAN hardware? For some reason you have don’t have to OR in anything into the ID for the CANUSB dll to work, but you have to or in 0x80 into the flag data to get the extended frame mode. Why does Labview implement it differently then the standard CAN protocol below. Just trying to understand the difference between the CAN implementations using the extended CAN frames since I can’t make the NI-CAN extend frame code work, but the CANUSB code works fine.

Message ID (11 bits)

SRR (1 bit)

IDE (1 bit)

Extension on Message ID (18 bits)

RTR (1 bit)

[Dave.C]

Hi QRP,

I believe this KnowledgeBase article should address your question. 

It states that a conversion must be performed on the extended arbitration IDs before writing and reading them.  The reason for this is that the 30th bit is used to identify extended or standard arbitration ID. The arbitration ID is represented by 32 bits. When the 30th bit is high, extended arbitration IDs will be used. This uses 29 bits to represent the arbitration ID. When the 30th bit is low, the standard arbitration ID is used. This uses 11 bits to represent the arbitration ID.

[QRP]

Thanks. Yeah I knew that much. I'm talking with some hardware that supports extended CAN IDs frames. Is the 30th bit for extended IDs a Labview stardard or is this a CAN bus standard. I'm beginning to wonder if maybe the hardware I'm trying to communicate through doesn't support the Extended ID with that bit set. The hardware talks just fine using LAWICEL USBCAN adapter, but it hates the NI-CAN messages. I assume both the NI and USBCAN adapter use a standard extended frame packet between the 2. Is this not true? I might have to abandon using the NI-CAN hardware and intergrate the USBCAN dll into my labview code unless I can figure out what the difference is between the 2 extended ID can frames. Do you have any more information on this?

Thanks,

Rob  

[Dave.C]

Hi Rob,

Our hardware and software conforms to the CAN standard, however if you are using a protocol with an extended message (payload larger than 8 bytes, i.e. J1939), it can cause issues with our software being able to resolve the arbitration ID.

How long is the payload portion of your frame?

[QRP]

It's only 8-bytes long. I'm trying to sniff out what the USBCAN adapter is sending out, so I attached the NI 192017A-02 single termination cable to the USBCAN adapter and the other end of the cable to the NI-CAN. When sending frame messages to the NI-CAN I don't receive any frames back and I know they are coming accross the cable. Why do you think this is? They should talk together. If I connect 2 NI-CANs together it works fine. I'm not sure what really do. The equipment we are using supports the CAN 2.0 standard, but it just won't talk to the NI-CANs, but does to the USBCAN. This is just mind blowing 😃

Do you have anything to add to this?

[nathand]

Which NI-CAN hardware are you using? What software are you using to read the received CAN packets? Are you certain that all the termination is correct? What do you mean by "receive frames back" - you're not seeing them on the receiving side, or you're expecting them to echo back to the sending side? How do you know the frames are being sent? Do you have the ability to put an oscilloscope on one of the CAN lines?

[TroyK]

I came across similar problems when trying to get NI-CAN hardware talking to Vector CAN hardware.

It came down to using the correct method for indicating an extended frame on the different hardware.

To indicate to my Vector hardware that a frame used an extended ID I had to set bit 31 high.

So an ID of 0x1ABBCCDD becomes 0x9ABBCCDD.

If you don't set bit 31 the driver transmits it as a standard ID = 0x4DD.

Vector CAN needs the extended ID ORed with 0x80000000.

BUT, to tell NI-CAN that a frame uses an extended ID, you must set bit 29 high.

So an ID of 0x1ABBCCDD becomes 0x3ABBCCDD.

NI-CAN needs the extended ID ORed with 0x20000000.

Your two different types of hardware may be using different bits to indicate an extended frame. Both conform to the CAN standard because it doesn't specify what to do with those extra 3 bits! Surely they could have come to some sort of agreement, but alas, standardization only makes it so far.

Bits 29, 30 and 31 are not transmitted. Try setting them ALL high, then both types of hardware should recognize that you want an extended frame.

OR your extended IDs with 0xE0000000. It shouldn't break anything... I think? (Add disclaimer here...)

Don't forget to mask out the extra bits when trying to match the IDs returned. AND the IDs with 0x1FFFFFFF.

[QRP]

I figured out the problem. Even though the CANUSB was set at 250K baud it really only sends out data frames at 125K. Setting the NI-CAN baud rate to 125K fixed the whole problem. They both communicate now. Thanks guys for the help.