11-29-2017 07:13 AM
I performed the Test.
This broke the code in two ways:
One case of an event structure was left without trigger (was: window area: mouse release)
All references to a sub panel disappeared (so presumably the sub panel disappeared).
I fixed it for these numbers:
FP-O: 2712.3K
BD-O: 21547.9K
Code: 3583.0K
Data: 7837.4K
Total: ~35680.5K
On disk: ~6935.4K
Code complexity: 17.4
last compiled: partial comp. optimisation
So BD-O space has gone up considerably, space on disk has gone back down.
Does that point us to the root cause? Can anything be done without messing up the FP?
11-29-2017 07:20 AM
As a subpanel control doesn't have a terminal, copying the BD will not copy the subpanel control. Place this one on the FP before copying and that should work out.
It seems to me that there could be some caching issue with the original VI on disk.
What about saving the original VI with a new name?
11-29-2017 07:34 AM
Thanks for taking the time.
The VI has ~15 other sub panels that survived the BD copy just fine - weird.
Saving under a new name yields the same 12 MB disk footprint.
Best regards,
Florian
11-29-2017 07:36 AM
What about separation of compiled code for a try?
11-29-2017 07:52 AM
That should already be the case.
Should I reverse that?
11-29-2017 07:53 AM
Yes. Toggle once, save, check size. Toggle again, save and check size. Does it change? If yes, how?
11-29-2017 08:13 AM - edited 11-29-2017 08:17 AM
That was it!
Not so much the toggling, but the VI did not have the "separate" checkbox checked.
With the box checked it is 7 MB, without it 12 MB.
Here's what I think happened:
The affected VI was saved under a new name recently. Some time before I had separated all compiled code.
I'm pretty sure I had set the environment option "separate for new files" - but it was not set to on when I just checked.
It either got reset / not saved properly due to a crash of the development system, or I was just wrong and didn't set it (I'm pretty sure I did though).
One more mystery solved. Thanks for taking the time Norbert - I would not have looked at that setting anytime soon on my own.
Edit: I had not set the environment option, but had set separate for new objects in the project properties. Shouldn't that have worked too?
Best regards,
Florian
11-29-2017 08:29 AM
Renaming a VI does not create a new VI (VI Server wise). That means that the new copy of the (existing) VI should have identical settings to the original VI before the renaming.
11-29-2017 08:42 AM
Sorry, I'm not a native speaker and work with a german version of LabVIEW.
What I meant was (translated roughly) using the "save as" dialogue of the VI and selecting "open new copy" with the "add to project" box checked.
Should that retain properties?
If so the code separation must have been turned off in some other fashion - I surely didn't do it manually.
11-29-2017 08:50 AM
Without having tested this, i guess that Save As with a new name still ports all settings. Imagine if settings like Execution settings (e.g. reentrancy) got lost...
Maybe someone saw an asterics on the VI, wanted to review List Unsaved Changes and did accidentally misclick without taking a notice. After reviewing the changes, she/he chose to save the VI before selecting Save As to create a new copy....