LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

It's hard to believe that this is the first post to request something like this (pun intended), but I couldn't find it after a few queries.

The base idea would be that both the static and dynamic connectors used to connect the methods to the owning class shall be defaulting to the owner class, a.k.a. this object in text based languages. The main problem is the use case for refactoring. When moving around methods the class controls and indicators have to be replaced every time. It doesn't matter if I'm moving methods between classes or to interfaces it is the same pain: replace the connectors (with QuickDrop), then change the names to class names, then update the icon, finally move the VI to the new location.

I know that this could and maybe is already solved with scripting, but I think the development environment shall grant the option to change the control and indicator to this object that will always default to the owning class, without manual updates. Even the labels could be This in and This out, and replaced in real time with the actual class implementation on the block diagram of the calling VIs.

The proposed solution would also get rid of the error telling about the dynamic dispatch controls shall reference the owning class, since it would happen automatically.

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)

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

Integrating markdown, asciidoc, whatever. This would help eliminate a step for most of us lowly third parties making docs for our software. A built-in browser would be nice, or just opening the doc straight away in a compatible viewer would be fine.

Loading the NI website's page for the help doc takes ages. This could also be a way to locally host vi docs and have a built-in browser-like display of help files.

I frequently find the context help information not detailed enough and get frustrated waiting for the website to load. If it was a one-stop shop markup-based doc, that's meaningful time saved.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

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.

For string controls and indicators please add a vertical alignment option. We have applications where we will programmatically change the font size, which requires a string control/indicator to be sized for the largest option. Since there isn't a vertical alignment option, the string is always aligned to the top and it can make the front panel layout look strange.

Other applications have long strings that may be a single line or may be a variable number of multiple lines, but we'd like to be able to center the text vertically. Again, this requires the control/indicator to be sized for the largest option, but all the text is always vertically aligned to the top of the front panel object.

View All (2)

A "This subVI" reference

Using property nodes, it's possible to retrieve a list of subVI references within a VI's block diagram. However, there's currently no way to link each reference to its specific subVI instance.

For example, if you place three instances of subVI "A" in a diagram, you can obtain three references to these subVIs, but there is no way to determine which reference corresponds to which instance.

The proposed idea is to introduce a "This SubVI" reference — a property or node that would return the reference of the current subVI instance (the one hosting the object or node). This enhancement would significantly improve scripting capabilities, support tool development, and aid in debugging tools.

View All (2)

PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.

As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.

I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.

There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.

The solution could be as "simple" as this:

When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
- Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
  - Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
- When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.

If we type up a list in a text label we can now (since LabVIEW 2023) right-click on it, select quick change and convert it to a number of different objects (array, enum, boolean etc)...Once you have done however, right-clicking on the result does not offer the quick change option anymore.

It would be nice and feel more consistent if the same option was available when right-clicking on the supported objects as well; allowing us to convert those to any of the other options and/or even back to the original list (which would allow you to then edit that list efficiently and then reconvert it). Basically an label/object to object/label quick change, instead of just label to object.

PS. I know there are various quick drop plugins that do parts of this, but this would extend the now in-built function to cover those and more scenarios...

Many times data is generated or transformed using a function or vi with a single output. In those cases the wire name is the one given by the function or VI terminal, but it would far more descriptive if the wire could have a proper name according to is usage in the block diagram. You can attach labels to wires but these are not propagated particularly when used in places like "bundle" or in structures (for, while, etc.). In large diagrams thus it can be difficult sometimes to now what a wire is for.

This idea proposes to enable the override of the default name of the wire connected to output terminal to that of the label of the function, in case the label is not empty, for single output function or VI. In a similar fashion to the propagation of labels of constants. This could be automatic (not empty label) or deliberate (for instance, using a tick box in the properties page)

This is different from idea Allow-Wire-Labels-to-Dictate-Name-Inheritance-in-Bundles in that it follows the current LabView behavior of the wire name being dependent on labels on constants, and avoids possible conflicts.

View All (3)

If we want a ring of a string type we can use a combo box and if undefined items are not to be allowed it *could* behave as a regular ring (integer type) with no text editing/input, but that is not an option in LabVIEW now. Having such an option would allow us the keep the behaviour of multiple ring controls identical (and hence more intuitive to the users) although their types behind the scene for programmatic convenience are different.

If you want to keep the ring as a string (to not have to deal with it indirectly though the ring/enum string array property, which would be the current workaround...) you are currently forced to accept that the this ring will behave differently than other ring controls or enums:

In Microsoft applications the suggested feature is available by setting the style of the combo box to DropDropDownList.

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires ~~jumping through flaming hoops~~ tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

Cleaner code for those who know how to work with this property.
Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!

right-click -> Find In Project

Super Polymorphic VI

In LabVIEW, we can create a polymorphic VI, but polymorphic VIs are made by creating multiple disparate VIs and logically tying them together. What I'm proposing is a single VI which can be used to perform many different functions, as is normal in many text languages.

Imagine a class with 10 different functions, and the ability to read/write from each. We'd have 20 similar VIs. I propose a single VI with a tabbed front panel. When you select a different tab, you'd see a different block diagram. Each could have a different connector pane. When saved, it would create a single file. On a palette, it would be a single function. We could use a polymorphic selector to choose which function to operate on.

This would simplify distribution of classes and drivers.

View All (2)

Improved Comment entry

When I add block diagram comments inside a structure, they are often long enough to require several lines. Since auto-grow is on, I need to stop typing before the comment reaches the edge of the structure, resize the comment to be multi-line, select inside the comment again, and re-start typing. From then on, the comment word wraps at my sized width. Could you make a special character like ctrl-, alt-, or Shift-comment move me to the next line and make the comment that wide, so it word wraps at that width from then on? While you're at it, could a word-wrapping comment autogrow in height to fit the comment, like a one-line comment auto-grows in width? Subdiagram comments could use that feature, too.

LabVIEW Idea Exchange

Class controls and indicators shall default to "this" class

Default Setting for "LabVIEW Version" in the Environment

Front Panel Control Context Help: Show Control Type

Graphical context menu at mouse pointer, super-duper quick drop

Extensible markup supported in VI documentation and help files. Locally hosting vi.lib help docs.

Eliminate uninitialized shift registers from vi.lib

Multiple dispatch / Function overloading

The properties page of "boolean array to number" must include the "sign extension mode" setting.

Add vertical alignment property for string controls

A "This subVI" reference

Support PPLs in vi.lib, instr.lib, user.lib, etc

Label to Object (Quick Change) upgrade to Object/Label to Object/Label

Allow single output function / VI label to override wire name

Reversion of custom images of Boolean Control states to the NI default in Control Editor

Add dropdownlist style option to LabVIEW combo boxes

Mouse events on 2D pictures should have an event data node for mouse information

Abortable recompile when closing project

right-click -> Find In Project

Super Polymorphic VI

Improved Comment entry