vi under windows target - speed >1ms

[KWaris]

Is it possible to achieve the speed faster than 1ms for a vi running under windows target. All the data communication functions such as queues doesn't seem to be timed out in less than 1ms and I tried to monitor the loop rate using tick count function but these also monitor in ms scale and do not return value in DB format.

I will be amazed if it is not possible to run a windows vi as fast as 1us when the processor could run in GHZ.

Will appreciate comments on this. I am working on a high speed control application and it is not suitable to use the RT target for this application.

Kind Regards

Austin

[hooovahh]

Is it possible to achieve the speed faster than 1ms for a vi running under windows target. All the data communication functions such as queues doesn't seem to be timed out in less than 1ms and I tried to monitor the loop rate using tick count function but these also monitor in ms scale and do not return value in DB format.

I will be amazed if it is not possible to run a windows vi as fast as 1us when the processor could run in GHZ.

Will appreciate comments on this. I am working on a high speed control application and it is not suitable to use the RT target for this application.

Kind Regards

Austin

Couple things. Your processor maybe running at the GHz but that is if you are only running one instruction. There is tons of overhead when running in windows when compared to a microcontroller. I would say I could do many operations on a 4MHz micro faster than on a 4GHz windows machine, and more reliably. Which is why when I need determinism, and high speed I move to FPGAs or RT environments.

Windows is not deterministic, and should not be used for an application that needs to maintain timing less than 1 ms. What if the antivirus application decides to run a scan and slow down the PC? Or if Windows update decides to install a bunch of crap during a very sensitive time? There are many cases where Windows will not be able to maintain timing and will fail.

You can run a VI that has a loop rate less than 1ms. But the overhead associated with measuring that applications rate, will effect your timing and then may run slower. Quantum Mechanics is not my thing but measuring something can effect it so that the measurement is not accurate. Also your loop may run faster than 1ms some times, but again with Windows it may take more than 1ms the next time. There was some code posted on NI's forums that I can't seem to find right now that would calculate the number of clock cycles a VI takes to operator, and then using the CPU frequency would calculate the time it took. But keep in mind that doing these operations takes clock cycles and makes your numbers less accurate.

Also if you are trying to do something quick try to remove all of the extra steps that maybe in your way, like queues. There have been times where I had a nice wrapper written with queues or user events, but when I needed to do something fast, it was better to just do it in one VI than it was to pass data around to other VIs.

[KWaris]

I personally believe that such High Speed application should be done in RT and FPGA. I recently did all data acquisition(using DMA FIFO) in FPGA, then streaming data from RT to windows using network stream. It was all good. Then I was told to add some machine logic in FPGA, I did it but the built exceeded 100% resource utilization. I decided to perform this logic in RT.

So I ended up adding 5 timed loops all set to different priorities in RT and then I used Network-published shared variable to stream this data form RT to windows. But to no avail!

I found that there was a delay of at least 35 seconds before I started seeing some values on the operation screen( a simple HMI to display the status of the machine). And I was having further deployment issues.

I dont know what the right way to use RT target especially in CompactRIO.

I used the following method but it didn't quite work!

Data acquisition Data- Transducers to AI card to FPGA to DMA FIFO (target to host) to DMA FIFO (read) to network stream (write) and then reading it back on windows.

Control Logic- Limit switched to FPGA to RT to Networked Publish Shared Variables to HMI- but that really didn't work. (Sometimes, Variables wont update or show any change).

Will appreciate comments

Kind Regards

Austin

[Tim_S]

Is it possible to achieve the speed faster than 1ms for a vi running under windows target. All the data communication functions such as queues doesn't seem to be timed out in less than 1ms and I tried to monitor the loop rate using tick count function but these also monitor in ms scale and do not return value in DB format.

I will be amazed if it is not possible to run a windows vi as fast as 1us when the processor could run in GHZ.

Will appreciate comments on this. I am working on a high speed control application and it is not suitable to use the RT target for this application.

Kind Regards

Austin

What you are looking at is the timeout, not the time to run. A dequeue element primative operating on a queue that has entries in it will run much, much faster than 1 msec. A dequeue element will wait until the timeout with an empty queue.

I don't trust a Windows PC to run at better than 100 msec updates, and sometimes not even that. Anything you are trying to do faster should be moved to a more real-time or hardware-level device.

Tim

[mje]

The basic timing primitives and VIs that have timeouts function off a resolution set by the system timer which is controlled by the host operating system. Even on modern PCs, you'll at best get a system timer resolution between 10-20 ms. This is something LabVIEW inherits from the OS, I believe all non-deterministic operating systems have similar resolutions. I've done very little deterministic programming, and none of it in LabVIEW, but even then I was dealing with tick resolutions on a similar timescale.

The reason the system timer is so coarse is largely beyond my comprehension, but as I've been told it more or less boils down to scheduling. Having the scheduler decide what to run is overhead, and chopping the timer resolution up into finer increments means your scheduling overhead runs more often, chewing up a larger fraction of your processing time that is best spent executing other things.

All of that though has nothing to do with how fast a VI can run. You can get VIs to run in well under a millisecond. You probably won't get down to a microsecond though, there is some amount of overhead involved in a VI call (as is the case with function calls in any language). That doesn't mean you can't execute a chunk of code more often than a microsecond, careful placement of loops, use of inline VIs, and subroutines can make for some pretty impressive speeds.

However to get meaningful metrics off pieces of code like that you need to loop such that you execute however many times to get an appreciable amount of time passing, then divide the elapsed time by the number of iterations.

[Tim_S]

I found that there was a delay of at least 35 seconds before I started seeing some values on the operation screen( a simple HMI to display the status of the machine). And I was having further deployment issues.

I dont know what the right way to use RT target especially in CompactRIO.

It sounds like you have a solution that has issues and need to go back and learn more about how to implement the solution. RT and FPGA do not get implemented like Windows code as there are rules on the hardware and methods of doing things that you need to be aware of. For example, I know memory use is not the same on RT (I'm not knowledgeable enough about it to elaborate), and many of the Good Coding Practices in FPGA programming will take significantly more resources on the chip that what would be deemed "Bad" code when programming for Windows.

[mje]

Hmm, I stand corrected. The Tick Count (ms) primitive seems to be returning 1 ms increments to me. Has it always been like this? I swear I used to see granularity in the return value...

[ned]

Tick Count has always been in milliseconds. Get Date/Time in Seconds returns fractional seconds to greater precision than milliseconds, perhaps you're thinking of that.

[JamesMc86]

Hi Austin,

If you are doing high speed control the RT/FPGA are much better for this. Doing control ideally should be done on single point data, no queues as the introduce latency to the system but everything we do on windows tends to use buffers of some form to get the performance required for DAQ.

Perhaps if you post a little more information on your FPGA issues we can suggest some improvements to make it fit.

Cheers,

James

(null)

[crelf]

Windows is not deterministic, and should not be used for an application that needs to maintain timing less than 1 ms.

Quick clarification: Windows *is* deterministic, if your acceptable jitter is high enough. LVRT is more deterministic than Windows, but you can't say an OS is deterministic or not - it all depends on your use case.

[Yair]

Hmm, I stand corrected. The Tick Count (ms) primitive seems to be returning 1 ms increments to me. Has it always been like this? I swear I used to see granularity in the return value...

As said, tick count has always returned ms resolution. Get date/time used to have a lower resolution (in XP), so it would only update once every ~16 ms, but that has changed with either Vista or 7, presumably because MS stopped relying on old functions they had to rely on up to that point.

[hooovahh]

You can get VIs to run in well under a millisecond. You probably won't get down to a microsecond though, there is some amount of overhead involved in a VI call (as is the case with function calls in any language). That doesn't mean you can't execute a chunk of code more often than a microsecond, careful placement of loops, use of inline VIs, and subroutines can make for some pretty impressive speeds.

I was curious so I wrote a quick VI to see how fast I could get a loop to run that performs some calculation. Now this is a very simple VI that doesn't call a subVI (so no overhead there). But I wanted to see how fast I could get a loop to run.

Please pardon my crude code, but on my machine running 100,000,000 loops, each loop takes about 42 nano seconds to execute. Much faster than I would have expected, but again there isn't really much going on. As soon as you add any communication VIs, loop rate will increase.

EDIT: I removed everything in the loop and the loop now runs at less than 2 nano seconds...but again what good is a loop that doesn't do anything? Other than a dwell I guess, which won't be very consistent.

[mje]

Heh, I was just working off the documentation which states there's a small amount of overhead in calling a VI.

When you call a subVI, there is a certain amount of overhead associated with the call. This overhead is fairly small (on the order of tens of microseconds)

I don't believe it's constant though, likely involves how much stuff needs to be taken on and off the registers etc, but that's way out of the scope of my knowledge. Maybe that documentation was written in the days of the 486 and is a little out of date? Heh.

The code you posted above though doesn't call a VI, it's calling a primitive function. Slap the increment in a VI and you'll start to see the overhead come up. I just tried it and it's actually surprisingly low. I went from 30 ns per iteration when using the primitive to 100 ns per iteration when using a VI. I guess sub µs is easily done nowadays, forget about tens of µs as implied in the docs.

I'll note changing the VI to a subroutine gets execution down to 50 ns per iteration, almost par with the primitive but still a little overhead. Making the VI inline obviously gets rid of all overhead.

[KWaris]

.hooovaah, I wonder how you getting 42 nseconds by multiplying loop rate in ms seconds with 1000?

The thing is, one thing is obvious. We should rather not put anytime in a loop. The loop will run as fast as it could to execute. This is never going to stall the application. And perhaps best approach is to do what you did, find the minimum rate and then just add some more time for the update of the user interface?

Unfortunately, especially in windows where most of us may rely on the timeout inputs of the enqueue function to execute some code periodically, we are really limited to 1ms to timeout the queue. Otherwise, that piece of code which we include will not run.

Perhaps in the later versions, we could use a smaller number.

I apologize Hoovaah, you did the right thing. I am just doing the things a bit fast today without thinking.

[ShaunR]

I was curious so I wrote a quick VI to see how fast I could get a loop to run that performs some calculation. Now this is a very simple VI that doesn't call a subVI (so no overhead there). But I wanted to see how fast I could get a loop to run.

Please pardon my crude code, but on my machine running 100,000,000 loops, each loop takes about 42 nano seconds to execute. Much faster than I would have expected, but again there isn't really much going on. As soon as you add any communication VIs, loop rate will increase.

EDIT: I removed everything in the loop and the loop now runs at less than 2 nano seconds...but again what good is a loop that doesn't do anything? Other than a dwell I guess, which won't be very consistent.

Most of the overhead is the front panel control (of course). I get about 1.5ns without it and 40ns with it (still using the +1).

VI overhead is vastly over rated for this sort of stuff. Shove it in a sub-VI and you can get it down to about 0,3 ns