LabVIEW Idea Exchange

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

                

                  A picture's worth a thousand words

 

 

aaaa.png

 

 

                                                     but,

 

 

bbbb.png

 

 

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.

 

Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.

 

The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library. 

 

I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).

 

C++ and C# default everything to private unless you declare public; I think that's true in most text languages.

 

But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.

 

In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.

 

* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.

Have you ever accidentally opened LabVIEW?  I have multiple versions of LabVIEW installed and pinned to my taskbar.  I often open the wrong version since the version number is not included in the icon (see this awesome idea).  It would be really nice to be able to cancel the load rather than having to wait until the program fully launches to close it.

 

Microsoft Office products give you the option of canceling the load from the splash screen:

Excel_Cancel.PNG

 

How about seeing something similar in LabVIEW?

LabVIEW_Cancel.PNG

 

- Becky

OpenOffice last version was released 5 years ago. One of the best suites that continued the work is LibreOffice, developed by The Document Foundation. NI has a add-in for OpenOffice, but not yet for LibreOffice.

 

Please update the Integrating TDMS in Third-Party Products page adding support for LibreOffice, Apache OpenOffice, Calligra Suite, NeoOffice, etc.

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

This is an extension of Darin's excellent idea and touches on my earlier comment there.

 

I suggest that it should be allowed to mix booleans with numeric operations, in which case the boolean would be "coerced" (for lack of a better word) to 0,1, where FALSE=0 and TRUE=1. This would dramatically simplify certain code fragments without loss in clarity. For example to count the number of TRUEs on a boolean array, we could simply use an "add array elements".

 

(A possible extension would be to also allow mixing of error wires and numerics in the same way, in which case the error would coerce to 0,1 (0=No Error, 1=Error))

 

Here's how it could look like (left). Equivalent legacy code is shown on the right. Counting the number of TRUEs in a boolean array is an often needed function and this idea would eliminate two primitives. This is only a very small sampling of the possible applications.

 

 

Idea Summary: When a boolean (or possibly error wire) is wired to a function that accepts numerics, it should be automatically coerced to 0 or 1 of the dominant datatype connected to the other inputs. If there is no other input, e.g. in the case of "add array elements", it should be coreced to I32.

Hi,

 

when I have to rework a vi, i usually start by putting the existing code in a disable structure

and then start working in the disabled 'case'.

 

Quite often I end up trying to replace the disable structure with a case structure to test the new or reworked vi.

 

Now I have to copy everyting into a temporary vi, remove the disable structure, put a case structure in place, paste again and rewire iputs and outputs.

 

Please add the ability to replace the disable structure with a case structure.

When indexing a map on a for loop, the indexing is automatically done by ascending order on the key value.

I like this as a default behavior.

 

Capture d’écran 2020-10-06 103344.png

I'd like to have a context menu option to force the for loop indexation to be done in reverse order.

We have many windows to manage, and often it's just 1 parts that's really interesting, the block diagram.

 

It'd be half as many windows (and cool) if the window "Flipped over" when you change from front panel to diagram! Think of it as a circuit board or something.

backend-vs-front-end-2.jpg

I would love it if LabVIEW had logical constants, similar to what other languages have. Basically, a logical constant is similar to a variable (i.e. it's a value which is assigned a name), but its value is set at compile time. CONSTs help code readability.

 

In LabVIEW, a CONST would basically be similar to a global variable, with two differences:

 

1. It would be read only (so no race conditions, everyone can relax).

2. Changing the value on the front panel of the CONST VI will automatically require the user to save the VI, without needing to manually set the new value as the default.

 

Today, you can implement these in LabVIEW using all kinds of methods, but non of them is as convenient as this.

It would be really cool to have a custom probe that could be placed on any cluster/class wire to view the data in the cluster, but instead of being displayed as a standard view of the cluster, the labels of the items would be listed along with the data type and the current value (works for scalar or small arrays, not so well for large arrays/waveforms). The standard view of a cluster probe is shown below.

 

standard.png

 

I built a custom probe to do this but found that the data type of custom probes is strictly typed and therefore I have to convert my data to variant on the vi block diagram before adding the probe, which isn't great. I've attached the code for my custom probe, and a screenshot of it below.

 

custom.png

 

If variant custom probes could be used on any data type, this would work.

Hi.

 

I suggest an ellipsis be added to long enum or text ring values if they don't fit in the control. As it is today long values are line-breaked at last fitting hyphen (for instance):

 

EnumLongSelect.png --> EnumSnippedSelect.png

 

Instead I'd like as much text as possible to be displayed with an ellipsis at the end. The above example would then become:

 

EnumEllipsisSelect.png

 

Cheers,

Steen

When we use diff to compare old and new VIs, currently both the FP and BD open and the FP is on top. But frequently the FP hasn't changed at all -- the API can stay the same while making substantive changes internally. So in cases where there is no FP diff, please put the diagram window in front. That would make reviews of large quantity of small changes (like replacing a commonly used subVI with a new subVI) easier to quickly review. 

Timed Loops are only supported on Windows and RT, making it difficult to port applications that use it to Linux.

 

In talking to some NI R&D people, it should be possible to port the RT Linux shared library to desktop Linux. (Perhaps it wouldn't even need to be recompiled, since it's x86.) We also need support in the editor on Linux to allow us to drop the structure.

 

This seems like low-hanging fruit to at least try to implement.

 

I am happy that LabVIEW supports Python code with the Python Nodes. But it is difficult to debug errors. A console showing the output of the Python Scripts would be handy.

Enthought's Python Integration Toolkit had this function so I guess it shouldn't be a big thing to add?

 

This may have been proposed before but here goes anyway.  I don't usually watch the probe window over periods of a day or more.  I know that there may be some rare occasions that this might be beneficial, but it would be much more useful to see milliseconds in the Last Update column.  This would allow for quick but rough performance testing by placing a bunch of probes inline on an error string for instance.

 

Probe Window No Date

I use Splitter extensively to create resizable GUIs. However, if I create my resizable GUI and then my customer asks me to add parameters in a new pane on the left, I can't add to an existing GUI a splitter in the top of the hierarchy, i.e. a new vertical splitter that all the existing splitters will be on the right of the splitter and a new empty pane on the left. Any splitter I add will be added to the bottom of the existing hierarchy, and there is no way to change this. So to do this I basically need to rebuild the GUI again from scratch.

 

Another example, if this is my GUI:

scope.PNG

I can't add a status bar now, as any horizontal splitter I add will be inside an existing pane, and this can't be modified. However, if this idea were implemented, I could View splitter hierarchy and create a new horizontal splitter at the top of the hierarchy so that I would have my status bar without rewriting the whole thing.

 

 

Thanks,

Danielle

 

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • This idea would speed up development by enabling us to cycle through element selection without using the mouse.
  • When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
  • This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
  • I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png

If you build a PPL with a class and then probe the class wire, all you get is the name of the class, whereas probing a source class shows you its private data.

 

Currently the only way I'm aware of (hopefully I'm just ignorant on this matter) to see the private data is to create extra code to expose it in some form.  This also often requires the PPL in question to be rebuilt which can be a huge pain when trying to debug. If the PPL is built with debugging enabled, wouldn't it make sense to show the private data contents in probes?