LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

There are many VIs located beneath the "<LabVIEW>\resource" folder that need to be called as subVIs of LabVIEW add-ons (e.g. project providers need to call provider API VIs located there).  However, because the resource folder is not a Symbolic Path this introduces many challenges for LabVIEW add-on developers.  LabVIEW add-ons that link to VIs beneath the resource folder cannot be moved to a new location (for example as part of a source distribution build step), otherwise they will not be able to find these resource subVIs (since they link via a relative path between the caller and subVI, rather than a relative path between the resource folder and the subVI).  Note that NI doesn't really feel this "pain" since most of the add-ons NI develops are developed "in place" beneath LabVIEW and ship with LabVIEW -- they don't get "built" and they don't get "installed".  However, for 3rd party add-on developers, it's critical that the resource folder be a symbolic path.

 

Note: This would make building packages of project provider plug-ins possible with VIPM.

Recently I've talked to companies that are already using LabVIEW and their organization has standardized on tools such as JIRA for bug tracking/project tracking as part of an organization-wide initiative.  JIRA connects to other IDEs/programming tools such as VisualStudio, Eclipse, IntelliJ, etc.  Atlassian (the company that makes JIRA) also provides tools that can part of a larger Agile process and can facilitate code reviews and other software development processes.

 

JIRA.png

 

The idea up for vote is to offer more comprehensive LabVIEW interoperability with industry standard tools such as JIRA, or other software as part of an internal software design process.  (feel free to specify a certain tool, if you have a preference)

It is common, in writing reusable code, to handle arbitrary clusters in variants.  To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items.  After access, one needs to convert the array of variants back into the original cluster.

 

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository.  They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow.   Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

 

The other direction, Cluster to Array of Variants, works like this:

Array of Variants to Cluster.png

But trying to reverse the process breaks:

Array of Variants to Cluster.png

 

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also.  The matching of array to cluster elements can be by cluster order rather than element name.

 

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

Although I expect that it will take a while before this is implemented I would like to add the request so NI can start thinking about it.

 

As you might have noticed that Microsoft announced a few things on Microsoft build 2015.

 

Aside from the hololens and windows 10 for the raspberry pi they both share 1 common factor. They both run "Universal apps" (see http://www.engadget.com/2015/01/21/windows-10-makes-microsofts-dream-of-universal-apps-come-true ).

 

So it would be great if we can run LabVIEW programs as a "universal app" and run our code on all windows 10 devices..

The Property class, which represents the property node, has a property called All Supported Properties which ideally would show all the properties supported by the class the property node is linked to.

 

The problem is that it doesn't. If you have nested properties which come from another class (for example, the properties for the caption which can be selected by opening the pull right menu, as seen in the top image), those properties aren't returned when you call the property, and instead you just get the property for the caption reference, as seen in the bottom image, where the ControlIndex property is shown immediately after the Caption property.

 

NestedProps.png

 

 

Instead, I want either this property or a new property to return all of the nested properties as well, just like you get in the UI.

This would be useful for setting properties using scripting and alternate UIs (like this one or this one, which can't work today, because they can't get the full list of properties).

 

 

 

As part of a review of a shipping product, I want to make sure that all of our LabVIEW-built executables are using the same version of LabVIEW so that we also only have to ship one version of the LabVIEW Run-Time Engine. Everyone I've talked to has given me advice on things to change at export time, build time, or even run-time to know the version of LabVIEW it was built in (e.g. the App.Version property), but what if I want to know the version of an EXE I have already built?

Here are the methods I've tried so far:
1. I created a set of VIs that does it crudely by reading the EXE file in as if it were a text file, finding mention of lvrt.dll, and then scanning back a few hundred bytes to try and find a version X.Y token in there. (Of course this could be done in any language, not just LV). This solution can be automated for my product release's review process, but it would be prone to failure if the EXE format changes or my assumptions aren't correct. I wrapped the solution in one that searches our installation directories for all EXEs and returns all LV EXEs with versions (as they are detected here) and all non-LV EXEs so I can verify that my tool is not giving false negatives on LabVIEW-based executables.

Parse EXE as text for Version

 

(See attached .zip file for my LV implementation)


2. Run the EXE on a machine with no LV RTE and read the version from the error popup that you get when it launches. Obviously this requires user interaction, and requires launching the executable.
3. Install all LV RTE versions you think the EXE most likely requires. If it launches without incident and stays in memory, you can use Process Explorer to figure out what libraries it has loaded and see which version of LV RTE was called (since the lvrt.dll will be under "<NISHARREDDIR>\LabVIEW Run-Time\<Version>"). Obviously this isn't easily automated either, and requires launching the executable.
4. I tried using Dependency Walker to see what lvrt.dll dependency was found, but it didn't show me anything useful. I'm guessing it's dynamically loaded somehow, and DepWalker can't tell me?

What I'd really like are two things:
1. An LV Invoke Method like "Get VI Version" and "Get VI Editor Version" that works on built applications -- "Get App Version" with the same types of inputs and outputs as (file path input, string version output and U32 version output). An added output to determine platform and/or bitness would be nice, too.

2. An LV RTE property that tells me the Run-Time version in the file's properties. I could potentially automate checking of this via .NET calls or something like that

GetAppVersion.png

 

Embed_LVRTE_Version_into_EXE.png

The detailed help link in the LabVIEW Context Help window is a great way to add extra documentation to your LabVIEW code.  However it currently only supports .hlp, .chm, .htm, and .html files types.  This should support many more documentation types such as pdf, txt, doc, .xls, png, .etc, etc.

 

pdf.png

Firefox is not publishing the PNG data that contains a snippet inside the Drag and Drop info, however the info is stored inside CFSTR_FILEDESCRIPTOR (source) it would be very helpfull if LabVIEW supported this as well.

 

TOn

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.

Type Parameter Definition

 

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.

 

Type Parameters

 

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.

Calling a VI with Type Parameter Inputs

The same type parameter could be used on multiple inputs of a VI.

Multiple Inputs of The Same Type Parameter

And all of the type parameters would adapt to the same type when the VI is being used.

Calling a VI with Multiple Type Parameter Inputs of the Same Type

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.

 

Type Parameters with a Cluster

Note that x and y as instances of the same type parameter have to be of the same or compatible type.

Type Error With Type Parameters

 

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.

Type Parameters in Class Private DAta

 

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.

Creating a Type Parametrized Object

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].

Calling a VI that Creates a Type Parametrized Object

 

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.

Type Parametrized Create Method for a Dictionary

 

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.

 

Get Element From Dictionary

 

 

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.

 

Calling a Type Parametrized Dictionary

 

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.

I've long wished Labview had native support for Interfaces.  Recently I ran across an article describing Traits as a better alternative to Interfaces, Mixins, Multiple Inheritance, etc.  Traits are (as near as I can tell) similar to Interfaces with the main difference being Traits can define a method implementation while Interfaces can only define a signature.

 

I'd like to see Traits implemented in G instead of Interfaces.

 

(Cross posted to LAVA.)

 

 

I often need to interpret JSON formated Strings.

Until now I use regular expressions.

 

A JSON-Parser (like the LabVIEW-XML-Parser) should simplify the expense for me drastically.

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

  • Changing VI connector panes
  • Renaming or moving VIs on disk
  • Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

 

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

 

 

Version 1.0

Version 2.0

VI Path

 

<userlib>\mytoolkit\CompRes.vi

<vilib>\mytoolkit\Compute Result.vi

Owning Library

 

none

Mytoolkit.lvlib

Connector Pane

 pane1.png  pane2.png

 

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

At the moment you can Register for Events using a Cluster of Refnums.

But you cannot Destroy User Events or Unregister for Events in this way.

 

This approach allows for you to scale your application without the need to change the code that handles Registering Events.

It would be very convenient to be able to close references in this way (using a Cluster of Refnums) too, as per my illustration below:

 

21670iEFD0527198796259

Hello,

 

Actually the LabVIEW project Build Specification allow to create an old style DLL shared Library.

This kind of DLL is not so user friendly to use, because you have to define the DLL function prototypes, when you want to use them  ...  (Import, declare ... )

 

It would be nice, to be able to create a .Net DLL shared Library which is more easy to interface. (Without declare, import ...)

 

Build specification.png

The DotNet DLLs can be used without having to create Import declaration.

The self documentation of DotNet DLLs don't need to declare all function prototypes when you want to use them.

 

My need is :

- To create LabVIEW drivers libraries

- To create Packed libraries, from these librairies, to be used by LabVIEW projects or TestStand sequences.

- To create DLL from the same libraries, to be used by dotNet projects

 

Thanks a lot for reading.

 

Manu.Net  

When a third party add-on expires you get a dialog asking you to activate it, but the dialog does not offer you the option to remove it instead:

 

Mads_0-1665130603004.png

 

If would be nice to be able to select add-ons in the add-on list and then click a Remove/Uninstall button (and/or right-click). The current solution is to manually fire up the package manager and uninstall it from there (the remove button could alternatively (if needed /quicker to implement) call the package manager and tell it to start the removal of the selected packages.

[Cross-posted here on the JKI blog]

 

One LabVIEW feature that (if it existed) would make a big difference for VIPM users is the ability to refresh the menus (e.g., the FileTools, and Help menus) programmatically after installing packages that add menu-launch VIs.  Maybe we could do this if LabVIEW added a new VI server method called Application:Refresh Menus.

Note: this would be similar to how we can refresh the palette menus programmatically by invoking theApplication:Refresh Palettes method (shown below).


refresh-palettes

 

I bring this up, because one feature that I’d love to see added to VIPM (some day) is an easier way to build menu-launch tools into VI Packages, and I’m sure more people would be asking us why their add-on doesn’t show up in LabVIEW after it’s installed.

Hopefully, we can help NI get this feature onto the LabVIEW roadmap by convincing them that it’s worthwhile.

Hi,

 

It would be awesome if there was an option in project window to set if the method is contained within a .lvclass file or ouside of the .lvclass next to it in the folder.

 

Now it's like this:

HowItsNow.png

 

It's hard to use a class like that in a plugin architecture with VIs on the outside. Lets put everything together inside like a LabVIEW LLB!

 

How it should be:

HowItShouldBe.png

 

Don't get me started on Packed Project Libraries 😉 We just need LLB functionality, for the class to behave like a folder and we are happy 🙂

 

Piotr

I haven't tried yet, but this might be already possible by generating C code and then building a Python package from that. It would be nice to have that automated.

I think there's also a commercial potential to sell Vision Assistant as a separate product (to Python developers).

Having a continuous integration system is an essential component of software development:

Continuous Integration ProcessContinuous 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.