What is going on "under the hood" of the 'Wait Until Next ms Multiple' vi?

[Edjsch]

Altenbach,

Oops, I stand corrected. Thanks. Yes, LabVIEW is a "parallel" language, unless forced to execute otherwise. One place I use the Wait (ms) is, for example, when writing and reading from a serial port. NI's example is to do a VISA Write, then Wait in a sequence structure through which the VISA reference wire is passed, then do the VISA read. Here a Wait is desired as opposed to the Wait Until Next ms Multiple.

In my application where I need a time stamp delta from where a test started, I use the Wait Until Next ms Multiple so it is very close to the rate that the user set. I.e., if the user wants to take a reading every 100 mS, the time stamps will be very close to 0.100, 0.200, 0.300, etc., while with the Wait (ms) it varies more.

What I confounded was item 2 in this example: http://www.ni.com/white-paper/4120/en: "If the wait executes first, the whole thread will sleep until the Wait (ms) is finished, and the code in parallel will not execute until the Wait (ms) is finished. The resulting loop period will be the code execution time plus the milliseconds to wait time."

Anyway, since I got your ear, do you have any idea of how LabVIEW achieves close to 1 mS resolution on their wait functions?

Ed

[altenbach]

---

@Edjsch wrote:

"If the wait executes first, the whole thread will sleep until the Wait (ms) is finished, and the code in parallel will not execute until the Wait (ms) is finished. The resulting loop period will be the code execution time plus the milliseconds to wait time."

---

This seems to be specific to LabVIEW RT AND time critical priority setting. This is probably a very special case. Sorry, I have no expertise here.

[Edjsch]

Altenbach,

Thanks for your input, as always. I did verify what you said about Waits executing in parallel in this previously linked to example: https://decibel.ni.com/content/docs/DOC-14149, in case any readers doubt this. The loop in the first tab (Case 0) has a Wait (625). I added 2 more Wait (500) vi's. The test results were identical, confirming that the longest wait takes priority and they all execute in parallel, as you said. Kudos.

In my serial port application that I mentioned, I do a write, a wait, and a read. That is in a larger loop so I can optionally write and read the port any number of times. If I use a Wait in that big loop, that executes after the Wait while reading, so in that case they execute in series. Therefore I use the Wait Until Next ms Multiple so the big loop executes on a heartbeat (hence the metronome icon for that vi), which is my desired functionality. This is what I was getting at when I misspoke. Thanks for the clarification.

Ed

[johnsold]

If your serial port device uses a termination character or a known number of characters to be sent after each write, you can eliminate the waits and let the VISA Read function handle the communications as fast as the data is available.

Lynn

[Edjsch]

Lynn,

Yes, that's correct, assuming you have the Timeout property in the VISA Configure Serial Port The VISA Read vi set to a value greater than the worst-case response time of your serial device that you are trying to read. (The default is 10 sec, which I find too long. I set it to 1 or 2 seconds.) However, if, for example, you set the Timeout to 0, it will return immediately and you will have not read any data! If you look at NI's example "Basic Serial Write and Read", they use a delay (Wait).

However, we are getting far off the topic of how the Wait Until Next ms Multiple vi is implemented. We still don't know. But thanks for your input.

Ed

[Jeff-P]

Hi Ed,

In general, the Windows Performance Counters (see msdn here and a discussion of this same topic here) are able to give sub millisecond timing, and using this in conjuction with the system clock can be used to give better resolution. I suspect we are doing something of that nature under the hood. There is in fact a VI called the High Resolution Relative Seconds.vi located in the vi.lib\utility folder which can be used as a sub millisecond high resolution timer. As has been mentioned previous times in the thread, even though we can give that kind of resolution, it is not good to rely on these functions for execution timing of your software on windows since LabVIEW can be interrupted at any time.

Hope that helps.

Regards,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments 

[Edjsch]

Jeff,

Thank you for your reply. Yes, I'm aware of this. See my original post where I said, "There is the "multi-media" timer (now the HPET or High Performance Event Timer"), but it is meant for sound and video at the driver/kernel level, and not for the UI level, as LabVIEW or C# are."

I don't need sub-millisecond timing at the UI level, which as you say is not really possible. But close to 1 mS is a reasonable target for modern CPU speeds. LabVIEW attains as close to that as is possible running under an OS such as Windows. The question is: Is LabVIEW using the Windows System Timer, the one with supposedly 0.5 to 1 mS maximum resolution depending on OS (see my first reply), but which running a .NET application such as C# or VB, gives only 15.625 resolution for their timer control tick event or the sleep function (which is analogous to Wait (mS)).

Even with my LabVIEW application running (in the development environment), if I query the performance timer with that Set Timer Resolution application, it indicates 15.626 mS. So it appears that LabVIEW is not setting it to 1 mS. So how does LabVIEW do it? Can you ask the developers? Thanks for any additional insight you can provide.

Ed