LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Comments for code explanation of the block diagram can be added using the text labeling tool but they can occupy too much space. Many LabVIEW examples use an alternative of placing a marker label such as "1", "2", etc at desired locations which refer the viewer to another comment location on the block diagram where expanded corresponding text is displayed. This means though that diagram scrolling must be done to see the explanation for the comment. How about a Help Hint type of "hot" label that when hovered over pops up a short comment and when clicked on shows a more detailed comment. Similar to the front panel's Description and Tip but available at edit time and maybe not requiring a right click to see the full comment description - just a left click.

View All (1)

Project error code files ...

Today, the management of error codes is a little bit complicated. (Error code file to include in executable properties ... )

It could be intersting to add a new entry to a project which could list all custom errors only available to the project.

This file or project property could be associated with the project as a source code !

How many time you'll get an old application ... without all files ... And error code file is a source file. So the error code file should be located near the project ...

Or best inside the project !

The best way to manage the custom errors would be to edit them in the project properties like "conditionnal disable symbols".

Simplifying the error code management will reduce the none managed errors ( The famous 488 error !!!! which i hate ! )

View All (3)

The number of parallel Instance is currently capped at 64, independent of hardware. This limit should be raised.

First Reason: Since even 64 bit Windows 7 supports up to 256 cores, it would be reasonable to raise that limit to 256.

(Even the next version of windows mobile (8) will support 64 cores. (Mobile! On a Phone! 🐵. Obviously the upcoming hardware is fast moving in that direction.)

Second Rason: Sometimes it is useful to generate many instances, even if we have fewer cores available, for example maintain individual data in a large number of identical reentrant subVIs. (Such an usage example where we want many instances even on a single core machine can be found here)

Idea: Raise the max number of parallel Instances of a parallel FOR loop to 256.

A full ZIP API

Having a complete API for zip file

Currently it has :
- New zip file
- Add a file to zip file
- Close zip file and add a comment
- unzip the zip file to a folder

This API is not quite complete.

Example of use of ZIP files: In a data streaming application, you want to make an archive of recordings files. The data files average 500 MB Once compressed, they do more substantive than 50MB. You create an interface to assist the user in steps of compression. Once compressed, you want to propose an interface for retrieving compressed recordings.

The ideal is to list the files and clarify some information, such as track number, recording time and a few other indicators related to data.

But to do that, we 'could' use two ways:
- The properties of the zip file.
- An additional file that would read that to see them.

Several problems arise:
- It is not possible to read the commentary added with the close function.
- It is not possible to edit the commentary added with the close function.
- It is not possible to decompress a single file.
In the example, if we unpack all files to read properties, it'll take time and a lot of CPU resources.

It would require full management functions:
- New file
- Close file
- Add a comment
- Read the comment
- Erase the comment
- Add a file
- Delete a file
- List all file (with or without a mask)
- Uncompress a zipped file to disk
- Uncompress a zipped file to memory

- compress and uncompress a string in memory (usefull to optimise the network data flow)

In the ideal case, a zip file should be considered a folder. So we have all classical file functionality to manage it.

View All (4)

Currently, the only object that we have access to in an Event Structure it the control itself:

This is not what I am interested in, most of the case, when I am working on the BD.

Rather, I'd like to either find the terminal, or local variables, references, etc.

Moreover, going to the control using the above shortcut may result in a messed up FP, not mentioning cases like this:

where the control may be hidden or invisible because it is in another tab than the one currently selected.

Now, I know that some will argue that the control terminal is most of the time in the event structure (see for instance this thread)...

But read the thread's comments for counter arguments: we would be talking about the Value Change event, but this is not what I am talking aboutin general: any event for that control should give access to the control's terminal (and BTW, it could very well be an indicator) and, as for a terminal, to this list of related objects:

(The last one courtesy of this shortcut plugin)

View All (3)

View All (2)

Run selected code only

I often have the situation in which I want to test a portion of my VI without running the entire VI. To accomplish this, I usually copy and paste the code fragment into a new VI and run it. When I'm finished, I close out the new VI without saving it. I've often wanted to simply select a code fragment and run just that part. For example, by right-clicking on the code fragment and selecting "run". It would be a nice little time saver. Of course, this would really only be feasible in certain situations: namely in which the code does not have any dependencies on other code sections. This essentially means that all the inputs are controls or diagram constants and all outputs are indicators. This seems like it would be easy to add to LabVIEW since it is just a subset of existing functionality. Other implementations would probably be more trouble than they are worth.

View All (5)

There are already a couple ideas to retain wire values on a hierarchy (here and here). This is a request to disable (or toggle) the 'retain wire values' option on all VIs of a hierarchy in the same vein as 'disable breakpoints on hierarchy'. This request was spurred by an investigation into VI performance on resizing a very large 2D array of strings, wherein several memory allocation strategies and lookup strategies (arrays, maps, variants) had been exhausted, only to discover that a subVI whose (front panel and diagram had been closed) was set to retain wire values. Merely toggling the retain wire value setting off on this particular subVI improved performance by approximately one order of magnitude for this particular project.

Investigating and accurately measuring run-time LabVIEW performance can be challenging with so many debugging tools available, the impacts of which are not immediately obvious. For this reason, I would like to see a menu option that recurses on VI hierarchy and toggles the 'retain wire values' option, in the same vein as the option which removes all breakpoints from VI hierarchy. The option would be very helpful with run-time performance investigation or optimization.

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

View All (1)

View All (2)

View All (3)

A Better "List Unsaved Changes"

This is a neat tool I have only recently begun using heavily, but there are some big drawbacks that I would like corrected:

1. The window is not resizeable. As you can see, virtually all of my VI names overflow the "VI List". Also, I would like to see "Changes" have more line items vertically. (Similar idea: Allow Find All to be Resized)

2. I cannot double click the VI's in "VI List" to open that VI. More often than not, I want to check out those VI's to see if the "changes" are legit.

3. I would further like to be able to double click each line item in "Changes" and have the BD zoom and focus on that change, just like it does when you "Tools > Compare > Compare VIs..."

4. This window is modal, so I can't even do #2 - make it floating. (Another modal window woe: Make Build Error Window Floating, Not Modal where I explain a brute-force-screenshot workaround).

5. A huge help would be if the list of "changed" VIs could be shorter in the first place just by using the Do Not Save Option

These five ideas are just some basic UI improvements that would make this feature much more usable and powerful.

View All (5)

This should be simple....(!?)

I want my user to be able to resize the window but only in one dimension - e.g. drag the right border of the front panel right or left but not allow them to resize the height while the VI is running. (In my current project it just doesn't make sense to allow them to do this).

I have to keep rewriting the front panel size on the resize events but it has ugly side effects (parts of the front panel become visible temporarily until LabVIEW puts the bottom border back, amongst other things).

The VI properties can disable resizing completely but it should be easy to add a couple of sub checkboxes for Height and Width.

I'd like to see those properties reflected in the usual places (property node etc).

Support didn't have a better solution than the code I have but suggested that I put in an idea .... so this is it!

View All (4)

Comments in configuration file (*.ini)

At the moment you can Replace a Missing VI in the Project by popping up on the project item and selecting Replace with... which brings up a file dialog where you can go trolling through directories to locate the missing VI.

I propose the option where you can Replace the Missing VI by navigating the Palette.

This method would be much quicker especially if you have a lot of VIs to replace.

An example use case is that you have refactored code in your project, creating a reuse library seperate to the project and changed the namespacing of the VIs as part of the distribution.

This distributed library is now available in the palette and you want to relink your project back to it.

I imagine it would function simiar to the below:

View All (1)

It would be really cool if LabVIEW had a String Control with inbuilt Spell Checking functionality available at Run Time.

End users will be able to correct input data whilst developers would not have to implement anything (except for maybe enabling spellcheck as a Property of the String Control) as it would all be handled under the hood.

I am thinking that it would look similar to the operation below:

The standard functionality of spell checkers in browser apps (e.g. IP Board) would be sufficient. The above example is from IP Board's editor and the implementation appears clean and fits the workflow well.

There are two other spell check Ideas here and here but the ideas/discussions are about spell checking in the IDE - this Idea is for Run Time.

Note: This idea could be expanded to other use cases however, the above is my primary one. And yes I ran spell check on this post to avoid any of those comments

View All (1)

Add Subpanel property Frame.Visible

View All (3)

LabVIEW Idea Exchange

Description and Tip-like Help Hint Comments for Block Diagram

Project error code files ...

Support more parallel instances in the parallel FOR loop

A full ZIP API

Add "Find Terminal" (and more) in Event Structure context menu

Replacing "Match Pattern" with "Match Regular Expression" should work as expected

Allow direct entry of Polymorphic VI Menu entries / Labels

Run selected code only

Autosize Column Width option for tree controls

'Do Not Retain Wire Values on Hierarchy'

Add ability to disable "Allow future versions of the LabVIEW Runtime" for Real Time application

Glyphs on Controls and Indicators if used on connector pane

Move (or at least copy) the Select function to the Boolean palette

A Better "List Unsaved Changes"

Independent control for user resizing front panel horizontally and vertically

Comments in configuration file (*.ini)

Replace Missing VI in LabVIEW Project using Palette

LabVIEW Spell Check For String Control in Run Time

Find Broken VIs : A New Project Feature

Add Subpanel property Frame.Visible