LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

Add a NIRG-compliant free text field

View All (1)

LabVIEW AF is a fantastic tool to create multi-threaded messaging applications the right way. It promotes best practices and help write big yet scalable applications.

I feel however that there is not enough included in the box 🙂 When looking at many other industry implementation of the actor model e.g. Scala Akka, Erlang, Elixir, microservices in many languages etc. you find that the frameworks usually include many more features. https://getakka.net/

I understand the decisions behind the design for AF yet would like to start a discussion about some of these.

I would like to see the following features being included into AF:
1. Ability to Get Actor Enqueuer by Path through hierarchy of actors e.g. /root/pactor/chactor could be used to get the enqueuer to chactor. This would probably require actors to have unique paths pointing to them. Having a system manager keeping all enqueuers on local system is not a bad thing. It is a good thing.

2. Ability to seamlessly communicate over the network and create your own queue specifications. For example actors should be able to talk between physical systems. Using the Network Actor is not a good solution, because it is simply to verbose and difficult to understand. The philosophy of AKKA should be embraced here "This effort has been undertaken to ensure that all functions are available equally when running within a single process or on a cluster of hundreds of machines. The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail."

3. Improved debugging features like MGI Monitored Actor being inbuilt. https://www.mooregoodideas.com/actor-framework/monitored-actor/monitored-actor-2-0/

4. Included Subscriber Publisher communication scheme as a standard way for communicating outside the tree hierarchy. https://forums.ni.com/t5/Actor-Framework-Documents/Event-Source-Actor-Package/ta-p/3538542?profile.language=en&fbclid=IwAR3ajPR1lvFDyPFP_aRqFZzxR4FCQXh2nB2z0LYmPRQlnvXnsC_GQaWuZQk

5. Certain templates, standard actors, HALs, MALs should be part of the framework e.g. TDMS Logger Actor, DAQmx Actor. Right now the framework feels naked when you start with it, and substantial effort is required to prepare it for real application development. The fact that standard solutions would not be perfect for everyone should not prevent us from providing them, because still 80% of programmers will benefit.

6. Interface based messaging. The need to create messages for all communication is a major decrease in productivity and speed of actor programming. It also decreases readability. It is a better with the BD Preview in Choose Implementation Dialog in LV19, but still 🙂

7. This is more of an object orientation thing rather than actor thing but would have huge implications for actor core VI, or Receive Message VI. Please add pattern matching into OO LV. It could look like a case structure adapting to a class hierarchy on case selector and doing the type casting to the specific class inside the case structure. You could have dynamic, class based behavior without creating dynamic dispatch VIs, and you would still keep everything type safe. https://docs.scala-lang.org/tour/pattern-matching.html

The natural way for programming languages to evolve is to take ideas from the community and build them into the language. This needs to also become the LabVIEW way. I saw a demo of features of LV20 and I am really happy to see that many new features were inspired by the community. Lets take some ideas about actor and add them in.

I wanted to share my view on the direction I think AF should go. I see in it the potential to become the standard way to do big applications, but for that we need to minimize the barrier to entry.

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.

Allow multiple event callback VIs

As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI. The only problem is that there can only be one Callback VI per LabVIEW installation. My suggestion is to allow more than one callback VI to be called when the events happen. This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.

This is similar to my previous idea, but generalized for all the callback VIs.

View All (5)

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)

Call Library Function Node

View All (2)

VI VIewer for mobile app

Since I'm working with LV-DLLs there is a very very annoying Bug. I just made my first tries in LV 2012 (up to now I'm using LV 2009) and I recognized that the bug is still there but an information/warning dialog opens now when it takes effect. With other words: The bug became a feature ;-( So it's time to make a suggestion for changing in the LV behaviour.

Here are the steps you have to take to reproduce the problem:

1) create a new, empty LV project

2) first create a cluster, store it as type def and add the type def to the project

3) create a new VI (called test) that uses this cluster as output (input will work, too). Add the VI to the project, too.

4. Create a DLL-Spec with this VI as exported function (sorry, I’m using a German LV):

5. Usually the default prototype is not the best. So we re-configure it like this.

Click to ok and store the project and all files.

6. Ok, last step: Building the DLL 🙂
– Ups, we forgot to change the element “n” inside of the typedef-cluster to U16 (it’s still set to double). But no problem – changing the typedef will correct the bug everywhere where the ctl is used.
Open the typedef, change and store it. Now re-build the bug-free DLL - finished! .. or not? No, you're not. Because you changed the type def LabView has reset the hard configured prototype to default *grmpfl*

Now you might say: “Hey, where is the problem, just re-configure it.”

Currently I have a single project which uses up to 25 DLLs created in LV. All are using the same data cluster typedef. Each DLL has approximately 10 exported VIs. This makes 250 prototypes I have to re-configure if there is just one little change within my cluster!!!

LV resets the prototype even if a VI-IO changes from “required” to “recommended” – a change that does not have any effect to the behaviour of the exported VI.

So NI, please change this “feature” to a real feature as soon as possible!

Meanwhile I have to go on using variant elements to send data to my DLLs and back.

Appended you'll find a very similar example. Don't forget to save the VI after you've changed the type def.

View All (7)

separate Vision and Motion palette

TDMS files generally come in pairs. There is the TDMS file itself which contains all the data and meta data stored in the file. And there is usually a tdms_index file. This is the file with the meta data in it, but not the actual data. The idea being that this index file is created from the original file, but since it doesn't contain all the extra data, it is faster to search through for a particular offset in the file to find something.

If a TDMS file exists in a folder without a tdms_index file, it will generally be created when calling the TDMS Open function. This means when DIAdem indexes it, or when Excel Importer opens it, or when Scout opens it, this index file is created. Often a useful way of looking at a folder of logs is to look at the Date Modified or Date Created and look at the newest. But if we are viewing a folder of TDMS files which don't have the indexes, as soon as we open one to view it, the index file will be created with the modified and creation date being set to right now. This suggestion is to have it be set to the same value as the original TDMS file. As always pictures are useful. Here is a folder of TDMS files sorted by the date modified.

Before Open.png

After double clicking that file the TDMS editor of choice opens it and the directory looks like this:

After Open.png

The index file is created, but since it has a newer mod date it moves to the top of the list. My suggestion is to have the index file have the creation and mod date set to the TDMS file so the directory will look like this after it is created:

Yes I realize you can write code to set this but I can't think of a reason why I would ever want to know what the date and time that the index file was created. I'm only interested in the data, not the index file. If this is implemented on the TDMS API side of things, then all tools that get made from that point forward will have the file modification set automatically.

Using Search Results in Scripting

View All (7)

NView, Alt+Tab order

Hi!

Especially in multi monitor setups NView provides some very convenient functions. LabVIEW and NView, however, don't play well together. That is: I have to disable NView to use LabVIEW properly. That's very annoying, as you can imagine.

So my suggestion is: fix it

I suspect, that LabVIEWs scrambling of the alt+tab order is part of the problem. So I'd like to see that fixed too. I mean, you already have a shortcut to switch between Frontpanel and Blockdiagram (Ctrl+E). Why additionally scramble the alt+tab order to get FP and BD side by side?

Best regards,

pktl2k

P.S.: I'm sure, users of not-NVidia graphics have similar trouble with their respective NView counterparts.

View All (2)

Project Quick Access

From LabVIEW Project, we can access the last modified files, from the menu File>Recent Files.

Recent Files1.png

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.

Quick Access1.png

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.

I was thinking that defining packed project libraries as the source of VIs used by the LabVIEW enviroment would speed up everything ex. loading LabVIEW, loading palettes linking dependencies, building executables etc. + solve linking dependecies conflicts.

The thing that we could do is just add the packed project library for the standard LabVIEW functions as the base of the palettes, but since we want users to be able to see what's inside we would still leave the VIs in the same folders - this way the user would be able to choose if he wants to use the packed versions or the versions from the disk - unpacked.

This way only the ones with a specific unpacked instance would have to be loaded as single VIs, and we would have everything nice and clean.

Tell me what you think.

View All (6)

Hello,

I often have to use report generation toolkit in order to generate EXCEL reports.

This is a very easy way to generate userfriendly test reports.

But, the API of the EXCEL report generation toolkit should be improved, in order to be abble to insert real Excel graphs in the excel sheets.

For the moment, when you want to insert a graph in Excel, this is done by inserting a MSChart object.

The problem is that a MSChart object is not an Excel graph !

There is no link between the data inserted into Excel and the MsChart graph object.

A MsChart object contain all the data necessary to draw the graph.

It should be interesting to had the ability to create real EXCEL graphs ... with a link betweend the data inserted in a sheet and the graph.

So it should be possible to have access to data modifications directly reflected on the EXCEL graphs.

Thanks a lot.

(And sorry for my approximate english)

Manu.net

View All (1)

LabVIEW Idea Exchange

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

Add a NIRG-compliant free text field

Align LabVIEW Actor Framework to other frameworks used in the industry

Instantiate VIs as generic delegates when working with C# libraries

Allow multiple event callback VIs

Expand XML capabilities & examples

Call Library Function Node

SubPanel in LabVIEW Getting Started window

VI VIewer for mobile app

Build shared library (DLL) - Define VI prototype: Allow content of cluster (type def) to be changed without resetting VI prototype.

Provide an option to drop while loops with different colors - Randomize Color of Loops

separate Vision and Motion palette

Set TDMS Index Mod Date to TDMS Mod Date

Using Search Results in Scripting

NView, Alt+Tab order

Project Quick Access

Pack the existing LabVIEW functions to Packed Project Libraries to speed up EVERYTHING

Allow VIs to attach to forums post with option "separate compiled code" set

add hardware support for side scrolling mouse button

Report Generation Toolkit should create EXCEL Graphs, not MsChart objects !