LabVIEW Idea Exchange

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

When using a case structure within a loop for a state machine, or when using an event structure, it is frequently necesary to either add a new case/event or add a new state variable to the structure.  This can lead to unexpected behavior if the user has accidentally used "Use Default If Unwired" on an output node, and will require time consuming wiring of all cases otherwise. The Linked Input Tunnel Option helps with this.  However, the mass of state variable wires, if there are several, still creates a confusing and cluttered diagram.

 

It would be nice to add a "Feed Through if Unwired" option.  This would allow us to wire ONLY the variables that need to change, and only need to examine the relevant cases.  Additionally, you would get a nice clean diagram.  Here is one idea, shown for an Event structure:

 

NI Shift Reg Suggestion_sm.JPG

When building an application, the build will fail if any of the VIs are broken.  But, the build doesn't fail until very late in the build process.  It would be great if the build would fail right away if any VIs are broken.

 

Note: In one of our big applications, it sometimes takes 30 minutes into the build before the build fails.  However, it only takes a couple minutes to detect this by loading the VIs into memory and testing if they are broken.  So, as part of our one-click build, we implemented a pre-build test for broken VIs and abort the build -- this saves us a lot of time (in cases where the build is broken).

At the moment you can Register for Events using a Cluster of Refnums.

But you cannot Destroy User Events or Unregister for Events in this way.

 

This approach allows for you to scale your application without the need to change the code that handles Registering Events.

It would be very convenient to be able to close references in this way (using a Cluster of Refnums) too, as per my illustration below:

 

21670iEFD0527198796259

One of the quickest (and easiest to forget) methods to improve performance of your VI is to disable debugging.  It requires a trip down the VI properties to get there, however.  I propose adding a button on the BD alongside the other debugging buttons to Disable and Enable Debugging.  

This LV typedef for the Waveform Graph property Cursor List is missing Line Width and Line Style! This is probably a solution to the mystery behind another post Show Attributes Selections I made earlier today. In order to completely define our Cursor List properly with one Property Node, those two elements must be part of this public typedef.

 

CursorListProperty.png

CVI has this feature, almost every other UI library has it, too.

Only LabVIEW is missing the simple option to limit the number of characters that can be entered into a string control.

 

I know, it is possible to do this programmatically. But this is always a piece of extra effort I have to undertake, while the solution never looks really satisfactory.

Usually all I can do is react to the value change event of a control and cut what's too much. But this means the user sees some flickering, since the character is first drawn and the corrected version is drawn at a later time.

 

Side notes on how I think this should be integrated:

This should be an additional property for all string controls. For existing controls from older versions, the value should be set to it's default (-1), which means unlimited.

If activated, this feature should also cut the strings in VI input terminals to avoid "special behaviours" in this case.

When you do a search for something in the hierarchy and you have a password protected VI, you get this dialog:

 

 

 

 

Often (for example in this case) we don't have the password for the VI and never will because it was developed by someone else. So why not allow us not to see this in the first place?

 

  • First idea - Don't display this at all for VIs in vi.lib. Just skip them.
    Presumably before LabVIEW ships the VIs aren't locked anyway, so the LabVIEW developers shouldn't have a problem, and if they do, let them do a programmatic unlock. The users shouldn't be the ones to suffer.
  • Second idea - Generalize it a bit more. Allow us to have a configurable list of folders where the search won't bother to try and unlock VIs (so that if we have locked code from other vendors, we can discard it as well). The default folder for the list should be vi.lib.
I cannot tell you how much time I spend changing the appearance, properties, connector pane, etc, etc. every time I "create a SubVI".  I try to always use the same connector pattern, error in and error out, error case structure on BD, and even a common icon appearance within a project.  It would save hours over the course of a project if I could set up a template that would be used BY DEFAULT for "create SubVI".  Also, allow me to set that template as the default for "New VI".  Save me the step of File - New - From Template - choose it.  If I go File - New VI, I want to see my default template.  Anyone who has used AutoCAD (2D) in the past will be familiar with this.  One could create a blank drawing and save it as 'acad.dwg' in the AutoCAD program directory and AutoCAD used this as the default drawing template.

If you install anything (anything!) from NI on a computer that runs windows 8 or newer, you will get bugged by a dialog to disable fast startup. The option is enabled by default, no matter what you install. It will popup with every single install, even minor patches, and even if this option has been intentionally unchecked in the original installation to be patched. If you don't want to disable fast startup, it is a never-ending whack-a-mole of these dialogs. (... but the need to disable fast startup for some scenarios is a more general problem that NI needs to address. It could be a new idea, but I think NI is aware of this problem. It might even be something that Microsoft could address such that devices don't get lost in the scenarios where fast startup causes problems)

 

This idea is centered around executables that we built and distribute via installers..

 

While this option (=disabling fast startup) can be useful when certain DAQ hardware is used, it makes absolutely no sense for other LabVIEW programs. Most of my programs don't use any DAQ hardware and it is not reasonable to globally cripple every single computer that has them installed. People tend to click [next] without reading, assuming that the defaults are typically reasonable.

 

Currently, this install query can be silenced by editing the setup.ini and changing the entry "WinFastStartup=1" to "WinFastStartup=0". I have built dozens of applications over the last few days and it is becoming seriously annoying to constantly remember to do that.

 

I suggest that the installer builder should get another checkbox that allows us to set that option permanently. Here is how it could look like.

 

 

  • Checking that box will give the current experience where the installer asks to disable fast startup. (it could even be checked by default to mimic the current default behavior)
  • Leaving the box unchecked will skip that dialog and will not disable fast startup.

 

IDEA SUMMARY: Allow us to configure the fast startup dialog from the installer builder tool.

 

 

taking ideas like that seen here  , I got this idea: 

 

 

When working with "Path Constant", which works with a path too long, we observe look like this:

path2editado.PNG

Would be much nicer if we could double-click the “Path Constant” for us to see something like this:

path3 editado.PNG

The idea is this.

path idea labview editado.PNG

Hi.

 

SubVIs are sometimes easily missed in a block diagram when you glance over it, and their current configuration is impossible to determine unless you open up each subVI and examine its VI Properties. I suggest a quick way to highlight and configure subVIs within a BD. Consider this section of code:

 

SubVI_Clean.png

 

Then one could hold down the ALT-key (or some other easily accessible interface) to get this view, which gives you an interactive highlight glyph overlay on top of each visible subVI. Letting go of the ALT-key returns your BD to normal of course:

 

SubVI_Alt.png

 

The interactive highlight glyph gives you direct access to this for each subVI:

 

- It highlights where in the BD there is a subVI.

- It shows if the subVI has unsaved changes.

- It shows the runtime priority of each subVI (more on that later).

- It shows the reentrancy mode of the subVI (as well as inlined/subroutine state).

- It highlights any unwired required inputs of that subVI.

- It shows if the subVI has debugging enabled (which can have a negative impact on performance).

- It illustrates if the subVI is otherwise configured for optimum performance (more on that later).

 

More on the subVI highlight glyph:

 

 

SubVI_Highlight_Details.png

 

I imagine tooltips might pop up containing additional info if you hover the mouse pointer over the elements in the glyph. I think clicking the "unsaved changes" asterisk should save the subVI with all the bells-and-whistles as if you opened it and did CTRL+S on it. I think clicking the "Debugging enabled?" element should toggle the Allow debugging property of the subVI directly. I think clicking on the colored frame should open the reentrancy setup dialog of the subVI. The colored icon frame is part of many LabVIEW style guides for icons btw, but not everybody is familiar with them, and thus don't use icon frame colors like this. Also such colors might clash with other style guides - class icon templates for instances, or company logo colors. That is why I propose the reentrancy setting being part of this subVI highlight glyph.

 

More on subVI priority:

 

I have earlier proposed a much simpler way of defining subVI priority with a number, which is along the lines of how it's defined in a timed structure, instead of the current way of setting Priority and Preferred Execution System in VI Properties (which many people find hard to figure out and keep mixing it with timed structures). That idea can be found here. This priority number is what I propose is located on the subVI highlight glyph. Clicking on this element in the glyph should open the subVI's Priority setup dialog directly.

 

More on the "optimum performance" element:

 

I haven't really thought deeply about this element, but I see it as an indicator of if "all the rest" about the subVI is optimized for best performance and least runtime pitfalls. Stuff like making sure Enable automatic error handling and Auto handle menus at launch are disabled. Anything outside of the optimum will light this indicator. Clicking on it should open the subVI's VI Properties dialog or similar.

 

What do you think?

 

Cheers,

Steen

Hi all,
For a lot of reasons, I have to work with several LabVIEW versions.

My biggest fear is to save something in a later version : projects are quite big, and a save for previous version is hard when using terce parts (such as OpenG, JKI, etc.)

My whish would be to have a warning message when I save a vi in a new version, such as :

"You are saving a 8.2 file in 11.0 : do you want to continue ?"

 

 

Have a nice day !

Viewing this suggestion requires a bit of setup

  1. Forget you know what Silver controls look like
  2. Think about it from a user point of view
  3. Imagine a set of indicators including a sole boolean indicator show up on the screen. You have no comparison to other states of the boolean indicator.

New Bitmap Image.png

Is it True or False?

 

 

 

 

 

 

My opinion is that the gradient and lighter shade of green makes the state a little ambiguous. Not too much ambiguity, but enough to give me pause. Decreasing the gradient and darking the shade a little should help.

boolean.png

 

Yes, I realize this is a property you can set. This is more of a suggestion for setting the standard.

(this suggestion aside, my compliments to the designer of the Silver controls)

 

 

             Reset the Probe index when the <Probe Watch Window" is closed


 

original6.png

                              above, the probe index equal 18, however only one probe is active.

 

                When you close the <Probe Watch Window> ...therefore when you close all probes,

                in this case, reset the probe index for the next time.

                It's useless and annoying to have a probe index equal to 18 (sometimes much more),

                when only one probe is active. Thank you.

Much like the ever-popular With with Errors, "Get Date/Time in Seconds" would be great with error clusters for inputs/outputs.  This would help with coordinating timing (start/stop and duration).

 

Here would be an example of what the underlying code is that I currently use:

 

GetDateTimeInSecondsWithErrors.png

 

Pretty simple...  and an example of what the use could look like:

 

GetDateTimeInSecondsWithErrors_Icon.png

 

And a duration example:

 

GetDateTimeInSecondsWithErrors_Example.png

Hi all,

 

Since the release of the new “Silver” control style in LabVIEW 2011, I had the idea of having a style control on the front panel. You would essentially click the drop down box and it would change all/selected controls and indicators on the front panel to that style.

 

Take a look at the mock up below.

 

Untitled.jpg

 

 

The idea could be extended to having a style of control that the User could populate, notice the “User” on the drop down.

 

I hope that you like my suggestion I can certainly see many uses for this.

I would like to be able to create BD array constants from the predefined string and numeric constants.

 

Presently you cannot create an array constant by dropping a predefined constant into an empty array box on the BD.  Arrays of string constants such as Carriage Return, Line Feed, Tab, and Space need to be created programmatically using build array or manually using the '\' codes or hex codes.  Arrays created in such a manner do not have the graphical indications of what is contained.  Some of the constants (Space) are actually VIs, which may complicate things for NI.

 

Similarly the Math and Science constants like pi and e should be allowed to be dragged to an array of DBL.

 

Lynn

Arrays from constants.png

 

 

This idea got triggered by this other idea but this here is a significant variation and deserves it's own entry.

 

There is possibly some need to graph multiple XY plots on the same xy graphs, all sharing the same X values. One problem with the current XY graph implementation is the fact that the x-values need to be duplicated for each plot, unecessarily inflating the data structures.

 

One possible workaround has been suggested here, but I think we can do better!

 

Remember, that in this scenario, all plots have the same number of points, thus the data could fit in a plain 2D array. Why not?

Currently, xy graphs don't accept 2D arrays, so this will not clash. (Of course downconversion will be problematic).

 

I suggest that we should be able to directly wire a plain 2D numeric array to the xy graph terminal. In this case, the first row (or colum as set by a property or other configuration) is taken as X-array, while the remaining rows (or columns, resp.) are Y1, Y2, Y3, etc. arrays.

 

 

(Of course an xy graph should also accept a 1D cluster array where each element is such a 2D array. This is useful if there is more than one set of multiplot data, each with a different x-range or number of points.)

The Class Hierarchy window is a great tool to see the relationships between classes. It would be even better if you could use it to change those relationships.

 

I imagine something identical to the way we program with G: connecting wires and moving around icons. A user should be able to drag a class icon around in this window and wire relationships as they see fit.

 

21133i7D399BB1CC32A52F

 

1. Notice an additional button in the Hierarchy window. This is what's used to draw the relationships.

2. By moving an item out of the row (or column if using the "Horizontal Layout") that it's in, the relationship wire disconnects.

3. Using the wiring tool, a user can reconnect the relationship at a different level. Now the red one I've moved is a grandchild of Green.

4. If the user tries to make an invalid relationship (multiple parents, children higher than parent, etc.), then the wire shows broken. The Class Hierarchy window cannot be closed until it's fixed.

 

 

Discuss! I'd love some feedback on this idea. Good? Bad? Better method available?

 

While helping in the forums, we regularly run into VI's saved under an older LabVIEW version, modify it and post it back, usually saved in the latest LV version. Soon after the original poster complains, asking for a converted copy.

 

Years ago, I even proposed a small starware utility (Get VI version) that returned the LV version any vi was saved in. Unfortunately, it stopped working with LV 8 (and didn't recover since... ;)).

 

I found several proposals for displaying the version number (for instance here and here), but they are related to the application version and not to the vi version. None corresponds to this very basic idea : as long as a vi has been saved in a version different from the one in use, display it as unsaved (using the usual star), with the original version number attached. Something like this :

 

19239i840BEC563A1BADB9

 

Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.