LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Abstract VI execution

It would be nice to have a performant way to execute an abstract represented VI.

There are currently two generic ways to execute a VI by reference:

- abstract represented but not performant (FP required, running in UI threading)

- specific represented and performant

Executing a VI currently.png

Is it possible to provide such a functionality which combines the advantages of both solutions like this?

Executing a VI proposed.png

This means, the target VI could be handled in abstract way without coupling to the specific VI connector panel.

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)

Clear Probe Watch Window

View All (3)

Use Nigel to suggest commit message

View All (3)

Static File Reference

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.

Managed way to get Class Properties

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)

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

1 (annotated).png

2 (annotated).png

View All (3)

It would be great if one could mark certain files as having an absolute path so that it is easier to move projects that use a common resource around in a multi developer/station environment.

A project might for example require a shared library or file that is installed by another application into c:\XXXX

Currently, all developers must place their project at the same relative folder depth to the shared resource to avoid linking issues. e.g If Developer A uses c:\Users\Dev A\Project\ then Developer B would need to use c:\Users\Dev B\Project\.. The project would complain about not finding the shared resource if Dev B was to use c:\Users\Dev B\Repos\Project instead for example.

Marking the shared files as having an absolute path would resolve this

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 couldn't find this explicitly mentioned here, but it seems related to:

Block diagram references should be 16 pixels tall (currently 19 pixels) - NI Community

Same Height of Unbundle by Name / Terminal / Local Variable - NI Community

Although making changes like this could hurt legacy code, earlier implementation is preferable. Local variables are already the same size as bundles and property nodes, but constants are not. My suggestion is to increase the size of bundle/unbundle elements by one pixel and decrease the size of constants by two pixels by reducing their border thickness. Since numerics require a type indicator, a 1 px border wouldn't compromise recognition. Numeric constant type visualization - NI Community

right-click -> Find In Project

It would be really nice if you were able to resize properties dialog boxes for controls, indicators, constants, and other nodes on a front panel or block diagram. Sometimes the information entered in a dialog is larger than the allotted space. Fortunately, in those situations, there is usually a tip strip that shows all of the information rather than just the visible portion of the information, such as shown in the enum properties dialog box picture below. To make all information visible, it would be great if properties dialog box windows were resizable and the contents of the tab control pages automatically scaled with the size of the dialog. It would also be nice if pages containing objects with columns (e.g. multi-column listboxes, etc.) allowed the columns to be resized as depicted in the picture below.

View All (1)

Make Class Mutation History Optional

This topic keeps coming up randomly. A LabVIEW class keeps a mutation history so that it can load older versions of the class. But how often does this actually need to be done? I have never needed it. Many others I have talked with have never needed it. But it often causes problems as projects and histories get large. For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes. The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.

My proposal is to add an option to the class properties to keep the mutation history. It can be enabled by default to keep the current behavior. But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

En un mundo cambiante tecnológicamente, se requiere responder antes los nuevos retos tecnológicos y, en materia en intercomunicación de apps, estaría excelente contar con herramientas, (API, TOOLKIT etc.), fáciles de usar como se ha caracterizado LabVIEW, para poder comunicar y enviar la información que se genera por medio de LabVIEW a otros sistemas como SAP S4HANA ON Cloud, actualmente tenemos SAP S4HANA ON PREMISE y esta excelente, sin embargo, todo cambia y en algunos casos se vuelve un desafío el poder cambiar con transparencia y facilidad, estoy seguro que es posible desarrollar diversas herramientas que pueda compartir la información que se genera desde el hardware de NI, a cualquier otra plataforma que los diversos clientes requieran, en nube, dispositivos móviles etc.

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

Pro-grade mockup shown below:

View All (2)

LabVIEW Idea Exchange

Abstract VI execution

Class controls and indicators shall default to "this" class

Clear Probe Watch Window

Use Nigel to suggest commit message

Static File Reference

Add dropdownlist style option to LabVIEW combo boxes

Managed way to get Class Properties

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

Allow file renaming to record changes to capitalization only in Windows

Add vertical alignment property for string controls

Error functions should be located in a dedicated palette named “Error Handling” (or similar)

Add support for Absolute Paths to LabVIEW Projects

Eliminate uninitialized shift registers from vi.lib

Match Property Node height to constants

right-click -> Find In Project

Be Able to Resize Properties Dialog Boxes and Certain Contents of Specific Pages

Abortable recompile when closing project

Make Class Mutation History Optional

Conectividad de LabVIEW con SAP S/4HANA ON Cloud

Checkbox to let the App Builder prefer the "x with Configuration Support" to auto-install MAX