May RT hosted VI and PC hosted VI access same FPGA reference at same time?

[Liquid_Crystal]

May a RT hosted VI and a PC hosted VI access same FPGA reference at same time?

If the RT is restarted, asy from a power failure, how should I deal with the old reference to the FPGA  and pass the new FPGA reference to the PC hosted VI?

Any suggestions are appreciated.

[jkurtw]

mgroom,

What hardware platform are you using? Are you using cRIO and accessing the FPGA VI from the PC and from the RT controller?

I am not sure off the top of my head if you can do both at once, but I can't think of a good reason I would recommend someone do that.

Can you give some detail about your application and what you are trying to accomplish?

thanks,

Kurt  

[Burt_S]

I just tried this and it turns out that it is possible (although there are a few strange things that can happen that I won't get into).  Regardless, I agree with Kurt and can't think of any good use cases for this type of architecture.  Some more information about why you are trying to do this would definitely be helpful.

[Liquid_Crystal]

I have a cRIO 9072 with analog, thermocouple and DIO modules. The FPGA code is grabbing data ~every second.I have a LabVIEW program running on a PC which displays data graphically, controls the DIO and does data logging and archiving to file. It may get data every minute or once an hour depending on how slowly we want to monitor the system and how much raw data we want to log. This approach allows logging of “raw” data and more importantly, allows us to see what is going on in our system so we can develop the control phase of the project.The PC and cRIO connect wirelessly with two WAP-370s, IP a.b.c.1 – IP a.b.c.2 – IP a.b.c.3 – IP a.b.c.4. The PC has a dedicated NI card for this part of the hookup and another NIC for connection to the rest of the world, IP w.x.y.z .I also have a RT program running which gets data from the FPGA. This RT program monitors the raw data ~every 10 sec. (time determined by shared variable access) and processes data on the fly.For example: the RT program monitor the on-off cycling of a motor and measure its power consumption over the course of a day then, the Main program on the PC asks, via shared variables, for this scaled and processed data once a day at midnight.The Main program uses an “Open FPGA reference” to get raw data from the FPGA as the does the RT program. If I open and start the RT program from within LabVIEW or deploy and “Run as Startup” from within the Project, then start the Main program, everything works. You may have to restart once or twice to get everything going but at lease I’m collecting data. Problems:  1) In the past, for reasons unknown, I was able to get the RT running via the .exe as well as the Main program on the PC but a power cycle on the cRIO causes the reference to the RT to be lost by the Main program………… how should I deal with the old reference to the FPGA and pass the new FPGA reference to the PC hosted VI?................ 2) If the RT program is started from the Project (assuming a build spec etc.) starting the Main program on the PC causes the RT to stop ! ……………………… May a RT hosted VI and a PC hosted VI access same FPGA reference at same time? The goal is to get the RT program to run on its own (auto-start from power failure) and still have the Main program controlling and logging data when the RT comes back up. Any advice you can offer is appreciated.

[Burt_S]

So as I mentioned, I have tried to have both targets access the FPGA at the same time, and it seemed to work alright once both targets actually connected.  However, occasionally there were issues with the host trying to connect after the RT already had.  Essentially, you might be able to do things this way, but this is not how the FPGA was meant to be used.

In general, the FPGA should only be opened by either the RT or the Host.  If both targets require data from the FPGA, then the RT target should gather the data, and send the appropriate data back to the Host.  I would highly recommend using this architecture for your application because many unforseen problems may occur otherwise.  However if you would like to stick with what you have, the only way I can think of getting a new FPGA reference to the PC would be for it to close its current reference and open a new one once the system was back up again.  You would need to set-up a system where the PC is notified when the controller reboots, and then goes into a reconnection routine and opens a new reference.  Again I do not recommend this, but it might be a solution for you. 

[Liquid_Crystal]

Thanks for your insight Burt. If I do a Build then Run as Startup the RT program is fine but when I then start the Main program, running on the PC, there are indeed issues. Starting the RT program from the desk top and then starting the Main program work fairly consistently, the advantage in this approach is ease of development. Since development will conclude, hopefully some day, and the RT program will have to stand on its own, I will certainly consider an approach that does not require two different connections to the FPGA.Unfortunately, I am running out of memory on the cRIO 9072 and haven’t even started adding feedback control code. Adding code to pass data to the Main program via shared variables will eat up even more memory. Can more memory be added to the cRIO 9072 or is another model called for? Thanks again, Merrill

[jkurtw]

Hey mgroom,

It sounds like your I/O rate requirements are not very high. If you are using LabVIEW Real-Time 8.6, your application architecture could be simplified quite a bit if you used CompactRIO Scan Mode (http://zone.ni.com/devzone/cda/tut/p/id/7338)

It can easily handle I/O rates in the 100Hz range, without you having to program the FPGA. Also, the scan engine automatically pulished all I/O to the network so that you can read/write to I/O from the host application on your Windows machine.

Since you are using a 9072 you will have to take one special step to get scan mode running on your cRIO, but you only have to do it once. See this KB: http://digital.ni.com/public.nsf/allkb/122E971F52FD081A86257500007A046C

Definitely worth looking into if you have 8.6.

Kurt  

[Burt_S]

Hello mgroom,

I wanted to let you know that as far as memory is concerned, you could try putting a smaller subset of the drivers on your controller.  You could find some drivers that you aren't using in your application and remove them from the controller to free up space.  Also if you are doing any logging, you might want to look into our 9802.  This could save the rest of the space on the C drive for your application.  Also, you could always try to make your program smaller.  If none of this is possible, then your only option may be to upgrade controllers.  Hope this helps!

[Liquid_Crystal]

Thanks for your suggestions Burt.

Scan Mode sounds like the best way to go.

Thanks again,

Merrill