LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Problem: When creating a new VI using File >> New VI (Ctrl + N) its reentrancy setting is Non-reentrant execution.

Solution: The reentrancy setting of new VIs should be Preallocated clone reentrant execution.

Background:

In most applications the vast majority of VIs could and should be set to "Preallocated clone reentrant execution". In a nutshell, Preallocated clone ensures that each instance of a given VI is completely independent of all other instances. This is desirable in the vast majority of cases.

We should encourage best practices by changing the default reentrancy setting to the setting that is desireable in most cases, namely to Preallocated clone.

The other two options - Non-reentrant execution and Shared clone reentrant execution - are the best choice in specialised cases only.

Non-reentrant is necessary when needing to guarantee that multiple instances of a VI block each other from executing at the same time and/or when wishing to use uninitialised shift registers as a means of asynchronous data communication (e.g. FGV or Action Engine).
Shared clone is best when aiming to reduce memory usage. Shared clone can help on memory-scarce targets such as cRIOs or sbRIOs, or when dealing with massive amounts of data (arrays of millions or billions of elements). Worrying about memory usage is not a concern for the vast majority of VIs, especially when working on modern desktop systems that have 8, 16, or more GB of RAM memory, and when dealing with reasonable amounts of data (arrays with up to a few million elements).

New VIs set to Preallocated clone would be in good company, as detailed below.

The vast majority of LabVIEW nodes rightly execute as if they were set to Preallocated clone. This enables us to use many instances of each node freely without worrying that it will create timing dependencies between vastly different caller VIs.
- For example, one can use the Add node inside as many DQMH modules or Actor Framework actors as they wish, without creating any timing dependency between those callers, which is great.
- As far as I am aware, the only nodes that execute as if they were set to Non-reentrant are those that require the UI thread. These nodes execute in a sequential, blocking manner.
Many of the VIs that ship with LabVIEW are rightly set to Preallocated clone.
- I believe that most VIs that ship with LabVIEW and are set to something other than Preallocated clone should be set to Preallocated clone, but this should be addressed in a separate idea.
All inlined VIs (and therefore, all VIMs, which must be inlined) execute as if they were set to Preallocated clone.

Further notes:

If Non-reentrant was chosen as the default because it was judged to be the friendliest to new users (an argument that I believe does not outweigh the arguments in favour of Preallocated clone), then at least there should be a Tools >> Settings option to enable people to change the default reentrancy setting.
The fact that new VIs are by default Non-reentrant defeats the benefit that LabVIEW offers in terms of ease of creating parallel threads. Many of these threads will in fact not be truly parallel, because of the undesired one-instance-running-at-a-time blocking effect of Non-reentrant instances that execute in vastly different areas of an application.
I have never tested this, but EXEs are likely to be smaller (perhaps by a few KB, or even a few hundred KB) when the vast majority of VIs are set to Preallocated clone. When using multiple instances of Non-reentrant VIs LabVIEW must add some kind of mutex'es (mutually exclusive locks) in the compiled code. When VIs are set to Preallocated clone these mutex'es disappear, leaving behind smaller, cleaner compiled code.
The disappearance of mutexes might help enable the LabVIEW compiler to perform optimisations that are not possible when non-reentrant boundaries are present.

Reentrancy resources:

View All (3)

View All (4)

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)

I have created NI MAX custom scales to use in a data acquisition system with a cRIO and LabVIEW. As part of the Quality Management system at my company, I regularly calibrate instrumentation, and update these calibrations as custom scales in NI MAX. My issue is that these calibrations/custom scales are a very important part of overall data integrity. The concern is multiple test users can gain access to NI MAX and randomly change the custom scales without knowledge of the Quality System manager, thereby compromising data integrity. Perhaps NI could look into allowing password protections of Custom Scales like they password protect the configuration of the cRIO system I am using. This would help greatly to protect data integrity. Thanks for your consideration.

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)

The current behavior of a zero iteration For Loop with data that passes through it is shown below. The value passed out of the loop is the default value for the data type rather than the data itself.

If you do not want this behavior, you must replace the border tunnels with a shift register. My suggestion is to change the current behavior and instead pass through the actual data rather than the default data type value if a For Loop iterates zero times. Many LabVIEW developers, especially newer ones, are not even aware of the current behavior, which can lead to bugs in software using For Loops.

Obviously the picture above is a contrived example, but this situation can occur quite easily if an auto-indexed array is wired to the left border of the For Loop and the array is empty at run-time with other pieces of data being passed through the loop.

View All (2)

The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.

Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.

Screenshot (annotated).png

Notes

It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.

View All (2)

Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!

When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click

Step 1: Start creating a cluster wire

1 (edited).png

Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png

Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png

Notes

Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.

View All (3)

Make QuickDrop Quick

Resetting "First call?

View All (1)

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)

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:

While with node.png While no node.png

Add mqtt client to LabVIEW

The LabVIEW Help for the OPC UA Connect VI has this statement in the description of the "OPC UA data change event" output: "NI does not recommend using this output."

The example VI "Data Access Client.vi" inside "OPC UA Demo.lvlib" uses this output. Could it be possible to add a possible explanation as to why in the Example the "OPC UA data change event" output is used? Or could the Help for the OPC UA Connect VI be modified?

Example:

Help documentation:

View All (2)

The front panel below contains a modern-style string control and a classic-style string control.

3 (edited).png

We may want to replace the modern-style control with a classic-style control (for example if the team style guidelines recommend classic-style controls for non-user-facing front panels, or just for consistency).

The problem is that after right-clicking the modern-style control and selecting Replace >> Classic >> String Control, the control is replaced with something that looks different from an original, genuine classic string control. This is shown below. The new control looks like a hybrid between classic and modern. The same behaviour occurs when using QuickDrop to replace the control (Ctrl+Space, Ctrl+P).

4 (edited).png

My suggestion is: Controls and indicators should be replaced by genuine-looking items, not by hybrids that preserve some attributes of the old style, and some of the new.

Thanks

View All (2)

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)

LabVIEW Idea Exchange

The reentrancy of new VIs should be "Preallocated clone"

Automatically Set Input Terminal to Required using Ctrl button when Wiring Connector Pane

Use "In Place Element Structure" for VIs for Data Member Access (lvclass)

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

NI MAX Custom Scale password protection

Build spec name case sensitivity should be consistent

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

Zero Iteration For Loop Behavior Change Suggestion

Ability to enable or disable Automatic Error Handling for all project items

Delete listbox column/row (header) even when empty

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

New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)

Make QuickDrop Quick

Resetting "First call?

LabVIEW crashes when calling network functions under Linux

Hidden event data nodes shouldn't fail the Wires Under Objects VI Analyzer test

Add mqtt client to LabVIEW

OPC UA: Contradiction between help documentation and example VI, some more infomation would be good.

Front panel controls and indicators should be genuine after being replaced with control or indicator of different style

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