When two acquisition cards run in parallel, one acquisition card always runs at the highest sampling rate and cannot be changed

[JHUN-KULI]

Hello everyone, I have a problem in data collection. I want to collect the data of NI9232 and NI9237 in PARALLEL in FPGA and read it in RT terminal. During the test, there was no problem for each acquisition card to collect separately, but when I combined the program into a FPGA, the sampling rate with one acquisition card at the RT end could not be changed (increasing or decreasing the value of the sampling rate button, the program sampling rate remained unchanged). I tried to run only one acquisition card FPGA program on THE RT side, and it can run normally. I have attached my collection program (the program is based on LABVIEW routine, the interface may be a little ugly, because I have tested it for many times and I am in a bad mood, please do not mind), I hope you can give me valuable advice, thank you!

The current situation is that the 9237 can change the sampling rate and then load the FPGA to run, and the 9232 always runs at the maximum sampling rate, no matter how MUCH I change the sampling rate of the 9232.

（RT）

(FPGA)

[GerdW]

Hi Jhun,

do you think your small-scaled images are helpful in enabling us to provide useful comments?

Which samplerates are you talking about? Which values do you want to set for each of the two modules?

[AeroSoul]

Indeed very useful.

[jcarmody]

Just zoom in...

[JHUN-KULI]

Thank you for reminding me. I am sorry that the uploaded picture is too small. It appears normally on my computer. I rewrote a project, including RT and VI of FPGA. When I actually run this program, the sampling rate of the 9232 acquisition card cannot be changed, no matter how many sampling rates I input in the RT front panel, it will be collected at the maximum rate, while the 9237 can change the sampling rate, I really can't find the reason. (The code is a combination of two routines in LabView, 9232 and 9237, which work fine when run separately.)

[JHUN-KULI]

Hello, GerdW, I re-uploaded my project and it is in the compressed package in the comments section. Thank you for reminding me.

[JHUN-KULI]

Hello Jcarmody, I have uploaded the project in the comments section, thank you for reminding me！

[JHUN-KULI]

Hello AeroSoul, I have uploaded the project in the comments section, thank you for reminding me!

[GerdW]

Hi Jhun,

---

@JHUN-KULI wrote:

Thank you for reminding me. I am sorry that the uploaded picture is too small. It appears normally on my computer. I rewrote a project, including RT and VI of FPGA. When I actually run this program, the sampling rate of the 9232 acquisition card cannot be changed, no matter how many sampling rates I input in the RT front panel, it will be collected at the maximum rate, while the 9237 can change the sampling rate, I really can't find the reason. (The code is a combination of two routines in LabView, 9232 and 9237, which work fine when run separately.)

---

It's hard to read the code due to your (heavy) usage of non-ASCII chars, but: one of the FPGA loops contain a "Data rate" property node, while the other module has that property node only once before the loop. To me it's clear why one of your modules doesn't change it's data rate once the FPGA loops have started…

Edit: You don't need to create 3 or 4 messages to answer each of your responders, you could just answer all of us in one message…

[JHUN-KULI]

You may have misunderstood me. What I mean by changing the sampling rate here is that when the program is not running, the input value of the sampling rate of THE RT terminal is changed, and then the VI of RT is run. At this time, the RT terminal will load the parameter data into FPGA before data collection. When I stop running rt. vi, re-enter a new sampling rate and run rt. vi again, at this time, 9232 still collects data at the maximum sampling rate. No matter how I change the sampling rate parameter, the actual sampling rate of 9232 will not change. (Each parameter change is made after vi is stopped, not when Rt.vi is running.)