Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Arbitraion ID seems to be overwritten in the CAN layer by something else (possible labview bug?)

I've noticed something very strange.  After running this Labview program for almost a year, I decided to switch from the single CAN port PCMCIA card to a dual CAN port card.  I cannot tell if this was the reason for this problem, but its been happening around the time the card was switched.  I am also using Labview 7.1 and Ni-Can 2.3.2f1 driver.
 
Here is the scenario:
 
The receiving end of the CAN bus needs a message to do something.  Each message contains 5 CAN packets with the same Arbitraion ID, but different payload (which is then reassembled at the receiving end for a command).  All ID's must match.  I basically bring an ID and an index with 5 rows (each having a different payload for each CAN packet) into a while loop.  Here, I pass the same arbitraion ID to the ncWriteNet.vi, but a different payload (index) for 5 iterations of the while loop.
 
I use CAN0 for communication, and CAN1 as a seperate Can-Sniffer which logs all the can messages into a text file.  This will work for a few hours.  Again, this process has worked for almost a year, but I've noticed a problem occuring ever since I went to the Dual-CAN pcmcia card.
 
Out of 5 packets which each must have the same Arbitration ID, one of the packets suddenly shows up on the Can-sniffer/logger with a different ID number!  Out of the 8 bytes, either Byte 3 and 4 or 7 and 8 change to some obscure number. 
 
I confirmed that the Arbitraion ID is not changing in this while loop, I am passing a value which should never change.  It almost seems as if the CAN chip on the card is overwriting a register or something to that nature.  Why?  You would think if the Arbitration ID somehow changed in labview software, it would change for the remaining packets out of the 5.  What I actually witness is the ID changes back to the original ID for, say packet 4 and 5.  Very bizzarre.
 
Any ideas?  I will try reverting to the single CAN card, possibly try older versions of drivers to determine if there is a corellation.
0 Kudos
Message 1 of 2
(3,370 Views)
Hi dre99gsx,

The key I see in troubleshooting this is to determine where the data is changed at.  For example, it is easy to assume that this is happening when the data is transmitted, but couldn't it also be happening when it is being received on the other port?

Some ideas I would have to locate the source of the problem:

1. Switch the roles of the two ports.  ie, transmit using CAN1 and monitor using CAN0, to see if the same behavior persists.

2. Install both cards in the computer (if possible, you may need to use two computers).  Transmit from the single port card and receive on the two port card to see if the problem still persists.

3. Repeat step 2, but this time transmit from the two port card, and monitor on the single port card.

By performing some of these tests, we should be able to figure out if a particular port is causing problems, a particular card, or if the problem could be a result of something in software.  Let us know what happens when you try these ideas.

Jason S.
Applications Engineer
National Instruments
Message 2 of 2
(3,344 Views)