This vi slows down to an unusable speed with data.

[dj143]

Please take a look at the attached vi. Although I have not included everything to run the vi, I'm hoping you can look at it and see what I can do better. If needed, I can include the subvi�s and some sample data. After the main vi acquires the data, it is all displayed with this analysis vi. Unfortunately, when this vi runs with a lot of data, it slows the computer down to the point where it's very difficult to use. (It does not crash the computer.) When I say a lot of data, I�m referring to a Data Log file size as large as 37.9 MB which equates to 806,400 samples. Even a file size of only 1 MB essentially shuts it down. (very discouraging) I have tried running the array manipulation functions in th
e initialization sequence, but that does not help. The other parts of the main program run well, including the data acquisition. I�m using LV v7.1 with Windows 2000. For the computer, I�m using a 450 MHz Pentium 3 with 650 MB ram, and there�s over 32 GB of free hard disk space. Only this vi is running on the computer. Thank you as I�m anxious to see a better way process and display the data.

[altenbach]

You do a lot of unecessary work at each loop iteration. You should be able to get rid of most property read/writes in the upper right corner, they are expensive. Also all the "active cursor..cursor visible" don't seem to be necessary. Put all these in a seperate loop with an event structure for each plot triggered by e.g. "mouse-up" on each graph. Same for all the cursor postion reads.

The data does not change during the run but you are sending the SAME data every 50ms to each graph. Put all graphs, incuding the data unbundling, etc. in a case structure that executes only when [i]=0. None of the property operation require resending of the data to the terminal, ever.

Each graph is done twice, once hidden for printing. This creates many data copies of
your huge arrays. The print graphs need only receive data if printing is actually done. You could even use a single "print graph" which receives the right data and properties once right before printing each data set. All other property and data updates before actual printing are a waste of resources.

There are many more improvments possible, e.g. dynamic decimation of the data suitable for the display, better use of event structures for the UI (the loop need only run if something changed, and only needs to do a subset of actions relevant to the event).

[Khalid]

Altenbach's suggestions are excellent. You should not be writing to the property nodes when you don't have to. Use Events Structure wherever you can!

Here are some more potential improvements:

1. You seem to (over)write the same file in each iteration. You end up getting only the last iteration's data. Is this what you want? if yes, then you can write to the file, only once, at the end of your loop execution -- outside the while-loop on the right-hand side.

2. Similarly, you seem to rewrite the images over and over (tension.jpg, payout.jpg, etc., all seem to be written in the same place each iteration). Unless something else is happening in the missing Write JPEG file.vi. Look into this; this operation can be expensive.

3. R
eplace feedback nodes with shift-registers. Though you don't use many of these, they can speed things a little.

4. Use the Defer Panel Updates property when you're about to set a bunch of properties. See online help on this for more details. This can be a saver too.

5. You may want to hide those controls/indicators which you do not need to display at run-time, e.g., Data in, Data out, etc. (right-click the terminal on the diaghram and select Hide Control/indicator).

6. There may be potential improvements in your retrieval code as well. Reading the entire file into LabVIEW is not a good idea, for instance.

Finally, it is usually much easier to critique others work than doing it. So, don't feel bad about all this 🙂

Regards,

Khalid

[dj143]

I'm not familiar with the concept of dynamic decimation. In searching for it, I found the link: http://zone.ni.com/devzone/conceptd.nsf/webmain/6A56C174EABA7BBD86256E58005D9712?opendocument Do you know of other information available? Also, do know of any articles that show how to sense when something has been changed from the operator?

[dj143]

Thank you for your comments. I've spent the time reqworking the programming and have learned a number of issues. At this point it's not perfect, but very usable. The primary thing I did was to run most of the code only once when the vi is opened or when data is retrieved in a case structure. I also placed most of the property nodes in an event structure. I hope this experience will be useful to other readers. Thank you again...