LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Setting up an internal clock to take data acquisition at one minute intervals

Highlighted
I am trying to set up the attached VI to collect 100 data points on each channel as illustarted and export to spreadsheet. I want to activate the VI manually the first time and then have it automatically repeat every minute and append the data to the same file. I am having trouble building a loop for this. I would rather not have to use an external clock if possible.
0 Kudos
Message 1 of 8
(1,507 Views)
Highlighted
You can do this a couple of ways.

One is to set your scan rate to 1/60th Hz (once a minute). This can be done by one of two ways: Set the scan rate to 0.16667, or use the "Alternate Clock Config" cluster (in AI Start, AI Clock Config) by setting the clock period or interval appropriately (I have never done either of these, so try them and see what works best). Given the code you currently have, if you can figure out how to make this work, this will be your easiest option.

The second method is to modifiy your code. You will need to start a continuous acquisition of one point at a time (per channel). Then, read only one datapoint (per channel) from the buffer every minute.

I have a strip chart program around somewhere that I did something simi
lar to this, except I read a second worth of data at 1000Hz to give me a cleaner signal (by averaging to remove noise.) If you can't get the first option working, and also have trouble with this second option, email me and I will try to dig up that code. I can't post it here.
Message 2 of 8
(1,507 Views)
Highlighted
Unless I miss the point, I'm wondering why you are worrying about setting up a continuous acquisition to take data this slowly. Attached is a modified version of your vi that simply initializes the DAQ, takes the 100 points and closes the the DAQ. It then waits what's left of a minute and repeats the process. From your description, it sounds like this is all you really need.

It's not like the time it takes to initialize and clear the DAQ is going to adversely effect your measurement throughput...

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 3 of 8
(1,507 Views)
Highlighted
Mike,
I ran the modified version of the code you sent. The loop does what I needed as far as taking the measurements every minute but it seems to corrupt the data received. If I hook up a signal to one channel, the data looks fine. If I hook up a signal of different magnitude to another channel, it follows the first signal but with a slight delay in phase angle and a slight reduction in magnitude. This occurs regardless to the magnitude or phase of the signals. I even removed the second signal but left the VI set up so it would record the data from both channels and even with the signal removed, I am still recording a waveform. I will repost this question in the event no one sees it here.
Cappy.
0 Kudos
Message 4 of 8
(1,507 Views)
Highlighted
A couple things: First, unless you have a sample-and-hold board in front of your analog inputs there will be phase delay between the channels. The channels are being sampled very rapidly, but not simultaneously. Second, if the amplitude of one channel appears to be effecting the measured amplitude of a channel on either side of it (in the scan order)there is probibly a settling time problem. NI's cards internally only have a single A/D converter which is connected to each of the input channels through a multiplexer. Simple enough, but things start getting complicated when are doing on-board gain adjustments too. Now you have to adjust switch the multiplexer, allow it to settle and change the gain of the input amplifier. In addition, the amplifier itself has what is called a slew time, or how fast its output can change in response to a step change in the input. Put all together, if there is not adequate interchannel delay in a scan the input will still be showing the effects of a previous channel when you read the next one.

If this is the problem, there are two fixes: First don't put signals on dramatically different levels on the same card. This reduces the amount of time the DAQ card needs to adjust to each input--at the price of an additional DAQ card. Second, increase the amount of interchannel delay for the scan to give the card the time it needs to settle--of course this added time will also increase the apparent phase shift between channels so you might need to add a sample-and-hold card to get simultaneous sampling.

Personally, I would try the increased interchannel delay first to see if what you are fighting is a settling time problem as this is only a software change. If increasing the delay fixes the amplitude problem, you then can analyze the hardware solutions to determine which is the best.

Of course, if you really need absolutely simultaneous sampling, the decision is already made for you. Call NI and get an appropriate sample-and-hold card.

Hope this helps, as in a lot of things in electronics, setting up an acquisition system is a balancing act where you have to learn what compromises you can, might, should or need to make technically and financially.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 5 of 8
(1,507 Views)
Highlighted
Mike, I understand what you saying except I am able to run the original program before the loop was added and do not have any disturbance from other signals as well as another version that is sampling continuosly at the same rate. I think there is something going on since the automatic one minute sampling took place that is causing the issue. That is the part I need help with.
Ben.
0 Kudos
Message 6 of 8
(1,507 Views)
Highlighted
I just looked at your original code again and now I am confused too... Perhaps it's "call NI time". At least now you have a couple small code samples you can send them--which is what they are always wanting to see anyway.

Mike...
mporter@arielcorp.com

PS: If you get an answer from them let me know what they said so I can resolve my confusion as well...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 8
(1,507 Views)
Highlighted
Another thought I had just now, if you're willing to experiment a bit try the attached code, it is basically the same as the first one except that it captures the data as a scaled array not a waveform. Theoretically there shouldn't be a difference, but I noticed that the two methods do use different calls to the driver software.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 8 of 8
(1,507 Views)