Typedef Path in an Executable

[David@Work]

Hi,  I'm developing code in LabVIEW 2011 that uses typedef'd controls.  Some of these are rather large arrays, and the data for these controls is received as string values from a server interaction.  We have come up with a way to populate the arrays (including conversion from string to the appropriate datatypes) using a pre-defined VI that is called dynamically by the code.  The VI must reside in the same folder, and the name must match the typedef name (but with a .vi extension).

Here's my challenge...  In the development environment I use a property node to get the Typedef Path from the control by reference.  Once I build the code into an executable, it won't execute because the Typedef Path property is a scripting property that is not available in the run-time engine.

Has anyone encountered a problem similar to this, and if so, how did you overcome this obstacle?

Thanks in advance,

David Dupont

[Ben]

 If the "Special VI" is in teh same folder why not use the path of the Special VI ?

What special "population of arrays" is done by the Special VI?

Ben

[nathand]

Have you considered turning each Type Definition into a separate LabVIEW class, where the class data contains the corresponding type definition? Each class would need a single method to read the data. I suspect there's a way to do this that would simplify your code.

[David@Work]

The special VI needs to be "found" by the code by understanding where the Typedef (there are hundreds of these Typedefs in our system) is located.  The arrays are always arrays of clusters.  Some of the clusters have 60 or more elements of various types.  the main code (if no Special VI exists) loops through the array and through each cluster element, determines the datatype of the element, then converts the string data receeived from the server to the right type, and populates the array.  As you can imagine this executes very slowly.  The advantage of (reason for) doing it this way is that you don't need to know the datatype in advance.  The Special VI contains a copy of the cluster (knows the datatype), and so can execute very much faster.

[David@Work]

Although this sounds like a good idea, I'm afraid we're too far down the road to make such a large shift in paradigm.  But thanks.

[Mancho00]

You may need to have the dynamic VIs  'Always Included' in the build spec.  That way you shouldn't need the path, just the name of the VI

[Ben]

Since you have to figure out how to get around the scripting node we will need to know more about the "Special VI" or at least an example that we can look at.

I do not think there is much more we can do to help.

Ben

[tst · Accepted solution]

---

David@Work wrote:
Once I build the code into an executable, it won't execute because the Typedef Path property is a scripting property that is not available in the run-time engine.

---

Are you sure that this is the case? I haven't tested, but the help does say it's supposed to work in the RTE. Of course, the help isn't necessarily right, but it's worth checking. For example, it might not work because your build spec disconnects typedefs (although my understanding is that you're not building these VIs) or because you're missing compiled code or because of dependency conflicts, etc.

The point is that you should look at the exact error details and see where and how it fails. I'm assuming you have, but since you didn't give those details I can't be sure.

If all else fails, I would suggest running a manual/automatic process in LV when building these plugins which will store this information in a lookup table of some kind (database/the FP of the plugin VI/text file in the same folder, etc.) and then have the EXE read the information from there. That seems like it would less conversion work than the classes option.

[David@Work]

I like your idea of figuring out the paths, and storing them in a text file for the runtime version.  Why didn't I think of that?

Thank you.