building an executable with .vits with Labview 2011

[JimSchwendeman]

Howdy Forum,

I've recently adopted some code that dynamically calls two different .vits, one that parses (and displays data), and another that is used for logging this data.  

• While developing, it runs fine and dandy.  
• If compiled and not moved from the build directory, it runs fine.
• If compiled, and moved to some arbitrary directory, it throws Error 7, and croaks.
• If compiled, moved to some arbitrary directory and the .vits are also copied to that directory, it opens the .vits and tries to run them, but croaks as the .vits are broken due to all of the broken references to sub-vis.

I read this page regarding Error 7, and both .vits and the global that shares the info between them and the main .vi are included in the Always Included build information.  

The fact that my executable tries to open local .vits tells me that those .vits are not being included in the executable for some reason.  Any way to get around this, i.e. can I somehow "compile" each of the .vits so that I don't have to worry about associating all the sub-vis used by each .vit?

I am learning the painful lesson of build early and often, but would appreciate any insight you guys might have.  It would be much appreciated!

Thanks!

.jim

[Eric-E]

Hello Jim,

Using VIT's within an executable will cause issues. Creating a new VI within an executable during runtime is causing problems. Is there any reason why you are using VI templates? Perhaps using a call by reference would be better for this application.

Eric.

[JimSchwendeman]

Hi Eric,

Thanks for the reply!  

My understanding is that we use vi templates to allow the system to multi-thread, and take advantage of multiple processors.  Apparently, the previous version (no templates, queue-driven state machine) had performance issues as we began to increase the throughput.  (We're capturing hundreds of data streams per second, which are then parsed, and individually logged).

Can call-by-reference be used in a mannor that would let us take advantage of multiple core processors?

Jim

[Eric-E]

You can multithread without using .VIT's. Could you give a brief description of how/where data comes, and where it goes? What are general rates for the data? Hundreds of data streems each seccond, but are you creating VI's for each? More specifics would be great. Thank you.

[Hooovahh]

VITs were used in this way some time ago, but with the advent of reentrant VIs, and static VI references, and Asyncronous VI calls, they aren't really needed.  Several other techniques are better at calling VIs mutiple times.  

Heres some info http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/asynchronous_vi_calls/ Using this you can build the EXE with the VI you want to call in the EXE, then call it using a static VI reference and you don't need to worry about the path of the VI on disk or in the EXE.

[JimSchwendeman]

Hi Eric,

Sure!

The main .vi opens and reads multiple TCPIP ports to read incoming data streams, and append them to a queue.

1. Queued streams go to the first .vit, which parses all of the messages into a cluster of (human readable) elements.    
2. The parsed message is then added to a new queue, which the second .vit reads/logs the messages.  Each message has an associated serial number, and if that matches it writes to an existing csv file, otherwise it opens up a new .csv to write data to.

There aren't multiple instances of either the parser or the logger being opened, just one of each.  In windows, when I open the task manager and observe the individual core processor performance, I can observe that the .vits appear to be associated with different processors.

[JimSchwendeman]

Hi Hooovahh,

We aren't calling multiple instances of either the logger or the parser vit.  We start a single instance of each .vit at the beginning, and that's it.  The intent was to use that to take advantage of our quad-core processors.

Jim

[Eric-E]

I believe that using the VIT's as opposed to regular VI's will not allow you any additional functionality from your multi-core processor. LabVIEW is multi-threaded and automatically handles all thread allocations or swaps internally. However you can use these multi-cores more efficiently by the typical performance techniques like...

Using inplace structures

Specifying what is in the UI thread
Making subVI's reentrant so that you can call a subVI by more than one caller at the same time (shared clones between instances or pre-allocate clone for each instance)

Using larger amounts of data to read/write less frequently (because I/O is typically slower than other operations)

etc...

Using these performance tricks may prove to provide more performance enhancement over simply using VIT's. 

I hope this helps. If VIT's are a problem, have you tried regular VI's? 

[dan_u]

Hi Jim,

we use the .vit approach in a built executable as well. How do you open the .vit from the caller VI? Do you build a path to the .vit and feed that to open VI ref?

Maybe it looks for the .vit outside the exe for some reason even if a copy of the .vit is in the exe.

Daniel

[JÞB]

I actually have a simple example project that demonstrates some of the newer features that make VITs obsolete for dynamic launch.  (They still have great value for development!)

Go ahead and play with this project I built for internal benefit.

Edit: Attached backsaved for 2011 too