LabVIEW Idea Exchange

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

(This is an idea related to Jack's idea here, which however deals with "reshape array".)

 

When using "built array" with parts that are mismatched in lenght, the largest input wins and the rest are padded with the default value for the given datatype (zero for numerics). This is often not desirable, for example when graphing multiple plots.

 

Padding with zero causes extra data (zeroes) to show on the graph that did not exist in the original wires. A more desirable option here would be to pad with NaN so only actual data is graphed.

 

My suggestion is to add an optional input to "built array" that allows defining the pad value is case the inputs are mismatched.

 

Here is an example how it could look like. (of course the icon would probably need to change a little)

 

 

 

This has been discussed in various places like here, but I couldn't find an idea for it...

 

 

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File". 

 

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

 

runonerror2.png 

 

Currently the only indication that a VI will run on error is this discrete line in the VI help:

 

runonerror.png

 

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

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.

When entering debug mode (turn execution highlight on) it can be hard to see what is happening.

 

With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...

Parallel Loops.png

 

SubVI's get a green arrow when they are executing. So, could structures get them as well?

 

Parallel Loops proposal.png

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

 

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

 

DataForcing.png

 

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

 

ForcingImplementation.png

 

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

 

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

What if I had this:

 

idea1_1.PNG

Then I wanted to insert something with similar terminals:

 

idea1_2.PNG

 

I'd end up with this:

 

idea1_3.PNG

 

But the Error terminals aren't wired! So maybe I should be able to select both wires:

 

idea1_4.png

 

Then Right Click » Insert Write Node:

 

idea1_6.PNG

 

Then I'd have this:

 

idea1_5.PNG

 

How easy would that be!?

 

 

 

 

 

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

 

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

 

21826iFF181EE2E7ECE408

 

This would remove one step required for most use cases, speeding up my development experience.

NXG had a neat feature I miss in LabVIEW 20xx and that is resizable nodes for operations like OR, AND, and Add.  There are other nodes that could benefit from this too like subtract and multiply, but here is the idea.

 

Resize Nodes.png

 

I'm aware that the Compound Arithmetic is a resizable node that covers the examples I have here.  But often times I will start with just two inputs so I'll use the OR, then later on I'll need to add a node and now I need to replace it with the Compound Arithmetic and then add the other inputs.  If the suggestion is to just use Compound Arithmetic, then why even have an OR node?

Sometimes it is hard to open the FP and block diagram of the cloned/reentrant running VIs in middle of a debug to probe the wire value in a big size application.

 

How about adding this option?

 

Screenshot 2021-06-28 165725.png

 

Thank You

Adarsh

CLA from 2014

There should be an easy way to replace a control/indicator/constants of a certain type to an array of that same type, and vice-versa.

 

changetoarray.jpg

Message Edited by David_L on 12-04-2009 02:06 PM

 

tl;dr  There's a summary at the bottom if this is too long for you.

 

 

Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.

What I don't like about QD, however, is the keyboard shortcuts. These allow you to perform custom actions in LV and the concept itself is great, but the implementation QD uses has some issues which other similar tools like the right-click framework and LabVIEW Speak don't have, such as the items in the following list.

The problems:

  • It requires you to remember keyboard combos to call the plugins. That's great as a secondary access mechanism, but is terrible as a main one for a few reasons:
    1. It is not discoverable.
    2. It requires you to remember key combos.
    3. It doesn't work if you want a longer list of macros which perform all kinds of useful operations, because you run out of available shortcuts.
    4. Likewise, you have shortcut collisions, because people want to use the same shortcut for different plugins, so you might say "Ctrl+T", and it will mean something else to the person you're talking to.
  • Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having a clear representation in the user interface.


So, what can we do about it?

I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:

QD0.png


There are a few things to point out in this image:

  • The actions appear in the list using their full names and they have a glyph to set them apart from the other items.
  • The actions may (or may not) have a shortcut.
  • The actions may (or may not) have a keyboard shortcut (and there's no reason in principle why regular items can't have them too). This solves the existing problem of the shortcut limit - you only assign shortcuts to actions you access regularly, just like you can already do today with menu items.
  • There's a ring on the bottom which shows just the items, just the actions, or both. Ideally, the value of this ring would also be settable by other means (e.g. open QD using Ctrl+Shift+Space and the list only shows the actions or open QD when you have a selection and the list only shows the actions).

 

 

OK, so that's step one and it solves the first issue - the actions are discoverable, accessible and not limited in number.

 

Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:

QD2.png


This area shows the details of the currently selected action and allows selecting options for it.

Here's what we see in this example:

 

  • A title.
  • A description.
  • An image.
  • In the settings area, I gave the "Build array of references" action an option - you can choose to align the Build Array node to the center, the top or the bottom of the references.

 

The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.

 

 


Of course, once we have this panel, the next logical step is to also have it show the help for standard items, similar to this idea:

QD3.png



 

 


So, to sum up:

  1. Custom actions should be in the list of Quick Drop items.
  2. Shortcuts for actions and items should be fully customizable. That means that you can still use keyboard shortcuts to call the actions, just like today.
  3. There should be a panel which allows customizing options for actions and show the help for regular items.

 

I would like to be able to see that a constant is linked to a typedef without clicking it, especially enums.

This could be a light border around the constant, marching ants, or a flag of some type such as the example I have posted. You can quickly tell that the top enum is not linked to a typedef, whereas the bottom one has the little "td" flag.

 

 

 

typeDef_notification.gif 
  

Clusters are powerful and necessary, but they can easily clutter up otherwise immaculate code.  Why not have a "View As Icon" option (a la Express VIs) for cluster constants?

 

3.png

 

Right-click menu change...

 

2.png

 

 

There have been similar suggestions, but I think we need a clean, simple solution.

It has come up here in a different discussion, but I think it should be a separate idea, so here it is!

 

If we disable part of the code using the diagram disable structure, the disabled code gets lighter in color. The new compiler is good at eliminating dead code (i.e. things that don't need to be computed because there is no output), so it could be useful if these code parts are also bleached in a similar way to indicate that fact.

 

Here's how it could look like.

 

I would even suggest this to be enabled by default. Of course there also needs to be an option to turn it off....

 

(I was about to write up this idea, but then, searching for "dead code", I found comment by SynchronizationOverhead. So the original credit goes there, of course ;))

The VI documentation window could use some improvement and several additions could be made to make editing the text a lot easier.

 

6-4-2010 2-31-40 PM.png

 

Improving adding control and indicator name.

 

Typically the text in the documentation window does refer to the control and indicator connected to the connetor pane.

It would be very convenient to have this information already in that window so we don't have look it up when needed. Additionally, the control and indicators are typically bolded in the resulting text using the <b></b> tag. It would be convenient if this would be done automatically for us.

In the propose idea (see image below) the VI icon with the controls and indicators is shown and the controls and indicators when clicked do insert their name into the VI description. 

 

Note: The control name may be made to look like an hyperlink to indicate that there are click able.

 

For example, in the image below, clicking the "Items to filter" will insert the "<b>Items to filter</b> tagged text in the VI description.

 

6-4-2010 2-16-46 PM.png

 

Improve general text editing

 

While fancy text editing is limited in the VI description, adding a toolbar to improve text formatting would be useful.

 

6-4-2010 2-31-40 PM.png

 

 

Hello, this is my first post in this forum and I don't found ideas about this topic. I hope you like it.

 

Well, time ago I started to work with LabVIEW, It's powerful, but there are some kind of issues that I want to explain here. Now I'm get involved in a big project for a very big aerospace company, and I'm developing a complex application to acquire some data and process it. Well, this software is in development by some people and I have an idea for the work flow.

 

I explain it with an example:

If we have in every VI a little data base with some notes ordered by type or something we can read the code or we can start to work in a VI faster. Imagine that you have an event structure with several cases, and you put some notes like you can see in the following image:

 

Captura.JPG

 

Now, I'm able to revise quickly the code reading all the notes and start working only in the "TO DO" zone. But let's do a more complex design: Now I open my project explorer, and open the "Note manager" that could be like this.

 

Captura2.JPG

 

 

Here it is the real advantage of this tool: All the design are done and now I want to improve the application. Lets go only to the notes that interest to me: "TO DO" notes. If I double click on an element LabVIEW opens for me the VI centered in the zone that is interesting for me. And some more: I can check the work I've done and I can add new notes only with a click.

 

The more complex the project is, the more useful is this system. So, what do you think?

As it is now, when we select a structure, we can delete it, but everything in it will be gone as well.

 

If we right click, we can select Remove <structure>, and that will remove the structure, but keep everything in the active frame.

 

This idea is quite simple: make Shift+Delete do a Remove <structure>:

 

Shift Delete To Remove Structure.PNG

 

 

As a bonus, CTRL+Delete could execute a Remove and Rewire:

 

CTRL Delete To Remove and Rewire.PNG

It would be nice if the Strip Path function had a recursive option rather than having to string Strip Paths together or use an external loop.

 

 eg change from this:

strip_path.png

 

 

to this:

 

recursive_strip.png

 

 

regards

Ray

Download All

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.

 

Andi_S_1-1594012798289.png

 

As reference: This is the content of Class 1

Andi_S_2-1594012849411.png

 

 

What I suggest and expect is the following:

Andi_S_3-1594013798865.png

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

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

 

 

Hi,

 

Currently to replace something (for instance a node on the block diagram) you have to right-click and then select Replace... and then usually a lengthy navigation into the function palette or onto the disk with the OS file explorer.

 

Most often I already have a LabVIEW-project open, one or more explorer windows (opened at a useful context), and maybe also one or a couple of pinned sub-palettes - but I am not allowed to replace anything from these locations. I suggest that this will actually be allowed; that is: drag something onto the block diagram, and if you're enough on top of another object, then a replace-outline appears for you to drop your new object into. Here's an illustration for replacing something in the block diagram, but the same could apply to the front panel as well:

 

Replace.png

 

All the usual stuff should happen when you replace this way, as if you replaced through the context menu. For instance a prompt to save a VI that leaves memory, automatic update of a project's dependencies etc. Many ideas are submitted to this Idea Exchange to enhance the Replace context menu in different ways, but a feature as I'm suggesting here would improve my own workflow the most, simply because I already have much quicker access to my "replacer", through existing explorer windows, than going through the Replace context menu no matter how intelligently it gets populated.

 

Cheers,

Steen