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.