LogMAN

I use InnoSetup and offline installers. The steps are documented here: https://www.ni.com/docs/en-US/bundle/package-manager/page/automate-installer.html

"LabVIEW Programmer"

Here is the kind of response it produces for LabVIEW: The responses are impressive but it doesn't look like we are getting replaced any time soon...

The reason your cant change the unit label at runtime is because unit labels change the data type of the wire (notice the "S" in brackets at the end). That said, what you want can be achieved with the display format. Enable unit label and specify the unit "S" Change the display format to SI notation and the number of digits to 3 Now it will automatically add the prefix according to your value. For example, 10000 S will turn into 10 kS.

While community-scoped VIs are only accessible from VIs in the same library and friends, they are still exported. To see the complete list of exported members, use Get Exported File List.vi or open the library from the Getting Started Window. Attempting to execute community-scoped VIs results in a runtime error. Here is an example using Open VI Reference. The same error should appear in TestStand (otherwise it's a bug). LabVIEW simply hides community-scoped members in Project Explorer for convenience. Looks like TestStand does not do that.

LabVIEW clusters can actually be passed by value, given that the values are structs. For classes, you need to construct the class before you pass it to the method.

It sounds as if you want to pass a .NET Array type by ref to your method. This should be possible by constructing an array in LabVIEW, for example, by using the To .NET Object function, and passing the instance by reference to your method (assuming that your method signature is by ref). If you want to avoid generics, you can also initialize your own array as illustrated below.

Yes, this makes sense for class members. They should always access the private data cluster directly. Property nodes are only good for callers (and maybe when accessing parent class data). In the past I also avoided property nodes. Mostly because of stability and performance issues (~2011-2015). Nowadays they appear to be stable and are just easier to read (also, I'm lazy and property nodes don't need icons 😏). This is probably the best way to do it. Read-only and write-only access, however, should still be done with standalone bundle/unbundle. It makes it easier to understand what is going on, avoids unnecessary wires, and has the same memory footprint. By the way, Darren Nattinger recently held a presentation at GDevConNA 2022 that might be interesting to you. He provides some insights into features of LabVIEW that aren't as stable as one would hope...

Cross-post: Remove Block Diagram after Build with VIPM - VI Package Manager (VIPM) - VIPM Community Please always include links when posting in multiple forums.

Class constants and controls have black background when they contain non-default values: Class constants (and controls) always have the default value of their private data control unless you explicitly create a non-standard constant like in the example above. It is updated every time the private data control is changed. This is why VIs containing the class are broken until the changes to the private data control are applied. That is correct. It does not. The default control does not actually contain a copy of the private data control, but a value to indicate that it returns the class default value. Even if you make this value its default value, it is still just a value that indicates that it returns the class default value. Only when the background turns black, you have to worry. By any chance, do you write values to class controls? This can result in undesired situations when combined with 'Make Current Values Default':

That is very unlikely. It would turn classes into interfaces, which is a major breaking change.

Not sure about speed, but these VIs use features that aren't available in earlier versions. However, if backwards compatibility isn't an issue, this is probably the most native way to go about it. As for speed, perhaps caching is an option?

Just in case you are looking for a solution that doesn't have to work in runtime, there is this property for class libraries.

How fast do you need it to be? Speaking about native solution, there is <vi.lib>\Utility\LVClass\Is Class Not Interface.vi <vi.lib>\Utility\LVClass\Is Class Not Interface Without Loading.vi However, these might not work at runtime.

Interfaces have no private data control, which means you can just check if such control exists in memory. The original VI is available on GitHub: https://github.com/logmanoriginal/labview-composition ("Is Interface Or LabVIEW Object.vi")

Re-creating the property node should fix the immediate issue, but it may happen again in the future. Does your typedef contain sub-types? Changes to nested typedefs can have the same affect.

This can happen when a typedef changes from strict to non-strict or vice versa. In this case, the value returned by the property node will remain strict or non-strict, resulting in a coercion dot. Typedef Coercion.mp4

Further reading: LabVIEW Interfaces: The Decisions Behind the Design - NI Community

Just checked, my VIs are unprotected in all installed versions (English, 32-bit). They probably auto-protect them during translation.

I got several versions installed on my computer at home, including 2017, 2019, and 2021-2022Q3 and those VIs (at least 2017 and 2019) are unlocked. By any chance, are there differences in the language version installed?

They are unprotected in 2019. Was this changed in later versions?

It's three at the deepest level, not counting LabVIEW Object. The class browser arranges some classes wrong, which makes it look like there are extra levels.

That makes sense. Thanks for clearing that up! A very similar issue happened to me a couple of month ago on multiple stations with broken power supplies. On those stations, the PC would sporadically turn off, sometimes (approx. 1-2 times a month) causing several of our configuration files to contain empty or garbage data (random bytes) after reboot. Those files are only written to at the start of a cycle that takes several minutes to complete. The likelihood of a power failure in that exact moment is very slim at best. On top of that, we currently update configurations sequentially, which means that only one file is open at any given time. However, often multiple files were affected. We never got to the bottom of it, as replacing the power supplies fixed the issue entirely. I'd be happy to know what is causing this issue...

Something like that. The actual implementation takes several factors into account, for example, how frequently a file is accessed. Also, your disk has its own cache on top of that. If you have a virus scanner running, it might lock the file for processing. I believe the Set File Size function is to blame for that. By changing the file size to zero, the file is effectively cleared. The write function after that is cached and never gets flushed to disk because of power failure, which leaves the file empty after reboot. I'm not sure why it was implemented this way. The following will produce the same result without this issue: