06-03-2019 12:07 AM
In my experiment, I want to make real time (short time delay) analog I/O system.
I'm using cDAQ-9202 ( Analog input) and cDAQ-9264 (Analog Output) modules with 9174 chassis.
These modules have 10 kHz/s/ch , 25 kHz/s/ch sampling rate respectively, and I made my code with reference to Labview example code ( "continuous voltage input" and "continuous voltage output")
I expected that if I set the 10 kHz I/O sampling rate and 10000 samples (=1 s) for buffer size, there is around 1 s delay.
But, it gives over 5 seconds delay, even I just make data pass through without any data processing between input and output.
Moreover, with 10 kHz I/O sampling rate, if I set the 100 ~ 1000 samples for buffer size, it gives following error.
Error -200279: The application is not able to keep up with the hardware aquisition.
Now, I'm notice that there is some limitation for real time task with PC based DAQ system because they have to use PC memory and memory bus (I dont know detail.)
But still, over 5 seconds delay seems non-sense...
Is there some problem in my code? or some alternative way for configuring the real time analog I/O system?
P.S
Used laptop have i5-8250u CPU and 8 Gb RAM.
and Ideal time delay is under 0.1 ms in my experiment.
Even hard to reach to this short time delay with my hardware, I want to reduce as possible.
Help me !
Solved! Go to Solution.
06-03-2019 12:49 AM
The Samples per Channel determines the buffer (as you may have already read in the Help pages) and you want to mainly focus on ensuring that your loop can run quickly (so relatively few samples compared with the sample rate) whilst avoiding problems with the output.
One possible solution to this issue (at least decoupling the acquisition and output) is to use a Producer/Consumer design. This would allow your Reads to pass the values to the Write node without then having to wait for the Write to complete, preventing strange buffering effects from building up.
Maybe you can try that and see if it improves matters?
06-03-2019 05:42 AM
@livon_D wrote:
and Ideal time delay is under 0.1 ms in my experiment.
If that is your requirement, you definitely need to move to a cRIO format. I would probably go with the 9147 Ethernet expansion chassis. Then you program the FPGA on the chassis to do your read, process, and write. This will reduce your delays the most.
06-03-2019 07:57 AM
@crossrulz wrote:
@livon_D wrote:
and Ideal time delay is under 0.1 ms in my experiment.
If that is your requirement, you definitely need to move to a cRIO format. I would probably go with the 9147 Ethernet expansion chassis. Then you program the FPGA on the chassis to do your read, process, and write. This will reduce your delays the most.
Ditto that!
It is that "Ideal time delay is under 0.1 ms in my experiment." requirement that drives you to a FPGA. An RT system could do well at 1 ms if properly structured but "Ideal time delay is under 0.1 ms in my experiment." mandates an FPGA that can close a loop at near 0.001 ms depending on the performance of the hardware you are using (analog takes longer than digital).
Now if you do NOT have to react in less than "0.1 ms" Windows can keep up with input and outputs fine if your code is structured correctly but "read-Compute-Write" will be "an exercise in futility" running in Windows.
Trying to help,
Ben
06-04-2019 04:20 AM
thank you for replying !
06-04-2019 04:41 AM
@crossrulz 작성:
@livon_D wrote:
and Ideal time delay is under 0.1 ms in my experiment.
If that is your requirement, you definitely need to move to a cRIO format. I would probably go with the 9147 Ethernet expansion chassis. Then you program the FPGA on the chassis to do your read, process, and write. This will reduce your delays the most.
Firstly, thank you for replying !
Actually, I have no idea about FPGA, so can you give me more detail ?
As I know, FPGA is just programmable chip,,, Is there specific device or model which mountable in 9147 chassis.
Maybe it's hard to specify, and have to know more experimental detail, right?
it would be great if you give me some reference about general information for FPGA system.
Thanks a lot!.
06-04-2019 06:00 AM - edited 06-04-2019 06:16 AM
The pseudo-bad news is that typically you can't add FPGA modules to a C-series chassis. They're an in-built component of cRIO chassis.
The much better news is that the NI 9147 is a cRIO chassis, and you already have an FPGA.
You can add it to an existing project by right clicking on the Chassis element of your real time target and choosing to add a Target. This page might be helpful (no promises): http://zone.ni.com/reference/en-XX/help/372614J-01/lvfpgahelp/adding_an_fpga_target/
If the link gives a different name than I said, trust the link. I don't have a pc to hand to check.
For basic tips getting started on FPGA, see this tutorial: http://www.ni.com/tutorial/14532/en/
Here's a screenshot adding the FPGA.
06-04-2019 06:16 AM
@cbutcher wrote:
The much better news is that the NI 9147 is a cRIO chassis, and you already have an FPGA.
Unfortunately some digits were transposed. the 9174 mentioned is sadly a cDAQ 😞
06-04-2019 06:19 AM
06-04-2019 11:25 PM
Thanks guys.
Then,,, If I have 9147 chassis and FPGA software module, can I use FPGA system directly?
(Of course, I will make some FPGA embbeding code or ,,, something I need.)
I briefly checked the cRIO devices,,, and it seems to need a cRIO controller.
What is difference between them, cRIO controller and chassis, and which one is what I need for FPGA based real-time processing?
Only chassis? or controller?, may be not both.
I appreciate all your comments.
P.S Devices I have are 9174, 9202, 9264. that's it.