LabVIEW Idea Exchange

Here's a very fundamental User Interface concept that LabVIEW lacks: 

When you press and hold an increment or decrement button on a numeric/ring/slider...etc..., the rate at which the value changes is constant: painfully slow. Typically, in other applications, button presses will increase the rate of change of the number proportional to the amount of time held, and if you hold it for 5 seconds or so that sucker is flying.

We want the same native behavior for increment/decrement buttons in LabVIEW, but we want it to be configurable. Consider a Property Node that defines a Lookup Table for the velocity profile of the increment:

The way the above code is read: For 0<t<1000, the control only moves at 1unit/sec. For 1000<t<3000, the control moves at 10units/sec. For 3000<t<5000, the control moves at 100units/sec. Another (more difficult?) way to define the velocity profile is to provide the velocity profile vs. time as a formula.

Of course, while the "typical" profile would start off slow and accelerate, I'm sure the ability to create unique accel/decel profiles would give incredible control for some awesome, one-of-a-kind User Interfaces.

(As a side note, if LabVIEW simply implements a fixed acceleration rate that was non-configurable, I will still be frustrated and still take the XControl route.)

I'm sure someone can think of a better, more intuitive implementation, but the concept remains:

For a press-and-hold on Increment/Decrement buttons, the control should increase its rate of change proportional to the amount of time it has been held, as defined by the programmer.

Currently, when you use the Reshape Array primitive, if new elements are created, they are filled with the default data of the datatype. Alternatively, allow a terminal that defines the fill value.

The LabVIEW Robotics Module consists of a variety of sensor and actuator drivers, motion algorithms (such as kinematics), world map creation and search algorithms, a world simulator, etc.

It hasn't been updated since 2019 and is 32-bit only.

I would like to see it made open source.

I believe some or all of the sensor drivers are already available on ni.com/idnet.

There are several other VI-based components and examples that are standalone and could be easily released independently.

I realize that the simulator might have some 3rd party constraints for releasing as open source, but I'd love to see it released if possible.

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

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.

In a simple project, the main entry point into an application is usually easy to find:

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 

One possible implementation:

• Display tagged items as links at the top-level of the project.
• Links would be pinned to the top row
• Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
• For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
• In principle links could point to anything interesting, not just the main VI.
• Double-clicking a link should open (or navigate to?) the target item

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way. 

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI  I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

We've all probably found ourselves writing various forms of this:

It would be great if there was a malleable version of the "Traverse For G Objects" function that shipped with LabVIEW to save a few headaches. Rather than passing in a string for the class name, and then adding a downstream ToMoreSpecific operation, it could accept the refnum constant (in the above example, the "Control" class ref) and return an array already cast to that class.

The function of "Compound Arithmetic" can be changed very quick and easy.

Why not use that concept for other items too?

Use cursor mode "Operate Value" to change function quickly.

Old: Click > Replace > Comparison Palette > Item

New: Click > Item

See concept screenshot for example:

The clicked item acts like an polymorph selector to choose from same palette or from similar items.