LabVIEW Idea Exchange

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

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

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.

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

'\' Code Style

Symbol Style

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.

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.

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.

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.