LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I'm not sure if someone has requested it yet, but it would be very helpful if I could clear the probe watch window of the last retained values. This way I don't need to look at the timestamps and it will speed up the debugging.

If you e.g. open a project in a newer LV and then close it; it starts recompiling everything with no abort option, and only after having recompiled 2000 VI's i can choose to _not_ save them ...

I just opened it to check a few things and ended up with Kill Process to get out of it.

 

Let us cancel/abort the recompile when shutting down.

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.

 

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This idea is inspired by this idea and this idea.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

 

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

 

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

Similar to a Static VI Reference, you could have a static file reference which would function just like a path but would allow non-VI files such as a script to be called by a sysexec call or a python node, etc. to be implicitly included in a build without having to remember to add them as "always included".

I want an event to trigger when the user switches from linear to logarithmic mapping for a control. 

Screenshot 2025-04-01 124800.png

None of these currently existing events trigger for this scale change

Screenshot 2025-04-01 125545.png

Related forum discussions:

https://forums.ni.com/t5/LabVIEW/Can-I-detect-a-plot-name-change-event-in-a-plot-legend/td-p/2741164

https://forums.ni.com/t5/LabVIEW/XY-Plot-Scale-Legend-Mapping-Mode-Changed-Event/m-p/4226689

 

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

 

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

 

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

 

When is LabVIEW going to get with the times?

Idea Part 1: The menu that appears when right-clicking an input of the Replace Array Subset node should contain Add Input and Remove Input options.

Idea Part 2: The QuickDrop Remove and Rewire tool (Ctrl + Space, Ctrl + Shift + R) should remove unwired inputs of the Replace Array Subset node.

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This would be similar to the menus of several other well-loved nodes, such as the Build Array node.

 

Real-world example

The other day I wrote the following code:

1.png

 

 

 

 

 

 

 

 

 

 

 

Initially all the inputs of the Replace Array Subset node were wired. Then I realised I had made a mistake, and needed to remove the third-last pair of wires. I deleted the wires. So far so good.

 

I then selected the node and pressed Ctrl + Space, Ctrl + Shift + R to execute the QuickDrop Remove and Rewire tool, in the hope that it would eliminate the unwired input. It didn't. I then right-clicked the input, hoping to manually select Remove Input. That option didn't exist.

 

The only option I had was to manually disconnect the last four wires and reconnect them one input above, followed by removing the last input by dragging the bottom edge upwards.

 

Having to manually disconnect and reconnect wires was a little disconcerting. I wondered: what would have happened if I had made a mistake with say the second input, instead of the third-last input? A lot more manual wiring would have had to be redone.

 

Notes

The Wire Multiple Objects Together QuickDrop tool (Ctrl + W) is extremely useful. However, at the moment it has the following limitation.

 

The other day I found myself writing code like the following.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Naturally I tried using the QuickDrop Ctrl + W tool. However, it produced the result seen below, which is not what I wanted.

2 (edited).png

 

The Ctrl + W tool wires each source wire to a compatible (coerceable) destination. In the example above it wires to I32 and DBL destinations indiscriminately.

 

The desired outcome would be achieved if the tool preferred wiring to destinations that match the source data type exactly, before considering other compatible (coercible) destinations. In the example above, the tool should prefer the DBL destinations. It should wire to the DBL destinations first, before considering I32 destinations.

Notes

  • The example above shows 10 wires being wired between the Index Array node and the Replace Array Subset node. The real-world VIs I was programming the other day required wiring multiple pairs of Index Array and Replace Array Subset nodes, some with as many as 30 wires between them. Wiring them manually was a tedious and time-consuming operation.
  • This idea is somewhat related to the following idea: Improvement to the QuickDrop Ctrl+W tool: Wire constant to multiple destinations

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

 

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

 

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

It would be nice to have a managed solution to get LV Class properties both in development and in runtime environment: name of the properties, concerning accessor VIs with path and scope information.

Currently the only way to get these information is to handle the classes by XML parsing methods. This is neither managed solution nor working for classes which are found in compiled codes.

This is an idea I've been working on for a while. It's time to let others start evaluating it. 🙂

000.png

001.png

 ^ I included the above for Dmitry Sagatelyan and similar folks who have asked me for these things over the years so they know the mindset to use when evaluating the idea. But it's written up below for LabVIEW users who only know LabVIEW as it stands today (Q3 2024).

002.png

003.png

004.png

005.png

006.png

007.png

 

Feedback and questions welcome. 

The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.

 

ast.jpg

It is necessary for porting code that uses nextafter() in C or Python(or other languages) to LabVIEW.

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

 

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

 

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

 

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

 

Pro-grade mockup shown below:

BertMcMahan_0-1753792749382.png

 

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

 

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

  • The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

 

1.png

2.png

3.png

 

Notes:

  • This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
  • A significant number of native VIs are already configured to use Preallocated clone, which is great.
  • There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
    • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
  • The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.

I understand that empty interface boxes should reflect their purpose, but this design decision wastes too much block diagram space. When using interfaces, explicit type casting is often necessary by definition. Unfortunately, this quickly clutters the block diagram.

Quiztus2_0-1747037507652.png

 

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.

CaseyM_0-1695271655726.png

 

90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:

  1. Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
  2. Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
  3. You could more easily get to the BD of VIs running in a subpanel.
  4. It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.

Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).

 

This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.