LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VIs need recompile after source distribution

Hello!

 

I am having a strange problem with a source distribution and want to query the community.  I have an actor framework application that uses a plugin architecture for the hardware.  The plugins are just actors that I distribute using a source code distribution.  This mostly works, except for one hiccup I am having.

 

When loading one specific plugin, it causes an error 1003, stating, "The VI is not executable" and it refers to the Actor Framework.lvlib:Actor.lvclass:Actor.vi

 

I inspected the files of the problemed plugin in the source code distribution and did not find any errors.  HOWEVER, I did notice that when I closed the .lvlib file for the plugin, LabVIEW notified me that two if the files had been modified and needed to be saved.  I had not made any modifications to these files, but I saved them anyway and found that after saving the files, the problem went away.

 

It appears these two VIs need to be recompiled after building the source distribution in order for my application to work.  When I list the unsaved changes for the two VIs, I get, "VI recompiled", "SubVI call(s) modified", and "Type Definition modified".

 

Does anyone know why this might be happening? and how to prevent or work around it?  I suppose I could just open, save, and close the library after each build, but that sounds awful.

 

It might be worth mentioning that the plugin in question depends on items in the instr.lib directory.  I made sure to mass recompile those files, and that did not help.

0 Kudos
Message 1 of 8
(1,110 Views)

I have sometimes had issues where a VI always has a star when loaded; no matter how many times it gets resaved.

One possibility is an uninitialized shift register for a .lvclass.  The SR can be holding an old version of the class, which then needs to be mutated and recompiled.  But strangely the SR doesn't get updated.

 

Also, sometimes XControls can cause that kind of behavior.

 

An XControl should never, ever, have any kind of dependency on a .lvclass.

"If you weren't supposed to push it, it wouldn't be a button."
Message 2 of 8
(1,093 Views)

If you make a source distribution, you will get copies of the entire class hierarchy and the type definitions in it.

 

Then when you load the distribution, it might use the class hierarchy that is in memory in stead.

 

Perhaps that is what is conflicting?

 

I've not used source distributions since 5 years before OO was added to LabVIEW, but separating compiled code might help (providing you're using the distribution for development):

wiebeCARYA_0-1670839312764.png

 

0 Kudos
Message 3 of 8
(1,023 Views)

Also, when you close a project window, sometimes some parts of that project can remain stuck in memory.

Make sure you startup LabVIEW fresh before loading anything from your source distribution.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 8
(1,010 Views)

wiebe@CARYA wrote:

I've not used source distributions since 5 years before OO was added to LabVIEW, but separating compiled code might help (providing you're using the distribution for development):


Right. I forgot to mention that the application calling this distribution is an executable.  The compiled code must be embeded in the source files for this to work.

 

The two VIs in question aren't anything fancy.  They are simple methods for a Yokogawa power meter. 

Reset Totalizer.png

 

Most of the code comes from the official instrument drivers for that equipment and changing it as not really an option.

 

Maybe I am just going about this all wrong.  I was under the impression that the source distribution would recompile everything so I wouldn't have these issues.  Is there some other way I am supposed to be doing this? Do PPLs have this problem?

 


0 Kudos
Message 5 of 8
(1,000 Views)

So does this driver in the source distribution define an enum, and is this enum also used in the exe?

 

That will cause a conflict...

 

A PPL will probably solve this problem, as it (probably) won't complain that the enum wasn't loaded because it's already in memory, because it's all compiled code.

0 Kudos
Message 6 of 8
(984 Views)

@yourfavoriteproperty wrote:

wiebe@CARYA wrote:

I've not used source distributions since 5 years before OO was added to LabVIEW, but separating compiled code might help (providing you're using the distribution for development):


Right. I forgot to mention that the application calling this distribution is an executable.  The compiled code must be embeded in the source files for this to work.

 

The two VIs in question aren't anything fancy.  They are simple methods for a Yokogawa power meter. 

Reset Totalizer.png

 

Most of the code comes from the official instrument drivers for that equipment and changing it as not really an option.

 

Maybe I am just going about this all wrong.  I was under the impression that the source distribution would recompile everything so I wouldn't have these issues.  Is there some other way I am supposed to be doing this? Do PPLs have this problem?

 



I'm going to go out on a limb here and guess.  (I know, I do do that a lot) but you specifically mentioned "Actor Framework" and PPL in the same thread.  AF uses Error Rings.  Error Rings are Xnodes.  Xnodes don't play nice in Packed Project Libraries and sometimes need to be resaved when you create a Source Distro since, well, They are X nodes so they compile after loading.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 8
(974 Views)

wiebe@CARYA wrote:

So does this driver in the source distribution define an enum, and is this enum also used in the exe?


It does not.

 

I came up with a work-around.  I created a post-build action that runs a mass compile on the source distribution after it is built.

workaround.png

This adds a bit of time to the build process, but at least it does not require any manual user intervention.

Message 8 of 8
(973 Views)