.vi loaded with errors on the target and was closed

[Olivier_Labo]

Maybe I could help with a more stable procedure to get out of this situation, but I don't remember if it worked perfectly each time I needed.

1st, I realized that a software reboot (from MAX, or from project explorer window) is not as effective as a power Off reboot.

Then, I have a feeling that when an Exe run at startup, and we stop it when deploying a VI, some badly released things (classes, libraries,...) may affect the deployment.

Knowing that, the procedure is:

1 - Unset you StartupExe as startup.

2 - Power off reboot your controller

3 - Deploy your VI

I hope this could help 

[paul.r.r]

I'm fighting this issue currently as well. I am getting a mix of deployment completed with errors, vi loaded with errors on the target, and a message that one of my vis is broken. When I navigate to the 'broken' VI, the run arrow does show as broken, but the VI isn't actually broken - if I click the run arrow the error list that pops up shows nothing is broken. Mass compiling fixes the broken run arrow, but the next attempt at deployment usually results in the same problem again - deployment completed with errors, or vi loaded with errors on the target. (Usually a different VI.)

I am using lots of classes and the actor framework, and one VI that I have noticed that is regularly reported as being the vi with errors is an override of receive message, which simply logs the incoming message and then calls the parent method. I've removed my logging call, and kept the override that simply calls the parent method, but I still get the error. If I attempt to run this VI directly, LabVIEW usually crashes.

I have also noticed that closing the project doesn't actually clear the project items out of memory - I can close the project, then reopen and the project opens instantly (it usually takes 20+ seconds to load everything on first load) and will show as already being connected to the target.  

To others that have had this issue, were you able to build and deploy and executable to your target correctly? I am able to build my exe and deploy, but I am seeing weird behavior with my code that I am not 100% sure if is caused by my code, or by some build/deployment issue. 

[benjamin-hinrichs]

My deployment issue was solved by removing all VIs from its DQMH lvlib and adding them back (and saving a whole bunch of files twice). Closing LabVIEW and clearing the compiled object cache was not necessary for me. Credit for this solution goes to joerg.hampel. Maybe this could be applied to your actor.

Regarding the project staying open in the background after closing: For me it was unrelated to the deployment issue at hand. I can close the project file normally after removing FPGA from the cRIO project (have a separate project just for FPGA now). I got it from this thread: https://forums.ni.com/t5/LabVIEW/LabVIEW-Bug-When-Sharing-Module-Timebases/m-p/3895817

[MichaelSe]

for me,

renaming the vi with a new copy of it solved the problem!

thanks for this topic to help finding a solution.

[tobiy]

I have this same issue and cant fix it LV 2019 with sbrio 9607. I tried renaming, replacing, deleting chaches, recompiling.

I get the error in a tcp_listener.vi which is part of a TCP Class including some TCP functions. I am not sure if this is even an official NI class..

The funny thing is: When I draw a diagram disable box around the tcp_listener subVI in the caller VI, it deploys fine (ofcourse within the necessary function). When I instead draw the diagram disable box inside the tcp_listener.vi and I infact disable *everything* (inputs shortcutted to outputs), the deployment still fails.

So this is definitely *not* about the code.

Any suggestions?

[PESobol]

The only solution I've found is to rewrite the code, increasing the differences from the original until it works.   "In-line" the code, or move it to a subvi-.    Rewrite your vi (delete the original, start from scratch), write your own versions of labview sub VIs, try a different progamming structure/approach.  (I.e. use UDP instead of TCP!) .  Generally I've found that the fewer SubVi's I have, and the simpler they are, the more luck I have.  

Not very helpful I know.    

[tobiy]

Hi PESobol,

unfortunately UDP is not an option here. Using fewer subvis (as a general advice) is also not really what one would consider good code 🙂

However, you bet me to it. I should have realized myself after my previous findings, but probably I was too frustrated then.

In this case, just inlining the offending vi solved the issue! It was no big deal, since it was itself just forwarding the call to subvis so it is small, and the caller (with the now inlined code) is it itself a subvi to my program, so this doesnt bother me at all!

Kudos awarded 🙂

[PESobol]

Thanks-

Inlining code does reduce the memory usage, which is another measure of "goodness" of code.  Especially on the CRIO's that can be an important consideration-

I'm old enough to have been marked down for assembly language code that used 2 extra flops and 4 bytes of unnecessary memory!

[ImreSzebelledi]

Hello,

this problem still stands after more than a decade (LV 2020 SP1). The issue is the same for us : vi loaded with errors on RT and no way to debug what is causing the error. In my opinion clearing compiled object cache and recompile is a terrible workaround and not working 100% of times but at least is takes a lot of time and deletes compiled code for ALL of your project. Have fun recompiling everything every time for big projects. We use classes and libraries shared between Windows and RT and it is almost impossible to start both version at the same time. Something is definitely flawed in Labview and is costing our company a lot of time and money. I spent the other day (and many days altogether) trying to deploy the RT project and kept telling to others to be patient because this is like the lottery: either you are lucky and can deploy with success or get to keep trying wasting your whole day. At this point if LabVIEW had a viable alternative I would switch in a blink of an eye because updating the splash screen is more important than fixing bugs. Labview is okay for smaller projects but crumbles for big ones.

-Imre

[tobiy]

Luckily I was in no urge to deploy when the bug hit me. But I can see that it can cost 1000's of € worth of working time. Add that to the 1000's of € that NI hardware costs in excess of comparable realtime / fpga hardware.

I am sure many customers doing this calculation might find, that it is more economic to develope an alternativ to NI/Labview at this point. Once those customers are lost, they will never return.