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!
Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.
So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!
Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).
Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?
Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: https://forums.ni.com/t5/LabVIEW/Read-Write-Variant-to-TDMS/m-p/3334203
I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?
If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.
NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:
However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:
This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.
During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi" and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.
While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.
The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:
Having a continuous integration system is an essential component of software development:
Continuous Integration Process
This system requires automating the building process.
The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.
But the community has supplied a few sollutions to achieve this: CLI Tool
On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.
This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.
My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.
During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:
vi.lib (VI Package Manager installs packages to this location by default)
Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.
This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.
I have several LabVIEW applications that I work on, and each of them has a Perforce workspace associated. Every time I switch to a project that is in a new workspace, I have to dig through the SCC configuration menu to switch workspaces, which takes a while.
It would be really sweet if LabVIEW recognized that a project file was in source control, and associated the workspace with the project file. (Especially because I could have two application projects open, each in its own workspace.)
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.
If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.
Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.
The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.
When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.
Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!
When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon). What I'd like to see is a solution that treats 3rd party installers as first class citizens. I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.
This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.
When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run. This is a pretty simple scheme that would really simplify the process for end users.
I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas. I'd love to hear your comments.
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.
The operating system takes a long time to open an application when you need to open many file, if we group files in larger files, the times are reduced. With LabVIEW we can create libraries ".llb" is a really funky zipfile, but it is a file that was introduced to provide functionality in the past.
Like Java uses the ".jar" to create packages and distribute the code more easily. They are built on the ZIP format and typically have a ".jar" file extension; LabVIEW uses the ".vip" to create packages with VIPM. VI Packages are similar to zip files in that they contain all the VIs and resources for a specific LabVIEW add-on. But ".vip", are not recognized by LabVIEW in the project tree, instead ".llb" files, we can access its contents from the project tree of LabVIEW.
From a labview project, we can build a ".zip" file. (Build Specifications>New>Zip File). But if we enclose the project in the .zip file, it does not show us the content tree.
My proposal is that LabVIEW can recognize the contents of the ".zip" files, as well as the ".vip", to be able to access its contents and be able to use the lvlib, lvlibp, class, vi ... that are contained. In this way, we can use ".vip" files in <vilib> \ *, <urllib> \ * ... and be able to use its contents without needing to unzip it.
From LabVIEW Project, we can access the last modified files, from the menu File>Recent Files.
When we work with a large amount of files, it is very useful, so as not to have to navigate the whole tree, to find the last modifies files. But not always we will want to access the recently modifies files, so I propose to create a quick access category in the project tree.
When we work on a project with a large number of library, class, vi,... it can be difficult to find the files that need to be modified, so it can be very useful to have quick access to those files that the developer considers.
This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite. Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do). It could be used for creating installers of multiple, cross-project user installers comprising a complete system. To do this though, the current batch installer builder needs to be made more generic to be of use.
Add configuration options to control or disable license dialogs when non-NI provided installers are added
Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
Add batch installer version properties to allow end users to create system versions
Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)
Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.