There is a construct I am quite fond of in pointer-friendly languages, using iterator math to implement circular buffers of arbitrary data types. They are a little bit slower to use than straight arrays, but they provide a nice syntax for fixed sized buffers and are helpful in cases where you will be prepending and appending elements.
I am pretty certain that queues are implemented as circular buffers under the hood, so much of the infrastructure is already in place, this is mostly adding a new API. Added bonus: the explicit circular buffer can be synchronous, unlike the queue, so for example you can put them in subroutine VIs.
It should be easy to convert 1D arrays to/from circular buffers. Array->CB is basically free, the elements are in order in memory. CB->Array requires two block copies (most of the time). This can be strategically mananged, much like Reverse or Transpose operations.
You can implement most of the following two ideas naturally:
Circular buffers would auto-index and cycle the elements and not participate in setting 'N'.
You can do 95+% of what I wanted to do with negative indexing:
A lot of the classic divide and conquer algorithms become tractable in LV. You can already use queues to implement your own stack and outperform native recursion. A CB implementation of the stack would be amenable to subroutine priority and give a nice performance kick. I have done it by hand for a few datatypes and the beauty and simplicity of the recursive solution gets buried in the implementation of the stack. A drop-in node or two would give you a cleaner look and high-octane performance.
Finally, perhaps the most practical reason yet: simple XY Charts.
As for appearance I'd suggest a modified wire like the matrix data type. Most if not all Array primitives should probably accept the CB. A few new nodes are needed to get/set buffer size and number of elements and to do the conversions to/from 1D arrays. The control/indicator could have some superpowers: set the first element, wraparound scrolling (the first element should be highlighted).
When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step). Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.
What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary. Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.
Auto-indexing of arrays in for and while loops are a nice luxury in LabView. One option that could save much time would be a menu option to turn on conditional indexing, this would expose a boolean terminal under the auto-index icon to select if the current itteration should add the itteration to the array or skip it. From an execution standpoint there would only be a minor performance hit (could still preallocate max array size on for loops and automatically return used subset). This could also work for autoindexed in but would have less use that the autoindeded out case. I know I have built many conditional arrays inside of a for loop and it requires a case selection and a build array making the code less readable and requires time and thought. It can also be less efficient than a compiler can do.
See the example below which would run a for loop and only build array of < 0.1
I've encountered a programming situation where I may need to call 'Match Regular Expression' where the regex is selected at runtime, and where that regex may potentially have a variable number of submatches to return. Unfortunately, right now, the submatch count is a compile-time decision based on how far out I grow the node. I can grow the node to some maximum number of submatches ever expected, and thankfully the node doesn't throw a runtime error if there are fewer, or greater, submatch expressions in the regex. I'm building the individual returns into a string array for further processing, but it would be much more versatile if the node could return the submatches with a properly-sized string array.
The BeagleBoard xM is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).
The BeagleBoard xM is $149 and is open hardware. The BeagleBoard xM uses an ARM Cortex A8 running at 1,000 MHz resulting in 2,000 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 33 times the processing power!
Wouldn’t it be great to programme the BeagleBoard xM in LabVIEW?
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.
After 2011 we have the option to ignore all the missing vi's which are missing. But after loading the project if a vi is loaded and if it has a missing vi then there is no way to check from where it has to be loaded (Expected path of the missing vi). So it would be a good option to check the Expected path of the missing vi after loading its caller (May be in the properties of the missing vi).
I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)
The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").
It is time to put a dent in the floating point "problems" encountered by many in LV. Due to the (not so?) well-known limitations of floating point representations, comparisons can often lead to surprising results. I propose a new configuration for the comparison functions when floats are involved, call it "Compare Floats" or otherwise. When selected, I suggest that Equals? becomes "Almost Equal?" and the icon changes to the approximately equal sign. EqualToZero could be AlmostEqualToZero, again with appropriate icon changes. GreaterThanorAlmostEqual, etc.
I do not think these need to be new functions on the palette, just a configuration option (Comparison Mode). They should expose a couple of terminals for options so we can control what close means (# of sig figs, # digits, absolute difference, etc.) with reasonable defaults so most cases we do not have to worry about it. We get all of the ease and polymorphism that comes with the built-in functions.
There are many ways to do this, I won't be so bold as to specify which way to go. I am confident that any reasonable method would be a vast improvement over the current method which is hope that you are never bitten by Equals?.
Right now we can make a conditional disable structure that behaves one way if we the VI is running in the Run-Time engine or not. What I think would be useful is if we could also decide on performing one case or another based on the version of the Run-Time/Development of LabVIEW.
Say I develop some neat little reuse VI that relies on getting the name of the label of data type passed in. OpenG has a functional already that does this called Get Data Name. NI has a version as well in vi.lib called GetTypeInfo.vi. The problem is in 2011 the OpenG method is about 10 times faster, but in the 2013 version the NI version is 10 times faster.
Wouldn't it be nice if a conditional disable structure could choose to do one thing over another, based on the version of LabVIEW it was being run in? This way reuse code could be written to perform best in what ever version it was running in.
There are many situations were one code written using some function either runs slower or faster in different versions of LabVIEW and using this we could choose the best option for that environment.
Of course there is a work around and that is to read the App.VersionYear property, put that into a case statement and perform different code for one version or another but this has added over head, and is called every time it is needed.
EDIT: Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.
I want to start discussion about how to enhance Loop Conditional Terminals in LabVIEW. Generally my idea is to have an easy way how to monitor Conditional Terminal of user-defined "primary" loop. Under the hood there can be for instance notification triggered from the "primary" loop and one or more "slave" loop(s) equipped with "Wait for notification" (with timeout = 0) with predefined logical operation on the terminal input.
So this allows you to have one STOP source loop and one or more listeners.
Anyone wants to expand this idea?
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:
Instead I propose the Loop Structure which when initially drawn looks like this:
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 . 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):
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:
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":
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:
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:
The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:
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:
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):
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?:
So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all?
"If the key does not exist, the VI returns the default value. "
What happens if the key is empty isn't described in the help, and in fact it results in "Error 19 - Read key.vi" or Error 1 - GPIB (sic) in the boolean case. Not a very helpful error message as it doesn't mention which section and key was faulty nor the call chain so it can be easily found.
If the key is empty, return default. Alternativly add an input "Return error on empty" to make it optional.
Include section and key in error message
Include call chain (now that's a general improvement needed in many VIs)
How to reproduce?
Read an empty parameter from an ini-file as double, int or boolean.
I think the Array Element Gap should be sizable. This would facilitate lining up FP arrays with other items on the FP, or simply as a mechanism to add more apparent delineation between elements.
The size should be set in the Properties box, not by dragging the element gap with the mouse - that would add too much "cursor noise".
A new Property Node for this feature would complete Idea.
Format into text is very useful but can become hard to edit when it has a lot of inputs. I propose, instead of one huge format string, that the programmer be allowed to put the required format next to the corresponding input. Also, the user should be allowed to enter constant strings, e.g.. \n, \t, or "Comment", and have the corresponding input field automatically grayed out.
Diagram cleanup has become my friend lately. It doesn't do a great job but it is adequate to make th code readable and moving each terminal to remove as many kinks as possible just gets too time consuming.
However, I do a diagram clenup, look at the results and then go around option-clicking to swap terminals on symmetric inputs and then cleanup again. The diagram cleanup code should consider this option and optimize the terminal inputs.
By symmetric terminals I mean the whole host of primitives where the input order does not matter, addition, multiplication, Max/Min, Equals?, Not Equal?. This would remove a whole bunch of wire crossings that are very annoying and make code hard to read. Even "Bundle by name" would be amenable to this cleanup optimization.
If you really want a challenge, this could also be applied to the Compound arithmetic node but the "negate this input" would move as the input is reassigned.
(If this has been impelemented post LV 12, "never mind" as Emily Litella used to say)