03-11-2025 03:13 PM
So I am investigating some flashing code used on CAN and XNet hardware. I have vFlash with Vector hardware and it performs the flash in about 2 minutes. I wrote similar code for XNet hardware in LabVIEW and the flash time is about 2 minutes and 20 seconds. I figured the extra time is likely just my slightly less efficient code and didn't look into it further. Then I ran the same code on an embedded NI target running Linux RT. Then the flash time was roughly 3 minutes. I thought it was odd so I started looking a the CAN traces to find where different methods differ in timing.
It turns out the main issue I'm seeing is that the XNet Read function, takes longer to return than I'd like. I will write a bunch of XNet frames and they go out one at a time correctly, and then I need to wait for the ECU to respond. And this will take about 3ms longer on RT than the vFlash process takes. Here is a graph. Red is the extra time RT needs from the vFlash baseline, and white is the extra time Windows needed from the vFlash baseline.
I started digging into my code to try to read the CAN frames faster when I came across a behavior that I don't expect and hopefully one NI can help me with. I've tested the XNet Read on two different session types. The Frame In Stream (then filter for the frame I want) or the Frame In Queued only looking for this one frame. In both cases I had the Number of Frames to read set to 1, and the timeout would be set to 4s.
But what I found is that if I want to get the XNet Read function to return faster, I need to put it in a while loop with a 0s timeout, and -1 frames to read, then keep looping until the frames returned isn't an empty array. This isn't what I expected. Can someone from NI comment on this behavior? That the fastest way to get frames back from the hardware is to use the Read in a loop, as apposed to asking it to return once a frame is read. In the software I write I will sometimes have a similar timeout feature. When I do I will use a queue to return as soon as the data is available. If you put a read from one of my APIs in a loop reading it will be slower than specifying the timeout and number to read because it is essentially polling the results instead of waiting for them. Assuming this behavior is okay, is there any expected downsides to running a hungry loop reading over and over again? Thanks.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord