Antoine Chalons

The lvanlys will return an error code if there is a NaN in the array, this extra feature probably explains a part of the difference in exec time.

Do you have a barn to store all this?

I'm afraid you have to use NI's installer builder to get the list of dependencies of you app. Then you can use a 3rd party product to build it. Hopefully, over time this list will not evolve too much. Per project of course.

It could be, I'm running OpenSuse in a VM, I *think* LV was installed normally but then some folder were copied because VIPM is not installed but the user.lib is full of stuff. I'll try to get a clean install but VIPM can be tricky to install on Linux.

[cross-post] I'm starting to use LabVIEW 2020 Sp1 on OpenSuse 15 and the event structure editor - I mean the dialog to add / edit handled event - seems to have localization issues. Also, a difference from Windows LV, if a constant is connected to the timeout terminal, LV requires that you handle the timeout event... weird. Is it normal / known to have these "issues"?

I've been there a few times. The treasure hunt is not really fun. 2 suggestions : - if MAX is installed, you can see from there the NI drivers - and versions - installed, that's a good starting point. Careful though, if it's installed doesn't mean it's required for the application to run. - if MAX is not installed, I would go to the uninstall utility of Windows and select National Instruments Software, this will launch the uninstall utility of NI, it displays everything installed Also, you say the customer doesn't want to share the source, but if they have it, maybe you can tell them how to get the information you need.

I couldn't help noticing this, when the presenter said "what we're working on for LabVIEW 2022 and - beyond." But hey... Let's be positive and hopeful. I'm looking forward to playing with G Web Dev Software.

This is not a montage. This VI was running and giving expected results. I suspect the malleable VI (Get config section from TOML file) to be somehow responsible for this visual artifact. After hitting ctrl + B, the broken parts of the wires were removed, I reconnected and that's it. Is this a known issue ? LV2020 v20.0.1

Wow, ok, thanks for the warning! Not sure my feather weight will be enough to change anything but I'll be sure to ask NI to fix this bug via my own channels.

I think I found the solution from this post on NI forum

Can we set the data type of a CLFN parameter via scripting?

I see. Indeed it's a different approach. Traverse for GO ignores the BD selection. My version could be modified to deal with nested case structures.

here it is in 2018 Set Tunnels Default Values_modified.vi

Here's a versions with a few modifications : - fixed the undo - do nothing if launched from panel - if selection is a case structure, take all tunnels and enable "use default..." if not already enabled - if zero tunnel were effectively modified, fail the undo - if at least one tunnel was effectively modified, force recompile the VI to make sure LabVIEW will re-assess the broken arrow Set Tunnels Default Values_modified.vi

I have an issue when using this QDP : - before using it, my VI has a broken arrow because a tunnel has some missing assignments - after using it, the VI still has a broken arrow although my tunnel is set to use default if unwired - if I click on the broken arrow, it turns into a non-broken arrow What's the best way to force LabVIEW to re-assess the broken / non-broken state? EDIT : also, as you close the I referenc too early (in the false case), the undo doesn't work.