extended ID, NI-CAN-Card

[Achiles77]

Hello everybody,
 
in my thesis (diploma) is to be provided  a simulation-software for CAN BUS detectors. The CAN-Bus are operated by CAN-ard (NI-CAN-Series 2 PCMCIA). I learned that in CAN-Protocoll 2 kinds of Identifiers (11 bit and 29 bits). I use extended Identifier (29bits).
When I tested the CAN example (CAN Receive VIs), I have determined that the NI-Card supply an ID from 30bits.
Exampel: However the CONTROLLER sends 10AAA00B (Request) is shown to 30AAA00B
Someone has an idea or an experience with NI-Cards?
 
Regards 


Unbenannt.jpg:
Loading Image...

[Troy K]

Why does the NI driver use the 30th bit to mark an ID as extended?Is there a standard somewhere that states that this is the correct way to do it?I only ask because I have been given an A2L file that uses the 32nd bit to mark an ID as extended.So I'm having trouble connecting to the ECU.I used some VECTOR CAN equipment to get a CAN trace and the data being sent out was using an 11 bit ID.I manually changed the A2L file so than now the correct 29 bit identifiers are being used but I still get timeouts when I try to connect to the ECU.I'm using a NI USB-8473s.Message Edited by Troy K on 05-09-2008 02:05 PM

[DirkW]

There is no standard regarding the extended ID mark. Vector is using the 32nd bit and NI uses the 30th bit to let the driver and you know about the ID format. However the NI driver parses the vector and NI format correctly and removes the the 32nd and 30th bit from the ID if you import a db file into MAX or use the NI-CAN Channel api.The frame api still has the bit set to let you know about the id format and you have to set or remove it manualy.DirkW

[Troy K]

Ahhh, so that's why it didn't work properly for me. I only had a NI USB-8473s. It only works with the Frame APIs, not the channel APIs. Still, there should be a standard! Not quite as annoying as motorola/intel endianess, but it's up there.