XNET questions

[Luis_CT]

Guys,

Hope you’re all doing well. After spending significant amount of time in the Vector world. I finally got approval for an NI XNET CAN interface (yeeii!) and I’m exploring some of the driver functions. Currently I do all my CAN/LIN analysis in CANoe using CAPL and Vector tools and so far, to be honest it has worked well.

Now, as a LV developer I would like to start doing some of those tasks in LV rather than CAPL (with XNET). So, I have some questions.

1. In CAPL everything is handled with events (Messages, frames, signals, etc). Is it possible to have the same functionality with XNET with User Events? I want to avoid polling.
2. My XNET interface is USB and will run on Windows (no cRIO or RT PXI controller). Would that be a limitation for the type of applications I can develop?
3. I use CDD (CANdela) files a lot. I looked for official support of CDD or OBX files in LV but I don’t see anything from NI. How do you handle that in your applications?

Thanks and hope to see you in the next User Group meeting.

[Hooovahh]

I've never written any CAPL, so I can't say if everything it can do XNet can do (better?).  But I see no reason why it can't.  The only thing is you are going to have to do the work yourself.  If you want it to say "When you see this message, send out this message".  Well then you're going to have to program that. 

But because it is LabVIEW you can write your own wrappers and have it do whatever it is you want.  So if you want to work off of the Event Structure, this will mean spinning up an asynchronous loop that reads periodically, and then when something happens to generate a user event.  This would then be an event that you would register for in your main application.  You may want to read some of my CAN blog part 3, 5, and 6.  This won't cover everything XNet, but helps highlight some of the learning curve you should expect.

We have several USB XNet devices and I haven't done lots with it yet, but it seems to be quite capable.  Remember that lots of functionality like frame/signal retransmits, and reading can be done by the hardware.  Other CAN devices in LabVIEW usually are just single point read/write and can mean lots of extra work just to read signals, or simulate an ECU.

A while ago someone had a proof of concept for reading CDDs here.  I've had to update it over the years to try to work with more non-standard formats.  It's a decent start and just pulling out DTC descriptions and DID information is pretty handy, rather than having to hard code information that might change later.  NI should probably provide a first party solution, since they do have the A2L parsing functionality in the ECU M&C toolkit.

[Luis_CT]

Hi Brian,

Thanks for your reply. I will recheck your blog and the tool from TroyK and see if I get the diagnostic data (DIDs) I need for my application.

On the other hand, yes, an Event Structure would be the one to generate an event once the desired Signal or Frame appears in the bus but as you mention it requires a helper loop to poll the bus and parse for that specific trigger which could take a couple of ms.

In CANoe, a CAPL program represents an ECU in the network. Basically, if you would like to respond to a specific bus stimulus (signal, frame, etc) you only setup an on <event> action within the ECU, making it more deterministic. No additional processes are needed to parse the frame.

Example:

on diagResponse <diagnostic_name>

{

                /*MSG received. Do Something...*/

}

I’ll look at the XNET manual but quick question: Do you know if any of the XNET API functions can process these types of events directly in HW without the need of additional G code to get more determinism?

Thanks!

[Hooovahh · Accepted solution]

Well I mean in that case I would call the XNet Read with the session type being Frame In Queued.  This is a session type that only receives the frames requested.  The XNet Read on Frames has a Number to Read, which defaults to -1 (all) and a Timeout.  You can set that to have a timeout of say 1 seconds, and read 1 frame.  This VI will then wait a maximum of 1 second waiting for the response to have a frame.  If the frame comes in earlier than that the VI returns with that frame being read.

[Luis_CT]

Perfect. That should work. I guess I need to jump into the manual to know more about the driver. 

Thanks Brian!