LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (1)

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Combined v2.png

Details

The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
“Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

.NET: System.DateTime.Now
C++: std::chrono::system_clock::now()
Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

Nevertheless, I would be happy with the following names too:

“Get Timestamp Now”
“Get Current Date/Time”
“Get Current Timestamp”

Notes

Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

View All (2)

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

1 (annotated).png

Thanks!

View All (3)

LabVIEW native dataframe type

Since a few years, we have native support for Map and Set in LabVIEW.

How about adding a DataFrame type similar to other programming languages (possible even with a native interaction with Python)?

A DataFrame type would be a 2D value where columns can have different datatypes. Currently, one needs to build around this by creating an 1D array of a cluster (or class) type.

Access to the data would be with numerical indexing for the rows and field access (like in a cluster) for the columns.

KR, Benjamin

View All (5)

Bug replication steps:

Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
Connect an indicator to a VI's connector pane.
Right-click the indicator and select "Change to Control".
The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).

Notes

Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

1 (edited).png

View All (2)

Providing additional Context Help information on Controls that contains information as to their "type" (Classic, System, Silver, etc.) as well as their font, font-size, and control-type (indicator, ring, enum, etc.) would be useful. The utility of this is obvious if you have ever had to modify/update an existing GUI and want to maintain the look and feel when adding new controls -- this would allow you to easily see what was previously used for the existing controls on a GUI. This "verbose" information could possibly be turned on/off as a Tools->Options->Front Panel setting.

View All (2)

View All (4)

Suggest adding functionality to the event structure when handling Value Change events, so that the user can tell whether the source of that generated event was via a write to a Val(Sgnl) property node, or via a Front Panel change made by the user.

This could potentially be achieved (albeit with backwards compatibility considerations) by defining an appropriate enum constant for the eventsource.ctl which available in the "Source" field of the Event Data Node (currently has "LabVIEW UI, ActiveX, User Event, and Other <>..." as the only defined constants).

More discussion and rationale is in this community topic:

Solved: Re: UI-Triggered Event vs. Value (Signaling) Event? - NI Community

View All (4)

I like compile time type safety checks. I dislike using variants. Occasionally, and increasingly more often, I find myself going to great lengths to provide compile time type safety. At a point, the type check gets lost in the inheritance hierarchy and I am back to depending on runtime checks for errors. It's not uncommon for me to have a class method that needs to "just work" across the bulk of the base types, but it sure is a pain to make wrapper classes, static inlined methods, and a nasty polymorphic .vi to mimic this behavior. Perhaps I am ignorant to some features of LV (do malleable vi's fit in here somewhere?), but multiple dispatch/function overloading sure seems like the silver bullet for this issue without messy inheritance trees.

I'm open to discussion on alternatives. This "problem" has come up in a couple of recent projects of mine, and I always feel dirty using a variant or making a static API for a class that ought to be extensible.

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

Regards,

Raphaël.

View All (6)

Auto-expanding nodes

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

Start wiring the new error, then click on the merge error node.

LabVIEW expands and connects the error wire

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

View All (1)

Idea: The In Range and Coerce Include upper limit option should be selected by default.

1 (annotated).png

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.

In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

Essentially, what I would like is a Type Specialization Structure that works backwards.

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

Simple example of Select

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

"Find" -> "Class Constant" option

Dynamic Probes for Class Data

Class data is painful, if not impossible, to properly probe when debugging LabVIEW code.

It doesn't need to be this way. Every other programming language I've worked with allows viewing this type of data when debugging.

Currently, by default, you only see probe data based on the wire's edit-time class definition, not it's actual runtime class instance. It would save me weeks (literally) a year if I could simply place a probe on a class wire and view the internal class data of the runtime class, including all levels of inheritance.

I realize it's not a small ask since the probe GUI would need to be dynamic (as data type/GUI elements, not just values, would need to be updated when probe is hit.)

Currently the quickest way to open a typedef is right-click >> Open Type Def.

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Notes

The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

View All (2)

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

View All (2)

LabVIEW Idea Exchange

Broaden the scope of VI Analyzer to projects, libraries and classes

Show a different broken arrow when the VI doesn't have errors itself.

The “Get Date/Time in Seconds” function should be renamed to “Get Date/Time Now”

Boolean constants should be 16 pixels wide and 16 pixels tall (currently 16 x 14)

LabVIEW native dataframe type

Fix bug: "Change to Control" should obey "Connector pane terminals default to Required" setting

Front Panel Control Context Help: Show Control Type

Path control with auto-complete (similar to Terminal)

Value Change event: was it generated due to Front Panel change or Val(Sgnl) property node write?

Actually stop loading the project when pressing the stop button

Multiple dispatch / Function overloading

Make "Match Regular Expression" inlinable

Auto-expanding nodes

The In Range and Coerce "Include upper limit" option should be selected by default

Give me a “modal when called” Front Panel / Window behavior or I will Kill LabVIEW (taskkill /f /im LabVIEW.exe)

Generalize backwards propagation technology - Backwards Type Specialization Structure?!

"Find" -> "Class Constant" option

Dynamic Probes for Class Data

New gesture: Ctrl + double-click on typedef should Open Type Def

Indicate that array constant contains more elements than currently visible