LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

When you have a dynamic VIT in a LV Class, what happens when it is part of an executable?

Solved!
Go to solution

Strangest thing...

 

It's in a project along with hundreds of other VI's.  The build options the same as the other hundreds of VI's.

Yet, when you build an executable, it does not want to execute.

 

Well.... that's not quite accurate.  Because I could create another VIT in an example code and it worked!

 

Originally, I had the VIT being built into the application.  Now I set the destination into a VIT folder.  The VIT and assciated files make it to the VIT folder.  I print the path and it matches.. So it should be dynamically called, but it isn't.  How do I know?  I placed an equivalent to a printf to see if the VIT executes.  The very first thing it does is write "in the VIT" to a file.  Nothing shows up in the file..  The file is used elsewhere, so writing to the file works.

 

I'm at a loss to figure out what is going on...  Unfortunately, there is no way to post the code.  As for posting an example of the code style, well that works, so that's no good either.. 

 

AAAaaaaarrrrrrrggggggggghhhhhh!!!

 

Any ideas, out there?

 

Smiley Sad

0 Kudos
Message 1 of 9
(3,878 Views)

More info:  Discovered that setting the option to 2 for the Open VI Reference vi helps when using VITs.

 

I get an error 1145.  The funny part is that the code already implemented a similar solution to that described in the thread below:

http://forums.ni.com/t5/LabVIEW/Is-it-possible-to-load-same-vi-in-several-subpanel/td-p/185350

 

Strange...  very strange...  Why work for one VI but not another...

 

Hope this thread will help someone in the future if they encounter the same behavior.

 

(no solution, yet)

 

0 Kudos
Message 2 of 9
(3,869 Views)

Hi Ray,

 

Not sure I understand exactly what problem you are having, but some of what you said sounds familiar...Maybe this will help?

 

http://forums.ni.com/t5/LabVIEW/Dynamically-loading-template-VI-class-member-causes-error/td-p/11415...

 

Jason

Message 3 of 9
(3,861 Views)

Thanks Jason

 

Great minds think alike..  I was discussing with a collegue changing the VIT to re-entrant VI's. 

I will have to postpone this activity until this weekend, but I will re-read the thread you provided.

 

What I coded looks similar to the example Ben posted. 

 

Cheers

 

RayR

0 Kudos
Message 4 of 9
(3,859 Views)

HI Ray,

 

I tried to summarize in the other thread that the issue boils down to the class it self.

 

Every class has to "know" about all of its members. Since the template instance does not exist when the class was last updated, the class does not know about the tmplate so the template is "not part of teh class" so therefore can not use private methods.

 

Re-write the template to only use public methods and it should work (well it worked for me).

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 9
(3,840 Views)

AARRRRGGGGHHH!!

 

It is using Private Methods... 

 

-sigh -

 

Oh boy..

 

As I said, I'll be re-visiting it tomorrow.  I don't know how easy it will be to modify it to use public methods... 

Maybe going to the re-entrant vi route will be the way to go.

 

What's your opinion, Ben?

 

Thanks for the heads-up.. 

🙂

RayR

0 Kudos
Message 6 of 9
(3,834 Views)

I wrapped up the private methods in public methods and used those instead.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 9
(3,831 Views)

Thanks Ben for your replies.

 

Before I attempt changing a VI that was written by a client and make a total mess of it, there's something I'd like to point out.

 

I tried the re-entrant VI approach and that didn't go any further than the VIT approach, and probably for the same reason(s).

 

The interesting part is that (with the VIT approach) the same VIT is called by another process and it works fine.  It is just for the process that has it appear within 2 sub-panels.  So the issue is related to having either having two instances spawn at once of the same VIT or it is related to the sub-panels.  I think it is the two instances (or copies of the VIT) that causes LV to caugh...

 

So you are trying to tell me that the above description is accurate and it is because of the private methods...??...

 

How would I "wrap" those private methods into public ones?  The seems to be a piece of this puzzle that I am not yet grasping..

 

Thanks for your patience and help.

 

RayR

0 Kudos
Message 8 of 9
(3,783 Views)
Solution
Accepted by topic author Ray.R

I'd like to thank Heiko F. for his wisdom at solving this one.. 🙂

 

The solution was to take the VIT out of the LVClass folder and to disconnect it from the class.

THe VIT could physically reside in the original folder where the private methods are located BUT it was added into the project OUTSIDE the class folders.

That meant right-click on "My Computer" and add the VIT file.  Then of course, simply set the VIT file as always included in the build properties.

 

Build and "voila" solved..  😄

 

 

0 Kudos
Message 9 of 9
(3,768 Views)