LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I suggest that NI clearly mark those functions in IMAQ that require a run-time license. Perhaps color their icons pink or some noticeable color. There is a lot of misinformation in NI technical support regarding this issue. I wasted a lot of time developing an IMAQ program and found out later that it required a run-time license that my client did not want to buy. So, I had to rework the code to eliminate those functions that require a run-time license.

admin note: Invalid link has been removed.

Inserting snippets to a diagram is easy. We just drag it from an explorer window. Nothing wrong with that. 🙂

However, there are scenarios where this is not the optimal way to do it. For example if the diagram is maximised to the screen or the entire screen is already filled with many windows.

I suggest a new menu entry for the block diagram:

"Edit...Import snippet from file"

When selected, it would simply open a file dialog with png files as pattern where we can select the desired snippet to be placed on the block diagram.

A possible alternative would be for the "Function palette...Select a VI" mechanism to also include "*.png" in the pattern so we can pick and place a snippet like a plain VI. What do you think? It would function similarly to a shell (merge) VI.

(Now, what should happen if it is just a plain PNG file or in the wrong version? It would simply import it as a picture, same as with any other image. This will allow us to easily recreate the code from the image if it is a snippet in the wrong version.)

Did I miss something obvious?

Support Undo in Project Explorer

The very first time that you save a new project, the file dialog defaults to the My Documents directory (on Windows; similar on other platforms). While it is sometimes a good idea to put all the user docuements in the My Documents folder, my company uses a different approach where the currently active projects are in a distinctive folder on a seperate encrypted volume. It would be nice if we could set the configuration file of LabVIEW to start there instead of in MyDocuments. For all other file types, when you save them for the first time, ... ... if you are working outside of a project, the file dialog would also default to the specified location. ... if you ware working inside of a project, the file dialog would default to the directory where the project file is saved. This is similar to the behavior that exists today for items inside libraries -- the file dialog defaults to the same directory as the library.

This is one of those penny-saved-is-a-penny-earned things. In this case the penny is a few seconds of my time.

When I stub a method in a parent class and require all descendants to override the parent, I don't actually want to override the parent, I just want to implement the method in the ancestors.

There are two ways I can do this:

Create a new VI for override, delete the Call Parent Method, create a new case structure, enlarge the working area, and then start coding.
Create a new dynamic dispatch VI and then save the VI with the correct name.

I'd like LabVIEW to recognize that I've checked "Require descendant classes to override this dynamic dispatch VI" and not checked "Require overrides of this dynamic dispatch VI to always invoke the Call Parent Method node" and give me an additional check box in the New VI for Override dialog to use the dynamic dispatch template instead of the override template.

My new way of doing this would be:

Create a new VI for override and place a check mark in the box.

View All (2)

Does anyone else find having to create code to customise a listbox or table symbol a little frustrating? If I want to insert a number of custom symbols into a listbox I have to create code to load images and programmatically alter the embedded symbols, run the VI, then delete the code. But what if the listbox is already a part of a large VI? It's not always so easy to insert the necessary code for this one-time execution.

I would like to see a tool to enable customisation of the listbox and table symbols. A tool that can be launched easily, such as from the right-click menu, with some of the useful features of the new Icon Editor such as access to a list of Glyphs, and perhaps the ability to build a database of project-related symbols that can be pasted as a block into controls, perhaps by dragging and dropping from the LabVIEW project tree.

There currently exists a Right-Click-Framework tool that gives us something close to this, but it would be nice to have something built into the LabVIEW Developement Environment.

Existing Method: example code snippet for programmatically customising symbols (painful)

Right-Click-Framework: the Symbols Wizard, a plugin for the Right-Click-Framework, for managing custom symbols

View All (2)

Save us from ourselves

Can you venture a guess what's wrong with this diagram?

Well, you could, but there's no way you can be guaranteed to guess all of the problems.

The answer is that N3 will show the value of X+Y (not X*Y, since there's an add primitive under there which you can't see) and that N4 will show the value of Y.

The problem here is that LV allows us to let things overlap. This is great if you want to write obfuscated code, but has no practical use in the real world. So my idea - BREAK THE VI if nodes, wires or tunnels overlap "too much" *. Today, LV already gives you a warning for some of these, but most people don't have warnings turned on and don't look at them.

While having overlapping objects does not directly affect whether the VI can execute or not, and while I do realize that this is an extreme change in behavior, it is enough of a source of potential bugs that I feel this change is warranted. Maybe NI has some info about how much something like this would be useful or annoy users.

* No, I don't know what "too much" is and I normally don't overlap things myself, but it can happen accidentally and I do get code from other people which does have this to a degree.

I think it would speed up BD development/modification time if it were possible maintain BD wiring as you drag and drop nodes/terminals/constants/sub vis etc. across structure boundaries.

A simple example is that if you have a correctly wired Terminal inside a Case Structure and you drag and drop that Terminal outside of the structure, the wire becomes broken. In my opinion; most of the time you are then required to wire the Terminal back up to the original place through the boundary. This is not so bad if it is just a single wire but for sub vis with multiple connections it is a hassle.

If LabVIEW automatically re-created the wires and associated tunnels during the drag and drop operation, it would save me alot of time.

Not sure if this functionality is something you would want on all of the time, maybe something that is switched on when required.

Apologies to the original author if this is a duplicate suggestion.

Steve

I would like to see the functionality of the TCP and UDP primitives expanded to include more state information, better control of the connections and the capability to receive events for the connection.

Items that I can see which would be helpful would include the following:

Ability to enable/disable the Nagling algorithm.
Ability to abort a TCP connection with a TCP-RST. (The wire is there on the TCP-Close primitive but it doesn't do anything)
Ability to receive an event when data is present.
Ability to receive an event when the data has actually be put on the wire. (Currently the write VIs return as soon as the data is buffered. There is no ability to have the application wait until the data is actually delivered.)
More access to the IOCTLs that are available on a socket connection that a programmer has access to via Linux or Windows socket libraries.

View All (3)

We've all probably either written our own on-screen keyboard VI, or downloaded the various OpenG or other available freebies. I've got my own well-worn VI's for this purpose, but have spent some time and aggravation remodeling them as OS's and user tastes change over time. They are also not 100% consistent across platforms.

I think a set of touchpanel controls should be native to LabVIEW for consistency and ease of upgrade. NI could get a lot of marketing mileage out of improving LabVIEW as an HMI development platform by offering a set (and not just for purchasers of NI's touchpanel module). If I'm clueless and these exist somewhere already, let me know.

View All (1)

Set Font on Dialog Box

The built in dialog boxes (such as one button dialog) in LabVIEW are set to the 13pt dialog font. It would be very handy to be able to set the font size, bold, color, etc. for a dialog box. Some of my applications need a pop-up that is easier to read, so I have to make a custom dialog box in order to change the font size.

View All (2)

Often I need to know if a user selected a tool in graph palette, but there is no event for it.

I can handle mouse click events, but when user selects one of the zoom tools, the popup that shows zoom tools doesn't generate mouse click events for the graph at all.

I guess the popup is not considered to be a part of the graph or it is rendered outside the graphs boundaries.

So there is no way to register the fact that user selected one of the zoom tools other then poll for it in a loop. No good. I don't like doing that. 😞

View All (4)

When designing large applications it is normal that the top level VI will spawn background tasks to perform specific tasks. It would be nice if the top level VI could receive an event when the subVI exits. I realize this is possible if you specifically add code to the subVI to post a message to a queue or fire off a user defined event. However, it would be nice if the event were available without the need to add code to the subVI. This would make it easier to design top level applications that could spawn tasks and not palce any additional coding requiements on the subVI. The "Panel Close" event can be used with callback however it will only trigger when the subVI exits via the Window Close button (X in the upper right corner). This is too restrictive and will not allow the top level VI o be informed the subtask exited programmically.

View All (4)

Every control or indicator in LV has got a label and a caption.

If I understand the purpose of those two items correctly, the label is used as some kind of unique and (at runtime) unchangeable identifier, while the caption is a text to display on the front panel, change at runtime etc.

I don't understand, why it's possible to have several controls with identical labels.

I agree that it would be kind of hard to force labels to suddenly be unique (it might even break some code), so I would like to have an option to do this.

In the VI settings there should be the option "force unique labels for controls & indicators".

The default for new VIs should be set in a global option "force unique labels for controls & indicators for new VIs".

For existing VIs this option should be set to false, so we don't break any existing code.

When this setting is changed from false to true, LV should check if there are any duplicate labels on the diagramm.

If there are any duplicate labels, LV should show a message to inform the user that hitting the OK button now will change some of his labels.

If there aren't any duplicates, the change should be applied without any further notice.

You ask yourself, why I don't like duplicate labels?

They lead to VIs that are very hard to debug if you are using property/invoke nodes.

They lead to even more problems if you are using property/invoke nodes to access controls using their labels.

It just doesn't feel right to have two elements with the same name. That's a bit like having two variables with the same name but different content in other programming languages.

Sub VI without Front Panel

In most of the cases, front panel is not use for a subVI, but it always disturbs me be opening too many windows. So, there should be a new kind of VI that only have a block diagram. Terminals could be designated on the block diagram.

帖子被Qizhen在 02-09-2010 11:13 AM

时编辑过了

A lot of times I generate 1D arrays in each iteration of a for loop. Rather than concatenating the arrays inside the for loop I use and indexed output tunnel which gives me a 2D array. Using the Reshape Array function this can be reshaped into a 1D array essentially concatenating the 1D arrays together.

My problem is that the "dimension size 0" input of the Reshape Array function is required. I suggest that if this input is not wired to simply interpret the n-dim array as a 1D array.

Interestingly enough in the context help for Reshape Array "dimension size 0" is not shown in bold so it should not be required.

Have you ever had a cluster or control where you needed a user-friendly appearance on your main VI or dialog VIs but desired a more functional appearance on your subVIs? Traditionally, you might create a Type Definition and customize each instance. However, if you make a cosmetic change, you have to do it to all instances individually. Or, worse, if you make a data type change (e.g. add a new Boolean to your cluster), then all instances reset to match the new CTL file appearance *Ouch*. Or, to avoid this, maybe you created a Strict Type Definition, and lived with dysfunction on your subVI panels.

This idea would allow you to:

- Give a Windows dialog look to strict type def instances on UI panels while providing a more functional look (e.g. showing all controls organized logically) for subVIs
- Show / hide certain controls for certain use-cases
- Appease those end users (who usually also want everything simultaneously visible on the panel) that demand a certain SIZE for controls and indicators that is not useful for subVI I/O.

Why not store multiple representations in your Strict Type Definition CTL file? Then, open any parent VI panel, right click the border of the strictly type defined cluster, and select from the named representations you've previously created!

See below: Imagine taking your laptop to the customer site and not having to scroll around looking for your error clusters!

UI Representation

VI with Functional Representation

Message Edited by LabBEAN on 07-03-2009 11:36 AM

Message Edited by Support on 07-09-2009 10:26 AM

View All (14)

The argument is similar to what falkpl suggested here. The issue is refactoring old (pre event structure) code.

Many times I had the need to convert a multi-case case structure to an event structure where each event case duplicates one of the original cases. This is currently hard to do and involves a lot of copying and wire mending.

Of course the conversion cannot do any event assignments so things will be broken, but for me it would be sufficient to create the new event structure as a 1:1 "event-case":"plain-case" conversion of the code contents, without any events assigned. (This must be trivial in terms of code!) Assigning the events later is easy.

For symmetry, the reverse operation ("replace event structure with case structure") should also be available.

LabVIEW Idea Exchange

Please clearly mark the IMAQ functions that require a Run-Time License to work.

Insert snippet from file via menu entry

Support Undo in Project Explorer

Improve the file dialog default path when saving new files

Option in New Override VI Dialog to use the Dynamic Dispatch Template Instead of Override Template

A tool for managing custom control symbols

Save us from ourselves

Maintain wiring when dragging an object through a structure boundary

Provide more TCP/UDP related information

Touchpanel Control Suite with Native LabVIEW On-screen Keyboard and Keypad

Set Font on Dialog Box

Generate event on Selecting a tool in graph palette.

Add an event that would fire when a spawned subVI exits

Option to force unique labels on controls and indicators

Sub VI without Front Panel

Allow "Reshape Array" to reshape n-dim array to 1D array without wiring "dimension size 0"

Menu selections to clear history of recent files and/or projects

Independence from Strict Type Definition without Representations

Convert case structure to event structure and vice versa

Add Antialias support in picture control