LabVIEW Idea Exchange

Since the Error Ring constant is read from  *--errors.txt files at LV startup and then ignored it is cubersome to add new error codes "while coding", you have to restart LV to get a refresh.

Please give us an option to re-read the contents of the errors.txt files from within LV, maybe from within the Error Ring popup dialog.

/LeifS

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

Current situation:

improved functionality:

A lot of Front panel controls have some nice abilities to limit the input of data with optional Maximum, Minimum and Increment values with different Coercion options available on each of these.  Of course these only apply to data entered by the user but I find myself often trying to re-create this input limit through a vast number of property nodes.  It would be really convenient if the control associated with these settings had a VI Server Invoke Node available which would perform this "Data entry" check and coercion when called.  This way we can better synchronise FP and non-FP data entry behaviour of front panel controls in certain situations.

This lovely property setting would be a prime candidate for a control "Invoke Node" via VI Server!

The method could have the option to automatically update the control with the coerced value and also output the coerced value together with a boolean informing whether a coerce took place or not.

Shane.

PS Now that I've posted the inage, I realise that the old value would have to be returned also.......

The menu ring is a handy control, but I prefer enums over plain integers for these types of control in most cases. Give us a menu ring with an enum format. (please! )

For development purpose I define in a "IMAQ image control" (typdef 'IMAQ Image.ctl) a default image.

The VI with a image as default value is very huge and not usable in a executable.

After development i would be useful if you could delete the default Value of the "IMAQ image control" by mouse as on array elements ->empty Array.

Renaming files with F2 or the context menue entry "rename" is easy - as long as the file is a LabView or NI-File. But if it is just a simple *.txt, *.pdf, ... file it is not possible. Please add this function! - thanks.

I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:

1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.

2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-control-of-VI-under-real-time-target-should-brows...

These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

• Changing VI connector panes
• Renaming or moving VIs on disk
• Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

I would like to use this pattern for launching an asynchronous VI:

The specific use case here is to run a specific subVI, but not have to wait for the subVI to complete (i.e. to launch a daemon-like VI).

There are a few advantages to this method:

1) The Static VI reference makes it very easy to open the VI that is being "launched" and make changes.

2) If I change the connector pane of the Asynch VI, the Asynchronous Call By Reference Node updates or indicates that I broke something (like a regular subVI would).
3) The Asynch VI is automatically included in deployed code (exe's, TestStand deployments), because of the Static VI Ref.

The main problem I have is that I can't determine at run time if the VI is already running or not.  That's because the Static VI Reference causes the Asych VI to be "Reserved for Execution" when my launcher VI runs, and always report "Running" for the Execution State.  In the case structure above, I can't take meaningful action based on the ExecState (like don't run if already running), because the returned value is always running.

This idea proposes that the Execution State property (or some new similar property) be expanded to truly tell us whether a VI is actually running or not (regardless of whether it is a subVI, or reserved for execution somewhere).  Since the "Run" button is capable of showing this difference, there ought to be a way to programmatically access that state information.

One of the fundamental idioms in LabVIEW is "never use a local variable when wiring directly from/to the control will suffice."  As many of us know, local variables break the dataflow paradigm and should only be used in cases that necessitates them.

No doubt there is much value to using references to front panel controls in architectures such as a QSM, however, I felt like I was commiting sacrilege every time I was forced to wire these references from local variable-like reference nodes while leave dangling controls hanging about. 

Every control has a reference to it under the hood, so why not have the ability to show a reference terminal on the control itself; this way we can start our reference wiring straight from the control itself. 

 Control Values

Control References

I suggest we show/hide the reference terminal using the same method Shared Variables show/hide the timestamp terminal

Hello all,

In the "Glyphs" tab of the VI icon editor, would it be useful to sort glyphs by the ones the developer uses the most?

(I feel like I'm going to get a whopping ten votes for this one, but I had to say it anyway.)

We all likely have glyphs we use all the time, and ones we never use in the "Glyphs" tab of the VI icon editor.  (Does anyone actually use the Wii Remote icons?  They look cool, but have such limited usability.)  I find it mildly frustrating to wade through all of the glyphs every time I go to create icons.  This is because I haven't memorized the sometimes unintuitive keywords.

Thanks for your consideration.

Mr. Jim

I often want to see if a while or for loop is running by watching the loop iterator. Now I have to stop the program, wire the loop iterator to the border of the loop, add a probe to the wire and run the program.

It would be great that I could right click the loop iterator and add a probe while a program is running.

When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.

For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!

I wasn't able to find this on the exchange, sorry if I missed it!

When deleting linked tunnels, any wires that are only passthroughs between the terminals (i.e. are not wired to anything not linked to it) should be automatically deleted.  This should work regardless of whether the input terminal or the output terminal is deleted.

When multiple output tunnels are linked to the same input tunnel and one is deleted, only the broken portion would be deleted (again unless the wire is connected to something other than another linked tunnel).

A use case for this is when you have a bunch of shift register passthroughs in a queued message handler and decide to combine them into a cluster.  An additional benefit of this is that the broken wires that would remain would point out the code that actually used the linked terminals and would thus likely need to be changed (i.e. wired up to bundle/unbundle by name).

add an "output" to the condition   (sorry for my bad english)

This would avoid overloading the Diagram

like this :

I propose to replace Max & Min for two elements, which we could resize like some array functions for 3, 4, 5,... elements when you know how many you have to compare.

I actually have 5 elements coming from a bundle, I have to do this

For as long as I've been using LabVIEW, I've often turned to the LabVIEW Help file (which is a compiled HTML file) and found very little help.  I'll search for something simple like "For Loop" and receive 500 (literally, try it for yourself) possible topics, including the Cohen-Coon Autotuning Method, Control in NI-DAQmx, Limit Specification VI, and so on.  These have nothing to do with For Loops.

I'm proposing that the LabVIEW Help be turned into something that is ACTUALLY helpful.  I'm not sure about the best way to do this.  I think that it should still be portable and shouldn't require any Internet access to use (as lots of us cannot access the Internet on our development machines).  I would really enjoy a tool that would allow me to search for something like "For Loop" and receive like 5 topics that all have to do with using a For Loop in LabVIEW.

Hi,

I'm struggling with finding out the proper case in my case structure. It would be nice if the cases could be sorted automatically. Even better would be if we could change the sorting style (asc or desc).

Additional feature could be that the list of cases presented below should react for typing something like IntelliSense. For example, having the list of cases open as on the screen shoot below, if I type first few letters of the case name it should dynamically, (while I'm typing) go to the first case matched. 

Current problem: unsorted long lists are difficult to search