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.

Idea:

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

Reasons:

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

To achieve this, I found 2 techniques:

1. Replace by a temporary Control file:

- Create a new VI of type "Control VI";

- Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

- Save the .ctl file to a temporary path;

- Use method GObject.Replace with parameter "Path" on the old control / constant .

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

2. Recode the Replace method from scratch:

- Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

- Copy all relevant properties from the old control / constant to the new one;

- Reconnected its terminal to the wire on the block diagram if needed;

- For a control, relink locals, linked properties nodes, linked method nodes, references;

- For a control, reassign it to the connector pane if needed...

- ...

- Delete the old control / constant.

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

Regards,

Raphaël.

View All (8)

Edited Image 1.png

Notes

Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
This idea is somewhat related to the following idea: "Show node names when dropped" option

View All (2)

View All (3)

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-than/idi-p/2299860). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-window/idi-p/1844127).

View All (3)

Allow user-defined default icon

I started a discussion here

Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project. I never use the default icon provided by NI. -- N-E-V-E-R -- That's a personal choice.

So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless. Let's see how many users of LabVIEW also find the default icon useless.... (Kudos would be a way to take a poll).

A nice feature would be to allow the developer to create her / her own default icon. The default icon is probably somewhere in the ini file (I have not checked). One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.

In my case, when creating a new VI, it ends up with a icon like this:

I would be happy to have a default icon that looks like this:

The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.

And may plenty of kudos adorn this thread.. 🙂

Spoiler

View All (4)

Using "Edit Palette Set" is cumbersome and painstaking.

Specific use case example: I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers. To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.

It would really nice if we had the ability to generate or easily edit mnu files. In the example, a simple search and replace of the paths that the functions in the palette link to would work

Idea: The Assert Structural Type Match node should be growable (able to expand the number of inputs downwards and/or upwards). This would be similar to how many well-loved nodes can be "grown" downwards or upwards, such as Build Array, Concatenate Strings, Index Array, Merge Errors, etc.

1 (edited).png

3 Growable Nodes (edited).png

The following screenshot shows a real-world VIM that I created where I would have benefited from this feature. I needed to ensure that three inputs were all of the same data type. This required using two Assert Structural Type Match nodes. It would be possible to use a single node with three inputs if this idea was implemented. This would result in fewer wires and fewer objects on the block diagram.

View All (2)

The Project Explorer Files view already contains the useful "Move on Disk..." option. It would be useful if, when a VI or CTL is owned by a lvclass or lvlib, an option named "Move to Owner Folder" (or similar) existed. This option would move the selected file to the folder that contains the lvclass or lvlib that owns that file. This action would be equivalent to using the "Move on Disk..." option, but would save the user from navigating the (potentially large) folder structure to find the right folder. In short, it would save a few seconds and would help ensure consistency. It would also encourage the best practice of storing owned VIs and CTLs in the same folder as their owner lvlib or lvclass (actions that are easy to do are performed more often).

For example

Screenshot 1: A project that contains two libraries

Screenshot 2: In the Items view, the mouse was used to drag C.vi from Library 1.lvlib to Library 2.lvlib

2 (edited).png

Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".

3 (edited).png

Notes

It would be great if the "Move to Owner Folder" menu item was also available when multiple items that are owned by the same owner are selected.
A related idea: It would be useful if, when using the Items view to move an item from an owner to another, LabVIEW would pop up a dialogue message similar to the following "Would you also like to move the file on disk to folder <insert here the folder path of the new owner>?". The dialogue would contain Yes and No buttons. This would save the user from having to switch to the Files view altogether.

Thanks!

View All (1)

API for NI web server

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

View All (2)

Currently, the TDMS File api does not offer a way to get the TDMS file size.

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too). To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

View All (1)

LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project:

Great! Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.

However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.

The request: Add the ability to either open or abort these running VIs from this window. It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:

(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

1 (edited).png

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

View All (2)

Excel displays the number of selected cells.

1 (edited).png

VS Code displays the number of selected characters.

5 (edited).png

LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png

LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png

Notes

In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

View All (3)

View String Constant as Icon

View All (2)

Default cases should be pure!

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

View All (1)

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

View All (4)

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

View All (1)

I realize that the DBCT is nearing its 20th birthday, and probably is not a priority for a fix, but this is so simple and has tripped up a number of LabVIEW programmers doing database applications for so many years.

The VI Rec Fetch Next Recordset (R).vi has a flaw which manifests itself in stepping past the last recordset in a multi-recordset return - then leaks a reference which causes mayhem in downstream code. A simple test of the recordset reference would make this VI properly useful.

Among my other posts in reply to forum users about databases, the issue is captured succinctly here.

I long ago made the mods to the toolkit VI (actually, two), and reapply them with each new LabVIEW version as needed. If anyone at NI/Emerson wants to look into this, I'd be happy to share the particulars.

Dave

View All (2)

LabVIEW Idea Exchange

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

Method to replace a Control/Constant from a template object in memory

When a node is replaced, the new node label should be visible if the initial node label was visible

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

Indicate that array constant contains more elements than currently visible with scroll bar

Allow user-defined default icon

Document MNU file format or add better editing tools

The Assert Structural Type Match node should be growable

Project Explorer "Move to Owner Folder" option in Files view

API for NI web server

Need a way to get TDMS File Size from a TDMS File Reference

Add ability to open/abort running VIs from "Abort Running VIs" popup.

"Always On Top" option for Search Results window

LabVIEW should display the number of selected items in Project Explorer, block diagram, and front panel

View String Constant as Icon

Default cases should be pure!

Project should support links (like bookmarks) to main VI

Detailed Error Info at a Glance in Context Help

[Linux] LabVIEW Project Environment missing "Explore..." option (to show the file in the OS's native file explorer)

Please fix the longstanding bug in the Database Connectivity toolkit relating to multi-recordset returns