Problems with real-behaviour on PXI-4461 card

[Juergen82]

Hi guys,

I have quite some problems implementing a real-time low level controller (see attached project) on my PXI 4461 card. 

1.) Since I cannot aquire a single data sample at a time, I use continuous sampling. Here the smallest portion of data points that can be read are 2.  To implement a contoller I need to use the actual data to calculate the output for the next timestep. I found a small workaround by just adding the two imput values and dividing it by 2 (small lowpass FIR filter) tolower aliasing effect. I limit myself therefore from 204800S/s to the hal, but that would work for my application. But here comes the first problem. The read input data are correct, but if I pass to the output they are somehow corrupted by a blockwise ringing, which can be seen in the two attached pictures. 

2.)  Since the effect gets smaller as the sampling rate gets higher (even though it still remains), I tried to go to maximum samping rate. But even though the loop of the time critical vi is doing nothing then reading and passing the data to the output, already at 50kS/s it is not possible to communicate with the target anymore since the loop uses to much resources. However, a check of the processer usage (with Real-Time System Manager) showes that just 50% are in use (NI PXI-8106). The 'Profile performance and memory window' shows that most of the time is used by the DAQmx Write VI. The time for the Read VI is neglectible small. Interestingly enough, if I add a constant with the value 2 to the 'number of samples to read' input of DAQmx Read vi (instead of letting it unconnected), the problem at the DAQmx Write command occures much earlier and also lowest sampling rates are not possible. For me here is the end of any logic, since 2 seams to me the 

3.) I do not really know what the DAQmx Read and Write commands are actually doing at the hardware timed moments, and cannot find it in any description of DAQmx. Are they just writing/reading in/out some buffer and go on, or are they actually waiting until the data are written or new data are received. If it is the second case, what times the loop then? I added a timing diagram in the attachment that would seam logical to me. It assumes that the Read VI waits for new data and therefore times the loop and the write command writes the data to a buffer where the hardware module uses them to the hardware timed moments. Is this timing correct? It does not seem so. What is the real timing.

Best regards,

Juergen Pfingstner 

[Marian_O]

Hello Juergen,

the PXI 4461 Digitizer is designed for DSA (Dynamic Signal Acquisition), like Sound and Vibration. The basically idea is not, to implement a controller with loop-rates up to 204,8 kHz! For controllers with such high frequencies, the use of FPGA-Targets (like cRIO) is recommended.

The PXI-4461 is capable to achieve that high sampling rates using an onboard buffer. This buffer is designed to hold up to 2047 samples per channel. Using (for example) the DMA-transfer mechnism, this bunch of data can be processed while the next package is aquired.

For the implementation of a controller, you do not need a whole package of data, but discrete values which have to be acquired, processed and send to the analog out.

DAQmx Read and Write can be used for this purpose, but you can do this only software timed, because you now only the next value. For getting higher sample rates, you have to know more values to pack them together and write them into the onboard output buffer of the PXI-4461. This is not possible, because usually, you are not able to "predict" the values, that will be calculated by your controller algorithm in advance.

Please, could you zip your images? I am not able to open gz/tar files.

Best regards

[Juergen82]

Thank you Maian,

If you look at my project I did exactly what you proposed. I read the smallest block size (2 samples) build the mean of these values and used it as an input for my controller. Also fo the output I write two times the same value. This procedure reduces the controller rate by a factor 2 compared to the sampling rate.  However, if you think that approach is not working, I can try a software timing.

For us it would be important to still set up an controller, first of all we want to use the hardware we already bought and second we need the 24 bit resolution which no other card provides. We do not need such high samping rates as 204,8kHz. Therefore, if I use software timing in connection with DAQmx Read and Write, what sampling rates will I be able to achive (what do you think) and more important will I still have the problem of big time delays due to internal buffers (because such additional phase can make the controller instable).

If such a software timed controller works (hopefully), still the problem shown in the pictures attached remains. 

Best regards,

Juergen

[Juergen82]

And here are also the deterministic (time critical) and communication labview files for the target system. The Host Vi is also attached even though it is uninteresting. If you need the whole project let me know, then I will download a tool to .zip the files.

Best regards,

Juergen 

[Marian_O]

Hello Juergen,

some more details: the PXI-8106 Real-Time Controller uses a Dual-Core CPU. 50% CPU usage could mean, that one core is at 100%, the other one near 0%. In your case, the DAQmx Read/Write Loop is processed with maximum usage of one core, because you are giving the CPU no sleep time in your loop.

Using Software-Timing under Windows, you may achive update rates of single values up to a few ms, but take care of jitter produced by other threads running on the machine.

Under RT-Targets, you will achive higher update rates.

[Juergen82]

Hello Maian,

The information about the 50% CPU usage helped me. I see the problem now, that the time critical process is always using the shared variables and so the communication VI, even though it would have time to run on the second processor, never get the access right to write in them. So summing up there are just two problems remaining:

1.) Corrupted data as in the pictures

2.) Very long time delay, which causes to much phase advance.

In fact not the sampling rate is limiting my application, since I just need to control up to maybe 200Hz (so 10kS/s would probably enough), but the phase advance (=time delay through buffers) that limits my application to a few Herz!

Juergen 

[Marian_O]

Well, let's go ahead with Number 1: corrupted data.

It seems to me, that your analog out repeats two given values around 8 times, thats the reason for the "zig-zag"-line. Could you change your analog out setting from "Continous" to N-Samples with 2 samples each?

[dsb@NI]

Can your control requirements tolerate the known sample delay of the delta-sigma converters used on the 4461? We use the 4461 extensively for stimulus-response measurements where we need to know the delay in order to perform accurate measurements, but the absolute delay is not so important. The delay is a function of the update/sample rate but will be on the order of ~1 ms. Might that lead to an unstable controller in your case?

[Juergen82]

Well, 1 ms creats 72 deg phase advance at 200Hz, which is not extremly critical for stability, but already limits the useable bandwidth and therefore the tracking performance. Also I fear that it will be a bit more than 1 ms since I cannot use the full sampling rate.

If there would be a possibility to reduce the delay at would be definitly much better to do so.

Juergen

[Juergen82]

Thank you for the tip Marion. I will try this in one of the next days.

Juergen