LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Example:  I graph a temperature input, using auto-scale on Y.  The end-customer complains that the temperature suddenly started rising at the wrong time.  I try (futily) to explain that the rise was only 0.01 degrees, but the scale on the graph expands it to fill the screen.  Then someone else comes in, and we repeat the conversation.

Auto scale chart.png

 

What I'd like is a feature to keep auto-scale, but set the minimum span.  For example, set the minimum span to 10 degrees:

Auto scale chart min.png

 

The story is similar for integer charts.  Too often, a value is on the bottom of the chart, or on the top, and all you see easily are vertical lines

Auto scale chart bool.png

With an auto-scale-min-span of 1.1, it would look better:

Auto scale chart bool min.png

 

I use a lot of very generic programming, so may not know if I should set the minimum span to 1.1 for boolean values.  For that case, it would be great to have a feature that makes the auto-scale go X% beyond the min & max values.  In this case 5% would give the results above.

 

One more feature (one I've written programmatically, and it's a MAJOR pain):  set auto-scale to only scale up if the data is less than 50% of the current span, and scale down as needed (but over-shoot to anticipate more scaling).  It's irritating to watch a graph constantly scaling up and down, especially an XY graph.

 

And finally (I've also done this programmatically, and it would be tough to make automatic):  lock several chart scales together.  If an operator changes scale on one XY graph, the others change to match.

 

 

Hi there,

I'd like to have a new rectangular boolean button with an LED included. Just like the already available "Push button"

 

Greetings

A.

 

PS: For some reason, I can't upload an example image directly to this post, so please see the attachment...

Like clusters order, I would like to have them ordered just like I order my folder, not in alphabetical order. This could make easier to use them.

 

 

LabVIEW 2012 behavior:

 

obprop.png

Move the create subVI to the right click menu for highlighted code.

One thing that has always annoyed me about resizing of loops is the inconsistent (at least to me) behavior when it comes to resizing them, and the movement of the loop terminals, depending on whether or not something is connected to them. The behavior varies depending on whether or not you have AutoGrow enabled in the options, which is even more confusing since that setting affects when you shrink a loop.

 

Behavior 1:

resize_BD.png

 

Behavior 2:

 resize 2_BD.png

To me this seems like inconsistent behavior, though others may see it as perfectly consistent. May I humbly request that, at the very least, there be a consideration that when resizing loops, the iteration and conditional terminals are never "lost", regardless of whether AutoGrow is enabled or not?

 This idea was brought about my Altenbach's latest suggestion (found here, go vote for it its a good idea!).

 

I would like to see LabVIEW be smart enough to auto increment the number if it occurs in the middle of the name, not just at the end.

For example, if I duplicate a control called Motor 1 Status, I get Motor 1 Status 2, rather than Motor 2 Status which would be better I think.

Please make it so that an unconnected bundle is an error.  Below is an example of current behavior, where even though the bundle by name is disconnected on the output, it does not cause an error.

 

DisconnectedBundle.PNG  

There are lots of ways to convey information graphically to your users. For example, you can use size, shape, pattern, and saturation/transparency. The differentiation between any two pieces of information becomes even more apparent when you use multiple approaches.

 

One of the things we are commonly taught not to lean on for differentiation is color. To differentiate the color of two objects, the eye needs a sizeable area of the colors to be able to view them. (Figuring out the color of small or thin objects can be very hard.) And then there's the ever-present threat of colorblindness in the user.

 

Why are the access scope icons used in classes and libraries small and identially shaped, differing only in their colors? I find myself leaning in to the monitor any time I want to figure out whether a class method is private or protected. It shouldn't have to be this way.

 

unhelpful.PNG

 

I'd like to see access scope glyphs that are:

  1. Slightly larger. So much detail is put into the project item icons, and so little of it is useful for determining what kind of project item that is. Why not dedicate more of that space to the differentiating information, like the object's access scope glyph? That would keep me from squinting so often.
  2. Uniquely shaped. UML uses a plus sign (+) for public scope, a minus sign (-) for private scope, a hashmark (#) for protected scope, and a tilde (~) for package scope. I'd like to see the glyphs shaped like this, so at a glance I can know a project item's scope without needing to figure out its color.

(Since LV doesn't have a "package" item, I would suggest that we overload the tilde (~) for Community-scoped items.)

 

helpful.png

 

I am not an artist, nor a graphic designer. If you like my idea but hate my glyphs, I'm open to replacing them with prettier ones. 🙂 In case you do like my glyphs, I've attached them for anyone to use.

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:

 

ToMoreSpecificType For Strict VI References.jpg

 

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:

 

ToMoreSpecificType For Strict VI References #2.jpg

 

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.

 

 

The Unit Test Framwork provides some useful statistics on code coverage and project coverage of tests but these mean that it is much slower than other frameworks.

In particular the project coverage causes a very long results load time (>5mins AFTER test completion) on a RT target as it appears to load (and possibly compile) the VIs for the target.

 

It would be great to have an option to disable these high levels of reporting for day to day tests to speed up development.

I recently had a tough nut to crack.  I had created an XControl whose "Label" (i.e. Visible name) I wanted to be able to change at run-time.  This was a label INSIDE the XControl, not the label of the XControl itself.

 

My naive self decided to create a property node named "Label" with a read and write VI.

 

Guess what happened.... The property nodes attached themselves to the already existing "Label" property for the XControl itself.  Only by going into XML-editing mode could I undo this effect and rename the short AND long versions of my property node.  While I was intrigued and almost wanted to see how many other properties I could access this way I thought better of it and want to change the behaviour for future generations of LV.  If a user tries to create a property node for an already existing property, please let them know they are doing so.

 

I had briefly, through non-reproducible steps, managed to create a property node for WRITING the "Label" (the inbuild one, not the one I WANTED to create) reference to my XControl.  I refrained from seeing what would happen if I did so.....

 

Shane.

It would be nice to have the ability to delete channels and channel groups directly from a TDMS file without having to convert to TDM to do the edits and then back to TDMS.

The Filedialog Express  should have an option to confirm overwriting a existing file. Like the Open/Create/Replace File

 

filedialog.PNG         replace.PNG

 

 

 

Hello,

 

Recently we do not have real control on the shortcut menu. We can modify/disable the Graph's Run-Time shortcut menu, and we can access Events of selection for example. This does not work for the Plot Legend: if someone wants to use the legend, but for example exclude some of its options from the menu list, recently is not possible. We have neither Events associated with the Plot Legend Run-Time Menu Shortcuts.

Could this be fixed/enhanced? Either to give an option to have the same custom modification as for the Graph's menu, and/or get Events (filtered too) for this menu.

What do you think?

 

Idea came from this post: http://forums.ni.com/t5/LabVIEW/Export-Data-Right-Click-Graph-Display-Format/m-p/3337820/highlight/true#M979937

I would like to be able to obtain the IP Address of an application instance.

AppRef-returnIPaddress.PNG

 

 

Here is one scenario:

 

Plug in architecture.

Host machine loads plugin VIs that monitor several targets via VI Server.

The main VI opens the connection to one of the targets' application and sends the application reference to the plugin so this VI knows what target is communicating with.  

 

It would be nice to be able to obtain the IP address from the Application Reference via a VI or a property node. 

 

Now, I know I could be sending the IP Address instead of the application reference, but if I know I am going to be calling several VIs in the same target, why do I need to open an application reference for each VI, when all could share the same application reference.

 

Another scnerario for this was posted here: http://lavag.org/topic/6861-address-of-an-application-instance/

 

 

As outlined in a post in the NI forums HERE, and seeing as I'm currently being forced to re-install several LV versions on my Laptop (Have been doing so since yesterday!) I want to re-iterate my affinity for having LV installed in a Virtual PC.

 

Memory problems, Hard disk crashes, Virii, stupid user: there are many reasons why an OS would need to be re-installed.  In my case it happens that my HDD was on its way out.  I think this may be linked to many crashes I have been experiencing over the last 8-9 months.  I am nor re-installing ALL of my LV versions.  This is a major pain in the tuchas.  I have backups, but I would rather re-install since I don't know when the data corruption started.

 

Being a nice law-abiding citizen (or a sucker, depends on who you ask) I don't want to violate NI's EULA by installing each LV Version (Ideally each quarterly update)on a separate VM.  This violates rather quickly the "install on 3 PCs rule").

 

Please please let us install on many Virtual PCs as long as they are not distributed amongst other users.....

 

Did I say PLEASE?

 

Shane

I would like a public folder to be used as the default storage for the Icon Editor

 

OR

 

At least a public folder it looks to as well as <osdatadir>:\Icon Templates.

 

The reason for this is I would like to install icon templates as packages using VIPM/OGPB.

The current user-specific location of <osdatadir>:\Icon Templates does not suit this framework for managing packages.

Instead Moving to cases instead selecting one by one every time,  whenever we highlight the cases it has to show the cases.  It will reduce the

programming or debugging time.

 

 CASE STRUCTURE.png

Let's have the following standard situation:

 

Project

 

 

 

 

 

 

 

 

It happens quite often that you accidentally start dragging the class in the project window and sometimes you drop it outside of the containing lvlib. Now if you don't realize what has just happened, you drag-and-drop the class back inside the lvlib and save everything. Which means you've just lost the mutation history data and cannot load your persistent data any more. This is extremely dangerous (unless you have a quite fresh backup of your class).

 

I suggest that a serious warning message is popped up every time a class mutation history is about to be destroyed.

There needs to be a LabVIEW API for Requirements Gateway.  API functions would be

 

1. Open/Create Requirements Gateway Project

2. Add/Remove Requirement Document

3. Add/Remove LabVIEW VI 

4. Get Code coverage

5. Create Report

etc

 

I think this would be extremely useful with trying to dynamically get code coverage, and really extend functionality