LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

4.png

 

 

 

 

 

 

 

 

 

 

 

 

Idea: The In Range and Coerce Include upper limit option should be selected by default.

 

1 (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.


In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!

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

Hi all,

image processing is not anymore the "tough stuff"/"niche" of the past. Videos are everywhere now, maybe even more than sounds. So functions that handle video should be included in the cross-platform standard labview, at least for the essential functions (reading/writing files with a minimal set of codecs, acquisition of frames through ip or usb for common protocols, conversion between image format for display and processable data). This would attract a lot of young users. It would also jumpstart future developments of labview in the direction of AI.

Thx

VI Analyzer is great tool but can only perform static analysis on VI (as far as I know). It could be nice to run some tests on libraries / classes or even projects files as well to enforce good practices. 

LabVIEW's units support angular measurements of degrees, minutes, seconds, radians and steradians but I don't see support for a full revolution. If this was added, we could use 'rev/min' as a unit which is a very common unit.

 

I think that users don't really use units as much as they might because of limitations such as this. There are some other things that I would like changed with units, but this should be and easy one to fix.    

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.

The default Data Directory path is set to "%Userprofile%\Documents" under windows. 

This is fine regarding custom probes, settings etc, but problematic when it comes to the compile cache and other "runtime" files.

 

In our corporate setting, this folder is always synced with onedrive AND with the roaming profile. So one problem is, that it bloats the synced volume, which by it self is annoying. But it often leads to corrupt files when onedrive blocks them or writes them in the wrong moment. 

 

So our workaround is to set this path to %programdata%\LabView Data. This, however, brings new problems, since now all users need write access to this folder.

 

I think a better way would be to save the folder under %localappdata%, but this can not be done with a symblic path and must be defined static, so it works just for one user.

 

Solution:

Provide a symbolic link to the %useroprofile% or %localappdata% folders. Additionally it would be nice, if the cache target folder could be seperately defined.

I would like the ability to perform a one page or bounded clean up on some of my diagrams. I understand such a cleanup will take longer and might not be possible in all scenarios but a space bounded cleanup would make certain block diagrams a lot easier to work with.

It would be great if Package builds also supported these two arguments as is supported by normal installers Advanced Page (Installer Properties Dialog Box) - NI

 

The value in this, is that you could then store your package feed in a directory that is relative to the package and automate installing the package and adding the feed to NIPM.

 

Currently, as per NI support, there is NO way to do that.

The database toolkit is limted by the database variant to data function. It can only cast to a labview datatype as long as you wire that datatype to the type input. This means that you have to know the datatype of any SQL query in advance (or convert to string). It would be very useful if the function would also accept a variant datatype. This way it would be possible to cast any complex type into labview datatype, without the need of a predefined cluster.

 

Image - casting the database input with a the variant type input (circled) doesn't work

aartjan_0-1735459849988.png

 

Listbox dividers are included in keyboard navigation of the listbox (arrow keys), without visual feedback. 

 

Dividers, which can't be selected programmatically or by mouse clicks, should be skipped during keyboard navigation.

 

See this post.

When running NI web server, the domain URL of the server will always redirect to the NI web server (or Systemlink) login page. Every Labview-built web application/webservice has a name and therefore must have a path (like: https://example.com/mywebapp)

I would like to be able to set a default redirect in the NI Web Server configuration to redirect the domain url to the default web application on that server.

 

It can probably be done in some Apache config file, but those a really managed by the NI web server configuration and are easily corrupted. My forum post about this issue has not yet been answered.

Idea:

 

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

raphschru_0-1732660843348.png

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.

If different libraries are created by different manufacturers, the same error code can occur multiple times and each has a different meaning.

If you include a project code (unique UID) with the error code, for example, it is possible to provide a unique error message for different program code origins.

 

 

1) Bring to Error Constant a Tag for the Project

 

michaeln_0-1731616848772.png

michaeln_1-1731616959219.png

 

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. 

 

Ryan_Wright__2-1731433895037.png

Open the VI Properties dialog when the Control key is depressed and the VI's icon in the upper right is double-clicked.

 

Right-clicking the icon shows a pop-up menu with VI Properties, Edit Icon..., and Find All Instances. Double clicking it opens the icon editor.

One thing I love with LabVIEW is to be able to execute the same source code on multiple targets (Win, Linux, NI Linux RT, etc)

 

I use Linux more and more to deploy my LabVIEW built apps and now instead of VM I use Windows Subsystem for Linux (WSL) on Windows 11, in very few steps I can create an Ubuntu instance, add a desktop and xrdp and then remote desktop into it.

 

What would be fantastic is to not event need a desktop and xrdp but just install LabVIEW in the WSL instance via terminal and then run LabVIEW on Windows and select the WSL instance as execution target as I would do for an RT target.

Bundle automatically names cluster elements for some references but not to a VI.

dwb_1-1729527929738.png

I have a habit of putting an enum with a digital display visible in each of my case structure frames controlled via enum.

 

It has become second nature already. Today I stopped and wondered why we can't simply include a digital representation as an "[X]" appended in the visible selector.

 

So here I am asking for it.

 

Intaris_0-1728572984028.png