CompactDaq AI with Visual Basic .NET

[DieselPower]

How about the following possibilites:

The sample type finite or continuous?  Correct in setting up the task and the reader (passing a number of samples to read)
Sample rate is in the createdaqtasks function when setting up task timing.
Number of samples is in the createdaqtasks function when setting up task timing (and passing a number of samples to read when calling reader().readmultisample).

Those are the only factors I can think off. 

Are you testing with a chassis full of thermocouples or an empty one?  Why is all of the data 12?  I can't see any change in value to verify that it is storing new samples every second instead of every 2 seconds.

[Erik_J]

Hey Michael,

You said before that you are using 8 modules.  How many total channels are you using in your scan list?  If it is more than 10, then you may not be able to get a rate faster than 1 Hz.  This is because the effective maximum sample rate for thermocouple tasks is 12/(n+2) S/sec, where n equals the number of channels in your scan list. The extra 2 is because both the cold-junction and autozero channel values are automatically read and used to calculate the temperature every time the scan list is sampled.

More information can be found in this KnowledgeBase.

Unfortunately, this may be what has been causing the slow sampling rate all along.

Regards,
Erik

[KyleBryson]

That app note is for the single-module USB-9211, not cDAQ.  All 8 9211s in a cDAQ-9172 chassis will run in parallel, so the maximum rate is greater than 1 Hz.  The multiplexers will still scan through 5 channels on each module, but they all start at the same time, yielding a rate of 2.something Hz that I posted several dozen posts back.

I'm not sure where we stand on the software front, but I'm still suspicious that the NumSamples being set somewhere is causing a task to terminate and restart between loop iterations.  You should be able to set up a task (continuous or finite) with a large number of samples (say, 60), the desired sample rate (1 or 2 Hz), and have it run for the correct amount of time (60 or 30 seconds, for example).  The number of points that you read in each reading loop should be inconsequential, since the acquisition itself is hardware-timed at the desired rate (1 or 2 Hz).  You could just read all 60 samples at the end, or 1 point/channel every second, or whatever.

Kyle

[DieselPower]

I am going to take the loop out today and have the program read and write only when I click a button.  I'll then measure the time it takes to read and write.  I need to get this thing going because I just got a request for another test cell and I have to decide which hardware to go with.

If I want to read 1 sample per second, what rate and number of samples per channel would be ideal?  I thought that the devices would accept faster sample rates so AIs and TC inputs could be grouped into one task.  If this is the case, then I'd like to be able to read at 10 kS/s, but only 1 sample per channel on the TC modules.

I'll report back with my findings.

[KyleBryson]

If you want 1 Hz, set your sample rate to 1, and your number of samples per channel to how ever long you want the acquisition (i.e., 60 for 1 minute).  You're correct, you can run the task at a faster rate (constrained by the other AI modules you're using), and your thermocouple data will repeat.  By default, the 9211 will sample as fast as possible when you request data at a rate higher than it supports, which will be faster than 1 Hz.  In order to control the 9211 acquisition frequency with a 10 kS/s sample rate, you will have to set the conversion rate of the 9211.  For your app, I think you will want to set it to 4 Hz (w/o CJC) or 5 Hz (w/ CJC).  To set the 9211's convert rate, write these properties:

DAQmx Timing => More => AI Convert => Active Devices    <=  "cDAQ1Mod1, cDAQ1Mod2, cDAQ1Mod3..."
DAQmx Timing => More => AI Convert => Rate                    <=  5 Hz

I would suggest making sure you're satisfied with the way it's working with a sample rate of 1 Hz before moving to the faster sample rate and controlling the convert rate manually.

Kyle

[DieselPower]

I might have narrowed the problem down a little.  I need to understand these asyncronous callback things in the example code.  Before that, I'll mention that the sample program begins and ends multisamplereads.  I am not beginning or ending, but just calling the read function at 1 Hz. 

Is the asyncronous callback something that is mandatory, recommended, or neither?  What exactly is this beast doing?  If I want a timer in my program that calls a thread once per second in order to have smoother program use, how would I implement this callback deal?

Currently, my program is as follows:

Timer at 1 Hz
    Call Thread
End Timer

Thread
    Read
    Write
    Make Decisions
End Thread

For some reason, not starting and stopping the reader is causing some problems with compact daq, but not with SCXI.  I figured out why all of the data is 12 on the code I gave you.  I am reading the wrong columns for certain things in load channel configuration.

[DieselPower]

I added some features to time each of the steps of this program, and this is what I found.  It appears to be reading only once.  Each consecutive time that I click the read button and then the write button it writes the same data that was read the first time I clicked it.

Time is in ms.

Message Edited by SCXI and MS 2k3-VB.NET on 01-10-2007 08:26 AM

[Erik_J]

Hi Michael,

A callback function is recommended.  This is because a callback is a function that can be called by a section of code external to where the callback actually resides. NI-DAQmx can be configured to call a callback function in response to an event.  During the acquisition in the Continuous Acquisition of Thermocouple Samples example, a DAQmx event is triggering the callback function so that the table can be updated with the new values.

Please see this Developer Zone article for more information on using callbacks in your code.

Regards,
Erik

[DieselPower]

This doesn't make any sense.  Why does my code work flawlessly for SCXI, but does not work for CompactDAQ?  I am not using any asycronous callbacks in my software and my 1 Hz loop takes ~400ms to execute.  I try to run that same software on CompactDAQ and it will read one time and then spit out the first values it read over and over again without actually reading the channels again.  I don't know how to set the async deal at 1 Hz.  What is the difference between SCXI and CompactDAQ?

Every time I call [Task1Data = reader(Count).ReadMultiSample(x)] it should be reading again, but it doesn't after the first call.  SCXI reads the first time and every time after that.  Is there something that needs to be reset after each call of the reader?

[Erik_J]

Hey Michael,

How many total channels are you sampling on the CompactDAQ?  And how many on the SCXI?  Which SCXI module?

It is very strange that you can achieve the 1 Hz rate on SCXI but not CompactDAQ.  I think we are making progress, is hardware now the only variable in the equation?  If hardware is all that you are changing, then the only thing I can think of is limited sampling rate of the hardware.  But everything we've looked at indicates that you should be able to get the rate you desire.

Regards,
Erik