LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

Hi,

I have come across various occassions where I would like an entire folder of VIs to be saved for previous.

In a situation where I have a project and a top-level VI, it is easy to do a save for previous. But there are situations where the folder contains VIs that are not directly linked to each other, and the save for previous version doesn't work for all of the VIs. Typically the VIs for such projects are also under the same folder.

So in the lines of Mass Compiling a folder, it would be nice to have a tool that does a Mass Downgrade (or Save for previous) for a particular folder, LLB etc.

Currently I do it by using a Save.For Previous API. If this is a situation that occurs for many folks, it would be a good idea to have this option available.

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.

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)

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)

DVR and IPE Structure Feature

View All (4)

View All (5)

The templates for XControl properties are quite simple, the standerd input and output controls and the boolean Value control. Nine out of ten times however I find myself doing the same action for every property I create, namely inserting a 'bundle by name' node between Display state in and out, selecting the correct element, change the Value control to the correct datatype and align and wire unbundle node to the value control for a write property and doing something similar with an unbundle for the read property.

Wouldn't it be nice to have the template already have the bundle/unbundle node already inserted and aligned?

Or, even better, wouldn't it be very nice if the "Create Property" dialog would optionally let us select an element from the Display State cluster and just create the code for us.. Look ma, no programming!

View All (2)

XControl classes

How about allowing the creation of XControl classes?

Families of XControl classes would allow the Publish / Subscribe paradigm I'm struggling with as discussed here: http://forums.ni.com/t5/LabVIEW/XControl-publish-subscribe/m-p/1568958

Being derived from a common ancestor client, XControls could be managed in a collection (array) and the publisher could call a common or overidden class method for each XControl client in the list.

XControl classes would also allow an elegant implementation of the Model View Controller paradigm used extensively by other object oriented languages.

You should also allow XControls to be members of an existing class. That way the XControl would gain access to the member variables of the class without resorting to cumbersome accessor vi's.

XControls sub-classes of a class should also be allowed, then methods in the parent could be overidden in the XControl. Mediator objects can then call class methods without caring if the instance is a XControl View, Model, Controller or some other object.

Phill

Congratulations everyone who inspired, design and implemented the new bookmarking and documentation feature of LabVIEW 2013. This is going to be hugely useful. And you’ve kept it so simple; we can all run with it! Thank you! However, I have 2 requests that (I think) will improve it further.

1. Make the “free label arrow heads” sit behind the free label. This would prevent the following issue.

Click “auto cleanup”

Arrow head covers the label.

I know that, since 2012, you can enable labels on wires... but this 2013 feature delivers a new way of documentation.

2. Please… please… please provide a shortcut for the bookmarking tool. I think the bookmarks deliver a great new way of quickly navigating large projects – as such, I would love to be able to toggle the bookmark viewer (on/off) just like I can with the context help window (ctrl + H).

This tweak would prevent me having to leave the bookmark window open, and then faff about with Windows own <ctrl + Tab> to get the job done.

I think these changes are minor… but impactful.

Genuinely though, thank you for implementing these exciting new features. LabVIEW 2013 – the greatest iteration yet!

View All (5)

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

I have noticed that Property Nodes for certain numerics do not properly store Range Properties as the native datatype of the control, but rather stores them as DBLs. I have attached the screenshot to illustrate my point:

Notice the first Numeric's datatype is a DBL, and therefore you see no coercion dots for the Range Properties or the Value Property. The bottom two examples show I32 numerics, which have the proper datatype for the Value Property, but have the wrong DBL datatype for the Range Properties.

I propose that the Range Properties should reflect the datatype of the Numeric, just as the Value Property does!

(This may affect other Property/Invoke Nodes besides Range... please list any other datatype inconsistencies you may find in the comments.)

View All (7)

XControl volatile state

It would be nice if XControls could maintain arbitrary state information akin to display state but was volatile and so not preserved when the XControl was saved and (importantly) did not set the VI modified flag when it was changed.

An XControl's display state is the natural place to store all state information about the XControl that you might want to access via property or method nodes as well as via user activity on the facade. However, anytime the State Changed ? flag is set in the facade, then container vi is marked as having unsaved changes. This is obviously sensible if the state change is meant to persist - e.g.. control resize, but not if the state change is volatile and can bee discarded after each run.

There are various alternative methods that can currently be employed, but they are not satisfactory:

1) Additional shift registers on the facade - are not available within property or methods

2) Storing volatile state data in LV2 style globals - unfortunately the same global is shared between instances of the XControl. This is still the best solution as the Container refnum can be used to generate a per-instance unique identifier to enable the global to manage the state data for all instances of the XControl.

3) Storing volatile state data in a 1 element queue. There are two problems - firstly some daemon process needs to be able to keep the queue reference alive but this adds complexity in making sure the dameon process shuts down cleanly. Secondly, there is still a problem of ensuring separate data storage between instances of the XControl.

4) Storing volatile state with the data. This works where the data type supports attributes I.e.. variants and waveforms but not for the general case.

5) Storing volatile data in a tag of the container refnum. This requires scripting and private methods and only works in the development environment.

A better solution would be an additional ability type def that is provided for volatile state, presented as a control/indicator pair for properties and methods and prepare to save, wired through on a shift register for the facade and presented as an indicator to init and as a control to uninit.

View All (2)

The one place I use Stacked Sequences is for setting up various parameters at the start of a vi. I usually have several frames, especially if the setup is complex, with each frame performing a different class of operations (reading from config files, checking for hardware, setting control appearances, etc.). And often, I find that multiple frames need to plug values into clusters at different points in the setup sequence. Sequence Locals for passing these clusters from frame to frame are terrible since wires have to backwards to come out of the locals, and the result is ugly and non-intuitive. So why not not have Shift registers, just like in loops. Much nicer. It might make Stacked Sequences more acceptable.

LabVIEW continues to evolve into a more optimized programming language through many under-the-hood compile optimizations, and LabVIEW 2010 brings the compilation improvements to a new level. However, these optimizations currently happen every time the user saves a VI or perfoms an undo. In the past, this would only take <1 second, but with LabVIEW 2010 there are several scenarios where each save of the same VI now takes 7 seconds, with reports of other VIs taking 15, 30 seconds or more.

SUGGESTION: Postpone compile optimizations until the user presses RUN, performs a build, or similar operation.

RATIONALE: Compiler optimzations are not necessary during edit time where a programmer is just saving their wiring progress, and anyway multiple edits can change the prior optimizations. The optimization of code is only necessary when the user is ready to run the VI in some fashion (in LabVIEW, in a build, etc.). At that time, the user is certainly happy to wait for the improved run-time performance.

I love this options "Change to array" and "Change to element" in the context menu. Additional idea:

I have a numeric constant with certain "Display Format" settings such as a hexadecimal appearance with leading zeros and visible radix:

When I turn this constant into an array using the function mentioned above the format settings get lost. Same behaviour vice versa as well.

It would be very nice if this settings would be retained.

Thanks for the good work!

Thomas

LabVIEW Idea Exchange

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

Mass Save for Previous Option (Mass Downgrade) similar to mass compile

Create Property or Invoke Nodes from Auto-indexed tunnels

Include Mathscript routines on LabVIEW palettes

Update the Bessel functions to allow for complex arguments

Block Diagram Cleanup should replace any Stacked Sequence Structure

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

DVR and IPE Structure Feature

Cancel during application or installer build that actually works

Improved XControl property read/write VIs (and maybe accessor support like classes)

Align input and output of Array To Cluster and Cluster To Array functions

XControl classes

Improving LabVIEW 2013 Bookmark and Documentation features

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

Maintain Consistent Datatype for Property Nodes on Numerics

XControl volatile state

Revert to old LabVIEW version naming

Shift registers for Stacked Sequence Structure

Postpone compiler optimizations until a run or build

Maintain "Display Format" Settings when changing to array