LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Create smaller banner for libraries

Create a public bug-tracking dashboard

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

reported
monitored
voted
...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...

Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

View All (1)

The Edit Events dialog has seen a number of improvements, but it is still very cumbersome to use when adding events for a newly added control. It requires too much effort to find the control in the Event Sources list. This problem can be easily and quickly addressed simply by reordering the controls section of the Event Sources tree in a more intelligent manner. There are two key problems:

1. The controls in the Event Sources tree are listed in the order they are added to the VI front panel. So the most recently added control is at the bottom of the list. Consider the following scenario, which is very common: You are editing a VI dialog that already has many controls. You want to add a new control and configure events for that control. Doing so requires scrolling all the way to the bottom of the Event Sources list to find the control. This is the exact opposite of the desired organization. The newest controls should be at the top, because they are the most likely ones that you will be configuring events for!

2. Clusters are expanded by default in the Event Sources tree. This bloats the list and makes it difficult to find the controls you really care about. When searching through the controls list, the first thing I have to do is collapse the clusters to filter down the list. But then next time I open the dialog, they are expanded again! It is relatively rare that a user wants to configure events for controls contained within a cluster. Generally the cluster controls are error inputs and outputs, or hidden off-screen clusters containing configuration data. They don't generally require event handling. Obviously there are some use-cases for it, but I think that it is appropriate to have clusters collapsed by default. It is not hard to expand them when searching specifically for a control within a cluster.

So my proposal is simple and straightforward, and would greatly increase most developers' efficiency when creating VI front panels requiring events. Sort the controls in the Event Sources list with the newest controls at the top instead of the bottom, and collapse all cluster controls in the tree by default.

Putting a comment next to a shift register item is something that I frequently do, and is frequently done in NI sample code. (See Quadrature Decoder with Position & Velocity - NI 9505 (FPGA).vi as an example of this.) The trouble is that when you move the shift register, the label doesn't go with it. I would like a right-click option to add a label to a shift register. The label should have a default position on the inside of the loop above the shift register, but options to locate it on the left or right, and inside or outside the loop. It should also be able to be moved around like any label in labVIEW. But is should stay in the same relative position to the shift register when the shift register is moved. And if a labeled shift register is duplilcated, the label should also duplicate with an added extension number to make them distinct, just like duplicating a control or indicator.

View All (5)

In many spectral monitoring applications such as vibration spectrum, electrical power spectrum and other frequency analysis, it is standard practice to label peaks in the FFT graphic. To do this in LabVIEW, we use cursors and cursor labels to point out specific frequency of interest. However, LabVIEW does not allow the fonts and rotation of cursor labels to be adjusted either manually or programatically.

It is common practice to use a cursor marker on the peak of the FFT frequency, with its label in a vertical orientation. Here is a common peak labeling practice used in most all vibration spectral applications:

It is painful to create work around such as programatically relocating cursors, writing text on graphs, etc. Is it possible to add at least the rotate cursor name property to LabVIEW?

Here are some other posts I have seen in the discussion forum related to this topic.

Rotate Text on Cursor

http://forums.ni.com/ni/board/message?board.id=170&message.id=242378&query.id=1281596#M242378

Move the name of the cursor

http://forums.ni.com/ni/board/message?board.id=170&message.id=45856&query.id=1282652#M45856

Change the Text Font:

http://forums.ni.com/ni/board/message?board.id=170&message.id=406465&query.id=1282652#M406465

I look forward to comments and feedback.

Preston

View All (3)

Make Edit Values table longer

I use .ini files for alot of my configuration setups and like to add comments after the key value for future reference and clarity.

The problem is that if you write to the .ini file, all comments formatting (i.e. white space) is removed resulting in a .ini file that looks like a bomb has gone off in it.

Below is a snapshot of before and after the write for clarity:

Ive spoken to tech support and they confirmed that due to the nature of how the VIs are written this is the default behaviour. For clarity and full understanding I have included their response below:

I've been looking through the source code for the config file vi's and I've found where the tabs are disappearing. During the open config file function, the existing keys are parsed. This includes trimming any whitespace, which is why all your neatly aligned columns with tabs are disappearing, in the general case.

This can be overcome by modifying the file. The config files are all found in <LabVIEW>/vi.lib/Utility/config.llb/NI_LVConfig.lvlib.

In this library you will need to modify "Parse Key Value Pair.vi". Remove the "trim whitespace" function in the false case, which is currently removing whitespace before the comment. This will lead to all the whitespace remaining.

However, this will only work for keys which are not edited. When you write a key, this all changes. At the low level, the "Add Key.vi" is doing the formatting of the key. In here, you can see in the true>true>true case that there is space added between value and comment, which simply reformats the key to have 4 space characters before the comment. You could change this space constant to tab constant (maybe just have 3 of them), which would preserve most of what you are intending to keep. It will be slightly subject to the length of text affecting the tab alignment. If you need to sort this, you could use a bit of code which reads the string length and decides how many tabs to insert.

This method will work, however it is laborious and time consuming. For me personally it would be a great addition if there were a boolean control that allowed me to set whether to preserve the original formatting or not (True by default). You could even argue that there is no need to have the option to turn it on/off, simply preserve the original format by default then edit the original document after if you so wish.

Any comments or thoughts on this would be appreciated.

Regards

Mitch

In LV 2011, an asynchronous Call By Reference feature was added to LV. This feature added a new node called the Wait on Asynchronous Call node. This new node has a timeout that is configured way way of a right click menu option.

It would be nice if the timeout was specified by way of a normal input that can be wired. This has several advantages:

The timeout can be specified at run time
The timeout value can be visible on the diagram without right clicking and showing a dialog
The timeout would be more discoverable by users

Copy and Paste-Replace

This is just an idea I had while working on a simple application. I often find myself wanting to replace multiple objects on a block diagram in a repititive manner. As an example, I have an application that uses a queue requiring an enumerated value as an input - when I started the application I didn't use a type definition, but I (of course) quickly arrived at a point where I needed to replace all of my constants with a type definition.

Right now I have a few options:

1) Delete the type definition and drop a new one down and wire it up

2) Right-click and select 'replace' and point it to the ctl file

both of which take a considerable amount of time to do over and over again.

Here's my idea... I create the type definition once, and press CTRL+C while it's highlighted on the block diagram. Then I select one (or multiple) items that I want to replace with this type definition and when I press CTRL+P it automatically replaces and wires the item in the copy buffer.

It's hard to illustrate, but I just wanted to throw it out there to see if anyone likes the idea.

View All (4)

View All (5)

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:

scrollbar in case structure list

View All (2)

Event Timeout Terminal (Event Structure)

Say I've dropped two 2D array controls on my block diagram, and would like to change both of their appearances in the same way. I can select each one at a time, right click and head to Visible Items > Index Display. However, it would be nice to be able to select multiple items of the same type and have the option of applying the same change to all of them.

Currently, selecting both and right clicking lets me change the following:

It would be nice if LV could recognise that I've selected two identical controls and offer me the option of changing the display settings for each of them:

Expanding this, you could use the same approach for BD constants, such as setting multiple string constants to '\' code display, or disabling size to text.

View All (1)

spent half a day today figuring out how to get my icon that was created in LabView's icon editor over to the icon editor in the Application builder. After much trial and error the only method I found was to select and copy the pixels to the clipboard while in the LabView icon editor, then run the Application builder and open its icon editor and then paste the contents of the clipboard into it. Some pixels change colors when doing this. Why doesn't the LabView icon editor allow one to save an icon in the .ico format that the Application icon editor requires? Seems logical to keep the same icon for your compiled app instead of having to create a new one in the App Builder. It would be even better if the Application Builder would just automatically load the icon from the startup VI by default, but allow the icon to be changed in Application Builder icon editor if desired.