Dave Graybeal Posted February 17, 2006 Report Share Posted February 17, 2006 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 Quote Link to comment
jpdrolet Posted February 17, 2006 Report Share Posted February 17, 2006 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. Quote Link to comment
i2dx Posted February 18, 2006 Report Share Posted February 18, 2006 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 ... Quote Link to comment
kennoncotton Posted February 20, 2006 Report Share Posted February 20, 2006 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 Quote Link to comment
Dave Graybeal Posted February 21, 2006 Author Report Share Posted February 21, 2006 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 Quote Link to comment
kennoncotton Posted February 21, 2006 Report Share Posted February 21, 2006 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.