NI CAN Frame API for parallel VI's

[PatrickMiller]

I posted this originally in the Delacor toolkits section but Darren essentially answered my concern that the NI CAN Frame API functions are calling DLL's which might act serially even if I choose shared preallocated:

"I was using the VI analyzer on my project and noticed that the NI-CAN library functions are non-entrant by default. Since i'm going to have 12 CAN modules(clones) open/read/wrote to asynchronously, if they are all using the same non-rentrant CAN read function it won't have any real parallelism to it correct? They will have to wait for execution in line. 

My question is should I be changing this base NI-CAN functions to shared clone reentrant? And If I do that will that also break any projects that are using the standard non-rentrant CAN functions. Can I unlink the CAN library for just this project and not break the functions pallete CAN library?"

Is there a way that I should be approaching having 12 NI CAN 8473's with separate CAN buses running in parallel asynchronously? If they are all calling the same DLL then they will still always get stuck at that point and have to wait in line. We do plan on upgrading our software using the newer XNET API, its just taking some time and would require new hardware from the 8473 to the 8502.

I currently have 12 asynchronous DQMH modules (12 clones) which I thought were working correctly and in parallel. They all call this CAN-read subvi attached.  

[PatrickMiller]

I guess all I'm asking is what happens if you have 12 clones all calling the same DLLfor CAN read at the same time.

[Hooovahh · Accepted solution]

I was pretty surprised to see that this read VI isn't reentrant, but you are right.  If you are sitting and waiting to read on one CAN port, it will take time to read the data, convert it to the cluster and return it, and in that time more frames will be coming in on the other ports.  Now depending on the time it takes to do a read, and depsending on rate that the other ports are seeing data (baud rate and throughput) this might not be a problem.

I had 12 NI-CAN devices plugged into a single USB hub, going to a single USB port on a PC and reading all of them was fine.  Of course this was low speed CAN (maybe single wire I can't remember), and we were only interested in the single point reading, and any duplicate frames, and frames from IDs we didn't care about, were ignored.  This helped with throughput.  

My gut reaction is that things might be fine depending on the application, and what you want to do with the data.  If you are logging all raw CAN frames, from 12 buses at once, with high throughput (80% or higher) then you are probably going to run into issues where you can't read the frames fast enough, and a buffer overflow will occur.  But if you are just trying to display a small set of IDs, and only their last values you might be fine.

If you change this VI to be reentrant and call the DLL in parallel things might work fine, or you may crash the DLL or application.  Only NI can say for sure how it will behave.

[PatrickMiller]

Thanks for replying hooovahh.  I only found this issue because I used the VI analyzer (learned about it from one of your user group presentations), so I actually didn't see any issues that point to this.

1. I'm not logging any frames, I only care about "what is your latest status at this moment".

2. Data rate is 500k with a CAN low and CAN high wire.

3. I am doing a lot of CAN writing which also likely has a similar DLL call. Writes are only happening about every 10ms x 12 clones.  

Since i'm not really having any issues, i'll just keep it non-reentrant until I see an issue.

[Hooovahh]

Good idea, and good luck.  XNet hardware is much more capable, and can handle all kinds of situations with less software overhead but has a learning curve that is difficult.  Especially if you are used to the relatively simple NI-CAN.  I have a few blog posts on XNet session types if you do ever get some of that hardware.

[PatrickMiller]

Yea, we're going to have to move to Xnet due to the obsolescence of the USB NI-8473. I first learned using Xnet following your blog posts and I noticed that most of the issues I have now are solved using the Xnet API. I also like that it can offset a lot of the functions into the hardware instead of software side.

Thank you for helping with this!.