LabVIEW Idea Exchange

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

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:

 

20985iEE7ABCE2AA5DD1B3

 

The current process of moving one of these elements:

  1. 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!
  2. Wire to the new element, and deal with deleting the old wire
  3. 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:

  1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
  2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
  3. 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)

20991iC0D9F95AD3E82BBE 

 

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.

Since 1986, when LabVIEW first launched, there has been one constant.  Icons are 32x32 elements. 

 

That made sense on 17inch CRT monitors.  There have been improvements in displays since then but, no corresponding improvement to the Icon resolution. 

 

Isn't it time to change that?

In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.

 

The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.

 

The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).

 

Screenshot 1

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screenshot 2

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

Let's Encrypt is an Certificate Authority (CA) that provides FREE TLS certificates for people and organisations to secure their websites and servers. Their certificates are valid for a maximum of 3 months, but client applications can automatically update the certificate when due.

It would be very nice to have this functionality in the NI web server. Exipiring certificates are cumbersome to manage.

I would be surprised if this is not a duplicate but I was unsuccessful finding it.

 

The subject says it all. Simply add a scrollbar to free text labels. I sometimes use a string constant for free labels simply because they can have a scrollbar.

 

scrollbar.png

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page 

VinnyAstro_0-1705567415946.png

 

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

 

This happens to me all the time:

VinnyAstro_1-1705568287315.png

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

VinnyAstro_2-1705569130610.pngVinnyAstro_4-1705569195313.png

 

 

 - Vincent.

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

 

 Case Insensitive Equal.png

 

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

 

 
Case Insensitive Equality Comparison.png

Block diagram string constants have a useful feature "Size to text" which is accessible through the standard right click menu.  One way in which this is useful is to ensure that information in an array of constants is not hidden: Right click on an element of a string-constant array and select "Size to text" and it will expand to show the full length of all the strings it contains.

 

What's needed is an equivalent for numerics (including rings and enums).  When dropped singly, these constants expand and shrink around their contents.  But if you drop a numeric constant on an array constant, it takes the size of the numeric and can only be expanded manually.  If you then enter a constant that is longer, only the first part will be shown, and there is no indication that the values are truncated.  (see image)

 

I think that arrays of numeric constants should resize to show everything entered, automatically.

 

16985i3AA6C5F1591D73F6

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

_carl_0-1719594144175.png

_carl_8-1719594621558.png

 

But...if it's a class override method, I can't do this:

_carl_5-1719594530350.png

_carl_6-1719594541579.png

_carl_7-1719594559755.png

 

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

 

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up.  This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

 

 

LV2021 has a new "feature" called "Auto-Routing" (this is not Auto-Wiring, which can be deactivated in the options!). Auto-Routing moves wires around if you touch for example Sub-VIs.

Especially in compact VIs this function is a disaster right now. Sometimes for example wires will go "through" Sub-VIs so that an output leaves the Sub-VI at the wrong side resulting in a VI which is terrible to read:

1. Original Snippet of a VI:

Before.PNG

2. Same snippet, I just moved the "Get Variant Attribute Function" by one pixel to the right:

After.PNG

First we thought this is a bug, but the support told us it is a feature. But please: Let us deactivate this "function" in the options. I have colleagues telling me they would stop using LabVIEW if this remains as it is right now.

It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.

 

Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.

Jim_Kring_0-1607621796261.png

 

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...

 

Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

Clusters can be added together using the "Add" primitive:

_carl_0-1674589830749.png

Why not support adding them together in the same way using "Add Array Elements"?

_carl_1-1674589902284.png

I use a lot of user events and often define the user event references in a typedef cluster before actually writing the create/generate/destroy code. It would be really helpful if the Create User Event primitive would change its input datatype based on the output (i.e back propagate the datatype), much like the Variant To Data primitive.

 

Back Propagation of Data Types.gif

 

 

 

Problem:

I faced to delete multiple elements form the array which is having 20 steps.

 

solution:

if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.

 

 

Array element.png

 

 

GUIProgrammerDream.png

 

...the ability to bulk-create References, Local Variables, Property Nodes...

Resizing the front panel so it is correct when running the VI is still very tedious and can easily mess up during editing. The problem is even more severe for Xcontrols, because their runtime size is often very small so there is not even enough room to e.g. display all the tools in the tool bar during editing. Once the runtime size is correctly set, all it needs is a double-click on a terminal that has its FP item hidden outside the visible area and everything on the FP shifts and messes up.

 

We need three things:

  1. An "edit time" FP size that is "comfortably big" so we can see the entire toolbar and possibly also helper controls and even maybe some comment text intended for the programmer that are outside the operator area and only used for debugging and such.
  2. A "run time" FP size that matches exactly what the operator sees during running.
  3. A special decoration or other visual cue during editing that indicates the FP area that will be visible at runtime.

 We already have the crosshair in the upper left corner when showing the grid, so that could be defined as the upper left corner at runtime by default. All we need is define the upper left and lower right corner and the runtime FP area is uniquely defined. As a visual cue, everything outside the runtime area could be a shade darker or tinted differently than normal to indicate that fact. Running the VI would snap the FP boundaries to the bright area.

 

Then we also need handles to move any of the boundaries at single pixel increments. A control that scales with the front panel would simply scale to the bright area instead. Of course a legacy mode for older VIs that did not have this feature during their creation needs also to be supported.

 

The example image shows a reddish transparent area (just to throw out another idea, maybe a slightly darker grey would be better). This is one of my own subVIs that demonstrates the problem at hand. At runtime, only the progress bar should be visible, while at edit time, I want to see all controls, because I might need them e.g. to wire the connectors. It is not easy to switch between the two sizes.

 

(Of course we can currently program around all that by setting windows parameters via property nodes, but it is ugly, inefficient, and tedious.)

 

 

 

It would be nice, if the different kind of LabVIEW windows would have slighty different icons within the windows taskbar. It would be easier to quickly identify BD / FP / project / Ctrl / etc. windows in the taskbar.

 

This suggestion has also been made at

http://www.labviewforum.de/unterschiedliche-Symbole-fuer-Frontpanel-und-Blockdiagramm-in-der-Taskleiste-t13546.html

Here you can find two suggestions for FP & BD-icons.

Probing a typedef results in a vertical list showing all the fields in the cluster.  Creating the typedef cluster often involves organizing the fields in a particular layout, setting units etc.  It seems like probing the data and displaying it in the same format makes more sense.

 

For instance, I have a cluster of camera information set up as a strict typedef:

 

STSLabs_0-1653830762726.png

 

When I probe a wire of this information I get:

 

STSLabs_1-1653830848197.png

 

This cluster isn't too big so getting to all the information doesn't require a lot of searching and scrolling, but that can be an issue.  What's more of a pain is that the default unit for angles is rad and I cannot mentally convert them quickly so I end up having to double-click each 'rad' label in the probe window and change them to 'deg' so I can confirm the data is what I expect.

 

I know I can create a custom probe to display the typedef, but having to constantly create custom probes for each cluster is a bit of a burden.

 

Am I missing something?  Is there a good reason to NOT display the probe using the typedef?