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!
DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing). Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up. An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open. Many dlls have similar pointers/handles that need to be properly closed. This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.
A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created. That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle. This VI would contain the code to cleanup/close the contained non-LabVIEW references. Could have other uses, such as debugging.
I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help. Please consider it.
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.
This is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.
The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.
In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.
Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.
Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.
Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.
We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.
Finally, we have Destroy Promise. It does exactly what it says on the tin.
I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway ).
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.
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.
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:
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.
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!
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...?
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 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.
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.
Add a module to LabVIEW to use it on Android OS or Apple iOS.
People have already been getting smartphones for awhile. And now in 2011, there are so many manufacturers that make tablets with Android OS or even Windows. Apple iOS is considered to be the cool thing but Android OS is more open and used by more manufacturers (since only Apple for it's iOS). Since the Andorid Tablet is so new, yes there are more Apple tablets out there than Android tablets but if it's like the smartphone market, Android OS will overtake the iOS market. It's just a matter of time.
I don't know whether one is easier to code than another, but if you had the time I think a module for both the Android OS and the Apple iOS would be extremely powerful. Wouldn't it be great if we could run an instrument from our phones or tablets?!?!
But I would just be careful to make sure the module was robust and not too many key features were missing from the full LabVIEW version. In the past, we tried the PDA Module and Touch Panel Module for an instrument and it didn't work out. The module was very buggy and missing a lot of features from LabVIEW that we though were important key ones. We ended up abandoning the PDA module idea and went with an advantech touch panel computer with Windows XP and just kept writing with regular LabVIEW.
Currently in LabVIEW you can have a top-level palette (Programming, Measurement I/O, etc) automatically populate based on .mnu files existing in the folder structure at <LabVIEW>\menus\Categories\. However you cannot do this with the sub-palettes such as Arrays, File I/O etc.
I propose to allow auto-populating palettes for all LabVIEW palettes so developers can place their own palette within the appropriate LabVIEW palette for their functions. One example is OpenG and MGI each have a palette of Array functions. They are currently placed in a top-level OpenG\Array or MGI\Array location. If we could sync these folders, we could place each of the array palettes under the Programming\Array palettes:
Simply by dropping their corresponding mnu files here:
Thoughts? Discussion on LAVA that spawned this idea is here.