Advice for making my software more efficient

[Ben_Jaminnash]

Hello,

I am running LV 8.5 on a Dell Windows XP SP3 machine. I have a LICOR 6252 device printing data through a COM port to labview. Each packet contains 6 peices of data, all of which I want to store and eventually save to a spread sheet. The LICOR can send this data packet every 1 second. However, when I set the data rate that high, data is only saved every 10-12 seconds. I assume this is due to inefficencies in how I am saving everything to an array. Can you suggest anything I can do to make my program more efficient so that more of the data will be saved? Thank you. 

[GerdW]

Hi Ben,

how can you say, you save data after 10 seconds, when the save function is called after YOU press the stop button in the loop?

Your VI will save data when you press this button. Not earlier, not later…

On efficiency: use simple VISA functions istead of the ExpressVI. Avoid coercion dots.

[Ben_Jaminnash]

Thanks. What I meant by saved was that the data is added to arrays which are continually compounded in the while loop. Once the loop is exited, the data is complied into one array and saved to a spread sheet. Can you explain how a VISA function will make this program more efficient? 

[DailyDose]

FYI, your while loop is spinning at a very high speed accumulating empty data.  Unless the Instrument I/O is causing the while loop to wait on it, you will have massive gaps in your arrays. I'm not too familiar with the Instrument I/O, but my guess is that it's not waiting for data.  I could be very wrong though.  Try putting some sort of case structure that determines whether or not you acutally have data to add to your arrays so that you're not adding gaps.

[crossrulz · Accepted solution]

Your building of arrays will kill your speed and memory.  What you really should do is log your data to file while you are acquiring it.  To do this use a Producer/Consumer setup.  The idea is to read the data and parse it and then use a queue to send the data to another loop that does the logging.  This way, you will not need to keep building up your arrays and memory stays at a minimum.

And just digging into the Instrument I/O Assistant.  You definately do NOT want to use it.  It is performing a read from your instrument for EVERY parameter you put in.  From what I can tell, you only need a single read and you can parse all of the parameters from there.  What does this mean?  Your measurements are not coming from the same measurement time.  That can cause some MAJOR issues with projects I have had.  So, yes, you want to use the raw VISA.  You can do the setup before the loop and close the port after the loop.  The parsing of the data should be really simple as well.

[Ben_Jaminnash]

Great! Thank you for the help! I will impliment the Producer/Consumer setup in my program.

[Ben_Jaminnash]

Is there a better way to log the data then to put it into an array attached to a shift register? If i do that in the consumer loop, will it still kill my memory?

[DailyDose]

This is dependent on your application's needs.  If you know the array is never going to get beyond a certain size which can still be defined as "small" then you have nothing to worry about.  But if this is going to poll for a very long time, a solution then is to monitor the array size.  Once it hits an index of say 500, you then dump the data into whatever file you're wanting to save data in, clear the array, and press on.  But CrossRulz's suggestion was to not load up your arrays at all using the consumer/producer.  I would say that saving a data point every iteration to file is not necessarily a great idea.  Which is why I'd take his idea and implement it with watching the size of the array.  Hit 500 elements, queue the data, empty the array, continue reading.  Then the consumer loop can store the data in one iteration.  It's a little CPU friendlier, but not necessarily RAM friendlier.