05-01-2023 01:53 PM
Amongst other things, we want to measure six staggered PWM signals to ensure that their staggering is actually being evenly distributed in the way we intended. We were thinking the best solution might be to grab an NI 9147 Ethernet RIO and a couple of NI 9381 multifunction I/O modules. That gives us all the I/O we need with some flexibility in the future between the extra I/O on these modules and the extra slots in the RIO. For our application, we seem to have sufficient sampling rates with the hardware, but we don't think the Scan Engine will be sufficient to get the PWM signal profiles we are trying to capture. Although we have worked with cRIOs in the past, we haven't utilized the Ethernet RIO yet, so we've been doing a little research:
Solved! Go to Solution.
05-01-2023 02:07 PM
Putting this all together, it seems like we would be able to reprogram the FPGA to use the DMA and access that from our Windows host application. Can anyone confirm that we are understanding this correctly or clarify where our thinking is off?
Yes, you can. The KB Can I Access My FPGA Target from LabVIEW 64-bit? shows an example of how you can bypass the cRIO controller and communicate with the FPGA directly from the Windows host application. As a matter of fact, when we debug and click the Run button on the FPGA VI, we are interfacing with the compiled FPGA VI from the Windows host LabVIEW ADE directly.
However, the latency of communicating from a Windows host via Ethernet is definitely much higher from the real-time controller but depends on the application, the latency might not matter at all.