When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.
... View more
I´d appreciate an event that is called whenever there is a change of Top cell (row). Several times I needed to "align" visible content of two objects (listboxes, trees, etc.). Value change or mouse scroll event can be used but still I´ve found no way how to catch when the user uses scrollbar arrows or draging scrollbar position indicator. The only solution I found is to keep it aligned by periodically reading out Top row visible property of one object and set it for another one. That requires code in Timeout event that is called very often (otherwise it is noticeable for user) causing performance drop.
... View more
Languages like 'R', 'Python', and MatLab (yes I use the old name) have these. They are useful.
One of the key ideas in LabVIEW is that the user needs minimal interventions to code a useful result. As more information is encoded in a data type there is more opportunity to make "hands free" code that "just works". I think these two data types can do that.
Primary data type in R
It is Array-like, but NOT an array
each column contains one measurement (row) on one variable
It acts like a list of vectors, but the vectors have the same number of rows, and indexing allows a return of all or subset from all columns
column types are heterogenous - they can be different
column types can be set. A column of 0 vs. 1 can be set as factors/binomial values or as continuous.
There are functions that data analysis folks do every day that are informed by variable type, so the function operating on the inputs doesn't need type specified because it is interior to the table. This means you can say "plot(mydata)" and if your data is set up well, the graph parameters are already specified and useful.
This is from Hadley Wickham, a very famous person in 'R'. He does great work, and his name has high brand value in data-analysis.
Uses the "data.table" package
is able to be screaming-fast (think roller-coaster) especially when used with the "split-apply-combine" approach to data analysis, and SQL-like operations.
is built for handling huge data (100GB tables) quickly and efficiently.
In many applications the same operation is not possible due to memory constraint or viable due to processor overhead can execute adequately (aka wonderfully) by using this data type on the same hardware.
... View more
We've been saying it for years now. Enums should be typedefs.
Why not make EACH and EVERY dropped Enum into a typedef automatically. Drop a new Enum from a palette, it is a typedef. Copy it, it's linked to the original. For my taste, even ask for a save path after dropping the enum but for the sake of our sanity, just make each and every enum a typedef already.
... View more
We can right-click a string object and change the state (control, indicator, constant, array, element) by right-clicking. Unfortunately, the current behavior is (partially) inconsistent in the way the display format (normal, /-codes, pass, hex) is handled. Here are some results (list is incomplete), the symbol <> means in either direction.
Control<>indicator: The display format is retained
Array<>array constant: The display format is reset to "normal". *(Also see below)
Control|indicator<>constant: The display format is reset to "normal".
(*note that if I drop a string constant into an empty array container, the format and element size is retained. Converting to array using right-click should do the same!)
Whenever a conversion involves a diagram constant, the current display format is lost. I think it should be retained!
... View more
When using Typedef's I often have teh control wire passing through a VI. If I need to modify the typedef, I have to either create an instance of the controil/indicator, or got to a VI that uses the typedef control and the righ-click. From here I can open the Typedef.
What I would like to do is to be able to right-click on the wire and select directly 'Open Typedef' without having to go to a control.
It is a minor issue, but if I am in the middle of development in a VI, I don't want to have to click away from the VI under development to find the control. Additionally, creating a constant so that I can right-click on it is also not so convenient. If the Typedef is a large cluster, the block diagram may be distorted when the Typedef appears.
... View more
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.
... View more
As everybody knows there are two ways for generating an empty string constant in the block diagram: Using the "empty-string"-constant or creating a genereal string constant with no content.
Both ways have advantages and disadvantages:
- The "empty-string"-constant shows much better that the string is empty but it can't be used e.g. in arrays.
- The string-constant can always be used, it is easily generated by right-klick to a string terminal and selecting "create -> constant". Furthermore its value can be changed to somthing non-empty if required. Disadvantage: It's hard to see if the constant contains nothing or just a blank sign.
My suggestion: LabVIEW shall show a string constant which contains an empty string always with the symbol that is currently used for the "empty string"-constant. This is also valid if the empty string is within an array or cluster. If this behaviour is not wanted in a particular case, there shall be the conext-menu-option "show symbol for empty string" which could be deactivated.
For changing the value of such a new string constant, the symbol shall change to a classic string constant if the user moves the mouse (with selected text-editing-tool) over it.
Similar behaviour is also suggested for general-path- / empty-path-constants.
Remark: I'm working with LV2015SP1
... View more
Remark: I'm using LV2015SP1 - maybe there is already a change in LV2016.
Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist.
Because a decoration element does not have a property node, it must be searched via the decorations-property of the pane. The problem here is, that there no possibility identify a particular decorcation element because there seems not to be any identifier property.
What I'm requesting to resolve this awkward situation is to give all decoration elements a label-text property (or any other identifier property) which can be set during programing time by the LabVIEW programmer.
... View more
I have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.
The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.
There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.
As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.
I cannot comment on Amazon S3, as I don't use it.
Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.
... View more
For those of you who haven't signed up yet, you should go and have a look at the Next Generation LabVIEW Features Technology Preview (a mouthful, but in short, it is a UI and Development Environment demonstration version of what NI is cooking up for future versions of LabVIEW). There are some cool things and some downright awful ones. One of them has been sneaking its ugly neck in LabVIEW 2016: reduced contrast. I am (my eyes) getting tired of it. A few examples of the changes introduced in 2016 are shown below: 2015: 2016: Considering that the trend is for displays to not increase that much in size but increase in resolution, we have now to factors to fight against: the reduction in size AND the reduction in contrast. I won't mention laptop displays going in economy mode and reducing their luminosity, but the point is that it is making LabVIEW even more difficult and unengaging to use. Way to go to loose any chance to attract new users, and run the risk to loose old timers due to added eye strain. Put simply: Restore high contrast icons and please, do not go ahead with the washed out IDE and UI objects showcased in Tech Preview.
... View more
So one shortcut I really like is CTRL+Shift+E. This shows a VI in the opened project and drills into dependencies, and libraries to show you where the VI is. The most common reason for me doing this is to find the library or class that a VI is in, and to find the other members within that library. One issue I have is if I open a VI that isn't in a project. This isn't very often but some times I want to work on editing a library or class that isn't part of a project yet and is just some reuse code that I intend on cleaning up.
When I open a VI that is in a library, but not in a project, CTRL+Shift+E does nothing, but what I think would be nice is if this same shortcut could be used when not in a project to open the Edit >> Browse Relationship >> This VIs Class and open the class to show where the current VI is in the class or library. Or alternatively this idea could be to make a new shortcut that does open the library or class a VI belongs to, and select the VI in a similar way to the This VI In Project works.
... View more
As we increasingly integrate with HTTP servers the LabVIEW functions appear more and more limited.
Authentication is a major concern and in enterprise environments one option is NTLM (or Windows Authentication).
I would like to see the HTTP client support this as in this case we had to abandon using LabVIEW for the integration.
... View more
Imagine that you have made lots of code, wiring up several VI etc. all with the same data, a cluster for example, going in and out. Now you regret not having defined that wire as a typedef. Today replacing the data with a typedef will involve a lot of steps; you start by clicking on one of the controls or indicators, and create a typedef...then you need to do the tedious work of replacing all the other controls and indicators up- and downstream.
Would it not be nice if you could just right-click on the wire and select "Define type"/"Create type definition" or "Replace with type def/class" - and then choose to have the type definition automatically replace everything along the wire ("propagating type def")?
This idea was inspired by and first came about as a comment to this idea by cowen71.
... View more
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course :)). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
... View more
I had this idea for a while and did not find anyone else suggesting it, so heres the Idea:
Usually I have many VIs open at the same time and its annoying to switch between them, because they all have the same symbol in the Taskbar, and all are named "Frontpanel of ..." (rest is cut off)
Why can't Labview show the VIs icon instead? Maybe even with a little label on the icon for frontpanel / block diagramm.
Or is there already a solution for that?
Hope you like the Idea.
... View more
Everyone knows, actual assembly and constructor selection through dropdown and objects is very painful.
Disadvantage: A programmer has exactly to know, what he search for and in which assembly he can find it.
Common .NET Editors supports users with dot notation and text recognition. e.g. Visual Studio
OK that is luxury and not necessary - but what about a simple filter input field like in "Edit Events" dialog?
To capture this in a nutshell:
- add a filter input field
- add a little bit luxury with dot notation and autocomplete
- maybe there is a way for remanent selection of some default assemblies (cf. Visual Studio) so that filter base is fast and assembly dropdown must not use all time
Benefit: Notation to select a constructor (or method or property in other nodes) is that the filter input string is similar to all .NET class documentations, tutorials and examples. Transfer will be much easier.
... View more