Jump to content

Using scripting to inspect code from a built exe?


Recommended Posts

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?

Link to comment

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?

Link to comment
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.


Link to comment
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 by Thoric
Link to comment

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.

  • Like 1
Link to comment

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.

  • Like 2
Link to comment

Jack. That's. Just. Awesome.  :worshippy:


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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.