Jump to content

Issue Running Exe that Includes SCC VI's


Recommended Posts

I've completed work on a VI that uses the SCC VI's included in LabVIEW to get the latest version of my groups Reuse Library. The VI works great and will be used at the startup of LabVIEW to hopefully keep all our Machines up to date with the latest versions of our reuse code. ( Another Thread in relation to this project is Launching Application at LabVIEW Startup ).

Alright, now for the issues that I've encountered. First, when I build an executable from the VI that uses the SCC VI's included in LabVIEW it does not work as it did when running the VI from within LabVIEW. The issue that It appears to be having is that it cannot find the Source Code Control Configuration settings, and therefore cannot connect to our VSS. This makes sense to me considering the fact that the SCC Configuration Settings are something that is Setup within LabVIEW. But, this leads me to question how we are supposed to get these VI's to function from within our own applications that run from executables. Are these VI's not meant to be used within a Distributed Application? Or, is there a Workaround that I'm missing to accomplish this?

I look forward to hearing your opinions and/or knowledge on this matter.

Thanks In Advance,

Dave Graybeal

Link to comment
I've completed work on a VI that uses the SCC VI's included in LabVIEW to get the latest version of my groups Reuse Library. The VI works great and will be used at the startup of LabVIEW to hopefully keep all our Machines up to date with the latest versions of our reuse code. ( Another Thread in relation to this project is Launching Application at LabVIEW Startup ).

Alright, now for the issues that I've encountered. First, when I build an executable from the VI that uses the SCC VI's included in LabVIEW it does not work as it did when running the VI from within LabVIEW. The issue that It appears to be having is that it cannot find the Source Code Control Configuration settings, and therefore cannot connect to our VSS. This makes sense to me considering the fact that the SCC Configuration Settings are something that is Setup within LabVIEW. But, this leads me to question how we are supposed to get these VI's to function from within our own applications that run from executables. Are these VI's not meant to be used within a Distributed Application? Or, is there a Workaround that I'm missing to accomplish this?

I look forward to hearing your opinions and/or knowledge on this matter.

Thanks In Advance,

Dave Graybeal

If your application is to update your VIs to use them in LabVIEW Environment, why can't you run these VIs in LabVIEW before using the project?

I have not used SCC within LabVIEW recently but maybe you could try to put the application executable in the LabVIEW directory? There it could find the setting where they are expected to be.

Link to comment

my guess is:

if you start your VIs in the development environment, the SCC VIs use the LabVIEW SCC settings. If you start it as an exe, there is an instance of the LabVIEW Runtime engine started in the background, which has its own memory, thread, working directory, etc ...

a workaround could be: calling the SCC-VIs dynamically and do NOT include them into the exe, but provide the path to to the LabVIEW directory ...

I am not very experienced with SCC, so this "guess" could be complete crap, but I think, it's worth trying ...

Link to comment
The issue that It appears to be having is that it cannot find the Source Code Control Configuration settings, and therefore cannot connect to our VSS. This makes sense to me considering the fact that the SCC Configuration Settings are something that is Setup within LabVIEW. But, this leads me to question how we are supposed to get these VI's to function from within our own applications that run from executables. Are these VI's not meant to be used within a Distributed Application? Or, is there a Workaround that I'm missing to accomplish this?

Dave,

I assume you have followed the instructions on "Building Stand-Alone Applications with Source Control VIs" from the LabVIEW help? Here is an on-line link. I think your problem maybe that your application's .ini file doesn't have the necessary configuration tokens in them. Take a look at KnowledgeBase entry 3M0D2S00. This KB was supposed to be live but wasn't, a collegue of mine saw your post and realized it wasn't live and updated it today.

Kennon

Link to comment
Dave,

I assume you have followed the instructions on "Building Stand-Alone Applications with Source Control VIs" from the LabVIEW help? Here is an on-line link. I think your problem maybe that your application's .ini file doesn't have the necessary configuration tokens in them. Take a look at KnowledgeBase entry 3M0D2S00. This KB was supposed to be live but wasn't, a collegue of mine saw your post and realized it wasn't live and updated it today.

Kennon

Thank you Very much Kennon, This looks exactly like what I was missing. I'm going to give this a go and make sure it solves the issue I was having. I didn't think to look for an instruction set on NI's website as I have built many applications in the past and wasn't counting on the need to take extra steps when using other NI provided VI's. It would have been nice if the LabVIEW application builder would have recognized the use of these VI's and auto inserted the necessary lines in the INI automatically. Maybe thats something to toss up to The Wish List thread!

Thanks again,

Dave Graybeal

Link to comment
It would have been nice if the LabVIEW application builder would have recognized the use of these VI's and auto inserted the necessary lines in the INI automatically. Maybe thats something to toss up to The Wish List thread!

Dave,

Yep it would be nice if App Builder took care of this. We did make some progress in 8.0 in that we automatically copy the labview.ini file for you and rename it to yourapp.ini. We do remove some of the entries that are only used by the development environment, like grid line settings, and in a test I just did we do remove the SCC settings as well. I'm trying to decide if that is an oversight or because building SCC into an EXE is not very common, what we should do to not clutter the ini file for everyone else. I'm thinking it isn't too bad to clutter the ini file for everyone else and we should leave them in there.

Also in 8.0 you can specify a .ini file from your project to use as your application's ini file, you could do this before but now it is highlighted as something that needs consideration. This way you know what settings are going to be used like specifying the web server to be enabled in the exe even when it is disabled in LabVIEW.

I think copying the labview.ini by default is really just a good way to get started. If you have an EXE that you are serious about what you want to do is have a custom ini file for it. I recommend doing the following. Configure all your settings in LabVIEW the way you think you need them. Then open your labview.ini take out everything you don't think you need and save that as yourapp.ini (change the section header too). Then add that file to your project so you can include it as the ini to use for the build specification.

I think that while building exes has gotten easier there are still some rough places (like ini files) that need some polishing, we'll keep working on it.

Kennon

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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