hardware timed loops on X Series cards

[krivan]

Hi,

as the attached image refers about it I have three embedded for loops with a while loop around. I need to set their specific microsecond timings and this is why I ask for help because it can only be done by hardware timing.

The inner loop should fire in every 4 us [250kHz], the middle loop 16 us, and the outer for loop ~ 1 second.

I have an X series PXIe-6358 and I thought of somehow using the signal of the on-board 10MHz clock source like I keep running a loop at the 10MHz speed and every 40th firing of that loop could deliver the 250kHz sample clock. How is such an application done on an X series card? If there is a way I would prefer avoiding the use of the on-board counters as they are already occupied by measuring input signal frequencies.

Thanks,

Krivan

[krivan]

Can I receive some assistance regarding the topic above. I looked at many forum posts but somehow didn't get nearer to the right idea I suppose...

Kind regards,

Krivan

[Brad_K]

Hi Krivan,

What do you want the loops to do? The X Series board doesn't have a CPU, so it can't run the G code inside the body of a for-loop. It is possible to use an X Series to control a LabVIEW "timed loop", but the G code itself runs on the PC's CPU and for best results you would need LabVIEW Real-Time running on a second PC. However, the X Series board is perfectly suited to doing hardware-timed analog/digital input/output without running any time-critical G code.

Brad

[krivan]

Hi Brad,

the purpose of the for loops is data acquisition, the loops store the measured data into a 3D array, more specifically it is described here. If you look at the producer loop you find the three for loops I referred to above.  Because the need of specific frequencies the loops should fire quite exactly. 

I read about timed loops but I couldn't find the way to link it to my X series card. Unfortunately my hardware resources are quite limited so I can use only the computer that is linked to the PXIe-6358.

[John_P1]

Hi Krivan,

From your description and VI in the linked post it sounds like this is what you want to do:

That is, acquire 1000 points every loop from each channel, average the 1000 points, then index it into an array of size 1000 x 64 x 64.

However, I don't understand what you mean when you want to acquire 1000 points @ 10 kHz, but request that the inner loop execute once every 4 us.  It would take 100 ms to acquire that much data at your sample rate.

Best Regards,

[krivan]

Hi John,

brilliant code, thank you. With regards to the parallel for-loop, does the auto-indexing mean that the Labview automatically creates 16 instances of the for-loop and performs the averaging on each channel?

Regarding the sampling frequency you are right. So if I want to ensure that the inner and the parallel for-loops execute in every 4 microseconds I need to increase the sampling rate for example to maximum 1.25 MHz [800 ns] and take 5 samples at every acquisition. Is this correct?

Krivan

[John_P1]

That code doesn't use what is referred to as a parallel for loop but the auto-indexing does make it so that the loop iterates across the dimensions of our array.  So, for your 1000 x 64 x 64 array, the outermost loop will execute 1000 times in the above code.  The 2nd loop will execute 64 times.  The inner loop doesn't use auto-indexing, and will execute 4 times.

You won't be able to run the inner for loop as quickly as you want to due to the overhead of calling DAQmx Read, so setting this up as you have  now just described would overflow your DAQmx buffer.  You'd be better off reading back more data per loop iteration and filling a larger section of your array at a time.  I'm still not clear on your requirements otherwise I could offer more specific advice.  I just posted the previous code based on what you described in your other post.  What is the purpose of the 1000 x 64 x 64 array, it seems unnecessarily complicated comapred to using 16 x N array.

Best Regards,

[Brad_K]

John's VI doesn't ensure that the DAQmx Read or the averaging is done with any particular timing. The X Series board acquires samples with deterministic timing and enqueues them in a circular buffer in system memory, and the DAQmx Read VI dequeues the samples. As long as the circular buffer doesn't become full, the averaging can take as little or as much time as necessary, and you could probably increase efficiency by reading more than 1000 samples at a time. However, if you need to send the data to another thread within a specific amount of time, or write it to an analog output channel, it's a completely different story.

Brad

[krivan]

Now I don't understand what is not clear from what I've written or what information is still required [John wrote that my requirements weren't clear]. So I cannot do the 16 x N idea because I am reading out a sensor matrix and all data points of one reading should belong to basically the same time point. As I need to read out this complete 64 x 64 array in 1-2 ms continuously I have to force the inner for-loop to execute in every ~4us. The middle for-loop has to be consequently 16us. The outer loop should run until the predefined 3D array is filled up. This 3D array is then transferred to the consumer loop that streams it out into a file.

Now it is certainly possible to acquire more data so that the DAQmx Read doesn't need to fire so many times and the 3D array can be longer as well avoiding sending big data chunks to often but the original problem still remains.

Can you help me out with this hardware timing, how can I do it, how to achieve the specific timing, eventually a vi or a png would be also helpful.

Thanks,

Krivan

[John_P1]

Hi Krivan,

Regarding your original problem, the loops in LabVIEW are software-timed and non-deterministic (unless you are on an RT OS running LV RT).  However, this shouldn't matter as all of the data is buffered by the DAQmx task, which is hardware-timed.  The loop rate has nothing to do with the actual sampling of your data, which is controlled by a hardware clock.  DAQmx Read will block until the desired number of samples are available, so in a way it indirectly controls your loop rate.  However, running a 4 us software loop with a DAQmx Read call inside of it is unfeasible.

If you wanted to acquire enough data for a 1000 x 64 x 64 array approximately once per second, you would need to sample at ~250 kHz with no averaging.  So, given the max rate of the card is 1.25 MHz, going at max rate and averaging 5 samples would give you about enough data to fill your array every second.  Is averaging necessary?  You originally intended to average 1000 points, but now we are talking about averaging 5 points.

This is quite a bit of data to be manipulating on-the-fly in LabVIEW.  Your data is double precision currently (I highly recommend switching to I16 given what you've described so far), so at max rate this corresponds to 160 Million Bytes being loaded into your loop per second (40 million bytes if I16 instead of Double).  This data has to be scaled on-the-fly by DAQmx, then manipulated into your 64 x 64 x 1000 array which I still don't understand the purpose of.  As far as I can tell all it really accomplishes is make an extra copy of the data in memory (which we are using quite a bit of) and eating up processor time.

The resulting columns that you are asking for have samples that come from different times, since the 16 channels are interleaved and repeated 4 times per column.  If "data points from one reading should belong to the same time point", then the 16xN array should make more sense (at least to me) since every sample in a given column would come from the exact same clock edge.

Even once you get the array, we then have to write this data to file.  At the rates we've discussed, writing 1.25 MHz * 16 channels * 8 bytes per sample / 5 samples averaged = 32 Million Bytes per second.  That's pretty close to the disk write speed of standard 2.5" PATA drives.  You'd probably have to disable buffering and write data in a multiple of your disk sector size to even get close to the limit (even without any other processing going on).  Switching to I16 would be a very good decision, although you will have to keep track of your DAQmx Scaling Coefficients in a file header of some sort (it's a 3rd order polynomial that's accessible through a channel property node).

Alternatively...

DAQmx Configure Logging takes care of just about everything mentioned above except manipulating the array dimensions and averaging samples together.  If you just want to log data continuously to disk, it could be as easy as running a shipping example.  As far as I can tell, post-processing should still be an option for you if you want to change the way the data is organized.

Best Regards,