LabVIEW Idea Exchange

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

 It is a very common / preferred practice to design Vis along a horizontal structure of error clusters wires.

 

Sometimes, cleanup does not create a horizontal error wire.

 

Please add a  "force error wire horizontal" option.

 

Thanks

 

I would like to propose the use of a stacked parallel execution structure.  Especially in FPGA applications, this will solve the problem of diagrams running off the screen.  All execution pages will run simultaneously as if independent while loops were scattered across the BD.  This idea potentially leads into a 3 dimensional visuallization of coding LabVIEW. Note: In the image, the pages are offset but should look similar to a stacked sequence structure.

 

 

Parallel Execution Structure 3.JPG

 

 

We have a Round towards -Infinity  (3.8 becomes 3,  -3.8 becomes -4)

We have a Round towards +Infinity (3.2 becomes 4, -3.2 becomes 3)

We have a Round to Nearest (Rounds up or down to nearest integer, if 0.5, banker's rounding to even integer)

 

Why is there no Round towards Zero?  Basically a truncate.  (3.2 becomes 3, -3.2 becomes -3)

I have a use for that right now, but it takes several primitives to work. 

 

As a corollary, a Round Away from Zero.  (3.2 becomes 4, -3.2 becomes -4)

 

 

Message Edited by Ravens Fan on 01-19-2010 04:53 PM

Building on the "Path Case Selection" idea, it can be difficult to remember all of the values of an Enum when defining a case structure.  I suggest a popup menu on the case structure which lists available values for selection.  Values already defined in other cases could be greyed out, and values selected in the current case could be selectable for removing.  Perhaps it would require a heading to differentiate from selecting a case, and Ctrl-click (Ctrl-right-click?) to activate.

Case Popup

This idea simply extends "Allow References to be wired into Case Selectors" by JackDunaway.  In short, allow paths to be wired directly into a case selector, with one case for "Not a Path", one for "Empty Path", and a third for "Valid Path".  This would often save me small trees of nested cases.

When you’re making a By Reference LabVIEW Object using a Data Value References (DVRs) the user of your class would need to embed each Dynamic Dispatching VI inside an In Place Element Structure (IPE). Or you have to create wrapper VI for each method but this undermines the advantages of LVOOP Inheritance.
 
The idea is that a DVR containing a LabVIEW Object wired to a Dynamic Dispatching Terminal is equal to calling the Method VI inside the IPE structure like illustrated below.

DVR DynamicDispatch.PNG

Message Edited by Support on 01-15-2010 04:39 PM

Since the commands "Group" and "Ungroup" objects it is only available in the FP's toolbar, there is no way to customize a shortcut key to it. The proposed ideas are:

  1. Have the controls also available in the "Edit" menu to allow us the customization through Tools -> Options... -> Menu Shortcuts.
  2. NI define two keyboard shortcuts, for example, Ctrl+G to group and Ctrl+Shift+G to ungroup.

Sometimes, like in many other software that have a paint feature, we need color swapping between foreground and background. The idea is to add a spot in the Tools Palette to allow this operation in one click. Here is a suggestion:

 

swap colors.png

 

It's difficult to see the spot because I did not changed anything, just added the double ended arrow. One way to help the visibility is turn it white when the mouse hover over it.

The tiny circles that represents inversion of the operation in the compound arithmetic node are hard to see (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enlarge-the-Invert-Circles/idi-p/1023748#A3241). The proposal is to get rid of the circles and invert the central part of the respectives connectors:

 

2010-01-13 compound arithmetic inversion suggestions.png

The difference between the suggestions is that in the second the corners were rounded to reduce the impact a little. I liked the first most.

For non-integer increments, the data entry currently accumulates binary errrors due to the limits if the DBL representation, so e.g. sometimes the upper limit cannot  be reached using the increment button several times, but only when entering the upper limit directly.

 

This comes up at regular intervals, e.g. here. In one fo these discussions, I long ago suggested to make it into an idea. It seems this has not happened, so here it is! 🙂

 

This limitation needs to be handled with some internal code, e.g. to coerce the value to the nearest decimal fraction based on the least significant digit of the increment value whenever the up/down buttons are used. ... or something similar. 😉

I'm sometimes amazed how lazy I get. As soon as a cool new feature comes out, like a For Loop with Break, I want something better. I'm tired of writing code to search through an array of clusters for some specific value that matches. I really want LabVIEW to do this for me. This could drastically improve coding efficiency in advanced applications.

 

Imagine we have a new primitive search function that can search an array of clusters for a specific item and return the index of the first match. Then instead of writing this code manually, I could just drop the function and select the type to search by.

 

This:

 cluster_search.PNG

 

becomes this:

new_cluster_search.PNG

A minor niggle I have is the way LV reacts when we resize windows.  The anchor point is always at the top-left of the window.

 

If I grab the top of a window and make it smaller, I don't get rid of space at the top of the window as expected but rather at the bottom.  This makes alighning the top of the window a painstaking process of resize, adjust, chack, resize, adjust, check.....  I'd live for LV to anchor at the opposite side of wwhere I'm resizing.  If I want to resize the panel shown below to get rid of the space at the top of the panel I insitinctively grab the upper windo edge and resize.  But alas, the result is not what I expect (Even after 10 years of LV programming). 

 

Panel resize top.PNG I want to get rid of the space at the top.....

 

Panel resize top_2.PNGDoh!  Grabbing the top edge doesn't do what I want!

 

Shane.

Message Edited by Intaris on 01-11-2010 09:40 AM
 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
 
 align.jpg
 
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.

We use the lock/unlock SCC method, and one thing I often forget to do on a new installation of LabVIEW is to set "treat read-only VIs as locked" to true.  I think this option should be set to true by default.

LabVIEW native primitive to get string’s number of lines.

 

Just an example:

string number of lines.png

 

Also, Get Number of Lines could be extended to File IO function too, File Get Number of Lines.

Allow the Case Selector Label to be moved along the top border.  Often wires naturally fall in the center of the case and it would be nice to move the Selection Label to the left or Right to make the BD neater

It would be very nice if we could tell the installer script to synchronize its version number with the version number of a specific executable.

 

12-29-2009 2-38-53 PM.png

 

Additionally, it would be very nice to have this version information (once they are synchronized) displayed on the installer wizard (for instance in the title window or on the wizard first page).

 

PJM

Spurred by Darren's latest nugget, I think it would be an excellent addition to the feature to be able to retain wire values for all subVIs of a particular VI as well as the VI itself. Several times, I have found myself having to run a VI a couple times to get to the point where I can satisfactorily examine the data flow. There is a JKI RCF plugin by Vishal posted here which implemented this, but native functionality would be much preferred. 🙂

 

I'm not sure how best it could be implemented in UI so as not to disturb those who don't want this, and I can forsee a hairy situation arising if a particular subVI is called from a different hierachy later. Ideally, the subVI would retain values for the last execution in the retained hierachy, but obviously that's incorrect in the grand scheme of things. I'd love to hear other ideas on how to handle that scenario.

This is somewhat related to this idea by GregS, but still not quite the same.

 

The array index terminal of an In Place Element structure currenty require to be wired. It should exactly like "index array" such that unwired inputs behave like the plain old Index Array (an unwired index is the index of the above terminal +1 (recursively). The top terminal defaults to zero).

 

As an example, here's a simple construct that keeps the N, average, min, and max in a size 4 array. For some reason, the code is broken unless I wire indices 0..3. None of the indices should be necessary and the functionality should remain exactly he same without them.

Message Edited by altenbach on 12-28-2009 09:58 AM
Charts assume that the X-values always represent evenly spaced points. With LabVIEW 's charts, you only provide the Y value, and do not specify the X value.
For arbitrary X-values, one has to construct something (usually involving shift-registers).

Often charts are meant to display values as a function of time. If one changes the acquisition rate, one would expect the chart to change accordingly.
As LabVIEW only allows you to scale (and offset) the chart's X-axis, it would be nice to have a timestamp input (for instance expandable form the chart's terminal).
 
Resulting chart would look like this (here two plots). 
 
Chart with time stamp.png