too long duration in (timed) whlile loops

[stefan_hartmann]

hy there,

i am: routined labview developer, advanced course done, no performance course (not yet as it seems i need that).

programm: multi while loop event structure with command queues for each loop, plus one single elemnt queue for each loop running as a variable. network communication trought the queues is possible !. Several Hardware addons like PXI-Controller for Motion and Digital I/O communication, RS232-communication with several different controllers als separated loops. The software works also without connected hardware components.

problem: loop rate of "continous loop" should be below 5ms, but is around 15ms/iteration at the moment.

hardware: 2core computers, WinXP32bit, LabVIEW9

goal: improving loop rate of the "Continous Loop"

what has been tryied and tested:

ok i tried a lot of things, partly sucessfully.

- making subVI's reentrant as some of them are used a lot of times in each parallel loop (see VI Hierarchy)

- increasing subVI speed with code improvements, partly sucessfully

- analysing with profiling of the VI's

Question:

when i was profiling performance of my VI's, i recogniced that summarizing the "Continous-Loop" SubVI's duration does NOT correspond to the current Loop-duration. they are around 20 to 30ms, whereas they should be according to the number of runs and corresponding total time, at 3ms. this means it is factor 6 to 10 slower than it should be in my point of view. i really dont have an idea why this happens. the printscreen and its corresponding information is without an other iterating loop (just deque waiting) running.

i tried to get more into detail and did some tests and benchmarking with my continous loop. it showed that this additional time (latency? so high?) actually is not produced by the Continous subVI and also not from the deque part of the loop. it seems that almost all the loop time appears after the loop code is finished... and before the loop starts, somehow...

if you have any suggestions or information why this is the case, or if you even have ideas for improvements or references, please let me know.

attached you find printscreens of the corresponding program part. i dont want to public the whole programm to everyone. if you have ideas and/or need the code for own testing, please send an e-mail directly to stefan.hartmann(at)psi.ch.

best thanks in advance

[cirrusio]

Stefan,

Unfortunately, it is unclear what your actual code is doing given the screen shots that you have posted - there is no way to tell what you are dequeuing (or where from) or for that matter what the bulk of the program is doing given that it looks like most of the action is wrapped up in the subvi which takes that data from the queue.  5 ms execution time can be kind of tight given the jitter imposed by the Windows OS if you have any kind of computation occurring in your program.  Is there any way you could possible post the application?  You might get a more complete response if you did.

Peace, Matt

[Broken_Arrow]

To see if your queue is holding up the loop, change the function from Dequeue Element to Get Queue Status.

[stefan_hartmann · Accepted solution]

Hy there,

ok i found the problem. the long iteration time mainly occured because of a queue that had to load and write 100x100 string array several times per iteration. this was the reason why iteration time actually was measured so high and produced an additional delay per iteration, next to the subvi-times.

i solved this problem by now using 100 queues with 1x100 string array, where i actually just need one queue per iteration and not the 100x100. This results in iteration times of around 2ms!

cheers