CAN reception stops unexpected when using more CAN objects

[Anders H?dt]

Hello,

I'm developing my first NI-CAN application under Windows XP and NT), using VC++ 6.0, and NI-CAN v1.6.

I only need to receive CAN frames, I do not transmit.
I use several Arbitration IDs. Packets with some IDs are transmitted periodically at quite a high rate(baudrate 250kb/sek), while other IDs are used for bursts of some houndred packets at full speed, then nothing for several seconds. Yet other IDs are used for single, unsolicited packets.

It's the bursts and the unsolicited single packets I am going to use.

I experience problems if I enable reception of more than one Arbitration ID.

I use separate CAN objects for each arbitration ID.
There is a single callback function, that is connec
ted to all CAN objects by a call to ncCreateNotification for each CAN object.

I have tried setting NC_ATTR_PERIOD in the CAN objects to both zero(Disable) and e.g 1000 (1 second), but I cannot see that this really does any difference, as the timeout period that I experience, is set by the parameter to the ncCreateNotification.

However, I see that if I use one single ArbID (And one CAN object), I receive the frames as I expect.
If I enable more ArbIDs (by creating more CAN objects), I get timeout callbacks from all IDs for a while, but when my burst starts, it seems like this CAN object goes dead. It does call the callback a few times, and then nothing more. When the burst stops, I do not get any timeout callbacks either.

I use ncReadMult, and always return NC_ST_READ_MULT from my callback, to re-enable reception.

Any ideas?
Anders Hørtvedt
Argos Control
Norway

[DiegoF]

Hi,

I can't see anything wrong from your description. There is no problem in using the same handler with diferent objects. Be aware that the notification callback function runs in a different thread, so you need to provide the propper protection mechanism if you are using global data in the callback function. The notification functions should be as short as posible. Usually the callback read the frames and stores them in some queue. Another function in the main execution flow is in charge of processing the frames.

Also, be aware that you need to configure ALL the objects, then open ALL the objects and finally use them. If you are not following this sequence you might run into problems.

If you're receiving a lot of frames with different Arbitra
tion IDs you might consider using the Interface Object. By using the compare and mask attributes, you can configure the interface object to receive a group of arbitration IDs. You can then install a single notification handler in to the interface object. Within the notification handler you would sort the frames using their arbitration IDs.

I attached a small example. It's a modified version of the analyzer.c shipping example. A single callback handles the notifications of several objects. I did it quickly so there might be some errors. The main problem is making sure all shared data is protected. A problem present in a any multithreaded application.

Hope this helps.

Diego F.
National Instruments