VI Server communication fails when built into an exe

[crelf]

G'Day All,

I've got some software (written be a previous employee) where two VIs running on separate PCs that communicate using VI server. The first VI (let's call it the reader) opens an application reference to the writer PC, and then a VI reference to a VI. Then, references to all of the indicators are returned, and the VI on the reader PC is able to read the name, type description and flat data of the indicators using an invoke node. This all works well when operating under the LabVIEW development enivronment, but when the writter is built into an exe, it all falls over. It *almost* works (the name and type descriptions of each indicator is returned correctly), but I'm getting an empty "flat data". I've checked the characteristics of each node that I'm using, and they are all available under the run time engine (both read and write) - has anyone got any idea of why this is screwing up?

Download File:post-10-1073107487.zip

[Jim Kring]

G'Day All,

   I've got some software (written be a previous employee) where two VIs running on separate PCs that communicate using VI server.  The first VI (let's call it the reader) opens an application reference to the writer PC, and then a VI reference to a VI.  Then, references to all of the indicators are returned, and the VI on the reader PC is able to read the name, type description and flat data of the indicators using an invoke node.  This all works well when operating under the LabVIEW development enivronment, but when the writter is built into an exe, it all falls over.  It *almost* works (the name and type descriptions of each indicator is returned correctly), but I'm getting an empty "flat data".  I've checked the characteristics of each node that I'm using, and they are all available under the run time engine (both read and write) - has anyone got any idea of why this is screwing up?

Chris,

Is the Front Panel of your target VI preserved during the build process? If not the FP controls may not "exist" and therefore not have thier own data space, even if you can get references and type descriptors. This sound like a realistic scenario, so mabye this is the easy solution to your problem (I hope so :-). You can force the app builder to preserce a VI's front panel by putting an owned property node (implicitly linked) on the VI's block diagram that is linked to a front panel control (rather than setting the parameter in the build settings dialog).

Cheers,

-Jim

[crelf]

Yeah - I had a look at that, and they all keep their front panels