03-28-2007 04:41 PM
03-29-2007
03:39 PM
- last edited on
05-16-2025
09:09 AM
by
Content Cleaner
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
03-30-2007 09:20 AM
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
04-02-2007 12:51 PM
04-03-2007 09:23 AM
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
04-03-2007 11:28 AM
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?