PID loop rate with counters

[balki]

I'm not really sure I understood your question, but I'm guessing that you are confused how the board actually reads your points without configured timing or without a buffer?   If so I would direct you to the DAQmx help->NI-DAQmx Key Concepts->Counters->Configuring a Displacement Measurement with NI-DAQmx:

Configuring a Displacement Measurement with NI-DAQmx

<SCRIPT type=text/javascript> </SCRIPT>

To configure a measurement, specify the initial sensor position through the Initial Angle attribute/property. You also can specify if the Z Input Terminal is used with the Z Index Enable attribute/property. You can configure the reload position on a Z index, and when a Z index position should cause a reload to occur in relation to the A and B signals, by using the Z Index Phase and Z Index Value attributes/properties, respectively.

When performing a single point, or on-demand, displacement measurement, you first arm the counter by calling the Start Task function/VI. Each subsequent read returns the current position of the encoder. If you perform multiple reads without first starting the counter, the counter implicitly starts and stops with each Read function/VI call, and the position is not recorded properly between read calls.

With a buffered displacement measurement, the device latches the current position onto each active edge of the sample clock and stores the position in the buffer. There is no onboard clock for buffered displacement measurement, so you must supply an external sample clock.

[hkowalczyk]

Balki,

thanks, I'm using the encoders to measure the speed, thus my need to use the frequency counter function instead of the regular encoder functions.

Thanks
Henri

[balki]

Well then, the answer to your question is in the section next to it:

#################################################################################################################

Configuring a Time Measurement in NI-DAQmx

To configure a measurement, you specify the expected range of the input signal. Based on this range, NI-DAQmx automatically picks the internal timebase that provides the highest resolution for your measurement and uses it as the counter timebase. You also can explicitly specify the source of the counter timebase by setting the Counter Timebase Source attribute/property and the rate of the timebase by setting the Counter Timebase Rate attribute/property. For more information on where to connect input signals, refer to Connecting Counter Signals.

To perform buffered time measurements, use the Timing function/VI with the Implicit timing type. After the acquisition begins, NI-DAQmx consecutively measures each sample of the input signal and stores it in the input buffer. Due to this consecutive measurement, the rate of the input signal implicitly determines the rate of the acquisition. Depending on the phase of the input signal in relation to the start of the measurement, the first sample of buffered measurements is often invalid. For instance, if you are performing a buffered period measurement, and you start the measurement when the input signal is halfway through its current cycle, the measured period for the first sample is half its expected value. Subsequent samples indicate the correct values because they are guaranteed to be taken after a full period of the input signal. For this reason, the first sample of buffered period, pulse width, and semi-period measurements often indicates a smaller value than the actual value. For buffered frequency measurements, the first sample often indicates a higher frequency than the actual frequency.

With bus-powered M Series USB devices, such as the NI 6210, NI 6211, NI 6212, NI 6215, NI 6216, and NI 6218, you can take buffered time measurements with the sample clock timing type. After the acquisition begins, your device consecutively measures each sample of the input signal but does not store it to the input buffer unless there is an active edge of the sample clock source signal. Using this timing type, the sample clock rate determines the acquisition rate rather than the input signal. With this buffered time measurement method, all measurements returned are a valid, complete cycle of your input signal. Using this method, you can measure signals that are much faster than your sample rate, which minimizes the amount of data transferred from your device to NI-DAQmx.

For non-buffered time measurements, calling the Read function/VI initiates the measurement and returns the next valid sample. Calling the Read function/VI repeatedly does not return consecutive measurements of the input signal.

#################################################################################################################

Essentially, this means that the hardware will work the same and give you a valid measurement, but unlike buffered inputs, 2 read calls do not return 2 buffered data points.  The hardware starts, takes a measurement, and stops, and the driver returns that measurment to the user, thus the 2 reads have non deterministic correlation in time.  But like I said before, since your just grabbing the oldest sample out of your buffer anyway, it appears that you don't care about how the reads are correlated.

[hkowalczyk]

Balki,

Thanks for the help.  Do you mean like the attached picture?  I tried it that way and unfortunately it's slower by about a factor of 3 over doing the buffered measurements.

Thanks

Henri

[Kevin_Price]

Not sure but here are some speculations:

1. Though not configured for buffered reads, you're still requesting a 1D array of N Samples.  I'm really not sure what to expect from the DAQmx Read vi in that case.

2. The Help text balki quoted indicates that an *unbuffered* read will return the NEXT sample.  Trouble is, with frequency measurement, the external signal *defines* the sampling interval, so you can't always predect how long you'll need to wait for that next sample.  It seems that this mode could slow down your RT loop rate.  Even though the Read call has a 'timeout' available, I don't expect *that* will give you very good timing resolution or deterministic timing.

   If this is the key factor, I'd point you back to some of my comments earlier in the thread.  Maybe you'd benefit by doing a buffered acquisition but specifically reading only the most recent sample(s) that you wouldn't have to wait for.

3. You mentioned RT at the beginning of the thread.  I noticed that you're writing directly to an array indicator here rather than a shared variable.  I haven't done RT in a few years, but that kind of construct might slow things down when running from the development environment.

-Kevin P.

[hkowalczyk]

Kevin,

1 - Yeah I guess I wasn't paying close attention, I just deleted the buffered part from my original, thus kept the array.  I'll try it again, but somehow don't think that will get me a 3x speed improvement!

2 - Yes you're right it does slow it down quite a bit.   Unfortunately reading only the latest sample has very little impact on the speed. I've tried changing the buffered lenght form 1 to 10000 and it has minimal impact.   In reality, if I'm reading the buffer fast enough it has to be very small.

3 -  the indicator was just a quick and dirty sample, and funny enough has very little impact on the performance of the loop, as compared to the actual reading of the frequency.

I'm pretty much resigned to the fact that I have a very accurate and expensive way of measuring high frequencies at a very SLOW rate! It just seems strange that I would  be the first person trying to write a control system with RT using encoders to measure speed?! There seems to be something fundamentally wrong about the way that frequency is measured with Daqmx because it is much slower than just doing counting functions.  Also, if you look at my previous post I mention the tremendous performance drop when using certain scaling factors.  very strange stuff indeed.

-Henri

[Kevin_Price]

Just a couple more thoughts.  Don't expect much, but shouldn't take long to try...

1. Since you observed some speed issues with scaling, maybe you should do your counter reads as U32 values.  That's gonna get you closer to the metal since the count registers are 32-bit ints in hardware.

2. Even though freq measurement and period measurement amount to pretty much the same thing at the counter hardware level, I've always used period measurement because I got used to thinking that way under DAQmx.  I don't particularly care for the API into freq measurement because it usually complicates things for me.  I would almost always have to change a bunch of DAQmx properties to override the default settings.  So anyway, my impression of freq measurement is that more stuff is being done under the hood and behind my back that I don't need and often don't want.  I could very easily be wrong, but I carry an abiding suspicion.
   All that to say this: try setting up your task for period measurement and read U32 values.  Defer any numeric scaling to your parallel consumer process to keep your time-critical loop as lean as possible.

Hope it helps, but I gotta admit, I'd be kinda surprised.

-Kevin P.

[AlexDubya]

In my current configuration I'm using a specialized FPGA to do fast sampling but going back to the beginning of this thread:

Why does NI Advertise 70KHz+ on this page http://zone.ni.com/devzone/cda/tut/p/id/5423 for PXI using DAQmx, RIO, etc ? Is 70KHz not a PID update rate? Can we do any control loop (i.e simple proportional control which takes 1 float point multiply) at close to 70KHz?

[hkowalczyk]

Alex,

You can get that rate if you are using analog inputs. the issue for me is that the counter is too slow, and thus I can't close the loop fast enougn.

-Henri

[hkowalczyk]

Were there any updates to the counter code in any subsequent versionso of Labview after 8.5  that might increase the performance of my PID loops?  Might consider upgrading the software if that was the case.

Thanks,

Henri