LabVIEW Idea Exchange

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

I think it would be great to allow zooming out on a block diagram. I know we should make all attempts to code on the available window space without scrolling but it's not practical in some situations.

The Vision Acquisition Software seems to send all GigE attributes to the camera that have been set in the camera file. There should be an option to select which attributes are sent to the camera when connecting. This would allow the settings configured through vendor specific third party tools to persist when acquiring in MAX or LabVIEW.

 

This could possibly also alleviate the "Attribute value is out of range" error if MAX is only sending the attributes you specify.

All the time I make type def enum's in order to use with a state machine. Most of the time I create the enum from the block diagram instead of the fp. Maybe I should change my habit but I wish there was a "create type def" option on the bd right click menu so I didnt have to change to control, switch to fp, customize, then change back to constant.

 

 

 

I have seen ideas for automatic creation of constants, but here is one for easier manual creation. 

 

Simply hover the mouse over a terminal as usual, and then press 1, 2 or 3 to create a constant, control or indicator.  No mouse-click needed.

 

I have attached a vi that uses VI Scripting (LV 8.6.1) to demonstrates this functionality.

 

Regards,

David

 

Instructions are on the front panel of the vi, but here they are again:


Instructions:
1. Run this vi.
2. Open a new vi and place an "add" function on the block diagram.
3. Hover the mouse over any terminal and press 1,2 or 3 to create a constant, control or indicator.

Of course, this will work for existing vis as well, and with any terminal on the block diagram.

Enable a Sub VI to launch as a daemon without having to open a reference to it using its path.  The VI Properties page would look like this:

 

21429iB830C4B88A795136

Wait until done would be checked by default, and auto dispose reference would be left false be default.  So instead of parsing the path to the VI on disk and using a method to run it:

21433i0CFC0F873277247C

I just set the correct properties in the VI Properties page and drop the subVI on the block diagram of the calling VI.

I was just involved in a discussion about a default return value for the dequeue primitive when a different idea struck me.

 

Why can't we define a default value for typedefs.  Especially enums would benefit by having a case reserved for operations where something didn't work as expected and a default value is returned.  Being able to seperate this value from other (normally required) values would be a boon for ensuring data integrity.

 

21307i98E925E66B45E54C

 

Why can't we have the default value set to something we don't normally interpret as being valid?

 

In the LLB Manager, it's nice to have a separator between Top-Level VIs and the subVIs.

 

I'd like to see something for a mid-level VIs. This would allow the "major" (but not top-level) blocks of code to be easier to find when developing, separating them from the low-end subVI pool.

 

21151i6B3333152562E342

In their current form, Auto-Indexing tunnels only operate on a single dimension of an array.  For example.  If you input a 2D array, through an auto indexing tunnel into a for loop, and display the resulting 1D array in an indicator inside the for loop as below, you will always get the last row.

 

I'd like to see a feature where you can right-click on the tunnel or something, and set it to auto-index by column, instead of by row, and get the last column instead.20773i86B483107F51CD3820775i651136B201680B64

 

It could be as simple as an option in the context menu for the auto-indexing tunnel to say "Index by rows" or "Index by columns"  It gets more complex with 3D 4D and moreD arrays, but you could do something like a submenu flyout that says "Index By Dimension" > "1", "2", "3" etc

 

a transaction log of all docked probe window activity, in a human readable format if possible. it should include probe position declaration, timestamp, data and conditional probe result. the transaction log is 'dumped' in a separate window, and optionally saved to disk. it is meant to work a bit like dbgview, which displays information sent via OS outputdebugstring() or debugprintf() on windows. maybe something like this already is implemented in the desktop execution trace toolkit 'DETT', but this idea is only for data of probes and is native to IDE. if gives a migrate path to DETT to see more info about execution behaviour...

I just downloaded a library and a project it was developed in. I tested it, and everything works fine. Then I copied the library (.lvlib, all .vi files and preserving folder structure) to a new project, but when I open it I get a conflict saying that the same library is defined twice? A conflict that cannot be resolved BTW.

 

I spent 30 minutes just getting out of the mess this puts me in. The result, project2 is now OK, but project1 now complains that it has duplicate code. Come on! I know I have two copies of the same library! I want to have two copies of the same library! Why can't LabView just use the "local" version and not complicate my life with something that happens to lie on the disk somewhere and has absolutely no connection to the current project?

Problem is that sometimes a front panel control is so big, that it takes up too much real-estate.  (Especially, if you are using a lot of elements within a cluster.)

 

One nice solution, would be to allow the control to be collapsed down to an icon of some sort.

 

This can easily be demonstrated by the similar behaviour of references that allow the option to "show control".

 

 

From this.....  Queue Refnum (Show).PNG                    To this...   Queue Refnum (Hide).png

I often use strict type definitions to change data between SubVIs. The wires of the type definitions are always pink and this is sometimes a little color chaos.

Strings are pink, clusters are pink, ...

 

It would be nice to have the feature like in the LabVIEW classes. There you can definie the look of the private variables wire (form and color).

 

 

Often I'm developing applications that use large clusters for typedefs. Instead of resizing the cluster, I often turn off auto-grow on a case structure to prevent the large cluster from exploding my block diagram when it is placed. I think it would great to have the ability to show scrollbars to better navigate inside structures when screen real estate is an issue.

We all (should) check if an array is empty before passing through a For Loop, if we are indexing it and any references or values pass through the For Loop so that we pass null references or default values for the data type.

 

Most people use either an "Array Size" primitive for selecting "0" or "Default" or an "Empty Array?" primitive for selecting "True" or "False" in a case structure around the For Loop.

18049i62E217D020F17D5C18051i254696F87AD8D82F

If we could just wire the array to the Case Selector and have it automatically create two cases "Empty" and "Has Data" or something, it will make the diagram cleaner and easier to read, while saving a few second for every instance of use. 

18053i19D01296C2C082C8

A lot of the vi icons I make only have text inside a box. It would be neat if the text could be inserted in the icon from the name of the vi, without me having to type it in. Of course you have to name the vi in such a way that it all fits in the icon.

 

Also, this function should be optional, so if you wanted to make a glitzy icon, you could, just as we can now.

Using the LabVIEW 2009 Build Spec (as an example) allows you to add a Destination to a Library which is very handy, as it means you can namespace VIs at build-time.

 

I would like to take this a step forward and then be able to set that new Library as a Sub-Library of another Library that already exists in the Project.

I would then want to be able to set the scope of this Sub-Library as well (relative to its now, Parent).

 

This combined with my Locking State Idea would allow be create a Distribution that would hide and protect a Support VI Library

As the Sub-Library would be Private Scoped (from above) and the Parent Library would be set Locked (does not show Private Members).

 

I currently can implement this using Scripting but it would be nice to have it native.

 

Cheers

-JG

 

 

17619iFB1C3A1375DBE39317621i6935DFDFCA489040

Hello!

 

What I really would like to se implemented as a future feature is a 'Search 1D Array.vi' with the option to do a case insensitive search.

 

Usually I just plug a "to upper case" vi on both array and search string inputs. It would be nice to be able to select it right on the vi instead.

 

The functionality should work as with the case insensitive match in the case structure.

 

 

Cheers!

//Beckman

It would be beneficial if nodes had the ability to retain data from their previous execution. Along with "Use Default If Unwired" it would save memory allocation and coding time if there was a "Use Current Value If Unwired" selection which would retain the node's value and pass the last executed value. 

 

 Use Current Value If Unwired.PNG

This figure illustrates one application where "Use Current Value If Unwired" would save memory and increase performance instead of using multiple property nodes or local variables for retaining the output data. It would also eliminate extra wiring in every case this node is not used.

Hi,

 

in LV2009 a new set of VIs have been published for working with configuration VIs. They are now part of config.lvlib. But some VIs of config.lvlib are marked private, therefore I cannot use these VIs as Sub-VIs, if the calling VI is not part of config.lvlib. This is bad (at least for me), since I have written some tools to load a configuration directly from a string and not from a file. To do this in LV2009, I need these private VIs, which I cannot use without changing config.lvlib.

 

Therefore I suggest to make all VIs of config.lvlib public. In fact, is there a good reason, why these are private in the first place?

 

Regards,

Marc

When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).

 

An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".

 

Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.