LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (3)

"Resizing helper" tip strips

Since very early LabVIEW versions, we always had the small sizing tip strip at the bottom that showed the current size in pixels when resizing an object on the front panel or diagram.

This is maybe OK for simple decorations, but for most other objects it is very inadequate and not helpful at all. For example if I resize an "index array" node to show more outputs, the node size in pixels is probably the least interesting information! It would be much more useful to indicate the number of outputs instead.

Now if we resize an "index array" node for 8 outputs, we simply resize until the tip strip shows [8 outputs]. Without this, we need to guess the size, count, resize again, etc. A slow, tedious, and error prone process, especially for larger sizes.

Of course the "resize tip strip" should adapt depending on the object that is being resized to always show the most useful values(s). Here are some possible examples:

Resizing action example of tip strip

Resize a 1D array: [5 elements visible]

Resize a 2D array: [6 rows x 5 columns]

Resize "built array" node: [7 inputs]

Resize "index array" node: [5 outputs]

Resize "initialize array" node: [3 dimensions]

Resize "replace array subset" node: [8 elements/subarrays]

Resize "compound arithmetic" node: [4 inputs]

Resize a graph: [Overall size: 400x600, plot area: 380x500]

...

It should of course apply equally for front panel and diagram objects. For example the suggestion for the arrays would apply to an array control, array indicator, or array diagram constants.

Of course there are many more possible objects, each with it's on set of useful size parameters. This is just a small collection. Please go over the palettes and make other suggestions!

Message Edited by Support on 06-02-2009 12:36 PM

View All (3)

Create a Picture Ring Constant

I feel like in a few cases, my code could be more readable, if a picture ring constant existed. By that I mean if I could have a block diagram object, that showed an image, and clicking it would allow me to select one of the other images in the ring, which correspond to a numeric value, just like the picture ring control does.

I've come into a few cases were I want to know if my picture ring on the front panel is equal to some case. So I will use the equal primitive and compare my picture ring control value to a constant. Problem is my constant is just a numeric, because that is what the data type of the picture ring is. I then usually need to put down a comment explaining what the value of 2 or 3 is supposed to be. I feel like a better solution for readability would be to have an equal function, and wired to it, is another instance of that picture ring type def, where you can see the image that the value is being compared to.

Now sure this doesn't come up often, and in most cases it is recommended you convert that ring into an enum, and then you get a bunch more benefits, but in a few cases I feel like adding a picture ring constant would only make the code more readable.

View All (6)

Relative Path Node

I'd like to work with relative paths at a higher level of abstraction.

I often use path constants in block diagrams, and almost always I need relative paths. I love Browse for Path option on the file path constant. Inconveniently, I end up with an absolute path when I browse like that, then have to manually select the front end of the path, and drop a few other nodes and wires to specify what the path is relative to. The resulting code looks like this:

Four Relative Paths LabVIEW 2019

Note that the path 3 and path 4 are identical.

I would like to see a single node that:

Lets us specify what the path is relative to,
Lets us browse for a path like the file constant, and
Displays relative path without manual editing.

Here is what the code displayed above would simplify to:

Four Relative Paths with New Node

I'd like the base path selection to include options consistent with those from the file palette. One way to do this is to have a shallow hierarchy like this:

LabVIEW
- Application Directory
- Current VI's Directory
- Default Data Directory
- Default Directory
- Temporary Directory
- VI Library
System
- User Home
- User Desktop
- User Documents
- User Application Data
- User Preferences
- User Temporary
- Public Documents
- Public Application Data
- Public Preferences
- Public Cache
- System Core Libraries
- System Installed Libraries
- Application Files
- Boot Volume Root

This idea is based on the discussion from the Path Constants Relative to the Current VI's Directory Path idea. I'd like to thank AristosQueue and crossrulz for their feedback on that thread.

Select VI Quick Drop Default Text

View All (1)

LabVIEW provides 6 VIs to allow reading and writing image files - each one pertains only to a specific format (bmp, jpg, png). We should add VIs which figure out which image format is given, and uses the correct image VI automatically in the case of reading. In the case of writing, the format is determined by the extension of the provided file name. I created a read and a write VI which does this here:

https://decibel.ni.com/content/docs/DOC-12141

I feel that this should be included in the image palette:

Many people do not realize that memory allocated by a queue is never deallocated until the queue is destroyed or the call-chain that created the queue stops running. This is problematic for queues that are opened at the beginning of the application and used throughout because all of the queues will always retain their maximum size, causing the application to potentially hold a lot of memory that is currently unused or seldomly used.

Consider a consumer that occassionally lags behind and the size of a queue will grow tremendously. Then the consumer picks back up and services the elements out of the queue in a short period of time. It is unlikely the queue will be this large again for quite some time, but unfortunately no memory will be deallocated.

I'd like a primitive that will deallocate all of that memory down to just the current number of elements in the queue. Since the queue won't need that much memory again for a long time and the queue will auto-grow again as needed, I'd like to recover that memory now instead of waiting for the application to be restarted (which is currently the only time the queue is created.)

The alternative is to add some code to periodically force destroy the queue and have the consumer gracefully handle the error and open a new reference. Then replicate this change for all queues. Seems messy and puts too much responsibility on the consumer. I'd rather just periodically call a 'deallocate queue memory' primitive on the queue reference within the producer, perhaps once every few minutes, just to be sure none of the queues are needlessly holding a large amount of memory.

I believe this will:

Improve performance in other areas of the application because less time will be spent looking for available memory to allocate.
Reduce the chance of Out of Memory errors because large blocks of memory will not be held [much] longer than they are needed.
Improve the common user opinion that LabVIEW applications are memory hogs or leaky.

I realize this will hurt enqueue performance when the queue begins to grow quickly again, but this area is not a bottleneck for my application.

Thanks!

View All (1)

Enqueue array of elements

Smooth Scrolling

Oftentimes, I would rather have a smooth scrolling action rather than the line-by-line action. This is not just a whistle or bell to make UI's more modern; from a usability standpoint, it's easier visually to trace a smoothly animated object rather than a jerky object.

Here are two dorky little GIFs to illustrate the point (first is "clunky", second is "smooth"), but go ahead judge the difference yourself by opening the attached LV 8.2 VI. It contains a "simulated" smooth array using a cluster trick.

Oh yeah, this would apply to Arrays, and Trees, and Listboxes, and Clusters, Matrices, and Tables, and.... (hey, we currently have smooth scrolling for string indicators! One out of a half-dozen is a good start....)

I envision an option between clunky and smooth, because both options have their merits for different situations.

View All (2)

This idea is somewhat similar to Shrink-Wrap-Structures but for comments and strings

The idea is to resize a comment or string to the text by double clicking one of the resize indicators around the box.

This would happen without changing the number of lines or words on each line.

resize double click.png

The process would be resize the horizontal direction of the box until the line layout looks nice (and fits!) then double click the corner to remove the unwanted space.

There could be different resize processes depending on the corner or edge you click eg. double clicking bottom middle resizes to only remove vertical space, top left would resize and shift the text down and right so the bottom right corner remains anchored.

There are some other ideas about resizing multi line comment boxes but none were quite as straight forward as this so I made a new post for it.

This mechanism is similar to other programs for resizing boxes so it seems like a sensible thing to implement.

extra option on 'merge error'

I know that many extract wires 'upwards' and later on merge errors to collect errors and continue. From a layout perspective it's natural to add the top code to the top input of Merge Errors, but from a data flow perspective any error that happens there is often secondary to the 'base/lower' part of the code. This means you need to connect the top code to the bottom input of Merge Errors.

Wouldn't it be nifty if you could have an r-click option or input of "reverse order" or "merge from bottom"?

I assume that it behinds the scenes makes an array of errors and looks for the 1st one, so this would only add a 'reverse array' inside the function. To not have that ability forces you to do a Build array, Reverse array and Merge Error, which feels unnecessary.

View All (1)

Taking this comment and making it an idea on its own.

Numeric controls can be configured to display their value today as SI Notation, decimal, octal, hex or binary by enabling Visible Items >> Radix and then setting the radix ring to the desired value.

This proposal is to add a new option to the ring for unsigned integer types: ASCII. This would cause an integer to be displayed as a series of characters as each byte of the integer is interpreted on the standard ASCII table.

(If in the future LV improves support for unicode string handling, adding a radix mode for "Unicode" might also be good, though at that point you'd have to specify an decoding to use for the individual control)

Note that adding this option to the Radix ring would really invalidate calling it "radix". Having "SI Notation" in the ring is already stretching the definition, but this would push it over the edge, so we might want to call it "Display format" or something like that. Or perhaps there's an alternative way of specifying this display mode that would be better (everyone, put your suggestions in comments below), but the main thrust of the idea is to let a number be shown using its character interpretation.

View All (4)

Bring NXG C Node to LabVIEW

View All (2)

When you select a portion of code to create a sub vi, the logic that names the contorls on the sub-vi makes some bad choices. For example:

In the block diagram above, the selected portion of code will be used to create the sub-vi.

The resulting sub-vi front panel looks like this:

Notice that the input control inherited the name of the control from the parent but the output did not. Also note that the error output control inherited the name of the output from the sub-vi inside the new sub-vi, but the input error did not and ends up with the name 'error out 2'. This of course would NEVER be the right name for this control.

It would be a lot smarter if the new sub-VI inputs would inherit their names from the inputs of the functions inside the sub-vi since that more accurately describes what they will do with those controls. Also, I think the output indicators should inherit their names from the original destinations in the parent VI since that more accurately describes the data they will contain once the sub-vi executes.

The current behavior seems to be exactly the opposite of what a developer would want.

give decorations a property nodes

This idea is an extension / alternative for this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/give-decorations-a-label-property-to-address-and-modify-them/idi-p/3558864

You can give Kudos to both 😉

Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist but it's hard to reach them (if your read the other idea, you'll see that it is even imposible for a specific element).

What I'd like to have is a right-click-menu-entry "create property node" (same for method node). The result shall be a property node appearing in the block diagram which is linked directly to the decoration element.

View All (3)

The Open/Create/Replace File Function with the Create operation does not create the file if the specified path leading to that file does not already exist. One has to use the separate Check if File or Folder Exists vi followed by the separate Create Function to first create the folder if it is found to not already exist and then actually Create the file with Open/Create/Replace File. It would be useful to not have to perform the already exists operation and simply provide the capability (perhaps as an input boolean option) to create the entire file's folder path if it does not already exist when using the Open/Create/Replace File Function to create a file.

Steve

View All (1)

Insert class VI contextual menu

View All (3)

LabVIEW Idea Exchange

Different Blink Rates for different LEDs

"Resizing helper" tip strips

Property to get LabView Editor bitness 32bit / 64bit and patch level

Expose all available LabVIEW Project Methods via VI Server/Scripting

Create a Picture Ring Constant

Vertical Justification for String Indicators

Relative Path Node

Select VI Quick Drop Default Text

Add read/write image VIs that work with all image formats

new primitive to deallocate unused memory from queues

Enqueue array of elements

Smooth Scrolling

Resize Text (Comment or String) with Double Click

extra option on 'merge error'

Give numeric control a radix display option of "ASCII"

Bring NXG C Node to LabVIEW

Create SUB-VI from selection should intelligently inherit control names

give decorations a property nodes

Open/Create/Replace File Function - create file's path if it does not exist

Insert class VI contextual menu