LabVIEW Idea Exchange

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

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

 

1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do

 

Thoughts?

It would be nice if NI could provide the option to BLINK different LEDs at a different rates instead of a constant blink rate that it there at present.

We need the additional properties of the used LabView Editor:

bitness: 32 or 64 bit

ServicePack Number: 1,2,3 ....

Patch Version: f1,f2,f3 .......

 

fixedimage.png

 

So, what i like to have is, that i can get the above listed properties from the currently running LabView Editor, programmatically!

 

See also forum discussion for the problem:

programmatically get Labview Editor bit Version

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

Current methods for the LabVIEW Project that exist as Right Click Popup Menus are not exposed via VI Server/Scripting.

However, these methods would be very handy to call programmatically. 

 

I say, if we can Right Click Popup on it, then we should be able to script it!

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.

 

Picture Ring Constant.png

 

I'd really like to see some additional text formatting options, specifically:

 

1.)Vertical text justification in string indicators (top, center, bottom)  ******* please!

2.)A better font navigation, the pulldown list of hundreds of fonts can be exhausting (scroll, scroll, scroll, scroll, ...)

3.)Better font previewing for those that can't recall exactly what "Gloucester Extra MT Condensed" actually looks like  😄

 

 

 

 

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 2019Four 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 NodeFour 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  and 

Quick Drop (Ctrl+Space) is often used to work with a selected VI (e.g. Ctrl+P replacement). The Quick Drop dialog window opens with blank text box. Default that text box to the VI name if one is selected when Quick Drop is opened. That text should be pre-selected so that typing replaces it (no extra keystrokes for backward compatibility). Furthermore, it would be extra nice if the selected VI was automatically highlighted in the list.

QDP.jpg

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:

 

1.png

 

 

Deallocate Queue Memory.PNG

 

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!

EnqueueArray.PNG

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.

 

ClunkyScrolling.gif                SmoothScrolling.gif

 

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.

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.

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.

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.

I just found out about LabVIEW NXG's C Node. I know my team would love to have it in LabVIEW to use for bit masking in a familiar syntax. The Expression and MathScripts nodes have issue with 64-bit values and give unexpected results. A quick test in C Node does fix these issues.

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:

 

 before subvi.png

 

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:

 

generated subvi.png 

 

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. 

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.

 

deco_property.png

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