Jump to content

etgohomeok

Members
  • Posts

    4
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    2013

Recent Profile Visitors

1,300 profile views

etgohomeok's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

0

Reputation

  1. Thanks, I was not aware of the hidden gems package and it looks like there is a function there for moving libraries on disk. Looking at the block diagram of that VI, it seems that there is a specific order of operations in saving the various project items to ensure the linking stays in tact. We will work with that and see if we can get our project to work.
  2. Hello, this is not strictly VI Scripting related but I believe it's a pretty similar topic, so I hope this fits in with the discussion on this board. I am attempting to write a script that parses through the contents of a very large LabVIEW project (thousands of files) recursively and selectively moves/renames some of the files. The basics of this are fairly simple, however I have thus far been unable to come up with a way of moving files on disk that handles all relinking and dependencies without any issues. At a high-level, my question is whether or not the "Move on Disk..." option in the right-click menu of the project explorer "Files" view is accessible programmatically somehow, using invoke nodes. The option I'm talking about, for clarification, is this one: Using this option in the project explorer seems to be able to move all types of files in the project (VIs, libraries, classes, etc.) and handle all relinking properly without any conflicts popping up. However, there doesn't seem to be an equivalent "Move on Disk" method int he invoke node for project items. I have had some success with some of the "super secret" nodes for VIs: However this only works for VIs and there is no equivalent function for library (.lvlib) and class (.lvclass) files. I've tried various combinations of saving and relinking functions that are available, however I always end up with conflicts when I load the project after running my script. If the "Move on Disk..." function is not accessible programmatically, does anyone know of another way to programmatically move/rename library and class files on disk without causing conflicts? Thanks, Ethan
  3. 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?
  4. 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?
×
×
  • Create New...

Important Information

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