Build Error - Causing cRIO to drop network communication

[adekruif]

I have an interesting problem that I have not been able to solve and in searching have not seen anyone else with this problem. I am hoping someone can help determine what is causing the problem as it's causing me lots of headaches right now. I am using LabVIEW 2020 SP1.

The code I am building is for a cRIO-904X target and has a FPGA component as well as RT code. The FPGA code is very basic and is reading/writing to a NI-9870 card, then pushing the data into a FIFO, to be processed on the RT (See here: NI 9870 - Continuous Serial Read - On-Demand Write - NI Community). When I build the startup executable, midway through the build process I get this error message. 

Based on the error information once the build is complete, it appears to me that it is loading "clear error" from my builds folder and not from the Program Files (x86) location. I don't understand what the niFpgaMemoryEmulationRefIn vi would be doing with the clear errors.vi?

 

The build succeeds and I can set the executable as startup most of the time. The times it doesn't succeed, when trying to deploy the executable as "run as startup", the cRIO will not respond, and subsequently cannot be reached until the unit is restarted with a power rest. When the unit is in this state, I am able to ping the unit, but cannot connect to it in LabVIEW, and NI-MAX cannot see the cRIO either. I am unable to login with PuTTY as well. When the unit is restarted, it will return to this state sooner or later, so I think there has to be something in my code that is either maxing out the CPU's or throwing an error that it can't recover from.

What I have tried so far to get rid of the error:

1. Restarting LabVIEW.

2. Restarting my Computer.

3. Removing the FPGA from the project and reloading it.

4. I've replaced all the places in my code I used "clear error" and still get the same error.

I'm unsure of what to do next, so any help would be greatly appreciated. 

[JKSoerensen]

I think what you are experiencing is crosslinking because your code loads both your build output and your source code. 

You can only have one VI with a given fully qualified name in memory at the same time.

Here is some inspiration, as I am on a phone and going off to bed. 

https://www.ni.com/en/support/documentation/supplemental/08/best-practices-for-managing-ni-labview-a...

Let me know how it goes.

Jesper

[adekruif]

Thanks Jesper. I have identified which VI is causing the issue and have removed it from the code (for now) and now it compiles without any errors. I will have to read up more on cross linking and why my one VI is causing issues.

Turns out the error that kept dropping the cRIO off the network was NOT due to the compile error, but a separate issue.