How to guarantee accurate starting time of each frame of a sequence?

[Britoa]

Looking at the profiler data, draw looks like it took the most time.  Try making your front panel smaller, without as much information (even for just one run, just resize the window to much smaller and run to see if you get better results)  Everytime you move a window or the mouse, Labview will redraw everything you went near.  Graphs, charts, waveforms all draw much slower, as do pictures.

[Christ0phe]

Ben: i have implemented your 5 proposals including disconnecting network. The only thing that very slightly improves my situation is to set Labview to run in priority=High in the task manager. Actually it reduces the peak value of my cycle time.

Britoa: I have reduce considerably the size of my chart and rerun several tests but with no change.

I am pretty sure that if I had enclose all my While code into a CIN I would not run into this issue. I have tried to replace my while loop by a Timed While loop in which I have increased the priority to 1000000 and fixed a dt but did not see any improvement.

How can I convert my while into a high-priority bit of code?

Thanks

[johnsold]

Local variables are slow.  Replace them with wires and shift registers.

Move any controls and indicators which do not change while it is running outside the loop.  Updating indicators takes time (the Draw time which was mentioned above).  Since the user cannot meaningfully interpret anything within the ~100 ms you are trying to achieve, this means all of them.

Put the reads and writes in parallel loops. Then any OS interactions with the hardware will not affect the timing of the main loop.

Lynn

[JÞB]

OK I'll bite-

Why are you spending days re-inventing the wheel?  As has been pointed out multiple times - the Windows OS is too "busy / undependable" to provide the timing tolerances for the LIN protocol.  A HARDWARE solution is required (there I go outside the box again )

Plug a NI-USB 8476 into your system and let the Amtel ATA6620 do the job it's designed to do!   Its internal uP is dedicated to the task of pushing data to and from the LIN phy layer in a deterministic manner.  And you even get the CAN API to interface back to LabVIEW. 

Of course- you could keep trying to brute force Windows behavior.  But I wouldn't bet on a robust and deployable software only solution.    The Voltage protection alone will save you any number of motherboards if somone hooks your solution to a 60V node

[Christ0phe]

Hello Jeff and thanks for your answser;

Right now I use the following hardware: http://www.kvaser.com/en/products/lin/usb.html and the related Labview drivers (CIN based) that Kvaser provides for free along with their products. No problem at all during all those years that I used their CAN based hardware and Labview libraries.

But the fact is that here I had to reprogram the LIN schedule table in Labview and that is where the issue is I guess.

I just need to make my loop less sensitive, I do not ask a precision of 1ms on my 100ms loop, 10ms would be enough. I cannot believe that the answer to this tiny thing is to go real-time !

Maybe to 'convert' the labview code into a CIN?

Thanks for your support

Christophe

[Yamaeda]

Your first implementation suffers from Execution time+Wait since execution and wait is in separate frames. Simply putting them in the same frame will improve results, although if absolute values are important windows is limited as mentioned.

/Y

[Christ0phe]

Yes for the first implementation. But like I wrote above:

LIN zoom v1.vi 182 KB

LIN zoom v2.vi 740 KB

LIN zoom v3.vi 200 KB

LIN zoom v2 and v3 bring very little improvement!

[Yamaeda]

The 3rd one still has Execution time + Wait syndrome. Simply put a "Wait X ms" within the executing frame and skip the wait frames.

/Y

(code wise the 3rd is the best)