Jump to content

Jim Kring

JKI Team
  • Posts

    2,200
  • Joined

  • Last visited

  • Days Won

    105

Posts posted by Jim Kring

  1. @Zaphiro Technologies

    CC: @RolfK

    There is a cross-platform shared library naming trick.  (It could be that the package build process messed up the paths when writing linker info.)

    See: LabVIEW Help >> Configuring the Call Library Function Node

    Quote

    If you want to run applications or shared libraries created on different platforms, use the * wildcard to make the reference to the shared library platform independent. Use * for the file extension and * or ** to the left of the file extension, depending on how you name 32-bit and 64-bit libraries.

    The following example illustrates how to use the * wildcard.

    Example  -->   Translation

    • myshared.*   -->   LabVIEW replaces the reference with the appropriate file extension to match the platform that is running the Call Library Node, for example, myshared.dll, myshared.so, and myshared.framework.
    • myshared*.*   -->   LabVIEW replaces the reference with myshared32.* on 32-bit platforms and myshared64.* on 64-bit platforms. You can place the * anywhere to the left of the file extension. For example, my*shared.* can translate to my32shared.*. LabVIEW replaces .* with the appropriate file extension.
    • myshared**.*   -->   LabVIEW replaces the reference with myshared.* on 32-bit platforms and myshared_64.* on 64-bit platforms. You can place the ** anywhere to the left of the file extension. For example, my**shared.* can translate to my_64shared.*. LabVIEW replaces .* with the appropriate file extension.
  2. Hi @JKI-OfAllTrades,

    Looking at the VI Peek package info, I see that it's compatible with LabVIEW 2020 or greater, which is why it's not showing in your package list.

    Note: In the VIPM Settings window you can show all packages, even if incompatible with the selected LabVIEW version. However, you won't be able to install it.

    One idea is to download the source code and then use LabVIEW 2020 Community Edition to Save For Previous into LV2017.

    Good luck!

  3. Some searching online shows. Possible solution…

     

    This kind of behaviour can be encountered when a scheduled task is created in order to continue the installation process after a reboot triggered by a prerequisite. After the system reboots, the setup is launched by the scheduled task and, then this scheduled task is then automatically removed. In your case it seems that the removal doesn't happen, thus the setup is launched on every boot. 

    You could try to manually delete this scheduled task from Windows Task Scheduler. If you cannot find a task in Task Scheduler, please check if the following registry keys contain a value which triggers the setup:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

    or

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
    
    • Upvote 1
  4. Hi @Anton Sundqvist

    My guess is that the permissions are such that only administrators can install things into the "C:\Program Files (x86)\National Instruments\Shared\LabVIEW CLI" folder.  Probably, the easiest solution is for the user to make that folder writeable to all users.  Then, the package should be able to install files there, even if VIPM is running as a non-admin user -- this is better than trying to run VIPM as Administrator, which can result in other issues.

×
×
  • Create New...

Important Information

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