LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Suggestion: Correct the symbol of the "not" primitive function by removing the invert dot on the input node in the icon.

currently: source: http://zone.ni.com/reference/en-XX/help/371361H-01/glang/not/

That means in exact words of the LabVIEW design the following: negate and negate; first negate due to the invert dot at the input, then negate again due to the "not" function.

suggestion: That means negate (only once). See also http://en.wikipedia.org/wiki/Negation

IMHO, unless this is corrected, other ideas have no chance to be implemented consistently, such as: Negate input on boolean functions

Thank you for reading!

View All (1)

The Run Method is pretty much the only option we have in LabVIEW to scale an application dynamically by instantiating new VIs - but there is one big catch - for some reason it requires the unser interface to be idle(!).

Related methods like setting control values e.g. do not have this requirement so they do not pose a problem - but the main method for dynamic instantiation does - and can be blocked by something as simple as a user that opens the calendar view of a date and time control (which of course never should do this either, but that's another issue/idea).

Personally I use the run method to create new trend windows (you never know how many trends a user wants to see at the same time), create session handlers for remote clients etc. The times it is used to actually create user interfaces it is not a big problem that the run method is in the user interface thread, but for session handlers and other things that needs to be created in the background based on requests from the outside? A HUGE issue.

View All (2)

Add Match Regular Expression sub VI

The Match Regular Expression is worth it's weight in gold, once you get used to it. There is some functionality missing though:

1) The begin\end positions of the capturing groups are not available. These positions can be more useful than the matching strings.

2) It's unnecessary slow when the string results are not needed.

3) The results are output terminals, making it hard to adapt to dynamic inputs. A results array is sometimes more convenient. For example a pattern is entered in a GUI.

I use the attached VI (based on the same API) a lot, to bypass these limitations. I think it would be useful in the LabVIEW palette, under String>Advanced String Functions.

Match Regular Expression (VI Version).png

Control/indicator Dashboard

(not really related to this idea)

Deferring panel updates is a tedious procedure, requiring a panel reference (not intuitive to get!) and a couple of property nodes. However, deferring panel updates is sometimes very important. For example when coloring the fields of a large table according to their values, a serious performance impact is encountered unless we defer panel updates. There are many other situations where panel updates should be suspended temporarily, especially if property nodes are used in a tight loop.

My suggestions is to make flat sequences a little bit more useful by adding a new function to the right-click menu of each frame: "Defer Panel Updates". Now a new connector will appear on the frame that accepts a panel reference. If left unwired, this applies to the panel of the current VI, but we can wire a reference to any panel we desire (useful for subVIs). There should be a visual indication indicating that updates are deferred, e.g. a slightly different background pattern (e.g. faint checkerboard or similar). Note that this idea does not clutter the palettes with a new structure, but simply extends the functionality of existing elements. Let's put those sequences to some good use!

During execution of such a frame, the panel updates are deferred and automatically enabled again once the frame ends. The configuration should be "per frame" of a multi-frame flat sequence.

This has many advantages over the current situation:

It is immediately clear what part of the code executes during the deferral
The deferral is clearly delimited and it is not possible to accidentally forget to re-enable the updates

As an example, here is my subVI code to color the fields of a large correlation matrix (located on the main VI) according the respective value so we can easily pick out where correlations between fitting parameters are a problem.

TOP: current solution. BOTTOM: how it could look like with this idea implemented.

View All (6)

From my experience, it would be more useful for terminals on the connector pane to default to Required instead of Recommended.

Here's my thinking:

Usually You Want It - In general, when you create a SubVI you require all of the inputs, in which case it is a pain to go and change every terminal individually to required.
Conscience Programming - If you are creating inputs for your SubVI that are not required, chances are you are very conscience of this, have done it intentionally, and written code to handle that case where the terminal is not wired.
Easier Debugging - If Required terminals are not wired, VIs will be broken, i.e. you have compile errors instead of run-time errors. These are much easier to debug (especially when the errors appear on functions inside your SubVI that did not receive their required inputs). If in fact the terminal should not be required you are prompted to make that decision, instead of finding at run-time that your program does not work as expected.

I completely understand why we need these three categories. However, it seems that the usual use-case is and should be Required and therefore the default should refelct this.

Chris V

View All (8)

Orientation of Tab Text

View All (1)

I find myself often wanting to copy (to the clipboard) a VIs fully qualified name (i.e. including it's library and class prefixes), so that I can paste somewhere else, like in documentation, emails, code, etc. However, it's not possible to easily do this. I LOVE that I can copy a VI's path on disk to the clipboard from the VI Properties dialog, but it would be great if it were possible to also do this with the VI's fully qualified name (as shown in the screenshot below).

LLB Manager Improvements

The default widths of the LLB Manager window and the Name column in the multicolumn listbox are too narrow (see the attached picture). They should be widened considerably so VI names are completely visible without having to resize the Name column and LLB Manager window.
The multicolumn listbox displaying items should be replaced by a regular single column listbox since only one column in the multicolumn listbox is actually used. This would allow for listbox scaling due to window size changes to work much better. Currently, when you resize the LLB manager window, the multicolumn listbox resizes as expected, but the width of the Name column doesn't change accordingly, which means you often have to manually resize the column when resizing the window.
You should be able to select multiple items in the listbox, such as VIs, and open them by pressing the Enter key (like the behavior in Windows File Explorer). The only way to open multiple items from the multicolumn listbox currently is to select them and then right click on them and select Open in the shortcut menu.

View All (1)

The LabVIEW IDE may coerce diagram constants when the enumerated typedef changes. The problem is: the constants may occur in many places, and the coerced value is not necessarily helpful.

In the pictures below, the "Idle" element is removed from the typedef and the IDE coerces the diagram constant to a neighboring value "triggered".

Now the program behaves as if triggered.

When a diagram constant becomes invalid, wouldn't it be better to flag it as broken, so that the programmer is forced to handle the problem?

View All (1)

Stacked Plots improvements!

Its possible to stack plots using a WaveForm Chart:

You can also do it using Mixed Signal Graphs.

But the functionality is very restrictive. I propose these improvements:

Allow stacking plots on Waveform Graphs and XY Graphs also.
Allow users to modify the number of stacked plots at run-time. This is currently impossible. You need to pick the number of plots you want to stack during design-time. And then you are stuck with it at run-time. Though there are certainly plenty of clumsy attempted workarounds to this problem (e.g. see here). It would be great to have this function for run-time. Its very common in Biomedical data-acquisition applications to allow users to vizualize data in stacked plots (EEG for example), and its a pain to program this in a flexible manner using LabVIEW.

Run As SubVI method

In LabVIEW we can dynamically run a VI in a few ways:

a) If it's not running Top Level VI or if the VI re-entrant with the Run method.

b) Already running as sub VI, with Call By Reference.

c) Make a new VI and drop the (running) sub VI on the diagram.

Downside of a) is we can't always make sub VI's re-entrant, but still want to call it by reference. Downside of b) is we need to know the strict type (connector pane). Downside of c) is we might end up with a lot of VI's just to function as Top Level VI for the sub VI's and it doesn't work in executables.

I like to propose a method, so we can dynamically call a sub VI without knowing the strict type.

This is all I want.png

Using it, we enable LV to dynamically run sub VI's while setting\getting it's parameters by name.

For sub VI's (already running) this method will act as Top Level VI. For Top Level VI's it will fail unless it's idle.

(Please ignore my first confusing attempt)

Convert units icon

View All (1)

99% of the time when I use a Diagram Disable Structure, I am disabling code with an error cluster wired through. I don't want to lose the errors coming in, just the single operation, so I manually wire the error cluster through the empty case each time.

I've talked to others in the past about this and it would be nice for LabVIEW to be all-knowing and wire all datatypes through that match, but that would definitely lead to conflicts and mistakes. Error clusters, on the other hand, are simple are nearly always a single wire in and out.

Simply auto-wiring the error cluster input to the output would make the debugging process much easier.

Code with disabled operation:

View All (4)

Shared Variable Engine - Citadel

We are logging shared variables with the citadel database via the variable logging. In some cases (reset of PC ...) citadel makes a repair of the database after restart. When having databases greater than 20-30 GB this operation takes at least one hour. During this operation the Shared Variable Engine is not responding. When using the shared variables not only for logging purpose but also for controlling options and visualizations on that same pc this is very critical - this stops also the production for one hour.

It will be better to activate the Shared Variable Engine although during the repairing process of the database. We could pass on the data during the logging process but not on the controlling part of that aggregate.

Best Regards,

Joachim

How is NI-MAX still so bad after all these years? It goes completely unresponsive and crashes at the slightest provocation. This feels like it should be NI's bread-and-butter.

Every LabVIEW team ends up recreating so much of the functionality that NI-MAX is supposed to offer out of the box. Maybe with the discontinuation of NXG, some resources should be allocated to making this product usable.

KB articles like this and this probably shouldn't need to exist.

View All (3)

To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.

A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain www.labview.com and it needed to make a AJAX request to api.labview.com, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

For example, I'm starting an application and here's how I'd like it setup.

1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).

2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.

Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.

This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.

Panel Actors provide a very extensible UI tool. There is simply nothing better than panel actors to build composite UIs, but we are still limited in that we can only insert UI elements into existing sub-panels or new windows. What if there was a simple function called Create SubPanel.vi with inputs of size and position, and an output of the reference to the created subpanel? What if closing the subpanel reference removed it from the front panel. Now we could create an infinitely complex UI at runtime. It should be a simple matter to build special support for this into the runtime environment. (I actually have no idea how hard it would be)

Use case: an acquisition UI with pre-defined display elements (graphs, gauges, numeric boxes, etc, etc), all created as individual panel actors. The user asks for a new graph element display during runtime. We programmatically drop a subpanel and then spawn the requested graph actor into it. User wants it moved, and we can do that with mouse events. Same for resize. User wants it gone and we can do that too. User wants 10 elements or 10,000. We can do that with no problem. Give us this and we can create literally any UI of any complexity, fully configurable by the user.

LabVIEW Idea Exchange

Correct the "not" symbol by removing the invert dot in the icon

Run Method should not run in the user interface thread

Add Match Regular Expression sub VI

Control/indicator Dashboard

"Defer Panel Updates" within sequence frame so configured

Don't flatten icon layers when dragging from another VI

Connector Pane Terminals Default to Required instead of Recommended

Orientation of Tab Text

Report generation toolkit for OpenOffice

Fully Qualified VI Name (in VI Properties dialog) should be selectable with cursor for copy to clipboard

LLB Manager Improvements

Diagram constants changed by IDE when editing enumerated types

Stacked Plots improvements!

Run As SubVI method

Convert units icon

Auto-Wire Error Clusters Through Diagram Disable Structure

Shared Variable Engine - Citadel

Ground-up rewrite of NI-MAX so that it is actually usable

Add support for OPTIONS request to LabVIEW webservice

Easily create sub-panels during runtime