Jump to content

deploy hierarchies of shared variables in EXE


Recommended Posts

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.

SystemManager_2018-01-25_11-50-47.png

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,

LabVIEW_2018-01-25_11-49-55.png

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

Edited by ensegre
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.

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 Billy_G
      Hello, I wrote a LabVIEW program to communicate with a hardware sensor using vendor-provided LLB and a DLL files. The program runs fine on my workstation both from LabVIEW IDE and from a compiled executable. The problem starts when I copy the entire executable folder to a target host without a LabVIEW IDE (only with a runtime engine). The application opens with a broken Run arrow and a "missing external function" error message appears for every function call I made to the DLL (see attached).
      I have tested my application on 5 completely different Windows 10 computers managed by different people. On three of them with various versions of LabVIEW IDE my executable opened with a whole Run arrow and no error message. Two other machines previously had no LabVIEW, so I installed a Runtime Engine 2017f2 32-bit with default settings to match the version of my IDE. Both gave an identical error message.
      The DLL is always included in the application build. I have tried placing the DLL in every conceivable location on the target host: in the executable folder, in the /data folder, in the c:\Windows and system32 folders... I even created a full folder tree matching the location of the project on the developer workstation. Same error. When I intentionally hide the DLL, my executable prompts me to point to it upon being opened, and when I do, I get all the same error messages.
      Vendor documentation only asks to put the two files in the same folder. From programmer's manual: " The driver was written in LabWindows/CVI, version 4.0.1 and is contained in a dynamic link library which can be linked with a variety of programming languages." There is no vendor-provided support.
      One way I actually got rid of the error message was by editing every Call Library Function Node in every VI in the LLB to use relative path to DLL together with the Application Directory VI. However, I feel that there has got to be a better way to compile than by editing a vendor-provided library, especially since it works as-is on some computers. Can anyone suggest what it is?
      Thank you for your time!
       

    • By Vitali
      Hi.
      I use shared variables on several projects on different nodes. On some of them, after rebooting the OS, the variables restore their value (as it should be), on others this does not happen. I use Windows 10 and approximately the same setting. Does anyone know where I can search in the OS settings or LabVIEW to get predicted DSC behavior after rebooting the OS.
      Sincerely, Vitaly.
    • 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
      This is a DSC module question: has anybody here experience with building standalone executables which include shared variables bound to DSC modbus i/o servers? I have an issue with deployment, possibly related to licensing. I posted on the dark side, but haven't got feedback yet.
      https://forums.ni.com/t5/LabVIEW/shared-variable-bound-to-Modbus-i-o-not-working-in-deployed/td-p/3809801
      TIA, Enrico
    • 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
×
×
  • Create New...

Important Information

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