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

Wiring an enum to the selector of a case structure.is a very common activity. You facilitate this by having a function in the right click menu called "Add Case for Every Value", which is a nice feature I use frequently. Very often for enums, however, the contents of case statements is very similar between cases. Maybe one or two things are different between each case.

I propose you add a function that copies the contents (including the wire connection ports) of the selected case to other cases or all cases. If this were available, a base set of code could be made in one case and transferred to others and then modified as needed.

Thanks for listening!

The current error-case only allows two states, when the error-cluster is wired: "No error" or "Error".

My suggestion is, to allow any number of cases which depends on manually defined error-codes (see attached picture). The error-case must be enhanced so that error codes can be treated separately in individial cases.

Previously to handle a specific error code, first the code must be read from the error cluster and than be wired to the case. This is to be omitted.

View All (9)

View All (2)

If you bring up the contextual menu on a control, you can go to the Find menu item and search for things related to that item. Like, if there is at least one local variable, you can find local variables for that control by picking Local Variables.

This also works for finding the control's presence on the other side (front panel vs back panel), and Property Nodes and References and perhaps some other things. But, it doesn't let you find event handlers for that control.

It woud be very nice to be able to find the control's event handlers through this submenu.

Good day,

I often use the tab controls to get more front panel real estate for applications where many parameters have to be accesible rapidly. I use the tab control to group my controls according to their fonctionnality. It would be desirable to have the controls from each tabs available as a single cluster in order to pass them to subVI. Of course, the controls from each tab can be grouped using a cluster on the front panel but this leeds to an extra border on each tab (the cluster border). Also, it remains that if one wants to pass all parameters to subVIs, he has to pass the many clusters to the subVI or bundle the clusters to one new cluster then pass this cluster to the subVI. I thought of using a tab control in a cluster but it seems that clusters have a problem dealing with tab control.

My idea would be to have a cluster type which looks and works like a tab control, but instead, each tab would be a sub-cluster of the Tabbed cluster.

This would simplify the development of complex parameter intensive user interfaces and remove lots of control terminals in the block diagram.

Thanks for giving some attention to this idea!

Michel Lanthier

Hi.

If you build the same executable multiple times, the EXE file is always different between each build. (using FC /B on the command-line for comparison)

We have been requested by a customer to prove him he could build the executable himself and get the same executable as the one we built for him.

That's currently impossible.

We opened a service request with one of your engineers and that was the conclusion.

Please provide us a way to compare executables.

Thanks in advance, and best regards.

Quite often I wish to display or hide one control based on the value of another on my GUI, or switch some other property of a control. Also often I use arrays of clusters to handily provide multiple identical control sets- e.g. where I need an identical set of controls for each of a number of I/O channels. This is a very neat way of reproducing the control sets and it's easy to deal with the resulting array on the block diagram. The problem comes when I want to select different properties on the controls on each channel- at the moment I have to either split the cluster array into separate clusters for display (a lot of work, and more messy code) or work around it in another less than satisfactory manor (e.g. hidden tabs to control visibility).

So the suggestion is- allow arrays to have 'pre element' properties, so I can have the advantages of an array of controls with the flexibility to set the properties of each element individually.

I realise there are memory and performance implications here, so there would need to be a special kind of array or an array setting to designate an array as such.

I have often the case, that i have to switch different projects with different LabVIEW Versions.

2 bad things may happen.

- My VI is loaded with a previous LV Version and I see an error message. But it won't load my VI

- My VI is loaded with a more recent LV Version and the VI will be loaded BUT saved in this more recent version.

It will be great to have a tool, like a LabVIEW Launcher, which recognizes the VI Version, or to offer a Tool similar to TestStand Version Selector to set it manually.

I have often the case, that i have to switch different projects with different LabVIEW Versions.

2 bad things may happen.

- my VI is loaded with a previous LV Version and I see an error message. But it won't load my VI

- my VI is loaded with a more recent LV Version and the VI will be loaded BUT saved in this more recent version.

It will be great to have a tool, like a LabVIEW Launcher, which recognizes the VI Version, or to offer a Tool similar to TestStand Version Selector to set it manually.

Download All

I find myself going throught the same mouse stokes over and over to make sure I don't leave DVR IPE errors unhandled. Lots of Merge Errors everywhere. It seems unessecarily tedious. My suggestion would be to do one or more of the following

1. An error terminal on the front of the De-ref and Ref icons that performs a merge error

2. A conditional error terminal that halts execution of the whole IPE for incomming errors

3. A conditonal DVR terminal on the De-ref that does not execute the IPE if a 1556 Error is thrown by the incoming DVR. Also would just pass one 1556 error out of the IPE since they are always both thrown with a bad DVR.

View All (1)

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

Add "Copy Case Contents To" right click menu

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

Unbundle should allow an array of clusters

Optimized Error-Case with error-code separated cases

Include A Python Script Node

Data connectivity toolkit for 64-bit LabVIEW

Default Wire Labels

Ability to move cluster elements

Contextual menu's Find submenu on controls should include event handlers

Tabbed cluster

Provide a way to compare executables produced by the AppBuilder

Arrays with per element properties

Super Strict Type Def

Overlap Structures

Automatic Line Labels

LabVIEW Version Selector

LabVIEW Version Selector

Error Terminal Options on DVR IPE Ref/De-ref

Resizing the Window shows size

Replace Color Box constant with U32 Vice versa