LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Strict typedefs and non-strict typedefs differ significantly. There's too much of a gap for me. Sometimes I'd love a control to be somewhere in between.

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked. That way we could shoose to long only boolean text, width or colour but leave the other properties free. VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.

When right click on a cluster and selecting "Reorder controls in cluster..." the bloody control indexes hide the labels of the controls in the cluster, rendering it difficult to select which ones should be in which order. How does the programmer distinguish between one or another control??!!!??? :mad:

Hopefully the image below is worth 1000 words. And yes, I did resize the cluster in the hope that the re-order index would go further to the right of the control, but it didn't.

This is something that needs to be fixed. It should actually be considered a bug rather than a product enhancement.

When dealing with a small cluster, it might be okay... but when dealing with clusters having over 200 controls, setting the proper order in a royal pain!

Download All

View All (1)

Allow 45 Degree Free Labels

View All (4)

Sometimes you have to read a lot of shared, local or global variables in sequential order. In this case, it can be a bit "boring" having to drag all the variables by hand. In addition, if you are reading shared variables, you also have to wire all the error cluster inputs and outputs. It could be useful to implement something similar to a property node or a Read/Write Control FPGA Node that you can resize and select which variable must be read or written in each position of the node as you can see in the following image:

View All (2)

Every time I need to open up several VI's at the same time, my Windows Taskbar becomes full of open windows and it gets hard to wade through everything. Part of the reason for this is that every time a VI is opened, two windows have to be opened to view the block diagram (both the front panel and the block diagram). I would like to see a fix that allows me to just have several block diagrams open at one time without their front panels, making it easier to deal with the numerous open windows I get sometimes.

A graphical programming language deserves to have great graphical tools representing the design of big applications.

It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes.

I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.

https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Project-to-Plant-UML-Diagram-Script/td-p/3984499

Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.

View All (2)

Linked Input Tunnel - Highlight Tunnel

Duplicating graph scale programmatically

We can duplicate a graph scale by right click, but we cannot do it when the VI is running.
It's better that we can duplicate and delete a scale both manually and programmatically on running VI.

For programmatic approach, I suggest invoked method like this:

Download All

View All (3)

I'd like to see the Destination Path in the application builder have an option to be a symbolic path based on the project directory (the direcotry where the project file lives) rather than an absolute path. For instance, if the project path (in our case, a local Git repo) was "SS10 Src Repo" and there was a subdirectory called "Builds", it would be nice to NOT have to specify "C:\users\xxx\Desktop\SS10 Src Repo\Builds" as the destination path, but rather check a box to say "symbolic path relative to Project Dir" and simply specify "Builds". If the repo is moved or renamed, all those destination paths in each project file need to be edited.

One reason for doing this is to locate executable that are built from the project, and called from project files via System Exec.vi. At runtime you need to find the executables (assuming they are localized and not in the PATH) and you can use the Application Directory file constant to figure out where your executables SHOULD be (relative to AppDir). But configuration to specify their location in each project file using an absolute path is a b**ch... it would be great to not have to edit all the dest paths in each .lvproj each time we check out the repo on a new machine, or by a different user...

View All (1)

I often work with DVRs, usually using typdefs or classes for the underlying data.

It's a serious pain to access the typdef or class from the DVR itself (control, indicator, or wire). There's no option for accessing this through the menu, and I often find myself dropping code in my block diagram to output the data type, then right-clicking on the data type and then from that menu opening the typdef or class.

The request: add a menu option for "Open Data Type Def." or "Show Data Class Library" to directly access the underlying type if it's a type def or class. This menu option could be exposed on wires, controls, and indicators.

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.

View All (3)

Case Structure Navigation

Case structures should have an easy to use Navigation like multiple grouped windows have in Windows 7. If a window is grouped in Windows 7 you will get a nice window that allows you to view what is in each window and navigate to the one that you want.

This would be very beneficial in LabVIEW for case structures.

It would look like the attached:

View All (1)

Run-Time Menus with Icons / Glyphs

When was the last time NI updated the Run-Time Menu Editor?

Yes, it's been a looooong time 😉

I think this should be put on the road map as soon as possible.

The user should be able to define glyphs that are shown next to the menu items, just like in any modern UI library.

The RTM editor itself could use a complete rework, too. At the moment that's not what I'd call use-friendly (you can't even resize the window!).

This applies both to run-time menus of VIs as well as controls and menus that are called programmatically.

No, I don't attach an image here - just click into the menu bar of any remotely modern application on your computer to get an example of what I'm talking about 😉

When I build a web service in LabVIEW, there is no version number updated for each build. If I then install that web service on my target, I have no way of determining what build has been installed.

I have solved this by creating some scripting VIs that update a VI control's default value when the build is run. This VI is available via my web service so I can ask it what version it is.

I think everything that can be built from the project should have a version attached to it and that version should be accessble and reportable. Also, it should be possible to auto-increment it.

View All (4)

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

View All (1)

LabVIEW Idea Exchange

Bridging the gap between strict and non-strict typedef

Do not hide cluster control label when re-order controls

Always Show Abort Button on Block Diagram

Allow 45 Degree Free Labels

Make every created Enumerated type a Typedef

Implement Variable Nodes similar to Property Nodes

Allow the Front Panel Window to be Closed While Keeping the Block Diagram Open

Include composition and usage relationships (and maybe others) in class hierarchy window.

Linked Input Tunnel - Highlight Tunnel

Duplicating graph scale programmatically

Add Option to Make Destination Path in Application Builder a Symbolic Path (relative to the Project directory)

Insert class member VI with right click on wire

Mechanism for Accessing DVR Data from Control/Indicator/Wire

Property accessor creation class shall have some user options

Case Structure Navigation

Run-Time Menus with Icons / Glyphs

Make it easier to show the radix when you change it.

Ability to Group Decorations on the Block Diagram

All build-able targets should have versioning

Standard marking for when 'error in' is ignored/passed through