LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
  • Issue 1: Block Diagram Cleanup is very close to the Reorder button and can be hit my mistake.

 

  • Issue 2: Cleanup Options should be made available per run. Currently, it takes several clicks and scrolling to get to the options.

 

  • A Confirmation Dialog Box with Options, like the one shown, would address both issues...

 

BD_CleanDialog.gif

As we us Ctrl+Z for other program we can go quite back but in case of LabVIEW we are usually limited for 4 to 5 steps only. I think there must be some option to go back more step because some times in block diagram it happen which bother a lot specially if your not in good mood 🙂

Imagine you develop an VI that generates serious errors and you would like to force a calling VI to handle them. This ist not possible is the current and previous versions of LabVIEW.

 

Typically a library VI does not know how to recover or to handle the errors. The calling VI has the responsibility to handle such subVI errors or to propagate them to its caller.

 

The following VI snippet shows the idea of the error handler structure. I am using this work-around to imitate a try-catch mechanism, but still missing the complete list of possible errors  of subVIs.

VI-Snippet: Exception Handling (LV 9.0) 

 

The calling VI needs to know all possible errors/exception that can be thrown by a subVI. At the moment a develeoper has to check the blockdiagram, VI description or manual to get this information. From my point of view this error/exception information must be part of the VI's public interface.

 

So, I propose an additional category in the VI Properties dialog: "Exceptions" and a "try{...} catch(exception){...}" programming structure.

- The Exceptions category should contain the list of possible exception that can be filled by the developer, Error/Warning code, description etc. Additionally the developer should be able to pass data to the exception handler, e.g. similar to dynamic event dispatching to the event structure. Of course the corresponding data types need to be defined somewhere in the VIs public interface, e.g. typedefs(.ctl) or subclasses of a generic exception class.

- The "try{...} catch(exception){...}" programming structure could be designed similar to the event structure with dynamic events. The timeout case would correspond to the try-block, other cases implement the catch(exception)-blocks. Since exception are part of the VI's public interface, possible exceptions coud be selected from an context menue that contains all possible exceptions of all subVIs in the try-case. All exceptions not handled here will be propagated to the calling VI. Of course this unhandled exception become automatically inserted in the exception list of the exception-category of its VI-Properties.

- Missing exception handling when using subVIs that have defined exceptions will break the VI Run-button.

 

I think it is absolute necessary to become able to force a subVI user to deal with possible exceptions. At least all VIs contained in vi.lib should have at least an explicite error list in its VI Properties as part of their public interface.

 

What's your opinion?

 

Regards Holger

I know that I can set the default for new VI to make inputs required but there should be a way to "make all connectors->required, recomended or optional" (a menu option similar to the make this terminal-> option).  There is a menu option to do this on a per terminal baisis but I dont see one to do it for all terminals.  For me this is useful when refactoring and cleaning up someones (or my) legacy code.  I find that the majority of terminals should be required (this is why by default I make mine required).

 

Is there already a way to do this?  I realize that I could probably do this with an external vi but this is more work.

Creating a decent icon could take longer than writing the VI itself. Additionally, creating a decent icon requires graphic art skills most people don't have. Furthermore, for most VIs there's no obvious choice of a good icon. Often, the most practical thing to do is just put text on the icon.

 

I propose adding a feature to VIs where you can quickly apply an option or feature to have the VI name appear in some way on the block diagram to represent the VI instead of having to create an icon.

 

This is not meant to replace the use of icons on VIs altogether. Icons are good for localization and can give a professional look to VIs at the API level. This would be used for cases where localization isn’t an issue, it’s not worth while to take the time to create an icon, and text would likely be more clear than a graphical icon anyway.

 

 

There’s many ways this could be implemented. Here are some possibilities:

  1. VIs could have an option to specify that an icon containing the VI name appears on block diagrams. See Figure 1. The VI icon would be created and managed for you and update if you change the name of the VI. You would not be able to manually edit the icon.
  2. VIs could provide a way to generate an icon for the VI that contains the name of the VI. You could then use the icon editor to further edit the VI icon. You could regenerate this icon if you changed the name of the VI.
  3. Currently, on a block diagram you can select Label and Terminals as visible items for a VI. The Label shows the VI name, and the Terminals show the terminals instead of the icon. VIs could have an option so that the Label and Terminals are always on the VI on block diagrams. See Figure 2. When using this option, the VI wouldn’t have an icon you could edit or view.

With implementations 1 and 2, if the VI is part of a library (or project) the top of the icon would have a banner for the library in case two VIs in different libraries have the same name. See Figure 3. The banner could be the library name, or there could potentially be a way associate a custom icon template with the library to specify a graphical library banner.

 

 

With implementations 1 and 2, it’s possible that there isn’t enough room to fit the VI name you want on the icon, or least not at a reasonable font size. One way of dealing with this is there could also be a way to specify a custom name instead of using the VI name. If the VI name doesn’t fit, you could specify an abbreviated name to use instead.

 

 

Another way to deal with VI names not fitting on an icon is to allow VI icons to be of size other than 32x32. This would likely be a separate feature you could use with any VI icon.

 

 

I’d appreciate feedback on which of the different implementations you like, on how important it is to allow icons of sizes other than 32x32 for this feature, or on any other aspect of this idea or other directions you’d like to consider.

 

Figures

Add the ability to configure a contextual menu when a user right-clicks a control or an indicator. Configurable in the properties of the objects and available triggers for the event structure.
It would be nice if LabVIEW automatically check for updates and notifies the user of all of the upgrades available for everything that they have registered. It would be nice if patches were just down loaded and installed much like the Windows Updater function. It would keep LabVIEW, all of the tool kits, Measurement and Automation Explorer, and every licensed software up to date. It could also push down labview as long as you are on the subscription and current.

Hi

When I use one single DAQmx VI and then I open menue for relationships I see hundert of the NI VI's

I need a checkbox in the option for not seeing all this VI's

 

 

 Jürgen

 

 

 

 

 

BrowseRelationships.JPG

 

Hi,

 

there is an idea about making labview.ini and other user configs to the corresponding user folder .

 

I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.

 

E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).

 

If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).

 

Regards,

Marc

Link the control, indicator or constant to the type def when creating it from the contextual menu of the value property node.

I don't know with which version of the NI-488.2 driver this changed, but for a while now when one scans for instruments connected to a GPIB controller in MAX, that list is presented at the bottom of the controller's Properties tab in a list that cannot be resized and is tall enough only for four items.

Yes, I do know that I can expand the controller item in the Configuration tree to access all of the intruments connected, but in that list it only says Instrument0, ...

I really liked the old way, where the list of connected instruments was the default displayed and you could see all your 14 instruments at a glance with PADs and Identifications. To me this information was a lot more useful and the list of GPIB properties that is currently displayed.

 

So my suggestion is to display the list of connected Instruments its own tab and display that tab when the user presses 'Scan for Instruments'.

When I write instrument drivers for new instruments I do use the NI-488.2 Communicator, which can be accessed from MAX, to try out various GPIB commands.

The one thing that drives my absolutely insane every time I use it is this:

 

When one types a command into the 'Send String:' control and happens to hit 'Enter' (as I am prone to doing when entering text) the program exits!!!

 

I have lost count of the number of times that this happened to me.

Why did National change the way pasting objects on either the front panel or block diagram?

In 8.2 the paste (Ctrl-V) would paste the clipboard where the cursor was last clicked. 

In 8.6 (or possibly 8.6.1) it always pastes it in the center of the panel or diagram and is floating.

This is very annoying.

 

0 = Enabled

1 = Disabled

2 = Disabled and grayed out

 

error.jpg

When working with reentrant VIs, every time you double click an instance of a reentrant vi on the block diagram, the cloned instance is opened. This is fine during debugging but during development when you want to modify the actual code this requires that you open a clone, then CTRL+M to open the actual master vi. Much more frustrating if you have to dig several VIs deep through a highly reentrant hierarchy.

 

We have CTRL+RT Click to open the block diagram directly, how about something like ALT+RT Click to open the master VI instead of the clone.

 

Under normal development this is not such an issue but if you happen to be working with LV FPGA, just about everything is reentrant.

It would be nice, if the different kind of LabVIEW windows would have slighty different icons within the windows taskbar. It would be easier to quickly identify BD / FP / project / Ctrl / etc. windows in the taskbar.

 

This suggestion has also been made at

http://www.labviewforum.de/unterschiedliche-Symbole-fuer-Frontpanel-und-Blockdiagramm-in-der-Taskleiste-t13546.html

Here you can find two suggestions for FP & BD-icons.

Insert a library in a class
When you select "Advanced->Customize..." on a control you can't Select a second control and do the same. 

This way it's a pain to "copy past" image from one to the other control. It should be possible to customize two controls at a time

  

EditTwoControls.png

Say I have a numeric control on the front panel whose value is 3.8.   If I put my cursor after the six and increment it (using the inc/dec buttons or the arrows) it goes to 3.9, 4, 5, 6.  It should go 3.9, 4, 4.1.

 

Inspired by this idea... Changing the fill colour of thermometer according to the temperature

 

You want to customize the behavior of a LabVIEW control or indicator. The normal answer is to create an XControl. The problem is that you want to the XControl to have the same properties and methods as the base control. You have to recreate all the methods and properties yourself and then handle them all in your facade.

 

It would be nice to be able to create an XControl from a base control with all of it's properties and methods created for you. The you could then extend a base control instead of recreating one from scratch.