LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

The Matlab data plug-in supports version 7.0 files.

https://www.ni.com/example/29178/en/

 

The newest files are 7.3:

https://www.mathworks.com/help/matlab/import_export/mat-file-versions.html

 

Projects are beginning to require this newer format.

 

When writing a string key to a configuration file with the Config file "Write Key.vi" on the File I/O palette, the value will always have quotes around it because of the "Add Quotes.vi" in that particular method as you can see in this image.

 

WriteKey.png

 

Not all external programs handle ini files with quotes around strings as well, and this question was already asked and answered in 2010, but for some reason NI never added this VI or the option to remove the quotes to the actual palette.

 

I would like to have the option to have my string keys with and without quotes.

Companies around the world are trying to make it easy for robotics, for example NVIDIA is doing everything that they could get into simulation and and NI should have been in the front to support, just like NI had the tools for mobile interface in 80's, and never released to the public, if it would have happened then Android would not have born, just like that robotics once NI loses it to NVIDIA and python and other tools, it would be difficult so I am trying to create a simulation environment just like digit twin for robotics, where labview will simulate in open source for Gazebo, and then based on the simulation will control the actual robot.

 

Setup LabVIEW talking to Gazebo through ROS, if you are interested to be part of a group where we could get the software updated, please email me at jacobs.mathews@gmail.com

I installed LabVIEW 2020 on my PC and my friend is working with LabVIEW 2016 every time I open his projekt now it gets upconverted and if I downconvert it to 2016 I can only do it via the special option, which does not even allow me to overwrite the original 2016 files. Iam stuck with 2020 since I did not buy SSP GREAT, how is this in any way userfriendly? Its worse then the compatibility of Word with Libre office.

 

That was Bryans original post 12 years ago, its still the same.

https://forums.ni.com/t5/LabVIEW/How-do-I-continue-to-save-for-previous-version/m-p/4143151#M1194547

pbpatel_0-1617942167348.png

It would be nice to have this facility for splitter lovers.

The built in web services are a handy way to expose a simple RESTful API to a LabVIEW executable. And it's nice that it supports hosting static content like HTML pages and javascript. But it would be extra nice if we could host directories with dynamic content, such as a folder of log files that we want to expose for troubleshooting purposes.

 

For example, if I have services that generate debug logs, I could do something like start up a python simple http server to host the log directory and make the files accessible remotely. As log entries are appended, or new files are created, they are automatically made available via browsers (or programmatic GET operations). It would be really cool if the native labview web services could do this, to avoid having to set up a separate process (and manage another port number). If I've already set up a web service for remotely interacting with this process, it feels natural that I would be able to extend it to host stuff like this.

There are several great ideas on this Idea Exchange that were marked as Completed because they were implemented in NXG.

Although arguments could probably have previously been made that this wasn't really "complete" for most requestors, it was reasonable given the idea that NXG would replace LabVIEW 202x.

 

Given the updated fate of NXG, can these posts all be reevaluated and marked as either New or In Development, as appropriate?

If the evaluation is too effort-intensive, can they all be marked as New again?

Many common functions include a "found" or "exists" output. Examples include:

  • Get Variant Attribute
  • Element of Set?
  • Config file VIs (Read Key, Write Key, Get Key Names, etc)
  • Chek if File or Folder Exists

 

Why then does Look In Map provide an inverted ("not found") output? Wouldn't it be better if it was consistent with other similar functions??

fabric_0-1617240144803.png

This is most frustrating when replacing existing code using variant attribute lookups with equivalent maps. "Look In Map" is pin compatible with "Get Variant Attribute" except for that one inverted output! This has caught me out on more than one occasion...

Ello,

 

Many of us have to install multiple versions of LabVIEW on a development system due to legacy projects where the benefits of transfer to newer versions of LabVIEW are outweighed by time and risk.

 

What I'd like to be able to do is have modern versions of drivers etc installed at the same time as legacy ones that are unsupported.

 

For instance, I have IMAQdx installed for LV2019 and LV2016 using VAS 19.5, which is only backwards compatible down to LV2016 (ref). I'm trying to install IMAQdx 4.2 to be able to use it as part of an LV2013 installation, but the installer will always tell me that there's no need, I've got a newer version! Unfortunately, said newer version isn't compatible with LV2013.

 

My workaround is to uninstall IMAQdx and IMAQ 19.5, install 4.2, then deal with the consequences afterwards. The other alternative would be to set up a series of VMs for different versions, but that's easier said than done in my company!

Please allow value signaling for the boolean button with latch mechanical operation.

It would be helpful if the LabVIEW Python node natively supported Python dictionaries as LabVIEW Maps. This would make it simpler/easier to support a frequently use Python structure. You can work around but you have to do extra data preparation/formatting in both LabVIEW & Python. It would be nice if the node handled that converting to list of tuples and building the LabVIEW map or vice versa for us.

While writing/debugging applications that make heavy use of reentrancy it is not uncommon for a reentrant VI to be left open after the rest of the application has shut down.  This leaves VIs, Classes, LVLIBs locked in the project and your only recourse is to hunt down the offending reentrant item or close the project and reopen it. 

jon_mcbee_0-1616609690472.png

 

It would be valuable to be able to see the running clones in the list of reentrant items found by navigating to View>>Browse Relationships>>Reentrant Items, maybe denoted by a *, like this below:

 
 

Having that would easily allow me to open the running clones and close them out manually so I can continue debugging.

Don't have enough time to make any fancy pictures or diagrams, but the idea is simple. When cleaning up VIs, I find myself constantly switching my right hand between the mouse and the arrow keys. It would be really slick to be able to move highlighted FP/BD objects with a CTRL + Mouse Scroll combination. Here's my thoughts on what the combinations could be:

 

CTRL + Mouse Scroll Up: Move highlighted object(s) one pixel up

CTRL + Mouse Scroll Down: Move highlighted object(s) one pixel down

CTRL + ALT + Mouse Scroll Up: Move highlighted object(s) one pixel right

CTRL + ALT + Mouse Scroll Down: Move highlighted object(s) one pixel left

 

And to get really fancy...

 

CTRL + SHIFT + Mouse Scroll Up: Move highlighted object(s) several pixels up

CTRL + SHIFT + Mouse Scroll Down: Move highlighted object(s) several pixels down

CTRL + SHIFT + ALT + Mouse Scroll Up: Move highlighted object(s) several pixels right

CTRL + SHIFT + ALT + Mouse Scroll Down: Move highlighted object(s) several pixels left

please do needful to enable Trim White Space function to accept string array input also

V1.0 of TOML was recently released : https://github.com/toml-lang/toml/wiki

There is an MIT Licensed open source project here : https://github.com/erdosmiller/lv-toml

 

It's a nice starting point, but :

- it's not complete

- it's based of v0.4 of TOML

- it not maintained as stated here : https://lavag.org/topic/21972-anyone-using-toml-files/?do=findComment&comment=135193

- it's not native

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.

 

If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).

 

However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).

 

Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

Trying to toggle back and forth between the instructions and the code for the online CLD exam was both distracting and difficult since most hot keys didn't work. Placing the instructions or goals in the block diagram would allow easier reference for those taking the exam. 

Since LabVIEW 2017, it's possible to build application with a compatibility with future version of run time engine.

This option is set by default but can be disabled.

 

I just discover that this option is set for real time applicaiton and cannot be unset. I mean that if you build your application in with labview real time 2017, it will run with a system installed with a newer version of LabVIEW Real time.

 

This can be a good idea, but I'm a little bit surprise that I cannot have informations on that options for real time application and I can't control it.

 

Here is a way to test it. Tested on a real time desktop with pharlaps.

Install RT target with LV 2017.

Build an application and set it to run as startup. A simple application writting something in the console is enough.

Make sure your applicaiton is running at startup.

Update your system by only installing LabVIEW real time 2019.

Restart your system and your application is still running !

 

Because I faced an issue where LabVIEW 2020 broke my application build in LabVIEW 2017, I'm asking myself how NI can garanty that a real time system will work in any case if we upgrade the system to a higher version of LabVIEW real time version without recompiling the application.

 

Real time system can be used to control system that can be a secure system. If a user update by error a system, I want to keep my system safe for user.

 

So my idea is to remove this option or give access to the user to unselect this option to avoid any bad behavior.

 

best regards

When creating a new Source Distribution to run on an RT system.  It makes no sense that the "Exclude vi.lib VIs" option is checked by default.  The VI will not run and cannot be launched asynchronously which is the whole point of a source distribution on an RT system.

 

The "New Source Distribution" wizard that creates it with default properties should look at the context it is being created and pick appropriate options.  This is supposed to be a smart IDE.

We use Queued Message Stage Machines a lot and often send messages through API calls. In a state machine I prefer using enums to determine the state and in the QMSM that would be useful too because sometimes a typo in a message in an API call stops it from working. 

 

However, the Message Queue functions accept string only. 

 

 

image.png

 

Even if we make changes to the message cluster or make the VI polymorphic but we would then need to do it every time we are setting up a new machine with LabVIEW. Would this be useful for anybody else? 

image.png