LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

When I was developing an option I thought it would be good if we have an option of hiding the close button instead of simply hiding. Since even when we hide the close button the tip strip is still available. I am proposing this idea after searching the forum.

Option for hiding the Close, Minimize and Maximize buttons.

Once this option is enabled the other option releated to the windows will get disabled.

So the window finally looks like this.

It would be good if it gets appreciated.

View All (1)

View All (3)

INTRODUCTION

Dealing with arrays that are passed by reference (using control RefNums) to a SubVI has much more utility if it is NOT necessary to extract a local copy of the array in order to play with it. In additiion, there are some properties missing from arrays and clusters that would make it much easier to write code, and which seem to be consistent with other objects' property offerings.

Note: All proposed properties are IN ADDITION to existing properties. The behavior of existing properties is NOT changed.

NEW PROPERTIES

The following is a list of the proposed new properties:

NEW ARRAY PROPERTIES

ArraySize

ElemIndex

ElemRef

ElemRefs[]

NEW CLUSTER PROPERTIES

ControlLabels[]

DISCUSSION

Array Sizing

CURRENT: If you pass an array reference to a SubVI and want to know the size of the array, you need the wire the array "Value" property to the reference (which allocates space

and creates a local copy of the array) so that you can then wire the array to ArraySize to find the number of elements in the array.

PROPOSED: I propose a new array property "ArraySize" to return the number of elements in the array. This would have identical functionality as ArraySize.vi, but would be implemented

as a property where it can be used with array RefNums.

Deriving References to Array Elements

CURRENT: If you want to traverse an array and generate a list of references to all elements in the array, you have to first set the "NumCols" and "NumRows" to 1, and then use IndexVals

(to set which element is indexed) followed by "ArrElem" to actually get the reference.

PROPOSED: It'd be a lot sweeter if two more properties were added to arrays; the first would (obviously!) be an index function that is NOT related to the visibility properties of the array (as is

"IndexVals"). Let's call this new property "ElemIndex". Of course, in order not to break existing code, you cannot let the "ElemIndex" property cause damage to programs that currently

use "IndexVals", so we also need a new property (let's call this one "ElemRef") that returns the reference to the element in place of "ArrElem".

Obtaining References to Multiple Array Elements

CURRENT: Currently the "ArrElem" property returns a reference to a single element. it would be nice to get an array of references to elements in an array in the same manner as you can get

an array of references to all controls in a cluster using the cluster "Controls[]" property.

PROPOSED: So let's create another array property called "ElemRefs[]" that returns an array containing a reference to each element in the array.

Identifying Cluster Members Obtained Using "Controls[]"

CURRENT: The "Controls[]" property of clusters suffers from the problem that you have to know the order of elements in the cluster if you are looking for a specific cluster member. If you write

code using "Controls[]" then you are dependent on the order of elements in the cluster. When the cluster is a strictly typed control, this defeats the advantages of strict typing. The

effect is that when you change the type definition of a strictly typed cluster so that either (1) the order of elements change, or (2) you insert or delete an element, you have to rewrite

code that used the "Controls[]" property if that code needed to identify specific cluster elements and not just process all elements identically.

PROPOSED: A new property, "ControlLabels[]", alleviates this problem and adds significant utility to clusters, especially those strictly typed. The ControlLabels[] property when added to clusters

allows the references returned by the "Controls[]" property to be matched to a specific cluster element using that cluster element's label. The ControlLabels[] array returned would

be the labels of all cluster elements in the same order as the references returned by the "Controls[]" property (which is in the same order you see with "Reorder Controls in Cluster") .

This means that code written for a type defined cluster will still work if the type definition is modified either in the order of controls in the cluster, or if new elements are added or deleted

(so long as the deleted element wasn't one that was handled specifically in the code!).

View All (4)

View All (1)

FTP Improvement

I would like to suggest that NI add some needed functionality to the FTP VI's that it ships with. As you can see in this thread: http://forums.ni.com/t5/LabVIEW/Access-FTP-with-whitespaces-in-dir-names/m-p/3097215#M886371 the FTP LIST command does not work well for some FTP servers when the directory being listed has spaces in its name. The FTP MLSD command does work in this case, but there are other servers which don't support MLSD. My post on the above thread implements a fairly crude mechanism for using whichever command does work. But more importantly, the MLSD isn't even included in the NI FTP library. It would be great if the NI FTP VIs worked over a broader range of FTP servers.

I prefer having the setting "Show subVI names when dropped" ticked (found in Tools >> Options >> Block Diagram). However, this option applies only to VIs. It doesn't apply to primitive nodes such as "Search 1D Array", "Format Into String" or "Match Pattern". This is fine, as the name of the setting implies this.

However, because I sometimes prefer showing the names of nodes, I have to select one or multiple nodes, right-click and select "Visible Items >> Label". This is a minor inconvenience, but it'd be nice if there was another option named something like "Show node names when dropped", as seen below. When ticked, the node labels would be visible by default. Hopefully the implementation effort of this setting is low.

Screenshot (edited).png

Screenshot 2 (edited).png

Thanks

View All (3)

Printer selection dialog

View All (1)

As part of the base package in the LabVIEW Developer Suite, include an integrated SCC in the IDE. We are using a third party SCC program right now, and it has it's quirks when integrating with LabVIEW. Our group is comfortable with the quirks now, but for a new group starting a new project, the hurdles might be big enough to nix SCC. If a LabVIEW-specific package was maintained with the IDE, those quirks could be reconciled for the LabVIEW-specific style (i.e., a file is "modified" when compiled, diffing two VI's, ...)

NI has been really promoting SCC recently, and I think they should officially develop (or adopt) an integrated package with the LabVIEW IDE.

View All (7)

Of course there are many other desirable improvements (found by a simple search for "Event Structure" in the Idea Exchange forum).

One of them though would be a priori easily implemented with the floating Help Window (contextual Help): show the source (control) type as a basic help for the programmer to figure out whether "Binning" is the Boolean which select a binning option or the actual I32 value of the chosen bin increment (in the example below taken from what I am working on right now):

From that so-not-graphical list of control names, I have absolutely no clue. Sometimes the list of events might give me a clue, but not always.

This is just the beginning of a long list of additional information that would be helpful, but let's start with something really simple.

View All (1)

Hi,

My idea is as simple as the title states - an additional Compound Arithmetic function that works like "Equal?", but with multiple inputs and single boolean output.

I believe it is fairly easy to implement such functionality, and I can see no other single block that could compare multiple values, and offer easy expansion as well.

The easiest way to build similarly working VI (that comes to my mind right now) below.

View All (3)

It would be very helpful to be able to change formatting (different background, font, etc.) on individual items in a listbox. My use case would be listing a bunch of files in a listbox. Some of these files need to be brought to somebodies attention but most don't. The user also needs to view the files around the highlighted file so just listing the files that need attention is unhelpful.

In the image below imaging that the file highlighted needed review. I would want to use any logic including string matching, or other logic to highlight the background color of just that item.

Image 3.png

search (and replace) code segments

Currently we can only search and replace specific nodes, it would be beniciiary if we could search and replace for specific code segments.

This would be usefull if we placed some very often used structure in a Sub-VI and want to replace all those instance very quickly.

I am doing this right now for a 'sent event' piece of code and it's quite a lot of instance (>40) that I have to look up (by a specific node) and select, replace etc.

The search should be intelligent and ignore wire routings, just looking at all of the connected nodes and wires.

View All (7)

Consolidate LabVIEW File Types

Consolidate all LabVIEW G files into two file extensions:

Source LabVIEW File (*.xx) - Human readable source code files (e.g. *.vi)
Compiled LabVIEW File (*.xxc) - Compressed compiled binary files (e.g. *.vic)

Justification:

LabVIEW is proprietary. I need LabVIEW to open LabVIEW files. There are +15 LabVIEW file extensions to create LabVIEW G code. Recognizable LabVIEW extensions are worthless because I still need LabVIEW to open and edit the files. Some LabVIEW files contain compiled code, whereas other LabVIEW files are glorified name-spacers; some are UI components, while others embed compiled LabVIEW code into other LabVIEW files.

With every new LabVIEW version, capabilities are added that inherently cause inconsistencies between LabVIEW file types, environments and overall behavior. Let me explain.

Problem:

Current LabVIEW file types don't adhere to consistent behavior:
- Libraries (lvlib, lvclass, xnode, xctl) are xml files (human readable) but also contain encoded compressed data (non-human readable)
- VIs (vi, vit, vim, ctl, ctt) are binary files that can contain compiled code (or not)
- Libraries (lvclass) add dynamic capabilities like dynamically dispatched VIs and can embed class private data controls (or not for interfaces) using the same extension, rendering the extension useless
Inconsistent code redistribution
- Distribution libraries (llb, lvlibp) embed compiled code differently
- Packed libraries (lvlibp) resolve system paths differently that source
- Libraries (lvlib, lvclass) lack the capabilities to embed reusable libraries for redistribution - Similar to Python's PIP library
- Some 3rd party applications (like VIPM) to manage distribution inconsistencies add more file types and compounds the redistribution problem
Compatibility discrepancies
- VI (Poly, Express), Class (Class, Interface) already introduces development idiosyncrasies that could be resolved with a one "file" fits all methodology.
- More file extensions equals more variability, increased maintenance time, and puts ownership on developer community to find discrepancies

Proposed Solution:

Consolidate current LabVIEW G source files (vi, vit, vim, ctl, ctt, lvclass, lvlib, xnode, xctl) into a single Source LabVIEW File (*.xx) that is human readable (i.e. xml) that contains no encoded, compiled or compressed data. - Similar to NXG's xml format
Introduce Source LabVIEW File (*.xx) nesting/namespacing to remove the need for external Library files (lvclass, lvlib, xnode, xctl) - Similar to how C# or Python files allow for multiple methods within a single file.
Add a build spec component to generate a Compiled LabVIEW File (*.xxc) that embeds the Source LabVIEW Files and Compiled Object Cache - Similar to Python wheels/pip package manager
Allow developers to use the Source LabVIEW File (*.xx) or Compiled LabVIEW File (*.xxc) interchangeably in their development projects - Similar to how Python's *.py or *.pyc can be called

Features:

A single LabVIEW Source File (*.xx)...

can be human readable (i.e. xml) - Editor agnostic
can embed one or more LabVIEW Source Files - Single file libraries
replaces *.vi, *.vit, *.vim, *.ctl, *.ctt, *.lvlib, *.lvclass, *.xnode, *.xctl
adheres to common coding language extensions (C#=cs, Python=py, Java=java)

A single LabVIEW Compiled Files (*.xxc)...

is a specific build specification for packaging and distribution
contains the source files (optional) and compiled object cache
can embed run-time components - Package distribution
adheres to common coding practices (Python=.pyc, Java=.jar)
replaces *.lvlibp, *.llb, [*.exe]

LabVIEW currently has +15 extensions to develop G code:

(Not including, LV Projects, NXG, VeriStand, TestStand, LabWindows/CVI, etc.):

- Virtual Instrument (*.vi)

- Virtual Instrument Template (*.vit)

- Malleable Virtual Instrument (*.vim)

- Control (*.ctl)

- Control Template (*.ctt)

- Virtual Instrument Library (*.llb)

- Library (*.lvlib)

- Class (*.lvclass)

- XNode (*.xnode)

- XControl (*.xctl)

- Packed Library (*.lvlibp)

- Palette Menu (*.mnu)

- Run-Time Menu (*.rtm)

- Data (*.tdm, *.tdms, *.lvm, *.bin3, *.rc)

Should we consolidate?

View All (9)

I like to make plugin tools that work on items in the project e.g. Libraries/Classes.
I like implementing these plugins using the Quick Drop plugin framework.
And I normally always work with the LabVIEW Project in my standard workflow.

If I want to act on a Library, obviously I can just open a Member VI and get a reference to the Parent Library to do this.

However, I feel it would be more natural to Quick Drop on the Library in the Project itself!!

I also feel that it would be faster...

...And isn't that what Quick Drop was invented for?

I don't know if native options would ever exist, I am looking to call my own shortcuts - but there is alot of scope to implement custom plugins.

I have only given one example above.

Cheers

-JG

View All (6)

Extend on the concept of the termchar to include a multicharacter termination string for VISA reads.

Ideally, the termination string could be defined as a regex.

When I establish a connection with a linux based Device Under Test using a terminal server or TCP socket, the device ready prompt is the typical username@hostname:#

I currently read the VISA session in a tight loop a byte at a time and buffer the characters to compare to a regex of \n%s@.+?:[~|(/(\w)+)]+?#

The time required depends on the length of the response from the device under test, so I have to keep track of the total time myself; I can't use the VISA timeout.

If NI-VISA supported a regex based multicharacter termination string, I could set my VISA session to look and wait for the prompt.

In the old days when VISA was first designed, I'm guessing that this sort of functionality would have been taxing on the memory and CPU. With today's 64 bit GHz multicore processors, abundant RAM and common regex libs, I don't hink this would affect timing.

View All (3)

Currently if you're using some VIs with the 16 contact pane (five columns, 1st & last with five contacts, middle ones with two) and some with the very common 12 contact "4-2-2-4" pane, if you try to line things up horizontally with an error cluster along the bottom and a refnum or such along the top, you get all sorts of messy looking kinks in your wiring. This could easily be fixed:

The edge contacts on 5-2-2-2-5 shouldn't be uniform in size. Instead the top and bottom ones should be the same height as on the 4-2-2-4. The middle three will still be decently large, the same size as the edge contacts on the 20-contact 6-2-2-2-2-6 pane. And now everything will line up nicely.

Hi,

I sometimes could've used a VIT that maintained its connection to the VI you create from it, in the sense that if you later update the VIT any VI created from it update equivalently. Here I suggest such a "linked VIT", I call it a VI Definition here (.vid?), but it could be named something else if you have a better term. I envision something like this:

Consider a VIT containing code like this (just a small stupid example, often VITs are more complex), except this is a VID:

Then you create a new VI from the VID, and fill in some additional code:

To illustrate which pieces of code comes from the VID, I've dimmed those parts (since they have a couple of special properties I'll explain in a moment):

What you may not do to the objects originating from the VID:

1) You may not delete or replace any of those objects.

2) You may not unwire any originally wired terminal.

3) You may not delete any existing cases from case structures, event structures etc. Special situations arise when a referenced typedef changes for instance.

4) You may not change any control labels (if the VID can identify the original controls by other means you could perhaps be allowed to change their labels?).

5) You may not insert any object onto an existing wire (if this can be done while maintaining the autoupdate functionality from VID to VI then it maybe should be allowed?).

What you may do:

a) You may resize any existing structures, as well as move any objects and wires.

b) You may wire to any originally unwired terminal.

c) You may insert any number of new objects.

d) You may add new cases to case structures etc, and you may reorder cases.

e) You may change structure labels and control captions.

f) What about original free labels?..

What the above makes possible is that if you later change* the VID all the VIs created from it will update as well (when they are loaded into memory and checks their changed .vid file). Only what was changed in the VID will propagate into the VIs, nothing else is changed including the custom code added to each.

You should be able to unlink a created VI from its VID, possibly with a password protection.

What do you think about this?

Cheers,

Steen

* When a VID is changed a lot it's probably not possible to detect 1:1 what was changed when LabVIEW later compares it with each instantiated VI, so some change history inside the VID should probably be maintained to enable LabVIEW scripting the same changes into each instantiated VI.

View All (6)

I've just run into a "feature" of the LV2009 Parallel For Loops which is a bit of a nuisance! The number of loop instances is determined by two values: 1) the number of instances in the Configure Iteration Parallelism dialog, and 2) the number wired to the P terminal of the loop. It turns out that the number of instances created is the smaller of these two.

The nuisance is that if I wire the number of processors from CPU Information to P (as recommended) then when my new 16-core machine arrives (I wish!) I don't get that benefit unless the dialog value is also >= 16. And the 64-core machine that arrives next requires the dialog value to be reset in every Parallel For Loop - or I set it to be some unreasonably large number now, and therefore it's pretty much meaningless.

My suggestion is that the default number of instances set in the dialog is "Maximum" - i.e. it will use the maximum number of processors available. It should still be able to be set lower should the programmer wish to restrict the number below that. Then the default case works transparently as the programmer would usually want without needing to wire from CPU Information, and there are no surprises down the track when loops don't speed up on a new machine as expected.

View All (3)

when using the shared variable multiple variable editor to bind shared variables between the PC and cRIO its an annoying UI experience when doing more than a couple of bindings.

While the dialog can be resized, the new size is not remembered when binding the next variable, and its current size / layout is not useful for showing trees.

Also it doesn't remember your last position in the tree - so every time you wish to bind a variable you have to click to expand cRIO, click Chassis, scroll and click Module then scroll and find the variable by luck as you can only see the first few characters then click again.

bind shared variable.png

Cheers

View All (2)

LabVIEW Idea Exchange

Hide close button of the front panel windows

Make Bookmarks Available in Documentation for Compatibility with Requirements Gateway

New Array and Cluster Properties (Primarily When Using Control RefNums) - Cleaning Up the Implementation

Context menu "create constant" should by default create iconified cluster constants ...

FTP Improvement

Preview block-diagram of sub-vi on mouse over

"Show node names when dropped" option

Printer selection dialog

Include Source Code Control in LabVIEW Developer Suite

Edit Event in Event Structure should show the type of the selected source

New Compound Arithmetic Function - "Equal"

Give control of individual element formatting in a Listbox, datagrid and other array display controls.

search (and replace) code segments

Consolidate LabVIEW File Types

Make Quick Drop Shortcuts (plugins) Available for LabVIEW Project Items

Add regex based termination string option to NI-VISA

Tweak 16-contact connector pane wire landings.

Introducing the VI Definition aka "autoupdate from VI template"

Change definition of the number of parallel instances in For Loops

Shared Variable Binding Dialog Improvements