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

 

 

 

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

Sometimes we have a need to do some mild synchronization between otherwise parallel tasks. Typically we would use a flat sequence (but there are also exceedingly fancy tools such as "Rendezvous"). Even a flat sequence is often overkill for the given situation: It is a 2D object with it's own diagram and input and output tunnels. We need to decide what should be inside and what should be outside.

 

I suggest to extend the idea to a 1D object: The "Synchronizer Bar". It is basically a flat sequence with zero frames, condensed to a single vertical line (Maybe we could even allow kinks in it???).

 

The function is very simple and immediately intuitive (as anything in LabVIEW should be!!) and can be described in a single sentence:

 

"No data can leave any of the tunnels until all tunnels in the structure have received data."

 

Ideally, we should be able to "free-hand draw" this structure interactively with the mouse and a tunnel will be automatically generated for each wire we cross.

 

Here is a dumb (but illustrative) example (ignore the code itself). That's how it could look like.

(At the moment I simply merged the edges of a flat sequence, but I am open for prettier suggestions ;))

 

ZFF.png

 

 

Overall, it should be closely related to the flat sequence and include certain right-click actions (e.g. Add frame before/after, which would expand it into a flat sequence).

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)

 

 

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)

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

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.

LabVIEW crashes randomly when network functions are used on Linux. This problem appears especially when many connections or files are open.

R&D has identified the issue but is evaluating wheter or not the issue will be resolved in future releases.

 

All the details are here : 

https://forums.ni.com/t5/LabVIEW/TCP-Allow-files-descriptors-gt-1024/m-p/4297433#M1255356

 

An example is attached.

 

 

 

 

Download All

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

2-3-2010 1-35-27 PM.png

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

2-3-2010 1-41-08 PM.png

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

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.

 

 

All property nodes should use enums to make the code readable and not required to open help every time you need to set a properity.  I find myself creating typeDefs for my self so I don't have to look up what the properity does and to make my code easier to edit.  Example provided is to disable a control on the front panel.  This is in the LabVIEW style guide Smiley Wink

 

propertyNodesEnums.PNG

What if I had this:

 

idea1_1.PNG

Then I wanted to insert something with similar terminals:

 

idea1_2.PNG

 

I'd end up with this:

 

idea1_3.PNG

 

But the Error terminals aren't wired! So maybe I should be able to select both wires:

 

idea1_4.png

 

Then Right Click » Insert Write Node:

 

idea1_6.PNG

 

Then I'd have this:

 

idea1_5.PNG

 

How easy would that be!?

 

 

 

 

 

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

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.

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!

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

 

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

 

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].

 

I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.

 

I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.

 

To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?

 

Bob "Imperfect" Schor

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

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 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