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

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.

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.

The block diagram of this VI is seen below:

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.

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

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.

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