LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

View All (2)

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.

Reduced inteface size

When adding a file via the project tree to a .lvlib or .lvclass, it is highly likely that the file is located in the same folder as the corresponding .lvclass. For .lvlib, the file is either in the same folder or one level deeper.

When using the right-click menu Add File... on a .lvclass or .lvlib, the Select File to Open dialog should automatically navigate to the folder containing the .lvclass or .lvlib.

Currently, it navigates to the previously used folder instead.

This should immediately navigate to the folder containing Cell.lvclass.

Mass open/close branch in Project

View All (1)

If a DLL is configured in a Call Library Function Node and is either missing or defective, the entire program cannot be executed. In most situations, this behavior is acceptable.

However, it can also be quite frustrating, especially if the part of the program that uses the DLL is not called. Additionally, it would be helpful for debugging purposes if the program could still execute even when a DLL is unavailable.

Therefore, I propose that the configuration dialog of the Call Library Function Node includes an additional checkbox labeled "Break execution if DLL cannot be loaded." If this checkbox is checked (default setting), the behavior will remain as it currently is. If the checkbox is unchecked, the program should run until the affected node is executed. At that point, the node's error output should indicate either "DLL not found" or "DLL found but cannot be loaded," and execution should proceed beyond the node. In this scenario, it will be the programmer's responsibility to handle the error appropriately.

As an extension of this idea, I could also envision a new entry in the LabVIEW.ini / application.ini file to assist with debugging. If this entry is not present, the explicit configuration of the node will be used. If it is available, it will override the explicit configuration with either true or false.

Please also see this related idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/get-DLL-path-from-the-call-library-function-node/idi-p/4433632

View All (4)

View All (5)

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)

LabVIEW Idea Exchange

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

Reentrant/Multiple Search result windows

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

Reduced inteface size

Pre-navigate Add File... dialog to folder containing .lvclass or .lvlib

Mass open/close branch in Project

Mass Compile Should Optionally Override Save Version

Allow file renaming to record changes to capitalization only in Windows

Prevent a Missing DLL in Call Library Function Node from Breaking Execution

get DLL path from the call library function node

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

Add "Scale Legend Change" as an event for graphs