LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (1)

LVClass By Reference Features

Property nodes for LVClasses are a tease, this is what I really want:

Invoke nodes that correctly wire call dynamic dispatch by value VIs (this includes the ugly wireing of the "preserve runtime class" inside the in place element structure. Its ugly, just obfuscate it for me.

References to Data value references that correctly respond can use the "to more generic" and "to more specific" class so that I have the DVR to the more specific.generic class REFERENCE.

Justification for Invoke nodes:

I work with lots of different Classes, and libraries. I can quick drop alot, but I do not know all the publicly exposed functions in a give class especially since 90% of the time it is still in development. Generally a pallete won't see the light of day in internal development (somewhat of a pain to make/maintain, definately not a single click operation), so getting the correct methods involves paging back and forth between the project explorer, this is slow. I want to code quickly, if I can have the Public api exposed by an invoke node it means I dont' ever have to make a pallete of VIs (we can argue over this all you want, it just isn't simple/fast enough) and I can access the functions much more easily/quickly. Even if every class had a pallete, it would still be inferior to the invoke node solution because A.) I have to remember where every pallete is. B.) Sharing/installing pallete changes for other developers is PAINFUL. I want to give them a zip file that they can chuck anywhere. I sure do not want to make a scripting function to update there palletes, so it requires file moving/installation/making sure they actually put the class in the right folder (which someone will always do wrong and invariable cause me to right arrow enter 1000 times when I receive their project.)

View All (6)

It would be nice if you can define a webpage or email address for bug reporting in a VI or library, that you could set under File->VI Properties before you distribute a library/device driver, etc.

If this address is set, labview could automatically add a menu entry "Report Bug/Feature Request" in the Help menu that takes you to a webbrowser or a email client with some preforumlated text, e.g. subject: "[Labview Bug Report] <VI name> <VI version>".

This way one wouldn't have to start browsing the web frist to figure out where to report problems.

It would also be nice, if one could set this once for a complete project and all VI would inherit this from the project they belong to.

regards

Arun

View All (3)

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

Managed way to get Class Properties

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.

LabVIEW Idea Exchange

More error messages for the DLL import

LVClass By Reference Features

easier bug reporting for (downloaded) VI's

LVM API

Too Many Updates to Run-Time Engine!

Managed way to get Class Properties

Mass Compile Should Optionally Override Save Version

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