1


I have a .Net 4 control /.dll which I am using with LabVIEW.

The control exposes the following event: 

    public delegate void CommNewDataEventHandler(UInt16 u16StageGroup, UInt32 u32Status , string [] strNewDataTitle, float[] fNewData, string[] strNewDataUnit);
    public event CommNewDataEventHandler CommNewDataEvent;

What I would like to do is subscribe to this event within LabView and update a numeric indicator with the value specified in float[] fNewData. What is the correct way to do this?

current VI callback VI

drone
  • 53
  • 7

2 Answers2

2

There is no "correct" way to do this, but you can put code in the callback VI to pass data to where you need it.

For example, you can pass the control reference as the user parameter (this is the terminal on the register node and the control on the FP) and then use Variant to Data to convert it back to a reference (edit - you don't need to convert if you create the VI after wiring the data into the node) and use the value property. This is inelegant, but it will work.

A more elegant solution would be to pass a user event of your data type to the callback VI (for instance, as the user parameter) and then generate that event with the data you got. This is more cumbersome, but less hidden.

Like so (ignore the missing horizontal wire. It must have blinked when I took the screenshot, but it's there):

.NET LabVIEW event callback example

You can find the image here if imgur takes it down: https://forums.ni.com/ni/attachments/ni/130/16266/1/event%20callback%20example.PNG

Yair
  • 2,266
  • 12
  • 12
  • Is there an example of what is recommended in the last paragraph? I'm a LabVIEW novice, but I know C# well. – Kevin S. Miller Jun 04 '19 at 15:14
  • 1
    There's a very similar example using a notifier in the other reply, but for completeness, I added one with a user event. – Yair Jun 05 '19 at 05:15
1

As the previous poster has suggested, there is no "correct" way to do this. There are a number of different approaches you might take depending on the scope of your project. For the general .NET event registration and handling procedure NI has a good example here: https://decibel.ni.com/content/docs/DOC-9161

This sample code is a "timer handler" (using a native .NET timer API) and illustrates how to register for an event and create your callback VI. Let's modify this to achieve your goal. To do so, we must somehow communicate through our callback VI to another part of the program (containing the numeric indicator we want to update). Options for establishing communication between seperate parts of our application:

  • Global variables
  • Functional global variable
  • Control/indicator references
  • Structured synchronization mechanism (i.e. queue, notifier, etc.)
  • Messaging system (i.e. UDP via local loopback, managed queues, etc.)

There are many, many options and this is certainly not an exhaustive list. Every approach has advantages and disadvantages and your decisions should be based on what kind of application you are writing. Note that some are better style than others. My preference (when writing fairly simple application) would be to use something like a notifier for a single point data update. My opinion is that this offers a good amount of flexibility/power and you won't get knocked for style points.

Below is a modified version of NI's example program using a notifier to pass the data from the callback VI to the top level VI. When the event fires, the callback pushes some data onto the notifier to signal to the top level VI that the elapsed time has expired and the event has occured. The top level VI waits for the notification and uses the provided data to update the value of the numeric indicator.

Note that this is a very trivial example. In this case I don't really even have to send any data back. I know that if the notifier does not timeout that the event has fired and can subsequently increment my counter in the top level. However, the notifier allows you the flexibility to stuff arbitrary data in the communication pipe. Hence, it can tell me "hey! your condition occurred!" and "here's some data that was generated".

Callback VI

callback

Top Level VI

top level

If you are writing a larger application, your loop to monitor the notifier can run in parallel with other code. Doing so allows you have an asynchronous mechanism for monitoring the status of the event and displaying it on the GUI. This approach allows you to monitor the event without interfering with the rest of your application.

Kin3TiX
  • 708
  • 1
  • 5
  • 18