"Wait Until Next ms Multiple" accept DBL

[Chringel]

For some applications I would like to enter an update rate for a while loop with a better than 1 ms resolution (eg 15.4 ms). From one iteration to the next the update period doesn't need to be sub ms accurate. Over a longer period however the difference between 15.4 and 15 ms adds up.

It would be very nice if the "Wait Until Next ms Multiple" would accept a DBL at the ms input and control the update period on average with sub ms accuracy.

[Intaris]

You mean you want the funtion to automatically dither between whole-integer values in order to maintain an overall period?

Like 15,16,15,15,16,15,15 and so on to give 15.4 on average?

Could be interesting....

[Chringel]

Exactly!

[Intaris]

Aside fromt he fact that you could code this yourself I don't know how accurate this would be in the case of missing cycles due to the PC being busy.....

[Chringel]

Of course I can code this myself, I've done that already. It would be convenient if the "Wait Until Next ms Multiple" vi would do this for me.

If the actual time (t) of each iteration is compared to the time (t0) of the first iteration plus an integer times (n) the desired update period (dt), it can be done accurate enough. So compare t to t0+n*dt.

[PaulG.]

Why would we want this kind of control precision with no guarantee of more accuracy?

[Intaris]

Can't think of a use myself yet.....

[Chringel]

@PaulG: Convenience.

I recorded data from an instrument for more than an hour. The instrument had an output rate of 26.5 ms.

The instrument is connected to a larger system. I want to inject the recorded data into the larger system in real-time to observe the behaviour of the larger system. This data set can be used as a reference for changes in the larger system.

Although there is a nice vi that could be used to inject the recorded data into the larger system with a steady rate, this nice vi cannot be used since it does not accept sub ms periods.

I had to code something myself. It would have been convenient if a standard vi could be improved a little.

[ToeCutter]

No likey- a function like wait ms multiple should be close to the metal and not do anything 'clever' IMO. Also, extremely unlikely that NI will complicate and change the behaviour of a built in function.

[Brian_Powell]

Personally, I'd rather see this investment on the timed loop, since sub-millisecond accuracy is already supported there in LabVIEW Real Time.

It's been a while since I dabbled in this area of the code, but I think the reasons for limiting the function to milliseconds is that we use timers on Windows that only have millisecond accuracy.  (And of course on Windows, there's no guarantee of that accuracy.)

Given the investment needed to change how we implement the function, and given that there are workarounds (use an external timing source(*) or use LabVIEW Real Time), I suspect we aren't likely to implement this idea.

(*) I've never used an external DAQmx timing source for the timed structures.  Anybody have any experience with that?  How well has it worked?

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.