What are the advantages of NI-XNET over NI-CAN

[KavehV]

Assuming that I'm only interested in CAN, are there specific advantages to going with NI-XNET over NI-CAN?

[Gibson]

NI-XNET interfaces combine the performance and flexibility of low-level microcontroller interfaces with the speed and power of Windows and LabVIEW Real-Time OS development. Designed from the ground up for performance and ease of use in demanding applications such as hardware-in-the-loop simulation, these interfaces work well in high-signal-count, low-latency environments.  

The key technology behind the performance of NI-XNET is the NI-XNET device-driven DMA engine. This patent-pending technology reduces system latency, a common pain point for PC-based CAN and FlexRay interfaces, from milliseconds to microseconds. The engine works with onboard per-port processors to move CAN and FlexRay frames and signals between the interface and the user program without CPU interrupts, freeing host processor time for processing complex models and applications.

refer to http://zone.ni.com/devzone/cda/tut/p/id/9727 for further details on NI-XNET

[labviewman]

Are the NI-XNET CAN devices capable of loading the bus to a 100% level, which the NI-CAN devices are incapable of?  If so, can both ports on the card do this at the same time? 

[Bill_in_Detroit]

I have used several NI PXI 8512/2 XNET cards to read and write CAN frames on networks operating @ 500 KBPS with 95% bus load according to Vector CANoe statistics.  I am sure this can be extended to at least 99% without too much trouble. Both ports can be used as they each have their own dedicated hardware / software buffers.  You will be surprised how effortlessly you can queue frames to be sent and how quickly the hardware responds to received frames if you are familiar with the previous NI CAN technology, especially the NI cRIO-9853 cards.

Now the disclaimers:

I used LabVIEW RealTime 2009, an NI PXI 8106 embedded controller and an NI PXI-1044 chassis.

I spent at least a week optimizing the code to get rid of many timing issues using the Real Time Execution Trace Toolkit before I was able to finish my design.

The CAN messages were all J1939 and were generated by Vector CANoe.  Of the many J1939 CAN frames some used the BAM and others used the CMDT transport protocols.  I verified the 95 % loading by capturing several seconds of data with Vector CANoe multiple times and did not see any missing frames.

[O_Proulx]

Hi everyone,

I really like Bill's disclaimer.  This kind of disclaimer is always attached to performance questions. 

I suggest you look at this document if you have more questions on XNET performance.  We have performed several benchmarks to measure performance there.  Seeing as there are so many variables in a CAN system and so many ways to use CAN, we also tries to isolate different types of performance testing and explain the reasoning behind each test.  As in Bill's system, we also use a consistent test system.  The nice thing is that we provide the test suite (in LabVIEW 2009) so you can try and reproduce results on your own system (you need a 2 port card in most cases).

I hope that helps. 

[Bill_in_Detroit]

Olivier:  Thank you for the comments about the disclaimer in my recent post here.  While re-reading the post, I realized that I mis-stated one substantial fact, and that was the network speed.  I have worked with high speed CAN for so long I automatically stated 500 KBPS as the network speed I used to achieve the 95% bus loading.  However, in this case I meant and should have said 250 KBPS. It is possible to run J1939 CAN at 500 KBPS (I haven't tried it) but the SAE has not as of this writing adopted 500 KBPS as a bus speed for J1939.  As J1939 CAN frames are (to simply state it) merely CAN frames filled out to a full 8 byte data package (albeit with an extended 29 bit arbitration ID vs the standard 11 bit ID of high speed CAN) and having examined the information Olivier pointed out (almost 9 months ago) I have no doubt that the XNET cards can deliver the high performance required to achieve near 100 % bus loading at the higher network speeds.

Now for more disclaimers:

I have exchanged emails and spoken with Olivier and others at NI at length about their CAN technology and have encouraged them to push the limits so those of us out in the field can continue to stay ahead of the competition using our favorite tool, LabVIEW.  I have received no compensation for my views on this matter.  For those of you that want to put my experience into perspective, I have worked with LabVIEW for 16 years & CAN for 5 years.  My compensation comes from being able to get the work I am given done on time and under budget (usually ahead of time) - and I couldn't do it without LabVIEW and the support provided by National Instruments application engineers and the members and contributors to these forums.   Thanks!  

[Doc_Holiday1865]

Don't take this the wrong way, but if it's 500kbs, it's not J1939.  The J1939 standard specifies 250kbs. 

I would also like to say I have run the NI-CAN USB dongles at 1Mbit/sec at 95% busload, verified using Vector Canalyzer.  You have to make good use of the send and receive queues, and keep the loop times tight.

[Bill_in_Detroit]

Doc:

My experience has been such that when I see someone write "Don't take this the wrong way..." it reveals a little of the mindsight of the writer and I have to wonder what they really were thinking.  However, if you had read the note immediately above your last post you would see I corrected my mis-statement.  "While re-reading the post, I realized that I mis-stated one substantial fact, ... in this case I meant and should have said 250 KBPS."

[Doc_Holiday1865]

Bill,

I did read that, and though I replied to your message, my reply was not directed just to you.  It seems that I have seen quite a few J1939 posts with baud rates other than 250kbs.  Perhaps I am over sensitive.

I should also say that when I ran the USB dongle at 1Mbit, I didn't run it for more than a couple minutes.  I would imagine that after some time period, you would run out of "buffer" because of the 480kbs USB limit.

I also would like to point out that you should never, in practice run CAN at even 80% bus load.  We have a prototype vehcile here and it hovers around 80% bus load, if you get a couple errors the bus tends to crash.  I don't know what the actual recommended practice is, but I have a feeling it's less than 50%.  But I'm not sure.

[labviewman]

I have a few comments:

1) I have used USB NI-CAN devices at 1 Mbps to receive data on a 100% loaded bus for hours at a time w/o any errors (sending data is limited to 70%-80% bus load but there is a bug in NI-CAN in sending data for extended periods and using multiple threads to write to NI-CAN. NI is aware of the issue and working on a fix).

2) USB running at 480 Mbps can easily keep up with CAN running at 1 Mbps (480x bit rate), but keep in mind you can't compare bits on one bus to bits on another (as different as apples and oranges)

3) I co-authored a paper (still in the approval phase) on using CAN running at 1 Mbps using 8-bit micros that 100% loaded the bus using dynamic priorities to ensure high-priority msgs would be sent by their scheduled deadlines (worked quite well).  Having said that, at least in automotive, they usually keep lus loading to less than 30% (then add more buses ) and do not use dynamic priorities (I don't think anyone does unfortunately)

4) If you are getting any error on the bus (i.e. CRC, bit stuffing), you have other issues such as excessive stub lengths, insufficient shielding, excessive bus lengths, or other cable-related items.

Todd