Do I need to deploy FPGA code and RT Main code independently to a cRIO 9068?

[NI_Hobbit]

Hi all,

I won't be able to include vi's on this post because I'm developing on an offline computer.

I inherited a project. I had an issue that required me to reformat one of 2 cRIO 9068s that I am using. I'm not sure if I was unable to restore the cRIO properly or if there is an issue with the code I am trying to deploy. Before the format, I was able to run my RT Main vi on the RT Target and talk to it with a Host Main vi on the Host computer. Now when I try to run the same code (not deployed), the cRIO disconnects from the host computer and I can't see the vi execute (or fail to). 

There is FPGA code included in the project that was developed before I took over the project. Do I need to deploy this code in addition to the RT Main vi and associated build files or is this a different issue?

This is my first time working with executables. Thanks for the assistance.

[ZYOng]

Usually, the FPGA bitx file is deployed using Open FPGA VI Reference VI in the RT VI. You can check the source code of the RT for the usage of this VI.

Regarding the status of cRIO after reformatting, you can try deploying a simple while loop and see if it is running.

[NI_Hobbit]

Thanks ZYOng,

I tried making and deploying a simple loop. It works as expected. What might be causing the program to disconnect when I run the old code?

-Hobbit

[ZYOng]

In my experience, most likely cRIO has crashed from the deployed program and goes into reboot.

I would recommend disabling the code part by part and locating the source of the crash.

[NI_Hobbit]

The code itself hasn't changed since it worked last time, that's why I haven't considered it as a possible issue.

It occurs to me, I may have missed a software package when I set it up again. I don't know how to go about deciding what packages to use. Can I just add every software package available on NI MAX? How would you ensure you don't miss one you need?

Thanks again for your responses.

[ZYOng]

If there is a missing package, the deployment window will tell you that LabVIEW is not able to run the code due to missing dependencies. cRIO will remain connected.

[rolfk]

There is an option to open an FPGA session with a path to the bitfile rather than having the bitfile automatically embedded in the Open FGA node. And that might cause the issue you see when the specified bitfile can’t be found or might have gotten corrupted.

But that would require the ability to look in the code itself and examine the Open FPGA configuration/wiring.

[Bob_Schor]

I tried to write the simplest LabVIEW-RT Example that I could, involving programming the FPGA inside the RT Target (which, in my case, is a myRIO-1900).  I'm attaching the entire Project Folder (which I realized I developed in LabVIEW 2019, but the Original Poster is using LabVIEW 2017, as I recall, so I'm going to "Save for Previous" which might do weird things with the FPGA code -- I'll attach both 2017 and 2019, just in case).

The User needs to open the Project and manually start the Host code and the Target code.  Here is the Host code:

All it does is count down from 100 (in seconds) and exit.

The Target code is similar -- it uses the FPGA to count up to 64 seconds, showing the seconds (from 0 to 15 in the myRIO's LEDs, repeated 4 times).  After it starts the FPGA (which starts counting), it waits for 70 seconds then reboots itself to stop.

Start FPGA is a little utility I wrote to start the FPGA code and wait until it starts running.  In here is where you reference the FPGA you want to run.  I like to point to the FPGA VI file, but as others have noted, sometimes this doesn't work, and you have to point to the BitFile.  It is a mystery to me why it works sometimes, but not others.

And here is the FPGA code.  The Timer (used only if you are "watching the VI" in Development mode) counts down from 64, while the 4 LEDs "count up" from 0 to 64, expressing the lower 4 bits in the 4 LEDS on the myRIO Chassis, 0.5 s on and 0.5 s off.  

Without a myRIO, you'll need to put some substitute code in the FPGA that basically does a "Wait" for, say, 60 seconds (or more, or less) before exiting.  [Actually, the FPGA doesn't need to do anything, but it belongs on the RT Target side of the Project and needs to be started by the RT Target's code.]

Hope this clarifies how Host, Target, and FPGA codes interact (I didn't show Host/Target interaction -- I do this using Network Streams).

Well, I've never tried to save a RT Project "for previous version".  I apologize for only attaching the LabVIEW 2019 code, as "going backward to 2017" was getting too tedious.  However, the VIs are simple enough that even "pictures" should be OK, I hope.

Bob Schor  

[NI_Hobbit · Accepted solution]

Thanks for that Bob Schor.

The issue I was up against looked like a cRIO refusing to connect to NI MAX or any machine it was supposed to connect to. I suspected it could be a CPU usage issue, where COM loops didn’t have the resources to execute. This article shows a way to record what is happening even though there is no debugger available.

This logger can be placed all over the project and it will record the time of execution as well as some data. You can modify the logging function to capture the specific data you need. I added a function to record CPU usage and errors/warnings from the error IO for my problem. Put it in a timed loop or you will fill your hard drive quickly.

The issue turned out to be a weird LabVIEWism. Halfway down this article, you’ll find the following; “Remove all property nodes that reference front panel objects or properties from the VI. In most cases, property nodes that reference front panel objects and properties (such as window position), if used, will prevent a real-time application from executing because a VI's front panel is removed when a real-time executable is compiled.”

The things you learn on the 375th message board.

So… don’t go down the same rabbit hole I did. Enjoy that article.