LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Project templates

Hi, guys

Do you use Templates in LabVIEW?

You might have used VI templates in LabVIEW (*.vit).

You might have used control templates in LabVIEW (*.ctt).

You might even used VI templates and control templates together.

Why can't we create templates for complex libraries like project files or (class-)libraries?

For example:

I've created three template VIs which are connected to one control (TypeDef) template.

(The three VIs are for loading, editing and saving the data of the control template to a special kind of data.)

But using the VI templates will create a separate control (TypeDef) for each VI!

If I could put the Templates together in a library or project, It would make things easier,

because LabVIEW 'could' already know about the connection between the two template VIs

and the template control (TypeDef).

That's just a simple example which could get much more complex on whole project templates.

Until now I have to copy the project template and use it as I need to. It works somhow, but

multiple people using the same template causes much trouble (Someone always forget to create

a copy before changing it )

So there's the idea. What do you think?

View All (4)

One thing which occurred to me today is that the majority of examples which ship with LabVIEW concentrate on one function or another.

What we don't seem to really have is an example for an actual functioning application with a GUI which actually does something useful. Or at least I'm unaware of something like this.

I think it would be neat to include a sample project for an application demonstrating how to load and save to INI files, set front panel objects, Custom menu interaction, how to synchronise loops and so on. Just a small-ish program which does SOMETHING useful (not the Icon editor, that's too complex).

I think this might help a lot of people "get" the things needed for a decent application as opposed to running code from within the IDE all the time.

Shane.

Reorder Button Color

I find the color of the Reorder Button on the front panel a little confusing. The colors of the two circular arrows being gray gives me the impression that the buttons is disabled for some reason, especially considering the related buttons to the left have some color with green and yellow boxes. It causes me a slight mental block every time I want to use it. I would suggest that the Reorder button be given some color, such as green, so that it mentally gives the impression that it is allowed to be pressed.

Message Edited by Ravens Fan on 06-21-2009 01:15 AM

A micro second wait VI

NI Community,

I have developed some applications where it was desirable to have a Wait, but 1 millisecond is just too long.

I came up with a method using the High Resoution Releative Seconds.vi, to create a delay in the microsecond range (it's attached). This works for the particular application I need it for, because I am waiting on an external buffer to be ready to accept new data (its rate it can process is 60 nanoseconds). Waiting for an entire millisecond in this case is just too long.

The downside to this method is it is tied to your processor speed and current workload. It would be great if NI supported a 'Wait Until Next us Multiple.vi (it doesn't Sleep).

Attached is my work-around. I'd love to see other ideas on this topic.

Thank you,

Dan

View All (3)

VI Analyzer has a spell check ability (woo hoo!!)

You can even add custom words to a custom dictionary, for the case where you have a need to.

However, for a out-of-the-box spell check system for an application used heavily by the Test and Measurement community, I was very discouraged I needed to add words such as

Agilent

GHz

preamp

to the custom dictionary to stop getting them flagged as misspelled.

How about a standard out-of-the-box dictionary refresh to include technical terms commonly used in T&M applications?

View All (1)

View All (2)

Save compiled VI in separate file

Most SCC systems expects the source files to only contain source, and not (as in LabVIEW) both the source and compiled code.

This means that most SCC system flags the sourcecode file (i.e the VI) as changed whenever a recompile is performed and saved.

Since LabVIEW wants to recompile the VI's very frequently regardless of real sourcecode changes, it would be better to split the VI into two files, one containig only the sourcecode and another containing the compiled code.

This way we could configure the SCC system as with other languages to ignore the compiled files and only handle REAL source changes.

Note that the flag "Don't save automatic compiles" only helps for readonly-flagged files, which isn't enough when when working in SCC systems that doesn't use locking

View All (2)

Similar ideas have been posted before with even more options added to the String Probe. Maybe if we start with something simpler, we can expand from there.

I would like the String Probe indicator to resize, at least horizontally, to the full space provided in the Probe Display section of the Probe Watch Window. As the user resizes the Probe Display, the String Control would also resize.

It would be nice if this behaviour could also be extended to a String Array.

View All (4)

With the advent of LVOOP, some things have changed about the way we work with LV.

I currently have an example of an instrument driver (USB) which I'm implementing using LVOOP. I have many different individual commands, each with their own input and output values. I have one nice "polymorphic" VI with all of the creator VIs for every command organised nicely in a menu with several levels. I say "polymorphic" because I don't set the VI to adapt to the data type.

After processing the instrument command, I again use a "Polymorphic" VI (See above regarding the "") for reading the various values from the processed command. Both of these "polymorphic" VIs use menus and do NOT adapt to data type.

I have basically two VIs for every class, one to create the query / command and others to process the data contained within the created object. I have two VIs for EVERY instrument command.

What would be cool:

Having a special VI for a class which is presents the user with a menu for the individual functions (no adaptation to data type) which itself can be included in a regular polymorphic VI (adapting to the object type).

This would allow the user to select a different instrument command and have the corresponsing process VI on the right automagically update to present the user with the commands available for that particular object.

That way we could create an entire instrument API with only TWO VIs ("polymorphic" creator and polymorphic-"polymorphic" function VI).

Shane.

Message Edited by Intaris on 01-29-2010 02:42 AM

View All (2)

Close All VIs in Project

The length of the right click context menue (mainly in the block diagram) increases in each new LabVIEW version. So the handling becomes more and more uncomfortable - especially because there is no eye-catcher for the different entries.

There es one program who is doing it much better: MS-Word 2013. There are much more functions in the right click menu in comparison to the LabVIEW menue but it is more comfortable and the items are easier to find because of the icons => Have a look to the picuture.

I'd like to suggest to implement a context sensitive right click menue in the style of MS Office to re-align the existing items and beeing ready for further extensions of the menue.
Beside giving the current menue entries a new style also some of the properties of the structures which are selected could be moved to this new menue (e.g. text styles, number formats, basic alignment, grouping, ...).

View All (8)

There are several methods to exchange data between parallel loops.

These methods however are (intrinsically) not following LabVIEW's dataflow-along-wire paradigm.

If you think in different layers, where several loops are running in parallel at the surface, you could have subsurface datatransfer.

You could add a new "tunnel mode" to the LabVIEW 2013 right mouse menu on the border of a loop.

There you could also specify whether you would like the data passing the boundary to be queued.

You would however think of something to visualize these settings at the loop boundary as well as having some error terminals in case of queues.

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.

If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).

However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).

Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

Say I have a VI with an arithmetic function: add, subtract, negate, etc...

I would like the ability to programmatically change the output configuration of the function through scripting. Right now (as I understand) you can only read the datatype of the output terminal but not set it. I specifically want to be able to control the fixed-point configuration of the output of these functions through VI Scripting.

[admin edit]: I added an attachment to this post pertaining to the first comment on the thread (since comments cannot contain attachments).

View All (1)

This is more of a bug report than an idea suggestion (although the boundary between both is sometimes tenuous).

When creating a Formula Node input or output variable, the name of a control or indicator created by Right-clicking the terminal is "input variable" or "output variable":

It should be named after the variable it is connected to. In the example above, I would expect "delta".

Shouldn't be difficult to do, the Mathscript node does things right:

PS: don't tell me I don't need to declare the output variables in the formula node. I know. I just created the latter for debugging purpose, which reminded me to post this overdue bug report.

View All (2)

LabVIEW Idea Exchange

Project templates

Include examples of actual Applications in LabVIEW, not just functions

Mixed Signal Graph and Cursor Events

Reorder Button Color

A micro second wait VI

Case structure with case sensitive/insensitive indicator

vi analyzer spell check dictionary

Vision - Add Silver Theme to the Image Display

Compiler optimalisation options to get rid of the long compile times

Save compiled VI in separate file

VI Analyzer to ignore Clear Errors output

Resize String Probe as Probe Display is resized

Allow special "polymorphic" class functions

Close All VIs in Project

Right click context menue in MS word style - better visibility of items, less mouse movements

underpass (subway) for data exchange between parallel loops

Drag and Drop VIs from Project Files Tab

Allow calling a MATLAB script via path

Give VI Scripting write access to modify function output configurations/datatypes

Creating a control/indicator from a Formula Node input/output variable should preserve this variable's name