LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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.

View All (3)

Make QuickDrop Quick

LabVIEW 2020 32bit (English), installed on Windows 10 (French).

I have noticed some small inconsistencies in the localization and formatting of the "File Dialog" and its subdialogs.

Let's say you have a "File Dialog" express VI configured in mode "File, Existing".

The main dialog and the "non-existing file" subdialog look like this:

Here I've put the parameters in [square brackets], of course it is the developer's duty to localize them.

For the rest, except for the "All Files" pattern label (which should be "Tous les fichiers" in my case), everything is correctly localized and satisfyingly formatted.

Now let's compare with a "File Dialog" express VI configured in mode "File, New".

The main dialog and the "replace existing file" subdialog look like this:

The "replace existing file" subdialog is not localized and its format is not consistent with the "non-existing file" subdialog.

For the subdialog's title, it should be the [Prompt] as well.

For the file name, it should be the short file name (and not the full path). This one is my personal preference but both subdialogs could display the full path as well, as long as it is consistent.

Regards,

Raphaël.

View All (6)

A universal conversion bullet.

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.

View All (4)

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

View All (5)

When I want to select a given index of an Enum (Index, not String value) then it can be cumbersome.

I can make the digital display visible for the constant or control, but when the drop-down list appears.... yeah.

Enum drop-down.png

Can't we include the Index on the left side of the drop-down list (Spot my numbering error)?

Enum drop-down with index.png

It's not too hard here because they're sequentially ordered (more or less) but we have some enums with over 100 elements which are not so nicely ordered. Sometimes we just need to find out which element corresponds to a given index, or to select a given index directly. This is not so easy manually. I know we can enter the value for a constant in the DigitalDisplay area to select that element, but I still feel it would be nice to include the index when showing the selection list.

This is useful anywhere there is an Integer to Enum conversion (or the opposite).

Add Find Resource for NI-845x things

View All (2)

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.

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!

View All (2)

Text editing with ctrl + arrow keys

When I try to select a word or more words I currently have two options. The first one is to hold down shift and select on letter by letter basis which is slow. The second one is to select with help of mouse, which is error prone.

Normally all text editors have options to move for 1 word left or right by ctrl + left arrow or ctrl + right arrow. The same goes for selecting a word (ctrl + shift + arrow). I would like this functionality to be supported by LabVIEW at least on block diagram, VI documentation, enum editing.

View All (1)

When creating a SubVI by selecting a piece of code from your block diagram, the "error out" indicator created is not the standard indicator with grey background as available in the controls palette.

On the contrary, it is similar to the standard "error in" control with white background controls.

To me it results on a poor style and readability, and I use to replace it manually with the palette indicator.

I suggest using the default error indicator when creating a new subVI (and anywhere else if possible).

Expression Node Redesign

For reasons outlined in detail in this idea, the the expression node should be redesigned. These vertical lines are too thick and the end arrows are pointless and too busy.

After all, the expression node is basically a [single line|single variable] formula node and for this reason it should look more similar to a formula node.

Here is my suggestion for the redesigned expression node (on the right). The current design is shown on the left for comparison.

Note that the grey left and right borders are exactly matched to the border design of the formula node, making things consistent and intuitive. (Top and bottom should remain single pixel to save diagram space).

View All (1)

NI has a private method for returning the hWnd of a VI but there is no "publicly" available method for this. The private method is already shared around forums and used extensively as interacting with the Win32 APIs is a common need for advanced UIs. The appearance configs for VIs only work relative to other VIs and trying to develop LabVIEW based applications that are used alongside other applications presents many roadblocks, even with other NI software such as TestStand. (TestStand has an API method for getting the hWnd!)

The other method commonly used is to also use the Win32 FindWindow call however this presents issues if there are multiple windows with the same captions (easy enough with Cloned VIs) and is not a robust approach.

View All (3)

View All (2)

LabVIEW IDE Overhaul

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!

View All (13)

Single Window Mode

While I have many, one of my major gripes with LabVIEW is that it's very easy to have dozens of open windows. This would normally not be a terrible burden, but LabVIEW has a bad habit of raising ALL open LabVIEW Windows when any single one is given focus.

For example, if I have both the front panel and block diagram windows of 3 VIs, a project window, the VI palettes, and a ctrl+h help window open, then clicking any one brings all 10 windows to the front. This is a problem if, for example, I'm trying to draw an icon based on some source image from Google image search. I am forced to maneuver all LabVIEW windows and the browser window such that the two things I actually want are both visible at the same time.

To get around this, and other difficulties introduced by the huge numbers of windows that labview is fond of creating, I propose this idea based on the relatively recent addition of a "Single Window Mode" to the open source photo editor Gimp (http://www.gimp.org).

In the original Gimp UI, each open image occupies a unique window. Additionally, the toolbox and other dialog windows (layers, brushes, etc.) occupy unique windows as well. This, to me, is remarkably similar to the LabVIEW UI.

In Gimp's Single Window Mode, the toolbox and any open dialogs can be locked to one side of the screen and each open image is in a tab. (Note that this is strongly influenced by Photoshop's UI.)

I would like to see something very similar to this for labview. In this concept, each open VI would occupy a tab (perhaps split vertically into front panel and block diagram) and open dialogs (such as VI palette, ctrl+h help window, navigation window, project explorer, etc.) could be docked to the screen edges. Here is a rendering of such a concept.

I would note that most text IDEs (such as Eclipse, Visual Studio, etc.) use a very similar paradigm (ie lots of source files open in tabs, project viewer, find+replace, etc locked to screen edges). Clearly more thought would have to be given to how front panels are displayed, e.g. outside of a labview development environment, but I feel that this concept would be a dramatic improvement for the development task.

View All (2)

LabVIEW Idea Exchange

DAQmx errors should contain the whole call chain. Improvement to the 'DAQmx Fill In Error Info.vi'

Make QuickDrop Quick

"File Dialog" and its subdialogs should have consistent localization and format

A universal conversion bullet.

Change the Clear Error primative's icon to reduce block diagram clutter

LabVIEW crashes when calling network functions under Linux

Icon Editor Title Text Entry

Build spec name case sensitivity should be consistent

Delete listbox column/row (header) even when empty

Show Enum indices in selection list

Anyone else want local variables to be created as read instead of write?

Add Find Resource for NI-845x things

Improve alignment for VIs with 5335 connector pane

Text editing with ctrl + arrow keys

Use standard "error out" indicator when creating a SubVI

Expression Node Redesign

Provide a public method for retrieving the hWnd of a VI window

Add "LstEvt" (Last Event) to the event data node

LabVIEW IDE Overhaul

Single Window Mode