LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Enter Equation In Numeric

View All (4)

When a project file has been changed, you can view a list of the changes that have been made to the project when closing it. Unfortunately, these changes often lack important details.

For instance, the most common change I make to project files is adding or removing items (even if inadvertently, such as opening a new VI and then immediately closing):

However, the message doesn't indicate which item was added or removed. Usually when I'm looking at this window, I want to know specifically which item was added/removed so that I know whether or not it's important to save the project file or if I accidentally added something that I didn't want in the project (or removed something that I did).

"Get Data Size" node

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

1 (edited).png

For example, the node would return a value of:

1 byte when fed a U8 wire
2 bytes when fed a U16
4 bytes when fed a I32
8 bytes when fed a DBL
800 bytes when fed a 1D array that contains 100 DBL elements
9 bytes when fed a cluster that contains a DBL and a U8
9 bytes when fed an object that contains a DBL and a U8
18 bytes when fed an object that contains two other objects that occupy 9 bytes each
and so on

Notes

The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
- When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
- When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

Thanks!

View All (3)

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix. New constants should be able to autoadapt for radix, much like they do for type: Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls). For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion). Hex is an exception, obviously, because b and d are already valid. The other radices have no such problem.

View All (1)

Install LabVIEW API ONLY for NI Drivers

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

View All (4)

Modern embedded web browser

View All (4)

View All (2)

I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

View All (3)

View All (6)

Reorder Probes

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram.

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

View All (1)

Key focus Event

View All (5)

View All (3)

vi properties window name

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption. I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog.

like this:

View All (2)

Treat WSL like a RT Target

One thing I love with LabVIEW is to be able to execute the same source code on multiple targets (Win, Linux, NI Linux RT, etc)

I use Linux more and more to deploy my LabVIEW built apps and now instead of VM I use Windows Subsystem for Linux (WSL) on Windows 11, in very few steps I can create an Ubuntu instance, add a desktop and xrdp and then remote desktop into it.

What would be fantastic is to not event need a desktop and xrdp but just install LabVIEW in the WSL instance via terminal and then run LabVIEW on Windows and select the WSL instance as execution target as I would do for an RT target.

View All (2)

Add Control Anchors to Labview

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

Would be resized into:

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

View All (2)

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

Why not include this in the context menu? (Bonus points if Polymorphic VIs get added too!)

View All (3)

Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean. But, if you don't pick the right colors, LabVIEW keeps a single text color.

This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:

But, as you can see, LV only supports one text color. I propose that LV support two text colors (ON and OFF). Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.

In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

View All (2)

LabVIEW Idea Exchange

Enter Equation In Numeric

Details on which item was added/removed in Project Explorer

"Get Data Size" node

Dynamic/smart Index/scrollbar on array constants

Autoadapt numeric constant radix plus automatic radix conversions

Install LabVIEW API ONLY for NI Drivers

Modern embedded web browser

Control all the 4 [6] colors of Booleans from their Properties page

Automatically Display Value in Tip Strip for String and Path Constants

String control/indicator/constant with line number display.

Reorder Probes

Key focus Event

Flush Event Queue Should Return the Data!!

vi properties window name

Treat WSL like a RT Target

Add Control Anchors to Labview

Increment label ending in numeral when copying control

Option to add malleable VIs directly into project

Change CLUSTER SIZE to a Wired Input

Support Multiple Boolean Text Colors