slow VI execution

[wb2nvy]

The first time I ran this VI using Labview 8.2.1 in the development mode, Windows XP, I thought it ran slower than it should, but speed wasn't critical. I modified the program slightly and it ran even slower. Then I updated to Labview 8.5, and I changed the loop from looping 6 times to an abbreviated 4x loop, and it runs slower still. I have attached both the VI and the profile data. The profile data looks reasonable, but it doesn't reflect the full 2 minutes it takes for the VI to execute through all 4 loops. This VI is intended to read pot settings, both fully CW then fully CCW, and the manual turning of the pots on each loop takes no more than about 1 second. Can someone tell me why this runs so freakin slow? My IBM thinkpad has nothing else going on in the background. And it's not just VISA/pot reading that is slow- all events outside the pot reading are also slow.

[Dennis_Knutson]

Do you realize that with your for loop, you are repeating each case statement 4 times? I don't see the point of the for loop at all. I don't see anything change from iteration to iteration. Without the for loop, your current VI would execute case 1 one time, case 3 one time, case 4 one time, and then case 6 one time.

[wb2nvy]

Thanks Dennis. That for loop was definitely redundant. I removed it and now it executes in 1:18 instead of 2:00, but that still seems ridiculously long for what it's doing, doesn't it? So now instead of 30 seconds per loop it's down to 20 seconds per loop. Aside from the pot readings, shouldn't everything else execute in milliseconds?

[Dennis_Knutson]

I don't see much in the code that could account for that much time though you could probably move the VISA Flush Buffer outside the while loop. Without the hardware, I can't tell how many times the inner while loops might be iterating so you might want to probe the iteration terminals. The amount of time reduced points to a possible problem with your serial function. Could you post the Readpots VI?

[wb2nvy]

Readpots.vi

[Dennis_Knutson]

I don't see a problem with that. In your while loops, you are looking for an exact match. You might want ot check, as I mentioned, how many times these loops iterate before the exact match is found. Another thing you should do is replace all of the error cluster tunnels in the while loops with a shift register. If for any reason, you get an error, it would get cleared when a loop iterates again and you might not see it in your error indicator.

[wb2nvy]

Thanks again Dennis. I'll check those things. I found that if I close the VISA read immediately after doing the read in the readpots.vi, things speed up to 50 seconds for complete execution. Apparently the read VISA was continuing while I was processing the results. I'll take it from here, and I very much appreciate your inputs and your time.

[_orko_]

One thing I notice is that you are initializing and closing your HP34970 on each iteration of the main while loop.  With the default (unwired) setup of the HP34970 Initialize, it sends commands to reset the instrument to it's default configuration and query it's IDN, which take time to do.  You may want to move the open and close to outside of the main while loop.  It wouldn't hurt to also move your serial initialization and close out as well.

One comment I would also like to add is that nesting too many structures and using local variables too generously is a good recipe for race conditions and "weird" bog downs/bugs to appear.  You may want to learn up on using event structures and queues, such as the producer/consumer with events template example you find under Frameworks in the "File->New..." dialog.

Good luck, I hope that this helped you out.

[wb2nvy]

Thanks for your valuable input. I looked at the producer/consumer with events template and I see it uses an event structure. I don't have event structure in my programming palette. But it looks a lot like a case structure, so maybe I can make that work.