.vi loaded with errors on the target and was closed

[BPerlman]

For some reason I can't edit my previous post.  I said "I am", but then I realized I am not sure what ".llb extension archieves" are. We are using our VIs in a library of llb's.  I don't know if that is what you mean, or if you mean some kind of commercial llb's.

Batya

[BPerlman]

OK, I removed one function (which just created a cluster with the default values) and replaced it with a constant.  This is after I unlinked everything from the typedef and removed the typedef control from the project.  Now I have one VI which takes this cluster as an input.  If I put a diagram disable around just this VI, the main VI suceeds deployment and runs OK.  When the inputs to the function were not part of a cluster, everything also ran OK.  So somehow there is a problem with this function and the cluster going in to it, but no broken arrow or anything.

I've attached a screenshot of the relevant area of the block diagram, and the front panel of the called VI.

Help!?

Thank you.

Batya

[MGiacomet]

This continues to be a "change propagation" bug that NI doesn't want to invest in fixing (they prefer to spend time beautifying the splash screen, etc. )

Another "workaround" is to open the "offending" VI and try to deploy/run again. In one case, LV then found a different "offending" VI. I opened the next one and tried to run again. This time it deployed and ran fine. I then stopped the main VI, did a Saved All", closed the "offending" VIs and "the problem" went away.

[Edupo]

Finally I finished of getting out all my .vi and .ctl from .llb archieves. Program runs fine and I introduced OOP and some more improvements.

Thx Schmitz for your help 😄

I'll spread this "trick" to all my colleagues.

But calling this "a trick" NI is staining the reputation of LabVIEW. ( mani hour wasted by this issue).

[BPerlman]

This is getting really frustrating.

All I wanted to do here was improve the interface to one of our API functions (subVIs).

Now my demo program doesn't deploy. 

I may have to just go back to the ugly interface.  It seems a shame!

I have tried restarting, redeploying.......it is my top level VI that doesn't deploy, all the subvis do (including the one with the changed interface).

I got rid of my one typedef and removed the .ctl from the LLB

I don't want to take all our VIs out of the LLBs.....that would seriously change how we organize, source code control, and distribute at least two products (which share most of their VIs).  A bit of overkill for improving the interface of one VI -- especially since this is not a new product at all and we probably have many customers using it......who would then have to change their organization, source code control, and possibly distribution if they upgrade to a new version of the product.....

Batya

[BPerlman]

OK, now I really removed the control from the llb.  And took the helper function out entirely for now.  And reverted back to the old version of my VI with the clunky interface and had it deploying and running like that.  Then I reprogrammed from scratch the new interface, and did not make a typedef.  

Still does not work.

I don't think that I have any more time to work on this.  We'll unfortunately have to return to the old, less elegant, interface.

It seems a shame, and just when I'd worked with LabVIEW long enough I was starting to like it 🙂

Oh, well.

It is interesting that this entire thread is written and commented on by people who have posted little or nothing else on the forum -- maybe some of you are experienced LabVIEW users and just haven't been on the forum much, or maybe we are all somewhat newbies -- but no one experienced here has weighed in on this issue.  Why is that?  

Batya

[henryk]

I think we need an insiders secrets compendium.

Interesting to see that the problem has so many faces.

For me the concept of developing with typedefs and subfunctions in llbs proved toxic in the long run. Initially everything worked, but over time this problem started . I moved everything out of llb and into library folders and the problem never re appeared

The second quirk I encountered came from running out of the IDE too long. Some changes work but suddenly you hit one and everything seems to break. My workaround was to recompile the project.  Once that was done everything worked.

I was working with custom drivers in the FPGA and custom cards but it sounds like these problems exist elsewhere as well.Unfortunaetly it takes a long time to debug some of these issues.

I have found this forum the best place to get ideas of when you hit the wall of 'I don't know what to do next'

thanks

[BPerlman]

The crazy thing here is that I got rid of my typedef -- I reprogrammed the function without putting in a typedef, and I still had the problem.

Getting rid of the cluster input and making a terminal for each integer seems to have solved the problem (OK, not getting rid of the cluster, but reverting to an older version of the VI before I added the cluster...)

The fact that I have to pick a less appropriate interface to an API VI that I am providing to my customers, because of some strange unexplained and apparently unsurmountable (without changing our product too much) problem in LabVIEW, seems to me just ridiculous.

I guess the forum is the insiders secrets compendium.....

Batya

[Michel_L]

I also got this error just by renaming the parent directory of my project.

The offending VI was not in an llb.

I worked around the problem by making a dummy change in the offending VI and then deploying it and running it again.

I hope this helps!

Michel Lanthier

NETE

[Edupo]

For me, the solution, was not to use *.llb in real-time targets. PXI or VxWorks.

Not only main .vi is important. Every dependence on RT Target must not reside on .llb.