X___

My apologies, I must have had a brain fart when I looked into that (I suspect isolating the vim from the VI I was using it and not connecting a "no error" constant to the input)?

Things work as they should upon checking again.

When passing a "no error" error cluster to the "To JSON Text.vim" VI of the JSONtext toolkit, the output string is empty.

This is not the expected behavior.

I would expect:

  status = false
  code = 0
  source =

Tested with v1.9.1.125 in LV 2021 SP1 on Windows

The VI hierarchy window is fairly useless. For large projects, it is painfully slow to update. The links between objects don't make the architecture of a project any clearer. It cannot be printed with high resolution as a PNG or PDF file. Etc.

Ignoring these shortcomings, it appears to not behave as expected: when selecting View>>Always Show Labels, collapsed library boxes expand laterally as if to accommodate the library label, but no label is displayed. I am labeling this as a bug, but maybe it isn't.

Similarly, a library is represented by said box with an icon inside. The icon seems to be picked up randomly from one of the VIs in the library. This is not helpful. There should be a way to set a "library" icon (not just a template as defined in the library "Properties" window.

Tested in Windows LV 2021 SP1 64 bit

There is no typos and errors in your posts. Only pearls of wisdom and oracles of truth that we mortals can't understand yet... 

At this point, I have removed the single occurrence where I had used the toolkit, as the license would have been problematic to make my code acceptable as reusable.

19 hours ago, JKSH said:

It feels strange to me too. As I understand it, the "no merge" clause makes libraries legally unusable by others.

A quick search reveals that the "no merge" clause is found in numerous different software licenses: https://www.google.com/search?q="merge+the+Software+into+any+other+software" My best guess is that the clause was originally written for standalone applications (meaning that you're meant to run the software as-is, without copying its source code into your own, or linking your own software to its binaries). However, somewhere along the way the clause got copied directly into a library license, without the involvement of a lawyer who understands software licensing.

Perhaps @mabe can clarify?

That would great if someone from Averna could clarify that license.

I can of course replace it by some alternative approach (especially since it behaves pretty badly when moving the parent window around, flickering like a bad neon sign :-).

I am confused about the license type of the Balloon Tip addon from Averna.

The license text that shows up in VIPM does not mention any type, but somewhere says that:

"1.    GRANT OF LICENSE. Subject to the provisions of this Agreement, Averna grants Licensee a limited, personal, nonexclusive, nontransferable, non-assignable license to use the free Averna BALLOON Software (the “Software”) for your internal personal or business use (non-commercial) in accordance with the terms herein.

...

5.    RESTRICTIONS. You may not sub-license, assign, rent, lease, transfer or otherwise distribute the Software. You may not reverse engineer, port, decompile, translate, alter, modify, disassemble the Software or merge the Software into any other software or otherwise attempt to discover the source code. You may not use the Software on another hardware platform. Averna reserves the right to make changes to its products or services without notice or obligation to notify any person of such changes."

I was trying to find some wording to the effect that you can use the toolkit provided you include the license file, but the part I emphasized above seems to say you can use it for "internal" (to your business) use.

First, I don't quite see how even for an internal use you can use the software without "merging" it into your own (in the sense that the code will need to be integrated to the rest to be actually used).

And second, what is the purpose of a piece of code that you cannot share with others than those in your "business"?

I am suspecting that the license file has simply been badly written.

Any hint of what to do (save for avoiding the toolkit at all cost)?

Open the search function (Ctrl+F) and browse for the "NaN" constant. A dialog pops up telling you this palette item is not supported by the Find Dialog...

You can search for the "NaN" string and it will find all the NaN constants (plus all the occurrences of the "NaN" string).

You can search for all other constants (pi, machine epsilon, +/-Inf, etc.), but not for the NaN constant, which is just a numeric constant with NaN typed in it.

You can search for ALL numeric constants, but not for a specific one, say "1". Of course, you can search for all "1" strings in your code, and the constant 1 will show up among the search results, but it will be hidden in a long list of irrelevant results.

And try to search for a constant with units... You can't. What would be nice is to look for a constant irrespective of its unit, as for instance 60 s = 1 min. Did I encode that time constant as 60 s or 1 min? I need to search for 60 AND 1 to find out.

On 3/24/2025 at 5:35 PM, Gribo said:

Thanks, I will write a post build script to add the VIMs back to their .lvlibs. Hopefully, I won't find more of those things.

The idea is not so much to modify anything to the lvlibs, but merely to copy the original VIs instead of the version LabVIEW generates when releasing the source distribution.

It doesn't make any sense to me, but the fact of the matter is that it works.

I just used the result of the release (which files are saved where) to figure out which original ones I need and where I need to copy them (overwriting the released ones in the process).

Actually, you might need the code if you don't have the IDE installed.

I don't think the runtime alone would be able to generate compiled code from the mere diagrams...

It might have nothing to do with the topic at hand, but I was recently struggling with the oddities of Source Distribution and libraries, and found out that a bizarre trick fixed my problem:

Maybe you want to try that out.

Just for my enlightenment: why do you want to embed the code in your VIs?

I tried the solution I sketched out at the end of last post and it appears to work like a charm, however moronic it may sound to have to do that to have a usable source distribution.

The post-build VI I am using is shown below for illustration.

The strange tidbit about llb's (bottom inside-most case structure) is something that I have added since the first version of that post as it turns out that LabVIEW doesn't deal properly with llbs when creating a source distribution.

When finding a VI inside a llb (say myLBLLB.llb in the original code), it will save that VI in a subfolder called myLBLLB.llb in the distributed source. That will then result in some compilation error that will prevent the release of the distributed source. The above post-build VI nukes this folder and replaces it by the actual llb (and therefore keeps VIs in that llb that may not necessarily be needed).

On 2/8/2025 at 1:06 AM, ShaunR said:

Check project files and lvlibs with a text editor. If you have full file paths then that's a problem. File paths should be relative BUT! LabVIEW cannot always use a relative path (for example if it's on a network, different drives et.al.) Sometimes LabVIEW also gets confused but you need all paths to be relative even if it means reorganising how you structure your files.

Tested that, all paths are relative.

On 2/8/2025 at 1:06 AM, ShaunR said:

Do the above and put all dependencies in VI.lib. If you are using source control, checkout dependencies to the VI.lib directory, not your own file organisational preferences (some people like to have them on a different drive, for example). The litmus test for this is that you should be able to move your project to different locations without getting the VI searching dialogue. The search will invariably put a full path in when it finds the file-don't let it.

As I mentioned, I moved my whole LabVIEW code to a different volume (by simply copying the whole development folder, preserving the folder hierarchy in which the different dependent libraries were located), and the project loads just fine. Since I am releasing the dependencies with the same folder hierarchy, I don't think this should cause problems to someone forking the repo. Having the dependencies in vi.lib would require messing up with the user's installation, which they may not want to do.

On 2/8/2025 at 1:06 AM, ShaunR said:

Recursion breaks the project conflict resolution. If you have recursive functions, make sure they are not broken by manual inspection. The usual symptom is that there are no errors in the error dialogue but conflicts exist and VI's are broken somewhere.

I don't think I have any of those.

On 2/8/2025 at 1:06 AM, ShaunR said:

Polymorphic VI's hate recursion. If you are using polymorphic VI's recursively, don't use the polymorphic container (the thing that gives you the drop-down selector)! Only use polymorphic VI's as interfaces to other code - not itself. If you are using the polymorphic VI recursively then use the actual VI not the polymorphic container. If something gets broken you will go round in circles never getting to the broken code and multiple things will be broken.

I use a few polymorphic VIs, but none recursively.

Overall it seems like I am better off writing my own source distribution release script, copying whichever file is needed, but that's sounds fairly tedious, as I would have to build a list of dependencies, etc. Or simply release a mock distribution to get that list of needed files, and then pick the original ones an copy them to my destination path?

This is too basic be of any interest to any of the gurus out there, so I am just typing this as a record of problems to be expected when releasing a source code in LabVIEW (in the way I had intended to do it).

Recap: I have a development folder where there are a number of VIs that I do not care to release (in addition to other files). That folder is under revision control by git. I do not want to make that repo public, but I want to release the actual useful code in a clean repo.

My approach: I select a Source Distribution in my project, in which I define which VI (+ libraries and other files) I want to save and where. There are a number of dependencies in other outside folders, which I export using the "preserve disk hierarchy" option to help with finding this VIs in the release.

When running the build, I have no issue. I need to create a different lvproj file in my release (but this is a one of affair) so that it doesn't refer to VIs that have not been released. I essentially drag all the lvlib files I have exported into that project, and reorganize things within virtual folders for convenience. If I open the top level VI in that project, and run it, everything works like a charm.

However, underneath the hood, everything is screwed up. Every single VI and library shows up as "in conflict".

Opening up the Resolve conflict dialog doesn't help, as none of these conflicts appears resolvable (all "Select this version" buttons are grayed out). The crux of the problem is that there are two available paths for each VI, the new and the old one. Clearly LV knows which VI to load when running the top level VI (the new paths ones), but somehow, the project is "in conflict" anyway. lvlib files seem to refer to VIs by relative path, so they shouldn't be the issue. VIs seem to store absolute paths in their data, so I suspect this the cause of the problem.

I have tried a number of workaround to fix the issue (releasing the distribution anew each time), to no avail:

- selecting different options in the "Additional Exclusions" tab

- uncheck "Preserve disk hierarchy" in the "Destination" tab

- Move the source to the same volume as LabVIEW (so that there is no need to distinguish between files in "C:" such as Windows dlls and files in the other volume)

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.

50 minutes ago, ShaunR said:

By now, you really shouldn't have to be deleting them manually.

If it's an exploit then it should have been patched already (within 24hrs is usual). If it's just spam bots beating CAPTCHA then maybe we can help with a proper spam plugin (coding challenge?). This is a software engineering forum and if we can't stop bots posting after a week then what kind of software engineers are we?

It's also quite clear to me that this is no more than a script kiddie. You can watch the evolution of the posts where originally they had unfilled template fields that, as time went on, became filled.

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?

On 1/21/2014 at 7:50 PM, JackDunaway said:

 

I stumbled upon one resolution to this issue (air quotes, "issue") recently:

1. Restart LabVIEW
2. From the Getting Started Window, select "Tools >> Advanced >> Clear Compile Object Cache..."
3. Clear both User and App Builder cache (my hunch is that the App Builder cache is not necessary; but why not)
4. Restart LabVIEW
5. Open the guilty lvproj
6. Mass compile the project root
7. Now, "Find Items Incorrectly Claimed by a Library" -- no more spurious ownership issues

 

Anecdotally, it's not sufficient to clear the cache while the project is loaded (or, perhaps it might be sufficient with a subsequent reboot). Your mileage may vary.

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!