LabVIEW Idea Exchange

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

The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.

 

Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.

Screenshot (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
  • It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
  • The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.

Idea/bug-report:

If you have a multicolumn listbox with column headers and you want to delete one of the columns you can right-click on the column and select delete column, but if there are no items in that column LabVIEW will not actually do anything(!):

 

This also applies to empty rows with headers. This is non-intuitive and makes it cumbersome to remove a header and keep the width/height of the ones you want to keep...

Seems to me 75% of the time when I create a local variable, I need to read it, not write to it.  Seems like that would be a time saver...

Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!

 

When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click

 

Step 1: Start creating a cluster wire

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Notes

  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
  • The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
  • Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.

Using 2023 for the first time (skipped 2021 and 2022)

 

QuickDrop used to be quick.

It was very convenient.

 

Now it takes a second to load.

 

That's pretty inconvenient if you're trying to... do much of anything.

 

Best example: If you're trying to remove code (Quickdrop's Control-R), now instead of quickly removing the selected code, you get to deal with accidentally RUNNING your VI (Menu's Control-R)

 

Please make it Quick again

It would be useful to add a Boolean for resetting "First call?". Sometimes it might be required to reset a first call during a run.   
It could be as following:

KhalilEslami_0-1684738034968.png

 

LabVIEW crashes randomly when network functions are used on Linux. This problem appears especially when many connections or files are open.

R&D has identified the issue but is evaluating wheter or not the issue will be resolved in future releases.

 

All the details are here : 

https://forums.ni.com/t5/LabVIEW/TCP-Allow-files-descriptors-gt-1024/m-p/4297433#M1255356

 

An example is attached.

 

 

 

 

Download All

I spent a good chunk of time yesterday trying to find out why I was getting a Wires Under Objects VI Analyzer failure, and after much paring down of code and fiddling with wires it turned out to be a hidden event data node that was running over a wire.  Below is a simple reproducing example; the second image is identical to the first, except that the event node has been hidden (but not moved).  Both of the images below fail the Wires Under Objects test, and my argument is that the one on the right should not fail that test.

 

Event node visibleEvent node visibleEvent node hiddenEvent node hidden

The point of the feature "hide the event data node" is so that I, as a LabVIEW developer, no longer have to worry about it cluttering my block diagram and it running into/over other items.  However, hiding it ultimately results in me still worrying about where it is hidden because it running into/over other items still turns out to matter when I run static code analysis. From this POV, this is a bug, and the VI analyzer test shouldn't fail.

 

This POV is also consistent with the way that hiding for/while loop iteration terminals operates.  In the images below (again, the second image is identical to the first, where the iteration terminal has been hidden but not moved), ONLY the left image fails the same VI Analyzer test, and this is the behavior I'd like to see with the hidden event node:

 

While with node.pngWhile no node.png

Hello old friends,  it has been a while!

 

I would like to see MQTT client functionality added to LabVIEW.

The LabVIEW Help for the OPC UA Connect VI has this statement in the description of the "OPC UA data change event" output: "NI does not recommend using this output."

The example VI "Data Access Client.vi" inside "OPC UA Demo.lvlib" uses this output. Could it be possible to add a possible explanation as to why in the Example the "OPC UA data change event" output is used? Or could the Help for the OPC UA Connect VI be modified? 

 

Example: 

EstebanF_0-1648574716377.png

Help documentation:

EstebanF_1-1648574758645.pngEstebanF_2-1648574778786.png

 

The front panel below contains a modern-style string control and a classic-style string control.

 

3 (edited).png

 

We may want to replace the modern-style control with a classic-style control (for example if the team style guidelines recommend classic-style controls for non-user-facing front panels, or just for consistency).

 

The problem is that after right-clicking the modern-style control and selecting Replace >> Classic >> String Control, the control is replaced with something that looks different from an original, genuine classic string control. This is shown below. The new control looks like a hybrid between classic and modern. The same behaviour occurs when using QuickDrop to replace the control (Ctrl+Space, Ctrl+P).

 

4 (edited).png

 

My suggestion is: Controls and indicators should be replaced by genuine-looking items, not by hybrids that preserve some attributes of the old style, and some of the new.

 

Thanks

NI has a private method for returning the hWnd of a VI but there is no "publicly" available method for this. The private method is already shared around forums and used extensively as interacting with the Win32 APIs is a common need for advanced UIs. The appearance configs for VIs only work relative to other VIs and trying to develop LabVIEW based applications that are used alongside other applications presents many roadblocks, even with other NI software such as TestStand. (TestStand has an API method for getting the hWnd!)

 

The other method commonly used is to also use the Win32 FindWindow call however this presents issues if there are multiple windows with the same captions (easy enough with Cloned VIs) and is not a robust approach.

Some more details on the Context Help and Detailed Help. Could there be a possibility to add some more information regarding the Invoke Method: Clean up Diagram. The information right now is kinda confusing. 

 

EstebanF_0-1644007831872.pngEstebanF_1-1644007886978.png

Hope this could help us to improve our platforms. 

Usually, unsupported LabVIEW features can be enabled with nothing more than an undocumented INI key. The one exception that I know of is the integrated XNode development feature in the Windows version, which is instead controlled by the license manager. (This feature exists in the Linux and Mac versions as well, but on those versions it's an INI key like everything else.)

 

Despite not being officially supported, community-made XNodes are very much a thing. Even on the Windows version, one can still create them using a third-party editor, or hack their way into the built-in one somehow. And it's clear that NI (rightfully) doesn't put much if any continued effort into preventing third parties from making XNodes, as the same methods that were used over a decade ago still work just as well now.

 

I'm not asking NI to provide official support for XNodes necessarily, but I think it's for the best if they at least remove all unnecessary, artificial roadblocks, and open up the XNode development forum and perhaps some internal documentation to the public, so community-based developers can at least have the best shot at learning how to do it right. You've already done this with Project Providers; why not XNodes as well?

I really like this idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Regular-Expression-search-in-Maps/idi-p/3934993

But as so often there are only a few Kudos - probably because it's a very special feature not needed by many programmers.

 

I'd like to suggest also to add a function (or option) for a case insensitive search for string keys as first and easy to use implementation. As second I also hope for the regular expression search.

 

It would be really helpful if we could specify a unique "friend" or group of "friends" for each method in a class, rather than a setting that applies to all members of that class.

For example, I have 4 clone threads running in my LabVIEW application. I am probing a particular data wire in all 4 clones. If I double click a probe watch is not taking me to the right clone instance. Please do needful to correct this.

Trying to toggle back and forth between the instructions and the code for the online CLD exam was both distracting and difficult since most hot keys didn't work. Placing the instructions or goals in the block diagram would allow easier reference for those taking the exam. 

We use Queued Message Stage Machines a lot and often send messages through API calls. In a state machine I prefer using enums to determine the state and in the QMSM that would be useful too because sometimes a typo in a message in an API call stops it from working. 

 

However, the Message Queue functions accept string only. 

 

 

image.png

 

Even if we make changes to the message cluster or make the VI polymorphic but we would then need to do it every time we are setting up a new machine with LabVIEW. Would this be useful for anybody else? 

image.png

 

 

 

 

I work with large projects.  And I often need to move items around in my projects.  However...  while you're dragging an item in the Project Explorer, if the cursor is at the top or bottom of the visible area, the window does not scroll.  This means that the item you're moving, and its destination, must both be visible at the same time in order to drag and drop it.

 

I regularly have to un-expand items in order to be able to simply move a file.  This is time consuming and forces me to un-expand tree items that I would prefer to keep expanded.