Compatibility of Pattern I/O with a PXI-6533 card with real time application

[Frank B.]

Hi,

I use a PXI-6533 card on a chassis with a PXI-8145 RT controller. I want to acquire 32 bits of data with this card at 1,25 kHz. These data are generated by an external FPGA card together with a clock signal. Referring to the 6533 documentation, a simple way to synchronize the acquisition is to use pattern I/O, entering the clock signal on the REQ pin. I tried the LabVIEW example Cont Pattern Input.vi. It seems to go well, but it does not work when I change this .vi priority to Time-critical or any higher priority than normal. Is there an incompatibility between this type of acquisition and real-time ?

[Cyn]

Hi,

do you have only one critical loop?
Is there an arror code generated when the VI doesn't seem to work? Which version of LV RT do you use?

Thanks in advance for more details.

[Frank B.]

Hi,

I actually have only one critical loop, that is the Cont Pattern Input vi, that I run targeted on the PXI. It doesn�t give any error code, I only lose the communication with the PXI and I have to reboot it afterwards. I use LV 6.1 with the RT module and NI DAQ 6.9.2.

In fact, from a more global point of view, the idea of my application is to read the 32 bits of data at a 1,25 kHz rate, process them through a digital PID and, at the same rate, which seems to be a great problem since the acquisition is buffered, generate a correction on one analog output of a 6052E card.
If you have any idea to solve my problem, it is welcome ! At this time, together with the fact that I can�t run the example in time critical priority, the acquisition buffer (th
at I check with the scan backlog) gets full too fast, and I think it could be the origin of the problem.
Thanks in advance for your help.

Frank

[Cyn]

Hello,

just put a wait until next ms function with a constant of 1ms in the loop and it should work.
The problem is that if you don't put any tempo in the time critical loop, you have no time to do anything else and you won't be able to stop your application.
That is why you have to reboot your PXI.

Hope this helps.

Cynthia Arickx
National Instruments France

[Cyn]

Hello,

you just have to add the wait until next ms function in the loop (for instance witha constant of 1ms). The problem if you don't put any tempo, is that LabVIEW won't do anything except reading data from 6533 board. LabVIEW won't be able to do anything else. By putting this fonction, LabVIEW release time for other tasks.

Hope this help.

Cynthia Arickx
National Instruments France

[Frank B.]

Hi,

Sorry for this late answer, I effectively added a �wait until next ms function� in the time-critical loop and it seems to work. In fact, I don�t see exactly how, but it works with 1ms up to 50 ms.

Nevertheless, the next step is to add the content of this example in a more complex system with a communication loop to transfer the acquired data to the Host PC. I already have such an architecture, with a �time-critical priority� .VI to read the data at 1.25 kHz and a RTFIFO to transfer them to a second �normal priority� .VI loaded on the PXI, that ensures a TCP communication with the HOST PC. This architecture works correctly on another application with an internal clock, BUT doesn�t with this example, even with your solution.
In
fact, it seems to work when I put the two .VIs loaded on the PXI in �normal� priority, but with a tremendous jitter (the frequency varies from 1 to 2 kHz) and a scan backlog that gets full very fast. Then, the PXI crashes as soon as I change any priority.
You�ll find attached these three .VIs and I hope this could help to find a solution.
Cordially

PS: Since we started this thread, I�m in relation with NI Support France on that subject. Nevertheless, we haven�t found any solution yet and any new idea is welcome !