LabVIEW Idea Exchange

Why is "Rearrange Cases" not an option for a Case Structure with two cases?  This page (http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/rearrange_cases_dialog_box/) indicates that you need at least three cases in order to summon the Rearrage Cases dialog box.  What if you just want to swap the order of two cases (For example: so that the default case is first or last).  Currently, I have to add a dummy case, rearrange, and then delete the dummy case.

Make the global variable icon double in size on the block diagram every time it is referenced by a VI in the project.

So this is OK!

This is not so good. Although this suggestion is semi-facetious it is an immediate indicator of poor coupling

Lots of Love

Steve Watts

I've been recently experiencing issues with memory running LabVIEW 32-bit under Windows XP 32-bit. One potential solution was to swap to LabVIEW 64-bit running under Windows 7 64-bit, but unfortunately I need either NI-CAN or NI-XNET driver support which isn't currently available. Luckily it looks like running the 32-bit application under Windows 7 64-bit overcomes the immediate problem but I worry that this involves compatability interfaces (not that I don't trust Microsoft of course).

LabVIEW 64-bit has been available now for approaching 4 years and it would be nice to see a full suite of modules for the 64-bit in line with the 32-bit version. Failing this a timeline of when they're likely to be delivered would be useful - the only answer at the moment seems to be don't know, which doesn't seem very professional!

Could I ask the LabVIEW R&D team to at least consider publishing a plan?

Need I say more?

I do a lot of math formula transposition from my written notes to LabVIEW where matrices or vectors are involved.

I usually try to use different index names for different dimensions and most of the time, the size of vectors or matrices are different, so having three nested loops with all sizes called "N" and all indices called "i" doesn't help with legibility.

It would be fine (somewhat) if one could add labels to the count and iteration terminals, but we can't. And labels on wires are not as visible.

And since a picture is worth 1,000 words:

The ability to view a cluster constant as icons on the blockdiagram (implemented after an idea posted here) is great! I use this for 99% of my cluster constants. But I have to first place/create the constant, then right click it and select "View As Icon". This is a bit tedious, espescially since greating a constant for a large cluster inside a structure will often mess with your layout via autogrow. I would like to have a checkbox in the LabVIEW options that controls the default behavior so I can make "View as Icon" the default. Just like the "Place Front Panel terminals as Icons" option.

Best Regards

David

The behavior of the Diagram Disable Structure is puzzling me a bit, and it seems somewhat inconsistent.

It seems primarily designed for testing alternative parts of code. At least one subdiagram must be enabled or the VI will be broken.
For this type of use DDS is easy to use: just go to the frame you want to enable, invoke the context menu and click "Enable this subdiagram." Simple and straightforward.

However, I wonder what the "Disable this subdiagram" menu item, that appears for all the already enabled subdiagrams, can be used for. Using it the VI becomes automatically broken.
This behavior is correct if there is at least one output tunnel. DDS cannot forecast which subdiagram I intend to enable, and since one have to be enabled to provide value(s) to its output tunnel(s), the VI cannot be executed. IMHO in this cases the "Disable this subdiagram" menu item, should be greyed out.

However, IMHO, another common use of the DDS is disabling part of a diagram momentarily useless, for testing purposes. For example the code for writing a big log file already tested, while debugging other parts of the VI. In this case, and in all cases where no wires at the DDS output are present, the VI can be safely executed even if all its subdiagrams are disabled. It would be great to have the possibility of directly enabling and disabling the front subdiagram. In this cases the DDS could even have just this subdiagram.



However, currently, to disable the (momentarily) useless code you must go to a blank frame and enable it. Why this convoluted path?

My proposal is:

when no output tunnels are present, the DDS could have all its subdiagram disabled, and the VI should stay runnable. To make clear this possibility, in this case only the "Disable This Subdiagram" context-menu item should be enabled.

Cheers.

Marco.

A simple Idea, though I'm not sure how simple it will be to execute.

Idea:

Make run-time environments (RTEs) backwards compatable.

Example:

Allow a LV2010 executable to run on a computer that only has the LV2012 RTE installed.

Benefit:

Saves hard drive space and install time. The LV RTEs are 600mb or so. Yes, hard drive space is far from being expensive, but it's annoying having to set through 5 installs just so you can run programs from 8.5, 2009, 2010, 2011, and 2012.

When you have a project explorer populated by many classes, it takes many clicks to find and get to the class node in the project.

What I frequently do is to create a class object (or control/indicator) from a class wire then right click >> Show Class Library...

But this step adds an unnecessary object to the BD.

What I want is the same "Show Class Library" shortcut menu from WIRE, VI Connector Pane, and Unbundle node so I can quickly access to the class library in the project tree.