From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page 

VinnyAstro_0-1705567415946.png

 

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

 

This happens to me all the time:

VinnyAstro_1-1705568287315.png

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

VinnyAstro_2-1705569130610.pngVinnyAstro_4-1705569195313.png

 

 

 - Vincent.

The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.

 

Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool.  If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.

 

Many of the property accessor VI creation scripting is currently hard coded, or not easily changeable. There might be some conventions around how to name a property accessor, or about the usage of the error handling case structure inside the accessors. It would be nice, if there was a user settable option for these.

The things that I have to change often:

  • The read VI to Get, the Write VI to Set
  • Front panel controls and indicators to the default style
  • Removal of the error handling case structure
  • Renaming the Error in (no error) to error in (this might be solved by the global ini setting though)
  • Organizing the labels to the left for controls and right for indicators on the block diagram
  • Cleaning up the front panel, with the Ctrl+U shortcut, while there is a scripting code in the quick drop to arrange both the front panel and the block diagram, by default Ctrl+F

To fix most of these, I modified the scripting library, for all the templates and the global defaults containing the name for read and write VIs.

It would also be nice if we could override the scripting class as a whole, in order to customize the end result, without needing to go over trough VI again.

In common, the loops are divided into two categories: entry control loops and exit control loops. The entry control loop checks the condition first, and the code will get executed only if the condition is true. But in the exit control loop, the code will get executed first, and then the condition is checked.

So the "for loop" and "while loop" are entry control loops that will not execute the code if the condition is false, but the "do while loop" will execute the code (run) one time even if the condition is false because it is an exit control loop.

 

This is also the case in Labview, where the while loop will execute the code (run) one time even if we wire true to the conditional terminal, but in the for loop, if we wire 0 to the count terminal code inside the loop, it never gets executed.

So it is more meaningful to say the labview's "while loop" as "do while loop".Screenshot 2024-01-05 110311.pngScreenshot 2024-01-05 110320.png

When pressing the "Stop" button when your project is loading you get this screen

 

BasvE_0-1704359642069.png

 

It seems that pressing "No" is the fastest way to abort loading but for bigger projects it still tries to load some classes/libraries/vi's which could take a lot of time.

 

I would love to see a way to abort loading the project instantly.

Bookmark manager is extremely useful for navigating large code bases. Every feature I have in flight, I've got marks for all my expected or in-progress work. Sometimes I'm using it to navigate through related chunks of code. So I'm constantly referencing it. But it gets buried behind windows, just like the equally useful Error List Window. I'm constantly reopening both, but the Error List Window has a quick hotkey to bring it to the front (ctrl+L). I'm finding more and more that I want Bookmark Manager to have a hotkey too. 

 

I've edited my personal menus to have "ctrl+," as the shortcut key, but I wish I could grab ctrl+k as a better mnemonic. Ctrl+k is currently paired with ctrl+j for bring to front and back... and those are keys that cannot be reassigned by users because they aren't main menu items. Personally, I'd place higher priority on accessing Bookmark Manager than reordering zplane, but I understand I might not be in the majority there. 

 

Anyway, the idea is for some standard key to be assigned to the View>>Bookmark Manager menu item. 

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-than/idi-p/2299860). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-window/idi-p/1844127).

 

dwb_0-1703104642443.png

 

Struggling to replace R&S FSW-K70 by VST and RFmx for my customer, found 16APSK and 32APSK are not directly supported by RFmx DeMod.  The customer is currently using FSW-K70 and their current test scnearios require 16APSK and 32APSK modulation and demodulation.  

 

I found a thread mentioning about APSK support below.  

 

https://forums.ni.com/t5/LabVIEW/APSK-Modulation-Demodulation/td-p/4232293

Timed Loops are only supported on Windows and RT, making it difficult to port applications that use it to Linux.

 

In talking to some NI R&D people, it should be possible to port the RT Linux shared library to desktop Linux. (Perhaps it wouldn't even need to be recompiled, since it's x86.) We also need support in the editor on Linux to allow us to drop the structure.

 

This seems like low-hanging fruit to at least try to implement.

 

It would be nice to have a keyboard shortcut to bring the unfocused BD or FP of a VI to be aligned with the active BD or FP by aligning top edges and distributing vertical edges compressed, like in the picture below. This would help to manage a collection of cluttered FP and BD windows.

 

CuriousSwede_1-1702722071766.png

 

And it would also be nice to "lock" this arrangement, in a way so that the two windows could be moved as one object, but still be individually rezisable.

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

 

CuriousSwede_0-1702651324354.png

 

I like that there is a zoom feature in the latest release, however, I don’t like how it was done.  Zooming in causes fonts to get really funky. I’m sure there are major reasons for this since LabVIEW IDE is not based on vector graphics.  I would just like to see better font handling for fonts.  

I don't know how many times I've built an application or packed library during my 25+ years using LabVIEW. What still annoys me extremely much is when the AppBuilder gets a tiny error, like "wasn't able to copy this file" (always at the END of the job), or something else having no effect on the (already built and completed) application or PPL itself. Still AppBuilder deletes the whole build, sometimes 30+ minutes time wasted, and simply tells you the build "FAILED". 

 

My suggestion is: Make AppBuilder just a tad smarter and don't delete the EXE or PPL! Just let the developer know what file(s) to copy manually, or what post action didn't work! 

Current Behavior:

When using the "retain all errors" option of the Merge Errors function the combined error message JSON output is not a valid JSON string.

This is the source output of Merge Errors when retain all errors is active - it is not a valid JSON string.

 

<JSONErrorMultiple_1.0>[{
    "status": true,
    "code": 111,
    "source": "This is a test message including\nnewlines"
},{
    "status": true,
    "code": 222,
    "source": "This is a test message including\nnewlines"
}]

 

 

Desired Behavior:

Make the combined errors source string a valid JSON string so that it can be parsed by other tools.

Valid JSON string:

 

[{"status":true,"code":111,"source":"This is a test message including\nnewlines"},{"status":true,"code":222,"source":"This is a test message including\nnewlines"}]

 

 The above JSON string can be formatted nicely by most tools - e.g. JSON pretty print - https://jsonformatter.org/json-pretty-print

 

The below string including the JSONErrorMultiple_1.0 key (but formatted correctly) also works:

 

{"<JSONErrorMultiple_1.0>":[{"status": true,"code": 111,"source": "This is a test message including\nnewlines"},{"status": true,"code": 222,"source": "This is a test message including\nnewlines"}]}

 

 

Current behavior:

When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.

 

Desired behavior:

When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.

Often when I want to look at the structure of a complex data type containing nested typedefs, I find the data type description in the Context Help quite heavy/verbose.

 

For example, could you tell at first glance how many levels of hierarchy there are in this data structure ?

 

raphschru_2-1700832707643.png

 

Well, actually there are 5 levels (including the root cluster), but this is obfuscated by the unnecessary levels added by typedefs.

The description could be much more concise:

 

raphschru_3-1700833121443.png

 

Here is an alternative that keeps the typedef type descriptions and appends them after the typedef name. However I'm not sure about this one because it could create description texts that are too long to be displayed in a single line:

 

raphschru_4-1700834723096.png

 

Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:

 

raphschru_7-1700835928603.png

 

What are your thoughts ?

 

Raphaël.

Show the Context Help for packed project library VI terminals. Without it, development suffers. For example, a wire conflict occurs but the nature of the source or sink type is not available for inspection.

pplhlp.bmp

One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.

 

There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.

 

The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.

Element of Array - edited.png

 

Thanks! 

When debugging it's common to place a series of probes on a wire that goes into an out-of multiple sequential subVIs (a "rail" wire).

 

For example, in the screenshot below, we might want to place four consecutive probes, on each of four consecutive error wire segments.

Petru_Tarabuta_1-1700167441346.png

Currently this requires four right-click gestures.

 

It would be useful to have a "Probe Chain" menu item (not sure if this is the best name, please suggest better ones) just beneath "Probe" or beneath "Custom Probe", or perhaps beneath "Generic Probe" in the Custom Probe sub-menu.

Petru_Tarabuta_2-1700167544064.png

When clicked, the "Probe Chain" would apply a probe to each wire segment in a sequential or consecutive set of wire segments. This would result in the same set of four probes shown in the first screenshot. It would save a few right-click gestures.

 

Another typical example would be when probing an object or cluster wire.

Petru_Tarabuta_3-1700167889489.png


Notes:

  • I'd be happy if the propagation of the probes occurs only in the downstream direction. What I mean is: if the user right-clicks on the wire segment between SubVI B and SubVI C (screenshot above), then probes 6, 7, and 8 would be created (using the numbering in the screenshot above), but probe 5 wouldn't be created because it is "behind" or upstream of the segment where the action was triggered from. I'd be happy if the propagation worked in both directions, but I suspect that the implementation would be slightly simpler for just the downstream direction.
  • In the first screenshot above, it would be ideal if the tool would create probe 4. But I'd be happy if the tool would omit creating that probe on the grounds that that wire segment is bifurcated, assuming that dealing with bifurcated wires would make the implementation more difficult.
  • Perhaps pseudocode for determining if wire segments are sequential or consecutive (i.e. if they form a "rail") is: if a node takes as input a single wire of a given data type, and outputs a single wire of that same data type, then consider the two wire segments to be part of the same "rail". I wonder if the Quick Drop Ctrl+W tool already implements a similar algorithm, and whether parts of that algorithm could be reused.

Thanks!

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

 

BD-Only VIs would be beneficial because:

  • They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
  • They would reduce the developer workload, thus making developers faster.
  • They would reduce the surface-area of the codebase.
  • They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

 

Notes

  • I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
  • The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
  • Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
  • I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
  • It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!