After fighting an increasingly slow IDE for a while I found the reason editing my libraries and classes was slow: Lengthy and large mutation history. I'd like to see an easy option to clear that history so I'm not burdened with the edit-time slowness when I don't have to be:
If I was smart with right-click-frameworky stuff I guess I could make it work myself, but for any so inclined:
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?
According to Wikipedia:
In some languages a class may be declared as uninheritable by adding certain class modifiers to the class declaration. Examples include the "final" keyword in Java or the "sealed" keyword in C#. Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration. Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code.
The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of superclasses (upcasting a reference type violates the type system). subtype polymorphism. Because the exact type of the object being referenced is known before execution, early binding (or "static dispatch") can be used instead of late binding (also called "dynamic dispatch" or "dynamic binding") which requires one or more virtual method table lookups depending on whether multiple inheritance or only single inheritance are supported in the programming language that is being used.
I have previously made appeals to allow for certain classes to restrict the ability to load new ancestors at run-time, thus restricting possibly allowing for inlining of dynamic dispatch VIs. A similar request has already been made in order to facilitate ilining of DD VIs. I believe that ultimately, it is support for a "Final" or "Sealed" class what I am looking for.
Such a modification on a class would effectively prohibit instantiation of any new version via factory method and would declare to the compiler that the code defined at compile-time is actually the full extent of code which will be available at run-time, thus allowing for the aforementioned optimisations to take place.
Questions would have to be answered regarding type propagation and some loopholes may remain regarding dynamic loading of new classes (only dynamic dispatch methods which are visible as instances of the "final" class can actually safely be inlined for example). Especially for a specific RT application of mine, this would be a great benefit as the natural progression of this idea is indeed the ability to write code such that dynamic dispatch VIs are actually inlineable.
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?
Often dealing with old code it's always a pain to install old versions of LabVIEW to get the code compiled the newest LV version.
For example, porting code made in LV 5.0 implies converting first to LV 7, then convert to LV 2009, and finally convert to LV 2013.
You then have to install these version, licences, ...
It would be nice to have a service on NI.com website from which we could send a zip archive containing the project to convert.
Then selecting the target LV version, a could service could unzip and compile the code across all versions of LV to have the code matching the requested version.
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
How about having a timeout occurrence as an input for functions which support timeouts?
I am illustrating a single use case with queues (and a notifier) but I would see this as being beneficial to nearly ALL functions with timeout inputs.
Sometimes we'd like to wait for one of a few different functions (an example of mine which springs to mind is the Dequeue primitive). At the moment we must essentially poll each primitive with a relatively short timeout, see if one responded and then handle accordingly. This is (for me at least) ugly to look at and introduces polling which I generally don't like. I'm an events man.
What I propose would be that instead of simply defining a timeout in milliseconds we can define both a timeout (in milliseconds AND an occurrence for the timeout). If we wire this data to several primitives (all sharing the same occurrence) the first primitive to receive data triggers the occurrence so that the others waiting in parallel return also.
In the case where no data arrives, each function waits the defined amount of time but upon timeout DOES NOT fire the occurrence. This would cover corner cases where you may want different parallel processes to have different timeouts (Yes there are cases although they may be rare). It is possible to change the "priorities" of the incoming queues in thie way.
Background info: One example where I could use this is for RT communication. Here we multiplex many different commands over TCP or UDP. On the API side it would be beneficial to be able to work with several strictly-typed queues to inject data into this communication pipe while still maintining maximum throughput. I don't like using variants or flattened strings to achieve this multiplexing.
Being forced to poll means the code must decide between efficiency (low CPU usage) OR response time (setting a very low timeout). Although the CPU load for polling may be low, it's not something I personally like implementing and I think it's generally to be avoided.
There IS a LVOOP solution to this particular problem but not everyone can use LVOOP in their projects (for various reasons). I can envisage other use cases where interrupting a timeout would be desireable (Event structure, wait on ms, VISA read and so on and so forth).
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.
We're witnessing more and more requests to stop LV hiding important information from us. In One direction we want to be able to know (and some want to break code) if structures are hiding code.
Others want LV primitives to give visual feedback as to how they are configured, especially if that configuration can have an effect on what's being executed or how it's executed.
Examples include (Please please feel free to add more in the comments below)
Array to cluster (Cluster size hidden)
Boolean array to number (Sign mode hidden)
FXP simple Math (Rounding, saturation and output type hidden)
SubVI node setup (When right lcicking the subVI on the BD and changing it's properties - show FP when run, suspend and so on)
Sub VI settings in general (Subroutine, debugging)
I know there are already ideas out there for most of these (and I simply chose examples to link to here - I don't mean to leave anyone's ideas out on purpose) but I feel that instead of targetting the individual neurangic points where we have problems, I would like to acknowledge for NI R&D that the idea behind most of these problems (Some of them go much further than simply not hiding the information, and I have given most kudos for that) is that hiding information from us regarding important differences in code execution is a bad thing. I don't mean to claim anyone's thunder. I only decided to post this because of the apparent large number of ideas which have this basic idea at heart. While many of those go further and want additional action taken (Most of which are good and should be implemented) I feel the underlying idea should not be ignored, even if all of the otherwise proposed changes are deemed unsuitable.
My idea can be boiled down to the fact that ALL execution relevant information which is directly applicable to the BD on view should be also VISIBLE on the BD.
As a disclaimer, I deem factors such as FIFO size and Queue size to be extraneous factors which can be externally influenced and thus does not belong under this idea.
Example: I have some Oscilliscope code running on FPGA and had the weirdest of problems where communications worked fine up to (but not including 524288 - 2^19) data points. As it turns out, a single "Boolean array to number" was set to convert the sign of the input number which turned out to be completely wrong. Don't know where that came from, maybe I copied the primitive when writing the code and forgot to set it correctly. My point is that it took me upwards of half a day to track down this problem due to the sheer number of possible error sources I have in my code (It's really complicated stuff in total) and having NO VISUAL CLUE as to what was wrong. Had there been SOME kind of visual clue as to the configuration of this node I would have found the problem much earlier and would be a more productive programmer. Should I have set the properties when writing the code initially, sure but as LV projects grow in complexity these kinds of things are getting to be very burdensome.
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:
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.
Currently if a VI is set to subroutine priority you can only call subVIs within that which are also subroutine priority (to prevent priority inversion I guess).
It would be great if it was possible to also use inlined subVIs inside subroutine VIs.
As inlining basically defeats a VI's priority setting an inlined subVI would just "inherit" the subroutine priority of its caller. I configure many of my very small reuse VIs as inlined (most of those in the GPower Error & Warning toolset from v2.1 onwards for instance), since they typically perform much better than subroutine that way. But since they are configured as inlined, this effectively prevents them from being (re)used inside subroutine VIs.
I am extensively using the Array to Spreadsheet string Primitive and most of the time I never used the Format string input (Use to wire an empty string constant) and still I am getting the right result what I expect. So I think it would be better if the Required Terminal is changed to an Optional Terminal.
It is known that the Array to Spreadsheet string is Polymorphic, but when we wire an array of I32 and DBL the output string is DBL format only. It would be good if the output String adapts the data type that is wired unless otherwise specified by the Format string.
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):
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:
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?.
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.
The Desktop Execution Trace Toolkit (DETT) can trace enqueue/dequeue operations, so I would think this is feasible:
Add a mechanism to like the Profile>Performance & Memory view to display all active queues in memory by name (for "unnamed" ones, use whatever unique refnum/identifier is available) as well as the max size and current # of items in queue. You could use the same "Snapshot" functionality as the Profiler tool.
A particular use case:
We were tracking a memory leak in a large application that resulted from an unbounded queue whose consumer was disabled. The standard DETT and Profile tools weren't showing where the excess memory consumption was coming from, since queue data does not "belong" to a single VI. Granted, you can see the individual enqueue/dequeue operations in DETT, and even highlight pairs, but that's a little cumbersome in a large application.
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").