Sorry for the strange title, but its a strange problem. We have a very large application that we built in LabVIEW 2009 and have mainatined and expanded through LabVIEW 2013. When we tried to upgrade to 2014, we ran into issues with our built applications not working even though everything validated in the development environment. At the time, we were rushed, so we passed over 2014 and now we are trying again with 2015. We opened our application projects and did builds without any issues. The applications seemed to open fine and most of the functionality worked, however there were certain parts that didn't. Our application architecture uses a small main VI with a lot of spawned VIs running as processes that are accessed through a messaging system. It works really well and has been for the last 6 years. We did a lot of troubleshooting and narrowed down the problem to what seems to be a change in how the application builder tries to optimize executable size. The size of our executables shrank considerably starting with 2014. To test our hypothesis, I made the attached library and it accurately reproduces the behavior we see (in a much smaller and non-proprietary way!)
The library contains a main VI and six subVIs. The main VI creates two user events, one is a 1D DBL array data type and the other is a type-defined cluster of a String and a scalar DBL. Once a second, the VI will generate a 100 point random array and generate a 1D DBL array event with this data. There are six subVIs that all do exactly the same thing: register for the 1D DBL event, on that event, calculate the mean of the array, then generate the other event with the mean and the name of the process generating the event. The main VI is registered for these return events and uses the process name to populate a table with the results. Super simple and quite representative of our application in general (though our application uses many more data types and a more complex message routing.) The six subVIs are a mix of two properties: calling method and whether they contain a front panel control that is referenced in the code. The three calling methods we use are 1) Launch Asynchronously with Call and Forget and using the connector pane to pass the two event references, 2) Use VI Server to run the VI and have the references read within the launched VIs from a functional global variable, and 3) Use VI Server to set the value of front panel controls by name and then running the VIs. In the development environment, all six VIs spawn and return results to the main VI.
But if you build an executable from the main VI with default settings, the last two VIs will not return values. It should be noted that all the VIs launched with VI server are launched using the same subVI to do the VI server calls. If you open the build settings and in the Source File Settings page, you disable "Use Default Sattings" and "Remove Front Panel" for "Call By Name Process.vi" and "Call By Name UI.vi" and rebuild, then "Call By Name UI.vi" will return values when the application runs, but "Call By Name Process.vi" still won't. We can't get "Call By Name Process.vi" to run in an executable except by enabling debugging in the application, but this goes against recommended optimization practices and has only changed since LabVIEW 2014. The application runs without issues in LabVIEW 2013. The other thing to note is in the build settings under Source File Settings, the VIs in the Process Spawns folder have Remove Front Panel checked by default while those in the UI Spawns folder do not. Also, setting the "Show" input True on our "Launch Spawn.vi", will open the front panel of the called VI even if the "Remove Front Panel" is checked.
One last thing to note is that the VIs that don't return values to the main VI are actually getting the data event from the main VI. If you add a front panel indicator to "Call By Name Process.vi" it will show the mean value updating with all the other spawned VIs, it just can't send the result back to the main VI. If you put an error indicator on the Generate Event, it doesn't indicate that an error has occurred, but obviously, the event isn't being generated.
I'm sorry for the overly long description, but we've already done a lot of poking at this and I thought I would help by passing along what we have learned so far. Mostly, we'd just like to have a solution for this, since "Launch Spawn.vi" is how we open most of the processes on our large applications and it will be time consuming (to say the least) to replace a generic launching tool with custom launch VIs for everything.
Thanks for looking.
) Changing the exclusion settings would apply to all lvlibs. Try adding the specific lvlib to the allways encluded source file list instead
