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
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
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
This method is of very limited use (probably useless) in practical applications.
The general use-case is for more than one plot to be displayed on the same graph. With the current implementation, if plots overlap (or cross), it is impossible to determine what plot the given coordinates are on.
This method should return an array of plots.
... View more
I'm surprised a search did not turn up anything about this. NI should create a LabVIEW Amazon Web Services/Azure/Docker Image(s). The sample case I am thinking of is having a Jenkins CI server running on AWS EC2 with a full LabVIEW environment installed. This would allow off-loading the long FPGA or full RF suite builds during CI.
Apparently NI had this with LabVIEW 2012 on AWS
I would suggest to NI the following steps:
create AWS LabVIEW image for cloud-based compiling - charge per use
Use AWS to work out the kinks to get an efficient, speedy image created
Open an NI data-center that does what AWS/Azure does but for the tech/engineering field and host all of their own software images
Profit (or at least start to pay back that huge CapEx outlay)
... View more
If I have a TypeDef cluster in my block diagram, I have the option to display this as an icon. This is how I normally have the clusters on my block diagram.
Occasionally, I have to replace a cluster with a different cluster. However, the cluster is replaced with a none-oconised version of the cluster. Thus often the block diagram expans in one direction or another accordingly.
I would like the cluster replacing the actual displayed cluster to adopt the same visual setting (i.e. to appear as an icon).
This actually feels like a bug to me rather than a feature request.
... 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
Consider expanding programmatic modification of the Build Process. There is already an Idea here to allow the Pre-Build Action to set the Version Specification before the Build Process (it happens during the Build process, after the before-the-change Version Specification has been cached and used in the Build). However, other Specifications in the Build Spec would be very useful to be able to specify in a (true) Pre-Build Action.
Target Filename (low priority)
Destination Directory (I like to put Builds in Public Documents, but the Public Document folder can "move", though LabVIEW's Get System Directory can find it, so I could "pre-build" a path specific to the given PC)
Build Specification Description (allows the user to include version-specific or Build-Time text)
Version Information (in addition to Version Number, before being used, the other Fields might be useful).
I've noticed references on the Web to automated Builds, and know there are Build VIs that will do a Build. I also know there are a set of "barely-documented" APIs that some have used for this purpose, but I don't know (other than the Set Version Specification, which doesn't work as I expected in a Pre-Build Action) of others. I don't especially want to poke around inside the Project's XML file -- can we consider adding some other "Pre-Build" Set functions? Could (for example) some of these "Build Properties" be set with a Property Node? Maybe this functionality is already there and I've not found it ...
... View more
This idea is an extension / alternative for this idea:
You can give Kudos to both ;-)
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 but it's hard to reach them (if your read the other idea, you'll see that it is even imposible for a specific element).
What I'd like to have is a right-click-menu-entry "create property node" (same for method node). The result shall be a property node appearing in the block diagram which is linked directly to the decoration element.
... 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
The current low level implementation of TCP functions only accesses a data stream, but not the raw data of the tcp telegram. It would be nice to have a low level TCP "Read/Write Telegram" function to get additional information from header or footer, like time stamps. Maybe as a buffered stream, like the current functions.
The resulting cluster could look something like this:
... View more
Hi, So in VI Properties, you have the Window Appearence tab with "Same as VI name" tickbox. Wouldn't it be great/better if this automatic name skipped the file extension? Settings.vi -> Settings OneButtonDialog.vi -> OneButtonDialog and so on. /Y
... 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
The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk. We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!) I would like to request a feature that allows us to easily and permanently remove any entry in the list. (...maybe it could even show for pinned entries?) IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list. It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry. These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.
... View more
Sometimes switching the inputs of compound arithmetic functions (ctrl+click) makes the diagram easier to follow. When this happens on nodes were one of the inputs are inverted, both inputs have to be inverted after switching the wires. This is probably the use case 99% of the time and thus should be automatically done.
... View more
The real-time updating of the block diagram when dragging the borders of a structure is a nice feature, though there's one thing I noticed was lacking compared to previous versions of LabVIEW - some sort of indicator of the structure's original size during a resize operation. For example I begin a resize operation in LV2015, and get a dotted border of the new structure size, while the original structure is visible. I can see the previous and current state of play in one move. With the LV2016 resize I can see the current state of things, but not what the structure size was. I propose adding an indicator to show the original structure size during a resize operation in LV2016. Why is this useful? I find it helps better visualise spatial relationships between items on the block diagram during a resize (how much room do I need to make inside the loop to fit three more VIs?). It is also a hint as to what cancelling the resize operation will revert the block diagram back to. It need not be a dotted box if that's confusing with older versions of LabVIEW. Perhaps a semi-transparent / greyed out version of the structure? Or perhaps a dotted line drawn between the old handle position and the new (similar the ctrl+mouse drag when inserting space).
... View more
After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go. We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time. So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk. Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.) In summary, there should be a menu entry that ignores indicators when making values the default. It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.
... View more