LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Fix XControls

Ok I'm going to try again.

I've already posted ideas on XControls before HERE and HERE but here's another try.

My feeling is that XControls COULD be a wonderful addition to the LabVIEW universe. However....

1. XControls are kind of weird. The implementation is kind of unusual and I finf the help available being not overly helpful. I HAVE implemented XControls but I find myself having to re-scratch my head every time I take on such a proposal. I would love a more intuitive way to work with XControls. Even a state diagram showing what's called when would help.

2. XControls are buggy. I've reported on these before but NI seems to not take this seriously. There are two issues which make XControls unusable for me (I'm willing to overlook the complexity).

2a. Synchronicity. Updating a value to an XControl terminal will return control to the calling code IMMEDIATELY event hough the XControl may require some time to process tha data. This is completely inconsistent with existing LabVIEW behaviour.

2b. Dynamic events don't work properly with XControls. If I register for a dynamic event in an XControl, firing the event will not "awaken" the XControl but the events will queue up until a valid event DOES happen at which point all the backlogged events get processed in a hurry.

If points 2a and 2sb w2ere addresses, 99% of my problems would go away but at the moment, XControls are just not worth the effort for most applications I could otherwise use them for.

Come on NI, you can do better.

Shane.

Scenario: I have a section of code that has missing subVIs and controls (they're typedefs), and I want to disable it. I put a diagram disable structure around the code, and it means that the missing VIs are okay, but LabVIEW still requires the typedef'd controls to be loaded <- this causes a broken arrow, even through the only broken code is within the diagram disable structure.

Fix: If the only reference to a typedef control is within the disabled case of a diagram disabled structure, then it should be ignored (and therefore should have to be loaded).

This one is really getting to me lately. I have already admitted to being a Right-Click-ohalic, but I am also a script-ohalic and sometimes XML-ohalic. I have many situations where I have an array of references which I need to iterate over. Should be very simple, wire the array to a for loop and add the appropriate property or invoke node. Creating property or invoke nodes from a right-click menu is very efficient, you get the list for whatever reference type you clicked on. For some reason, auto-indexed tunnels in for loops do not allow you to Create Property for ... or Create Method for... If you manually wire a property or invoke node to the tunnel you get the proper class so it shouldn't be too hard to skip that step and create the property/method by right-clicking the tunnel.

When the dialog box opens up and you want to select the Value Changed event for any control, it always requires scrolling down the 'Events' list. It would be easier if I could make the window bigger once, and have that dialog open up in the bigger size every time I opened it up. The 'Value Changed' event is the event used far more than any other event.

Since everybody's screen resolution is different, I recommend not making this dialog bigger, but making it resizable by the user, so that each user can set it to his preferred size. LabVIEW should remember the size it was set to the last time it was used and continue to use that window size on all subsequent openings of that dialog.

Present style dialog (Value Change event requires scrolling)

Resized Dialog (All events visible, especially the oft-used 'Value Change' event)

If you write a multi-purpose sub-VI, it is sometimes desirable to know during run-time, if an input of the sub-VI is connected to some source inside the calling VI or not. E.g. if you have two inputs and you want to do a certain action whichs depends on which input is connected, you have to write a polymorphic VI. Therefore you have to write at least 3 VIs: one VI for each input and the polymorphic VI. With a new control property or method, which tells you if the input got it's data from some source, you could do this with just one VI. There are of course other scenarios where this new feature could be useful.

Regards,

Marc

View All (3)

labview ini keys overview

A note from an NI-AE made me think: Why is there no list of LabVIEW ini file keys available, provided by the maker of the software?

So I propose the idea(s):

- NI should make a list of ini file keys with their usage. They may hide the "most secret" parts, but should keep the list up-to-date. There also should be given the LabVIEW version the key works on...

- NI could provide an INI file editor for the LabVIEW.ini file, similar to opening the page "about:config" in MozillaFirefox. The could even pop up the warning like FireFox does when opening that page...

The "Separate compiled code from source file" option is super nice for use with revision control software. However, sometimes the option to do so is not available:

This is usually because you have an express VI included somewhere in that VI's hierarchy. It would be nice to offer a means of displaying what those "conflicts" are--maybe a button to display a separate dialog, or to launch the search function with results of all the included Express VIs or any other potential conflicts. LabVIEW must know what those conflicts are--that's how it knows when to gray out the above option! So, how about a more detailed response as to why it has done so!

View All (3)

There are a number of very useful Mathscript routines which are not available in the LabVIEW Math or Analysis libraries. I would like them to be made available on the LabVIEW palettes as well. Those I can think of are:

Contour - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctions\contours
Delaunay - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctions\delaunay
Convex Hull - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctionSupport\geometry
Polygon Area - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctionSupport\geometry
Interpolate 2D for Scattered Data - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctions\intrp2d_uneven
Complex Bessel - vi.lib\imath\engines\lvmath2\RunTimeEngine\BuiltInFunctions\bessel_[hijky]

Some even already have nice looking icons

Are there more?

The current set of Bessel functions supplied in LabVIEW Core only allow for real arguments and outputs. This limits the usefulness of LabVIEW in certain areas of science where complex Bessel functions are required for calculations (i.e.. acoustic modeling). The Mathscript RT module has Bessel function calls that support complex arguments so it's not like the coding doesn't exist. This is one area where LabVIEW is deficient as compared to Mathematica and Matlab and can be easily corrected without forcing the user to buy the Mathscript RT Module.

View All (5)

Maybe this is a personal problem but I do this all the time and It frustrates me every time.

Edit an icon go to hit OK a little too fast and catch the cancel by mistake, all my hard work GONE. Yes this is only a loss of a few minutes but time is money. Do this 1 out of 50 times I edit an icon, ant it happens a few times a week.

Can we move the cancel button away from the OK or can we add an optional confirm on unsaved changes to the icon so I dont loose my work every time I make this mistake.

I know that I am fresh on these forums, and have only used LabView professionally the last half year, but nothing like this came up when searching, so perhaps it is is an idea worth mentioning:

Currently in labview: If we want to create a control from the terminal of a subvi or function we now have to left click -> create -> control. This action in itself require several seconds and very often a misclick produces an indicator or constant instead. (move mouse, select it, delete it, back to the terminal, left click, create, control)

My idea: Double clicking a terminal has today no useful action linked to it - so my idea is that when double clicking an input terminal a linked control will be created, and when double clicking an output terminal a linked indicator will be created.

Crtl + double click could create a constant: linked when clicking on a input, floating when clicking an output.

Ctrl+double click could also create a floating constant when used on wires 😉

conditional shift register

Conditional Error Ring

This idea came about from a discussion at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Require-LabVIEW-R-amp-D-response-to-any-idea-over-N-kudos/idi-p/2228468

The idea is to give LabVIEW users some say in which ideas are implemented. The key components of the idea are:

1) Set aside 5% of NI’s R&D staff to work on the “people’s choice” LabVIEW idea. That’s over 100 R&D staff, so a lot can be done.

2) Take LabVIEW ideas with kudos of 200 or more (there are 39 unimplemented ideas with 200 or more kudos).

3) Put together a poll of these 39 ideas and ask LabVIEW users to vote for their favourite.

4) Keep the poll open for 2 weeks and at the end of the period, take the idea with the most votes and implement it.

5) Once the idea is in beta, another "people's choice" poll is conducted and the process repeated. (Small ideas get implemented quickly, bigger ideas presumably are worth the wait.)

The 5% R&D staff, 200 kudos, etc figures can be played with to get the desired result.

I think we'll get more smiles on our faces from the 5% of R&D staff working on the "people's choice" project than we'll get from the 95% working on the "marketing's choice" projects.

View All (3)

DVR and IPE Structure Feature

View All (4)

View All (5)

LabVIEW Idea Exchange

Fix XControls

Putting a disable structure around a typedef front panel node on the block diagram shouldn't require the typedef to be loaded

Allow user to select the which NIC to use for network connections when multiple NICs are present

Implement More than 14 User Ideas in the Next Version of Labview

Create Property or Invoke Nodes from Auto-indexed tunnels

Resizable dialog box for 'Add Event Case...' and 'Edit Events Handled by this Case'

New property of Method to indicate, if an input of a sub-VI is connected to some source inside the calling VI

Save as and "open additional copy" - Close original VI

Expose "Call Chain" as VI Property

labview ini keys overview

Show "Conflicts" if a VI cannot separate compiled code from source File

Include Mathscript routines on LabVIEW palettes

Update the Bessel functions to allow for complex arguments

Optional "confirm" on icon editor cancel

Double clicking a terminal will add the control or indicator

conditional shift register

Conditional Error Ring

People’s Choice LabVIEW Idea Implementation

DVR and IPE Structure Feature

Cancel during application or installer build that actually works