LabVIEW Idea Exchange

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

The LabVIEW Task Manager is an outstanding tool for debugging LabVIEW Applications. It should be included in LabVIEW in my opinion.

 

a345fe65cbe713b29f505a851e0fe597.PNG

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed. 

 

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

 

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂 

 

I16 is currently the only output representation of this function, and it is particularly unhandy - I typically end up typecasting it 90% of the time. I propose the output representation of this primitive can be changed via Right-Click Menu.

 

BoolOutputRepresentation.png

After applying my own subjective intellisense (see also ;)), I noticed that "replace array subset" is almost invariably followed by a calculation of the "index past replacement". Most of the time this index is kept in a shift register for efficient in-place algorithm implementations (see example at the bottom of the picture copied from here).

 

I suggest new additional output terminals for "replace array subset". The new output should be aligned with the corresponding index input and outputs the "index past replacement" value. This would eliminate the need for external calculation of this typically needed value and would also eliminate the need for "wire tunneling" as in the example in the bottom right. (sure we can wire around as in the top right examples, but this is one of the cases where I always hide the wire to keep things aligned with the shift register).

 

If course the idea needs to be extended for multidimensional arrays. I am sure if can be all made consistent and intuitive. There should be no performance impact, because the compiler can remove the extra code if the new output is not wired.

 

Several String functions have an "offset past ..." output (e.g. "search and replace string", "match pattern", etc.) and I suggest to re-use the same glyph on the icon.

 

Here is how it could look like (left) after implementing the idea. equivalent legacy code is shown on the right.

 

 

 

Idea Summary: "Replace array subset" should have new outputs, one for each index input, that provides the "index past replacement" position.

 

 

 

 

I have a large base of compiled executables. One computer is encountering a "not enough memory to complete this operation" error. I'd like to drop a debug version of the executable on their computer and see if I can monitor which VI is using all the memory similar to DETT's remote monitor abilities.

 

New profile tool2.png

This is a follow through for Zekasa's Idea posted here. It was suggested that the function be a separate one, which I agree. I would like to see this in LabVIEW's basic package, without adding things onto the install, or coding it.

 

Search 1D Array Until Done.png

 

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

 

AnnoyingVI.png

 

 

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

 

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

 

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

 

I think LV should break any VI which has any of the following:

 

  • Objects beyond the visible boundaries of structures (including wires and constants).
  • Objects behind other objects (possibly not including wires).
  • Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
  • Anything else?

Hello (again),

 

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

 

CrossedOutLoops.png

 

Instead I propose the Loop Structure which when initially drawn looks like this:

 

NewLoop_Infinite.png

 

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient Smiley Happy. One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

 

NewLoop_While.png

 

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

 

NewLoop_Unknown.png

 

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

 

NewLoop_42.png

 

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

 

NewLoop_50.png

 

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

 

NewLoop_42_Conditional.png

 

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

 

NewLoop_MultipleArrays.png

 

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

 

NewLoop_Timed.png

 

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

 

NewLoop_Events.png

 

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

 

NewLoop_PriorityStructure.png

 

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all? Smiley Very Happy

 

Cheers,

Steen

We I love the idea of the new cluster constants. I have found thought if I need to edit these constants to change something It opens the control back to full size. This really defeats the purpose of these space saving features. We need to be able to double click these constants and have them open in a new window so that my block diagram size does not change

 

20861i667C4C24B992C741

 

If my diagram gets this big if I need to change a true or false state every time I need to change it what good is the nice new icon or constant.

 

Just a thought.

Support the loading and use of dotnet core libraries.  They are cross platform and could provide functionality for both Windows, Linux and Mac users and there is so much code that we could begin to bring into the ecosystem.  

Good programming practice says to handle your errors.  If you want to clear a specfic error, you have to do some variation on the following code:

 

ClearSingleError.png

 

Since this can be pretty cumbersome in your code, I would love to have a Clear Specific error VI/function that will do exactly this.  It can also be polymorphic and accept an array of multiple errors.  To make it even better, you could probably merge it with the existing clear error VI and set it up where if the error input is empty, it clears all errors.

 

CaptainKirby made a nice community example that does all this, but I'd like it to be on the palette for everyone to use...

https://forums.ni.com/t5/Example-Code/Clearing-a-Specific-Error-From-The-Error-Cluster/ta-p/3517242

 

For the "VI Documentation" test, it would be great to have an option to skip controls (.ctl). We never add VI Documentation to typedefs or other controls. 

 

vi-documentation-skip-ctls.png

 

(cross-posted to VI Analyzer Enthusiasts)

It is common, in writing reusable code, to handle arbitrary clusters in variants.  To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items.  After access, one needs to convert the array of variants back into the original cluster.

 

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository.  They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow.   Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

 

The other direction, Cluster to Array of Variants, works like this:

Array of Variants to Cluster.png

But trying to reverse the process breaks:

Array of Variants to Cluster.png

 

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also.  The matching of array to cluster elements can be by cluster order rather than element name.

 

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

 

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

 

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

 

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

 

21-4-2013 22-55-19.png

What happens when you want to change a Border Node on an IPE? It is a manual process which I propose can be automated as shown in the two examples I have provided...

 

InPlaceReplace.jpg


 

 

 

 

Swap Long.jpg

(hope this hasn't been posted before, couldn't find it)

 

Since we now have 64 bit numbers, can we please have a Swap Long function?

 

This is a real hassle to do yourself (convert to byte array, rotate array, convert back? or flatten to string, flatten back with different byte order?). If you have large arrays of "quads", it is a real performance hit without the function.

 

Regards,

 

Wiebe.

Situation:

You want to show a coworker or customer something "real quick" in the LabVIEW.  So you open a new VI, open the block diagram, and open the quick drop accidentally because you thought the palettes were already loaded.  

 

DANGIT you forgot that you haven't accessed the palettes since you started LabVIEW.  Now you have to resort to awkward conversation defending LabVIEW about how awesome it is, even though it can sometimes be slow, etc, etc.  If you decide to skip the awkward conversation and instead try clicking out of the window you see this awful image:

 

notresponding1.png

 

Oh No! Did LabVIEW crash?  Is it broken?  How long will this take?

 

Solution:

Cancel button on the windows in question that allows you to stop loading the palettes (or switch it to loading in the background) so that you can go back to work and find your function the old fashion way.  Save you time.  Save you annoyance.  Save LabVIEW some street cred.

 

cancel quick drop load.png

 

The world is a happier place...

 

Trim Whitespace currently accepts strings (scalars).

 

I propose that Trim Whitespace be made polymorphic so that it also handles an array of strings (basically just wrap the scalar impelementation in a For Loop).

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

 

ScreenHunter_002.jpg

 

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

 

ScreenHunter_003.jpg

 

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

 

ScreenHunter_004.jpg

 

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

 

ScreenHunter_005.jpg

 

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

 

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

 

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

 

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

 

 

Much like the ever-popular With with Errors, "Get Date/Time in Seconds" would be great with error clusters for inputs/outputs.  This would help with coordinating timing (start/stop and duration).

 

Here would be an example of what the underlying code is that I currently use:

 

GetDateTimeInSecondsWithErrors.png

 

Pretty simple...  and an example of what the use could look like:

 

GetDateTimeInSecondsWithErrors_Icon.png

 

And a duration example:

 

GetDateTimeInSecondsWithErrors_Example.png