LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Default cases should be pure!

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

View All (1)

On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible.

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)

It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down. Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI. The tool should just work. "Ctrl+." doesn't always work. You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.

Dynamic Probes for Class Data

Class data is painful, if not impossible, to properly probe when debugging LabVIEW code.

It doesn't need to be this way. Every other programming language I've worked with allows viewing this type of data when debugging.

Currently, by default, you only see probe data based on the wire's edit-time class definition, not it's actual runtime class instance. It would save me weeks (literally) a year if I could simply place a probe on a class wire and view the internal class data of the runtime class, including all levels of inheritance.

I realize it's not a small ask since the probe GUI would need to be dynamic (as data type/GUI elements, not just values, would need to be updated when probe is hit.)

Enum History Probe Improvement

View All (2)

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:

The current process of moving one of these elements:

Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
Wire to the new element, and deal with deleting the old wire
Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

Context menu with a "Move Up" and "Move Down" action (not so elegant)
A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)

Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

View All (7)

View String Constant as Icon

View All (2)

Improved Comment entry

When I add block diagram comments inside a structure, they are often long enough to require several lines. Since auto-grow is on, I need to stop typing before the comment reaches the edge of the structure, resize the comment to be multi-line, select inside the comment again, and re-start typing. From then on, the comment word wraps at my sized width. Could you make a special character like ctrl-, alt-, or Shift-comment move me to the next line and make the comment that wide, so it word wraps at that width from then on? While you're at it, could a word-wrapping comment autogrow in height to fit the comment, like a one-line comment auto-grows in width? Subdiagram comments could use that feature, too.

LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project:

Great! Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.

However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.

The request: Add the ability to either open or abort these running VIs from this window. It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:

(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)

View All (2)

When adding a file via the project tree to a .lvlib or .lvclass, it is highly likely that the file is located in the same folder as the corresponding .lvclass. For .lvlib, the file is either in the same folder or one level deeper.

When using the right-click menu Add File... on a .lvclass or .lvlib, the Select File to Open dialog should automatically navigate to the folder containing the .lvclass or .lvlib.

Currently, it navigates to the previously used folder instead.

This should immediately navigate to the folder containing Cell.lvclass.

Clear Probe Watch Window

View All (3)

align "rotate 1D array"

View All (2)

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

1 (edited).png

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

View All (2)

Add search results preview

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.

Of course I could use CTRL+G, but I'd still need to clean up the opened windows.

Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.

It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.

It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!

Some additional thoughts:

Spoiler

I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened...

Scrollbars might be nice?

The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?

I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened... Scrollbars might be nice? The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?

LabVIEW Idea Exchange

isfinite(x), isinf() and isnan() for Formula Node

Default cases should be pure!

Changing display style on string constants should make the style selector visible

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

Include foolproof shortcut to stop all running VIs and report which VIs were shut down

Dynamic Probes for Class Data

Front Panel Terminal as Icon Should Respect User's Options Preference

Enum History Probe Improvement

Rearrange Unbundle and Bundle By Name

View String Constant as Icon

Improved Comment entry

Add ability to open/abort running VIs from "Abort Running VIs" popup.

Case Insensitive Comparison Mode for String Equality Comparison

Pre-navigate Add File... dialog to folder containing .lvclass or .lvlib

Clear Probe Watch Window

align "rotate 1D array"

"Always On Top" option for Search Results window

Add search results preview

Static File Reference

Multi-Core LabVIEW Compiles/App Builds