Loop timing in PDAs

[Greycat]

After reading this thread I decided to do a little test on my PDA (HP Hx2490) running WM 5.0.  Here is what I found ... using an empty loop with just a calculation for displaying the timing of the loop, calling the wait(ms) function with the following parameter ->

< 100 ... takes between 200 and 220 mS

100 - 200 ... take between 300 and 320 mS

200- 300 ... takes between 400 and 430 mS

300 - 400 .. takes between 500 and 530 mS

Everyone of these settings has an occasional spike about + 100 mS

This doesn't seem to be simply a  minimum time the function needs to take ... there seems to be some other issues.  Anyone else get similar results? What are the known issues with this function for the PDA?

Greycat

[Greycat]

Here is another crude work around .... use an event structure in a while loop ... set the event timout to however longyou want to wait and this will delay things for you .. the only drawbacks are that it is not exact ... seems to take a little longer then what you set it too and it does have the odd spike of time it takes to execute (this might be my system only though) ... also you could use a couple of nested for loops and a particular operation - say a division operation - and simply set the numbers until you have as much delay as you need (I used a for loop that completed a simple division operation and iterated 1000 times, nested inside another loop that iterated 200 times - this gave me a delay of about 40 mS)  ... now after saying all this, there is one major draw back to timing in this way ... you will retain cpu control for most of the time you are operating and therefore not allow the cpu to work on anything else while you are running your labview app.  This is OK for some, not ok for others.  For example, the user input on my PDA will not come up right away when pressed using this sort of program flow ... it will take it at least 5 seconds  and the same amount of time to get it to disappear too.  Anyhow ... just a couple of thoughts on work arounds for now. 

Greycat

[Andy F.]

Hey all.  I tested this and did find very similar behavior to what was described on this thread.  I used a VI that I assume is similar to Greycat's (Tick Counts around a Wait Until ms Multiple) on the PocketPC Emulator and was able to get similar numbers using LabVIEW 8.  I will report this issue to R&D.  Thanks for finding this and doing such rigorous testing!

Thanks!
Andy F.

[tst]

Andy, I would appreciate hearing back on this since this a real problem for me on the device I mentioned - assuming I could implement my own non-CPU-hogging wait using a DLL, I would still probably be stuck with any other functions which use timeouts (event structures, TCP primitives, queues etc.). In that case, it would not be a matter of simply having low determinism under a second, but of having a program run very slowly.

[Andy F.]

This has been reported to R&D (#3W4C2PG) for further investigation.  A possible workaround would include using the timeout case of an event structure.  We currently do not have a timeline on when future status updates will be made for this issue.  We appreciate your feedback!

[Greycat]

OK ... this has just become a major problem for me also ... I am required to have syncronized time tracking with an autonomous instrument (up to hours) ... and these functions not working makes this pretty much impossible ... since the wait functions are not working you would think that one could use something around the event structures, but these seem to have variable timing for execution so this is not a viable alternative ... So, I to would like to be kept in the loop (no pun intended ) ...

Greycat

tst ... if you find a solution using a dll or anything else that can give you accurate delays, let me know please.  If I find anything, I'll be sure to let you know ... later ...

[tst]

---

@Greycat wrote:

tst ... if you find a solution using a dll or anything else that can give you accurate delays, let me know please.  If I find anything, I'll be sure to let you know ... later ...

---

I'm not working on this at all the moment, so don't expect anything from me. My point was simply calling a DLL which will only include a wait statement of some sort (which I'm sure is available in eVC). Since eVC comes with LV PDA (and I think is free) that should be fairly easy.

The main problems I see with it is that DLL calls are sure to be single threaded, so waits in different loops may cause problems and that (at least for the specific PDA where I have that specific problems) none of the LV timeouts (events, TCP primitives, queues, semaphores, etc.) don't work. This would probably constitute a serious problem in TCP communication where you don't know the exact length in advance and have to work on timeouts, but I don't think I tested it yet. If the timeouts work fine for you then I would probably use them.

[xingwei]

Is there any solution from NI R&D group for this bug?

I tested in LabVIEW PDA module 7.1 and 8.0,  and got the similar results. The minimum time delay in PDAs is 200ms.

[marshaun]

I've heard nothing other than that it was reported to R&D, four messages (and two months) back.

Shaun

[THailey3]

This was reported to R&D (# 3W4C2PGI) and was fixed in LabVIEW 8.2 PDA. Here is a link to the current evaluation software download for LabVIEW.

Thanks!