LabVIEW Idea Exchange

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

To "reduce friction" in creating subVIs from portions of code, I suggest adding "Create subVI from Selection" to the block diagram contextual menu- rather than only having it in the titlebar menu.

Automatic routing of new wires is actively trying to get in my way!

 

Automatic Wire Routing

I can add a manual bend and try to pixel align things myself then clean up mistakes after, but why can't it work right the first time!

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

If we type up a list in a text label we can now (since LabVIEW 2023) right-click on it, select quick change and convert it to a number of different objects (array, enum, boolean etc)...Once you have done however, right-clicking on the result does not offer the quick change option anymore.

 

It would be nice and feel more consistent if the same option was available when right-clicking on the supported objects as well; allowing us to convert those to any of the other options and/or even back to the original list (which would allow you to then edit that list efficiently and then reconvert it). Basically an label/object to object/label quick change, instead of just label to object.

PS. I know there are various quick drop plugins that do parts of this, but this would extend the now in-built function to cover those and more scenarios...

Many times data is generated or transformed using a function or vi with a single output. In those cases the wire name is the one given by the function or VI terminal, but it would far more descriptive if the wire could have a proper name according to is usage in the block diagram. You can attach labels to wires but these are not propagated particularly when used in places like "bundle" or in structures (for, while, etc.). In large diagrams thus it can be difficult sometimes to now what a wire is for.

 

This idea proposes to enable the override of the default name of the wire connected to output terminal to that of the label of the function, in case the label is not empty, for single output function or VI. In a similar fashion to the propagation of labels of constants. This could be automatic (not empty label) or deliberate (for instance, using a tick box in the properties page)

 

This is different from idea Allow-Wire-Labels-to-Dictate-Name-Inheritance-in-Bundles in that it follows the current LabView behavior of the wire name being dependent on labels on constants, and avoids possible conflicts.

 

LabView_idea.png

Sometimes, it would be useful to view string constants as icons to save space on the block diagram.

 

1_String Constant Right Click.png

 

2_String Constant Details.png

 

As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.

 

We need a palette full of "Amish" 😉 controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.

 

A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.

 

They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.

 

Now, why would that be useful?

 

Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.

 

Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.

 

The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)

 

So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.

 

As a welcome side effect, redrawing such a FP is relatively cheap.

 

Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM

There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:

 

WhatToDoTonight.png

 

 For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:

 

 

No_Error.png

 

 

We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.

 

I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.

 

 

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

 

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

 

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

 

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

 

Error wires can be passed into most boolean logic in LabVIEW.

 

Except...they can't be passed directly in as the condition for conditional tunnels:

_carl_0-1729004322300.png

For consistency, this should be allowed.

 

Hi all,

 

What I'm asking for is an optional indication of reentrancy in the context help window.

 

contextHelpReentrancyIndicator.png

 

 

This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.

 

 

I realize that Greg Freeman suggested something similar.  My intent here is to narrow down several ideas from that conversation down to a single suggestion.


(I hope I still didn't manage to post a duplicate. Apologies if I did.)

 

Thanks,

 

Jim

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

 

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

instance-vi-1.png

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

 

instance-vi-2.png

 

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

 

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

 

instance-vi-3.png

Not so much an idea, as a wish/plead/rant:

 

Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.

 

2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right!  Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).

 

 

I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:

 

Graphs and charts

1. You cannot stack plots in any of the graph indicators, only in charts
2. Number of plots stacked cannot be varied at run-time
3. Annotation properties are only partially available programmatically
4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way
5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample...
6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues
7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible
visibility.

8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming

9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...

 

Mixed signal
1. You cannot set the group names programmatically
2. The number of plot areas is not configurable at run-time
3. You cannot assign plots to a given group programmatically
4. You cannot show the visibility checkbox of each plot etc.

 

And then you have the additional 2000 ideas...;-)

 

As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.

Would that not make everyone's day?

 

 

At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.

 

Of course I could use CTRL+G, but I'd still need to clean up the opened windows.

 

Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.


It would save me tons of time if the search results window had a preview of the result:

Search Results Preview.png

The found item should be in the center, preferably highlighted in some way.

 

It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!


Some additional thoughts:

 

Spoiler

 I'd be OK with an image, it doesn't need to be like the DD preview in LV2020. I'd prefer to see an image even if the diagram is already opened...

 

Scrollbars might be nice?

 

The proposed image is just a quick sketch. It would need a splitter bar, and perhaps the preview should be optional?

 

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.

 

Centered.png

 

I think that changing the justification from center to left does improve readability.

 

Left Aligned.png

 

Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

You can currently pin LabVIEW projects, VIs, and other files to the file lists in the LabVIEW start dialog as shown in the pictures below:

 

Ryan_Wright__2-1712932470451.png

Ryan_Wright__3-1712932507143.png

Ryan_Wright__4-1712932555995.png

 

It would be really nice if the Recent Projects and Recent Files menus in front panels and block diagrams automatically included the same files at the top of the menu item lists (and in the same order) as illustrated in the pictures below:

 

Ryan_Wright__5-1712933140673.png

Ryan_Wright__7-1712933697562.png

I wish there was a boolean text specifier for Format into String functions.

 

% followed by "?" would expect two possible strings like this. Why not?

 

boolean.png

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL).  Yet this is when LabVIEW decides that nope, it can't be that easy:

 

_carl_1-1709776637528.png

 

Instead you have to track down every instance and manually swap them out.

 

The request: allow us to replace missing files using the "Replace with..." option.

 

There are several great ideas on this Idea Exchange that were marked as Completed because they were implemented in NXG.

Although arguments could probably have previously been made that this wasn't really "complete" for most requestors, it was reasonable given the idea that NXG would replace LabVIEW 202x.

 

Given the updated fate of NXG, can these posts all be reevaluated and marked as either New or In Development, as appropriate?

If the evaluation is too effort-intensive, can they all be marked as New again?

Let's Encrypt is an Certificate Authority (CA) that provides FREE TLS certificates for people and organisations to secure their websites and servers. Their certificates are valid for a maximum of 3 months, but client applications can automatically update the certificate when due.

It would be very nice to have this functionality in the NI web server. Exipiring certificates are cumbersome to manage.