LabVIEW Idea Exchange

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

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

This would avoid overloading the Diagram

like this :

Get contents of all XML Node Types:

As a beginner at XML parsing, it would be great if LabVIEW had a VI (like Get Node Text Content) but for every node type (it would get the contents, whatever they may be). 

All node types stated here:

http://www.w3schools.com/dom/dom_nodetype.asp

are possible and may require a different set of property/invoke nodes (some have children, some don't, some have values, some don't... and so on).

Inputs: Node handle

Outputs: Raw node contents (whatever XML is contained within the tags of the Node handle), Value (where applicable), Name (where applicable)

Write general string to XML node type:

It would also be great if there was a VI (or set of VI's) that could take an input (as a string) convert it to the w3 conformant XML.  It's important to use the w3 definition, rather than LabVIEW XML for external compatibility.

Inputs: Node handle, Node Type

Outputs: XML string of Node Type

The context menu for a file in the project window always contains the entry "properties" - but the dialog that stays behind is different between LabView-Files and non-LabView-Files. e.g. for a VI the VI property dialog opens, for a TXT-file the windows file-property opens. With other words: I can't open the windows file-property-dialog for LabView files.

I would suggest to have an menu entry "file properties" that opens always the windows file-property dialog. The current "property" entry can disappear for non-LabView files.

Remark: I'm using LV2011SP1

With using of

„\vi.lib\picture\bmp.llb\Read BMP File.vi”,

it is not possible to load a BMP file with negative height in BMP header. VI returns an error. Please update “Read BMP File.vi” to support complete BMP standard. Negative height in BMP header meaning that the bitmap is a "top-down" bitmap (the image data starting with the top pixel and end with the bottom pixel). Attached is one such image.

I'd like to have an option to allow resize X and Y separately.

Because I only want to allow Y resize, and not X, I need to program an event to detect X resize and restore the original size.
Users don't like it. The resize event is sometimes lost, when keeping the mouse down long, causing no restore to original size.

Right-Click to a single file in the LabView project folder (LV 2011SP1) opens the windows file property dialog.

Trying the same with several selected files or a folder (file view) does not work because the property entry is not there. Please also add it for multi-selections.

Alternatively (for my purposes) it would be sufficient to have the possibility to add or remove the read-only flag for all selected files or folders (and sub folders).

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 use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).

I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.

What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP.  As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.

Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example).  I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).

The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.

Although these controls are DISABLED (Not present in the source code)........

Here they are.....

This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.

Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.

Shane

It would be very useful that RT FIFOs could be of type lvclass as long as the class' private members are of static types (perform the same check that is done for clusters when you try to use them as the type for RT FIFOs).

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 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

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 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).

Hello,

LabView permits to import three different 3D file formats: VRML, STL and ASE.

So LabView can handle these file type, but is not possible to export any CAD format with LabView.

In example can not be exported to a CAD format simple x,y,z points generated by a mathematic process in LabView.

Next future will be possible to save CAD formats?

Pretty self explanatory subject. I would like the ability to open a VI directly from the QD dialog.

There is already a QD plugin that performs this action (Open from QD), however this seems like something that should be native to QD.

The Attached code calculates the square root free Cholesky factorization (LDL'), it is very useful to decompose matrices and in my specific case, to make observability analysis within electrical distribution networks. I'm publishing it because LV counts with other kind of decompositions like the LU decomposition, very useful but for my case, the values delivered by LDL' are more accurate and easier to calculate.

Best regards

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).

I would like to suggest having a "reverse bytes" option for each parameter within the Call Library Function.

There would be both "Reverse Before call" and "Reverse After call" options.

As the CLF's purpose is to interface two [potentially] different environments, it seems the correct place for a translation to occur, if needed.

Cheers!