LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (9)

Hi,

Stacked shift registers always has the most recent value at the top, no matter in which direction you start your mouse drag on the shift register node:

Sometimes it could be more optimal to reverse the stacked shift register direction, just for the sake of neat wiring. In that case it would also be necessary with a visual aid (in addition to the tooltip which isn't visible unless you hover your mouse over the object) telling you which is the most recent value; the one at the top or the one at the bottom:

This "dimming" of the older values in the stacked shift register also makes it easier to tell a stacked shift register apart from ordinary shift register that just happen to be very close together.

Cheers,

Steen

Optional maximum block diagram size

Why does the block diagram span 1000's of pixels. I would like to allow a block diagram size maximum to be specified on a vi basis. This way I could set my vi to limit the block diagram from 0,0 to 1200,800 for example. This not only forces good style but also prevents the inadvertent placing of functions off the screen (have you ever dropped a functional global call by mistake off the field of view by mistake and tried to debug the vi?). This feature would be optional so use it if you like (or impose it on your new programmers). If set on an existing vi, the code would be moved into the field of view with a warning message if position coerrsion is needed.

View All (1)

Allow multiple event callback VIs

As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI. The only problem is that there can only be one Callback VI per LabVIEW installation. My suggestion is to allow more than one callback VI to be called when the events happen. This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.

This is similar to my previous idea, but generalized for all the callback VIs.

View All (5)

As of LV2010SP1, there is no good way to interact with the Right-Click menu of a control programmatically. You can create a custom right-click menu for a control at edit time, and as long as you save the menu with the control (saving it as a discrete *.rtm file doesn't work--see CAR #256160), you're in business.

But if you want to make sure multiple controls all have the same menu, you're pretty much out of luck. There is no way to programmatically load an *.rtm file for a control. The best you can do is build up the menu one item at a time using the menu primitive functions. And you have to do that on menu activation event, because you can't get at the control's menu reference any other way.

This is pretty kludgy.

The other solution is to make those controls strict type definitions, but that isn't ideal in a lot of cases. For instance, I want to make sure all the XY Graphs in my application have the same RTM API, so I could use a single strict typedef, but that sucks if I don't want them all the same size, etc....

So here's the idea: fix runtime menus for controls.

Add an "RTM Path" property for all LVControls to allow loading custom RTM files at runtime.
Add a "Runtime Menu" property to all LVControls to grab the menu reference at runtime.
Make sure that RTM files are loaded properly in EXEs (see CAR #256160)

View All (2)

Better insert objects in diagram

I have searched for a similar idea (or even a discussion of the underlying problem) but couldn't find a good hit, so here is it.

Let me start with an illustration of today's trigger to this suggestion:

I have got square miles of real estate available to the right of the diagram, so I would expect the super-clever engineers at NI to have tuned the insert algorithm so that it nudges the indicator slightly to the right to make space for the "Transpose" primitive.

Instead, I get this:

Of course I can select the two objects and choose "Diagram Clean Up" (probably one of the rare instances where I would dare use the dreaded tool!), but I would argue that an intelligent diagram editor should be able to do that automatically.

Note that I am not even talking about insertion WITHIN a structure or towards the innards of a diagram.

Here the failure is complete, EVEN when autogrow is enabled (which I did very temporarily for this illustration):

==========>

Notice that the For Loop DID actually grow A BIT, but definitely not sufficiently for a satisfactory result.

In the absence of enabled autogrow (which is my normal use case), I would suggest the insertion to actually do some limited cleanup afterwards... Maybe something like that:

I am not saying this will always be possible, but at least try!

And, oh, BTW, this problem is definitely part of the illustration of this idea (and probably should be promoted to the status of a bug, IMO).

View All (1)

I propose a “Preserve Run-Time Type” primitive for Variants that is analogous to “Preserve Run-Time Class” for Objects. Below I illustrate, using a system of messages that I'm working on. Two message types carry either Variants or Objects (LVObject). In each case I must convert to a specific type (data type or child class) in order to use the messages data. For this I can use "Variant to Data" or "To More Specific Class", but I need to do the conversion outside my "Read Message" subVIs (top two examples below).

However, with Objects I can make a cleaner implementation (third example) where I use "Preserve Run-Time Class" to do the same thing inside the "Read" subVI. I would like to be able to do the same thing with my Variants but I cannot (but I've faked what it would look like in the forth example).

The object subVI that uses Preserve Run-Time Class looks like this:

A subVI using “Preserve Run-Time Type” would look similar, just with Variants in place of Objects.

In addition to cleaner code, “Preserve Run-Time Type” would allow additional logic to be built into the Variant to type conversion. For example, I like to use numerics with units in my messages, as a safety device against message sender and receiver using different units, or confusing what the message represents. However, one can always convert a numeric with units to a numeric without units by using "Variant to Data" with a non-unit type input. This defeats some of the safety (eg, sender could send "output" in Watts, but receiver thinks it's in Volts). I would like to make a message type that performs unit consistency checks inside the "Read" subVI, throwing an error on any mismatch; a “Preserve Run-Time Type" would allow this.

View All (1)

Call Library Function Node

It should be nice to be able to create a "typedef enum" for the pages of a tabcontrol ...

So the modification of a tabPage label could be automaticaly propagated to constants ..

The problem is ... When you modify the pages labels, and if you use the constant value associated with the pages ...

The associated wires are then brocken ... They are not automatically modified

When you only want to modify the Label of a tabPage (For example to correct a mistake), the Vi will no more work !

An other idea would be to add a kind of "Caption" to the tabPages, in order to disociate the 'Display name' and the Variable name ...

Here a short example ...

Other Idea : (From the well known Roms)

It should be nice to create the TabPages of a TabControl automaticaty from a typedef enum, and keep the link between the two items.

=> Modification of the TabPages modifies the typedef enum

=> Modification of the typedef Enum, modifies the TabControl content

View All (5)

When placing a property node on the block diagram, it is often set to read. I find myself having to right click on the property node and select "Change to Write".

It would be great if there was an option where the user could select their preference when the property node is placed on the block diagram. This would provide a more efficient way of pre-setting all the property nodes to Write or Read based on useage.

I checked and did not see a similar idea.

View All (2)

The simple suggestionis, in case a search is initiated from a diagram or front panel (by a right-click aciton), to memorize internally where that query was sent from, and provide a link back to that place in the Search Results window.

Of course if the Search is initiated by a Ctrl-F, it is probably a lot more complex to restore the situation to what it was before the search (windows could have opened, or be brought into focus, etc), so I am not including this in the suggestion.

Case study:

I find a reference, or a terminal, or whatever that belongs to a control or an indicator.

Now, I want to check all the places where a Property Node for this object appears.

I right-click >> Find Property Nodes and get the Search Results window opened.

Now, should I select any of the hits and try to "Go To" it, I instantly loose the location I started from (and where rather naturally, I may very well want to come back to resume work).

Of course, as a possible workaround (assuming I think about it, which is unlikely), I could drop a simple bookmark like #0 and once done with my PN exploration, go to the Bookmark Manager and find where #0 is located, but I will probably foget to do that most of the time.

PS: this is different from this idea, although the title may make it sound similar.

View All (3)

LabVIEW Idea Exchange

Native Ternary Logic support (3-valued logic)

Selectable direction of stacked shift registers

Optional maximum block diagram size

Easier source control: Check out/Check in VI from buttons on VI:s own toolbar

Local Variable Manager in "Edit" Menu of VI

Allow multiple event callback VIs

Fix Custom Right-Click Menus for Controls

SubPanel in LabVIEW Getting Started window

Better insert objects in diagram

Programatically Set Up Chart Parameters.

“Preserve Run-Time Type” for Variants (in analogy to “Preserve Run-Time Class” for Objects)

Call Library Function Node

Auto-corrected "TabPage enum" when modifying TabPage labels ...

write or read property node preference set in option

Search Results Window: "Back to Search Origin" button

Improve Error Ring

Auto Subvi suggestion

VI VIewer for mobile app

File IO

Probes with Radix visible