LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

The Probe Watch Window is a great addition to LabVIEW 2009 and I like that I have one centralized location to control all my probes.

What I don't like is that every newly created probe is embedded in the Probe Watch Window. There are various use cases where this is not desirable (see this discussion on LAVA for more info about it).

In the situation where you need the probe to be floating; instead of doing the following (for creating a new probe):

Right click on wire >> Probe (Or custom Probe)

You have to do the following (for every single new probe):

Right click on wire >> Probe (Or custom Probe)
Go to the Probe Watch Window and either:
- Click the "Open in New Window" Button
- Right Click "Open Window" Button

Basically this take twice as much effort as before.

I think that we need an ini setting (or a button in the probe watch window) to automatically float probes upon creation.

View All (1)

Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc. If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.

When developing for Windows in the past I have always edited my LabVIEW.ini file to include the following:

appFont="MS Sans Serif" 13
dialogFont="MS Sans Serif" 13
systemFont="MS Sans Serif" 13

And when deploying an application; I include these in the app's ini file also.

This seems to work for most windows targets since MS Sans Serif appears to be a common font. I suspect this will produce unpredictable results in OSX or Vista for that matter.

What I expect as a developer is not having to deal with these font issues. I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings. This means that the font information must be encoded and stored with the VI itself. I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities. This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar. I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc. Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.

Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries. It should just work. I hope we can all agree on this.

View All (5)

(This is a preemptive idea posting to make sure it is out there and does not get any significant votes.)

Don't vote for this!

(Now we will see who is paying attention :D)

The seasoned text programmer has problems adapting to LabVIEW because of dataflow. The concept where sections without data dependency can execute in any order really messes with the mind. We don't really want to think that way. It would be so much easier to do a literal translation of text based code to LabVIEW if we had a vertical stacked sequence!

Now order is restored, code executes "line" by "line", top to bottom, and all race conditions are eliminated. It also saves energy because we only use one CPU core at any given moment. Keep it green! 🙂 This structure is even Energy Star rated and might qualify for a rebate from your local utility!

Look at the picture! Now we have LabVIEW code that even a text programmer can understand. 😄

Look ma, no tunnels... no branched wires! 😮

Sounds good, right? Please discuss below and prove me wrong! (... and please remember the bold red text above!).

Did I mention that this is a bad idea? Oh, yes I did... In the title!

Create Bundle by name constant

The idea here is to have the option to create not just a constant when connecting to a property node or indicator, but instead to have an option to connect up a bundle by name with the constant connected to it. This would be invoked by the usual right click menu, but with extra options if a cluster is present. I'm not exactly sure how to handle the bundle or bundle by name, but as I am partial to the arrange horizontally arangement of a cluster, it might be nice to have the option to have the constant that is created be either horizontal or vertical, via different options in the selection menu.

View All (4)

Quirky Labels: Part 2

Observe the following behavior in this series of events:

1. A regular ol' cluster is created.

2. The labels are dragged with the mouse to the snap-to upper left hand corner.

3. Right click on the control, change to indicator.

4. Right click on the Array, uncheck "Visible Items > Index Display"

Things I do not like about the above process:

1. Between steps 1 and 2, the cluster gained 7 pixels in height!

2. Between steps 2 and 3, the numeric and enum end up with a label that's about to tip over and fall off the left edge.

3. Between steps 3 and 4, the array label lost all support, and is definitely about to fall.

Proposal: When components of a control or indicator are hidden or shown, or the size is changed, the position of the label is invalidated, and repositioned based on the new bounds of the object.

If you like this idea, please, go back and like this idea too: Quirky Labels: Part 1.

View All (5)

Local variables redesign

Compared to plain terminals and references (for example), local and global variables are too big. They waste way too much space on a bulky frame.

In my applications, local variables often come in large groups (e.g. if I need to write values from a file to a group of controls inside a case to load a different default set for the controls) and I tend to partially overlap the locals to save diagram space. I would prefer a more economical design, e.g. as shown on the right.

Globals could have that little globe (not shown).

I am not sure if we really need to encode read vs. write in the frame thickness like for terminals, but it could easily be done by making the frame of the "write" versions thinner (same outer dimensions). I think the little triangle is enough to show the direction.

Message Edited by altenbach on 08-15-2009 09:31 AM

View All (3)

wire jumping across case structure

View All (14)

View All (3)

View All (4)

View All (1)

Property "Eye dropper" tool

I would like a FP tool that is similar to the eye dropper except that it functions on a control's properties rather than color. Ctrl-click on a control to sample the properties (data range, default, representation, mechanical action, etc.) and click on a different control to change its properties. If the controls are different, the click is ignored. When one of the few tools we have is equivalent to right-click, I don't think we risk clutter by adding a few more.

Or, LV could allow some property changes (besides font) to multiple selected objects...

I have done it again! Every so often I get a VI running just the way I like it, save it (back it up as well), but when I go to use it the next time, all of my carefully chosen control values are gone. Having seen similar problems on the forum (in both questions and answers), I am not the only one. There is by default no keyboard shortcut to 'Make current values default', I have changed Ctrl-D (default) to do it so I usually go Ctrl-D Ctrl-S. (Ctrl-D is set to do something else, I forget what, but I never used that shortcut anyway). I suggest a modest change to the save dialog to add a little checkbox option (default unchecked) to 'Make current values default'. A gentle reminder the first time we save a VI.

I would like to see a setting on an lvlib or lvclass that would prevent private and/or protected items from showing up in the VI hierarchy.

In a .lvlib or .lvclass we can set different scopes on items, but why not add a property to define (on lvlib/lvclass level) which scopes that should be visible in the hierarchy view? The items listed as private in a lvlib (or lvclass), are mostly not necessary to see in the hierarchy window as these are internal anyway (and are not intended to be used or seen by the end user).

This change would mean that large scale projects could look much cleaner in the hierarchy window, and that the relationship between reuse components gets much clearer.

To make this work for older projects, I would also like the end user to be able to filter out private/protected items directly from the hierarchy window, as we today can filter out vi.lib, globals or controls. Turning on private view would still not reveal the items set as not-visible in the lvlib/lvclass, as this was defined by the developer.

View All (1)

When you have a lot of cases (or events) in your case (or event) structure it can be tedious to go back and forth between them (yes, Ctrl + Mouse wheel works great but can be hit and miss to get to the right one that is many cases away). Often times I am in one case, I need to grab/do/look at something in another case and then return to the case I am working on. It would be nice to have a Back and Forward button (similar to a web browser) so after I can quickly jump back to where I was. The only way to do it now is to click on the case titles, scroll up/down (which can be very tedious if you have enough cases that it goes off-screen) to switch between.

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:

All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.

I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):

Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:

Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

View All (4)

We (most of us) have come to find benefit in the Block Diagram cleanup - especially with the fresh upgrades that 2009 provides. How about a Front Panel Cleanup?

Our group has adopted the following standard (see below) in response to the otherwise neglected organization of SubVI front panels, and all of our SubVI's have this logical layout of FP objects.

So, here's the idea: have a button on the toolbar that "cleans up" a SubVI by organizing it into a "template" based on inputs and outputs as defined by the connector pane. If a FP object is not in the connector pane, place it in Local Data.

This idea could automatically be applied when using the Edit>Create SubVI menu item. The spirit of this idea resides in the fact that I think SubVI FP's should have a logical layout, and such a tool would reduce development time for this repetitive task that I perform on each SubVI I create. (Note that UI FP's do not conform to this standard!)

Please, vote on this idea based on it's merit and your ability to utilize such a tool, not on the template we use. If you like the idea but have a better template, post a picture! (You might even influence the way we make FP's!)

BEFORE FRONT PANEL CLEANUP:

AFTER FRONT PANEL CLEANUP:

View All (5)

Smaller Static References

Have you ever opened the VI Hierarchy window for a VI that calls many OpenG VIs?

If yes, you certainly wanted an option to exclude all OpenG VIs, didn't you?

The VI Hierarchy window has ONLY 3 exclusion settings (VI.lib, Globals and Type Defs), now that everyone can easily add it's own re-use code to the LabVIEW palette, we also need to be able exclude these VIs from the VI Hierarchy in order to see only the actual custom VIs called.

So please give me option to exclude user.lib!

.. And if I can even have others for Addons, instruments.lib and custom folder that would be lovely too, but user.lib is really a must!

View All (3)

I'd like to be able to switch the project explorer view to show actual VI/CTL icons instead of generic icons, very much like the function palette displays available methods.

The icon view should be possible to set for all items and/or only a subset of the project tree.

This would be very nice, since LabVIEW allows us to draw pictures that represents the code hidden in a VI, and a picture tells more than a thousand words...

/Jonas

Message Edited by Mellroth on 08-12-2009 12:59 PM

LabVIEW Idea Exchange

Add setting to automatically float new probes in LabVIEW 2009 Probe Watch Window.

Fix font behavior between windows versions, platforms & executables

VSS: Vertical Stacked Sequence (Bad idea, don't vote for it!!!)

Create Bundle by name constant

Quirky Labels: Part 2

Local variables redesign

wire jumping across case structure

Allow probes for strings to be resizeable and allow for the user to select the display format

Allow regular expressions to be used in Case structures selector label

Icon Editor "Icon Text tab" Usability improvement

Property "Eye dropper" tool

Add 'Make Current Values Default' option to Save dialog

lvlib/lvclass Access scope hierarchy filtering

Back and Forward buttons for Case and Event structures

Selection of Items on BD or FP needs to be Easier!

How about a Front Panel Cleanup?

Smaller Static References

Conditional terminal for individual frames of sequence structures

more exclusion settings for the VI Hierarchy

Actual icon to be shown in project viewer