LabVIEW Idea Exchange

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

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.

When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.

 

Mads_0-1695798309247.png

 

Issue:
Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)

Proposed feature: Trends
It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends. 

 

Proposed feature: Automated Analysis
Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).

I mean, OpenGL is cross platform, right?  Let's bring graphics performance at least into this century.

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

I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.

 

If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation

 

I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.

Quick Drop (Ctrl+Space) should support replacement (Ctrl+P) on the block diagram terminal as well as the front panel icon. The front panel icon can be selected and replaced with another .lvclass but if its block diagram terminal is selected the replace does nothing.

QDP.jpg

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.

 

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

 

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

 

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

 

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

 

Essentially, what I would like is a Type Specialization Structure that works backwards.

 

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

 

Simple example of SelectSimple example of Select

 

 

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

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"}]}

 

 

  • The default widths of the LLB Manager window and the Name column in the multicolumn listbox are too narrow (see the attached picture). They should be widened considerably so VI names are completely visible without having to resize the Name column and LLB Manager window.
  • The multicolumn listbox displaying items should be replaced by a regular single column listbox since only one column in the multicolumn listbox is actually used. This would allow for listbox scaling due to window size changes to work much better. Currently, when you resize the LLB manager window, the multicolumn listbox resizes as expected, but the width of the Name column doesn't change accordingly, which means you often have to manually resize the column when resizing the window.
  • You should be able to select multiple items in the listbox, such as VIs, and open them by pressing the Enter key (like the behavior in Windows File Explorer). The only way to open multiple items from the multicolumn listbox currently is to select them and then right click on them and select Open in the shortcut menu.

In a simple project, the main entry point into an application is usually easy to find:

simple.png

 

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

complex.png

 

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 

 

One possible implementation:

links.png

  • Display tagged items as links at the top-level of the project.
  • Links would be pinned to the top row
  • Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
  • For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
  • In principle links could point to anything interesting, not just the main VI.
  • Double-clicking a link should open (or navigate to?) the target item

 

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

 

Before.png

Start wiring the new error, then click on the merge error node.

During.png

LabVIEW expands and connects the error wire

After.png

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

 

 

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

Bonus.png

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

 

It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down.  Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI.  The tool should just work.  "Ctrl+." doesn't always work.  You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

 

2020-12-11_12-28-19.png

 

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

 

 

2020-12-11_12-34-49.png

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon: raphschru_0-1665514290538.png

instead of a library control icon:       raphschru_4-1665514883384.png

 

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

 

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

 

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

Since 1986, when LabVIEW first launched, there has been one constant.  Icons are 32x32 elements. 

 

That made sense on 17inch CRT monitors.  There have been improvements in displays since then but, no corresponding improvement to the Icon resolution. 

 

Isn't it time to change that?

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.

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! 

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.

Using 2023 for the first time (skipped 2021 and 2022)

 

QuickDrop used to be quick.

It was very convenient.

 

Now it takes a second to load.

 

That's pretty inconvenient if you're trying to... do much of anything.

 

Best example: If you're trying to remove code (Quickdrop's Control-R), now instead of quickly removing the selected code, you get to deal with accidentally RUNNING your VI (Menu's Control-R)

 

Please make it Quick again