LabVIEW Idea Exchange

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

Let's say you have a class you are developing and want to reuse it in multiple targets, particularly if you work with RT targets. You want to do most of your troubleshooting and development on the PC (assuming that the class has nothing hardware-specific) and when it works well you plan to do some final testing in the actual RT target.

 

So, you create your test project, with the PC target (with the class and the tester VI). Now you add the RT target and reuse all the VIs and the class. BAM! LabVIEW locks the class and you can't make any more changes until you delete one of the targets of your project. You can't even create two projects (one for the PC another for the RT), because the class will be locked.

 

NI has an "explanation" here http://digital.ni.com/public.nsf/allkb/219A8BB7FD8EF0D9862571840053A5E9 but I find it lame, because a similar situation described in the article happens when modifying typedefs (some VIs get temporarily "broken" until you Apply Changes in the typedef editor).

 

Please do not lock classes or at least have a button/command to unlock one of them.

For the reasons eloquently stated here:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Defer-Panel-Updates-quot-within-sequence-frame-so/idi-p/1288952

 

defering Panel updates is both useful and a bit tedious.  You have to fetch the Panel reference, and while you are doing your presumably time-consuming operation, the entire panel is stuck.  I suggest that Deferring Updates should be a property of an individual object and not just the entire panel.  Wrap your operation with a pair of property nodes to start and stop deferring and you are all set.

 

NewDeferPNExample.PNG

Currently on waveform graph, once a plot is named it cannot be deleted (it can be made blank, but it still shows in all pull downs).  For instance I plot 3 graphs, each having 16 plots.  I then refresh data and plot only on graph of 11 plots.  My new plot names show in the top of the pull downs, but all the previous plot names still show up as well (see attached screen shots).

Please expose a method to remove plot names (property to give array of existing names and property to remove name or all names).

 

In most software a tab character (/t) is "visually equivalent" to several space characters (see tab list below in notepad).

 

8-30-2011 2-34-58 PM.png

 

Unfortunately in LabVIEW, a tab character is visually equivalent (in normal display mode) to 1 space character. I am proposing that this should be change to be n space character.

 

8-30-2011 2-38-00 PM.png

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.

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.

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?

I frequently see people posting messages about issues they have using the application builder.  They report an error number and the text of the error description.

 

Here are some recent examples:

 

Error 1 while building in 8.2

Build Error, Error 6 occurred at AB_Source_VI.lvclass:

Get Error 6 about 50% of time when building Application

Build installer error code -12 while copying distribution

 

The error description always has a long path through numerous VI's that make up the application builder package pointing to where the error occurred.  But the description never seems to give any detail about what actually caused the error.  It is often too long of a file name, or too deep of a path that gave too long of a path/filename which the app. builder VI's could not handle.

 

It would be helpful to both the people who are having the issue, and to the people trying to help on the forums when they post their message asking for help, to have some information as to where to look.

 

Maybe that information is already available and I just don't know where to find it.  Fortunately for me, I don't think I've come across this problem.  One, I haven't need to build a whole lot of executables.  Two, I keep my project folders at the root level of my hard drive, so the initial part of the path is always short.  (e.g.  c:\ProjectFolder\......)  I know if you stored projects in a My Documents directory, the initial path is ridiculously long because of the way Windows locates My Documents on your hard drive  (e.g. C:\Documents and Settings\My UserName\My Documents\ProjectFolder in XP) so you've already wasted 40-50 characters even before you give the directory name for you project folder.

 

My request:  Let's show some meaningful information in the error dialog box for Applicaiton Builder errors that can help people figure out how to fix it.

I was going to post an idea to make the Find Items With No Callers window resizable.

 

Doing a search for "resizable" returns a few ideas specific to a particular window such as the example finder. But any and all windows should be resizable. Is there any good reason that the user should not be able to resize them?

 

find items with no callers.PNG

SVG would be a great image format for icons. It would also be nice if you could use it for front panel designs or as background images. Exporting a VI as an SVG might also be a nice way of printing a VI or copying it into a presentation.

 

The advantage would be that it's scalable and an W3C standard.

 

(see also  http://forums.ni.com/ni/board/message?board.id=170&message.id=449853#M449853 )

                

                  A picture's worth a thousand words

 

 

aaaa.png

 

 

                                                     but,

 

 

bbbb.png

 

 

Dear LabVIEW Team,

I hope this message reaches you in high spirits and with a cup of tea in hand, because I am about to share a groundbreaking idea with you.

After years of fascinating work with LabVIEW, I would like to express my sincere admiration for the breathtaking number of windows that make your development environment so unique. While other programming environments like Visual Studio try to structure the development process in a boring way, you clearly rely on the "more is more" principle.

It is simply fascinating to see how each VI always has two independent windows. It makes me feel like I'm exploring a virtual windowscape - a journey into the unknown where each window is an adventure in itself. I can't remember the last time I had this much fun developing.

But why settle for just a few windows when we could take inefficiency to a whole new level? So I propose: Let's keep increasing the number of windows! Why not give every single structure in the code its own window? That would really be the pinnacle of chaos efficiency.

 

I imagine it like this: When I create a loop, a new window opens in which I can program the code for the loop. For each case of a case structure - another window. The possibilities are endless! An endless labyrinth of windows that turns my screen into a colorful kaleidoscope. That would be the pinnacle of innovation, wouldn't it?

I hope my ironic enthusiasm for the distinctive LabVIEW window concept has been well received. I am certainly available to discuss this idea further and am willing to contribute to the creation of an even more chaotic, but undoubtedly entertaining, development environment.

With sarcastic regards,

An enthusiastically chaotic LabVIEW developer

 


Sehr geehrtes LabVIEW-Team,

 

ich hoffe, diese Nachricht erreicht Sie in bester Laune und mit einer Tasse Tee in der Hand, denn ich stehe kurz davor, eine bahnbrechende Idee mit Ihnen zu teilen.

 

Nach Jahren der faszinierenden Arbeit mit LabVIEW, möchte ich Ihnen meine aufrichtige Bewunderung für die atemberaubende Anzahl von Fenstern aussprechen, die Ihre Entwicklungsumgebung so einzigartig machen. Während andere Programmierumgebungen wie Visual Studio auf langweilige Weise versuchen, den Entwicklungsprozess zu strukturieren, setzen Sie eindeutig auf das Prinzip "Mehr ist mehr".

 

Es ist einfach faszinierend zu sehen, wie jedes VI immer zwei unabhängige Fenster hat. Das gibt mir das Gefühl, als würde ich eine virtuelle Fensterlandschaft erkunden – eine Reise ins Ungewisse, wo jedes Fenster ein Abenteuer für sich ist. Ich kann mich nicht erinnern, wann ich das letzte Mal so viel Spaß beim Entwickeln hatte.

 

Aber warum sich mit nur ein paar Fenstern begnügen, wenn wir die Ineffizienz auf ein völlig neues Level heben könnten? Daher schlage ich vor: Lasst uns die Anzahl der Fenster weiter erhöhen! Warum nicht jeder einzelnen Struktur im Code sein eigenes Fenster zuweisen? Das wäre wirklich die Krönung der Chaos-Effizienz.

 

Ich stelle mir das so vor: Wenn ich eine Schleife erstelle, öffnet sich ein neues Fenster, in der ich den Code für die Schleife programmieren kann. Für jeden Case einer Case-Struktur – ein weiteres Fenster. Die Möglichkeiten sind endlos! Ein endloses Labyrinth von Fenstern, das meinen Bildschirm in ein kunterbuntes Kaleidoskop verwandelt. Das wäre doch der Gipfel der Innovation, oder?

 

Ich hoffe, meine ironische Begeisterung für das unverwechselbare LabVIEW-Fensterkonzept ist angekommen. Ich stehe Ihnen selbstverständlich zur Verfügung, um diese Idee weiter zu diskutieren und bin bereit, meinen Beitrag zur Erschaffung einer noch chaotischeren, aber zweifellos unterhaltsamen Entwicklungsumgebung zu leisten.

 

Mit sarkastischen Grüßen,

 

Ein begeistert chaotischer LabVIEW-Entwickler

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.

Software development has moved on since a similar idea was declined in 2016

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-vers...

I would like to suggest just LVCompare is made available in all versions of LabVIEW.

If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.

As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.

 

Unlike building a Packed Project Library, source distribution builds will succeed even if a contained VI is broken. For my use case this is undesirable - a broken VI being included in the source distribution is always user error, and I would like to be notified during the build process.

 

It would be helpful if the build specification for a source distribution could be configured to fail if an included VI was broken. By defaulting to false this could be added in a backwards-compatible way without breaking any existing build specifications or workflows.

 

RyanZoeller_0-1646668674035.png

 

I could write a post-build step that validates the VIs are not broken, but this wouldn't provide feedback until the build is complete. A native solution could abort the build early if VIs are broken.

The last decade has seen a fantastic development in using neuronal networks to analyze data. Neuronal networks allow doing nowadays feasts that were unimaginable a decade ago at a tremendous speed. The latest release of LabVIEW allows using old TensorFlow versions <= 1.14. About four years ago, TensorFlow switched to TensorFlow 2.0, which resulted in a significant transformation in how models are organized. Models developed in TensorFlow <2.0 are incompatible with current standards. If National Instruments aims to maintain its position in the market of computer vision, developing tools to use current TensorFlow versions is a MUST.

 

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

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.

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.

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?