LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

 

tl;dr  There's a summary at the bottom if this is too long for you.

 

 

Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.

What I don't like about QD, however, is the keyboard shortcuts. These allow you to perform custom actions in LV and the concept itself is great, but the implementation QD uses has some issues which other similar tools like the right-click framework and LabVIEW Speak don't have, such as the items in the following list.

The problems:

  • It requires you to remember keyboard combos to call the plugins. That's great as a secondary access mechanism, but is terrible as a main one for a few reasons:
    1. It is not discoverable.
    2. It requires you to remember key combos.
    3. It doesn't work if you want a longer list of macros which perform all kinds of useful operations, because you run out of available shortcuts.
    4. Likewise, you have shortcut collisions, because people want to use the same shortcut for different plugins, so you might say "Ctrl+T", and it will mean something else to the person you're talking to.
  • Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having a clear representation in the user interface.


So, what can we do about it?

I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:

QD0.png


There are a few things to point out in this image:

  • The actions appear in the list using their full names and they have a glyph to set them apart from the other items.
  • The actions may (or may not) have a shortcut.
  • The actions may (or may not) have a keyboard shortcut (and there's no reason in principle why regular items can't have them too). This solves the existing problem of the shortcut limit - you only assign shortcuts to actions you access regularly, just like you can already do today with menu items.
  • There's a ring on the bottom which shows just the items, just the actions, or both. Ideally, the value of this ring would also be settable by other means (e.g. open QD using Ctrl+Shift+Space and the list only shows the actions or open QD when you have a selection and the list only shows the actions).

 

 

OK, so that's step one and it solves the first issue - the actions are discoverable, accessible and not limited in number.

 

Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:

QD2.png


This area shows the details of the currently selected action and allows selecting options for it.

Here's what we see in this example:

 

  • A title.
  • A description.
  • An image.
  • In the settings area, I gave the "Build array of references" action an option - you can choose to align the Build Array node to the center, the top or the bottom of the references.

 

The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.

 

 


Of course, once we have this panel, the next logical step is to also have it show the help for standard items, similar to this idea:

QD3.png



 

 


So, to sum up:

  1. Custom actions should be in the list of Quick Drop items.
  2. Shortcuts for actions and items should be fully customizable. That means that you can still use keyboard shortcuts to call the actions, just like today.
  3. There should be a panel which allows customizing options for actions and show the help for regular items.

 

Suggestion: Double clicking a connected terminal on the connector pane highlights and jumps to the connected control. This would be useful for controls that are off screen or hidden.

 

Similar behavior to double clicking the associated terminal/icon on the block diagram, where it automatically repositions the front panel's view.

 

Suggestion.jpg

When your certification expires, do you instantly forget everything you knew? Of course not.

 

I think the Certifications should be tied to a LabVIEW version. That way, there's an "implied age" to one's Certification (if they haven't taken a newer one), but you are still allowed to produce the Certification on cards, job interviews, etc.

 

 

CLAD logo Idea.JPG

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.

 

I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

I would like to be able to create executables that don’t require the runtime engine in LabVIEW. Perhaps a palette of basic functions that can compiled without the runtime engine and an option in the application builder for that. I routinely get executables from programmers that don’t require a runtime installation. I just put it on my desktop and it runs. It would be nice that if I get a request, I could create, build, and send them an exe in an email without worrying about runtime engine versions, transferring large installer files to them, etc.

After placing a new graph, we might want to go to the plot properties dialog and change the color, label, etc. of the plots we want.

Bzzzt. No go! We can only edit plots that have been added in some other way. (by resizing the plot legend, wiring and running once with data representing several plots, etc.)

 

For comparison, have a look at the cursor tab. Here we can add and remove cursors at will.

 

My suggestion is to add the ability to add or remove plots on the plots tab properties page of graphs and charts.

It could look like in the image on the left.

 

 

Hello,

Being able to rotate some indicators, controls, graphics or anything else would be great in my opinion.

Indeed, for example, when you have to represent an electrical circuit in your HMI, you must have several images of the same component with an angle of rotation of 0°/90°/-90°/180°.

So allowing a LabVIEW user to rotate some elements with an angle which could be set, would be more convenient.

 MALT.PNG

  Four images for one element. If we have 2.000 différent elements we must store 8.000 images.

 

 For Example mimic.PNG

Hello,

 

I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).

 

But many VIs written by NI have been programmed very sloppy.

 

Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:

 

spreadsheed_file.PNG

 

Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.

 

Regards

Help! I need a way to pack more Classes onto my Block Diagrams!

 

This idea is simple and quite subtle- reduce the size of the Class Constant on the Block Diagram. The majority of the footprint belongs to the Class Icon, which cannot be sized smaller, but the additional border graphic that creates the "Object Cube" effect can be reduced to give a total footprint of 42x42 pixels down from 48x48 pixels. (If you're counting, that's a 42% reduction in "fluff", discounting the 32x32 that must remain!)

 

Idea.png

 

 

If you're not crazy about the first-draft artwork, feel free to post a new rendition in the Comments section!

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

This idea came from customer Jason Willis during an NIWeek 2012 brainstorm session with LV developers. To me, it seemed like a good idea, so I figured I would post it to the community to flesh it out and see what kudos it gets.

 

When you have a reentrant VI, you have the one real VI and many clone VIs. Debugging the clones is hard. One way to make it easier might be to make the probes behave like the breakpoints do.

 

When you put a breakpoint on an individual clone, only that clone gets the breakpoint. But if you put a breakpoint on the real VI, all the clones get that breakpoint. That gives you a way to stop at a point of execution regardless of which clone gets pulled from the clone pool.

 

We could make probes do the same: if you put a probe on a real VI, any time the block diagram of a clone gets opened, a probe would be added to its wires in the same locations as on the real VI. If you removed the probe from the real VI, all the duplicate probes on the clones would go away too. But if you added a probe to a clone, the other clones would not get a probe.

I'm totally on board with Embedding Labels for Property and Invoke Nodes! Here are some additional improvements to those nodes:

 

Property Node Concepts

22360i1B976CE68F1194B3

 

Scripting and Invoke Node Concepts

22364iA43FCE953263A787
  1. Most importantly, the banner now more closely resembles a Static Control Reference.
  2. The directionality arrows are a pixel width's larger - more distinct, and matching the size of the new LV2010 Local Variables.
  3. The node banner is the same height as the unlinked property node.
  4. Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
  5. Scripting properties/methods are now more distinct. Currently, the small node banner inherits a few pixels of light blue distinction if any one property on the property stack IsAScriptingProperty. Proposed, shading will be applied on a per-property basis, allowing better visual distinction and a more coherent choice for what to shade.

Discussions/suggestions/insults/questions encouraged in comments section!

Often, when modifying code, I need to reduce the size of a structure due to removing code.  If I have a nested structure system (e.g. event structure in a case statement in a loop), this can get very tedious.  It would be nice to have a "shrinkwrap structure" functionality on the right-click menu as a counterpoint to the autogrow.  This would be an action that would reduce the structure size to something a bit bigger than the largest contents.  An option to set how much extra space to include would be nice.

I really, really don't like this behavior:

 

key_focus_border.png

 

Whenever you use the KeyFocus property, or simply the tab key on a running VI, whatever control has key focus gets that ugly black border around it.  Can we just eliminate this feature, or at the very least, have the ability to disable it?  The border doesn't appear on System-style front panel controls, but it does for anything else.  I've written all sorts of hacks over the years (the latest being in Quick Drop) where I have to figure out a way to hide that ugly border when a control gets key focus.

In general I would like to see LabVIEW more in line with the OS GUI standards. We have dialog controls and colors, however they are not set up to be the default choice - and we lack other GUI elements like status bars, notify icons, child windows etc. etc. A large part of LV-programmers' time is spent on ways to get LV to mimic what users will recognise and therefor intuitively understand.

 

In this case I simply miss the "sort glyph" that indicates that a table or listbox is sorted based on a given column and in which direction.

 

I imagine we could show or hide this and set its direction with a property node...It would not handle the sorting (although that would have been neat as well - if you had an in-built sorting that just needed to know a few parameters about the column data to do the job)...

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

 

Control auto numbering.png

 

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

 

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

What's wrong with the current LabVIEW Fonts option dialog? Plenty!

 

Let's have a look:

 

 

  • We can only see one of the three font groups
  • It does not tell us the name of the current font, just how it looks!

 

If we specify a custom font, we get a dialog that has confused me since I started out with LabVIEW 4.0 way over 10 years ago.

 

 

Especially the two checkboxes in the lower left corner have bugged me since day one, because they are very confusing.

 

  • If we open this dialog from the options menu, both boxes are unchecked.
  • If we open this dialog from the BD or FP font pulldown, one of the checkboxes in inoperational, but not greyed out. Why???
  • Unless we read the help, it is not clear what they actually do and what they actually show.
  • Do I click these to make whatever I have selected the default or do I click these to revert back to the default???
  • ...

 

This font dialog needs to go and be redesigned from scratch!

 

IDEA:

 

Why not make the Font options a bit more intuitive. Here's a quick draft. Even if we select the default font, it should show what it is but have the parts on the right greyed out.

 

It probably would need a small preview area below each selection (not shown). Each can be much smaller than the current preview window. (It does not matter if a 500pt font is clipped a bit.)

 

Message Edited by altenbach on 07-28-2009 09:41 AM
Download All

I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.

 

I get greeted by the hugely informative imagery as shown below:

 

BRoken local link.png

 

Yeah, good luck realising what exactly you deleted by mistake.  No name, no way of finding out what the local PREVIOUSLY linked to.

 

I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error.  Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.

 

An example of how this could look:

 

Broken Local hint.png

 

Here I at least know WHAT I have deleted by mistake.

When entering debug mode (turn execution highlight on) it can be hard to see what is happening.

 

With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...

Parallel Loops.png

 

SubVI's get a green arrow when they are executing. So, could structures get them as well?

 

Parallel Loops proposal.png

I would like to have an option to export a simplified image of a graph directly into png. The image formats available in LV2010 are bmp, eps, emf and pict. Png is superior to bmp with rougly 100-50 times smaller file sizes. At the moment if I want to export a simplified image of a graph to png then I have to use the extra code below or alternatively export the image to clipboard, paste that into a graphics editor an save it to png. It would be much more simple to have an option to directly export to png. My suggestions below:

 

export simplified image to png.png

export simplified image to png 2.png