Open Remote FPGA Refnum in Parallel to Deployed System Definition

[Pie566942.0]

Hi All,

If an FPGA VI includes the NIVS FPGA interface code (synchronization, DMA FIFOs, etc.), and its .fpgaconfig file is properly formatted, I can add the FPGA personality to an NIVS system definition, deploy the system definition to a PXIe RT target, and open a remote RIO reference to the FPGA bitfile from a LabVIEW VI running on the host computer.  Using this reference, I can access all the FPGA resources I expect from the LabVIEW VI running on the host, while the system definition runs.

If the NIVS FPGA interface IP is removed from the FPGA VI, and the RIO is removed from the system definition, and no other component of the system definition utilizes that FPGA, opening the remote RIO reference stops the system definition running on the PXIe RT target.

Why does opening a remote RIO reference stop the running system definition?

Is there any way to access the remote RIO exclusively from LabVIEW in parallel to VeriStand?

Thank you,

Steve

[Pie566942.0]

I'm going to try downloading the bitfie (compiled to run when loaded) to NV flash and connecting to the remote RIO while the system definition is running.  To be continued...

Steve

[StephenB]

hey Steve! 🙂

the project must be deploying its settings... Therefore killing NIVS. This is likely the same for any start up app. Maybe report it as an RT bug?

try deploying with Rio device setup in the start menu and then connecting? Or if that or your idea doesn't work, you could write a windows vi that loads the bitfile and interacts with it via the normal fpga interface... Just use the rio://<IP>/RIO# syntax on the open fpga reference node.

[StephenB]

if you're forced to write a windows VI you could use the fully dynamic host interface on NI Labs to make a generic front panel that works for any bitfile
https://decibel.ni.com/content/docs/DOC-17185

[Jiri_K]

Hi Steve,

you could use the Network Computer/Device target. It should not influence running VeriStand.

  

Regards,

Jiri Keprt

RTT&HIL Systems Engineer

[Pie566942.0]

Hi Stephen and Jiri 😄

Thanks for weighing in!  I can't wait to see what Stephen and Devin have been working on...

I should have been more clear that by "remote RIO reference" I was using a rio://IP>/RIO# resource name and binding to a bitfile, not the LabVIEW project approach.  For all intents and purposes, it's a stand-alone VI.  I do believe you're on the right track with the remote reference, and I'll close the loop on the forum after we try it out.

Best Regards,

Steve

[Pie566942.0]

I'm so glad you brought this up because it may have a place in another project.  Thanks for thinking outside the box 😉

Steve

[Pie566942.0]

The RIO Device Setup Utility got us the desired effect.  Now we're running and interfacing with a FlexRIO in the same RT system that's running the System Definition, but the FlexRIO's not in the System Definition.  Since the FPGA VI was compiled to Run When Loaded, we added synchronization between the host application and the FPGA VI in a start frame.  Since the FPGA VI never terminates, we added bookkeeping to reset registers and purge FIFOs between runs of the host VI.  I recommended a CAR for the Best Practices when Accessing FPGA Targets Across Networks topic in LabVIEW FPGA Module Help to include the caveat that downloading (or running?) the remote FPGA VI may affect execution of the RTEXE.  Thanks again Stephen and Jiri!

-Steve

P.S.  I suppose you may be asking why.  This one boils down to reuse of existing (and completely encapsulated) components - and fitting into the overall test program's architecture.  Before employing this technique, I encourage anyone considering it to dialog with NI.  Overall, the native VeriStand approach is likely the way to go.

[StephenB]

Thanks for the follow up Steve. Sounds like a cool app