X___

I have answered my own question by not checking off the "Disconnect unused inline subVIs" checkbox. However, I now have the issue that all the libraries in my Source Distribution now refer to the original paths of included VIs. This is strange as I have preserved the folder hierarchy when releasing the source, and I was under the impression that libraries, projects, etc. were relying on relative paths... There seems to be no way for me to resolve these conflicts, and even if there was, I don't think this is a practical way to handle this type of release. Does any one have any experience with this type of release (and actually tried to use the released source)? Note that the exported project, even though it is riddled with conflicts does let me run the top level VI just fine, as if all this complaining about conflicts was just for show.

I have a large project with many libraries which I am trying to release as a Source Distribution. I am regularly releasing standalone executables of that project without a hitch. However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs. Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken. I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next... Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries? LabVIEW 2021 SP1 64 bits on Windows 10.

Thanks for the clarification.

Can you tell more? The site is pretty terse. Examples of topics discussed in past editions would be useful.

It takes a thief to catch a thief.

Feed an array comprised of non trivial equal numbers (e.g. a 1,000 values of 1.2345) to the Std Deviation and Variance.vi of the Mathematics>>Probability & Statistics palette and look at the standard deviation output using a display format such as that shown below: You will be surprised to see that the standard deviation is non zero and within the range of the precision for the type (~1E-15). While this might not be an issue in most use cases, it is still not an optimal result, and suggests that the calculation done in the called DLL is not optimal (it probably uses the standard formula, but because of round-off errors, the outcome is non-zero). I am posting this in the "bug" category, although it is not strictly speaking one, just to warn unsuspecting users (like me), that dealing with floating point numbers comes with its load of gotchas. Here is a snippet to experiment with the phenomenon: Again the display format of the standard deviation indicator needs to be chosen wisely to reveal the round off error.

I did that too but it broke a VI connection in one of the analysis VIs...

NI Package Manager is advertising a LabVIEW 2021 SP1 f6 version that I would like to learn about before installing it, but I am unable to find anything online. Does anyone have a better search engine (or insider trick on how to get the Package Manager to be helpful)?

Try decimate array?

This actually doesn't work as a general solution (one exception is enough to invalidate the rule, and I just experienced it). However, as stated before, I believe that as long as they don't break the code, LabVIEW's compiler hallucinations can be ignored.

LabVIEW's motto: Move slowly and break things!

Another example of tricks with units. The above formula works fine. If I want to check the value of the Boltzmann constant by adding an indicator where indicated: Things look fine but they are not: tested in LV 2021 SP1 64 bit

I date back from the pica.army.mil email list but never used Usenet. I am so not anonymous that I had a bunch of members of that mailing list drop by in one of my old labs say hi and gift me with a NI screw driver (this was back in the day where NI was gifting their users with goodies and trying to cultivate their relations with universities, just to give an idea of how far back I am talking about). I was already pestering about LabVIEW shortcomings (to my defense, that was pre-undo). Nothing changes...

Noted.

I am not sure I get it. What is that "post-processing VI" you are talking about?