LabVIEW Idea Exchange

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

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...

 

LabVIEW is awesome. But sometimes things don't go quite right, and when something isn't quite right somewhere (maybe a bad bit of binary) it would be great to be able to recompile your code. Mass Compile is great for upcompiling from older major versions, but will ignore VIs that are already compiled in the current version. What I'd like to see is a "Force Recompile" flag in Mass Compile to ensure all identified VIs are most definitely recompiled, especially useful when you call Mass Compile from the shortcut menu in Project view.

 

Yes, it could take some time, but less time than scripting it and you can use the time to make yourself a nice cup of hot British tea.

 

forcerecompile.png

Populating the Tree Control with items takes very long time.  I suggest improving the performance of a tree control.  Many other applications have tree controls that are populated in a small amount of time, so it should be possible with LabVIEW.

 

I know of three ways to populate a tree control.  The first is to individually add items using the Add Item invoke method.  This method takes a very long time.  Adding 15,000 entries took over 180 seconds.

 

The second way is to use the"Add Multiple Items to End" invoke method.  This took over 20 seconds for 15,000 entries.

 

The third way is to programatically respond to the user expanding an item in the tree and populating only as necessary.  I assume that this is fast, but it seems like a lot of work to do every time a tree control is used that could have a lot of items. Maybe LabVIEW could improve performance by using the third approach internally for the programmer. 

 

Currently I am hesitant to use a tree control because of performance.  LabVIEW is a great product, and making the tree control perform better would improve LabVIEW even more.

 

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

 

Currently, the configuration file object only has access to save a file when you close the object.  I'd like to be able to save the file at any point in time and keep the object open.

 

 

 

Currently there is no way to delete multiple elements in an array, that are not in sequence.

This way elements 2,4,7 would be deleted in just one function.

 

Delete from Array.png

 

It is cleaner code and in big arrays can enhange performance (at least i think)

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

 

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

Hi,

 

I suggest an option added to the Open VI Reference primitive to open that VI reference without any refees. I suggest option bit 10, i.e. option 0x200h:

 

OpenWithNoRefees.png

 

The demand for this arises when you want to access methods and properties of VIs that may be broken, while on the other hand you don't have any need to run those VIs - for instance in one of my current tools (BatchEditor) where I'm tasked with investigating hundreds of VIs simultaneously of which some could be broken or missing dependencies. Other situations would be tools for traversing project trees for instance. Opening a large number of healthy VI references takes a while, and when something is broken in a VI, opening even a single reference could take 30 seconds to minutes.

 

Currently you can suppress the "loading" and "searching" dialogs by setting option 0x20h on the Open VI Reference primitive, but that only loads the refnum silently as far as that will get you. Opening the refnum takes the same amount of time as if you could see those dialogs, and you are rewarded with an explorer window if a dependency search fails. I just want a way to open a VI refnum without even starting to look for dependencies, thus very quickly and guaranteed silently.

 

The relevant people would know that this request isn't that hard to implement, as it is kind of already possibly using some ninja tricks. I'd like such an option to be public.

 

Cheers,

Steen

Pop up on a subpanel control. There's an option for "Make Panel Transparent". When you enable that, the background of the panel is transparent and you can see controls/indicators underneath. The key word here is "see". You cannot click on those controls. The subpanel eats the mouse clicks. I talked about this with a couple people and could come up with no use case where you would want a transparent subpanel and not be able to click on the controls behind it. What I think the behavior should be is "if the mouse click hits a control in the subpanel, that control gets the click. If no control in the subpanel gets the click, the click falls through to the controls behind it, if any."

When searching for a single pattern we define the pattern as *.vi (for example). If we want to filter out say three patterns like (*.c, .h,*.txt). It doesnt work that way. In file dialog if we define these patterns seperated by semicolon it returns the desired result but in list folder we have to use a for loop for multiple pattern searches. Will it not be useful if we define (*c;*.h;*.txt) in the pattern and get only these files?

It seems there are a lot of NI services that start running directly after logging in to windows.  I even tried manually turning them off using msconfig thinking the services would start when LabView was loaded or on an 'as needed' basis, but I was wrong. 

The user should have the option of starting services at windows startup or at LabView startup, or even not at all if it is not required.  Perhaps this could be added to select the services within LabView's 'Options' menu.  An explanation of each service and why it is needed would be great also.  With all of the programs that run on our computers these days, the less running in the background, the better.

When building an application, the build will fail if any of the VIs are broken.  But, the build doesn't fail until very late in the build process.  It would be great if the build would fail right away if any VIs are broken.

 

Note: In one of our big applications, it sometimes takes 30 minutes into the build before the build fails.  However, it only takes a couple minutes to detect this by loading the VIs into memory and testing if they are broken.  So, as part of our one-click build, we implemented a pre-build test for broken VIs and abort the build -- this saves us a lot of time (in cases where the build is broken).

One of the quickest (and easiest to forget) methods to improve performance of your VI is to disable debugging.  It requires a trip down the VI properties to get there, however.  I propose adding a button on the BD alongside the other debugging buttons to Disable and Enable Debugging.  

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

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?

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.

 

 

As we look at the Comparison Palette, there are three functions that offer negative logic, but fail to offer the positive logic alternative:

 

NotLogic.png

 

I commonly find myself placing a Boolean "not" right after these functions (e.g., if I want to know if there are elements in an array I must test if it is "not not empty", or if I want to know if a ref is valid I must test if it is "not not valid". Take a look at my other idea which illustrates not not logic.).

 

I have two proposed solutions: 1. offer a single function that has an "Invert?" option on the output, or 2. offer both the positive and negative logic primitives on the palette.

Message Edited by Laura F. on 11-16-2009 08:51 AM

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

When you or two numeric numbers it does a bitwise or.  The same should happen when using Or Array Elements, but it is not supported for numeric arrays. I see no reason why it shouldn't work just the same?

 

test.PNG

When a cluster contains refs to different type of controls that have a common ancester, the "cluster top array" primitive should be able to handle it instead of having a broken wire.

 

Example_VI_BD.png

 

Indeed, if the lower snippet works, one can assume that it shouldn't be too hard to get the upper one to work as well when possible.