Jump to content
Thoric

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

:ph34r:

Share this post


Link to post
Share on other sites
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.

:ph34r:

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
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.


  • Similar Content

    • By Dawid
      I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
      When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
      "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
      Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
       

      print.vi

    • By ensegre
      I wonder if someone ran into this and has a good suggestion about. I have a DSC project, in which it looks just right to organize hierarchically my shared variables. Like, e.g.

      Now this is easy to do programmatically, see the attached project. The problem arises when building an application. It would look as if the plain way to do it, would be to create a build specification which includes the additional libraries, and select their deployment in the "Shared Variable Deployment" tab. However, this doesn't seem to work for nested libraries as in my example. The only possibility seems to add in "Always included" each of the contained libraries. But by doing like this the hierarchy is flattened.
      If I include like this,

      then the variables within the container library are not deployed at runtime.
      In my example project:
      open the project in the IDE, run DeployAllSharedVariables.vi, then CheckDeployed, and see the result (all four variables found with their nested paths) build and run DeployFlatLibraries and see the result: four variables, but flattened paths build and run DeployHierarchicalLibraries: only the two variables in the unnested SimpleVariableLibrary are there. I've searched a bit, and only came up with this document, which (for >2009) says "just check the checkbox". Nor the help page says much either.
      I wonder if I can do what I'd like only compiling separately the libraries, and loading them programmatically afterwards, both in the IDE and in the exe. Which probably is sane, but inconvenient for the first attempts.
      TestDeploy.zip
    • By torekp
      So, according to this NI document
      http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/linking_vis_to_help_files/
      It should be possible to link a .chm file into your executable so that a user can choose Help > Help for This VI.  Well, I followed the advice, and no dice.  Here is my LV2017-64bit attempt.  In the development environment, it works fine, but in the executable Help for This VI is grayed out.  The .chm file is a poor excuse, and unrelated to this VI, but never mind that, it's not the problem here.

      LV17helpEx.chm
      html_help_VI.vi
      test_help_html.aliases
      test_help_html.lvlps
      test_help_html.lvproj
    • By Nienscecco
      Bonjour,
      I use Labview 2015 32-bit on a 64-bit Win& pro computer.  My application connects to Hardware using NI-VISA and NI-DAQmx only (Two RS232 communications via a VCOM port and one NI DIO card using DAQmx).  
      Until today, I was building an executable which  I was copying through the network on another win7 pro machine in the lab next to the hardware.  It was working fine with Labview Runtime 2015 installed on this machine along with NI-VISA and NI-DAQmx.  I never used an installer, I installed those 3 components seperatly.
      Yesterday I added some features to the application and the EXE won't start.  I have an error msg saying "The VI is not executable. The full version of Labview is needed to fix errors".  The machine in the lab can't run the EXE but the EXE won't even start on my development machine.  
      My previous EXE from last week still works fine. The code works fine with all new features if I run the main VI from the development environment. I've double check all of my licences status. If I open another project and compile the EXE, I am able to run this EXE (I use a complex app containing almost all the same software components) If I build an EXE with a different UI source file part of the same project, that EXE works fine. If I build the EXE from my previous version again, it works fine too. I tried removing all the new features I had added in the project and build the EXE again and I still get the error. I tried creating a new project file and import the same librairies to try building an EXE from a fresh project file and I still get the error. I tried installing Labview 2015 on another computer and try to build an exe from a fresh labview install on this computer and I get the same error. The development machine can't execute the compiled EXE) It has to be related to the code but, I can't roll-back and get functionality of the EXE again unless I totally replace all of my files from a backup made last month.  The most recent posts I read from a similar error are from 2013 and later.  And the problem described is always that the EXE does not work on the deployment machine but works fine on the development machine.  I must be at version 25 of this application to which I add improvements on a regular basis since almost 1 year.   I am really puzzled.  Is there a way to analyse or get more info about the broken EXE error?  All the new features I added are using components that were already present in the project and in the main VI.  The new features are important, I'd really like to use this working code with the hardware as soon as possible but I don't really want to install labview on the development machine.
      Any ideas? I don't know what to try next.  What would be the best information to provide / look for for the next step?
      Thanks to all in advance
      Nien
    • By Zyga
      Hi,
      I would like to associate icons with file types that are handled by a LabVIEW built application. To do so, "defaultIcon" key has to take a value of executable path with parameter "resource ID".
      The question is how to build in more than one icon with executable?
      Examples of LabVIEW keys:
      -library: ..\LabVIEW.exe,-8
      -llb: ..\LabVIEW.exe,-3
      Is it even possible with app builder? Any workaround?
       
×
×
  • Create New...

Important Information

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