LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I've used NI Packages over 5 years now. Early on in my time with NIPKGs, Allen Hsu said that NI's recommendation was to have "Pool" directory where all ni packages are located. Then have a separate directory for each feed. In effect, feeds act as "views" of the pool. I've adopted this model and used it with success.

However in the Build Spec, there is no option of where to place the built package. The build package always is placed in the same directory as the feed files.

Package Output directory under "information" is where the instance of the package is temporarily exported before it is moved to the location referenced by the feed.

In the same way NI Package Feed Manager allows you to specify a location of the ni package different that than the feed I'd like to see the same option exposed in the build spec ui. The NIPM api already exists... it just need to be exposed in the UI and persisted to the Project xml.

Insider program?

dotnet Core Support

Modern embedded web browser

View All (4)

The Problem:

When storing many builds of installers, currently there is no easy way to find out the version number of the exe that the installer installs.

In the past I had tried to work around this by programmatically setting 'Installer Product Version' to the same as the exe in my build script. Installer Product version can be found in the installer's nidist.id file under [Volume Id]>DistributionVersion, and the setup.ini file under [Distribution]>Version. This works nicely until you want the build number, or major/minor exceeds 255: 'Installer Product Version' is stored in the format major.minor.fix and the max values are 255.255.65535 i.e. u8.u8.u16. This is a limitation of MSI installers. See:

Version Information Page (Installer Properties Dialog Box) - LabVIEW 2018 Help - National Instruments
ProductVersion property - Win32 apps | Microsoft Docs

Executables have Version Numbers in the format major.minor.fix.build, with max values 65535,65535,65535,65535 i.e. u16.u16.u16.u16

I would expect the installer's setup.exe's File version (under Properties>Details) to be settable as major.minor.fix.build, but this is not the case. File Version seems the most appropriate as it is 4 digits and this is used in built exe's. I would like this to be settable via property nodes (in the same way as .exe's) as it does not have the u8 limitation and does not omit the build number. Currently property nodes do not affect it. If numbers larger than the u8/u16 limits are set via property nodes, they max out in nidist.id and setup.ini. Another acceptable workaround would be to include another key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes.

Proposed Solution:

Property nodes affect the installer's Setup.exe version number under properties, with max values of u16.

Or there is a new key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes, in addition to the existing key/value pairs that have some u8 max values and omit build number.

Perhaps this will no longer be an issue if NI moves away from MSI installers...

View All (2)

The top For loop + Unbundle is the current method to get the Keys and Values of all elements in a Map as arrays. If you need both, this is ok, but I'd prefer the second option, with a native node.

If you only want one (e.g. the Keys), then the For loop and Unbundle takes quite a bit more room than a similar-type of node (here the size is taken from the Collection Size node, and the paired outputs in the second row are from Matrix Size).

Can we have nodes to access the keys in particular, and perhaps the Keys + Values of a Map without requiring the For loop?

View All (1)

Reorder Probes

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram.

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

View All (1)

It would be very helpful if there was a way of seeing the full lists of two different enum type defs at the same time and edit both lists simultaneously. Right now if you click the button to edit elements in a enum it locks out LabView so that you cannot see the list of elements in another enum. It is also really frustrating that in the edit window there is no way to increase the size so that you can see more than 6 elements or make the Item column larger to see long enum elements.

Then there is no way to add more than 6 items easily to the bottom of the list. You have to hit insert and it puts the element second from last and then you have to move down. It should be more like an array or table where you can just type and hit enter and add a lot of elements easily, resize and see as many as you want without having to scroll if you want a full window of the enum.

This is a really basic thing, but it would be helpful if the qualified name (as seen in VI Properties) was enabled so it could be copy and pasted into documentation.

When I'm writing detailed documentation to tell other developers how the software works I often use the qualified name as opposed to VI name. For example "Send Creep Command.vi" doesn't tell the developer where to find it, but "Motion Control UI.lvlib:Motion Card 2 Data.lvclass:Send Creep Command.vi" does.

I would be happy with the string being enabled (so it can be selected and copied), or a button that copies the string into clipboard.

View All (1)

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

Essentially, what I would like is a Type Specialization Structure that works backwards.

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

Simple example of Select

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

This idea was submitted by a user who requested I post this for them.

As of now, the VISA resource controls only allow you to select resource names without their full Windows description. You can select individual COM ports (COM3, COM5, etc), or pick from a list of alias names if you've defined aliases for your com ports. But, it might be nice to give the user a configurable option which will provide the additional descriptive information that you can find in Windows Device Manager. This could allow novice users to select the desired COM port based on the actual physical layer needed for the application. Again, I'm pretty sure you can work around this by reviewing the different COM ports in Measurement & Automation Explorer, or even creating your own aliases to surface the additional information. But, if I'm creating an executable, to be used on different systems by novice users, then I may not want them to have to go into MAX to be able to properly identify their desired port.

So, instead of asking the user to select a COM port from a list of items looking like this...

Maybe give an option in a property page for the VISA Resource Control that might look like this (this is a mark-up)...

so that an operator can pick from a more descriptive list like what you see in the Windows Device Manager...

Thank you,

In LabVIEW you need to know the number of sub matches at edit time and cannot handle arbitrary regular expressions. It would be nice if there was a regex function that returned sub matches in an array which can be handled much more abstractly than a pre-sized xnode.

C++, the regex utilities return a container-like class https://www.cplusplus.com/reference/regex/match_results/

PHP an array of matches is returned https://www.php.net/manual/en/function.preg-match.php

JavaScript returns an array of matches https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match

View All (4)

I want class modifications to be saved immediately. It's very rare that I need to revert any change I have made to a class.

One of the most time consuming tasks is fixing a class after I close and reopen it because I forget to [right-click > save > save]. In fact, I frequently make two source commits because I have forgotten to save the class and I don't realize until after I have made the first commit.

If not exposed through the options dialog, can we at least get a new LabVIEW.ini key?

autosaveClass=True

saveClassOnChange=True

Type Casting Strictly Typed VIs

Allow type casting between Strictly Typed VI References

Why:

The asynchronous methods require strictly typed VIs. Strictly typed VIs depend on the connector pane and terminal wiring type (Required, Recommended, Optional). Depending on your development environment and configuration options (Front Panel > Connector pane terminals default to required), newly connected terminals may be Required -or- Recommended.

Opening a VI reference or calling an async method with the wrong terminal wiring type will result in Error 1057: Type mismatch.

To work around the connector pane variance, we need to type cast check every connector pane terminal variance in order to call the proper async method without getting the Type Mismatch error.

The amount of unnecessary complexity to call and collect a thread is infuriating. There is already enough complexity when it comes to spawning a new threads; between the conditional options (Non-Reentrant, Reentrant, Async Forget, Async Collect), VI type specifier (Generic, Strict), Connector Pane Type (Pattern, Rotation), Terminal Wiring Types (Required, Recommended, Optional), etc. Threading in LabVIEW needs improvement.

Idea:

To better support Asynchronous calls, we need the ability type cast the required strictly typed VIs to:

1. Add an option to Start Asynchronous Call and Wait on Asynchronous Call methods to ignore the VI terminal wiring type flags:

Required (0x21000), Recommended (0x20800), Optional (0x20000)

2. Support type casting VIs To More Generic Type and To More Specific Type to avoid the error 1057 Type Mismatch all together

Regards,

A LabVIEW Enthusiast

View All (3)

G Web referenced VI builder wizard

good day forum

propose the above, simply for:

- automatically building the web panel by populating the control types on the original referenced VI, adding and styling it with the GWeb control style

- automatically linking the referenced vi's and gviweb's controls

- execution mode: clone per session (default, specified connection limit), & single login session; to prevent race

- if VI reference stopped running, broken, missing or irrecoverable error, return 404

to reduce recoding works

*cannot find appropriate labels in "additional idea" thread, kindly relocate post to appropriate thread, TQ

Read/Write PDF

Interfaces are a great improvement in LabVIEW OOP. For me steepest learning curve was in figuring out how to implement default behavior when interface class doesn't have a private data control.
For example I have created Collectable interface (inspired by iterable interface found in other languages). It has default implementation for methods like Next and Add. It has accessors methods like Read and Write Items, which descendants must override.
When I create a new class which inherits from my Collectable interface, I need to override those accessors, and manually add required controls to new class private data control, and unbundle/bundle elements, and wire the controls and indicators.

data accessors

My idea is that there should be a tool to do automate this code generation.

I think the straight forward way would be to use scripting and project providers to create something similar to Actor Framework Create message etc. tools.
But a more fundamental change would be to implement this as part of property definition folders and property nodes. Which I think in this case should be in protected scope by default.

property nodes

The Collectable interface can be found from lavag.org

View All (2)

LabVIEW Idea Exchange

Allow the package build spec to specify NI Package location relative to feed location

Insider program?

dotnet Core Support

Modern embedded web browser

Installer Version Number under Properties should be Major.Minor.Fix.Build

Make VI Tags an officially-supported feature

Directly access a Maps Keys and Values

Make the 'location' terminal on the New VI Object function Recommended instead of Required

Reorder Probes

Improve enum editing for large lists and two enums at a time

Actor Framework- Batch Message Accesor

Enable Qualified Name in VI Properties or add copy button

Generalize backwards propagation technology - Backwards Type Specialization Structure?!

Provide a configuration option for VISA controls to show Full Windows Name for Serial Ports

Provide regex functions with match outputs as an array

Add option to auto-save class file (.lvclass) when a change is made to a class

Type Casting Strictly Typed VIs

Allow type casting between Strictly Typed VI References

Why:

Idea:

G Web referenced VI builder wizard

Read/Write PDF

OOP Interfaces, automate data accessor code