LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Did you know you can make property nodes and invoke nodes smaller by not showing the names?

Well, forget you know, it's a terrible idea to hide that information! You lose the self-documentating nature of LabVIEW. I use this as a comparison for Call Library Function Nodes (CLFN) - by default, these are dropped on the block diagram without showing names. I propose that the default is to show names for CLFNs for the sake of documentation, and so you don't have to hover over each terminal to find the one you're looking for. The biggest perk is simply the name of the function on the banner of the node. YES, there is a tradeoff between BD real estate and documentation, but I think "Names" trumps space virtually all the time.

View All (7)

Multiple picture for Boolean button

I don't know if this idea posted before.

When I want to customize a Boolean button by adding picture to it I have only three options which are import picture to True, False and decal. My suggestion is to add more options from which the user can add true and false picture on the Boolean button without changing its original shape. Here an example:

Let us say that I want to customize the Start Test/Stop Test button by adding a picture on the button that represents the start state and another picture to represents the stop state. In order to do this I have to import the true picture as decal then take a print screen for the control, also I have to import the false picture as decal then take a print screen, then I have to import the two print screens for true and false state

It will be nice if it is possible to have an option to add multiple picture same as the multiple test option

Path Control Disable Text Entry

If I have a path control on my front panel for the user to interact with, I will always show the browse button. This button makes selecting a path easy from a user perspective, and from a developer I know that the path they selected has some level of validity. So for instance I know that the path they selected must exist and be a valid path otherwise Windows won't let them select it, and the value change won't be triggered for the control.

But the user can manually type in text into the path control, and when focus is taken off the value change event will take place. The problem with this is the path they entered might not be valid, or may contain characters my platform doesn't support.

I doubt a user will manually type in text in the control often, they will use it as an indicator showing the path they selected using the browse button, but on the off chance that they type somthing and it isn't valid, my code might crap out throwing errors.

I can add code to check for a valid path, and I can add code to check for illegal characters in the path, but I'd have to do this for every path control on every UI the user sees. I could also write an XControl for this with a decent amount of work and hopefully meet my needs, but it would be nice if this were a native feature.

So what I'm suggesting is that the path control have an option, possibly in the browse options dialog, which makes the interaction with the control, only available by using the Browse button. This would ensure that any value change event will be from the user picking a valid path with the browse button.

Under Web Services there is a conversion palette. One of the functions here is to convert LV Image data to a PNG stream. This is super useful when dealing with sending and receiving large amounts of PNG data over something like websockets. I've used this in places where a web page can control a VI, and the image of some front panel controls can be sent to the web page.

However only recently did I realize this function turns the image into a PNG stream that is completely uncompressed. This idea is to expose the Compression input to the VI. Here is just one example where I get the image of a control then represent it as a PNG. With no compression this file is over 64KB. With just the most minimum compression that drops to 3KB, and down to 2KB under the highest compression.

Many of us at some point have wondered "Why the heck is the default number of elements for Array To Cluster equal to nine?" No good explanation is forthcoming. My new question is "Why should there be a default setting?". I suggest that instead of defaulting to nine elements leading to some hidden bugs (I have at least 3 solutions involving this function), that the Array to Cluster function simply breaks the VI until a value is chosen. Some possibilities for discussion.

1) Pop up the dialog upon dropping the node? A bit Express-y

2) Double clicking the node should pop up the dialog? I'd like that.

3) A visual indication that the value has not been set? A few possibilities:

4) Make the value an editable text field along the lines of the comments here:

http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/2430/page/1#comments

If it is easy to do I say yes. Don't even start down the dynamic adaptation road, that is not going to happen any time soon.

My main point is that this function is not used very often by most of us which means that it is not worth a major overhaul, and it is all the more unlikely that we remember all of the hidden behavior. Therefore a simple tweak, breaking the code until a value is set makes sense. Making it easier to set the value is a nice bonus, but secondary.

Someday a better method will come along (cluster support for Coerce To Type?) and this function can be put out to pasture, until then I would suggest just a little tweak.

View All (1)

Once in a while NI updates a system VI (new features, fewer bugs, etc.) but retains the old one for compatibility. If we open an old VI containing any such VIs in a new LabVIEW version, we typically find a special marking on the icon (e.g. obs). It does not tell us directly what the newest version is and where to find it in the palettes.

(for example the context help for the obsolete 2012 riffle.vi does not mention the obsolence and opening the full help simply points to the newest help version (this might be an oversight, though. Some other obsolete VIs have appropriate help if I remember right)).

I suggest a "right-click...replace" option for such legacy VIs that directly point to the newest version so we don't need to endlessly search the palettes (well, I know where riffle.vi can be found, but I don't think the majority of LabVIEW programmers will find it on the first attempt, so this could be frustrating ;))

Idea Summary: I suggest to add a "Replace...with newest version" to the right-click menu of obsolete VIs.

Here's a picture how it could look like.

View All (2)

Rewrite MODBUS library

There have been numerous ideas on how to improve the for loop. Some people want more information. Some people want the option to have less. Some people want to be able to move the terminals or hide them altogether.

This suggestion should take care of some of these issues, and open the for loop for future expansion: Let the for loop data be exposed through a terminal block, similar to what event structures have:

This would be resizable in the same way that the event structure node is and would allow you to change the order of terminals. This would also allow NI to add additional loop data without worrying about cluttering the loop for those who don't want it.

Additionally, if NI implemented this idea, then we would also be able to hide this node entirely, which is useful in some cases.

Here are some relevant ideas which would be helped by this idea:

Allow multiple toolbar button rows

When a complex application uses deeply nested clusters to organize their application data, it can be difficult for others trying to extend/maintain that code if they are not intimitely familiar with the names and the datatypes of the elements within the data structure. Is that element a integer, enum, string, path, array, cluster, object?

The context help provided when hovering over wires and the color and texture of the wire on the diagram is very useful, but neither of these are available when you are attempting to select the correct element from the bundle/unbundle nodes.

I propose that the same datatype glyphs shown in the context help when hovering over wires should also be visible when attempting to select the correct element in the bundle/unbundle nodes.

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

Add Merge Errors on Loop Terminal

View All (6)

change a group of Constants

View All (1)

Currently, "build path" function has input "base path" set as recommended. This can cause issue when you accidentally do not wire this input. By default there is empty path, which is not really helpful and even if there was any case when you want to wire empty path to build path function, you can easily create constant. Therefore, it would be much more user friendly to have "base path" input of "build path" function set as required by default.

Key Navigation dialog

View All (4)

Recently I've talked to companies that are already using LabVIEW and their organization has standardized on tools such as JIRA for bug tracking/project tracking as part of an organization-wide initiative. JIRA connects to other IDEs/programming tools such as VisualStudio, Eclipse, IntelliJ, etc. Atlassian (the company that makes JIRA) also provides tools that can part of a larger Agile process and can facilitate code reviews and other software development processes.

The idea up for vote is to offer more comprehensive LabVIEW interoperability with industry standard tools such as JIRA, or other software as part of an internal software design process. (feel free to specify a certain tool, if you have a preference)

After applying my own subjective intellisense (see also ;)), I noticed that "replace array subset" is almost invariably followed by a calculation of the "index past replacement". Most of the time this index is kept in a shift register for efficient in-place algorithm implementations (see example at the bottom of the picture copied from here).

I suggest new additional output terminals for "replace array subset". The new output should be aligned with the corresponding index input and outputs the "index past replacement" value. This would eliminate the need for external calculation of this typically needed value and would also eliminate the need for "wire tunneling" as in the example in the bottom right. (sure we can wire around as in the top right examples, but this is one of the cases where I always hide the wire to keep things aligned with the shift register).

If course the idea needs to be extended for multidimensional arrays. I am sure if can be all made consistent and intuitive. There should be no performance impact, because the compiler can remove the extra code if the new output is not wired.

Several String functions have an "offset past ..." output (e.g. "search and replace string", "match pattern", etc.) and I suggest to re-use the same glyph on the icon.

Here is how it could look like (left) after implementing the idea. equivalent legacy code is shown on the right.

Idea Summary: "Replace array subset" should have new outputs, one for each index input, that provides the "index past replacement" position.

View All (1)

LabVIEW Idea Exchange

Show Names on Call Library Function Nodes

Include the LabVIEW Task Manager in LabVIEW

Multiple picture for Boolean button

Path Control Disable Text Entry

Add Compression Input to LV Image to PNG Data

Remove Default Behavior from Array To Cluster

Make the replacement of obsolete system VIs easier.

Rewrite MODBUS library

Use a terminal block to access the for loop's data

Allow multiple toolbar button rows

context help datatype glyphs in Bundle/Unbundle nodes

Hide .lvclass extension on property nodes

OPC UA deployment licenses should be version agnostic

Add Merge Errors on Loop Terminal

Change Output Representation on "Boolean to (0, 1)"

change a group of Constants

"Build path" function´s input terminal "base path" should be required

Key Navigation dialog

LabVIEW Interoperability with Industry Software for Managing Issues, Projects, and Code Reviews

Add "index past replacement" output(s) to "replace array subset".