LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I often use the "Find All Instances" option from the right-click menu when clicking on a VI's icon to find all callers of that VI. However, it regularly comes up with fewer hits than the "Find Callers" option. In this case, it came up with 0 hits:

However, if I navigate to the VI in my project (ctrl+shift+e) and then right-click on it and select "Find -> Callers" it will actually find the callers:

I've never understood this discrepancy, and I see it regularly. Perhaps this is more a bug than a feature request -- but I do feel that if these callers are consistently findable from through one of these mechanisms, they should be consistently findable through both.

Note: in the case above, if I do open the VI (after finding in using "Find Callers"), it will then be found if I "Find All Instances...". But if I close the VI, it's no longer found using "Find All Instances".

When you're looking at the front panel of non-editable VIs, such as VIs in PPLs, many options aren't available. Some of these are still applicable, and would be really useful.

Example 1: If I want to go look at a class definition, normally I could right-click on the class in a front panel and then choose "Show Class Library". However, it isn't available if the VI is locked. My (less-than-ideal) workaround is to "Copy Data", drop the class on a new block diagram, and then I have access to all the normal menu options.

Example 2: The connector pane isn't visible. I often want to look at what is wired where on the connector pane, or to check if inputs are dynamic, but this info isn't visible.

I work with PPLs quite a bit...and sometimes...I just want to rename them.

Libraries that depend on the renamed PPL will then be broken, as expected. Example here:

It would be awesome if I could simply go in, right-click on the missing dependency, and replace it with the newly named one. But...for whatever reason...this option is disabled. Instead, I find myself having to go in and manually replace each individual broken PPL call (VIs, typedefs, etc.). This is unnecessarily time consuming and error prone.

Currently VI's show up in whatever taskbar's monitor they first showed up in and don't follow if they are moved to a different monitor.

This makes my workflow very difficult as I can end up with 18 VI icons (1 each block diagram and front panel) on Monitor 2 and 0 VI icons on Monitor 1. This despite the fact that might have moved have of the VI representations to Monitor 1. The only way to distribute them among the taskbars is to restart windows explorer. This is annoying to have to do even though I have a script to do it (thanks to the hero that posted that process!).

Relatedly, I don't always want all VIs to pop up when I want one to show up. I should be able to bring a block diagram up without having every other VI front panel and block diagram also pop up. Then I have to go and minimize each window individually so I can look at a document or spreadsheet at the same time.

View All (2)

We know that LabVIEW has some magic that it uses for automatic error handling. What if LabVIEW could use such sorcery to enrich the error string flowing on the wire, with information about the originating source of the error -- specifically the VI Reference and GObject UID of the node where the error was introduced. Then a "fancy error dialog of the future" (TM) could utilize those UIDs to navigate directly to the node and highlight it (a visual effect to show which node it is). This behavior could be added to the Simple Error Handler and General Error Handler VIs, and maybe ever there could be a "LabVIEW Gems" vi.lib utility that can extract the VI Reference and GObject UID for use in other, 3rd party tools.

View All (3)

Current Behavior of LabVIEW
Currently, the error messages that emerge from bad call to a Property Node or Invoke Node only state that the error occurred in a property node or invoke node.

User Need

As a user of LabVIEW, it saves me considerable time in development/debugging, when I can precisely know why and where in the code an error occurred , so that I can get on with the actual work of fixing the bug in my own code/logic.

Problem For Users

The current behavior, described above, makes it impossible to know (without placing probes and retaining wire values):

A) Which Property Node or Invoke Node actually generated the error (in cases where there are many of such nodes)? Again, all we know is that some Property/Invoke Node on the block diagram of the VI raised the error.

B) Which specific Property actually caused the error, in cases where a Property Node has multiple properties that it is reading and/or writing. Again, all we know is that the error occurred inside a Property Node.

Proposed Solution

Error message for invoke/property nodes should state:

- the Name of the Method or Property where the error occurred
- the Class Name of the VI Server Object (if available)

- the Object Refnum value (e.g. the hex value of the object reference)

- possibly even (only if running in the editor and not the runtime environment) the VI Server Scripting UID of the GObject node on the Block Diagram for super-fast debugging with a "fancy error dialog of the future" (TM) whose LV Idea Exchange post with undoubtedly be coming soon...

View All (3)

Especially when I use setting windows I normally transfer the actual settings from a setting-cluster or from global variables to multiple local variables and display the current settings in the front panel. After the user edited the settings of course the settings need to be transferred again to global variables or in a setting-cluster. So if multiple global or local variables are used, each variable need to be changed from read to write 1 by 1 by right click and selecting the action from the menu.

So I suggest to implement a function to change it at the same time for all marked variables, similar to property nodes.

The suggested procedure would be:

Mark variables with the mouse by holding "Shift" on the keyboard or drawing a frame
Right click to context menue
Change all to read / write

The feature would be consistent, because it is for example possible to create local variables of multiple controls at once with a similar procedure. (I just don't get in mind why the order is always upside down when I do this)

View All (3)

Use Nigel to suggest commit message

View All (3)

Currently, new sublasses require the user to find the correct parent class in the class tree. In larger projects, this can be really painfull.

I suggest two simple things to improve this very common task:

1. Make the class tree searchable: Put a filter string input above where you can filter the tree by name

2. Add a "Create New Sub-Class from this Class" Item to the context menu in project explorer. This could simpy open the class tree with the matching class already selected. Something like this would also be great for interfaces.

View All (2)

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

- Data nodes of timed structures (timed loop, timed sequence).

- I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

View All (4)

Hi all,

I' normally using one or multipe queued message handler with a clustered enum (which is saved as Type Def.) and a variant as a basic architecture of my programs. This makes sense and it is relatively easy to search forward and check a program step by step. Unfortunately, it is not so easy to go stepwise back in the program for debugging., especially if there are multiple callers of a function.
Therefore I wish I have a function, where I can search for a single item of this enum Type Def.
I know that there is a possibility to search a text and of course it will find these items, but is also finds all other kind of things labeled the same.

I had a small chat with a engineer of NI already and we had an idea to gerneralize this a little to give it more use cases.
In the current situation, we can search for a:
- Type Def. , but then it will find each item of the enum OR
- text, but then it will find all items labeled with this text.

So here is our idea:
Create a possibility in the search window to combine these 2 search formats with a boolean operator, in our special case, this would be AND. But in other cases it might be also useful to have some other operators.

You are welcome to share any thoughts about it.

Best Regards, Patrick

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

View All (2)

Clear Probe Watch Window

View All (3)

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.

Static File Reference

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.

64bit references

It would be nice to get 64bit references. The old 32bit references are build up from two main parts: the descriptor represented on 12bits and the address represented on 20bits. If the application requires more than the available 1048576 references the labview generates an error because the memory is full. The workaround is to close references found in the memory. If an application requires serialization, this rule should be kept in mind. If the application serializes references by an input data, the input data should be limited, which means that really big data can't be handled although the machine have enough memory to handle them. Unfortunately, this feature in the labview has been not changed in the last 30 years although 64bit processor architectures are used world-wide and the 64bit labview plays a bigger role every year.
I think, the main reason is the backward compatibility...but is it possible to provide 64bit references which could be chosen by the developer itself, where the descriptor field will not be changed but additional 32bits are available for addressing? e.g. new option in the labview settings "use 64bit references" or selection (polymorphic) from all native components which could be create a reference. If the feature is supported by (environment) settings, then the compiler uses it generic. If the feature is supported component level, then the references should be checked for conflicts. At the end the architect/developer/application is no more limited inside in the labview because the available 4503599627370496 addresses are more than enough for a long time again.

LabVIEW Idea Exchange

Toggle selection of entire array with the spacebar

"Find All Instances" of a VI should be just as capable as "Find -> Callers"

Show more data when looking at non-editable VIs

Allow "Replace" of Broken PPL Dependencies

Make VIs show up in correct monitor's taskbar and be independent of others

Automagically include GObject UID in error messages when running in the editor

Show VI Server class name and method/property name in Property/Invoke Node error messages

Option Change all to read/write for multiple local / global variables

isfinite(x), isinf() and isnan() for Formula Node

nextafter() or increment/decrement ULPs in SGL/DBL/EXT

Use Nigel to suggest commit message

Make creating subclasses less painfull

Normalize terminals height for timed structures and FPGA nodes

Extend the search function (Ctrl+F) to get more detailed search results / Search a single item of an enum Type Def.

Add/Remove Diagram Space Inside Structures Without Resizing the Structure

Problem

Proposed Solutions

Why This Matters

Clear Probe Watch Window

Conectividad de LabVIEW con SAP S/4HANA ON Cloud

Static File Reference

Abstract VI execution

64bit references