LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.

Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.

Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.

As reference: This is the content of Class 1

What I suggest and expect is the following:

=> The class tree shows all available methods within each single class!

bright colors: Methods that are defined in this class; pale colors: inherited methods

View All (4)

As the number of classes in a project increases it gets harder and harder to figure out which methods in a class are overridden because you need to scroll up and down to compare the methods listed under each class. A distinctive glyph or icon in the project explorer window would be very helpful. I understand that there are workarounds like creating an override virtual folder and moving the overridden vis inside it or right clicking the class and opening the "VI for Override" window and checking if the vi is listed. However, a distinctive icon would drastically increase code readability.

View All (2)

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)

Replace icon of method overrides

Similar to the library banner functionality, I find myself wanting to replace the icon of method overrides with the icon in the parent. This is done automatically for new overrides, but I haven't seen any way to apply a new parent method icon to its overrides once they exist already.

I imagine this working like the library banner: whenever the VI icon of a dynamic dispatch VI with overrides in memory is changed a dialog could pop up and ask if you want to apply it to the children as if the icon had been freshly generated the way it is for new overrides.

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)

Size of Decorations

View All (4)

MyLabVIEW

Yup, Upgrading LabVIEW versions takes a day.

The "Process" today is:

Install from media
Configure the new LabVIEW.ini
install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
Mass Compile all them......
Fix palatte views... and import and mass compile User.lib\ for here.....
Sync glyphs on the icon editor (If the link works......)
Add VIT's
Add Project Templates
Mass compileVIt's and Templates
fix "Metadata.xml"...

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

View All (1)

Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?

Ever wish LabVIEW had more appearance customization to make better looking GUIs?

I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.

Take a look at the difference:

Not Ideal Front Panel with background image and NO Opacity Control

Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%

Before and After Appearance Settings tab in the Properties Window for a waveform graph:

Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:

Kudos and share this idea if you want it to happen!

View All (9)

Install LabVIEW API ONLY for NI Drivers

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

View All (4)

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

View All (5)

Easier Reordering of Terminals

This is a follow on to this idea. After terminals are wired to growable nodes. Make it easier to move and reorder the terminals. The switcharoo tool exists if there are only two terminals but it is difficult if there are more.

I suggest making it easier with a keyboard/mouse combination or mouse long hold or something like that, to select a terminal. Then let the user drag it to another terminal and drop it. If that terminal is wired swap the selected wire and the one dropped over. If not wired, move the wire connection to the terminal dropped over.

View All (2)

Allow a general purpose "on Save" hook

and is a more general request.

Have the ability to run custom scripting code on a save event.

What problem does it solve?

For me personally, I am working on an autoformatter. It would be nice to run that everytime something is saved. Right now I have to monitor the source folder from outside LabVIEW (using Python) and then use G-CLI to run my formatted. I'm sure there are probably other ways to do it and an onSave hook seems like the best choice.

I'm sure there are plenty of other use cases. Perhaps some kind of linting or enforcing some sort of style guide. ie if you save a VI without a description, it won't let you unless you enter a description. Perhaps even every time you save a file, run some unit tests?

Ideal Solution

Ideally the scripting code would have access to the reference of the thing being saved. The easiest thing to envision is a VI, but why not also classes, libraries, the project itself? Maybe also some indication of what triggered the save. Was it a saveall, a save all this library, etc. Maybe if it is a saveall, you get a list of all the things being saved, before anything happens?

The IDE would then wait to continue until the scripting code completes, maybe even failing to save on an error or a boolean - not sure if that is the best behaviour as in a bug in your scripting code could cause you not to be able to save - so maybe some way to override the hook?

Maybe include a way to autogenerate a VI with the correct connector pane.

Maybe it makes sense to generalize this to add more hooks into LabVIEW? Perhaps a call to update the project provider to something more usable/less user-hostile?

Reorder Probes

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram.

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

View All (1)

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

Why not include this in the context menu? (Bonus points if Polymorphic VIs get added too!)

View All (3)

Quick Drop Replace Terminal

View All (1)

Event When User Event Becomes Invalid

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

LabVIEW Idea Exchange

Allow Wiring to Determine Property Node Read/Write

Support Larger Glyphs in Listboxes and Trees

Show inherited VIs as "ghosts" under child class in project tree

Distinctive icon in project explorer for overridden methods

glyphs in case structure menus

Replace icon of method overrides

Need a way to visualize VI call chain hierarchy

Size of Decorations

MyLabVIEW

Opacity/Semi-Transparency appearance settings for attractive Front Panel objects and User Interfaces

Install LabVIEW API ONLY for NI Drivers

LabVIEW Find Search Scope - Add user.lib

View >> Gigantic Coercion Dots (now with a variety of colors)

Easier Reordering of Terminals

Allow a general purpose "on Save" hook

Reorder Probes

Option to add malleable VIs directly into project

Connector pane double click terminal jumps to control

Quick Drop Replace Terminal

Event When User Event Becomes Invalid