Error 200278 - When using a waveform generator in a PID controller

[bjohnson]

Hi,

I am trying to build a VI for a test rig.  It should be able to control a valve based on a load cell or position input.  I am using LV 7.0 and do not have access to any of the controls toolboxes.  Therefore, I built a very simple PID controller in a case structure.  The problem is that if I want to capture the position and load cell data continuously I get the error -200278 when trying to compare the input values with a target waveform generated by LV.  The sample rates are the same, but there is something else that I am missing.

I have attached what I have so far and would really appreciate any help.

Thanks...

[Ray.R]

Have a look at this Knowledge Base article "Error -200278 at DAQmx Read"

Although not necessarily applicable, you may want to look at following example program in the Example Code Library on ni.com.

As well as this article NI-DAQmx: Continuous Analog Input with Both Start and Reference (Stop) Triggers

R

[bjohnson]

Thanks for the quick reply.  I read over those before I posted to try and cover all my bases, but to no avail.  The way that my instrumentation is set-up I don't have a way to setup start and reference triggers.  The rig will be run for a certain duration of cycles (fatigue testing) so continuous sampling is what I believe I need.  If there is a better way to setup the PID controller I am all ears.

[Sappster]

Hi bjohnson,

The reason you are getting that error is because the buffer is being filled quicker than it is being read, therefore you are getting a buffer overflow. To avoid this you need to either increase the number of samples to read or decrease the sampling frequency. I noticed that you had the task configured to read only 1 sample, but where using a n sample read function. If you are expecting to read multiple samples each time the read function is called you should increase the samples to read in the task configuration.

Another suggestion, is to create a producer consumer loop so that your acquisition timing is not limited by your time consuming PID calculations. For more information about producer consumer loops read this article:

http://zone.ni.com/devzone/cda/tut/p/id/3023

[bjohnson]

Mark,

From my understanding of the help document, if you are sampling continuously LV determines the buffer size for you.  For a sample rate of 1 kHz, the buffer size would then be 10k samples.  Even if I manually set the 'samples per channel' to be 100,000 samples, I get the same error.  Would a producer - consumer loop solve this issue?

Thanks,

Ben

[Sappster]

Hi bjohnson,

LV will determine the buffer size, but not the samples to read size. The number of samples to read is a limit that when reached triggers and event in software and tell the program to read the buffer. You don't want this to be too small or to large. If you have the samples to read set at 1 sample, then the software receives an event trigger every read (a.k.a. the sampling frequency) and therefore has to be able to respond just as fast as you are sampling to prevent the buffer from filling. If the buffer is too large, like if you set it to the maximum, then the software has the same issue because it has to read the entire buffer before the next sample is read and overwrites the buffer.

The reason you are gettng this error is based on how the DAQ read vi operates. When you call the DAQ read vi it checks to see if the hardware has triggered the read event and if not it waits for it until the specified timeout. In your code the event triggers are piling up and the read vi isn't being called frequently enough to read the buffer before it is overwritten. The while loop in your code will not be able to execute at 1KHz so the software will not be able to keep up with the buffer and it will overflow.

Try just increasing your samples to read to 100 and see if you run into the same issue.

The producer/consumer loop will help because it will reduce the amount of time it takes for the loop to iterate therefore increasing the frequency of reads.

[bjohnson]

Thanks Mark, I understand now.  When I use a sample rate of 1000 hz and 1000 samples/channel for the DAQ read and the same parameters for the sine wave generator I get the aforementioned error once, but after clearing it the VI works great.  I am guessing this is due to the sample threshold being filled.  What would be the proper way eliminate this from happening?

Also, the above parameters of 1000 samples for both the rate and 'samples per channel' for the DAQ read and sine function generator is the only way I can get it to work.  Becuase of how slow the test rig will operate I would like to sample at 20 hz or so.  Any idea of why only one setting is working?

[Sappster]

Hi Bjohnson,

If you make a copy of this file and delete everything in the while loop except for the DAQ read function, do you still see the error? If so the producer consumer will help because then your acquisition won't be waiting on your calculations.

Can you explain what you mean by:

 "Becuase of how slow the test rig will operate I would like to sample at 20 hz or so.  Any idea of why only one setting is working?"

Do you receive an error when you set the sampling rate to 20?

[bjohnson]

Alright, it looks like I may have solved this problem *knocks on wood*

I wired the 'samples per channel' constant to both the DAQmx timing and read blocks.  I believe the timing read block was trying to read at a higher rate than the timing of the channel would allow.  Now I am able to select any sample rate and have the VI work.  I attached the new VI for the achieves and to see if anyone can point out any glaring mistakes.

Thanks again for all the help!

-Ben

[bjohnson]

Alright, next issue with my VI.  Since I don't have access to the controls toolbox, I am using a PID controller I built that compares the sampled data with a sine wave generated by LV.  The problem is that the generated sine function is not produced in real time (much faster than real time).  This will cause all sorts of problems with the controller and test rig.  What is the best way to slow the generated sine function to real time?

Thanks in advance...