LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (3)

The In Range and Coerce function is frequently used to determine whether a value is within range of an upper limit and lower limit values.

But when it is out of range, you often also want to know whether the value is out of range too high, or out of range too low. It is easy enough to add a comparison function alongside and compare the original value to the upper limit. It's another primitive and 2 more wire branches. But since comparison is one of the primary purposes of the In Range and Coerce function, why shouldn't it be built into it?

The use case that made me think of this that as come up in my code a few times over the years is with any kind of thermostat type of control, particularly one that would have hysteresis built into it. If a temperature is within range (True), then you would often do nothing. If it is lower than the lower limit, you'd want to turn on a heater. If it is higher than the upper limit, than you'd turn off the heater. (Or the opposite if you are dealing with a chiller.)

Request: Add an additional output to In Range and Coerce that tells whether the out of range condition is higher than the upper limit, or lower than the lower limit.

(That does leave the question as to what should the value of this extra output be when the input value is within range. Perhaps, the output should not be a boolean, but a numeric value of 1, 0, and -1, perhaps an enum.)

It would be quite helpful if LabVIEW would automatically grow down a function when bringing a new wire to build array/string concatenate/build cluster/interleave arrays/build matrix/compound arithmetic, allowing the programmer to make a new connection to the function if the function currently does not have room for the connection.

Even better is if it would grow/insert where the wire is near the function, below an existing connection, similar to 'ADD INPUT'.

Interactive Application Builder API

Currently, when you programmatically build an application using the "Build" VI of the App Builder API, you have no feedback (such as build details, progress percentage, warnings, errors...) and no ability to cancel while it builds.

So you have no idea how long it will take to build and cannot cancel if it takes too long.

It would be great to have these interactions, just like with the manual build:

The Build VI could have 2 notifiers or user events as additional inputs:

- 1 to receive build details, progress percentage, warnings and errors

- 1 to send the Cancel command

These additional inputs would be optional and default to invalid refnums, which would mean "do not use the feature".

View All (1)

I don't know why LabVIEW does this, but when you copy and paste (with ctrl-c and ctrl-v as opposed to ctrl-drag) certain items on your block diagram, they do not act as most would expect. I think copy and paste should make an exact copy of what you are copying instead of changing the functionality/behavior. Examples

Local Variable:

If you copy a local variable, it creates a new control and makes a local variable out of that. I really just want a copy of the local variable that's already there. If I wanted a new control, I would have made one, no?

Property Node:

Copying an implicit property/invoke node changes it to an explicit node. Why wouldn't it just make another copy of the implicit node that I already had?

I'm sure there's other examples of this behavior that I can't think of now, so feel free to add them to the comments. If you have a good reason why this behavior is here, please let me know as be happy to be corrected...

A recent discussion on the forum "why not everybody uses units" explains this much better than I can.

http://forums.ni.com/t5/LabVIEW/Why-do-very-few-programmers-use-LabVIEW-unit-labels/m-p/1802644#M621423

But for faster readers, several bugs hinder the universal use of units in LabVIEW.

It is a wonderful system but should be completed in a way (at least the square function should be using it) but all the other remarks found in that thread like the identical look of the expression node and the unit, not working formula nodes etc. should at least be taken seriously.

I lik the system but for now it is hindered by too many bugs.

View All (1)

Horizontal Scroll Hotkey

By default, the mouse scroll wheel scrolls the block diagram or front panel vertically, CTRL+SCROLL scrolls through cases/events/sequences and adding the SHIFT modifer to either accelerates the scroll. In order to scroll horizontally, however, the mouse has to be hovering over the horizontal scrollbar. Because of the predominant left-to-right, top-to-bottom style of diagram organization, it would be excellent to have a more accessible way to scroll horizontally.

I haven't found anywhere ALT+SCROLL is used - I think horizontal scrolling is a good candidate to fill that spot.

Show .lvlibp Terminal Context Help

View All (3)

Problem: There are currently two ways of moving or transferring a VI or CTL from one lvlib or lvclass to another (or from having no owner to having an owner).

Method 1: Drag-and-Drop. Select the VI or CTL, drag to desired lvlib or lvclass, drop in desired location.

This works well in small to medium projects, and will probably remain the quickest and most common way of moving a item from one owner to another.
This does not work well in large projects, which can have dozens or hundreds of classes and libraries, sometimes deeply nested within complex virtual folder structures (for good reason). In this situation dragging the item can take a long time, especially when the destination lvlib or lvclass is "off the screen" and slowly scrolling through the project becomes necessary. This is done by hovering the mouse in just the right region in the top or bottom of the Project Explorer. This can be tedious and wastes time.

Method 2: Remove and Re-add. Select the VI or CTL, remove it from its current owner by right-click >> "Remove from Library" or by pressing Delete key, select destination lvlib or lvclass, right-click >> Add >> File... , then select the file on disk (this last step can take time in large projects with large folder structures).

This can be quicker than method 1 in large projects.
This method is technically a workaround. It does not directly transfer ownership of the item.

Note: Both methods usually now also require moving the file on disk to the new owner's folder location. This can be done using the Project Explorer Files view, but is an additional step that takes time. It's also possible to simply forget to move the file on disk (best practice is not encouraged).

Solution:

Right-click the VI or CTL, select Move to... option
A window appears. This window may use a Combo Box or a Listbox to display a list of all the lvlibs and lvclasses available in the project.
The user selects the desired destination owner and presses OK.
The item is moved to the destination library.

1 (edited).png

Nice-to-haves

The Move to... window may contain buttons or other mechanisms (e.g. clickable datagrid headers) that enable the user to sort the libraries and classes in the project by name in alphabetical or inverse alphabetical order, and to filter: display only lvlibs, display only classes.
When the selected VI or CTL is initially part of a lvlib or lvclass, that owner will be omitted from the list displayed in the Move to... window.
The Move to... window could contain a tickbox named "Also move on disk to new owner's folder?" or similar. When this is ticked, the item is also moved on disk to the folder of the new owner. This would remove the need to use the Files view to move the item on disk (would save time) and would help encourage a best practice (member items should be located in the same folder as their owner).
The Move to... option should be available when multiple items are selected. The items may initially be owned by the same owner, or may be owned by different initial owners.

This idea is inspired by the "Project Explorer "Move to Owner Folder" option in Files view" idea.

View All (4)

A native ms wait in every loop

If unwired it would default to 0, and at least let thread switching occur. You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default... Maybe also right-click on it and get to choose between "Wait (ms)" and "Wait until Next ma Multiple"?

(PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).

Cluster Justification

One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.

There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.

The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.

Element of Array - edited.png

Thanks!

View All (3)

View All (4)

The Edit Events dialog has seen a number of improvements, but it is still very cumbersome to use when adding events for a newly added control. It requires too much effort to find the control in the Event Sources list. This problem can be easily and quickly addressed simply by reordering the controls section of the Event Sources tree in a more intelligent manner. There are two key problems:

1. The controls in the Event Sources tree are listed in the order they are added to the VI front panel. So the most recently added control is at the bottom of the list. Consider the following scenario, which is very common: You are editing a VI dialog that already has many controls. You want to add a new control and configure events for that control. Doing so requires scrolling all the way to the bottom of the Event Sources list to find the control. This is the exact opposite of the desired organization. The newest controls should be at the top, because they are the most likely ones that you will be configuring events for!

2. Clusters are expanded by default in the Event Sources tree. This bloats the list and makes it difficult to find the controls you really care about. When searching through the controls list, the first thing I have to do is collapse the clusters to filter down the list. But then next time I open the dialog, they are expanded again! It is relatively rare that a user wants to configure events for controls contained within a cluster. Generally the cluster controls are error inputs and outputs, or hidden off-screen clusters containing configuration data. They don't generally require event handling. Obviously there are some use-cases for it, but I think that it is appropriate to have clusters collapsed by default. It is not hard to expand them when searching specifically for a control within a cluster.

So my proposal is simple and straightforward, and would greatly increase most developers' efficiency when creating VI front panels requiring events. Sort the controls in the Event Sources list with the newest controls at the top instead of the bottom, and collapse all cluster controls in the tree by default.

Support Relative Paths in Build Specs

At present, build paths in build specs are stored as absolute paths, unless the path happens to be in the same folder as the project. Relative paths that are a level or more up from the project folder are not supported. Modifying the XML directly does not support relative paths either.

When working on multi-developer projects, where source control root folders may be different, this can be a serious annoyance. One of the better workarounds at the moment is to build to a non-desired relative path (within the project folder) and then to run a post-build action to move the generated files to the desired location.

But it shouldn't have to be this way -- relative paths should just work. (They are supported elsewhere in projects, such as with dependencies.)

(Note: this is the follow-up to a post on the LabVIEW forum about the same issue.)

multicolumn listbox

View All (5)

As much as I love Quick Drop, I don't love this:

This delay occurs because we have to load all the palette information in the background to be able to drop objects by name. You can choose Tools > Options > Controls/Functions Palettes > Load palettes during launch to front-load this delay during LabVIEW launch, but (1) a lot of you don't really like the longer launch time much better and (2) a lot of users still don't know about this setting.

I'm sure there's a way to solve this problem and make Quick Drop instantly usable, but I don't know enough about the underlying palette code to get it done. Solving this problem, by the way, could have positive side effects on LabVIEW launch time, palette search performance, and maybe some other areas as well.

create a safe mode

If you happen to put something that LabVIEW doesn't quite like in folders like "~\LabVIEW xxx\project"
LabVIEW will crash at launch and give you a very helpful crash report as shown here : https://forums.ni.com/t5/Discussions-au-sujet-de-NI/Crash-de-LabVIEW-%C3%A0-son-lancement/m-p/4215135#M35349

In order to avoid being told by NI support that you have to re-install LabVIEW

Please add a "safe mode" that will ignore whatever was added by the user (or VIPM) in the subfolders of the LabVIEW folder.

And also fix CAR 732888

When you compare two Vis, one with a control, and the other one with the same control but with a change on the test justification (You can modify it by clicking on the dropdown menu of text settings, next to the pause button)

If you compare the vis at this moment it only shows this

----------------------------

Difference Type: text justification

As we can see there is missing information regarding other comparissons like label name, object type and detailed description like the following example

----------------------------

Label Name: Label1

Object Type: String

Difference Type: moved

Detailed Description: Changed from "(168,132)" to "(12,71)"

Consider that this is a small scenario (only comparing two indicators) where the difference can be found easily, but if you try this with bigger VIs it will have a lot of missing information

The fact that this information is not available is time consuming, eventhough they can be walked manually the record of changes is compromised

View All (4)

The Compare VI tool is immensely useful, except when identifying changes in case statements, where it is easily "confused". Take for example two VIs where the cases in the case statement are identical except that in one VI there is an additional case at the end, or has a renamed case. When you run the Compare VI tool, everything is out of whack. It shows differences between two case that are named totally different, ignoring the other case that is named exactly the same. When this happens, you end up manually comparing. It would be great if the Compare VI tool would ignore the case order and compare the actual case names when doing a compare, much like a text compare tool would. Maybe even make it an optional setting.

View All (2)

LabVIEW Idea Exchange

Automatically disable autoscale when the user changes min/max values of a graph

High Low Terminal for In Range and Coerce

Auto-grow build array, string concatenate, build cluster, interleave arrays, build matrix, compound arithmetic

Interactive Application Builder API

Fix Copy/Paste for property nodes, local variables, etc

Make units work all the way or skip them!

Horizontal Scroll Hotkey

Show .lvlibp Terminal Context Help

Add "Move to..." option in Project Explorer right-click menu to help move (transfer ownership of) VIs and CTLs

A native ms wait in every loop

Cluster Justification

Add "Element of Array?" function to Array palette

Wire Label Text should be Center Justify

Reverse the list of controls in the Event Sources dialog and collapse clusters by default

Support Relative Paths in Build Specs

multicolumn listbox

Eliminate Quick Drop's Initial Launch Delay

create a safe mode

Add information to compared Vis when the caption changes

Compare VI tools that doesn't get tripped up on Case statement names