CompactDaq AI with Visual Basic .NET

[DieselPower]

We read any range of sensors and thermocouples from 40 to 80 channels.  Right now, we're using SCXI chassis to handle the analog input.  I like the USB support and the lower price that cDAQ has to offer.  We read our analog inputs at 1 Hz.  The entire loop for the program (written in Visual Basic .NET) operates at 1 Hz.  It can not, under any circumstances, be lower than 1 Hz.  Right now, the loop is operating at 500-1500 ms to read 32 thermocouple channels from one chassis using 1 task for 8 modules.  If these things are supposed to read at 14 S/s, I don't understand why the loop is taking so long.

Thank you.

[Salvador_Santolucito]

I applogize if I am repeating information that you may already know.  I want to start at the beginning so that we understand eachother.

With cDAQ, you only have one AI task running at a time.  So if you have a cDAQ chassis with eight 9211 modules, you can have one task that will contain all of these channels. 

In each loop iteration, how many samples are you trying to acquire?  Is it necessary that you start the task, get the data and stop the task in each loop iteration?  Why don't you set it up to be a continuous task?

Thanks,

Sal

[DieselPower]

When I set it to finite samples, the loop takes 500 ms, then 1400 ms, then 500, then 1400 etc.

When I set it to continuous samples, the loop operates at 1000 ms, but after 83-85s I get an "Attempt to read samples that are no longer available."

Data set 86 is using finite samples, 1 sample per channel, 14 S/s rate

Data set 93 is using continuous samples, 1 sample per channel, 14 S/s rate

Attached are the data sets, the error, and a chart that shows the stair-stepping trend using continuous samples.  It isn't returning new values every second as it should.

[Salvador_Santolucito]

Hi,

From the code that I've seen it looks like you are creating a separate task and reader for each 9211 in your chassis.  Have you tried only using one task and reader?  Inside of your while loop, you should only have to start, read and stop the task. 

Thanks,
Sal

[DieselPower]

It may look like I'm using more than one task, but there is a section of code that says if .device.contains("cDAQ") then don't create a new task.  There is only one task. 

I do not have a Task.Start or Stop in my loop.  If I am using continuous samples and a timer that called the read function, should I do this:

create task, etc

Timer
    Call ReadRata
    Call WriteData
End Timer

ReadData
    Task.Start
    Reader.Read
    Task.Stop
End ReadData

?

[Salvador_Santolucito]

Yes, that looks correct.  What is the sampling rate that you want to acquire at?  If you want to acquire at only 1 sample per second, and you are already using .NET to time the loop, then why don't you use a software timed single point acquisition?

Basically, you would just create the channel and then in the loop call the reader to read 1 sample.  You wouldn't need to use the configureTiming function or stop/start the task repeatedly.

Thanks,
Sal

[DieselPower]

Right now I am reading 1 sample per channel with 31 or 32 channels on the chassis (8 modules).

I have set the sample rate at 14 S/s.  I don't want my loop to take 1 full second because I need some breathing room.  Using SCXI, the loop takes about 3-500 ms to do all of the DAQ and control.

What I listed in the previous post is not what I have written.  I don't have any Task.Start or Stop commands in the code.  I am creating the task and reader, than then calling the reader at 1 Hz intervals.

Attached you will find the program in it's current state.  You may not be able to run it due to it's use of Microsoft Excel...

[Salvador_Santolucito]

Hi,

I prototyped some if this in LabVIEW and here are my results..

Doing a software timed single point acquisition in a loop, the best loop time I could achieve was 1200 to 1400 ms.  So in LabVIEW, I was unable to keep up with a 1 sample per second loop doing it software timed.  I tested this with a different module (a 9215 )and I got the same results. 

So it may not be possible to achieve a 1 sample per second loop

Another thing that I found interesting in all of this is that you said that you were doing finite acquisitions of 1 sample.  I believe that the minimum number of samples you can have for a finite acquisition is 2 samples.

The latency in a cDAQ system is much more than a PCI based SCXI system.  In PCI, you have very low bus latency.  This means that your software can send commands to and from the PCI board very quickly.  This allows you to have very fast startTask / stopTask loop rates.

USB is a high latency bus.  So although you can achieve very fast rates when streaming data in one direction (i.e. continuous acquisition), you will recieve less performance when doing a lot of back and forth transfers (startTask / stopTask loops).

For your application, I suggest that you use a hardware timed continuous task to monitor the 9211's in your cDAQ chassis.  By doing this, you can set a 1 sample per second sampling rate and stream the data across the bus.  All you have to do is make sure your reader loop can keep up with this.

Thanks,
Sal

[DieselPower]

Will 9205s transmit samples at a fast enough rate across USB, or will I have the same problem with them?

Is ContinuousSamples hardware timed?

Why do I get the error that I've shown above when doing ContinuousSamples?

Message Edited by SCXI and MS 2k3-VB.NET on 01-22-2007 02:58 PM

[Salvador_Santolucito]

Hi,

I just tested this again in LabVIEW with a 9205 and 9215.. I found that with these modules, I was able to achieve much faster single point acquisition rates.  This ended up being around 80 - 100 ms per loop.

The reason that the 9211 is so much slower is because it is... well, slower.

The 9211 has a maximum sampling rate of 14 samples/second.  When you are doing multiple channels in a task, the maximum rate of the device is divided by the number of channels it is sampling.  So when you are doing multiple channels, you have to wait a relatively long time between channels for the ADC to settle.  In addition to this and the odded overhead of USB latency, the 9211 also takes an autozero measurement when the task is started.

So by starting and stopping the acquisition in a loop you are taking this autozero measurement (which takes about 400 ms) every time.  This adds to the loop slowdown.

If you do a continuous acquisition, you would definately be able to achieve your desired 1 sample per second loop rate.  The error you got is a buffer overflow error.  It is likely because the loop that you are using to read is running slowly.  I would suggest removing everything except the read from the loop to improve its speed.  There may be something else in your code that is slowing it down.  You may also want to look at the rate that your continuous acquisition is set for and how many samples you are reading in each loop iteration.

Thanks,
Sal