Using scripting to inspect code from a built exe?

[Thoric]

Hypothetically, if one created a LabVIEW executable that used a remote application reference to interact with the LabVIEW IDE, how much of the scripting function set would work?

 

I've already discovered "New VI" doesn't work, but what about the non-creative functions, such as programmatically showing a block diagram, traversing the block diagram, inspecting nodes and other objects etc.? It seems to me that it should be ok to perform inspection, just not manufacture, right?

 

So why are a load (if not all) of the scripting methods denied when attempted from a remote interface?

[gleichman]

Why would you want to do this? The block diagrams won't even exist if the executable isn't created with "enable debugging".

[Darren]

Scripting properties and methods are not supported in the run-time engine, so a built EXE does not have the ability to perform VI inspection.

[Thoric]

Gleichman: you misunderstand. I don't want to inspect the exe. I want the exe to be able to use scripting calls on other VIs that are in the IDE. Think of it as a compiled version of VI Analyzer.

Darren: I can understand why creation isn't supported, but if we're using Remote Server access to the LabVIEW IDE to purely read info about block diagrams then it's a benign process. Is there a reason this is blocked? Security concerns?

[Antoine Chalons]

Scripting properties and methods are not supported in the run-time engine, so a built EXE does not have the ability to perform VI inspection.

 

I think I understand why NI would want users to not be able to use scripting in a built application but I find it hard to believe that is there no way around the limitation.

[Thoric]

I think I understand why NI would want users to not be able to use scripting in a built application but I find it hard to believe that is there no way around the limitation.

I can only think up one workaround, and that would be a lot of work - it would involve wrapping each scripting function in a wrapper VI, and using standard VI server calls to open each VI, populate the VI terminals and execute them, sequentially, to achieve the equivalent scripting requirements. This moves the scripting session into the IDE, yet it remains controlled from the external executable. I bet it would be frightfully slow though.

 

Alternatively I guess you could keep the scripting elements of the executable as separate source VIs, and use VI server calls to load and execute them. Less clunky than the above idea.

 

Any other ideas?

Edited December 19, 2013 by Thoric

[Darren]

The LabVIEW Run-Time Engine excludes functionality that is purely for editing use...for example, there are no palettes in a built EXE. I'm guessing this is done to keep the Run-Time Engine size down. For better or worse, LabVIEW Scripting is considered editor functionality, and as a result, is not currently included in the Run-Time Engine.

 

FYI, the VI Analyzer Toolkit includes a test called Built Application Compatibility that will check your application for any functionality that is not included in the Run-Time Engine.

[gleichman]

If you're running this on a computer with the LabVIEW IDE installed, why do you need to create an exe?

[Thoric]

This component is part of a much bigger system that needs to work optionally on a machine without LabVIEW. I'm conducting a feasibility study at the moment, so if this doesn't work out too confidently I'll pull the plug.

[JackDunaway]

Thoric, the way I do this is using Actors, where the Actor using scripting methods is running in the LV environment.

 

Consider an actor as just an API around a shared resource, used to abstract and encapsulate state and resources. Defining an API to the Actor as a TCP/IP messenger with endpoints to handle message types (the native LV2013 Embedded Web Servers work swimmingly for this purpose) provides an API with the subset of functionality that you want to perform with the shared resource.

 

Following your example above, one message type into the Scripting Actor would be "CreateNewVI", and the payload passed with this message are all the by-value parameters needed to constrain the creation of a new VI. That message from the remote caller is marshaled to the Scripting Actor running in the IDE, which has exposed an API through HTTP endpoints. The new VI could further be manipulated through additional messages, or information about it could be returned to the caller by-val.

 

Limitations? Unlike .NET Remoting, we don't have native type safety between two remote applications, or "direct access" to the object itself. Additionally, this new level of indirection requires more programming -- you're creating a new by-val wrapper API as a subset of the by-ref shared resource API of Scripting. But this is both good and bad -- from a security standpoint, it's fantastic (since only the desired subset of VI Server is exposed, we have built-in declarations for things like access/error logs, security policies, access policies...). From a debugging standpoint, I'd argue it's far simpler, because all API calls are transactional with no distributed mutable state -- that's just a boon of actor-oriented design for ya.

 

Whether or not this strategy is suited for your problem domain is sensitive to many factors (more business than technical) -- though, know that what you're wanting to do is possible (at the same time, technically elegant and concise), and i'm glad to talk more on specifics.

[Thoric]

Jack. That's. Just. Awesome. 

 

I can see how powerful and reusable such a scheme would be. I'll be giving that a go (or at least a basic framework akin to what you describe) and I'll approach you directly, if that's ok, should I get a bit stuck.

 

Thank you