LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Simulated Devices in LabVIEW projects

Copy any Data Type to Clipboard

Currently the Clipboard.Write Method in the App Invoke node only accepts text as a data type. I think it should accept any data type. So for example, if you wire a array of doubles to it you would than be able to paste that data into a spreadsheet. Or wiring a picture data type would allow you to than paste that picture into a image editing program.

Our facility runs only one version of labview at a time and that majority of time for installing a new version is spent removing the old version. A check box on the installer to remove or update the previous version would be a great addition. In recognizing that several companies must support multiple versions of labview removing the previous version should just be an option, not required. 2nd having the option to select all toolkits and addons to install from the first disk then just a prompt for the other install disks as needed would really speed up the install process as well.

Most people know that Network Published Shared variables are pretty slow. If you write to a SV and then immediately read from it, you probably will not see the new updated value. One way to get around this is to write the value and then continuously read and compare the SV until the value is updated:

Pretty straightforward to do, but takes time to set up, as well as some Block Diagram real estate.

I think it would be pretty convenient (and easy for NI to implement) if there was an option for a SV to wait until updated.

It could either be an option from the right click menu, (that of course would update the icon to signify that it's now a blocking call) or use an input to the variable, or maybe a combination of both:

Slide Control Origin

Hi all!

I think that it would be cool to be able to set the "origin" of a slide control. You can do that programmatically by adding a second slide and check for the control/indicator in the block diagram. Right now, if you place one of this controls on the front panel, the origin will be at the bottom of it.

If you open the VI, you will see what I mean. It would be cool to have a Property node where you could set the origin of the slide, just as it has been done in the code with the constant.

Thanks!

Dear fellow wireworkers and LV-creators at NI,

A LabVIEW Chart with multiple plots can be changed to display the plots either in the overlay (default) or stacked mode by a chart pop-up menu option. However, there seems to be no way to change this programmatically with a property node or when a VI is running with a chart's runtime pop-up menu option. So if you want a VI with a chart a user can set both display modes at runtime, there is no other way than placing two charts on top of each other, one for the overlay and the other for the stacked plots and make only the desired one visible.

I call for an overlay/stacked plot property node for LV-charts

Thank you and happy wireworks

Urs

Urs Lauterburg

Physics demonstrator

Physikalisches Institut

University of Bern

Switzerland

If I have an existing cluster in my project and one day I decide to delete one of the elements of that cluster, LabVIEW tries to fix all the references or black them out to help me find the errors. However, It seems that LabVIEW in some instances keeps track of clusters internal controls with an index and when you delete something, those indexes are now messed up.

For Example, if you have a property node linked directly to an item within that cluster, then you delete an item in that cluster, the property node now points to something else. OOOPS!

Also, if you have an Event Structure Case pointed to a control within this cluster, and one of the other controls in the cluster get's deleted, this Event structure case now points to the wrong thing!

LabVIEW is internally keeping track of the controls in a cluster with an index. It works fine as long as you only add new stuff to the cluster. But if you delete things, LabVIEW does not handle it well.

If LabVIEW instead had a notion of the name of the items, then it probably could recover well when an item was deleted from a cluster.

View All (3)

First, let me say that I think this is probably in the range of not technically possible right now. Thats fine by me. It is the idea exchange after all. I dont remember seeing a rule that the ideas actually have to be feasible 😉

Second, I wanted to give a shoutout to a similar idea that solves a similar problem:
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Autorun-VI-Analyzer-when-source-code-control-checks-in-VI/idi-p/976796

Obviously I like mine just a smidge better, but honestly I would be happy with either 🙂

My apologies if I missed others or if this is a duplicate.

----------------------------

Basically my idea is this. Right now, LabVIEW gives you errors and warnings as you write your code. Then you finish and you get a shiny happy run arrow with no further feedback. In my opinion, that feedback should continue and it should continue as part of the core IDE, not as an addon (VI Analyzer) you need to run.

So far I've come up with two ideas I like:

1) Vi analyzer auto-inserts, as your code compiles, errors that crop up

2) The idea I like less is that there is a new button off to the side which tells you what VI analyzer thinks of your code. When you click it, you get the familiar pop-up but instead of showing actual errors it shows test failures:

I have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.

The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.

There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.

As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.

I cannot comment on Amazon S3, as I don't use it.

Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.

View All (1)

Imagine that you have made lots of code, wiring up several VI etc. all with the same data, a cluster for example, going in and out. Now you regret not having defined that wire as a typedef. Today replacing the data with a typedef will involve a lot of steps; you start by clicking on one of the controls or indicators, and create a typedef...then you need to do the tedious work of replacing all the other controls and indicators up- and downstream.

Would it not be nice if you could just right-click on the wire and select "Define type"/"Create type definition" or "Replace with type def/class" - and then choose to have the type definition automatically replace everything along the wire ("propagating type def")?

This idea was inspired by and first came about as a comment to this idea by cowen71.

LabVIEW Run-Time Toolbar

View All (3)

When adding one or more breakpoints to a VI, the user is asked to save the VI when closing it even in the case that he has already removed the breakpoints again manually or with the breakpoint manager. When using sourcecode control like TortoiseSVN, this makes always trouble when closing a larger batch of VIs and no time to look which VI has been really changed and which not. Because then you will save a new version of a VI which has not been changed at all. You have to click around a lot to not get into these conflicts.

Saving breakpoints with a VI might be a helpfull option for some developers (not for me, I have never had the need to save breakpoints with a VI).

Nevertheless my suggestion is that the version status of a VI should not be changed when adding breakpoints, or at least should be reseted when the breakpoints have been removed again.

View All (4)

I would like to have two more selections in the dropdown menu when I right-click on a wire to a class reference. The menu item should be "Public methods" and also

"Private methods" (if I'm working inside a class method) which would give me a direct access to the methods of a class, much like it does when you type a class name followed by a dot in e.g.. the Visual environment. (There you get a dropdown with all the methods and attributes for the class.)

Now Idea

View All (1)

I hate right clicking. Currently (for me LV2014) double clicking on a Block Diagram Class Constant does nothing. Many times class constants are connected to launching Actors or other class VIs in the Class library. But right clicking to pop up a menu and clicking "Show Class Library" wastes a lot of time (around 2 seconds ).

To quote an example from Steve Jobs about wasted time:

“If it could save a person’s life, would you find a way to shave ten seconds off the boot time?” he asked. Kenyon allowed that he probably could. Jobs went to a whiteboard and showed that if there were five million people using the Mac, and it took ten seconds extra to turn it on every day, that added up to three hundred million or so hours per year that people would save, which was the equivalent of at least one hundred lifetimes saved per year.”

View All (2)

View All (1)

LabVIEW Idea Exchange

Option to automatically apply icons to all items

Simulated Devices in LabVIEW projects

Copy any Data Type to Clipboard

Reduce Steps to install Labview and simplify installer options

Shared Variables: Wait until updated for write

Slide Control Origin

Change LabVIEW chart display from overlay to stacked at runtime

LabVIEW should not internally track cluster controls with an index but rather with a name.

Run VI Analyzer checks as part of development/compilation process

Google Drive, Box, Dropbox, OneCloud, etc. Cloud Storage APIs

Resolve XNET 52 bit signal length limit

New override code instead of ancestor subVI

Propagating type definition /Replace type all along wire

LabVIEW Run-Time Toolbar

Breakpoints should not change VI version

Direct access to class methods in dropdown menu for class wires

Changing state of Boolean constant is too easy

Double Clicking on a BD Class Constant should "Show Class Library"

Installer build spec option: Let User "Run Installed Application After Installation Completes"

Ship common "Interfaces" for use in customer written shared code