Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Max number of Messages using Channel API?

We have a 2-port CAN card (series 2) runing at 500kB. When we use channel API to setup 9 messages (about 20 signal-channels) at 100Hz update rate in a write task - the data is constant, set to repeat output last sample (therefore butffer size is not the problem).
Task Init-start gives error of too many channels too high speed. when we set only 8 messages at 100Hz or 9 messages at 90Hz, it works fine.
If we calculate based on 500kB and 8-byte messages (give enough overhead), CAN bus shall be able to transact at least 40 full-length (8-byte) messages at 100Hz.
there are two Rx messages at 50Hz on the bus. (totally only these 10 or 11 messages are on the bus).
so what is the problem, simple because the CAN channel API is not good enough? 
0 Kudos
Message 1 of 6
(5,330 Views)

Hi Bob,

What version of the NI-CAN driver are you using?  If you aren't using the latest, you may want to try upgrading.  Also, what exact error number and message are you receiving?  This would be helpful in finding possible solutions and/or workarounds.

Also, have you tried different baud rates and received similar behavior?

Thanks Bob!

Adam W
Applications Engineering
National Instruments

 
0 Kudos
Message 2 of 6
(5,309 Views)

Hi,

If you use a channel task with a certain sample rate, you will get a periodic object for every message in the backround. These objects can run with a maximum speed of 500 Hz.

But the problem is that the onboard cpu need this 1.5 to 2 ms execution time for every periodicobject and because it happens sequentially the tiome adds up.

That means if you configure 10 messages for sampled transmit, the driver calculates the maximum sample rate and if you configure more it causes the error message.

In your case 8 messages with 10 ms , is the maximum the board can handle periodically.

DirkW

0 Kudos
Message 3 of 6
(5,296 Views)
The NI-CAN driver I used was 2.3.1f1(?), then updated to 2.4.0f0. the results are the same. the erroe code is: -1074388831.
Dirk is right. I did some tests and find the max speed it can spit to the bus is 666Hz (frames/s). this is true for both channel API - sampled ouput and for frame API - CAN objects.
this will not meet the requirement of my (and many) application. I want use the NI CAN card to simulate several controllers in a vihicle to talk to one controller to be test. there are usally more than ten messages, many of them at 10ms update rate.
 
when using frame API network object, timestamped, the max throughput seen is 830Hz.  when use "immedaite", the max throughput is ~3.15kHz (76% bus load). this rate probably meets most application,
what's Interesting is, when use channel API, signle write (sample rate 0) in a loop, use the loop to control the rate, it is able to reach same ~3.2kHz rate, although the timing is not very accuate (but the channle API is not well timed either at higher rate: 6 messages sample rate at 100Hz, ouput recent: varying from 96 to 104Hz).
 
the driver needs some improvement.
 
 
 
0 Kudos
Message 4 of 6
(5,268 Views)

The differences in performance you can see are explainable from the driver architecture itself. If you choose the channel api with sample rate >0, you are using a periodic frame api object in the background, which has the 1.5 ms bottleneck. That's because the periodic object is handled by the board CPU directly and there is a lot of overhead in providing new host data to send. If you run the channel api with sample rate 0, it changes to the Network Interface object in background, which then uses software timing (your while loop) but transmits faster because it bypasses the CPU and transmits directly from the shared memory queue.

Normally a CAN network should not run with busloads > 50 %. Otherwise you could face a lot of jitter in your message timing. If you need busloads higher then 50 % the best method to achieve this is to use the write mult net function, which is able to handle 512 messages at a time. You can then continuously check the queue and reload new data if space is available. (for more information check the help for the function directly)

If you need channel db support with busloads >50 % (not really common) you could use a timed loop with sample rate 0.

DirkW

0 Kudos
Message 5 of 6
(5,257 Views)

thanks Dirk,

I'll go the software loop method. thanks to the power of the host PC, it seems using verly little CPU when I loop it at 10ms and for 10 messages. my actual application has 10 to 15 messages, most at 10ms rate.

I tried the the "net write multiple" the way Dirk mentioned, and the max frame rate is 830Hz --- mentioned in my previous post. I attached the vi. may anybody have interest to try if your can make >1000 frame/s rate, or find anything wrong with the vi?

0 Kudos
Message 6 of 6
(5,252 Views)