LabVIEW Idea Exchange

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

This is a very small suggestion, and hopefully easy to implement.  When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires.  All I'm asking is that Error wires are always placed underneath all other wires when they are created.  To my mind, this improves the readability of the diagram.

 

ErrorWire.png

 

What would help further is if Error wires were "faded", as if they were 50% transparent.  You do need to be able to see them, but not such that they stand out.  But I'm much less certain that such a change could happen.  The khaki color is an improvement on the old pink though, that's for sure!

 

All events have optional event terminals on the left. Signaling events also have e.g. a "discard?" terminal on the right.

 

Hovering over them with the mouse does not generate any relevant context help, and maybe it should. (well, there is a tip string that simply duplicates what is already written on the terminal giving boring redundant information).

 

I suggest that hovering over an event terminal with the context help open should first of all tell us how these terminals are called in general ("Event Data Node", according to the help, but who knows that???), but also give specific information about each terminal under the cursor.

 

For example:

  • if I hover over the "discard?" terminal, it could tell me that wiring a TRUE would ignore the event, etc.
  • if I hover over the "Ctlref" terminal, it could tell me that it outputs a control reference of the control that fired the event
  • if I hover over the "type" terminal, it could tell me a list of possible types and what they mean.
  • etc.

 

 

IDEA: I suggest to add relevant context help to all event data nodes. Thanks!

 

(Note that e.g. the "timed loop" terminal already have context help. This should be similar)

 

 

When an array leaves a loop with indexing enabled, you get an array which has one more dimension, but quite often you want to concatenate the data to an array with the same number of dimensions.

 

If the subarrays have the same length, you can use reshape array, but usually they don't and you need to do something like below.

 

It would be very useful if output tunnels for arrays had an "Enable Concatenate Indexing" option as well, as depicted below, which would do this.

 

 Concat Indexing.PNG

 

I wonder if newly created wire labels should inherit the wire color for better clarity. Labels on array wires (and other thick wire thingies, clusters, objects, etc) could go bold for the same reasons.

 

 

(Of course the programmer can later freely change these label text properties)

Here's an enum with a lot of elements:
enum1.png

 

The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:
enum2.png

I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:
enum3.png

Same information as the '\' Codes Display but easier to read.

 

Tools like Word and Notepad++ allow you to view the hidden symbols in a string, it would be great if LabVIEW did as well.

 

Normal Style

Normal Style.png

 

'\' Code Style

Code Style.png

 

Symbol Style

Symbol Style.png

The current boolean diagram constant is potentially confusing and too elaborate.

 

Confusing, because it almost looks like a toggle switch, so the new user might click on the right half, expecing an unconditional FALSE. However, there are no active areas, and an inversion of the current value occurs no matter where we click.

 

Too elaborate. All we need to see is the current value! Why do we need to see the "other" value greyed out??? We can guess that by simple elimination. 😉 There is too much redundant information, wasting twice as much diagram space than actually needed to display relevant information. The current design also makes e.g. 2D boolean diagram constant very confusing. Have a look at the image. Can you immediately tell that the 2D array on the left is only true on the diagonal? (I did not think so!). Now look at the suggestion on the right. Ahh... much better! 😄

 

 Suggestion:

The boolean diagram constant should be smaller, simpler, and cleaner.

The image shows the current design on the left and the suggested design on the right.

 

 

What a difference in clarity and economy!!

 

Message Edited by altenbach on 07-03-2009 02:39 PM

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

I would love to be able to draw a box over a bit of code on the block diaghram and be able to highlight execution just for what's in the box. The rest of the code should execute at full speed. This frequently becomes an issue when you are trying to track down a bug in a big program and you've got to wait for ages to get to the bit your interested in.

How many times have you found yourself entering items in an array, typing merrily along, only to have to switch back to a mouse to click on the next element and type it it.  I suggest that Alt-Enter complete the current entry and move to the next array element.

 

This idea proposed using the Tab key, which collides with manual tool changes.  Shift-Enter was also proposed, but it collides with the ability to move to a new line in strings and to add another element to a enum/ring.

 

I propose using Alt-Enter to advance to the next array element:

AltEnter.png

I spent a good chunk of time yesterday trying to find out why I was getting a Wires Under Objects VI Analyzer failure, and after much paring down of code and fiddling with wires it turned out to be a hidden event data node that was running over a wire.  Below is a simple reproducing example; the second image is identical to the first, except that the event node has been hidden (but not moved).  Both of the images below fail the Wires Under Objects test, and my argument is that the one on the right should not fail that test.

 

Event node visibleEvent node visibleEvent node hiddenEvent node hidden

The point of the feature "hide the event data node" is so that I, as a LabVIEW developer, no longer have to worry about it cluttering my block diagram and it running into/over other items.  However, hiding it ultimately results in me still worrying about where it is hidden because it running into/over other items still turns out to matter when I run static code analysis. From this POV, this is a bug, and the VI analyzer test shouldn't fail.

 

This POV is also consistent with the way that hiding for/while loop iteration terminals operates.  In the images below (again, the second image is identical to the first, where the iteration terminal has been hidden but not moved), ONLY the left image fails the same VI Analyzer test, and this is the behavior I'd like to see with the hidden event node:

 

While with node.pngWhile no node.png

This recent idea reminded me of something I have wanted for quite some time now:  the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.

 

ReadWritePropertyNodeBD.png

 

The basic idea is simple:  all properties have two terminals, one for writing and one for reading (except read-only of course).  No right-clicking, just wire up the direction you want.

 

The bottom case is a bit interesting.  I see a few possibilities:

1.  Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2.  Read then write : returns previous value.  What happens if there is an error?  Passthrough, old value?

3. Write then read: almost always passthrough.  In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.

 

I would expect it to perform the write and then the read (3) or passthrough (1).  What is more important to me is the actual value and not the intended value.  Mentally I just see data flowing into then out of the PN when both are wired. 

 

Bottom line:  I see no reason not to permit the wiring to determine read or write of a property.

 

If there is a cop-out lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list.  Then I could at least do the write+read with a lot less mouse movement.

 I believe the number and age of "New" ideas on this exchange renders the word meaningless. I just Kudoed an idea that was 13 years old and marked as "Status: New". This idea would be in middle school; that doesn't sound particularly new. Inaction on an idea after some amount of time should automatically trigger some other status. 

Another for the wish list.

 

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

 

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

 

See attached pic for an mock up.

case glyphs.PNG

 There are probably lots of menus that could benefit from something like this.

 

Problem: When an error occurs inside some DAQmx VIs, the error source (the string component of the error cluster) does not contain the call chain. This means that it is impossible to know the location where the error occurred based on looking at the error message.

 

Real-world example: The other day I encountered DAQmx error -200477 on a cRIO-9045 that uses DAQmx to acquire data from several different C-Series modules. The real-time application that was running on the cRIO contained an error handling module, which correctly logged the error to file. I saw the following when using PuTTY and the linux 'cat' command to display the contents of the error log file.

 

1.png

 

 

 

 

 

 

Notice that the error message does not contain any information as to where in the codebase this error actually occurred. This meant that I had to spend a few minutes inspecting the moderately large codebase before identifying the likely location of the error. Running subsequent tests I was able to confirm that that was the location of the error. The error was soon understood and fixed.

 

Root-cause: The root-cause of the issue (lack of call chain information) is the DAQmx Fill In Error Info.vi. In the real-world example above the error was occurring inside the DAQmx Timing (Sample Clock).vi.


4.png

 

 

 

 

 

 

The block diagram of this VI is seen below:

2.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Any LabVIEW errors generated inside that VI are generated by the DAQmx Fill In Error Info.vi. This VI is, of course, essentially a simple translator between the return type (I32) output of the Call Library Function Node and a native LabVIEW error. That VI has an unwired input named depth whose default value is 1. This means that only the last link of the call chain is inserted into the error message.

 

3.png

 

 

 

 

 

 

 

 

 

Solution: Always insert the complete call chain inside all DAQmx error messages.

I am currently struggling with the issue that the shown knob permanently triggers "Value change" event as long as the user has not finished adjusting it yet (left mouse button is still pressed). This may be an intended behavior, but it is not in my case.

For boolean elements, there is the configuration option of "Mechanical Action". For strings, there is the option "Update value while typing". However, there is currently no such option for numerical elements.


Therefore, I would like to suggest the following:
Add an option "Update while adjustment" - true by default, so it acts as it do currently. If this option is set to false, the "Value change" event would only be triggered after the input is completed by the user.

The situation:

There is a user interface that provides the user with an array control.

The array control provides the user only one or a limited number of elements.

The user must use the scroll bars or the index control to select the correct element that he wants to modify.

 

The problem:

The user can scroll to a position beyond the last available array element and enter data. This increases the size of the array as expected, but not as desired in the given situation.

After the user finishes entering, the program must check the size of the array and reduce it again.

The proposed solution:

There should be a "max. array index" property of the array control. It should prevent the user from scrolling to a position beyond this maximum element index and/or editing such a position. It should also prevent adding elements via the right-click menu when the maximum number of elements has already been reached.

 

Extensions:

There could also be a minimum property that prevents the user from deleting array elements so that the total number falls below the minimum.

 

Notes:
The proposed solution should only affect the user's input capabilities. It should not change the size of the array if it was specified programmatically.

It should be nice to limit the action of Ctrl-B to a selected part of the block diagram.

 

For the moment the Ctrl-B removes all brocken wires in the complete VI.

 

Sometime when you have a case structure with multiple cases ... and when you have multiple brocken wires in many cases ...It is usefull to keep non visible broken wires...

The broken arrow (list of pending errors) will then help you to find all locations to modify. 

 

SelectiveCtrlD.PNG

The State Diagram Editor was a very cool tool and lots of LabVIEW users (not only beginners, far from!) are missing it!

 

And no, the state chart module is not a replacement for the State Diagram Editor!

 

Discussion here.

 

Image borowed from Ben

Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?

Ever wish LabVIEW had more appearance customization to make better looking GUIs?

 

I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.

 

Take a look at the difference:

 

Not Ideal Front Panel with background image and NO Opacity Control

 

front_panel_no_transparency.png

 

Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%

 

front_panel_semi_transparent.png

 

 

 

Before and After Appearance Settings tab in the Properties Window for a waveform graph:

 

appearance settings before and after.png

 

 

 

Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:

 

tools pallete transaprency.png

 

 

Kudos and share this idea if you want it to happen!