LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Add structure on bare wires

View All (3)

Current state:

Suppose you have some neat code that bundles/unbundles elements from either a typedef-ed cluster or a class. You even provided free space in case some names are changed in the future:

But then, when you change an element's name to a longer one, this happens:

Now, to have the same neat code as before, you have to surgically select, move and realign the Bundle/Unbundle nodes correctly:

Since these nodes are resized in a centered manner, to keep neat code without the need to realign everything by hand, you must provide free space both on the left AND on the right.

Remark 1: The same issue can happen when you select another item with a different width in the Bundle/Unbundle node.

Remark 2: It seems all nodes of class "Named Bundler" and "Named Unbundler" are concerned. So that also includes the Waveform / Digital Waveform / Digital Data Bundlers/Unbundlers.

Proposed Idea:

When a Named Bundler or a Named Unbundler updates its own size (either because the typedef is changed or because the user selects another item), it resizes to the right instead of resizing from the center. So, if you want to provide space for further modifications, you only need to put space on the right (and not both on the left and the right). Also, I find that resizing to the right is quite consistent with the left alignment of the element names.

Regards,

Raphaël.

View All (3)

Native AMC Messaging

QMH producer/consumer patterns heavily rely on Queues, and NI' s AMC library is the top-tier tool for acting upon Queues.
Having used it for 8 years already, i can say its most amazing features are:
-The capability to pass huge amounts of indexed data: Message Name, Message, Attributes
-The great ease of substituting the Send Message to Send Network Message, for when the application needs to be working remotely, as AMC relies on UDP when in network mode.
It would be extremely nice if it shipped with LabView, also considering that the installation through Vipm can be tricky on older, non-Windows systems; even better, if Labview integrated an even sleeker implementation of it.

Note: STM Messaging library, which relies on TCP, would also be a great idea in my opinion.

View All (7)

Very often, I create concrete classes that only inherit from LV Object and interface(s). By default these have the same wire appearance as LV Object, which provides very little information when looking at block diagrams. Ask is to add a selection dropdown to choose which ancestor to inherit wire appearance from so I can easily make all descendants of an interface have the same wire appearance.

Bonus would be to default to the parent interface while creating the interface if you select exactly 1 interface and LV Object as parent during the class creation dialog.

The Class Browser (Ctrl-Shift-B) is a little-known LabVIEW feature that makes it much easier to work with property-based class hierarchies in LabVIEW (VI Server, DAQmx, VISA, Sys Config, your own .lvclasses, etc.). The Class Browser search function is particularly helpful when you aren't exactly sure what property or method you need, or if it even exists. Unfortunately, the search results are often very difficult to navigate, as in this example:

I was looking for a property or method relating to locking controls on the front panel, so I searched for "lock". Over 1000 results were returned. But the results include a tremendous number of duplicates. If there is a property of a parent class (like the Is On Block Diagram? property of the Generic class in the screenshot above), then that property will be duplicated for all child classes of that parent class... in this case, there are hundreds of children of the Generic class! It took me a few minutes just to scroll through all these duplicate results to finally find what I was looking for (the "Lock Objects" method of the Pane class).

Idea: Only show the parent class property/method in the search results of the Class Browser window. Do not show child class entries for that same property/method.

In the example above, if duplicates had been removed, then my "lock" search would have returned 49 results, which is a much more reasonably sized list of results to dig through.

Package build specs include a way to specify runtime package dependencies, and LabVIEW 2023 Q1 includes a utility to assist you in identifying and installing NI drivers used by a LabVIEW project. JKI dragon now exists to specify/install VIPM dependencies for projects.

The missing piece is non-NI NIPM packages. For instance, my company distributes a bunch of NIPM packages containing PPLs that are required by multiple projects. It'd be nice if these packages could be added to the "Manage Dependencies" dialog.

My idea is to add a way to specify at the project level what non-NI NIPM packages are needed to edit/build the project, which can then behave similarly to JKI dragon or the "NI drivers utility," so we can declare more of the dependencies for developing the project.

Auto generate library palette

When building an application or installer, the process freezes at the end, and LabVIEW becomes unresponsive.

This occurs when “Apply digital signature” is checked and the certificate uses a private key stored externally (rather than being included in a .pfx file). CA/Browser Forum’s Code Signing Baseline Requirements introduced stricter private key protections effective June 1, 2023.

The executable can be signed with a post-build action by running an external tool via the command line.
However, the installer does not support post-build actions and must be signed externally.

It would be preferable for the build process of both executables and installers to support code signing certificates with private keys stored externally (in the cloud), so the signing process can be integrated into the build, as how it worked with .pfx files.

View All (1)

Microsoft had a sale on Black Friday, so I got my first ARM laptop Surface Laptop. The laptop run beautifully on ARM. This made me trying to make a case to ask NI to have a native ARM build

The background ground:

1. Python is eating a lot of hobbyist market from LabVIEW

2. The rise of AI vibe coding definitely does not help LabVIEW in anyway.

3. On NI's roadmap, code generation from Nigel is still a year away.

4. Hobbyist buying a lot Raspberry Pi for home projects.

5. University use Raspberry Pi to educate their students.

6. Existing ARM capable LabVIEW is headless, has no GUI. Student won't have the time or lac of the capability to write a GUI utilizing Web Services. (Although I would say that would be real nice.)

7. Hobbyist are cost sensitive. Having a Windows capable X86 machine is expensive, compared to Raspberry Pi or BeagleBone solutions. Thus, this prevents many hobbyist projects from happening on LabVIEW.

8. If students or hobbyists don't use LabVIEW at home, they likely would stay away from LabVIEW at work. In a few to ten years, LabVIEW will lose even more market share.

9. Not being able to run LabVIEW on majority of ARM devices will force many engineers to pick text-based language to begin their project. They have no incentive to redo it in LabVIEW on x86 Windows machine. No one want to develop things twice.

So, now the benefit and other thinking:

1. Allowing ARM64 native build will open opportunity to hobbyist and student.

2. ARM64 would allow LabVIEW to run on Raspberry Pi on Windows on ARM.

3. ARM native build can start with minimum LabVIEW, device drivers won't be necessary. Is it not like the Hobbyist will pay over-priced NI DAQ devices anyway.

4. Allow arm64 dll to be called via LabVIEW. (One benefit is that Digilent's devices, a NI subsidiary, can be used on LabVIEW.

5. ARM64 laptop will sleeps better, they less likely to BSOD upon wake up. (Thank NI for making our whole departments' laptop BSOD every morning by their faulty PCIe driver. It would be a benefit to all people, if the native ARM build does NOT support any PXI at all.

6. NI should make Raspberry Pi/BeagleBone officially support for hobbyist market. This market does not make any money for NI likely, but losing this market will lead to eventual demise of LabVIEW in long term, given the current rise of Raspberry Pi/Beagle Bone, etc. So many companies are building their industrial equipment on Raspberry Pi and such.

7. Maybe also fix the LabVIEW on 64-bit Raspberry Pi OS. Just need to update arm64 to armhf in the package description.

View All (1)

In previous versions of LabVIEW (including 25Q1), if you right-clicked on a wire, you could navigate directly to the Breakpoint Manager. With the merging of probes and breakpoints in 25Q3, the "Breakpoint Manager" has been replaced with the "Debug Window". However -- there's no longer a right-click shortcut on wires to navigate to it. I'd like to see this brought back, as it's a more intuitive location to find it than the View menu. Finding it for the first time after the switch wasn't obvious either, because of the name change.

(And yes, I'm aware that there's now a keyboard shortcut to directly access the Debug Window (ctrl+d) which I'll be using in the future, but I wouldn't expect most users to have this memorized.)

No autogrow while typing

View All (1)

View All (5)

View All (2)

I often use the "Find All Instances" option from the right-click menu when clicking on a VI's icon to find all callers of that VI. However, it regularly comes up with fewer hits than the "Find Callers" option. In this case, it came up with 0 hits:

However, if I navigate to the VI in my project (ctrl+shift+e) and then right-click on it and select "Find -> Callers" it will actually find the callers:

I've never understood this discrepancy, and I see it regularly. Perhaps this is more a bug than a feature request -- but I do feel that if these callers are consistently findable from through one of these mechanisms, they should be consistently findable through both.

Note: in the case above, if I do open the VI (after finding in using "Find Callers"), it will then be found if I "Find All Instances...". But if I close the VI, it's no longer found using "Find All Instances".

When you're looking at the front panel of non-editable VIs, such as VIs in PPLs, many options aren't available. Some of these are still applicable, and would be really useful.

Example 1: If I want to go look at a class definition, normally I could right-click on the class in a front panel and then choose "Show Class Library". However, it isn't available if the VI is locked. My (less-than-ideal) workaround is to "Copy Data", drop the class on a new block diagram, and then I have access to all the normal menu options.

Example 2: The connector pane isn't visible. I often want to look at what is wired where on the connector pane, or to check if inputs are dynamic, but this info isn't visible.

I work with PPLs quite a bit...and sometimes...I just want to rename them.

Libraries that depend on the renamed PPL will then be broken, as expected. Example here:

It would be awesome if I could simply go in, right-click on the missing dependency, and replace it with the newly named one. But...for whatever reason...this option is disabled. Instead, I find myself having to go in and manually replace each individual broken PPL call (VIs, typedefs, etc.). This is unnecessarily time consuming and error prone.

Currently VI's show up in whatever taskbar's monitor they first showed up in and don't follow if they are moved to a different monitor.

This makes my workflow very difficult as I can end up with 18 VI icons (1 each block diagram and front panel) on Monitor 2 and 0 VI icons on Monitor 1. This despite the fact that might have moved have of the VI representations to Monitor 1. The only way to distribute them among the taskbars is to restart windows explorer. This is annoying to have to do even though I have a script to do it (thanks to the hero that posted that process!).

Relatedly, I don't always want all VIs to pop up when I want one to show up. I should be able to bring a block diagram up without having every other VI front panel and block diagram also pop up. Then I have to go and minimize each window individually so I can look at a document or spreadsheet at the same time.

View All (2)

LabVIEW Idea Exchange

Add structure on bare wires

Remove redundant path information in Project Explorer

Named Bundler/Unbundler nodes should resize to the right

Native AMC Messaging

Allow interface wire appearance to be inherited

Global LV setting to ignore separate compiled setting of projects, classes, etc.

Support Python node on Linux compactRIO targets

Class Browser should not duplicate search results for child properties of a parent class

Specify and and auto-install edit-time NIPM dependencies

Auto generate library palette

Support code signing certificates with cloud keys when building applications and installers

Make a case for LabVIEW native ARM64 build on Windows on ARM

Add Debug Window (AKA revamped Breakpoint Manager) back to right-click menus on wires

No autogrow while typing

Add unbundle to wiring menu for clusters

Toggle selection of entire array with the spacebar

"Find All Instances" of a VI should be just as capable as "Find -> Callers"

Show more data when looking at non-editable VIs

Allow "Replace" of Broken PPL Dependencies

Make VIs show up in correct monitor's taskbar and be independent of others