Jump to content

Recommended Posts

I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files.

 

I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description:

Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi

Possible reason(s):

LabVIEW:  (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine.

An error occurred loading VI 'my.vi'.
LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated

Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?

Share this post


Link to post
Share on other sites

Not really.  I mean turning VI source code into a compiled piece of binary, is the responsibility of the compiler.  In a built EXE, there is no compiler, this is in the LabVIEW IDE only.  So when you look at a VI file that has separate compiled code, the compiled binary is saved in a temp location that I can't remember at the moment, but I suspect it is in ProgramData or AppData somewhere.  

 

If this tools needs compiled code to execute, and you don't have it in the VI file, and you are running from the run-time engine, then you have no way of using this tool.  But if this tool can run from the LabVIEW IDE I think you should be fine.  

 

You can still invoke a VI to run programatically from a command line, and get functionality that looks like a built EXE, but runs from the IDE.  LabVIEW.exe supports a command line parameter, which it will attempt to open as if you did a File >> Open.  If this file is a VI, and it is set to run when opened then this might be a solution for you.

Share this post


Link to post
Share on other sites

Long and short your answer is what you suspect - there are several VI server methods that are not implemented in the run-time engine and are thus not available if you build an executable. The same issue crops up in other areas like build automation.

 

The way I get around this is to use the IDE but automate the process via scripting. I have a build VI (happens to be a VI Package) that runs automatically via LabVIEW command line arguments that performs the necessary operations and then quits LabVIEW. Not ideal I know but the only realistic option I have found.

Share this post


Link to post
Share on other sites

You can still invoke a VI to run programatically from a command line, and get functionality that looks like a built EXE, but runs from the IDE.  LabVIEW.exe supports a command line parameter, which it will attempt to open as if you did a File >> Open.  If this file is a VI, and it is set to run when opened then this might be a solution for you.

 

Thanks, this is likely what I will do since I don't see this tool being useful on systems without the LabVIEW development environment installed anyway. Is there a way to pass a command-line argument to the VI itself (since the VI needs to know which directory to search)? I guess I could create a compiled launcher that generates a .ini file somewhere with the path in it then calls my VI via command-line, and my VI can check that file for the path, but is there a better way?

Edited by etgohomeok

Share this post


Link to post
Share on other sites

Oh yeah that is a sticking point isn't it.  So I made a VI that is set to run when opened, and when it runs it just reads the Command Line Arguments using the property node.  I then opened this VI (and ran it because it was opened) using a command line call to LabVIEW.exe.  It opened and ran the VI just fine, but any command line parameters passed to LabVIEW.exe were not then passed along to my VI, I was hoping they would be.

 

A launcher would work, you could then write to a temporary path, or the ProgramData folder, and your VI could then open it.  I wish there was more documentation on the behavior of LabVIEW.exe when it comes to command line arguments, it might be possible to do what you want but I'm not aware of any other simple solution.

Share this post


Link to post
Share on other sites

Oh yeah that is a sticking point isn't it.  So I made a VI that is set to run when opened, and when it runs it just reads the Command Line Arguments using the property node.  I then opened this VI (and ran it because it was opened) using a command line call to LabVIEW.exe.  It opened and ran the VI just fine, but any command line parameters passed to LabVIEW.exe were not then passed along to my VI, I was hoping they would be.

 

A launcher would work, you could then write to a temporary path, or the ProgramData folder, and your VI could then open it.  I wish there was more documentation on the behavior of LabVIEW.exe when it comes to command line arguments, it might be possible to do what you want but I'm not aware of any other simple solution.

 

If LabVIEW was already opened, it indeed doesn't pass new arguments from command line. One possible workaround is adding "allowmultipleinstances=True" line to labview.ini config file. Command line call to labview.exe will then open new LV instance each time, and consequently the arguments will be passed. However, as with every not well documented features: use allowmultipleinstances with caution (it can go weird if you open same code in more than one instance of LabVIEW).

post-50361-0-03728100-1458683727.png

Share this post


Link to post
Share on other sites

What about the LVCompare.exe tool that can be used to automate source code control clients to know how to deal with LabVIEW files more friendly?

 

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/configlvcomp_thirdparty/

 

That should do most of the things required here and has various options to ignore certain classes of changes in the comparison.

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.