LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Array function - corrections

View All (2)

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)

Allow multiple toolbar button rows

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:

Format Data to String for File

Who doesn't like dumping data to CSV files? But there is a few pain points unless your data is already a string array or the same data type.

The usual way I end up doing it is formatting data to a string, then concatenating it with a delimiter. Then have to figure out if its a new file and prefix the header string. (Its also annoying open file doesn't return an empty file flag (True if New, or Replaced, or Existing AND empty)).

Then you need to add a new column of data - now there is a problem of keeping format specifier strings and header strings in sync. And then you end up with a stray delimiter so your column headers end up offset from the columns... And your format string breaks if you don't get the format code in the right place. And the data you want to dump increases until you have over 60 columns and its a nightmare maintaining long format and header strings, concatenate strings etc!

Format Cluster to String.png

It would be nice to format a cluster to a string. Optionally include the header row. For a 1D array could take its name and append the index to it.

Named Format into String.png

View All (2)

The Preferred Execution System setting of a VI allows for more explicit developer control of a VI's thread allocation. Currently there is no way to quickly view which VIs have been configured for which execution system. Furthermore it's not easy to see what execution system a VI configured with 'same as caller' will run under.

This idea is to add an optional color coded representation of each execution system to the VI Hierarchy window. When enabled, each of the execution systems is highlighted with a certain color around VIs, and applied to the lines between VIs.

For VIs with an explicitly configured execution system, the color around the VI would be solid. For VIs set to 'same as caller', the color around the VI would match that of parent in the call chain, but have a different appearance (shaded diagonal colored lines in this example). For VIs which are 'same as caller', but called from multiple different execution systems, the color around the VI would be shaded black.

Full resolution example:

Spoiler

Adding this option would allow the developer to quickly view what execution systems have been configured, which ones are not is use, and potential call chains of each execution system.

View All (2)

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.

Silver Error Cluster Boolean

Rewrite MODBUS library

Read/Write Enum to TDMS Property

If you attempt to write an Enum to a TDMS Property the function will return error -68007. "This channel or property value contains a data type that is not recognized by this version of LabVIEW." Reading and writing Enums as Channel Data however works just fine.

There are a few work arounds for writing and reading TDMS properties as Enums, attached is one such example where we write the value as a string, then have to convert that back later. There is extra work involved because we need to generate an error if the string value doesn't exist in the enumeration provided.

This idea is to ad native Enum Reading/Writing to TDMS properties.

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)

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)

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.

Properly Insert "Delete from Array"

View All (4)

This is a small thing but it drives me nuts. Whenever I place a case on the diagram, I always need to move the case seletor up or down so it aligns with the source output that will be driving the case. But, the newly placed case always has the seletor right in the middle of the left side. This is also where the drag hover control (?) is located. I seem to at least 50% of the time grab this drag control when I want to grab the case seletor and move it. If the selector was just placed above or below the middle of the left side, this issue would go away. I suggest placing it 1/4 of the way from the top, since most of the time the source of the selector is above the midpoint of the case block (at least in my code). YMMV.

I know it is a nit, but it is low hanging fruit to fix and it is annoying.

View All (4)

I've been using block diagram cleanup extensively over the past year in an attempt to speed up my LabVIEW programming. I am definitely faster as a result of using the feature, but there are still some VIs that I have to arrange myself, because diagram cleanup's arrangement is unacceptable. So the feature still has a ways to go in making all my diagrams acceptably clean. It's my understanding that there are many more configuration options in diagram cleanup that could potentially be exposed to the user, but I think an easier way to conform diagram cleanup to my standards would be to point it at a folder of VIs that I have personally deemed "clean", and have diagram cleanup mimic the arrangement in those VIs when cleaning up other VIs.

As an example, I am ok with input tunnels into a case structure overlapping somewhat, if those tunnels are coming straight from subVI output terminals that are close together. Diagram cleanup insists on adding space between the tunnels so that they don't overlap, which results in unnecessarily crooked wires. Ideally, I would have VIs in my "clean" folder that have slightly overlapping tunnels, diagram cleanup would discover that I'm ok with this, and subsequent cleanups would allow this arrangement.

View All (3)

A couple of recent ideas regarding the VI Hierarchy window are good, but do not go far enough, in my opinion. I would like to see the VI Hierarchy window annotated with a lot more status information about VIs, including:

A glyph showing if Execution Highlighting is enabled
A run arrow on any VI that is running top level.
A path from the top level VI through any currently executing subVIs (the path may be forking as there may be multiple subVIs running in parallel)
That path would have temporary lines going to VIs that are invoked using the Call By Reference node (as opposed to reordering the hierarchy tree to put such VIs as subVIs of the caller)
A glyph showing any VIs that have breakpoints on them and a different glyph if the VI is actually stopped at a breakpoint.
Reentrant clones of VIs, so that call chains can actually be seen, including the ability to double click on a particular reentrant clone to open its front panel
Any other execution state information that can be easily expressed as glyphs and highlighted connections among VIs and/or other file types shown in the hierarchy window (open to brainstorming).
Whether debugging is enabled or disabled on each VI

The VI Hierarchy window has already been updated in LV 2009 and 2010 to show all the connections among different files and resources. Finishing it out to show the full state of the system would make it a powerful debugging tool.

View All (4)

LabVIEW Idea Exchange

Array function - corrections

Remove Default Behavior from Array To Cluster

Allow multiple toolbar button rows

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

Format Data to String for File

Visualize Preferred Execution System configuration in VI Hierarchy window

context help datatype glyphs in Bundle/Unbundle nodes

Rename the "Enqueue Element At Opposite End" Queue primitive as "Enqueue Element At The Front"

Silver Error Cluster Boolean

Rewrite MODBUS library

Read/Write Enum to TDMS Property

Make the replacement of obsolete system VIs easier.

Index Array by array of numbers or booleans

Search 1D Array Until Done - a New array function.

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

Path Control Disable Text Entry

Properly Insert "Delete from Array"

Place case selector anywhere other than the middle of the left case border

Tell Block Diagram Cleanup What "Clean" VIs Look Like

A VI Hierarchy window that shows full state of VIs in memory