Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
The recently introduced Raspberry Pi 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 Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 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 15 times the processing power!
Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?
In LabVIEW we can dynamically run a VI in a few ways:
a) If it's not running Top Level VI or if the VI re-entrant with the Run method.
b) Already running as sub VI, with Call By Reference.
c) Make a new VI and drop the (running) sub VI on the diagram.
Downside of a) is we can't always make sub VI's re-entrant, but still want to call it by reference. Downside of b) is we need to know the strict type (connector pane). Downside of c) is we might end up with a lot of VI's just to function as Top Level VI for the sub VI's and it doesn't work in executables.
I like to propose a method, so we can dynamically call a sub VI without knowing the strict type.
Using it, we enable LV to dynamically run sub VI's while setting\getting it's parameters by name.
For sub VI's (already running) this method will act as Top Level VI. For Top Level VI's it will fail unless it's idle.
The In Place Array Index/Replace Elements function not only can save memory by avoiding copying arrays, it can also create "neater" and more transparent Block Diagrams. For example, here are two ways to triple the third element in an Array of 3 elements:
I needed to do the same thing, but for a 2D array (three channels of A/D data, I wanted to triple the third channel). The Help for the In Place Array Index/Replace Subset function suggests this is possible, using language like "element or element(s) of an array", noting the similarity between this In Place Structure and the two Array Functions that form the Input and Output nodes, and in earlier versions of LabVIEW (specifically LabVIEW 2012), explicit reference to rows, columns, and pages as replacement items. Here's what happens:
The Index Array left node forces you to specify both row and column, meaning you cannot operate on a single row (or single column), "breaking" the functionality with the separate Index Array/Replace Subset functions. This also, I believe, will force an Array Copy operation, something I'm (also) trying to avoid.
At its most benign, there is a Documentation "Bug" that should warn users that this In Place function is only designed for single array elements (which, in my opinion, severely limits its usefulness). I would like to suggest that this function be "fixed" to (a) for multi-dimension Arrays, allow, as with Index Array and Replace Subset, flexible choice of one or more Indices to be specified, with the unspecified Indices implying "All of the Elements", i.e. an entire Row, Column, Page, etc, and (b) maintain the "In Place" functionality by having this function generate the necessary code (behind the scenes) to access the specified elements and do whatever operation is required inside the Structure.
I appreciate that requirement (b) might be difficult. For instance, operating on a row in a 2D array should be easy, as the (row) elements should be continguous, making getting and putting them simple. However, if a column is specified, getting successive elements and putting them back becomes more complex. To the User, it all "looks simple" -- you get a 1D wire out, operate on it (say, multiply it by 3), and stick it back "in place", but the LabVIEW compiler has to "get" elements from non-continuous locations and put them back where it got them, but that's what Compilers are for!
As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.
So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.
So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.
There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs
Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.
As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.
If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).
Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.
IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.
As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wastedtaken up by borders, frames and trims, etc.
We need a palette full of "Amish" controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.
A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container. A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.
They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.
Now, why would that be useful?
Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.
Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.
The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)
So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.
As a welcome side effect, redrawing such a FP is relatively cheap.
Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM
The goal of this idea is to make it easy for the LabVIEW ecosystem to create reusable libraries for LabVIEW that would be type independent. Let's think for a second dictionaries, also called as key-value stores. Dictionaries are data structures that allow storing and retrieving values with a specific key. To create a generic reusable strongly typed dictionary is currently impossible with the LabVIEW type system. One can create a dictionary that is type specific but then it's not reusable. Or one can create a reusable dictionary but then it's not strongly typed. Type Parameters and Parametrized Generic Types as explained in this idea would allow creating strongly typed dictionaries that are widely reusable across applications. Specifically type parameters and parametrized generic types would allow LabVIEW ecosystem to develop highly reusable strongly typed components to solve various common programming problems. This would allow National Instruments to put more focus on the core of the language as the LabVIEW ecosystem could solve much wider range of problems that preivously have required National Instruments to contribute.
Add a new control type Type Parameter to LabVIEW that augments the current Control, Type Def and Strict Type Def control types. The Type Parameter type would act like a regular Type Def control with one special and important distinction. You could wire anything to an input terminal expecting a specific Type Parameter type and the downstream type would adapt at compile time to the type wired to the type parameter input.
In a single VI type parameter could be used in multiple places but all instances of the type parameter would adapt to the same type.
When a VI that uses Type Parameters in the front panel is used on a block diagram, the template VI is replaced by the compiler by a type specific instance that has adapted the type parameters to the type wired to the Type Parameter input. Notice below how in our VI the control and the indicator were of type Type Parameter with a default type of DBL and the instance got adapted to type U32 that was wired to the input.
The same type parameter could be used on multiple inputs of a VI.
And all of the type parameters would adapt to the same type when the VI is being used.
Note that in the above example we chose the element of the array to be a specific type specified by a type parameter. However the arrays themselves could as well have been specified by a type parameter.
So far we have focused on VI boundary where type parameters adapt the whole VI to specific type or types if multiple different type parameters are being used in the connector pane of the VI. Type parameters can also be used in composite types (e.g. arrays, clusters, classes) and the downstream composite types would adapt to what is wired to the type parameter input.
Note that x and y as instances of the same type parameter have to be of the same or compatible type.
Type parameters can also be used in class private data to create parameterized custom types. This is where type parameters become extremely powerful. Let's assume that we have a class 3D Vector.lvclass that has three instances of a "Data Element.ctl" Type Parameters. The default type of the Data Element is set to be DBL. The cluster private data has three instances of the Data Element, one for each of X, Y and Z.
Now we could create a Create 3D Vector method VI for this class that allows us to construct type parametrized instance of the class type.
Now calling this Create 3D Vector.vi with string as the inputs for type parametrized inputs X, Y and Z will create an instance of class 3D Vector with compile time type 3D Vector[String].
And this is where we now start seeing the superpowers of type parameters and parametrized types as well as generic type parameterized VIs that go along with them. Now we have a capability of creating custom VIs and custom types that both can adapt to different parameter types at usage time.
Let's get back to the question of dictionaries. We could easily construct a dictionary that allows the key type to be parametrized with one parameter and the value type to be parametrized with another parameter. For example we could use the dictionary with I32s as keys and Strings as values. Or we could use it with Strings as keys and File Paths as values. Constructor for such custom type would be trivial to create.
Once we have constructed the dictionary we would naturally like to use it. We could now use method VIs of the Dictionary class to add and fetch elements from the dictionary. As an example Get Element By Key would look something like this in it's simplest form.
Note that Dictionary In is type parametrized with two different type parameters Key Type and Value Type. In the class library there is a Type Parameter control Key Type.ctl and Value Type.ctl. Now type parameter Key Type.ctl is used both inside the private data of the class and on the fron panel as the Key input, the type of these two must be the same. The same is true for the Value Type element of private data and the Value indicator that both derive from Value Type.ctl type parameter. The has function is any function that can convert any LabVIEW types to some strings that we can use as keys for the variant attribute node. We are using variant attributes as the store implementation is this basic example.
Calling the Dictionary with integer as the type parameter and string as the value would look something like this.
As you can see the 0 and empty string will define propagate as type parameter types for Key Type and Value Type in the dictionary wire. Now Add Element.vi would have to adapt to these elections for Key Type and Value Type the moment the Dictionary wire is connected. The Key input immediately change to type INT32 and the Value input to type String. Similar would be true if the wires would be connected in reverse order. Connecting University of Texas string to the Value input of Add Element and connecting number 1 of type INT32 to the Key input of the Add Element would immediately adapt the Dictionary in and Dictionary out inputs to be of type Dictionary[Key Type = INT32, Value Type = String]. A type error would occur if Dictionary in would be of different type.
Type Parametrized Generic Types are an extremely powerful concept to incldue in a language and this idea describes a feasible way to implement them in a visual dataflow model of LabVIEW. This is and has been for maybe ten years my absolute #1 feature I have wanted to see in LabVIEW. I think the time is right for me to officially make this request. Ideally Type Parameters can be bounded but that's a topic for a whole other idea post.
Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!
Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.
Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:
Opening the "class properties" window takes 10 seconds or more
Renaming a class brings the editor to a standstill
For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!
Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.
Improve the responsiveness of the LV editor when working with classes.
Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
I don't know how many times I've added a case statement post-programming, but I do know that there isn't an easy way to make a tunnel the case selector. Usually I delete the tunnel and then drag the case selector down and then rewire, there should be an easier way. For loops and while loops have an easy way to index/unindex or replace with shift register, why can't a case statement be the same?
The dynamic events terminal accepts bundled Event Registration refnums, and you can use an Unbundle on the inside of the structure to access all of the events. This is very useful, and allows you to edit events dynamically during run-time.
The Register for Events terminal also accepts bundled User Events, registering them all at the same time. This is very helpful when writing code in which the User Events are generated in a subVI; you only need to present the User Events as a bundle on the output terminal.
The issue is that, if you have Registered the events as a bundle, you cannot access the individual User Events within the Event structure. This would be useful to have, for example, one event case modify which event structure a different event case listens to.
In the above case, it would be ideal if you could first unbundle the wire from the Dynamic Events terminal, then read all of the user events to which it is listening. This value would be a bundle (in this case, containing Event A and Event B), and you could wire "Replacement for A" into it.
Currently you can only replace both A and B at the same time, requiring you to keep track of what exactly is registered to each refnum separately.
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.
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.
I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.
The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.
As it is already wired, inline and not broken, dropping a For Loop around it should not break my code!
Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array.
Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.
This would remove one step required for most use cases, speeding up my development experience.