CAN XNET high speed custom device

[beavercreek]

the goal: a  CAN custom device that is capable of keeping up with 1M baud 50% bus load.  Keeping up defined as no frames dropped (missing).

1M baud 50% bus load would be ~4 frames /ms.

From what I understand the XNET Read (Frame CAN).vi uses queues and you will have problems unless you use XNET Read (Frame Raw).vi. 

"Due to issues with LabVIEW memory allocation for clusters with an array, this XNET Read VI instance can introduce jitter to a high-priority loop on LabVIEW Real-Time (RT). The XNET Read (Frame Raw) VI instance provides optimal performance for high-priority loops."

The XNET Read (Frame Raw).vi seems to require a predefined database to know what CAN messages to read.  The point of the custom device was to read/write ANY CAN frame without having to update a system definition (or database) between running several sequences.

So I THINK the solution to this is that the custom device must create a CAN database on the RT chassis (in memory) and the custom device must update this database while it runs based on information passed to it from a the sequence. (here is an example of in memory database examples\CAN Dynamic Database Creation.vi) The update could happen at the start of a sequence (each sequence is interested in its own set of CAN frames) and during the database update, losing some frames would be acceptable.

Does this sound like I'm onto a workable plan?

[inniwhoni]

Hi beavercreek,

The XNET Read (Frame Raw).vi shouldn't require an XNET database to be able to function. All you need is a valid XNET session which you can create dynamically with XNET Create Session.vi. Did you run into an error when using this VI that indicated you need a database?

Kevin F

Applications Engineer

[swbpnole]

I am current using/modifying this custom device:

https://decibel.ni.com/content/docs/DOC-21035

Read up. Maybe be what you need or you may be able to extend its functionality...

[beavercreek]

Hi Kevin,

Thanks for your response, looking at my original post, it would appear I misspoke.   You are correct it is not the raw frame that requires a database, but it is the single point session types (no queue usage) that require a database.  The reason for the interest in single point operation is this documentation:

Within NI-XNET, the session modes for single-point I/O are designed for use within high-priority loops. This applies to all four single-point modes: input, output, signal, or frame. XNET Read.vi and XNET Write.vi provide fast and consistent execution time, and they avoid access to shared resources such as the memory manager.  The session modes other than single-point all use queues to store data.

Although you can use the queued session modes within a high priority loop, those modes use a variable amount of data for each read/write. This requires a variable amount of time to process the data, which can introduce jitter to the loop. When using the queued modes, measure the performance of  your code within the loop to ensure that it meets your requirements even when bus traffic is variable.

Regardless, my efforts have changed over the last couple days of investigation since I've added some time measurement to the custom device and found that it is not the reading of CAN frames nor the post processing of that data that is consuming large amounts of time, but instead the time is lost between calls to the custom device (seems to sleep ~3ms) and something is also happening during the RT FIFO Read and XNET Write (Frame CAN).vi portion of the while loop.

Initially we had left the XNET Write (Frame CAN).vi timeout at the default (10s) which of course is ridiculous for a custom device, setting that timeout to zero resulted in no messages getting transmitted, which I believe could happen if the write queue is full.  So that is my next investigation, how large are the queue's and how full are they getting.

[beavercreek]

Hi Swbpnole,

I have seen the J1939 Add-On, downloaded and installed it briefly.   Mostly I was interested in which XNET Session mode and CAN read modes it was using.  I'm extremely happy that it has BAM capability and I have no doubt we will  be using it eventually.

I must confess I did not read enough documentation on the J1939 Add-On to determine if reading/writing arbitrary (non-j1939) CAN frames is possible from a stimulus profile.   Should I be looking at this documentation for that ability?:

J1939 Stimulus Profile Editor Automation Sequences

The instructions for use are contained in the J1939 Add-on Getting Started Document.zip.  Additionally, view the video named 5_J1939_Diagnostic_Channels_Automation.mp4 attached in J1939 Add-on Getting Started Videos_2.zip.  The attached file J1939 Stimulus Profile Example.zip contains the example profile and sequence files.

[swbpnole]

I have no experience using that piece of the project. However, I think it may be useful. Read up on it. Post questions in the support community forum for the product. There is one NI engineer who responds to questions about the addon there.

[beavercreek]

Hi all, just wanted to post a quick update.  I did investigate the CAN transmit Queue and found it generally empty:  QueueSize:24000;NumPend:1;NumUnused:999

My next step was to build 36 versions of the custom device engine.  Why?  well not having a really good understanding of custom devices and interaction with other parts of the system, trial and error seemed like a valid hunting method.

I created the 36 builds adjusting the RT FIFO Read and RT FIFO Write timeout at levels -1,0,5.  I also adjusted the RT FIFO Write "overwrite on timeout" Boolean.  That makes 18 builds.  The one additional factor was if the custom device should behave differently when the RT FIFO Read returns "empty" (hmm, i have no idea if that ever actually happened).

I then wrote a vi to call a sequence that uses the custom device repeatedly, looking for bad behavior.

The custom device is fairly well behaved with:

RT FIFO Read=5

RT FIFO Write=0

"overwrite on timeout"=true.

but I still hope to get it perfect.