Increasing the data write speed

[Paul]

I was wondeirng if there was a way to increase the rate at which data is saved to a file using the write labview measurement file function. I didn't see it as a property anywhere but right now the rate ranges from 1-3 seconds, and I would like for it to work as fast as possible. I tried using a time delay, but I actually need to speed up the rate not slow it down. Ideally I need to record data at 60 hz which is .01666 seconds, but I would settle for anything as close to that as I can get. Please advise.

[Bryan]

I believe the write labview measurement file function is a higher level vi that opens, writes to, and closes a file each time it's called. Opening and closing every time sucks up computer resources.

If you can open the file at the beginning, pass the reference to your loop with the write function inside, then close it after loop completion, you'll get faster logging.

If you're set on using that function and your current method, and you're not using a delay in your loop, then I'm afraid you'll be limited to your computer's processor speed.

[Paul]

The instrument that actually measures the data and sends it to the computer has a delay of about 45 ms. It sends it to a computer using a USB/GPIB converter. The USB is 1.1 and I was told that the information sent through a GPIB does not exceed theoretical transfer rate of a USB 1.1, implying that there is about a 1 second delay each time that function is calledin Labview. To me that sounds a little high, especially if data is to be preformed at 60 hz which required logging every .0166 seconds. Are there any other possibly methods to get data logged at about 50 times a second?

[James McAnanama]

The instrument that actually measures the data and sends it to the computer has a delay of about 45 ms. ... Are there any other possibly methods to get data logged at about 50 times a second?

1215[/snapback]

Does the instrument have the ability to log a series of measurements and then transfer the lot periodically over the GPIB bus (log 50 readings and tx these 50 every sec)? Alternatively, does the instrument have an analogue out? Can you control it using the GPIB bus, but grab the output over the analogue port in real time? (I don't mean to offend you with obvious questions - these are just some ways we have overcome slow GPIB readings with Keithley and Agilent equipment).

[Paul]

No offence taken. I am not sure about most of the questions that you asked and the people at Agilent weren't that helpful. I did however find a link to the device that I am using, perhaps that could answer some of the questions.

http://we.home.agilent.com/USeng/nav/-1135...6880312/pd.html

[Bryan]

This link looks promising maybe:

http://cp.literature.agilent.com/litweb/pdf/5989-0153EN.pdf

I don't have time to look through it completely.

Most of the information I've found for devices I've interfaced with I have found in the manual or command reference guide. (RS232/GPIB)

[James McAnanama]

I took a look at the programming guide and product manual from your link... Unfortunately, it doesn't look like there is any way to buffer the data. However, there may be another way around it.

-Can you describe your application?

-What is it you are trying to capture at 60Hz?

-Can you use a DAQ card to measure your parameter elsewhere in the system? (e.g. voltage drop at the DUT etc).

[Paul]

James,

In a nut shell what the program does is measure the power, voltage, and current from a fuel cell that is hooked up to that Agilent Loadbank. Then, there are two modes that can be run by simulating actual loads on the fuel cell. The data is then read and saved. So the basic premise is quite simple, and the fuel cell needs to be tested at 60hz, which is 50 readings every setting. Right now my supervisors aren't too worried about the time, but I would still like to find a way around it if possible.

Thanks again

Paul

[James McAnanama]

It doesn't look like you will get faster than the 45 ms delay you are seeing from the 6060B. In addition, if you are looking for features in the 60Hz bandwidth from the fuel cell, you will need to sample at >=120Hz to avoid aliasing. One solution might be to use either a NI DMM (http://sine.ni.com/apps/we/nioc.vp?cid=12683〈=US) or a DAQ card to probe your circuit. I use DAQs, but haven't used their DMMs yet. However, from the NI website, NI PCI-4070 FlexDMM is specified to sample 6

[Paul]

James,

Interesting read, well work with what we have in the mean time. Thanks again for all of your help.

[Jack Kelledes]

I have used that type of Agilent electronic load (6063B) and have given up on any type of high speed measurement from it.

When high speed is necessary we always use a dedicated meauring device because of accuracy reasons mostly as the readings of the load vary quite a bit from day to day.

For your application where only a few things need to be measured I would use something like an Agilent 34970A with a 34902A module plugged in. The advantages of this from my experience are that each channel is fully differential and isolated and the unit can store 50,000 readings at around 120S/s or faster if it's set up correctly. That way you could run your test and download your data afterward.

I work for a battery manufacturer and use simple setups like this regularly and have had no problems with them. Plus the unit is very versatile and can be used for many other things which might help with cost justification.