From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-23-2016 10:07 AM
Okay thanks for clarifying that. What version of LabVIEW and run time engine are you using? I want to check if this might be a version specific problem. There are some known issues with web services in certain versions of LabVIEW.
11-23-2016 12:01 PM
We are running LV 2014 with the most recent updates.
I would love to bump this up to 2015, but am worried that this will create other issues (also not sure if the client has access to 2015).
11-28-2016 10:39 AM
Are you using an installer as well or just an executable?
Do you have any patches for LabVIEW 2014?
The f2 patch for LabVIEW 2014 contains a fix for a known issue when including Web Services in an installer. It is a good idea to go ahead and install the latest patch, to avoid running into future issues.
11-28-2016 10:50 AM
I am running v14.01f3.
11-29-2016 04:17 PM
Thanks for the info. It seems that either a component of the code is causing the slow deployment, or it is a product of the large size of the application and web services. Based on the speed that the example project deployed, I am leaning towards a component of the code. Do you agree?
You mentioned that when the web service was smaller it did not take as long to respond. Was there a specific point in time during development when the executable started deploying significantly slower as an executable? How quickly did it deploy when the application was smaller?
Are you using any toolkits in your project that are not being used in the Weather Station example project?
Are all web services set to run at startup?
If you do not enable debugging for the executable, do the web services deploy faster?
I'll continue looking through our internal documentation in the meantime to see if I can find any additional information regarding this behavior.
11-29-2016 04:59 PM
Thanks for the info. It seems that either a component of the code is causing the slow deployment, or it is a product of the large size of the application and web services. Based on the speed that the example project deployed, I am leaning towards a component of the code. Do you agree?
Based on my past experience - yes.
Are you using any toolkits in your project that are not being used in the Weather Station example project?
lol - yup. This is a very large project that utilizes the AF and countless other libraries such as those using OpenG and the ESF. But, the AF touches these the most as we send messages from the web service to the main exe.
Now this brings me to another thought - what would happen if I called the launcher in a web service startup VI? I have not tried this before.
You mentioned that when the web service was smaller it did not take as long to respond. Was there a specific point in time during development when the executable started deploying significantly slower as an executable? How quickly did it deploy when the application was smaller?
Unfortunately, there was a disconect between the smaller version and this large version and so it is impossible to identify this breaking point.
Are all web services set to run at startup?
Yes
If you do not enable debugging for the executable, do the web services deploy faster?
I had this thought also - answer is no. One thing that I should note in the deployment of the exe is that I get a warning that things are loading from multiple sources. I will try to track down this file
11-29-2016 11:25 PM
OK...so here are some warnings from the debug session that are thrown every time I debug. They are related to paths of messages in the AF. The web service seems to expect them from a location within the web service itself but they load from the main app location in c:\ni-rt\startup. Any thoughts?
11-30-2016 06:31 PM
I think this would be handled better through a service request with our Applications Engineering department going forward. Please create a service request at ni.com/support and link this forum thread to the service request.
Thanks,