Sensor Sampling Rates and divagations
 

This is an issue that bugs me ever since I started using LabVIEW: Sample Rates.

If we use the Get Sample Rate of an analog sensor, we will see values such as 50kHz, which is a common rate for any DSP application. BUT when we actually use the sensor readings, they are called in while loops with frequencies such as 100Hz or even slower (at least in all examples I found), which, I think, throws away almost all the samples. I want to know if I’m the only one bugged by that. I mean, it seems like there’s a resistance in creating a loop that runs in a higher frequency.
Any DSP application would require a higher sampling rate, but when I try creating loops with higher frequencies, such as a second order Lowpass IIR filter in a 2kHz loop, or even much processing-simple tasks, I realize the task is too much for the processor, how come?
I discovered it by comparing the actual running time with the time the loop thought it was in a plot. When the actual running time was 12s, the graph displayed something around 5s (I supplied the graph with the correct deltaT in the cluster, before anyone asks).
Anyway, I need to understand why it seems I am stuck in this millisecond world while working with such a powerful machine as cRIO.

Maybe there are some misconceptions in the text above, I would much appreciate any enlightening in this.

Re: Sensor Sampling Rates and divagations
 

Hi Daniel,

I think we first need to get on the same page about what the primary programming model I was looking for... that will help to illustrate some of the trade-offs. The fundamental goal was a system that could run critical processes in the FPGA at high speeds and allow the user code to not need to keep up with those rates. This is a departure from a system that has no FPGA for I/O support or otherwise tightly couples the execution of the processor with the I/O. As such, the interface to the FPGA is designed to be single-point in all cases feasible. This means that you can read the current position of an encoder any time you want or you can read the state of an accumulator any time you want without needing to ensure that you don't miss a sample. When you get the sample rate and see a number like 50kHz, that is the rate that the accumulator and the analog triggers and other systems are handling analog data in the FPGA. It makes the programming task easier for students, but it does take away the flexibility to do things like run a custom filter at 2kHz.

In a system that provides high throughput to the processor, you would not initiate a read over PCI to the FPGA for every sample. In order to achieve those rates you need to employ DMA and buffers of samples. I anticipated some advanced users wanting this capability, so I implemented a DMA engine in the FPGA to move samples to the PowerPC in a more efficient and lossless way. Because it must work within a design that is primarily single-point, it is not as efficient as you may expect, but it is much better than calling read for each point. Unfortunately, it is only implemented as a top level API in LabVIEW, so if you are using C++ or Java, you will have more work ahead of you to interface the FPGA classes directly. In LabVIEW, take a look at the DMA examples.

Best Regards,
-Joe

Re: Sensor Sampling Rates and divagations
 

Thank you very much. I'll look into DMA.

Also, I tried running an IIR filter in my computer instead of cRIO, creating a blank VI. I put a knob as an input and a second order lowpass and started flipping it around to simulate a signal. I found the same problem as in running in cRIO in a frequency as low as 1kHz .. should I experience that in an I7 processor?

BTW, I also tried using a timed loop in this blank VI and the max frequency available to me was 1kHz. The 1MHz clock is shaded and can't be selected, why? Is there a way to enable it?
I noticed the 1MHz is available in cRIO, I'll see what can be done. Maybe I'll achieve higher rates with it (?)

Re: Sensor Sampling Rates and divagations
 

Would it be possible to post the VI? There are a number of things that can slow down the execution of the VI, and I don't believe it is just the IIR filter you are measuring. On a VM'd laptop, I placed a butterworth filter in a loop and ran with no delay at about 500KHz.

Greg McKaskle

Re: Sensor Sampling Rates and divagations
 

Here's my code:

Re: Sensor Sampling Rates and divagations
 

There are a number of issues contributing to what you are seeing, so I'll start by saying that NI does I/O in two different ways -- SW timed and HW timed.

HW timed I/O uses clocks on the board to sample the signal and store the value into board RAM. The PC driver and/or board ASICs will acquire the PC bus and move board memory into driver RAM and eventually into a buffer that can be accessed by a user program. The timings are accurate, the measurements are accurate, the throughput can be quite high, but these are not realtime measurements. The other name NI uses for this is a buffered measurement. The data buffers are typically available within a few ms, and the consumer PC can then filter, trigger, perhaps do control, but with the knowledge that there is a bit of lag and that the output rate is not the same as the acquisition rate.

SW timed I/O allows the user program to request a point at any time. This may be based on a screen button being pressed, a key, a trigger of some other measurement, or an OS timer. On realtime targets, the resolution and consistency of the OS timers is far better, and you can start to get the point-by-point processing at pretty high speeds, with good determinism using SW timing.

Looking more closely at the timing, you mentioned the timed loop, but the code you posted used two types of SW timer, the Wait ms, and the Express timer (blue one). The one you wired 100 ms to is the Wait ms, and as the name implies, it takes an integer number of ms and throttles the loop to no faster than that period. The OS has no guarantees, so the timer doesn't either.

The blue Express timing block is a beginner block that does the scaling for you, but is just a wrapper on the Wait ms. You can see this only if you right click and look at the Front Panel. As with the other block, once it adjusts to ms, it changes to an integer type. As the period shrinks to 0.5 ms, you get rounding into the node and this is why your panel showed that your loop actually ran more iterations than it should have.

The timed loop is a structure designed for the realtime OSes, but also made to work to some degree on desktop OSes. The timed loop can be driven by a selected timing source and has a number of calculations and scheduling policies available to you. If the OS has a way to sleep or schedule at microseconds, the loop exposes it. For Windows, your clock choices are limited, but the loop does offer better policies for adjusting the calculated period to achieve an overall rate. Obviously the timing between individual points will have the noise from the scheduling clock being used.

The not surprising summary of the timing area is that desktop PCs are readily available and can be made to do a good job at certain types of tasks, but unless you remove the desktop OS or supplement with another micro and OS, they don't do realtime at small periods -- below a few ms. This is why NI and other vendors sell add-in products that plug into the PC. NI doesn't have much of a DSP offering, but instead offers a variety of products from plug-in boards with another micro, cRIOs, PXI, and other RIO products that instead offload to an FPGA for even lower periods and lower jitter.

Different from the timing, I was also going to point out that the loop you uploaded does lots of memory allocation and additional calculations inside the loop. It accumulates the slider value to the end of a growing buffer, reverses the buffer, filters the buffer into another growing buffer, reverses that buffer. Sending the entire buffer to a graph rather than just new points to a chart also causes extra overhead. Finally, the coefficients for the filter are being computed each time as well. The real issue is the timing source for scheduling, but when you start running on a realtime target, you don't want to resize a 10,000 point double precision array 2000 times a second.

I hope this answers some of your questions.
Greg McKaskle

Re: Sensor Sampling Rates and divagations
 

Thank you very much, you've been very helpful.

Yes, I used the express timing block because it was the only one that (apparently) would deliver a timer with less than 1ms, since the input is not an integer number, now I see it doesn't.
I guess there's no way around it.. I didn't use the timed loop structure because it's limited to 1kHz, what I didn't know is that I am also limited by 1kHz either way.

About the last paragraph, thanks for the tips, I'm going to make it more efficient. Is there a way to limit the size of an array from the start? let's say, 1000 positions. I guess if I use "Delete from array" block, the samples are still going to be there, but not being used, so there's going to be memory allocation anyway.

Re: Sensor Sampling Rates and divagations
 

If you are looking to avoid resizing, you can use the init or reshape array blocks to allocate in advance, and then use array replace to update a particular element. LV has some features for bounded and fixed size arrays, but honestly, I've never had much luck using them.

The other approach is to not use arrays as much. The signal processing palette has a point-by-point filter, and the chart has an internal circular buffer, so you can then wire a single point and any storage is private to those areas that need it.

Greg McKaskle

Re: Sensor Sampling Rates and divagations
 

I just switched to a point-by-point filter and eliminated all arrays. It's clearly way lighter, I could implement a 5th order at 1kHz with no lag.

Sorry to insist, but have I understood correctly that there's no way to get a microsecond timer in my OS (win7 64)?

Re: Sensor Sampling Rates and divagations
 

No problem asking, right.

As far as I know, there is only a millisecond thread sleep on Windows. I'm not on the RT team, so I don't know the technical viability of doing this someday, but reading the help, the current version of LV does not support it except on some of the RT targets.

Greg McKaskle

Re: Sensor Sampling Rates and divagations
 

I believe if you have DAQ hardware, you can use it as a timing source and go faster than 1kHz on desktop machines. Probably not what you're looking for, though.

-Joe