LabVIEW Idea Exchange

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

The LabVIEW Icon Editor plays a central role in creating graphical icons for VIs.

Yet, it has some quirks that would be great to address, such as fixing a few issues affecting users on Linux.

 

Because the Icon Editor is written in LabVIEW, many LabVIEW users could actually help fix issues and suggest improvements more directly, if the Icon Editor source code were hosted on GitHub. This would allow people to submit issues and feature requests (even in the form of Pull Requests with the fixed/improved code).

By transitioning the Icon Editor to GitHub, NI could establish a process that allows for the incorporation of community improvements into the official LabVIEW releases.  This would improve quality and allow for more and better feedback from the community.

Note that NI has historically shared the Icon Editor code with each new LabVIEW release (here in the NI’s LabVIEW discussion forums).  However, there hasn’t ever been an effective mechanism for the community to contribute back their fixes and feature suggestions.  So, hopefully this would only take incremental effort for exponential gains!

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

The VI Properties window allows to select between local help file and Web-based Help URL.

 

Loc_fr_0-1718700568074.png

 

LabVIEW Class, Library and Project doesn't allow to use Web-based URL.

 

Loc_fr_1-1718700590702.png

 

Loc_fr_2-1718700613471.png

 

The idea is to have the same behavior for all source file.

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).

 

 

Jim_Kring_0-1707938415587.png

 

Background

 

The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.

Jim_Kring_0-1707938647270.png

 

Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).

 


Alternatives

We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference  (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

I wish LabVIEW had Official Container (Docker) Images.

 

With more and more users trying to use the docker in Continuous Integration, it would be 

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

 

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

 

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

 

Anyone else would support this idea or has anything to complement?

The title says it all.

In 2021 there was excitement about improvements to LVCompare and LVMerge, however there is still no way to compare classes or libraries.

I'm ok with not merging. I know that is a minefield. But at least show me what methods were added, what library or class settings were changed, which VIs moved from private to public and for classes, diff the private data and maybe show changes to the class heirarchy?

When manually analysing a project, we can set the target in which the VIs should be loaded. Unfortunately, VIs with RT code are often broken under windows, leading to wrong test results, or even worse, pop-ups asking for VIs.

 

Please add an Application Reference Input for the VIAn Run.v.

 

Maybe this option could also be useful set in the VI Analyzer configuration file?

Hi,

Following this forum thread, I post here my idea:

https://forums.ni.com/t5/LabVIEW/Modern-embedded-web-browser/m-p/4209271?profile.language=fr#M1219530

 

Is it possible to update the embedded web browser in order to comply with HTML5 ?

 

We uses external web pages to improve the user experience in out LabVIEW applications.

 

Regards,

 

Amaury

Currently, the Third-Party Licensing and Activation Toolkit doesn't handle PPLs. This makes creating a plugin, pay-per-component architecture difficult.  Handling licensing and activation of PPLs is needed as part of TPLAT or some other mechanism.

Swagger/OpenAPI  has become the default go to way to document and interact with rest API's.  It would be great that when you publish a LabVIEW webservice it generates the OpenAPI yml or json file (being able to generate both would be great).

 

Also having a right click in the lvproj webservice view that brings you to the swagger page for debugging would be helpful. 

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

The State Diagram Editor was a very cool tool and lots of LabVIEW users (not only beginners, far from!) are missing it!

 

And no, the state chart module is not a replacement for the State Diagram Editor!

 

Discussion here.

 

Image borowed from Ben

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

2-3-2010 1-35-27 PM.png

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

2-3-2010 1-41-08 PM.png

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

Codewars - Achieve mastery through coding practice and developer mentorship

 

What language is missing in this list??

wiebeCARYA_0-1662972904604.png

 

Codewars for LabVIEW should be mostly community driven, but NI would have to set it up.

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

 

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

 

21826iFF181EE2E7ECE408

 

This would remove one step required for most use cases, speeding up my development experience.

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

 

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

 

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

 

LabVIEW-Idex-Proposed-Fluent-Interface-with-Method-Chaining.png

 

See the first comment for footnotes...

If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.

 

Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.

 

 

OpenWith.png

The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.

 

Software development has moved on since a similar idea was declined in 2016

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-vers...

I would like to suggest just LVCompare is made available in all versions of LabVIEW.

If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.

As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.