LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

The current boolean diagram constant is potentially confusing and too elaborate.

Confusing, because it almost looks like a toggle switch, so the new user might click on the right half, expecing an unconditional FALSE. However, there are no active areas, and an inversion of the current value occurs no matter where we click.

Too elaborate. All we need to see is the current value! Why do we need to see the "other" value greyed out??? We can guess that by simple elimination. 😉 There is too much redundant information, wasting twice as much diagram space than actually needed to display relevant information. The current design also makes e.g. 2D boolean diagram constant very confusing. Have a look at the image. Can you immediately tell that the 2D array on the left is only true on the diagonal? (I did not think so!). Now look at the suggestion on the right. Ahh... much better! 😄

Suggestion:

The boolean diagram constant should be smaller, simpler, and cleaner.

The image shows the current design on the left and the suggested design on the right.

What a difference in clarity and economy!!

Message Edited by altenbach on 07-03-2009 02:39 PM

View All (1)

In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.

I propose the option to align the digital display as shown in the last picture.

(BTW, looking for duplicates I found one comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Assembly-of-the-graph-s-plots/idc-p/1085440)

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step). Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary. Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

View All (8)

Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!

But it's painful. Boooo!

Curently => Right-Click wire, navigate to sub-menu of Show>>Label

It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.

So we should make it just as easy to add labels to wires:

Step 1: Single-Select Wire
Step 2: Start Typing
Step 3: Profits!

We don't need no stinkin' right-click menus.

PS: I am proposing a single click on the wire instead of double-click because that performs a different action.

View All (1)

glyphs in case structure menus

Another for the wish list.

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

See attached pic for an mock up.

There are probably lots of menus that could benefit from something like this.

View All (1)

View All (6)

Not so much an idea, as a wish/plead/rant:

Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.

2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right! Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).

I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:

Graphs and charts

1. You cannot stack plots in any of the graph indicators, only in charts
2. Number of plots stacked cannot be varied at run-time
3. Annotation properties are only partially available programmatically
4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way
5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample...
6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues
7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible
visibility.

8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming

9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...

Mixed signal
1. You cannot set the group names programmatically
2. The number of plot areas is not configurable at run-time
3. You cannot assign plots to a given group programmatically
4. You cannot show the visibility checkbox of each plot etc.

And then you have the additional 2000 ideas...;-)

As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.

Would that not make everyone's day?

View All (3)

Show Reentrancy in Context Help

Hi all,

What I'm asking for is an optional indication of reentrancy in the context help window.

This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.

I realize that Greg Freeman suggested something similar. My intent here is to narrow down several ideas from that conversation down to a single suggestion.

(I hope I still didn't manage to post a duplicate. Apologies if I did.)

Thanks,

Jim

View All (5)

It is not obvious that a NaN numeric constant can be created by simply typing "NaN" as value. What we see are weird constructs, e.g. "zero divided by zero" or "square root of -1" to generate a NaN on the diagram.

I suggest to add a NaN diagram constant to the numeric palette to make it more obvious.

(This is just a quick draft. Of course it should be matched in color and design to the other constants)

This drives me crazy... I've noticed that if I have some code on my block diagram (or controls on my front panel) the scroll bars indicate that there is more stuff outside the view of the window that can't be seen. It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found. Every time I see this, my OCD kicks in and makes me try to move my diagram to show the hidden code, only to realize that LabVIEW is just messing with me...

Of course an image is worth 1024 words..

View All (5)

Hi,

Sometimes we have to check the execution of just a part of a long VI and I use to do is:

- set a breakpoint just before the part,

- run the VI,

- wait for the breakpoint,

- set highlight

- and follow the execution.

I believe that would be nice to set the highlight just like breakpoint clicking over the wire and, when the execution reaches it, show the execution.

View All (3)

The idea is quite simple to implement, I suppose.

Two main benefits:

1. allows you to know the exact size in pixels that the front panel will get at runtime, while the manual resizing of the FP occurs.
This feature should take in account VI's Windows Appearance options (Window has title bar, Show toolbar when running, ... etc). It helps you to set the FP size for the (different) screen on wich the program has to be run.

2. this feature can help you to set the BD size for the smaller screen on wich you know you'll have to edit the program.

Up to now you can only set a minimum FP size, and use it as a sort of "pixel size reference". However this is the internal net size of the panel, toolbars and title bar excluded, and the final setting is a bit tricky. You can also programmatically change the FP size, but this is of little use, if you don't want to risk that some control disappear out of the panel boundary.

The second benefit is only for those of you that use LV on different PC (Lab and laptop, for instance) like me... and, like me, hate having to scroll the BD for editing it :-). Usually I set the BD size to the maximum possible dimensions of the smallest screen I use.

Cheers

View All (3)

I wonder if newly created wire labels should inherit the wire color for better clarity. Labels on array wires (and other thick wire thingies, clusters, objects, etc) could go bold for the same reasons.

(Of course the programmer can later freely change these label text properties)

View All (3)

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.