LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Flying Probe in Context Help

View All (1)

Annotate palette items with dynamically generated keyboard shortcut characters. The keyboard shortcuts should be such that users don't have to use two hands to type them out. Typing out the shortcut will close the palette and put the palette item on mouse cursor. If the shortcut is on a palette folder, the palette will remain open and show content of the folder.

This is a great symbiosis between mouse and keyboard and will increase user's coding speed by reducing mouse travel.

There should be a couple of options for opening the palette via keyboard shortcuts for a complete experience-

Shortcut to open main palette. Similar to right click on blank space.
Shortcut to open recently or most used items palette.
Shortcut to open parent palette of node under cursor (or last node dropped).
Shortcut to open palette related to datatype of wire under cursor.

Here is a visualization of how the annotations might look like-

Note that all the shortcut characters are on left side of the keyboard, and could be typed one handed operation by a touch typist. It will be easy to configure the tool for left-handed people and concentrate the keys on right side of the keyboard. Also, the letters have been selected in a way that the two keys are on separate fingers for faster typing.

Comparing to quick drop feature-

Quick drop requires user to recall from memory. User has to either remember the short name or the full name of the item. With this idea, the shortcuts are right in front of the user.
Characters of full name of the item on quick drop can go all over the keyboard. User either has to move one hand around which will require looking at the keyboard or move the mouse hand to keyboard. With this idea, it will be easy to control the shortcuts to be on one side of the keyboard.

Note: Short name of items in quick drop are concentrated on left side of keyboard, catering only to right-handed use. Not sure how easily the short names can be configured for left-handed use.
Overall this idea supplements quick drop. It speeds up a few happy paths.

Inspirations

Figma. It is a website design tool and has a tiny palette with rectangle, circle, line, text, etc. It has keyboard shortcut for each of the palette item – R for rectangle, L for line, T for text, and so on. E.g. typing R brings the rectangle on mouse cursor. It has a small palette so remembering the shortcuts is easy. This idea cannot be directly ported to LabVIEW because of the billions of palette items.
Vimium C Chrome extension. This extension enables experience of vim editor in browser. One of the features it has is annotating links with dynamically generated keyboard shortcuts. Typing out the shortcut keys takes you to the link.

Combining both gave origin to the above idea.

View All (2)

Waveform charts are really useful but have an annoying bug. Every now and then (maybe once every 10 seconds depending on the update rate), the digital displays blink to zero even though a zero value was never written to the chart. I use these charts frequently in HMI type displays and explaining this behavior is always part of the training for new operators ("Don't worry if this critical sensor goes to zero for a second unless the line on the chart also goes to zero, then you should freak out and hit E-stop"). This has been brought a couple times over the last 8 years (http://forums.ni.com/t5/LabVIEW/Waveform-chart-digital-display-blinks-zero/td-p/554868) but has never gained enough attention to be fixed. I know this functionality could be duplicated with additional numeric indicators or even an xcontrol but I would prefer to just have waveform charts function correctly. I attached a VI that shows this behavior. All three of the digital displays randomly blink to zero.

Conditional Disable Symbol Constants

Currently we can use a Conditional Disable Symbol (CDS) only as some "special kind of case selector".

There is no way to get the actual content of a CDS.

I think there should be a Conditional Disable Symbol Constant.

This would behave exactly like a string constant, but it's value would change with the attached CDS.

This would enable us to generate log files or messages (especially on RT systems) that carry more valuable information.

In some cases it would also enable us to use CDS similar to #define in C.

View All (3)

Following Robbob's advice from the end of this http://forums.ni.com/t5/LabVIEW/LV-2009-error-bar-plots-suggestions/m-p/987381/highlight/true#M441998 thread, I'd like to "bump", and extend, X.'s idea posted there:

A true, built-in, native (not x-control) error bar option on a standard fully-fledged X-Y graph- perhaps implemented simply as a different bundling of arrays to the graph indicator- eg bundle(Xvals, Xerrs, Yvals, Yerrs) or bundle(Xvals,SD(X), Yvals, SD(Y)). In the latter case, the depiction of each data "point" as a gaussian intensity "blob" would be the answer to a years-old dream of mine...!

Thanks for considering....

Sometimes, when debugging code, I may force a situation, e.g. force a boolean to be TRUE or FALSE, or force a For Loop to only run once. Once I have made the fix I then forget to reverse my changes and run my code. Or, even worse, create an executable and send it to a customer. Doh!

Could we create a primitive, in the shape of a small bug, that I could drop in my code at the point where I force the code? Then, when I come to run a popup asks "Run with bug?" This would allow me to debug my code, but would also remind me to undo the deliberate bug before I run the code for real or try to create an executable.

One of the more annoying features (see also here) is the unzip operation after downloading a LabVIEW distribution. As a first step, it will unzip somewhere into the "National Instruments Downloads" folder.

Of course it will place the progress window right in the middle of your monitor. Typically this takes a while and actually want to do something else and move that window out of the way, so we can still watch it in the corner of the eye. Easier said than done! A simple click in the window header pauses the unzip operations and asks if I want to abort... NO!!! I simply want to move that window is the same way I can move any other window from any other application!!! Why that nonstandard behavior? Just to annoy us??? Here's what happen if I click anywhere near the top edge of the window:

When we righ-click the window header, we see two options "(1) move" and "(2) close". Why is close the default??? If we really want to close, the [x] button is right there another inch to the right and nobody should have trouble finding that spot. If I click elsewhere in the header, I most likely want to move that window!

In order to actually move it, I have to right-click the window header and select "move". That seems silly!

IDEA: The unzip window should should be less annoying and easy to move elsewhere. Thanks!

I think it would be a good idea to have a tool integrated into LabVIEW that would let you view the amount of time it took to run your VI.

There has been a few posts in forums asking for programmatic ways to do this, but this way would answer them all:

Clicking this would allow you to see the time it took for the last run of your VI to execute. Making it quick to see if and acute changes made to your code had made this more efficient (time-wise).

An improvement to this would be to have a sweep like feature on your block diagram that you could set up multiple markers to see the time taking for your code to reach them.

A bit like this:

These markers would be moveable and their values would update after execution.

These are just ideas, I'll be glad to hear your comments!

Regards,

View All (6)

I misunderstood ouadji's post here, but I liked my interpretation of it. I didn't find it on the Exchange so...

Idea:

Make it possible to copy the VI properties from one VI to another.

Method:

User right-clicks on the VI in question, selects "Copy VI Properties", then right-clicks on the new VI and selects "Paste VI Properties". BAM! All (or almost all - to be discussed) properties are copied to the new VI.

Similar to JMP's Copy Column Properties:

What properties would be copied over?

Initally, I thought EVERYTHING! But then my fit of insanity passed and I realized that some items should not be copied.

The Big Two That Shouldn't Be Copied (that's like, my opinon, man...):

Revision History

Window Title

Everything else is up for debate. So go, debate away you master debators!

View All (2)

I am a fan of the Combo Box for situations when I have a set of not-so-human-readable strings I would like to map to their human-readable counterparts in a clean and extensible fashion. So far, so good. Often, however, those illegible strings are also format strings which I often use in combination with Format Into String as below.

The problem, however, is when the different commands use different numbers of inputs. It is no problem to always wire input 1 and input 2, it is usually obvious from context, or through visibility controls which ones correspond to different commands. The problem however is that when I only use one format specifier in the format string the Format Into String function throws an error and returns an empty string. Too many specifiers is one thing, but in my opinion, too few should not be an error. A warning, maybe, but I'd ignore that anyway. Or, if an error must be thrown, at least return the result with the subset of inputs used.

One workaround is to use a case structure to sort by the number of parameters to wire. Not horrible, but the cases are based on the not-so-readable strings.

View All (2)

On a compact UI 1D arrays are very often uncomfortable.

On the one hand only a few elements can be shown, on the other hand there is often a lot of free space (usually on the side of the array).

My suggestion is to implement a 2D-View of a 1D-Array. Please see the pictures (1D-Array of a cluster control) for better understanding.

Left image: current view, 6 out of 10 elements are visible; right image: suggested 2D-View, all elements are visible

View All (10)

It is possible to import an EPICS .db file into LabVIEW in order to use the Process Variables (PVs) within LabVIEW.

(see https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/introduction-to-epics.html )

But, all records are imported as seperate LabVIEW items.

Each PV has to be seperately added as a 'bound shared variable' for inclusion into a VI.

Then each PV will need to be seperately connected up to a control or indicator, unless some means of iterating over the collection is implemented.

This is all fine if there are 3 or 4 PVs (as is the case for the example app).

My current application is quite modest in scope - there are 15 PVs for each of 6 devices, so 90 PVs altogether. It is barely feasible to follow this manual process for each of these - it would take hours and be very finger-trouble prone.

Many EPICS IOCs can use thousands, or even millions, of PVs.

I would suggest that the .db file import wizard process the PVs from each file into a cluster.

Or - possibly better - process PVs into an array of clusters.

IMO, the current implementation just isn't scalable to 'real world' control system IOC use.

If NI wish to provide LV integration with large-scale EPICS projects, I beleieve a better way of doing needs to be found.

(Re-posted from https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enhanced-EPICS-Support/idc-p/3203 )

The NI_ChannelLength is a handy property, written to each channel in a TDMS file that can be read to tell you the number of samples in that channel, without having to read all the samples and do an array size operation on it. Having this in a property can also be useful for programs like DIadem or the DataFinder tookit which index these properties.

This idea is to have an option to add a few more properties built into the TDMS write operation. It would be best if this were an option given to the TDMS Open, which is off by default.

I think adding a NI_ChannelMinimum, NI_ChannelMaximum, and NI_ChannelAverage would be very helpful so that this information is available without having to read every sample, for every channel, for every group. Again the benefit can be clear when using DIadem or DataFinder and having this information be quickly available.

Of course we can do this today if we don't mind having to read every sample, perform the Min/Max/Average then write this property, but this can be a very time and memory intensive process for large files with lots of samples, channels, and groups. For channels with data types which aren't a numeric, I'd say a constant can be used, like NaN, or 0 if the data type is not a double. I think this would be most useful for channels with a numeric data type, waveform, or timestamp.

View All (2)

Pressing the escape key while performing a click and drag zoom / pan / cursor operation on a graph should cancel the operation and revert the axes / cursor to the original state. At the moment the zoom operation can only be cancelled by dragging the mouse cursor away from the graph control. There is no way to cancel a pan or cursor operation.

The escape key would need to be pressed while the user has the mouse button held down to cancel the operation. This operation mimics cancelling a drag + drop operation within Windows.

I'm sure the above could be impelmented as an X-Control, but would be much more convenient if it was native to the LabVIEW graph and chart controls.

View All (7)

View All (2)

I believe it would be very beneficial to be able to delete space on the block diagram. There is already a great feature in LabVIEW which allows users to create white space by using the Ctrl+Click and dragging your cursor. If you use this block diagram expanding feature, it is very likely that you created too much space and would like a little less; however, the only way one can do this is by using the 'undo' feature, which will undo all of the work you just accomplished! Instead of rearranging loops and repositioning functions, it would be beneficial to be able to delete block diagram space.

View All (8)

LabVIEW Idea Exchange

Flying Probe in Context Help

Dynamically generated keyboard shortcuts for palette items

Fix waveform chart blinking to zero bug

Conditional Disable Symbol Constants

Error Bars on X-Y plots (sort-of BUMP)

Add a deliberate bug to your code whilst fixing it

Make "move" the default action for the unzip window when clicking the header

Measurement of execution time of code in LabVIEW

Copy and Paste VI Properties from One VI to Another

Too FEW format specifiers should not be an error for Format Into String

Multi column 1D array (2D view for 1D arrays / lists)

Indicate which controls have events attached to them in the Add/Edit Event list

Improve EPICS database file import facility

More TDMS Built In Properties (Min/Max/Avg)

Allow a repeat of the last action using a function key.

Easy change from Propery Node to Invoke Node

Press escape to cancel zoom / pan on graph

LabVIEW default configuration in user profile and overridden by project configuration

System Enumeration Indicator should hide the arrow

Deleting unnecessary space from block diagram (Opposite of Ctrl+Click and Drag)