LabVIEW Idea Exchange

When working on a queued statemachine today, I realized its difficult to keep the wires straight. Usually you want one error wire going through your queue functions and into your subVIs but lining them up to keep the error wire straight often causes wires connected to the top connection terminal to get in each others way. If the queue functions icons were taller, this problem would be eliminated. See attached pictures

 

 

Populating the Tree Control with items takes very long time.  I suggest improving the performance of a tree control.  Many other applications have tree controls that are populated in a small amount of time, so it should be possible with LabVIEW.

 

I know of three ways to populate a tree control.  The first is to individually add items using the Add Item invoke method.  This method takes a very long time.  Adding 15,000 entries took over 180 seconds.

 

The second way is to use the"Add Multiple Items to End" invoke method.  This took over 20 seconds for 15,000 entries.

 

The third way is to programatically respond to the user expanding an item in the tree and populating only as necessary.  I assume that this is fast, but it seems like a lot of work to do every time a tree control is used that could have a lot of items. Maybe LabVIEW could improve performance by using the third approach internally for the programmer. 

 

Currently I am hesitant to use a tree control because of performance.  LabVIEW is a great product, and making the tree control perform better would improve LabVIEW even more.

 

Actualy when we select a cluster Bundle or Unbundle when you hit ctrl-f you get this find dialog:

  CTRL-F ->

 

What I want is to select the text in the cluster and get text Find dialog:

 

 CTRL-F ->¨

 

Plus... that should work for Property Node and Invoke Node

In addition to vision assistant script files (.scr) directly opening in vision assistant as suggested here, The icon can also be changed from this

 

 

to

 

 

 

Not neccasarily with the extention .scr as it will clash with windows screen saver. It can be .nscr or .niscr

I don't know if this has already been posted but I didn't see it when searching. I'd love to be able to search Vis in a project for text such as comments and see which VI it was found in. Often I will initial something I worked on, or leave tags to remember to go back and fix or modify something, but can't remember which VI I left it in. With text based languages this is obviously easy, you can just do a grep on linux or a search on windows. It would be nice to do with LabVIEW though. If there is already a way to do this, let me know cuz I could definitely use it!

If you have messy "future" or "obsolete but we are being risk-averse and keeping it around" code in the Disabled state of a Diagram Disable structure, VI Analyzer reports test failures for such code, in my opinion cluttering results.  It would be great to have an option, perhaps in the "Select Tests" page of the setup wizard, to ignore any such code.

I would like to see a feature where the size of the tree images can be set by the developer.

I want to swap sides for the scale on my Front Panel Tanks and DSC vessels like Pressurized Tank. 

 

This is very easy to do with a Waveform Chart or Graph but impossible with Tanks and Vessels unless you wire up some property node scheme to change the position of the scale, but then the indicator numbers are now between the vessel and the tick markers, making it a look a bit unnatural.

 

This would be very handy, especially for DSC processes where I'm trying to mimic process flow on the Front Panel and pipes could enter tanks from different sides.

When I am searching for occurrences of a particular items in my application, I often run into this issue: The search feature only allows you to search for text or a type of object, but not both.  If I need to find a particualr VI Server method call, I can either search for all invoke nodes (which returns WAY too many to sort through) or I can search for the text in the method name, and end up with results that have nothing to do with invoke nodes.

What we need here is the ability to specify multiple search criteria and logical operators to tie them together.  So, I could do a search for invoke nodes with the text 'Abort' in their name.  This would be a big help in large applications as well as those that use a lot of VI Server or .NET code. 

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

I would like to be able to make static event registrations for an element that is contained within an array. Note: this is not just a registration of an event that happens to the array, but an event that happens to an element in the array.

 

This can currently be achieved with dynamic event registration, but I would like static event registration for two reasons: less code, and dynamic event registration must occur with a FP showing whereas static event registration never errors (meaning dynamic events can pose a problem for plug-in architectures using SubPanels).

 

 Here's one specific example achieved with the current method of dynamic event registration. I have an array of a cluster that has two elements, but I only want to know when a user clicks on the Boolean.

 

I want to be able to statically register that same event, which would look something like this (in 8.6.1):

 

 

As a bonus, as part of the event data cluster on the left-hand side of the event structure, I would like an I32 array called "Index" that gives the multi-dimensional index of the item clicked.

In the Application Builder dialog under the icon category, you have the option to create an icon using the icon editor.  After you complete this and save it, you are brought back to the app builder dialog.  However you still have to select the icon file and add the .ico file to the project.  This should automatically be added when an icon file is saved from the icon editor.

For displaying the intensity profile at a specific X or Y line positions of a 2D intensity chart or graph (typcailly at the 2D's cursor location), a separate 1D graph can be used.  This graph's plot area is aligned with the 2D plot area along its side.  Setting this up requires coding, especially if the 2D chart/graph is resized since then the 1D graph has to be resized as well.   A nice visualization of this is at :

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-axis-swap-for-Waveform-charts-graphs-and-intensi...

 

It would be great if this capability were inherent in the 2D intensity chart and graph, enabled by R-Clicking > Show X Profile and Show Y Profile.

 

A chart can be used to display each channel of acquired data on its own separate plot area for comparison with a common time axis.  If the number of channels varies in a running program, the number of plot areas should be changed, perhaps by changing the Number of Legend Rows.  The number of plots in a stacked chart cannot be changed at run time however.  This issue is known to NI  but apparently is not an easy fix maybe due to memory allocation issues.  I am posting it here in hopes of showing enough interest to get this some attention.

 

http://forums.ni.com/ni/board/message?board.id=170&thread.id=296053&view=by_date_ascending&page=1

 

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

Allow the Select comparison function to accept an array as its S Select input.  This would allow the result of an array comparison to be followed by the Select function and if that array were then wired to one of the Select T or F, would allow each array element to then be replaced individually based on the separate boolean result.  One of the Select input (T/F) would be allowed to be a scalar so the array element could be replaced by that one value if desired.  This capability would provide an alternative to performing this operation with a For Loop and take up less diagram space.

 

Topic is discussed here.

If a polymorphic VI performs the same operation on 20 different data types, when browsing your user.lib (or other) palette, you'll have 21 different objects to choose from (unless you customize the palette). That's nonsense: only the main VI should be displayed.

Creating an LLB will solve the "single file" issue, but won't solve the confusion on the palette.

Customizing your palette can be a solution, but in case you're redistributing your VI/LLB, the user must customize it as well.

In the polymorphic VI window, the option "include source code" should be present: by doing so, main VI will become a container for polymorphic instances, and not only a link to them.

To edit polymorphic instances, user should double-click on correnspondent list item.

When compiling a Polymorphic VI with many members, it's kind of awkward to press the "Edit Name" button each time, fill in the values, click OK, select the next member, repeat & rinse.

 

Why not allow direct text entry into the table shown in the picture instead of having to jump trough some loops?

 

 

 

Shane.

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.