LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Problem

I would like to create HTML report of my unit tests run together with information about project code coverage. This can be achieved if the "Generate HTML report" option is checked in Project>>Properties>>Unit Test Framework and when the tests are run via toolbar operation "Run Unit Tests". However, I want to create same HTML report with PROJECT CODE COVERAGE programmatically via "Create Report.VI" or CLI, but the report generated in this way doesn't contain the code coverage information.

Run via Create Report.vi

Run via toolbar

Why This Matters

This functionality can be useful for running unit tests and report creating via custom CLI operation for CI. My scenario is to use the report as an CI artifact with informative value about code coverage.

View All (2)

Delete breakpoints from debug window

Hi all,
when I use breakpoints for debugging, I found that the breakpoints sometimes automatical re-appear after they are deleted from the breakpoint manager. I did some tests and found that they only appear again, when there is no other change in that VI, so the VI is not marked with the * in the title, which indicates unsaved changes. They will also not reappear when the VI is saved manually after the breakpoint is deleted.
So the suggestion is that a VI should also be marked as unsaved after deleting a breakpoint.

Regards, Patrick

Open Class in Runtime

There is a managed way to open a library both in development and in runtime environment via Library.Open method. The same method is available for Class Libraries but without the possibility to open the Class in runtime environment although the Class Library is a specialization of the Library.

Therefore the getting the hierarchy and/or the members of a Class could be performed by terrifying non-managed way in Runtime environment.

It would be nice to get the same functionality from this method as found by the Libraries.

At the moment the quick change plugin leaves the cursor where the label was. In order to select the control type, you must move to the list and select the type manually. It would be nice if the window captured the mouse focus and moved the cursor through the items with the scroll wheel. This would make the operation much quicker. An alternative would be to allowing tabbing through the items and use the space bar to select the desired item. Both of these options eliminate the need to aim with the cursor. For the scroll wheel options, bonus points if it returns the cursor to the label position when finished.

Optional DVR input to controls

View All (4)

Add Find Resource for NI-845x things

View All (2)

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)

LabVIEW Idea Exchange

Get code coverage programmatically in Unit Test Framework toolkit

Problem

Why This Matters

Delete breakpoints from debug window

Open Class in Runtime

Free Label Quick Change - Enable Scrolling and or tabbing.

Optional DVR input to controls

Add "Create SubVI" to right-click menu on diagram selection

Add Find Resource for NI-845x things

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