LabVIEW Idea Exchange

Post an idea

I hope LabVIEW wishes to become the next-generation all-purpose programming language that will be used all over the world in all industries.

.NET and Java are the dominant Technologies in almost the entire world. With the introduction of the ability to create a .NET Interop Assembly with LabVIEW 2009, I was very excited because I thought that now I could go back to several former employers and make a convincing argument for them to use LabVIEW.... But then I realized, yes, I can now expose my code written in LabVIEW to .NET applications, but my code cannot do many things which are standard in those worlds. For example:

I can create a .NET Assembly, but I cannot:

inherit .NET classes
use generic .NET classes
create.NET classes that use generics
implement .NET interfaces
expose a LabVIEW event to a .NET caller
expose a LabVIEW class to a .NET caller
cannot create Office Plugins, or any other Plugin that requires me to implement an interface

i.e. almost every single financial institution has an in-house developer that creates various Excel Plug-Ins and Add-Ins, LabVIEW cannot be used to create such a product because LabVIEW cannot inherit from and implement the IDispatcher interface.

The CLI - Common Language Infrastructure is an open specification developed by Microsoft tha

It allows anybody to create a programming language that creates fully compliant .NET code. There are 3rd parties that have created products such as ActivePerl and ActivePython, which allow developers to use Perl and Python (and even COBOL!) to create .NET compliant code. My vision is for LabVIEW to do the same, so that now every single organization in the world that uses any .NET language can also consider using LabVIEW, without having to run into many issues along the way. Only with full .NET compliance will random worldwide organizations consider writing a portion of there software in LabVIEW before hopefully moving entire projects onto LabVIEW!

Message Edited by John80 on 09-03-2009 01:49 PM

View All (2)

This is a relatively trivial one that bugs me once in a while.

If we have a control or indicator (e.g. named "numeric") and make a copy of it, the new control is named "numeric 2". (followed by "numeric 3", "numeric 4" etc. if we make more copies).

Basically, if the label contains a trailing number, the highest existing number will get incremented by one for the new copy.

What's wrong with this? You ask...

Let me explain: In labVIEW most things start counting with zero (e.g. array indices, iteration counters, etc.). For consistency, the original control should be considered "zero", so the first copy should be called "numeric 1" instead.

Interestingly, if we initially rename the control to "numeric 0", the first copy will be called "numeric 1" automatically. Why is "1" skipped if the original label does not end in a number???

View All (1)

Summary: We should add an option to LabVIEW so that if you have the VI Analyzer installed, whenever you use source code control to check in a modified VI, the VI Analyzer runs with a predefined list of settings to make sure that the modified VI meets the standards you've chosen.

Details: There are many aspects of a VI that ought to be a certain way when the VI is considered "finished" that ought not to actually break the VI. For example, you might want the text in your free lables to be spell checked correctly on a finished VI, but you don't really want the VI broken while debugging if you have misspelled words. You might not want coercion dots in the final VI, but breaking VIs when you have coercion dots during development is overkill. At the moment, you have an option of turning on Show Warnings in the Error List Window for a lot of these sorts of things, and LabVIEW R&D could add more to the warnings list, but there are so many things that we warn you about that the list is just noise, and since warnings are off by default, most people never see them. Your other option is to remember to run the VI Analyzer before you check in your VIs, but not everyone remembers to do that everytime. If the analysis could autorun as part of check in, it would help ensure good standards for VIs. I suggest that LV should have some way for the user to establish a list of settings for which VI Analyzer tests to run every time VIs are checked into source code control.

View All (2)

Another for the wish list.

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

See attached pic for an mock up.

There are probably lots of menus that could benefit from something like this.

View All (1)

View All (5)

Searching an array for a certain element can be expensive for large arrays. The speed could be dramatically increased if we can assume that the input array is sorted. The speed difference can be several orders of magnitude.

There is an old example that discusses this in more detail. I also wrote a similar tool long ago when I needed to recursively score positions for the tic-tac-toe solver, using a retrograde analysis similar to what's used to generate endgame tablebases for chess. (It literally took hours with the plain old "search array"!).

(A similar tool is the "search ordered table.vi", which only works for DBL and returns a fractional index.)

Suggestion:

"Search array" should have a boolean input (default=FALSE) where we can tell the algorithm that the array is sorted.

(The output would be exactly as before, with -1 indicating "not found".). Setting this input to TRUE would switch to a binary search where in the worst case only ln2(N) instead of N comparisons need to be made. (e.g. 20 instead of 1048576 for a 50000x speedup!!!)

It could look as follows.

Of course it should continue to accept all possible datatypes (including clusters) and not be limited to simple datatypes as the polymorphic example quoted above.

Message Edited by altenbach on 08-31-2009 03:30 PM

View All (3)

View All (1)

Currently: When you "Find Missing Items" in a project, it thinks a few seconds (on a large project) and pops up a non-resizable window. You can double click on an item in the list, which closes the Missing Items list and it highlights the missing item in the project. You remove that item (or relink it) in the project, and then have to "Find Missing Items" again. Wait a few seconds, rinse, repeat...

Proposed:

1. When you double click on an item in the Missing Items list, do not close the list - leave it open, and gray out items that have been taken care of and are no longer "missing" (like the find dialog, when you delete a found item).

2. Allow the columns to be sorted by clicking on the header Name, Location in Project, or Path (this one holds a dear place in my heart)

3. Finally, allow the window to be resizable (a common request...).

(I have given the example for "Find Missing Items"... you can apply the same concepts to "Find Items with No Callers")

Message Edited by mechelecengr on 08-26-2009 02:19 PM

View All (5)

If you want to use the 'Call By Reference' node to call a VI, you have to provide it a strict VI reference. Today, the only way to get a strict VI reference is to request one with the 'Open VI Reference' function:

But it is common to get a VI reference in some other way, like it being passed in through a control or obtained from other VI Server methods/properties. We should be able to use the 'To More Specific' node to convert a plain VI Reference into a Strict VI Reference, like this:

If the reference does not have a matching connector pane, if the VI cannot be reserved for run, or if any of the other things that can go wrong with creating a strict reference happen, the To More Specific function would return an error on the existing error terminal.

View All (7)

I was looking at the terminals used on block diagrams in detail. It seems like the current design kind of obsures the DBL label and part of the array bracket to indicate the terminal represents an array. I started a discussion on these terminals in this thread. Terminal images for arrays on block diagram Why does the black arrow have a shaded background that obscures part of the text? I think that thread had enough positive interest that I am going to propose some sort of redesign to the appearance of the block diagram terminals here.

Several ideas came up as replacements. Here are some, the first two by me and the second two by Altenbach.

Mine:

The top of the first image shows the problem with the current terminal and is enlarged on the left. The bottom of the first image shows one proposal where the terminal is enlarged by 4 pixels in width.

The second image is an idea where the terminal does not grow.

My second idea.

Christian's two ideas:

Some key points were raised:

1. Some thought the direction arrow was redundant. In my opinion, some sort of direction arrow should stay.

2. Changing the overall size of the terminal may cause problems for some (this happens in my first option). It wouldn't bother me personally, but I do understand this point.

Message Edited by Ravens Fan on 08-24-2009 04:25 PM

I often employ a design pattern of for each item in a list where the list is a typdef enumerated type. This is a great way of making a linear sequence where each item is tested one time (test sequences, list checking .....). I used to make an array of the type and populate it with one of each item, this is not very scalable since when I change the typdef I have to redo the list. Instead I do a little type manupulation to make sure that I itterate one time for each intem in my enum, this requires some support code and extra wiring. It would be nice if I could make a for loop that takes the enyumerated type and used it as its itterator. See below:

The new for loop which takes an enum would greatly simplify the code readability.

I use this all the time and find it to work great, uppdate my enum and handle the new case, no chance of missing a case (I use it in conjunction with case structures with no defaults so my code breaks and forces me to handle the new case.

I have attached the code if any one is interested

View All (4)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

True .NET Support

Auto increment number in middle of control name

More Mac/Linux Support

Don't skip "1" during automatic naming of copies

Autorun VI Analyzer when source code control checks in VI

Status Bar for Labview

unconnected bundle

glyphs in case structure menus

Single Precision Measures of Mean.vi

Add Explicit Decoration References to LabVIEW

"Search Array": Add "array is sorted" boolean input

Find all instances on Shared Variables

Diagram Cleanup should not move loop terminals (option)

Add description to project folders

A Better "Find Missing Items" and "Find Items with No Callers" in Projects

Make the 'To More Specific' node able to convert a VI reference into a Strict VI reference

Redesign of images used for terminals on block diagrams

For loop accepts enums as enums

Enqueue array of elements

Increase the size of the rearrange cases