From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

Post an idea

I did a search for "VI Hierarchy" and didn't turn up this idea. I sure hope it isn't a repeat.

If you have a polymorphic VI in your VI hierarchy, when you view the hierarchy, it seems like every single polymorphic instance of that VI shows up, as well. This doesn't help me at all, and I don't know why it works this way. I should only see the specific VI's I am using.

After dropping just one function (DAQmx Read [Analog DBL 1Chan 1Samp])

Now check out my VI hierarchy!

It's gone berserk! It is showing me every single flavor of DAQmx Read! Try this for your own amusement.

Why don't I see only one DAQmx Read function in this hierarchy? Or maybe someone can shed some light on why it SHOULD work this way. I definitely think it SHOULDN'T. The block diagram I posted above should not have a hierarchy like this!

Message Edited by Support on 07-30-2009 09:27 AM

View All (5)

This is similar to the idea about moving items in the connector pane and is an extension of it for any input or output on the block diagram -

Often, you connect a wire to a wrong input or output. Today, fixing it requires wiring to the new location and manually deleting the old piece of wire. The only exception is two-input functions with both inputs already wired, where you have a keyboard shortcut for swapping the wires.

A much more natural and general method would be this - if you use the wiring tool on a wire source or sink and then on another, the wires should be swapped (or if there's only one wire, it should be moved).

In this example I wired the 7 into the wrong input and I want to move it one input down, so I:

1. Click the top input. This "grabs" the wire, so to speak.

2. Click the bottom input. This moves the grabbed wire to that input.

Message Edited by Support on 10-22-2009 01:25 PM

There are examples of generic ASCII spreadsheet formats that used fixed-width fields and no delimiter. (see for example the XMAP section of XPLOR files for crystallographic electron density, blue part below).

ZYX
XMAP: section # 0 average density=-0.336 sigma= 0.907
0
-0.97086E+00-0.49927E+00-0.82774E+00-0.13491E+01-0.57034E+00-0.71253E-01
-0.19491E+00 0.61017E+00 0.10064E+01-0.22888E+01-0.94020E+00 0.77451E+00
0.57539E+00-0.31211E-01-0.27430E+00-0.36526E+00 0.34772E+00 0.81884E+00

-0.19954E+01-0.10117E+01 0.18038E+01 0.19008E+01 0.11886E+00-0.41646E+00
0.47560E-01 0.48855E+00 0.57606E+00-0.22320E+00-0.12787E+01 0.47590E+00

...

LabVIEW could easily deal with these sections (i.e. read and write!) using "%12.5e" as format string and an empty string as delimiter. For some reason, an empty string as delimiter does not work for "spreadsheet string to array" and "array to spreadsheet string". If I explicitly wire an empty string to the delimiter input, LabVIEW will silently substutite a tab instead. This is somewhat unexpected, a tab should only be substituted if the input is unwired.

IDEA: An explicit emtpy delimiter string input should be accepted verbatim.

Of course things can go horribly wrong if the field code is variable width, but we need to trust the programmer to be aware and deal with it.

(On a related note, there is still no format code to allow padding the exponent to two digits with zeroes as in the blue parts shown above, however, fortunately the files seem compatible even if I don't edit the exponent to match that pattern)

Message Edited by altenbach on 07-21-2009 12:02 PM

Here control means both controls and indicators.

When replacing a control, some properties of the replaced control are inherited by the new control, e.g., label, caption, etc. and some are not, the most critical for me being the SIZE property (and the POSITION which is not in the Properties dialog). So while property nodes, event cases, etc. which depend on the label are still intact after the replace, I still must fix SIZE and POSITION (and other properties) afterwards.

Idea: When replacing a control, the set of properties in the intersection of the old control and new should all be inherited by the new control. Thus when replacing a control with the same type, ALL properties would be inherited. The exception to this would of course be when replacing a control with one that is a strict type definition.

View All (4)

I find that there are WAY too many steps to setting up a custom button with up, down and hover graphics. And there is too little documentation on this subject as well. Here are the steps I have to use to build a simple button from 3 basic png files (for the 3 states):

• Drop System button on front panel

• Right click menu > Advanced > Customize button.

• From control editor, choose customize mode.

• From the right click menu on the button:

1. Import from File
2. Select normal button image.
3. Copy to Clipboard
4. Select third picture item
5. Import Picture From Clipboard.
6. Select second picture item
7. Import from File
8. Select ‘down’ button image.
9. Copy to Clipboard
10. Select fourth picture item
11. Import Picture From Clipboard.
12. Select sixth picture item
13. Import Picture From Clipboard.
14. Select fifth picture item
15. Import from File
16. Select ‘hover’ button image.

• Change back to edit mode.

• Save control.

There has to be a better way!

View All (4)

Currently, we have to use Unbundle By Name from Cluster and select an element for Case Section

It would be great if we could just wire the Cluster Directly and have a Right-Click Option at Case selector to select an element (one element only).

P.S. If it is a reasonable suggestion and gets enough Kudos to get R & D team’s attention for feasibility of this idea, then we ask for more logical operators support that would be useful. Also multiple elements and/or more statement node i.e. (type == Array and # elements <= 2)!!!

Only sometime I miss “if statement” support in LabVIEW.

Message Edited by Support on 07-16-2009 11:56 AM

View All (4)

When trying to make a complex GUI using the tree control, it is often desired to set specific colors and fonts to individual rows, columns and cells within the tree.

A good example of this is a test result dataset where you want to have a tree that has items for each test and sub items for each measurement within each test, then have an additional column that displays the result for each measurement with a colored background, like this:

Unfortunately the method 'Add Multiple Items to End' has a limited number of attributes you can set when adding a set of data:

The only solution is to add all your items and then loop through each item and set the required cell attributes individually:

Even with setting 'defer updates' on while doing this, the process is painstakingly slow for large datasets.

The solution would be to add an array of clusters element to the cluster in the 'add items' method that would allow the setting of these extended attributes of the tree. This way, the data could be processed in the assembly code much faster than setting each element in a for loop, as is required now.

This would make the tree control much more useful. This should not be hard to implement and should be easy to make backward compatible. It would just require expanding the datatype that stores the tree contents to include this extended data.

View All (4)

One of the annoyance of designing a UI is that you will never know for sure how it will look on another user computer.

For instance, you design your UI with the default 13 point font size and when a user that has it default font size set to say 16 (and with a different font type) open your UI everything is a mess (text run out of the screen, text overlay controls ...).

In built application (meaning in an exe) one can add the following line to the executable and this fix the problem by coercing the font type and size.

AppFont=""Tahoma" 13"
DialogFont="Tahoma" 13
SystemFont="Tahoma" 13
CurrentFont="Tahoma" 13

But what about a reusable tool that are basically a source code distribution?

Currently, the simplest way to ensure this outcome is to write a reusable VI that will recursively set the font size and type of every labels or string to be what you designed your UI to use. This VI has to be run by the UI every time it starts.

What I propose is to add a global VI settings (probably somewhere in the VI properties) that will persist whatever font settings was used to design the UI.

This setting should default to false.

The image above is one possible solution (the simplest one).

Another solution would be to explicitely defined what every font style&size should be for every font type (something very similar to the explicit definition one can use in an ini that I mentioned above). In that case, there could be an entirely new font category in the VI properties.

PJM

View All (5)

The palette file editor is in desperate need of a make-over !

It shouldbe possible to:

Add libraries/classes/projects to a palette and create a whole tree of menus automatically
Edit individual vi icons as well as palette menu icons
Rename (i.e. Save As...) a palette file and have the refering links renamed optionally (a bit like the save as for a vi dialog).
Exclude files and directories according to user defineably patterns when synchronising to disk
Copy/Paste palette entries rather than just move them

Probably some other things, but that's good enough for starters.

View All (2)

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed.

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂

This one of my very old ideas and goes all the way back to InfoLabVIEW. I recently got reminded in this thread to write it up as an idea. You might have heard it before. If not, read it :D)

Currently, an output tunnel gets the default value for the given datatype if "use default if unwired" is enabled and a case executes where it is not wired. Recently, we also got the "linked tunnels" feature, which is more like an editing assistant.

Many times we have a big stack of cases but the computation of many outputs is shared by many cases, maybe with one or two notable exceptions. 😉 It would be cool to be able to define this shared "default" code only once so it is executed unless we create an exception case.

My suggestion is to have a new, special case that allows us to define the output of each tunnel for cases where it does not receive an overwriting input.

The image shows a few possibilities for an event structure (same applies for all other relevant structures).

A: A reference is wired across by default. We don't need to wire across any other case.

B: Nothing is defined, so it acts like today. This is the default, so everything is automatically backwards compatible with existing code.

C: A number is incremented with each iteration unless we overwrite in a specific case

D: The default output is based on the operations of several inputs.

E: If a tunnels is unwired, we get NaN (or whatever we need) instead of zero. For I32 me might want -1, for example.

F: Same as A. This is similar (but not exactly the same) as linked tunnels. (I.e. It also applies to existing unwired cases)

G: This tunnel is defined in all cases. If we add an unwired case later it would act like B.

H: (not shown): certain global event terminals (e.g. time) should also be available in the "default definition case", because we might want to utilize it for a default output.

Downconversion would be somewhat messy. It would probably need to wire the relevant default operations into all cases where an output is not wired, keeping the functionalty the same.

Message Edited by altenbach on 07-11-2009 10:45 AM

View All (2)

View All (1)

I would love it if LabVIEW had logical constants, similar to what other languages have. Basically, a logical constant is similar to a variable (i.e. it's a value which is assigned a name), but its value is set at compile time. CONSTs help code readability.

In LabVIEW, a CONST would basically be similar to a global variable, with two differences:

1. It would be read only (so no race conditions, everyone can relax).

2. Changing the value on the front panel of the CONST VI will automatically require the user to save the VI, without needing to manually set the new value as the default.

Today, you can implement these in LabVIEW using all kinds of methods, but non of them is as convenient as this.

View All (4)

Here's a very fundamental User Interface concept that LabVIEW lacks:

When you press and hold an increment or decrement button on a numeric/ring/slider...etc..., the rate at which the value changes is constant: painfully slow. Typically, in other applications, button presses will increase the rate of change of the number proportional to the amount of time held, and if you hold it for 5 seconds or so that sucker is flying.

We want the same native behavior for increment/decrement buttons in LabVIEW, but we want it to be configurable. Consider a Property Node that defines a Lookup Table for the velocity profile of the increment:

The way the above code is read: For 0<t<1000, the control only moves at 1unit/sec. For 1000<t<3000, the control moves at 10units/sec. For 3000<t<5000, the control moves at 100units/sec. Another (more difficult?) way to define the velocity profile is to provide the velocity profile vs. time as a formula.

Of course, while the "typical" profile would start off slow and accelerate, I'm sure the ability to create unique accel/decel profiles would give incredible control for some awesome, one-of-a-kind User Interfaces.

(As a side note, if LabVIEW simply implements a fixed acceleration rate that was non-configurable, I will still be frustrated and still take the XControl route.)

I'm sure someone can think of a better, more intuitive implementation, but the concept remains:

For a press-and-hold on Increment/Decrement buttons, the control should increase its rate of change proportional to the amount of time it has been held, as defined by the programmer.

View All (4)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

The VI Hierarchy Window Should Only Show the Actual VI's in Use

Number to Boolean String

Use the wiring tool to swap inputs or outputs which have been wired incorrectly

Menu selections to clear history of recent files and/or projects

Allow empty string as spreadsheet delimiter.

Inherit Properties When Replacing Controls/Indicators

Resolve Load Conflicts Improvements

right click speed

Improve the control editor (especially for making custom buttons)

Cluster to Case Selection

Make "Disabled and Grayed" Usable

Tree Control method 'Add Multiple Items to End' should allow for greater customization to tree contents.

Persistent font Settings

Better Palette Set Editor

New build option: Service

A better way to define the output of unwired output tunnels

Replace/Insert/etc context menu should show palette for wire element type as well as Array Palette

Report generation toolkit for OpenOffice

Adding CONSTs to LabVIEW

Allow Increment and Decrement Buttons to have Adjustable Acceleration Rates