Labview Problem: Sluggish Program = Loss of data

[labuda]

Hi,
I wrote a program which works as follows.
A Temperature Acquisition Hardware sends me information via RS232 at exactly 4Hz.
An MRI scanner sends me a sync pulse every 3 seconds to coordinate my software with the MRI, via a 4350 Digital I/O card.
My program records all the temperature data, the time of each sync pulse, and the value of a slider bar controller by a user (using keystrokes 1 and 3) and writes it to file.
Here is my program:
http://www3.sympatico.ca/labuda/PhaseII.llb

I don't expect anyone to understand what is going on, but can anyone tell me why this program sometimes works, and sometimes acts really sluggish, and therefore misses some of the sync pulses from the scanner (which are 1 second long, 3 seconds apart). The system resources are always 99% allocated to Labview, even though this program is not very complicated. The temperature data are buffered, so i get all of them, but the timing between them varies. Sometimes the buffer piles up for a few seconds and then gets recorded quickly.

The computer in question is a new Toshiba (1 month old), running only labview 7.1. So there should be absolutely no hardware limit.

As a test, I made a VI with one while loop and a stop button. Simple, but labview then hogs 99% of the cpu processing. Is this normal?

Can anyone tell me if there is anything immediately obviously wrong with my program? Any suggestions on solving this problem would be very appreciated.

Thanks
Aleks.

[altenbach]

I can see many potential improvements everywhere, but a few things really stick out:

1. In the left center of the diagram, there is a small while loop that updates the time display. This loop does not have any wait statement and thus runs millions of times per second, consuming all available CPU, doing nothing else but rewrite mostly the same data to the indicator. Place a 1000 ms wait in it!!!
2. Your graph has severly overlapping elements. This makes all FP redraws much more expensive.
1. Resize the graph so it fits into the clear area
2. Move the graph legend off the transparent graph background to back where it was, but now outside the graph.
3. Resize the plot area to the old size.
4. etc.
3. Frame#: it is really bad form to have two different indicators named the same. This leads to programming errors especially since it makes it difficult to keep the local variables sorted out.
4. The "Frame#" (1&2) and "Sync Pulse #" tracking should be done with shift registers instead of the tedious "local variable read--increment--local variable write", etc.
5. You have way too many coercions, e.g. SGL indicators for DBL arrays, comparison of a DBL with a I32, etc.

I highly recommend to tear the entire thing down and rewrite it as a compact state machine. The diagram would nicely fit on one screen. 😉