viServer OpenLibrary gets Corrupted Memory error

[billtr]

I am trying to integrate LabVIEW into our ClearCase build process. At a basic level, we store all vis in libraries, we plan to make increased use of LabView projects.

Right now the team is using LabView libraries without projects. I have access to some of them. I can open them using LabView 8.51. A warning is issued for objects found in different places, but the vis in libraries can be opened. However, when I try to execute this code:

Set Args=WScript.Arguments
llbName=Args(0)
WScript.Echo "Looking for vis in library "& llbName
Set lvapp=CreateObject("LabVIEW.Application")
Set llb=lvapp.OpenLibrary(llbName)
Wscrpt.Echo "Found library "&llb.Name

this is what happens:

D:\Data\builds>cscript get_vis.vbs Z:\tse\Projects\NEXTGEN\Tests\CurrentLimit.llb
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Looking for vis in library Z:\tse\Projects\NEXTGEN\Tests\CurrentLimit.llb
D:\Data\builds\get_vis.vbs(5, 1) LabVIEW: LabVIEW:  Memory or data structure corrupt.

Looking over the object model, the only way I can see to get a list of vis in a LabView library is to create an instance of that library using the OpenLibrary method of Application.

[NI-Bob]

Hello billtr,

Thank you for contacting National Instruments.  I have been looking into this issue and had a few questions for you.  First of all you say that you are able to open the .llb file in LabVIEW 8.5.1 right?  Is it possible that the warning that you are getting is because you are missing certain files on your machine? 

After looking through your code it looks like you are using VB Script is that correct?  Where do you have this code execute?  Is it built within a LabVIEW project or anything or is it just simply running VB Script code in order to open this .llb?

Also, I am trying to get an idea of where there error is actually occurring within your code.  Is it able to execute the "Set lvapp=CreateObject("LabVIEW.Application")" line and then errors out when trying to actually open the .llb here "Set llb=lvapp.OpenLibrary(llbName)"? 

If you can give me a little bit more information in general on this issue then I will be able to research this and try to determine why you may be getting this error.  I look forward to hearing back from you!

[billtr]

Bob,
Thank you for replying. I have been tasked with writing an extension to our version control scripts that will go through a large project (dozens of libraries, potentially more than one LabView project), identify libraries or LabView projects that have changed, then go through each vi in the changed library or project and diff it to see if it really changed, then try to merge it if it has changed. If the merge is successful we are happy, if it is not then the developer will be told to manually merge the changes because the merge is non-trivial.

It is not enough for us to simply say that a particular library or project changed. We need to know the vis that are different, and we need this to be fully automated, because there are hundreds of vis in one large project.

The test library I used is in ClearCase, visible as a file in a path on a drive letter. I am able to open that library in LabView, although I get three warnings that say that dependent vis were gotten from different paths than originally saved. Once the library is visible as the folder with vis inside, I am able to open each vi in the library, no broken links.

All I tried to do with vbscript was the exact same thing I tried to do with the application on the same computer from a command prompt: Open a vi in a library. The vbscript does not get past the line
Set llb=lvapp.OpenLibrary(llbName)
in other words, the vi server can get an instance of LabView (lvapp) but cannot use this reference to get an object reference to the library.

[NI-Bob]

Hello Bill,

I have been in contact with Kalin regarding this issue.  I noticed that he pointed you to a few examples that may have helped you determine if there is another way to access the .llb files using VBScript or C#.  Have they been of any help?  Do you have any questions on those examples? 

Also looking through the information you sent to Kalin you said that you had LabVIEW 8.5.1 installed but you are trying to call the .llb files just from a command window using VBScript is that correct?  I am working with other engineers to determine if the library files need to be complete with no warnings.  I will update you when I am able to find any new information.

Please let me know if you have any updates or further questions on this issue and I will do my best to assist you.

[billtr]

Hi Bob,

Wow, you are up late. While I appreciate Kalin's willingness to help, I had these examples and the vi server help file. I have LV 8.5.1 professional installed, and I am using vbscript to automate it via the ActiveX interface.

I'd like to gently point out that the real problem here is the lack of thorough documentation and good error messages. The code snippet I tried is absolutely trivial, anyone can see from the LabVIEW help file that the openLibrary command must be used to access a library. I got an instance of the engine successfully, but then when I tried to get a reference to a library the thing just blew up with a memory or data structure corrupt error. This is the equivalent of a traditional program core dumping on print "Hello World!\n" .

I realize that good error messages may never happen, since this is a mature product. However, if I cannot get my hands on a definitive programmer's guide where I can get past the trivial problems without help, I will be forced to conclude that automating LabView works well in the simple case of running and pushing buttons on a simple vi but it cannot be used to automate the development environment, despite the claims of NI and the documentation that clearly states this is possible.

A clear, definitive answer by the end of next week would be appreciated. If the answer is that indeed the development environment cannot be automated, I will explore using LabView itself to do what I want, put a simple vi on that as an interface and automate the simple vi. We know that works.

Examples of using LabView to navigate projects and libraries would be very helpful if I end up having to use LabView to do that.

Best regards,

Bill

[NI-Bob]

Hello Bill,

Thank you very much for getting back to me.  I just wanted to clarify a few things so that we make sure that we are both on the same page here.  It sounds like you are trying to set up an ActiveX Server using LabVIEW, similar to the examples we gave you, in order to utilize your VBScript code.  Is that correct or are we using it the other way around and having LabVIEW act more like an ActiveX client?

I am also curious if there is a specific reason why we are using the Command Prompt for this code.  Can you give a more detailed description of how you are trying to implement this solution?  Any extra information at this point will help us make sure that we are getting the best answer for you.  If it is at all possible to attach any of your code as well that would also help.  Thank you very much for your patience on this issue.  I will work with some other engineers here to get you a more definitive answer for you during the week next week.

 

[billtr]

Hi Bob,

Good call. It is always important to start with the requirements!

If you use a vi server it means that the LabView is being driven from the outside application, not the other way around. I am trying to drive LabView via the ActiveX interface. Most people do the opposite: inside LabView (the main application) access other software via ActiveX.

I am writing a process control system for our test engineers to automate the entire software development cycle by bringing together our project tracker (in-house) and our configuration management software (ClearCase) in such a way that no test engineer needs to know the arcane ClearCase commands, and all development work is done on branches that must be merged back to the main line for others to see the changes.

For projects larger than something small, or projects where multiplie developers must work on the whole system together, this branch - develop - merge idea is key. It enables developers to be very productive without stepping on each other's work.

The section "Source Control" in this document http://zone.ni.com/reference/en-XX/help/371361D-01/lvdevconcepts/configuration_management/ refers to the concept of reserved checkouts, i.e. if I want to change a file I check it out reserved, so no one else can toudh it. This is an immature concept that does not work with more than 2 or 3 developers in a small team working on very focused projects. Branching eliminates the need for this coordination, but it then demands a robust way to merge changes.

ClearCase knows how to merge text. I have that part almost ready to release now. ClearCase cannot merge binary files, it can only recommend the latest version if that can be clearly determined, otherwise it is up to the developer to tell ClearCase what the latest version is, or to check in yet another version that is known to be the latest.

LabView vis are binary files. Since that is our main programming language, we cannot simply take an entire library or project that may have been worked on by 6 people over a 3 week period and wave a wand saying that a particular version is the latest. We must be able to do these things:

1. Detect that more than one person has changed the object. This ClearCase can do at the library or project level with no help from LabView.
2. Provide a list of what individual vis have changed. This must be done in LabView. I had wanted to get the list of all vis in a library or project by automating LabView, then automate the stepping through the list using the command line merge tool (lvmerge.exe) to detect vis that were really different.
3. Assist the developer to merge the changes by cycling through the vis that have changed automatically, opening up the vis in the merge tool so that the developer does not have to tediously click through the file-open nonsense for dozens of vis. The merges must be done in LabView, the sequencing could be automated externally or internally.
4. Mark successful merges. This is done in ClearCase.

In summary, the ability to merge individual vis is a non-starter when NI itself strongly recommends projects and libraries for organizing projects. To put it in simple terms, it is like me telling you I have this fantastic tool for merging text files, but the entire body of source code must be stored in zip files. So, if you want to use my tool, you must manually open the zip file, extract the text file, then work with it and re-zip it when done. You would not be happy.

Best regards,

Bill

[billtr]

Hi Bob,

I am experiencing the power of code reviews. I was going over the conversion of our current soup of stuff to LabView projects when I realized that our real problem is dot-llb files that combine vis into a single physical binary construct.

Instead of doing that, you can put the vis in a folder, then reference the folder as a lvlib and put that into the project as a reference. Now our whole setup is expressed as individual vis while still having the advantage of the grouping by library and the packaging by project.

By doing this, ClearCase tells me exactly which vis have changed, and I can use the standard lvmerge.exe tool provided to attempt the merges automatically. I may be able to set ClearCase up to do this on the Windows side with no special effort on my part in development.

Thank you for hanging in there with me.

Best regards,

Bill

[NI-Bob]

Hello Bill,

This sounds like good news!  Using a lvlib reference in the project allows us to have access to each individual VI as opposed to the single instance of the .llb file.  You said that you are able to now tell which VIs have changed and them merge them using the lvmerge.exe, does this mean that you are satisfied with this solution?  It seems extremely similar to your solution except we are just simply bypassing the .llb file that was giving us issues from the beginning.  Please let me know if you have any further questions on this issue and I will assist you to the best of my ability.