LabVIEW Idea Exchange

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

Today, if we want a FOR loop with a fixed number of iterations, we need to wire a diagram constant to N. We could probably save a few clicks if we could click on N and type in an integer directly. It would also unclutter the diagram. This should of course only work if N is unwired.

 

Of course the N-Box would grow to the right to accomodate all digits

 

To later change the loop back to "normal", we would type N into the box or simply wire something numeric to N from the left.

 

As an example how it could look like, here's a simple cross product implementation (Yes, I know, LabVIEW already has a cross-product, so this is just to show the idea!)

 

Top: current implementation

Bottom: Same code after this proposed idea has been implemented

 

 

 

As mentioned at the end of my comment here, editing text is a bit clumsy. There should be a text toobar that is similar to what we can find in any other application.

 

Maybe it could be dynamic so it only appears when editing text.

 

Here's the quote from the other thread:

 

One thing that should be improved is the font pulldown which feels so early 1990's. When working with text, we want a text toolbar like anywhere else, (even in the post editor here in the forum!) with a bold, italic, etc. buttons, font and size rings, etc. You know what I mean!

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 function Index & Bundle Cluster Array can be quite useful and mimics a bundle in a for loop.

 

The reverse operation (= unbundle in a for loop!) would be equally useful.

 I wonder why it is not part of LabVIEW. Seems like an omission. 😉

 

I suggest to add it with the same icon graphics, but with left and right halves swapped.

 

(See also this example)

Message Edited by altenbach on 06-17-2009 01:21 PM

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)

 

 

Add new features, flexibility, and new controls to the Front Panel.  The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap).  I think it's time for NI to give more options and features for the Front Panel Controls.  I attached some suggestions.  They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting.  NI has done a great job on the Diagrams.  I should hope it's time NI improves the Front Panel.

 

Suggestions

I have used labview for a long time and avid user.  One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be.  I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded).  I wish Labview pro opened up the toolchain and started porting to many other platforms by default.  I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market. 

 

Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects. 

 

Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING).  Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done.  Really open up the doors for LabVIEW everywhere.

 

 

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

 

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

 

ReferencesIntoCaseSelectors.png

 

 

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

I can't count the number of times I've seen this dialog :

 

remove.png

 

Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]!  This dialog must be a holdover from pre-Undo days.  Do we pop-up a dialog when you select your whole diagram and press <Delete>?  What about when you press Ctrl-B?  These actions have the potential to remove just as much diagram content as Remove [Structure].

 

Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.

It would be nice if the Strip Path function had a recursive option rather than having to string Strip Paths together or use an external loop.

 

 eg change from this:

strip_path.png

 

 

to this:

 

recursive_strip.png

 

 

regards

Ray

Download All

My goal is to reduce palette bloat!

 

Let's look at the conversion palette. Certainly looks impressive, but why do we need so many different bullets??? They are basically all the same function:  A universal input and an output type.

 

I suggest that the 16 marked bullets on the image, plus some others (e.g. "to variant"), be combined into a single universal bullet where we can select the desired output type by a simple right-click. Whatever we select will determine the actual icon, so once things are in place, everything will look exactly as before.

 

When we first drop the universal icon on the diagram (or insert it into a wire), the context menu appears and we must select the desired output.

I would be nice if the Clear Error primative was modified so that it's icon was not the full subVI size, but rather smaller which would help to keep the block diagram neat and clean.

 

Proposed Clear Error Modification.png

The most common icon that I use in LabVIEW has a "title" section at the top.  It is so common, that when this is used, LabVIEW moves the Text Entries below it.  BUT, they don't allow for automatic entry INTO the title field.  Instead they allow 4 lines of text that all gets compressed when you use 4 lines of text.

 

Instead of the 4th line of text, how about an entry for the Title, it will appear in the small window at the top of the icon.

 

IconEditor_TitleEntry

1. Allow for "Tabbed Browsing" of VI's to better manage windows.

2. Allow for the BD to be open independent of the FP.

3. Allow dockable palettes... dock to either the edge of the screen, or to the top bar (pictured below) of LabVIEW.

4. As a bonus, consider being able to open PDF's, txt's, and html's in tabs also for Help and documentation.

5. Finally, allow the project tree to be docked into the IDE.

 

Please, add your own IDE upgrade ideas in this discussion - illustrations will be especially helpful here. If it's a major enough idea, create a new idea!

 

LabVIEW2010.png

Edit >> Create SubVI:  I almost never use this function... but it could be so nice!

Imagine being able to develop code on some diagram, check functionality in line, and quickly generate a subVI.  We're so close with "Create SubVI", but in 7+ years, I've never really used it.

 

Suggested Tweaks:


1) Use default connector pane (12 terminals)
2) If there are error clusters, wire them to the bottom terminals.
3) If there are error clusters, auto create a case structure and put the code in the No Error case.  Wire the error cluster through the Error case.
4) If there are in and out references (e.g. File In, File Out), wire these to the top terminals.
5) Run Clean Up Diagram.

I would love it if the Call By Reference node had a "don't wait until done" option, so that we can stop using the inconvenient and inelegant Set Ctl Val method or other inconvenient ways to pass arguments to dynamically called processes.

 

I believe the main issue with this is what to do with the outputs from the subVI (since you won't be able to use them) and I can think of two options:

 

1. This option would be settable at edit time and would break the caller if you wire any of the outputs.

2. This option would be settable at run-time and you would get default data from the outputs and an error or warning from the error out terminal of the node if you wire any of the outputs.

This one of my very old ideas and goes all the way back to InfoLabVIEW. I recently got reminded in this thread to write it up as an idea. You might have heard it before. If not, read it :D)

 

Currently, an output tunnel gets the default value for the given datatype if "use default if unwired" is enabled and a case executes where it is not wired. Recently, we also got the "linked tunnels" feature, which is more like an editing assistant.

 

Many times we have a big stack of cases but the computation of many outputs is shared by many cases, maybe with one or two notable exceptions. 😉 It would be cool to be able to define this shared "default" code only once so it is executed unless we create an exception case.

 

My suggestion is to have a new, special case that allows us to define the output of each tunnel for cases where it does not receive an overwriting input.

 

The image shows a few possibilities for an event structure (same applies for all other relevant structures).

 

A: A reference is wired across by default. We don't need to wire across any other case.

B: Nothing is defined, so it acts like today. This is the default, so everything is automatically backwards compatible with existing code.

C: A number is incremented with each iteration unless we overwrite in a specific case

D: The default output is based on the operations of several inputs.

E: If a tunnels is unwired, we get NaN (or whatever we need) instead of zero. For I32 me might want -1, for example.

F: Same as A. This is similar (but not exactly the same) as linked tunnels. (I.e. It also applies to existing unwired cases)

G: This tunnel is defined in all cases. If we add an unwired case later it would act like B.

H: (not shown): certain global event terminals (e.g. time) should also be available in the "default definition case", because we might want to utilize it for a default output.

 

 

 Downconversion would be somewhat messy. It would probably need to wire the relevant default operations into all cases where an output is not wired, keeping the functionalty the same.

Message Edited by altenbach on 07-11-2009 10:45 AM

Searched and didn't find this.  I know you can format the text manually.  Comments should be colorized automatically.

 

formual node.png

We've all seen it: The annoying 1-pixel bend when wiring between VIs with mismatched connector panes. Many ideas have been proposed to address this on a small scale... But I think it can easily be improved on a much larger scale.

 

IDEA:

Modify the way the 5335 connector pane is rendered so that the top and bottom terminals line up with those of the standard 4224 connector pane.

connectorpanes.png

 

In case the image doesn't say it all, all I'm proposing is that the top-left terminal of the 5335 connector is made 1-pixel larger by stealing 1-pixel from the terminal below. Likewise for the top-right, bottom-left and bottom-right.

 

The obvious benefit is that it becomes much neater to wire errors and references between mismatched VIs. Goodbye OCD! Smiley Very Happy