LabVIEW Idea Exchange

Reading this or that, I think I'm not the only one to want XControl accept multiple data types.

One of my use case is an XControl using "XYGraph Data type" as Data. "XYGraph Data type" can be Cluster or Array of cluster.

I believe there are much more use case where polymorphic Xcontrol could be useful. 

It has been a few months since a suggestion has been made to do something about the For Loop, so if nothing else it is time to stir things up a little bit.  There have been several suggestions to do something with the iterators, for example:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p/1022771

None of these has really gained traction, and heck, I haven't settled on any of them myself.  In most cases I am satisfied with a workaround, usually involving the Ramp VI.

There is one case where I am not happy with the workaround.  I happen to need reverse iteration values quite often (N-1,N-2,...0).  With the N terminal pinned to the top-left corner I have little choice but to do the following and start zigging and zagging wires:

I would simply like a reverse iteration terminal which can be moved around at will and simply counts down.  Doesn't have to look like I have drawn it, that just happens to be intuitive to me.  Naturally this terminal (and the normal iteration terminal) should have the option to be hidden.

I thought about having the option to have the loop spin backwards, similar to reversing all auto-indexing inputs and having the iteration terminal count down, but I just could not decide what to do about auto-indexed outputs.  My G-instincts tell me that they should be built in the order of loop cycles, my C-instincts tell me I am building array[i] and if i goes in reverse order, so should the array elements.  For now I say, forget it, and just stick to the simple terminal.  Array reversal is essentially free, so I at least have a workaround there.

If I "create constant" from a path input, and start typing into the path, the control grows to the left, away from the function that accepts it as an input.

But for VISA and IVI, the name controls grow to the right as you type into them, covering up the icon of the function that accepts the input, along with the wire connecting them.  Let's make VISA and IVI behave better.

The "Coerce dots" are handled by LabVIEW as Visual warnings ... but a bad type coercion could have very bad issues ! 

It should be nice to be able to find all "Coerce dots" in all the VI's of a project, in order to check if they are critical or not.

[admin edit] This functionality is currently available with the VI Analyzer Toolkit (included with a LabVIEW Professional license or available for separate purchase). Specifically, you can run the Block Diagram > Performance > Coercion Dots test with the 'Block Diagram' option turned off, and the 'Single Wire' option turned on with a 'Maximum Number' of 0:

If you run the test with this configuration, it will return a failure for every coercion dot in the analyzed code.

Note: The idea will remain open, but we're mentioning the workaround here for the benefit of users who need this functionality today and find this Idea Exchange post via search.

My forum question asked here: http://forums.ni.com/t5/LabVIEW/Determine-and-Minimize-LabVIEW-Build-Dependencies/m-p/1441734 has prompted me to post a New Idea on this exchange.

    To summarize:  LabVIEW executables tend to be on the LARGE side especially when driver packages like DAQmx, VISA amd IMAQ are required.  I'm asking if NI could add some enhanced functionality to the Application/Executable Builder that assist the user in determining and minimizing the size of the final distribution package.  Ideally this would be a completely automatic function that would simply minimize the build parameters to the smallest possible set after analyzing the active project.  Additionally, it would be great if this would be smart enough to pare down the driver package itself to the bare minimum.  (I.E. It shouldn't require a 150MB DAQmx package size to read a few thermocouples with a 9211 module.)

    At the very least, the Additional Installers tab should show the size of the packages you're checking off and the resulting installer's total size.

An example of the size increases of required installer packages for a simple DAQmx application:

As we look at the Comparison Palette, there are three functions that offer negative logic, but fail to offer the positive logic alternative:

I commonly find myself placing a Boolean "not" right after these functions (e.g., if I want to know if there are elements in an array I must test if it is "not not empty", or if I want to know if a ref is valid I must test if it is "not not valid". Take a look at my other idea which illustrates not not logic.).

I have two proposed solutions: 1. offer a single function that has an "Invert?" option on the output, or 2. offer both the positive and negative logic primitives on the palette.

For the moment, the XControls can only be used one by one, on a front panel ...

It should be nice to be able to create XControls arrays ... in order to create "funky" listviews ...

=> Would give the ability to edit/view a collection of clusters, using an appropriate editor.

Manu.

I'm looking at a clone. I don't see why I would have to ctrl-M to get an editable version to do such things as:

- get the contextual menu up on the VI's icon to 'find all instances'

- get help on a VI that's on the clone's block diagram

- open or find all instances of a typedef via its contextual menu (the typedef being on the clone's front panel or back panel)

When designing a application, I sometime find that I am not happy with the name I choose for a class after I have already integrated the class into my project.

I also often use the class name for the label on in/out terminals and block diagram constants of the class.

The problem arises when I change the name of the class from within the project.  If I then go inspect the code, I find that the labels still have the old class name.

For example, if I rename the class from 'My original class name.lvclass' to 'My new class name.lvclass' I still see this on the block diagrams:

But what I want to see is this:

So, I propose a rule.  If a control or constant of a class has its label visible and that label (or part of that label) matches the original name of the class on disk (with or without the .lvclass extension), when the class is renamed in the project, the label on the control or constant is also changed to reflect the new name.

The reason I say 'or part of the label' is if you have added a prefix or suffix (like 'in' or 'out') to the label, it would still get updated.

I also think that this should apply to labels that include the '.lvclass' and ones that do not, as I often will use the class name without the extension when labeling classes.

I am happy to accept that this correction would only apply to code within the project where the class rename happens.  But it would be a bonus if there was a menu option to rerun the cleanup from a different project that might use the same renamed class.

Thanks in advance for the Kudos!

I think it would help the process of learning Quick Drop shortcuts if the Context Help window contained the shortcut for the item.

I know that I can define the shortcuts and that I can look at them from the Quick Drop dialog.