XNET Write (Frame CAN).vi Issue?

[Daryl]

So the 1st time you write a frame to the function "XNET Write (Frame CAN).vi", it takes about 16ms for the function to write to the bus.  Subsequent calls to this function will not have this delay.

 

Is this a known issue?  Is it a handy feature of this function?  Or am I just doing it wrong (this is usually the case)?

 

Please see the attached VI's and let me know what you think. (Labview 2014, XNET 14.0)

 

Thanks.

delayed write issue.vi

work around.vi

Edited November 23, 2015 by Daryl

[hooovahh]

Why does it matter?  And if the answer to that question is because you want to send frames at a periodic rate, then I'd say you are doing it wrong.  If timing matters, don't use software timing.  

 

The same goes for writing to DAQmx analog outputs.  If you are trying to make a clean nice sine wave on an analog output, you wouldn't do it by setting each output as a single point AO value in a while loop.  Your timing just won't be consistent due to jitter.  What you would do in this case it make the full waveform of the output, put the whole output on the hardware buffer, then tell it to play that waveform and repeat it.  Here the hardware controls the timing.

 

You can do similar things with XNet.  If you must set a periodic message every 10ms, then tell it to send the signal (or frame) every 10 ms, and then update it's value when you want, and the next time it sends it, it will send the new value.  Or if you want to build a queue of signals (or frames) to go out one after another 10ms apart you can do that too, and before the queue is empty you can add more to the queue.

 

These different CAN modes are the Stream, Queued, and Single-Point.  Open the context help and it shows nice diagrams about how signals and frames are read or written in the different modes.  The database you select defines the rates of the signals (or frames).

[Daryl]

I have to send 1 diagnostic request (CAN Frame) within a few milliseconds of an analog trigger to reproduce an issue.  I am not trying to use this as a timing mechanism for a periodic message.  The work around VI I posted does what I need it to do but I was wondering if this was some kind of issue.

[hooovahh]

Not sure it is really an issue.  I can't say for sure but I suspect the first time you try to do something like this, some DLL dependencies are loaded or opened the first time and cause some kind of delay where every subsequent write doesn't have that.