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: 
Post an idea

It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.

 

Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.

Jim_Kring_0-1607621796261.png

 

My typical workflow is:

 

1) Start LabVIEW

2) Realize I have to pull\update my project from SCC

3) Explore to the project manually in windows explorer. Or open project, explore, close project, update SCC, reopen.

 

It would be nice to have an explore option in the Getting Started Window:

Explore from Getting Started Window.png

 

Either a right click menu, a button for each item or a button for the selected item would be great.

 

Same for VIs, maybe even the templates.

Typing “#” in the block diagram comment should give a suggestion of existing bookmark names(like autocomplete feature), as continue typing the list of matching names should narrow down. 

This helps;

  1. user to quickly select existing bookmark names
  2. avoid bookmark name mismatch due to typo error
  3. Save typing time
  4. maintain same bookmark name if need for tracking or linking purpose

 

Any thoughts? Will this be helpful ?

 

Thank you

Adarsh

CLA from 2014

I wanted to use a property node in an application today. I happened to have the Help context up and it showed "Run-Time Engine: No". But I could easily have missed that and not discovered the issue until much later, after building a lot of code and wasting time.

 

If the node had an obvious indication as soon as you put it on the block diagram - for example, a different color - that would help a lot and potentially save a lot of headache.

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.

 

Of course I could use CTRL+G, but I'd still need to clean up the opened windows.

 

Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.


It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.

 

It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!


Some additional thoughts:

 

Spoiler

 I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened...

 

Scrollbars might be nice?

 

The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?

 

If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.

 

idea1.png

 

Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂

I find the process of initializing Maps in LabVIEW to be unintuitive and inconsistent with the initialization process for other similar concepts (such as, say, arrays).  After some initial trial and error, the process I've settled into for creating maps is to drop a map constant, and then to drag and drop the appropriate data types onto it for my key and value. I first looked for an Initialize Map VI (which doesn't exist) and then tried to create the constant by wiring up appropriate types to an "Insert Into Map" and creating the constant from there -- but this doesn't work as expected because the terminals don't update appropriately.

 

What drove me to coming to the forum today though, was that in creating a malleable VI with a map inside of it, I found a breaking point for the "drop constant and drag values into it" approach. Since the map data types need to be dynamic to support malleable VIs, I've had to get creative to get around that...

 

_carl_1-1613065330054.png

 

 

 

 

An addition to the 'Find' project provider (or a standalone one) to find Parent Interfaces would be good.

 

I expected it to be included in LabVIEW already, but I don't see it.

Parent Interface Ideas.png

 

 

Jim_Kring_0-1607714897568.png

 

Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE.  In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain?  Here's the solution...

Jim_Kring_1-1607715044205.png

 

 

Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.

 

Note

The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.

 

Jim_Kring_2-1607715080073.png

 

 

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...

 

Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

Check out this nice readable diagram:

labels.png

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

 

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.

 

Proposal to make the Edit Items box longerProposal to make the Edit Items box longer

 

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

I wanted to suggest if it would be possible to add an option to resize the "Browse for Variable" screen which would help with the development of the new project. Especially when you have a generic subVI where you just change the variable but keep the logic built.

Download All

This idea was posted years ago and declined for lack of interest  (it got 6 out of 7 necessary, but I would have been the 7th!).  I would like to bring it back, I would like my application to have access to it's own version number.  In fact you can open the project programatically and see some build properties but not that one.  I can then grab the version from the build properties and set the default values on my FPGA code before compiling.

 

I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control.  Can't be done.  I find this very useful to make sure that my RT system and my FPGA code have the correct versions.

 

Same as with an about box, or version checking for compatibility.

 

The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.

 

At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP.  (Then select them all and set their values to default, hence the other suggestion about right click)

Please include mSec value in probe watch. This helps to find the execution time between two events within a few mSec delay. Thanks

When LabVIEW displays text, you are allowed to choose the following types of justification:  LEFT, RIGHT, CENTER.

 

Wouldn't it be much prettier if we could also select "fill justification".  Below is a subtle example, but its known to be easier on the eyes. 

Upvote!  😁

 

Capture.PNG

 

Similar to Visible items>Radix right-click menu it would be highly beneficial to have the same possibility for showing (and switching) of Representation.

 

 

ice_video_20200504-153122.gif

On bigger projects, when creating a new class, I find it time-consuming to track down the parent class I'd like to inherit from.

 

It'd save me some pain if there was some kind of filter and/or search option for this on the New Class GUI:

 

_carl_0-1614272545841.png

Other thoughts on this:

- While the tree structure is useful, I usually know the name of the parent class I want to inherit from, but I don't necessarily know the full inheritance of it, meaning the tree structure isn't the most efficient way to find it.  (Even alphabetical by class name would be faster in these cases).

- I'd find the tree structure here easier to follow if the lines were visible.

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