LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

XControl publish subscribe?

Solved!
Go to solution

Hi all

 

I'm trying to implement a publish subscribe messaging pattern using XControls and LVOOP.

 

I have various XControls which represent different views of the state of an object.

 

I want all my XControl (clients) to be updated when the object (publisher) changes its state.

 

I've achieved this sort of functionality before using VI's running in sub-panels that wait on a user event created by the publisher.

 

I gather dynamic events are not available with XControls, so have tried to create a list of XControl clients that could be notified by a XControl method call.

 

I've found a way of notifying individual clients by creating a method that fires the Display State ability but really want to manage all the XControls as a collection.

 

An array can't seem to store references for the XControls as each is a different type.

 

I've also tried using a Data Value Reference for each XControl reference hoping that this generic type could be stored in an array but no joy.

 

The only way I've found is for the main vi to register for the publisher user event and then call the notification method of each XControl explicitly.  This messes up the main vi and is not an elegant solution.

 

Does anyone know a way of achieving my desired functionality?

 

Thanks in advance for any responses!

 

Phill

 

 

 

0 Kudos
Message 1 of 16
(5,096 Views)
Solution
Accepted by topic author tadders

One bad way - you can create a daemon for each XControl which will register for the event and then use the Value(sgnl) property to trigger an event in the facade VI. See here for an example. You might also be able to do this with a single central daemon, but I'm not sure if it will be allowed to change the value of a control on the facade.


___________________
Try to take over the world!
0 Kudos
Message 2 of 16
(5,081 Views)

Hi tst

 

Thanks for the reply.

 

Your suggestion may work, but there would still be a very high coupling between the daemon and the XControls.

 

Any daemon, class or vi needs to store different types of XControls in a collection and be able to process the client list without bothering what type of client it is notifying.

 

Phill

0 Kudos
Message 3 of 16
(5,073 Views)

I had a similar requirement and made a stab at it: https://decibel.ni.com/content/docs/DOC-16947.  My solution was an abstract class from which all XControl types inherit.  Each XControl type (object) implements in its override VI.

 

Steve K

Message 4 of 16
(5,023 Views)

Hey pie,

 

Thanks for your input.

 

I ended up with a similar solution, except I pass an objects state to the XControl using a Data Value Reference to the class.

 

P

0 Kudos
Message 5 of 16
(5,003 Views)

What a pity

 

all I needed was a reference to my xctrl (that converses with the other outerworld as BOOLEAN) to be downgraded as BOOLEAN and value set as a common boolean. No methods, no extra properties.

 

 

Somehow it should be possible to convert that reference to the data type the xctrl looks to others.

 

A class with a FP..... but Xctrl is it not.

 

Gabi

 

 

7.1 -- 2013
CLA
0 Kudos
Message 6 of 16
(4,842 Views)

GabiTillmann wrote:

Somehow it should be possible to convert that reference to the data type the xctrl looks to others.


It's probably possible using Type Cast, but I don't think I would trust that in any deployed application.

 

I'm not sure whether I do or do not accept your argument. The Value property you want belongs to the Control class and you should already be able to cast to that. If you cast to the Boolean class, there's no reason to assume your XCtl will be able to implement all the relevant properties and to allow that cast just to support the Value properties seems a bit unnecessary.


___________________
Try to take over the world!
0 Kudos
Message 7 of 16
(4,822 Views)

Thanks tst

I have attached a little sample of what I thought might be nice.

 

I am building a P&I diagram out of DSC elements.

The valve will ultimatly get more properties like OPC tags, names etc.

I thought to attach the pipes to it so they get automatically activated, when the valve turns on.

But I guess that would require some extra programming anyway because there will be two endpoints on the sides of the pipe to control a flow.

 

Casting to more generic, even only a control, is obviously not possible. 

Hierarchy for Xctrl is also not provided, no inheritence.

Is there any another way to have a class with a Control style FP ?

 

I am still at the beginning of the project so I have more options to think of......

 

Gabi

 

 

7.1 -- 2013
CLA
0 Kudos
Message 8 of 16
(4,793 Views)

I don't have 2013 installed, so I can't look at your code (2011 is the most practical option for me at the moment).

I didn't understand the rest of your post without the code, so I can't comment on that.


___________________
Try to take over the world!
0 Kudos
Message 9 of 16
(4,787 Views)

Thanks again 

I attached a version in 2011.

But for the whole Project's benefit I think it's better to work with a class and an attached FP-Control instead of a Control with attached Code (like an XCtrl).

 

Gabi

 

 

You seem to be active early in the morning. Are you US based ?

Greetings from Germany

Gabi

7.1 -- 2013
CLA
0 Kudos
Message 10 of 16
(4,773 Views)