Timing measurements.

[AnnaT]

"Hello!
I am trying to write a vi for a drying equipment. The vi is supposed to continously gather temperature data from two thermocouples and the condensate weight from a balance, with a time between the measurements that the user sets with a knob. When a log button is pushed the vi should start logging to a spreadsheet file.
However, the time in my vi is all wrong, and I wonder if the code is wrong or if the problem is in the hardware. The first time measurement seems completely random and after that the time between measurements are almost constant, but not the specified time.
Needless to say, I am new at this and I would be very grateful if someone would take the time to have a look!
Thanks,
Anna
Sweden"

[chilly_charly]

Hi Anna !
The answer is simple : that's not a problem of hardware... 😉
Your code must be improved.
First step : read the "do and don't"'s about LabVIEW programming : keep your diagram tidy and compact, avoid un-necessary long wires, always keep the left-to-right data flow, never hide a wire under a diagram structure, etc... This will ease the reading of your diagrams, and make debugging a lot easyer (not only for you !!!).
Second step : improve the code :
a/your loop has a timing of two seconds. You will not be able to save correctly the readings if the user set an odd value for the time between readings (BTW, you forgot to wire the weigth reading, and there is one excess tab in the file header);
b/you are reading the tick number in various places
: this will make your time intervals different;
c/there is no reason for re-initializing the serial port at each loop iteration;
d/ the loop timing was in a sequence structure, so the period was equal to timing plus process time;
e/the stop button was not at the right place
f/the logger button should be reset at false upon vi run
g/Due to the way you do the init, the first record is done after one loop (2 secs);
h/...probably a lot more things to be said !

I made some improvements to your diagram (an hour hard work...), but I can't post your vi back. If you post your mail adress here, I will mail you directly the corrected art work...

Keep wiring

[AnnaT]

Hi!
Ouch, that was a lot of mistakes! The thing is, the code was originally written by someone else (who is supposed to know LabVIEW), and I didn´t really dare to delete too much of his code. So I guess my code on top of his resulted in the worst of two worlds...

Anyway, thank you so much for devoting an hour of hard work to this! If you could send your improved vi to anna.tannenberg@moderat.se, I would be most grateful!

Thanks again,
Anna

[johnsold]

Anna,

I agree with what chilly charly said. I would consider re-designing the code to use the state machine architecture. Fundamentally a state machine is a while loop enclosing a case statement. There are examples and many postings about this.

Also, I would separate the program into three parts, each one a separate state machine. One is for the user interface - the event structure can handle user input. Another is for the data acquistion and instrument interface. The third handles any calculations, data processing, your timing issues - anything that is not in the first two loops. Data is transferred between the loops using queues or functional globals.

If you want to put some effort into writing high quality LabVIEW code, look Rules
to Wire By, by Rande Johnson, published in LabVIEW Technical Resource . Also, A Software Engineering Approach to LabVIEW by Jon Conway and Steve Watts, published by Prentice Hall .

Lynn