Projects breaking with NetComm_UnloadCPPStartupProgram Errors

[Spectre_8753]

Since we updated our development stations and RoboRIO 2.0s to the 2023 release, we've been getting broken arrows on previously working projects.  The bottom of the error stack typically points to an error in NetComm_UnloadCPPStartupProgram.vi  - Sub VI not supported for current target. This VI contains a system call to run a shell script w/ a *nix path - we're running this on a Windows tablet, so I'm not sure how that maps.

Here's the weird thing.  I can create a new RoboRIO project and develop code that runs on the target just fine.  When we close the project and reopen it, we get this error starting with begin.vi and trickling down.  No other changes were made.

And it gets weirder.  If I create a new RoboRIO project and then copy the VIs from the broken project into the new project, it works fine.  Until I close that project...

So we have a workaround, but it's a nuisance and only started after we updated our development environment and RoboRIO images.  I gather from posts on ChiefDelphi that others have seen this behavior as well.  Anyway to fix this definitively?

[mshafer]

Unfortunately, most years the lower level WPI Lib VIs contain breaking changes. The only solution I'm aware of to run a version of a previous year's code on a new control system is to rebuild the code in a new project.

[Spectre_8753]

---

@mshafer wrote:

Unfortunately, most years the lower level WPI Lib VIs contain breaking changes. The only solution I'm aware of to run a version of a previous year's code on a new control system is to rebuild the code in a new project.

---

If that were the case, the project should never run at all.  These projects are breaking spontaneously when they are closed.

[mshafer]

Is your code on GitHub or somewhere I can look at the LV project? (or could you zip it and send it to me in a private message?)

*nix paths are expected since the code ultimately runs on a Linux Real-time controller (the roboRIO)., but I'm wondering if there's something going on with where the project is telling LV the code is expected to run (i.e., if for some reason the project is getting saved in a state that tells LabVIEW that the VI should be able to run the development machine...)

[oscarfonseca]

Thanks for opening this thread, Spectre_8753.

I have been following the thread in ChiefDelphi, which I presume is the same (or related) to this issue: https://www.chiefdelphi.com/t/get-a-netcomm-error-opening-a-new-default-labview-robot-code/423625 

If we are able to get one of the projects you see load broken from LabVIEW, as Matthew requests, it would help us to understand what may be going on with that installation combination that is making the behavior show up.

Thanks,

[Spectre_8753]

I sent an example project to Matthew.  Let me know if it wasn't received.  Thanks!

[Engbrecht]

I just wanted to jump in and say that we are having the same issue that is being discussed here and on the Chief Delphi Forum.

The problem went away when we switched to our older Roborio 1.0 rather than our 2.0.  It happens with a simple FRC default project that we have added no code to.  

[sciencewhiz]

There's some workarounds posted here:

https://www.chiefdelphi.com/t/get-a-netcomm-error-opening-a-new-default-labview-robot-code/423625/27 

[Spectre_8753]

Was this ever resolved definitively?  I still see it on my development laptop.  Projects get disassociated with a RoboRIO when they are re-opened, and are replaced with a CompactRIO target.  Is there a simple way to correct that in a project?

[oscarfonseca · Accepted solution]

I would not expect that to happen if the latest CompactRIO driver is installed, as recommended in the ChiefDelphi post.

Please let us know if the problems persist after implementing the suggested workarounds.

Thanks,