LabVIEW Idea Exchange

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

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.

 

Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!

 

21658iE20B431D386A4E45

 

                                            "Build Path" should be Growable

 

                              something like this,

 

 

toto.png

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

 

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

1 (annotated).png

 

 

 

 

 

 

 

 

Thanks!

The LabVIEW Robotics Module consists of a variety of sensor and actuator drivers, motion algorithms (such as kinematics), world map creation and search algorithms, a world simulator, etc.

 

It hasn't been updated since 2019 and is 32-bit only.

 

I would like to see it made open source.

I believe some or all of the sensor drivers are already available on ni.com/idnet.

There are several other VI-based components and examples that are standalone and could be easily released independently.

I realize that the simulator might have some 3rd party constraints for releasing as open source, but I'd love to see it released if possible.

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

 

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

 

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

 

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

 

Idea -->LabVIEW should also standardize here!

 

 

 

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

 

BD-Only VIs would be beneficial because:

  • They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
  • They would reduce the developer workload, thus making developers faster.
  • They would reduce the surface-area of the codebase.
  • They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

 

Notes

  • I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
  • The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
  • Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
  • I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
  • It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

Check out this nice readable diagram:

labels.png

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

 

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

Problem: Viewing and/or hiding labels on the block diagram is an important part of programming in LabVIEW. In general I display the labels of subVIs, native functions (e.g. TCP Read or Obtain Queue), constants, and structures such as Case Structures, For Loops, While Loops. But sometimes, for a variety of reasons, I choose to hide labels.

 

Currently toggling the visibility of labels can be done either by right-clicking and navigating to Visible Items >> Label or by using the AddLabels QuickDrop shortcut (Ctrl+Space + Ctrl+Q to make labels visible, Ctrl+Space + Ctrl+Shift+Q to make them invisible).

 

Both options are slow for such a common, repetitive, and necessary action. While I admire the intention of the QuickDrop shortcut, and do use it from time to time, it unfortunately cannot achieve the virtually-instant response that should be associated with this action.

 

Solution: Label visibility should be toggled by pressing a single key, for example key "L" for label. For example, if the TCP Read primitive was dropped with its label being hidden, then selecting the primitive and hitting "L" would make its label visible. No need to navigate with the mouse. No need to load QuickDrop (which can take more than one or two seconds, especially when working in large projects).

 

Notes

  • While key "L" is proposed above, I would be happy with any other key being chosen as the trigger of this action.
  • I would be happy with a key combination, such as "Ctrl + L" or similar being chosen.
  • The action should work for groups of selected objects, just like the two current ways of toggling label visibility work on groups.
  • The idea above refers strictly to objects on the Block Diagram, as that is where I need this feature most. It would be a bonus if the new functionality would apply to objects on the Front Panel too.
  • This idea sits in the "improve developer productivity" category. I want my IDE to enable me to be as productive as possible. Every second matters. In fact, even tenths of a second matter.

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂

 

abort_all_running_vi.png

 

 

When pressing the "Stop" button when your project is loading you get this screen

 

BasvE_0-1704359642069.png

 

It seems that pressing "No" is the fastest way to abort loading but for bigger projects it still tries to load some classes/libraries/vi's which could take a lot of time.

 

I would love to see a way to abort loading the project instantly.

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Combined v2.png

 

 

 

 

 

 

 

Details

  • The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
  • The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
  • “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

  • .NET: System.DateTime.Now
  • C++: std::chrono::system_clock::now()
  • Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

 

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

 

Nevertheless, I would be happy with the following names too:

  • “Get Timestamp Now”
  • “Get Current Date/Time”
  • “Get Current Timestamp”

Notes

  • Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

I have a habit of putting an enum with a digital display visible in each of my case structure frames controlled via enum.

 

It has become second nature already. Today I stopped and wondered why we can't simply include a digital representation as an "[X]" appended in the visible selector.

 

So here I am asking for it.

 

Intaris_0-1728572984028.png

 

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.

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

 

Currently, new sublasses require the user to find the correct parent class in the class tree. In larger projects, this can be really painfull.

I suggest two simple things to improve this very common task:

 

1. Make the class tree searchable: Put a filter string input above where you can filter the tree by name

2. Add a "Create New Sub-Class from this Class" Item to the context menu in project explorer. This could simpy open the class tree with the matching class already selected. Something like this would also be great for interfaces.

When drawing a selection rectangle that covers part of a cluster, structure, or wire, you can toggle selection of the entire thing by hitting the spacebar. (https://www.ni.com/docs/en-US/bundle/labview/page/selecting-objects.html)

 

I propose the same functionality with arrays. It's odd to me that this handy feature works with clusters and not arrays.

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:

 

_carl_1-1761599933386.png

 

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:

_carl_2-1761600292434.png

 

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".

 

 

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.

 

I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

(NOTE: This idea is the opposite of this one, so not the same)

 

The properties page of "boolean array to number" should prominently include the sign extension mode so we don't run into this confusion.

 

altenbach_1-1750952300236.png

 

 

altenbach_0-1750952204508.png