LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Leave the For-Loop as it is

Lots of ideas for different enhancements to the old trust For-Loop.

I propose leaving everything the way it is.

This is needed as a counter-weight to the multitude of "enhanced" for-loop suggestions out there.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-Iteration-Terminal-in-For-Loop/idi-p/1174449

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Real-For-Loop/idi-p/1211713

Spoiler

Some of the proposed versions I like but it feels like no matter which version would be implemented, 80% will be disappointed.

Spoiler

There are also some times I just think we're getting lazy as programmers

Spoiler

or Maybe Altenbach's drive for efficiency has affected us all!

Spoiler

I wonder how deep the rabbit hole goes?

Shane.

View All (2)

Find text in VI

View All (2)

View All (4)

View All (1)

View All (3)

Hard Inline VI

When you inline a subVI it is not the same thing as placing the contents of the VI on the callers block diagram. Almost but not quite.

The difference is that all outputs of a VI (inlined or not) become available at the same time when the VI completes execution.

Set the VI above to inlined and use it in another VI

The idea is an additional inline setting as follows.

Now the VI will truely be inlined as if it were not a sub VI at all.

The name "hard inline" is just a suggestion and could be called something else.

There should be an option (right click on the structure?) to convert a conditional disable to a case structure.

Why?

a) I often use conditionals to test different algorithms. In several times it finally has been nessecary to implement both (or more) of them into the final application as none of them cover all cases of input data well enough.

b) In other cases It showed that selecting the algorithm should be selectable (e.g. using a INI file or registry entry, a project's global or even from a front panel terminal).

In all cases changing the conditional disable to a case using the values from the conditional cases in use as case values would just leave the work to add the input to the case selector input (whereever it comes from).

View All (2)

Instrument simulator VIs

If we can have instrument simulator VIs, we can test our codes prior to the actual hardware acquisition

The idea proposes device driver packages from IDNet to include a vendor instrument simulator VI that can be run prior to code testing. The VI can be configurable (VISA based on virtual ports created during runtime, file paths to read from to simulate measurements and responses to messages, etc) and started asynchronously (call & forget) at the start of the program and terminates when the caller terminates.

or as a template from the "New > Simulated Instrument" where user can modify according to the instrument that they are going to use.

...and that it covers NI and 3rd party instruments

I propose to update the shipped version with a very slight modification to allow the custom definition of stripped levels for the call chain:

the optional/recommended input "strip levels" would remove the given amount of VIs in the call chain so that even error-wrapper VIs won't be displayed when the driver throws an error. The function even stays backward compatible 🙂

I'm currently writing some driver wrappers for DLLs and use this VI a lot.So far, I needed to use my own version ...

-Benjamin

Option for Child Window

I would like to see an Option for Child Window. This option will useful to keep open FP in Parent FP even when it is moved around, minimized, ect...

I understand LabVIEW dose not support MDI, but simple Child Window option will be helpful. Currently, I am using Windows API to do this, but native supported function/ option can be big help (won’t have to use VI server, Dynamic path builder to check application type vi, exe, llb, and others useful things that needs be done..).

Download All

Array size via Property node

When developing a utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.

There are various workarounds, but all of these are relatively tedious and over-complicated.

Why don't we have a "array data size" read only value on the property node of an array?

This would make things MUCH easier.

Shane.

Message Edited by Intaris on 06-12-2009 12:33 PM

VI Analyzer Test - Not a Refnum Usage

In this thread on LAVA, Aristos Queue points out some common usage patterns of the "Not A Number/Path/Refnum?" function that can result in performance problems and/or race conditions. He recommends either (1) comparing a refnum against a null constant value, or (2) trying the refnum operation you were going to do anyway, and using the error output from that operation to determine if the refnum was valid.

I propose a VI Analyzer Toolkit test that checks for this scenario called "Not A Refnum Usage". The test would return a failure under the following circumstances:

The input to the "Not A Number/Path/Refnum?" function is a refnum data type.
The refnum is any type other than Occurrence.
The output of the "Not A Number/Path/Refnum?" function is wired to anything other than a Boolean indicator.

If these conditions are met, the test would return a failure, and would make the two recommendations mentioned above as alternatives to using the "Not A Number/Path/Refnum?" function.

LV Version Tooltip

View All (2)

Select Array Data

Help dealing with insane objects

I think everyone's been there before.

Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code. Not a nice thing to have happen.

At the moment, it's quite a nasty job trying to track these things down. Usually most users resort to trial and error in trying to find the culprit. I myself use the mass compile function to at least narrow down which files have the problems. Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.

I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this. I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier. How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.

Message Edited by Intaris on 06-02-2010 02:29 AM

View All (2)

View All (1)

This idea comes from my experience in Simulink.

Suppose we have a hirearchy like this:

Main.vi---->Subvi1.vi---->Subvi2.vi

Now, if you are at "Main.vi" and you want to see what is there in Subvi2.vi, the normal procedure would be:

1) Open Main.vi Block Diagram

2) Open Subvi1.vi Frontpanel and Block diagram

3) Open Subvi2.vi Frontpanel and Block diagram

So now, we have three front panels and three block diagrams, a total of six LabVIEW windows open in front of us. If the application is more complex, the number of these "LabVIEW VI windows" would be even more, which makes it difficult to transition within SubVIs. Some would use the method of "Find All Instances" to find its place directly in the caller VI, but that is not good if you have multiple instances of SubVIs being used in your program.

My idea is, why not have a Single LabVIEW Front Panel and Block Diagram window, where we have a "UP" control, like the one in windows explorer, where we keep on moving between SubVIs just like any other folder in explorer, like the way it happens in Simulink?

So it would be something like this:

When you are inside the SubVI, a "Up" arrow should appear, as shown in the image below:

I am not sure how much this idea is feasible to implement in LabVIEW, but it would certainly be a nice feature, given it reduces the confusion with multiple open VIs when a SubVI BD is opened which is lying deep inside the hirearchy level.

LabVIEW Idea Exchange

Leave the For-Loop as it is

Find text in VI

Update while typing for comboboxes ....

Scripting of Actor Framework Abstract Message Wrapper for Child Classes (Actors)

Support OLE Variant or ActiveX Variant Type Access

Byte at port or Data available for TCP/IP VIs library ...

Hard Inline VI

Convert conditional define to case structure

Instrument simulator VIs

Modification of "Error Cluster From Error Code"

Option for Child Window

Array size via Property node

VI Analyzer Test - Not a Refnum Usage

LV Version Tooltip

Default Representation for Enum should be U8

Select Array Data

Help dealing with insane objects

Allow object/text search to find items in the whole project, including VIs not in memory

Search Coercion Dots in a Hierarchy of VIs

Keep only the SubVI visible with an option to go "Up the hirearchy"