LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

LVM API

LabVIEW has shipped with an Express VI which supports the ASCII LVM format since version 7.0. However, there is no other way to access LVM files from LabVIEW, short of burrowing into the Express VI and using the subVIs. Doing this leads to problems, since the subVIs have changed a few times. In addition, the Express VI does not support all the features of LVM and makes accessing multiple data segments somewhat nonintuitive. We need an API for LVM, ideally object based, so features like the special block can be easily extended by users.

Too Many Updates to Run-Time Engine!

We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.

Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build.

I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO

Generate Python code in Vision Assistant

View All (2)

Add command line options to LVMerge

View All (1)

Usually, unsupported LabVIEW features can be enabled with nothing more than an undocumented INI key. The one exception that I know of is the integrated XNode development feature in the Windows version, which is instead controlled by the license manager. (This feature exists in the Linux and Mac versions as well, but on those versions it's an INI key like everything else.)

Despite not being officially supported, community-made XNodes are very much a thing. Even on the Windows version, one can still create them using a third-party editor, or hack their way into the built-in one somehow. And it's clear that NI (rightfully) doesn't put much if any continued effort into preventing third parties from making XNodes, as the same methods that were used over a decade ago still work just as well now.

I'm not asking NI to provide official support for XNodes necessarily, but I think it's for the best if they at least remove all unnecessary, artificial roadblocks, and open up the XNode development forum and perhaps some internal documentation to the public, so community-based developers can at least have the best shot at learning how to do it right. You've already done this with Project Providers; why not XNodes as well?

View All (2)

When integrating libraries written in C# a common scenario that occurs is the necessity to cast a method to a generic delegate defined in the class in order to, for instance, subscribe callbacks to events belonging to sub-classes inherited by the object instantiated by the Constructor Node.

So far LabVIEW efficiently allows to subscribe to events, registering a VI as callback in case the event involved is fired, but does not allow to cast a VI to a generic delegate and that's very limiting.

The only workaround existing is to wrap the C# library, adding an additional C# layer that instantiates the delegates on behalf of LabVIEW and then exposes plain methods, properties and events that are straightly callable by LabVIEW itself.

The idea is to allow LabVIEW to instantiate generic delegates based on the definition of the delegate provided by the C# library and return the delegate object so that it can be provided as input to library's methods requesting it.

This feature would make the LabVIEW integration of C# dlls more solid and completely manageable within LabVIEW code without further wrappers needed.

Expand XML capabilities & examples

Just recently ran into an issue with XML namespaces where the LabVIEW implementation just didn't cut it. The AE had R&D confirm this too. The work around, after trolling through the vast sea of .NET XML features & forums, was there. Something this simple shouldn't burn up this much time.

The world around us uses JSON & XML extensively yet the examples are minuscule. It doesn't matter if new examples are .NET, Python or something else but we need to get to solutions quicker.

View All (2)

Hello,

I just had a call with a customer that have a problem:

we cannot install multiple version of drivers to develop applications with different driver versions.

This problem happens to our partners.

Example:

I have a customer that want to uses LabVIEW 2014 and another one that uses LabVIEW 2017. So I would like to make a project with 2014's dependencies and another project with 2017's dependencies.

So the idea is to manage the dependencies in the project itself.

Best regards,

Antoine

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.

Zip Format 1.png

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.

Zip Format 3.png

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.

Zip Format 5.png

It would be nice to improve documentation created by Tools->Import->Web Service... wizard.

Especially, I suggest to automatically create Description in created .lvlib Documentation so that it would be immediately clear which WSDL URL is handled by that library. Currently, WSDL URL is only placed as a String constant in Open Web Service.vi which is not really convenient.
Thanks for understanding and support.

My tools are technical facing, and I use math. Instead of ASCII only, a "markdown friendly" version of MathJax, something that allowed me to write clean equations, would be useful.

instead of writing

"sin(x^2) e1 +cosh(1/x) e2"

I could enter the text

"$sin\left(x^2\right)\hat{e}_1 + \cosh \left(\frac{1}{x} \right ) \hat{e}_2$"

which is LaTeX in a wrapper

And I would see displayed this:

LaTeX is deep and wide, developed for decades, nicely licensed, and supported well in academia.

Some linkes:

View All (4)

provide a means to see dotnet or externall dll documentation in Labview

Ie
/// <summary>
/// the file location where the data is to be logged.
/// </summary>
private string _path;
/// <summary>
/// the file location where the data is to be logged.
/// </summary>
public string Path
{
set { _path = value; }
}

ie to be able to see the following
“the file location where the data is to be logged.”
when the property node is touched In labview

I very much like being able to export a labview.vi to a .dll or .net interop library .dll. Our higher level automation is in C# and having access to labview.vi via .net .dll is great. However, the current build capability only allows a single prototype/method to be created. Consequently, I have to provide every input/output when invoking this single method. This can work but it's just inconvenient and not as obvious as being able to create multiple methods smaller things, e.g.

write setup values

write DAQ sample rates

start storing samples

stop storing samples

stop DAQs

write summary info

When I create a C# class, I can create any number of methods or properties to manipulate class data members. Exported labview.vi files should enable this too. NI AE said I could create parent.vi files (setup.vi, write_DAQ.vi, etc) that all include the actual vi of interest. These various vis could be added to the exported .vi list. And, this would indeed be a work around. But, this is a hack to get around this problem and the AE agreed. Instead, I would like to be able to define multiple methods/prototypes on a single exported .vi.

Set exe to run as admin

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

Greetings,

I recently took the NI Instrument Control class and we came to the topic of creating a VI tree.vi.

It didn't make sense that we needed to update the VI tree.vi AND the palette when we add or delete a VI.

I propose that there should be an option to auto-make a VI tree.vi or just a simple html page with the available VI's in your project/driver.

This currently makes sense since all the VIs should already be categorized in the palette.

Thanks,

-Jose

View All (5)

Many times when wanting to share a VI Snippet on a discussion forum to quickly demonstrate a suggestion, I find it tedious to save the snippet to a temporary location, then go to the webpage, navigate to the location and upload the image to add it to my reply. I think it would be very helpful to have the ability to configure the VI Snippet to automatically upload to an online image host (imgur.com for example or even an NI solution) and put the link on the clipboard. Then it's ready to paste into the reply. Other desktop screenshot applications already have this functionality (see ShareX (formerly ZScreen) ). The purpose of VI Snippets is largely to facilitate this exchange of small portions of code and this would simplify the process greatly.

Dialog for custom search results

View All (5)

LabVIEW Idea Exchange

LVM API

Too Many Updates to Run-Time Engine!

Add support for [INSTALLDIR] and [DISTROOT] for Packages

Generate Python code in Vision Assistant

Add command line options to LVMerge

Change XNode development to use an INI key rather than a license, and open the XNode development forum to the public

Instantiate VIs as generic delegates when working with C# libraries

Expand XML capabilities & examples

"cross-compilation" with labview

Use ".vip" in LabVIEW, like ".jar" in Java

Imported WebService Automated Documentation

LaTeX in text - use MathJax - for both front panel, and for annotation.

support embedding labview plots in powerpoint

provide a means to see dotnet or externall dll documentation in Labview

Ability to define more than one prototype/method for a single exported labview .dll

Set exe to run as admin

Auto-populate the VI Tree for Instrument Drivers

Add ability to auto-upload VI Snippet to online image host.

OpenG should be installed with LabVIEW by default

Dialog for custom search results