LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

I've got some code on my diagram:

I need to wrap the code in a case structure, so I do:

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

Many common functions include a "found" or "exists" output. Examples include:

Get Variant Attribute
Element of Set?
Config file VIs (Read Key, Write Key, Get Key Names, etc)
Chek if File or Folder Exists

Why then does Look In Map provide an inverted ("not found") output? Wouldn't it be better if it was consistent with other similar functions??

This is most frustrating when replacing existing code using variant attribute lookups with equivalent maps. "Look In Map" is pin compatible with "Get Variant Attribute" except for that one inverted output! This has caught me out on more than one occasion...

View All (1)

Probing a typedef results in a vertical list showing all the fields in the cluster. Creating the typedef cluster often involves organizing the fields in a particular layout, setting units etc. It seems like probing the data and displaying it in the same format makes more sense.

For instance, I have a cluster of camera information set up as a strict typedef:

When I probe a wire of this information I get:

This cluster isn't too big so getting to all the information doesn't require a lot of searching and scrolling, but that can be an issue. What's more of a pain is that the default unit for angles is rad and I cannot mentally convert them quickly so I end up having to double-click each 'rad' label in the probe window and change them to 'deg' so I can confirm the data is what I expect.

I know I can create a custom probe to display the typedef, but having to constantly create custom probes for each cluster is a bit of a burden.

Am I missing something? Is there a good reason to NOT display the probe using the typedef?

View All (4)

Increase Icon Resolution

This is a very small suggestion, and hopefully easy to implement. When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires. All I'm asking is that Error wires are always placed underneath all other wires when they are created. To my mind, this improves the readability of the diagram.

What would help further is if Error wires were "faded", as if they were 50% transparent. You do need to be able to see them, but not such that they stand out. But I'm much less certain that such a change could happen. The khaki color is an improvement on the old pink though, that's for sure!

View All (6)

Package build specs include a way to specify runtime package dependencies, and LabVIEW 2023 Q1 includes a utility to assist you in identifying and installing NI drivers used by a LabVIEW project. JKI dragon now exists to specify/install VIPM dependencies for projects.

The missing piece is non-NI NIPM packages. For instance, my company distributes a bunch of NIPM packages containing PPLs that are required by multiple projects. It'd be nice if these packages could be added to the "Manage Dependencies" dialog.

My idea is to add a way to specify at the project level what non-NI NIPM packages are needed to edit/build the project, which can then behave similarly to JKI dragon or the "NI drivers utility," so we can declare more of the dependencies for developing the project.

Wire bend issue to numeric nodes

Hello,

As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.

So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.

So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.

View All (1)

This is a really basic thing, but it would be helpful if the qualified name (as seen in VI Properties) was enabled so it could be copy and pasted into documentation.

When I'm writing detailed documentation to tell other developers how the software works I often use the qualified name as opposed to VI name. For example "Send Creep Command.vi" doesn't tell the developer where to find it, but "Motion Control UI.lvlib:Motion Card 2 Data.lvclass:Send Creep Command.vi" does.

I would be happy with the string being enabled (so it can be selected and copied), or a button that copies the string into clipboard.

View All (1)

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

Why not just keep both as they were when copying?

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

Auto generate library palette

Cluster Support for "Add Array Elements"

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

View All (1)

Add Target to VI Analyzer (API)

View All (5)

glyphs in case structure menus

Another for the wish list.

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

See attached pic for an mock up.

There are probably lots of menus that could benefit from something like this.

View All (1)

Make Shift+Drag more usable

Pressing Shift and dragging an object with the mouse make it move only horizontally or vertically. Great!

Unfortunately Labview decides which direction to move (horizontally or vertically) based on the first pixel the mouse moves. So, if you want to move something horizontally, but while clicking your mouse moves one pixel vertically, you're stuck with that direction and can start over again. ☹️

"Normal" applications decide the direction to move based on the ratio of x/y mouse movement: If the mouse moved more in vertical direction, the user obviously wants to move that way, if the mouse moved more in horizontal direction, then that is the user's intent. This means you can switch the direction while dragging and you're not stuck to one direction!

PLEASE modify the annoying behavior of Labview accordingly!

View All (1)

This recent idea reminded me of something I have wanted for quite some time now: the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.

The basic idea is simple: all properties have two terminals, one for writing and one for reading (except read-only of course). No right-clicking, just wire up the direction you want.

The bottom case is a bit interesting. I see a few possibilities:

1. Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2. Read then write : returns previous value. What happens if there is an error? Passthrough, old value?

3. Write then read: almost always passthrough. In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.

I would expect it to perform the write and then the read (3) or passthrough (1). What is more important to me is the actual value and not the intended value. Mentally I just see data flowing into then out of the PN when both are wired.

Bottom line: I see no reason not to permit the wiring to determine read or write of a property.

If there is a ~~cop-out~~ lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list. Then I could at least do the write+read with a lot less mouse movement.

View All (1)

Problem Statement

I often find myself debugging code that seems to have "hangged" and I want to find out which VI is causing the "hang" (maybe it's waiting on some event/queue/message/timeout or maybe it's stuck in an infinite/long loop). There's no really easy way to figure out which subVI (or perhaps a node) is not returning from its call.

My Work-Around

The way that I currently do this is to start opening up VIs and looking at their "Run Arrows" (the run buttons on the VI toolbar) to see which subVIs are currently "running" (being called).

Running (Top-Level VI)

Running (Sub-VI of a Running Top-Level VI)

<< This is what I look for

Not Running (Sub-VI of a Running Top-Level VI)

This technique works OK, but it takes a lot of time to track down the running VI (in applications where there are LOTS of VIs), since you have to just start opening up all your VIs a looking at their run arrows.

Question: Is there any way to look at the run state of a VI using VI Server or Scripting? Unfortunately, the VI Execution.State property is "Running" for all three states shown/illustrated above (the "Idle" state is for VIs that are not reserved for execution, meaning they are not in the hierarchy of a running top-level VI). Maybe I'd also add to my feature request that it would be nice if there were a way to interrogate this state using VI Server or Scripting.

Possible Solution(s)

What would be nicer is if I could ask LabVIEW to Find all Running SubVIs/Nodes and visualize them by their VI Hierarchy. Maybe we could have an option to show the run state in the VI Hierarchy window. And, maybe there could be a way to only show running VIs (hide all Not Running / Idle VIs).

Now, I realize that the VI hierarchy window doesn't have any way to visualize multiple subVI "instances" of a VI, but maybe that could be an option as well (Show all SubVI instances. Also, it would be cool if we could show "Clone" instances of reentrant VIs... but, I digress.

Also, the VI hierarchy window only shows VIs, it doesn't show nodes/functions that might be running (and what's causing my code to "hang"). It might be nice if we could also include nodes, at least for the purpose of helping me find out which nodes are running.

So, I'll end by just stating that I need some easier way to figure out why my application appears to have hung and I hope that this "Idea" leads to more discussion and maybe some more features in LabVIEW to help me debug and visualize my applications.

Do you have any ideas for how to better debug applications that appear to have hung? Do you have ideas for new LabVIEW features that could help?

Thanks!

View All (2)

LabVIEW Idea Exchange

Optional (and easily-dismissable) prompt to change newly-dropped case structure frame to FALSE

Output of "Look In Map" should NOT be inverted

Probe of a typedef cluster should use the typedef for display

Increase Icon Resolution

Always place Error Wires underneath other wires

Specify and and auto-install edit-time NIPM dependencies

Wire bend issue to numeric nodes

Enable Qualified Name in VI Properties or add copy button

Keep block diagram layout when copying between front panels and vice versa

Auto generate library palette

Cluster Support for "Add Array Elements"

[Linux] LabVIEW Project Environment missing "Explore..." option (to show the file in the OS's native file explorer)

Add Target to VI Analyzer (API)

glyphs in case structure menus

Make Shift+Drag more usable

Allow Wiring to Determine Property Node Read/Write

On auto-generated class palette, properly scope available VIs

Need a way to visualize VI call chain hierarchy

Conditional Indexing to optionally output the false condition (along with the true one)

Overrides of interface methods that have error in/out terminals should wire the error by default