LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to combine multitiered Windows host<-->RT host<-->FPGA target projects?

TLDR; If possible, what is the best build type to package a project that includes VIs deployed to RT and FPGA targets and that uses network-published shared variables, such that it's Windows host can be embedded in a sub-panel of a separate projects Windows host?

 

I work on a fusion experiment the University of Wisconsin - Madison. It involves magnetically confining plasmas and accordingly we have to control the magnetic fields by controlling the current flowing in our electromagnet coils. We are using LabVIEW and NI hardware (PXIe, RT, FPGAs) for these machine feedback control systems. The coils are driven by H-bridges that use pulse width modulation to control the drive voltage and PID feedback control to determine the duty cycle.

 

Presently there are two discrete projects, each utilizing a Windows host <---> RT host <---> FPGA target architecture. Our main project is the primary machine control code and the Windows host serves as the UI for the facility operator; the RT host performs PID feedback calculations and interfaces between the user and the FPGAs; the FPGAs implement the feedback control and H-bridge drive logic. The other project controls the facility charge/dump system, which charges/discharges large capacitor banks that store the energy used to drive the coils during each shot. They are charged between shots and discharged during the shot. This project also uses a Windows host <---> RT host <---> FPGA architecture, with the Windows host serving as the primary UI for the charge/dump system, allowing users to set the charge voltage, monitor the present charge voltage, enable/disable charging, and to actuate the dump switches. In both projects, host<-->RT communication is done via network-published shared variables, including communications between separate project windows hosts.

 

For the best user experience, I'd like to combine the UI into a single UI (basically add the charge/dump host to the main control code host). I'm looking for guidance/suggestions/resources that would help me determine the best way to go about this. One option is to combine the two projects into a single mega project, which I think would allow me to embed the charge/dump host in a sub-panel in the main control code front panel. However, from a code management standpoint it is nice having them siloed in separate projects.

 

As an alternative, I've been looking into Packed Project Libraries as a way to package the charge/dump project that could then be added to the main project, but it's not clear how this would work given the project relies on VIs being deployed to both RT and FPGA targets? All of the documentation I've found is for purely software projects, with no VIs being deployed to hardware targets. Is it possible to programmatically deploy both the RT and FPGA VIs from the windows host, and create a build (e.g., .exe, packed project library, some other type) that would then allow this host (charge/dump) to be embedded in a sub-panel of another projects windows host (main project)?

 

Sorry for the lengthy post, I hope it is clear what I'm asking. Thanks ahead of time for any insight offered.

 

Best,

The Pegasaur

0 Kudos
Message 1 of 3
(951 Views)

I think this should be do-able, provided that the two routines can be "separated in time".  We're doing something similar, but only need one cRIO.

 

We have our Top-Level VI (in the PC Host) working as a State Machine.  Right now, we can choose two types of "things" to do.  If we choose "Thing 1", the State Machine runs a series of States that tells the cRIO to "do Thing 1" using its FPGA.  If we choose "Thing 2", the Host State Machine sends a different series of States to the cRIO.

 

So you need to ask if you can combine your two Top-Level routines "in time" (or "at the flip of a switch").  Now, I'm going a little "out on a limb" here, but I think (and hope!) you can connect two (or more) Real-Time Targets to your Project, each with its own IP.  In our case, communication between Host and RT Target is through Network Streams, which are "locked" to the Target IP.  So if you set up two sets of Network Streams, one to "cRIO 1" and another to "cRIO 2", the two State Machines running within the Host can communicate independently to the two Targets, each of which talks to its own FPGA.

 

I just realized as I wrote this that you might not even need to separate the Host Routines in time.  LabVIEW (by virtue of Data Flow) is inherently a Parallel Processing system.  Depending on how much processing has to take place in the Host, you could have two State Machines running together in parallel.  Note that this might be one situation where you want two Event Structures, one to handle the Controls for Thing 1, the other for Thing 2.

 

I actually wrote a routine that managed up to 24 "Stations", each with an "Event" sensor and a TCP/IP-based Web Cam, no RT Target, no FPGA, and was able to save 5-10" videos from each Station whenever an "Event" (which happened every 5-20 minutes) occurred.  One (fairly-old) Xeon-processor Dell Workstation ran the whole thing.  The parallel routines were created as identical Clones of a one-Station routine -- we spun up a Clone for each Station we needed to run.  Runs lasted around 2 hours.

 

Bob Schor

 

 

 

0 Kudos
Message 2 of 3
(904 Views)

Thanks for taking a crack at this Bob. Let me restate the situation and the goal. There are two distinct projects, we'll call them the charge/dump and main control code, each using a Windows host as the user GUI. These GUIs tell the RT and through the RT the FPGAs to do "things" as you called them. Each RT is effectively a state-machine that is driven via the Windows hosts. They each work great as standalone systems, however having two different GUIs (hosts) is not ideal from a facility operator standpoint. We'd like to simplify and merge these into a single GUI. If I understand your suggestion correctly, it sounds like your suggesting combining the 'state machines' of my two separate windows hosts into a single host. This is totally doable and is something we have considered, however it would involve a substantial amount of work to combine the Windows host codes.

 

What I'm hoping would be a simpler solution is to find a way to embed one of the windows hosts into a sub-panel of the other host. So far I have been unable to make this work and am not sure if it can be made to work, hence my question. Doing the dumb thing and simply opening a VI ref to the charge/dump host VI I want to embed, and then loading that to the sub-panel in the main control code host fails because the embedded VI is not executable (apparently because it can't find it's dependencies). At least, this hasn't worked when they are two distinct projects. Combining them into a single mega project might work (by allowing the embedded charge/dump host to find it's dependencies)?

 

Now we come to my question, is there a way to 'package' or 'build' the charge/dump project in such a way that it's host can be embedded in sub-panel of the other main control code Windows host, effectively allowing them to be kept as separate projects, but have a combined GUI via the sub-panel embedding?

 

Hope that helps clarify what I'm trying to do.

0 Kudos
Message 3 of 3
(883 Views)