LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

need to record data for 4 hrs at a rate of every 30s

Hello,

I'm fairly new to LabVIEW and need assistance. I have this VI that manually records torque and temperature by hitting a button. I want to alter it so that when I run the program  I can automatically collect data every 30 sec for 4 hrs and then the program stops. Any help would be appreciated. I have attached the VI. 

0 Kudos
Message 1 of 7
(3,969 Views)

Use the Elapsed Time VI with the time set to 30 seconds and autoreset.  When the time elapsed boolean turns true, take your measurement and log it.  I would also keep a counter for how many measurements have been taken.  When this counter reaches 480 (4 hours worth of data), stop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(3,952 Views)

Thanks! I will try that.

0 Kudos
Message 3 of 7
(3,932 Views)

I have altered my VI by incorporating the Elapsed time VI. I have also replaced my DAQ assistant with simulated signals. I can get the VI to stop at the specified time interval I want. The problem I am running ino is when i am trying to gather 4 sec of data every 30sec. When I first start the VI it will do just that, but then after for every 30 sec it will record, but only for a split second, not the 4 sec I want. So I am getting 170 kb files when it saves for 4 sec and only 1 kb files after that. Any help on what I need to change or what I am doing incorrect would be greatly appreciated. I have attched the VI.

 

Thanks!

0 Kudos
Message 4 of 7
(3,819 Views)

One of the most difficult things for people new to LabVIEW to avoid is the temptation to "just start coding" -- as often as not, you end up with a bunch of (often Express) VIs wired together that do something, but rarely what you want it to do.

 

I recommend starting with thinking about the overall design, asking yourself "What do I want to do?".  In your case, it sounds like "Record data (not yet defined) every 30 seconds for 4 hours".  Now break this down -- what does "record data" mean?  How much data?  How many channels?  What data rate?  What do you want to do with the data?

 

This might be a "unit" of your code, that is, this "Data Recording Block" might, in some ways, stand alone.  One way this could happen would be if you recorded, say, 5 seconds of data, wrote the data to a uniquely-named file, then stopped recording.  "Aha!", I (don't) hear you saying, "this should be written as a sub-VI called "Save Some Data" that I put in my main program and call every 30 seconds until 4 hours have gone by".

 

What is this isn't your model?  Maybe you want to start data acquisition, keep it running, and every 30 seconds save some aliquot of the data to a file.  Fine, but that's another Design Decision that you should make before starting to code.  This kind of model sounds liek it might be a Producer (continuous data acquisition)/Consumer (periodic saving of the data) design, with the Consumer "worrying" about saving, say, 5 second aliquots of data every 30 seconds for 4 hours.  This last bit (namely getting the Consumer to "do its thing" properly) might be handled by a State Machine design ("Save to File", "Wait for next Sample Time", "Count Elapsed Time").

 

Here is a piece of Good Advice -- never put an "Abort LabVIEW" command in your program!  Notice you have a Stop button to stop the loop, and can OR wire the output now going to the Abort to the same Stop indicator.  Use Abort in the rare instance where failure to instantly kill the program will result in someone's death or injury -- you're not yet ready to code at this level.

 

Bob Schor

Message 5 of 7
(3,790 Views)

@Bob_Schor wrote:

One of the most difficult things for people new to LabVIEW to avoid is the temptation to "just start coding" -- as often as not, you end up with a bunch of (often Express) VIs wired together that do something, but rarely what you want it to do.

 

I recommend starting with thinking about the overall design, asking yourself "What do I want to do?".  In your case, it sounds like "Record data (not yet defined) every 30 seconds for 4 hours".  Now break this down -- what does "record data" mean?  How much data?  How many channels?  What data rate?  What do you want to do with the data?

 

This might be a "unit" of your code, that is, this "Data Recording Block" might, in some ways, stand alone.  One way this could happen would be if you recorded, say, 5 seconds of data, wrote the data to a uniquely-named file, then stopped recording.  "Aha!", I (don't) hear you saying, "this should be written as a sub-VI called "Save Some Data" that I put in my main program and call every 30 seconds until 4 hours have gone by".

 

What is this isn't your model?  Maybe you want to start data acquisition, keep it running, and every 30 seconds save some aliquot of the data to a file.  Fine, but that's another Design Decision that you should make before starting to code.  This kind of model sounds liek it might be a Producer (continuous data acquisition)/Consumer (periodic saving of the data) design, with the Consumer "worrying" about saving, say, 5 second aliquots of data every 30 seconds for 4 hours.  This last bit (namely getting the Consumer to "do its thing" properly) might be handled by a State Machine design ("Save to File", "Wait for next Sample Time", "Count Elapsed Time").

 

Here is a piece of Good Advice -- never put an "Abort LabVIEW" command in your program!  Notice you have a Stop button to stop the loop, and can OR wire the output now going to the Abort to the same Stop indicator.  Use Abort in the rare instance where failure to instantly kill the program will result in someone's death or injury -- you're not yet ready to code at this level.

 

Bob Schor


To expand on this idea, I usually write up at least a "casual" requirements document - even if it's just a few paragraphs - and code each "requirement" as a subVI.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 7
(3,716 Views)

Thanks everyone. I actually tried to take an existing VI that we had for vibration analysis that recorded data at noon and midnight and tried to alter it to suit my purposes (taking torque and temp data every 30sec for 4 hrs). I will try to break it down and take a look at what I need and what might be unecessary.

 

John

0 Kudos
Message 7 of 7
(3,694 Views)