LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

As discussed briefly here, the Type Cast function has a seemingly unecessary limitation that it does not accept arrays with more than one dimension.

Obviously, such arrays cannot be valid inputs for the "type" terminal (and thus the output), because of ambiguity (For example if we have a8 elements, LabVIEW would not know if we want a 1x8, 2x4, 4x2, or 8x1 2D array). However, having a multidimensional array as input does not pose any such problems and the result can be fully predicted. If such arrays are allowed as input, we could do cool things very quickly and with very little code:

Some examples (currently not possible! :()

Type Cast a 2x2 2D U8 array to a SGL or I32 scalar, for example.
Type Cast a 4x4 2D DBL array to a 1D CDB array of lenght 8.
Reshape a 3D DBL array to a 1D DBL array containing all elements (see image below for what we need to do today instead)

IDEA: The input of Type Cast should accept almost anything. In particular, numeric arrays with more than one dimension should be allowed and simply interpreted in memory order.

(Of couse certain things should probably remain disallowed as inputs, such as arrays of strings, for example.)

Reusing some elements of system popup

View All (2)

How about adding a feature to a few of the LV primitives such that an error cluster can be optionally added to catch some common issues that right now require special checking: For example, Divide by zero, returning an error as well as Nan, or Index Array where the index < 0 or > size. THe error cluster would allow easier handling of these cases WHEN DESIRED, by wiring directly to a case structure, etc.

(This idea evolved form a discussion at the CLA Summit during a talk by Nate Meohring.)

DaveT

View All (3)

Run VIs on LabVIEW Startup

The resizing function calculates the new position of controls based on the previous position.
But the position is an integer. So the calculation is rounded. If you resize several times a VI, rounding errors occur and position control shifts.
This is particularly true for complex controls (like a graph) that have been modified

Solution
Using the resolution of VI and position controls registered at the creation of VI and calculate the coefficient of expansion / displacement from these values.

View All (4)

Background:

I have a single pane that I was using to debug a state machine. It is not clever at all, but it is useful.

I viewer of the Snip might not see what I did here, but I used the "Align Objects >> Left Edges" tool and the "Distribut Objects >> Vertical Compress" tool to get all the text tags and the order of the components to be "human readable".

A human doesn't know that but the software should.

When I hit "cleanup" I get this:

From this image you can observe that "fast, human readability" is lost. I can hunt, but its not a simple up-down.

I think that the "cleanup" should recognize the formmating, and retain it in this case. It should do this by default. The entire paradigm of LabVIEW is visual programming. The diagram cleanup tool, in this particular case, has room for improvement there.

If you've got a project open, any new VIs you create automatically get added to the project. It'd be nice if there was a way to disable this feature.

I find the feature frustrating because:

- I often create new VIs that I never intend to save, just to test out some logic quickly. However, I can't just close the VI -- I need to go and remove it from the project too -- and this also leads to a dirty dot in my project (and extra work).

- I'd prefer to have full control over which VIs get added to my projects, and where they added within a project.

- If you've got more than one project open, you have to be careful about where you press "ctrl+n" from.

- I've found myself in situations where I close a project after creating a new VI, tell LabVIEW that I don't want to save changes to the project, and by doing so inadvertently lose the code in the new VI because I'd overlooked that automatic association.

Hello,

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively. (again)

This VI is found in "TCP Listen.vi", which is on the TCP palette. It maintains a registry of existing listener connections and attempts to reuse them.

What's the big deal, you ask? Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI. Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems. The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness. Thus, though it may be perfectly functional, I don't trust it.

I realize the code could be a whole lot worse. I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements. Kudos to that individual for all the new free label comments.

Nonetheless, here are some factors that obfuscate this VI:

There is no documentation under "VI Properties". What does it do, at a glance? (I know the answer because I've stared at it over a few versions of LabVIEW)
"TCP Listen Internal List.vi" also has no documentation under "VI Properties"
Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
Deprecated "Retrieve Element" case in the internal list VI. "Item Requested" is no longer a requested item, but the result of a search on elements.
"net address" is confusing and ambiguous Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
"Conflict" is ambiguous. This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

I know, I know, "If it ain't broke, don't fix it." ... but I think it could still use some work to make it more intelligible.

Respectfully,

Mr. Jim

View All (1)

Make Sync.vim extendable

View All (9)

Navigation window improvement

Manage the Graph legend TAB

1) The problem :

By programmation change the number of element inside the legend :

EXEMPLE :

Step 1 : We have 2 slop

Step 2 : by programmation we have now 1 slop

Step 3 : Now, if you want to re-increase the number of slot inside the legend, the tab is becoming automatically vertical without any possibilities for you to modify it :

2) Solution :

If it's possible, had a property node where you can choose horizontal or vertical tab for the legend or an option : "always vertical" and "always horizontal

Thanks

View All (2)

Multi-core LabVIEW IDE

I seem to spend a lot of my time in the LabVIEW IDE waiting. Waiting for LabVIEW to load dependencies, or do this or process that. For some projects with FPGA and CompactRIO I've calculated that I spend about 80% of my time just waiting for LabVIEW development environment to catch up.

Given LabVIEW's multi-core nature, it seems embarassing that I can create code to run blisteringly fast on a massively multi-core number-cruncher, yet the IDE itself is painstakingly slow. I wonder how much of these delays could be mitigated by a multi-core capable development environment? LabVIEW currently runs on just one processor, and with the increasing prevalence of multi-core CPUs as opposed to faster indivudal core speeds, I wonder if the chaps at NI are thinking of taking the plunge into a multi-core integrated development environment? I seriously hope so.

View All (4)

After much frustration searching the Labview help and NI website I finally came across the reason why my project kept coming up with vi file conflicts and/or using the incorrect version of a vi. Apparently when searching for a vi, if there is a windows shortcut (.lnk) in the search path, it follows it! Now this is a very powerful feature but a dangerous one too. Apparently this has been a feature of Labview all the way back to version 1.0 This fact is not mentioned anywhere in the Labview help but I did finally find this article: http://digital.ni.com/public.nsf/allkb/B43C655BA37AFFA0862575EC0051E936

In my case I have lots of example code on my PC. I often put shortcuts to similar code in the same folder with VIs and project as a quick way to reference alternate methods of accomplishing similar tasks. No problem, I'll just turn off this feature in the VI Search Path page of the Options dialog, right? Much to my surprise there is no way to turn this off.

Suggestion: Please add an option to disable this feature in the VI Search Path page of the Options dialog. Even if this option is dismissed and not implemented, please at least add this information to the Labview help, perhaps in the Paths Page (Options Dialog Box) if not in several other places in the help. It would certainly have same me hours of frustration and lost productivity.

View All (4)

The Undo (Ctrl-z) menu option is not available in stand alone applications built in LabVIEW.

The LabVIEW help confirms this: http://zone.ni.com/reference/en-XX/help/371361G-01/lvdialog/application_item_tag s/

Look where it says: "Items followed by two asterisks (**) are available in stand-alone applications you build in LabVIEW."

Then look for Undo and Redo in the Edit menu and you will see that they are not followed by the (**).

I posted the code that I created to implement Undo for exes: http://decibel.ni.com/content/docs/DOC-14805, but I believe we should be able to use the "Application Tags" instead of having to create code for something that is already implemented in the Development environment.

View All (6)

Add a NIRG-compliant free text field

View All (1)

LabVIEW Idea Exchange

The Type Cast function should accept higher dimensional arrays as inputs

Reusing some elements of system popup

Right-click to add error cluster to Divide, Index Array

LabVIEW different version show on the icon

Progress Indicators for Unit Test Framework Import Functions

Run VIs on LabVIEW Startup

Having a better function for adjustment control to VI size

remember Object formatting in diagram cleanup

Option to disable automatically adding new VIs to open project

Double clicking on a wire should add its label

Refactor or Rewrite the TCP Listener Internecine Avoider

Make Sync.vim extendable

Navigation window improvement

Manage the Graph legend TAB

Give discounts on Developer Suite based on the number of unresolved CARs

Multi-core LabVIEW IDE

Windows Shortcuts (.lnk) Become Part of LabVIEW Expected File Path

Make Undo/Redo menu options available in stand alone applications built in LabVIEW (exe)

Add a NIRG-compliant free text field

Install Third party executables before starting the LabVIEW application Installation