Running VBAI on 32 and 64 bit machines

[eberg]

I've have a standard VBAI routine developed on a 32-bit machine, using lots of .vi files, and running on multiple hosts.  To date, all the VBAI instances have been on 32-bit machines, with no issues, i.e., I just copy the VBAI routine to the new machine and run it.

But the latest instance is a 64-bit server, and while VBAI installs and runs locally, it installs in the "...\Program Files (x86)\..." folder which throws off all of my .vi file calls.  I tried putting the .vi files in the "....\Program Files\..." folder maintinaing the folder structure, and it appeared to work, but it didn't pass any parameters, and I couldn't edit any steps...

So here's my question:  Is there a way to make my standard VBAI routine run on the 64-bit machine, or do I have to load LabView and recompile the routine?

Thanks,

Eric

[Brad · Accepted solution]

When you say you can't edit steps, what do you mean? Do you get an error about VI is broken when editing a Run LabVIEW VI step in VBAI? I would recommend you follow the directions for creating your VI into a built LLB for deployment. These directions can be found when you're editing the Run LabVIEW VI step, and you go to Help>>Show Context Help. There will be a link to "Saving VI for Distribution" in the FAQ tab, which will walk you through how to make an LLB with all dependencies required in an LLB that can more easily travel with your inspection as you move systems.

I would also recommend that in the LV project, you include all your source VIs needed by the various Run LV Steps in your VBAI inspection, and this will allow you to have a single LLB that is easily portable. I would also recommend that you put this single LLB in a location that will not change when you move from one system (32-bit) to another (64-bit), so don't put it in your c:\Program Files (x86)\. On RT, we look in C:\User VIs\, so you could put your LLB in the same location on your windows machine, and then if you ever do move to RT, it will be very easy to have the LLB found.

It's important to have your source VIs in one location (along with the LV project you use to create your LLB), and the generated LLB/source distribution in another location (i.e. c:\User VIs\) and when you want to make changes, edit your source VIs and use the same project to rebuild you LLB that VBAI will use. You do not want to edit your built LLB\source distribution, and accidentally put VIs from vi.lib in there or else things will break.

Hope this helps,

Brad

[eberg]

Brad,

Thanks, this should work, I guess I've been "getting away with" not building a portable library since the installations to date have identical file structures.  So I will follow the suggested approach, since the user VI path-names are the root cause of my portbaility issue.

As for the error I was getting in editing steps, it was not an exhaustive test:  I usually put a Set Variable step right after a .vi call when reading information into VBAI, so when my .vi call did not appear to be updating any information, I tried to edit the associated Set Variable step to see what if any values were being updated.  That's when I got a message along the lines: Properties not available...and for some reason I'm thinking it clued me into the fact that they were missing in the x86 sub-directory, but I'm not certain.  I ended the experiement at this point since it was more of a cludge than I would typically deem acceptable for deployment.

Thanks again,

Eric

[eberg]

Not out of the woods yet.  I moved all my user VIs as suggested, but now I get Error 7 file not found when I run the main .vi file.  No surprise, I moved the .vi file to the user directory, but how can I fix it?  According to the properties, it shows the right (new) .vi path, but the error persists.  How do I fix it?

[Brad]

I don't understand where you get a file not found error. Is it when you edit the Run LabVIEW step in VBAI? Can you include your LLB and a simple inspection that uses it so I can better understand where this error is coming from (or include screenshots). I would not expect an error about file not found when you browse to the new location inside the LLB from the Run LabVIEW step. Your VIs may use relative paths in their code and now the location of the VI has changed, and those paths might not be valid anymore. Now that it's inside an LLB, you'll need to go up one more level to find your files...if that's what you're doing, that's my only thought for where a File Not Found error might come from.

Hope this helps,

Brad 

[eberg]

My mistake, I thought the Error 7 referred to the path of the "Open File+.vi" file.  But it doesn't it refers to the path of the target, a .csv file that was in one of the User VI directories I moved.  The target path was hard-coded by the original developer of the code, so once I found and corrected the string constant my VI ran.  And here I was thinking I had to edit the path of every .vi I had moved....boy am I relieved.

So disregard the question, problem solved.

Eric

[eberg]

So now the next obvious question is:  Why is the Open File+.vi file in one of my User VI sub directories, I think the original develper copied all the standard .vi files they used into their User VI directory...is there an easy way to fix this, e.g., can I just delete instances of standard plugins from my User VI directory?

[Brad]

When you build an LLB using the directions in the Run LabVIEW step mentioned above, all your VI dependencies (including vi.lib and user.lib) will be included in the LLB and your top level VI will now link to the VIs in your LLB. So it won't matter if you delete files from your user.lib or even move the LLB to a machine without LV installed, the LLB will have everything it needs so VBAI can call it. There may be DLLs the LLB needs, but LV will put those in a data directory next to the LLB and the VI will have a relative link to that data folder, so if there are any external dependencies in the Data Folder, make sure to have that folder travel with your LLB.

Hope this helps,

Brad