Increased response speed for continuous DAQmx with AI and AO

[JennaU]

Hello,

I am trying to increase the speed that my VI samples and writes at.  I have come across different ways of accomplishing this task, but am not sure what change (or combinations of changes) will work most efficiently.

Here is a brief outline of my program:

- Uses LabVIEW 7.1, DAQmx 8.5 and NI USB 6211

- Reads in 8 Analog Inputs

- For one of the analog inputs, there is an analog output that depends on its voltage value

- I need my application to update at a rate of 100 samples / second (or faster)

- I would prefer the AI and AO to run in synch with eachother, or with a very small lag time (less than 0.01 s)

Possible solutions:

1)  Make parallel loops - one for AI and one for AO (this worked for me when I was using a card from MCC, but I can't get both loops to execute continuously with this USB card)

2)  Change the buffer size / how the buffer stores and releases data.  I have read the note on how the buffer size is determined for a continuous acquisition, but for some reason, this value gives me the error 200279, meaning that I am not removing data from the buffer fast enough.

3)  Get rid of the express VIs (I currently cannot seem to implement a case structure in place of the comparison express VI that does not execute sequentially) 

I have attached my VI that makes use of the express VIs since it is the most clear depiction of my program.  This discussion forum has proved to be very helpful for me in the past so If anyone has any examples or knowledge that pertain to my application, I would appreciate any help that I can get!

Thanks

Jenna

[Paul_C.]

Hi Jenna,

You might want to reattach your VI it didn't seem to get attached.  It sounds to me like your setting up some type of PID.  Is this true?  What type of calculations are you doing with the analog input voltage value and what are you outputting from the analog output? 

Based on what you have described, I think you might try parallel loops (one for analog output/input and one for calculations) and send the data from the analog input with a queue to the calculation loop which will send the information back to update the analog output (this will cause some "lag time" but then your analog inputs will be read continuously at the proper rate). Click here for more information on using queues. 

In your second question, you ask about buffer sizes.  The reason you’re getting that error is likely due to the fact that you’re not reading the data from your buffer fast enough.  Since your only acquiring data at 100Hz, you could probably increase the buffer size to delay this error; however, the best solution would be to read more samples each time (set samples to read larger).  A good rule of thumb is to set your samples to read at approximately 10% of your sample rate.  This is just a rule of thumb and can depend on other factors like how often your DAQmx read is executing (how fast you’re while loop is executing).   For example, if you’re sampling at 1 KHz, you would want to read 100 samples every DAQmx read, but if your DAQmx read only executes only once every 3 seconds this might still cause buffer problems. 

In regards to your third question, could you explain a little more about what type of comparisons are you doing?

In addition, I would take a look at the DAQmx synchronization examples (Help » Find Examples » Hardware Input and Output » DAQmx » Synchronization » Multi-Function » Multi-Function-Synch AI-AO.vi.  This example doesn't use feedback from an analog input but is good for showing how to setup two tasks (one as the master and one as the slave) to start synchronized.

I hope this helps,
Paul C.

[JennaU]

Thanks for your reply Paul,

I've attached the VI that I was originally talking about.  I'm not setting up a PID controller... it is going to be more of an open loop control with defined settings in the program.  The analog input channel that the AO channel is based on is reading in position data.  Depending on what position the analog input channel reads in, the analog output value will change accordingly.  So for example, at a position between 45 and 60 degrees, the LabVIEW program will send a voltage of 4.0 V to the analog output channel.  In the VI that I've attached, I performed this task by using the express VI called "comparison" which determines if the input is in a certain range or if it is greater than a certain value.

When you say that as a rule of thumb the buffer size should be approx 10% of your sample rate does this affect what the dt would appear to be in a spreadsheet?  I'm pretty sure that when I used a rate of 1000 Hz with a buffer size of 100 samples, that my spreadsheet had a dt of 0.001... could I change this??

I will try what you are suggesting about queues and the two loops and see how it goes.  I'll also look into the synchronization.  Thanks again for your suggestions and help.

Jenna

[Paul_C.]

Hi Jenna,

In regards to your questions about the "comparison" express vi, you can implement simpler code to accomplish the functionality of the express vi which will reduce execution time.  I've written a small example of how to do your first comparison with a for loop.  Take a look at the picture below.  This converts the dynamic data type to a 1d array.  Then it indices the array with the for loop so you can compare each sample to see if it is within your range.  If it is within the range, it outputs 3.8.  If it isn't within range, it outputs 0.  This will make the array of 0 and 3.8's so you can add them to the other comparison arrays later.



In regards to your second question, dt is a function of the sampling rate and the buffer size doesn't affect dt.  If your sampling at 1000Hz, your dt, the time interval in seconds between data points in the waveform, will be 1/1000 or .001ms.  So if you want to change dt, you will need to change your sampling rate.  The idea between the 10% rule is to set your samples to read to some value that will keep you from buffer overflow or underflow issues. 

I hope this helps,
Paul C.

Message Edited by Paul C. on 08-29-2007 03:13 PM

[JennaU]

Hi Paul,

That will definitely be helpful when I expand the amount of comparison tasks that I perform with my VI, thanks! 

Right now I am still getting the buffer error where the samples are being overwritten (Error 200279).  This error appears periodically at the beginning of a data acquisition trial and I am not certain why this would be the case as opposed to having the error appear all the time.

The producer/consumer application design pattern is also a bit confusing to me.  Can I read the info from the DAQ assistant into the queue in a producer loop and write, view and calculate data in the consumer continuously?  Can I use occurences in addition to queues if I want to synchronize the two processes and eliminate the lag time?

I understand what the producer/consumer and master/slave design patterns are trying to accomplish, but it’s incorporating that into my VI that is giving me a headache!

Thanks for your help

Jenna

[Paul_C.]

Hi Jenna,

The buffer error (-200279) is most likely due to you not reading enough samples from the buffer each iteration of the loop.  It sounds like the loop you use to do the DAQmx read is probably slow (due to other processes running such as the comparison express vi's) and you aren't compensating for this slow process time by increasing the samples to read.  You might try using the value of -1 for samples to read.  This grabs all the available samples off the buffer every iteration of the loop.  In case you didn’t know, when you get an error in LabVIEW, it is often helpful to use Help » Explain error.. to help troubleshoot what types of things you can try to eliminate the error.

In regards to your questions about the producer/consumer application, "Can I read the info from the DAQ assistant into the queue in a producer loop and write, view and calculate data in the consumer continuously?" Yes.  The point of the queue for your application is to separate your loop for analog input data acquisition with the loop for calculations and analog output.  The first things I would look at are the templates that can be found in LabVIEW.  Go to File » New... » VI » From Templates » Frameworks » Design Patterns and take a look at the different templates for these ideas.  I would also recommend taking a look at the Master/Slave Design Pattern.  It uses notifiers instead of queues which might work better for your application.  The reason I recommend trying notifiers is because they pass the most recent data where queue would just pass the next data point in line.  A queue takes in all the data in a line so that when you dequeue the data it will just take the next element in line.  A notifier stores just the most recent piece of data and throws out the old.  So, when the “wait on notification” vi is executed, it just grabs the most recent data instead of the next data in line.   This will allow you to calculate your analog output value based on the most recent analog input values.  This will essentially make the program adjust to possible lag time.

In terms of program flow, I would recommend the following.  First, you will need to have the "master" loop take in your analog inputs and either use notifiers or queues to send the data (specifically from the one analog input your using as a reference: take a look at the split signals vi) from the analog input loop to the “slave” loop.  The “slave” loop will then be used to grab the most recent data, or the next in line if using queues, from the analog input and use it calculate the analog output.  This allows you to keep the analog input loop running at a decent rate without slowing it down by your "slave" loop which is doing analog output updates and calculations. 

In terms of lag time, there is always going to be some lag time between your analog input and your analog output.  It is going to be the sum of the analog input measurement time, the calculation process time, and the time it takes to output that data to an analog output.  What we are trying to do is find ways to reduce this "lag time" to as little time as possible by making your code more efficient.  By taking out express VI's like the DAQ assistant, we can avoid having to create a new task every iteration of the loop and initialize that task.  By setting up the DAQmx task prior to the loop, the only thing the DAQ driver is doing during each iteration of the loop is executing the DAQmx read.  Another example is with the comparison express vi.  If you can do the specific comparison directly, you can eliminate some extra processing time that is used by the comparison express vi. 

I hope this helps,
Paul C.

[JennaU]

Hi Paul,

Thanks again for your very thoughtful and helpful reply.  Before I start to tackle this I was wondering where the write to file should appear.  I am going to be writing all of my analog inputs as well as the analog output to the same file... can this be accomplished through another slave loop or should it appear with the comparison calculations?

Also, in reading up on master/slave configurations from NI Developer Zone articles, I found that the master loop ideally contains user interface events (UI).  Is the DAQmx read in one loop then considered to be the master loop?

Thanks

Jenna  

[Paul_C.]

Hello everyone,

This person has contacted National Instruments for support.  I will post back the final resolution when the issue has been resolved.

Thanks,
Paul C.

[JennaU]

I contacted NI support hoping to find some examples of queues (or notifiers) being used with AI and AO and they provided me with one.  The design templates helped me understand the subVIs and how queues work... but I was still unsure of how to modify it for my application.  I really do appreciate all the help I've gotten from this discussion board and have implemented Paul's suggestions into my programming. 

I've attached my VI as it stands right now for anyone who is interested.  I appologize if it is a little bit messy.

Data seems to be passing nicely into the consumer loop with the calculations (can see this with the Analog Out graph), but the AO doesn't seem to be updating while the VI is running (AO voltage wired to AI seen in the Gate voltage graph).  This might be because of the way the VI is wired... but I'm not sure.

I can post the final VI when it is finished.

[VincentTSWong]

Hi Paul,
    I am having similar problem also, but am using VB6. Can you kindly guide me through?
My application is such:
>> AI0 monitors voltage
>> AI1 monitors current.
>> the two AIs needed to run concurrently(multiplexer delay is still acceptable)

Is there any way I can get it done? I had searched through the net and spent a lot of time to go through the fundamental,
but no progress yet...

Thanks.....

Best regards,
Vincent