Loop timing in PDAs

[Wirer]

I have noticed that if you put a 'Wait Until Next Ms Multiple' or 'Wait (ms)' into a loop of PDA VI you can obtain an actual loop time of 200ms at minimum. This means that you cannot make the loop run at a constant rate less than 200ms by using these functions.

Using these delays is generally recommended in LV to not let a certain process (loop) consuming too much CPU time. If these functions are not usable for < 200ms, how to achieve a constant loop time less than 200ms without using delays? If the delays is not used, the loop will run as fast a possible. Some kind of delay/wait is absolutely needed to achieve < 200ms.

thanks,

Wirer

[Matthew C]

Hello Wirer,

Thank you for contacting National Instruments.

There are some known issues with the wait functions not waiting the specified amount of time on PDA modules. However, these issues are slightly different than the problem you are experiencing.

I am curious to know exactly how you are timing the execution of your loops, and are you using any kind of PDA emulator? Furthermore, if you are executing lengthy or complex code with each iteration of your loop, it is possible that the limiting factor is not the wait functions, but rather, the actual speed at which the PDA can execute your code.

Try implementing a test program that does not execute any code within a loop, and see if that test program also fails to wait a specified time less than 200 ms.
This should shed some light on the source of the problem.

Matthew C
Applications Engineer
National Instruments

[Wirer]

Thank you for your response,

In my tests with timing I have built a loop as simple as possible and there are no extra calculations that would be the reason for the high loop times.

In practice the code inside the loop consists of 'Wait until next ms multiple' having 50ms constant wired on it and a timer which calculates the actual loop time in milliseconds (I use shift register to remember previous time value). There are no extra calculations done within the loop.

With this setup I will get 200ms loop times at minimum, even if the constant ms value is less than 200ms. By setting the constant ms value to 0 the loop will iterate at a very high rate (thousands of iterations per sec) but it consumes all its CPU time.

We would like to have something between 0 and
200ms and it seems that a cannot have it with 'wait until next ms' function.

Is 'wait until next ms' suppose to work in PDAs with values less than 200ms???

[drew1005]

I am having the exact same issue.  I have a wait vi with a 5 ms constant attached that takes almost exactly 200 ms to execute.  If I delete the wait vi, the program runs full speed with minimal delay.  I also tried the Wait until next ms multiple vi with the same result.  My impression of Labview PDA 7.1 is that it is VERY VERY BUGGY.  I'm anxiously awaiting my copy of Labview PDA 8 and hoping that it works much better.

[drew1005]

I upgraded to Labview for PDA 8.0 and the bug in the Wait vi is still present.  I can't consistently acheive a delay less than 200 ms with the Wait vi.  I did notice that the delay isn't always 200 ms.  Sometimes it is 100 ms.  Could this have sometime to do with the built in latency of Windows CE?

[HDRM]

Hi,

I experienced the same problem even on our newly updated LabVIEW PDA 8.0.1.

The time for one loop execution is 200ms, sometimes 300ms.

Best regards,

Manuel

[marshaun]

Same problem here.  Loop timing resolution is ~200ms (occasionally 100ms).  This is a SERIOUS limitation of the PDA module.  Loop timing is fundamental to nearly all LabVIEW programs and to not have access to sub-200ms loop times is a major problem -- it affects my application dramatically.  (How does one smoothly update a graphical numeric display?  200ms is far too coarse for my application.)

For an issue with such widespread impact, I would expect NI to mention this limitation at least in the website documentation if not in the official documentation, but this forum thread is the only mention I see.

And as my tests (and others') have shown, this is clearly not a case of running out of CPU/Memory resources.  It appears to be a case of "wait" or "wait until next multiple" timing resolution.  When a "0" is sent to either of these functions, the CPU can execute significant amounts of code VERY quickly, but with the usual problem of starving other tasks.

Would any NI engineers care to comment?

Has anyone else found a workaround?

Thanks,

Shaun

[drew1005]

I'm using a rather crude workaround.  I have a sub-VI which simply compares the start time to the current time (with tick count.vi) and loops until the delay time is met.  I feed it the delay time as an input.  I've found that I sometimes have to adjust the delay time input to get the value of delay I need (I'm not sure if this is still true with LV 8.0).  The amount of time I delay isn't a very critical parameter, so I can live with a little uncertainty.  I wouldn't recommend this for really critical timing (and of course the minimum resolution is 1 ms).  I'd be interested in hearing other people's work arounds.

What I really don't understand is why my work-around works and the built in delay VIs don't!  As mentioned previously, it would be nice if NI would respond one way or the other on this issue.  If they don't have a fix, at least they could acknowledge the issue.

[tst]

I've recently run into some other timing issues with this industrial PDA running ce.net similar to the one described in this thread - whenever there's a wait the application would run very slowly (I'm talking many seconds, not 200 ms) and would only run normally when the screen was tapped.

The company which makes it suggested it might have something to do with the function used to create the wait and that it might be caused because of the PDA going into a mode of operation with much lower Hz (not sleep mode) very quickly after the user stops interacting with the device.

During my investigation I tried using basically all of the timing devices available in LV and they all had the same result, so it seems this is the same for all options, but I would try an event structure with a timeout just to see if it works on a PDA where the timing is OK.

The only workaround I was able to find for that device was to implement my own wait - a VI which had a loop with no wait which would check how much time has passed and then return. I only did a very quick test, but it seemed to suggest that this loop took all of the CPU resources. I didn't run any serious tests, though, so that might be another avenue to look at.

Another option I just thought of would be to try calling a DLL function which would implement the wait. This would obviously require writing some simple C code, and I don't know how fast the PDA module can call DLL functions repeatedly, but it's definitely something worth looking into and might provide a solution to our own problem.

I would definitely like to hear a response from R&D - which timing mechanism was used in the underlying code? Is it dependant on the speed of the CPU? Which workaround would be best for us?

[drew1005]

The hardware that I'm using and having problems with is the DAP CE5320X handheld.