Ask for suggestion about communicating between a VI and a dynamic

[Thang Nguyen]

Hi,

In my project I have one Main VI called A, and a dynamic VI called B. To pass data continously from A to B I use set variant control value node. To generate event from A to B, I send a reference of a boolean and use the register event node connect to event dynamic registration in B and set the value(signal) in A. To generate event from B to A, I also send a reference of a boolean and use the register event node connect to event dynamic registration in A and set the value(signal) in B. Do you think I did right or not? Is there any better way?

Thanks,

[LAVA 1.0 Content]

QUOTE (Thang Nguyen @ Oct 28 2008, 10:11 AM)

Hi,

In my project I have one Main VI called A, and a dynamic VI called B. To pass data continously from A to B I use set variant control value node. To generate event from A to B, I send a reference of a boolean and use the register event node connect to event dynamic registration in B and set the value(signal) in A. To generate event from B to A, I also send a reference of a boolean and use the register event node connect to event dynamic registration in A and set the value(signal) in B. Do you think I did right or not? Is there any better way?

Thanks,

My first thought would use a queue to pass the data. Since it looks like you understand how to set a control using the "Set control" method, just create a queue and pass the reference to the dynamic VI before you start it.

Ben

[Thang Nguyen]

QUOTE (neB @ Oct 28 2008, 11:29 AM)

My first thought would use a queue to pass the data. Since it looks like you understand how to set a control using the "Set control" method, just create a queue and pass the reference to the dynamic VI before you start it.

Ben

With the queue I have to wait for the time out to dequeue. In my dynamic VI B, I have an event structure. It maybe affect to each other. It will be the same with notifier. Maybe I don't know how manage them well.

[jdunham]

QUOTE (Thang Nguyen @ Oct 28 2008, 09:43 AM)

With the queue I have to wait for the time out to dequeue. In my dynamic VI B, I have an event structure. It maybe affect to each other. It will be the same with notifier. Maybe I don't know how manage them well.

You shouldn't need to wait for timeout. Main VI A should open the queue and drop your values in. Dynamic VI B should open the queue and start listening, and there should always be something in the queue. You can use a zero timeout and throw an error if the queue was empty, because your queue should always have the parameters waiting in it. We start all of our cloned dynamic VIs this way. The Dynamic VI should force-destroy the queue, because if you let the Main VI Close the queue, then it may clean up the data before the dynamic VI can receive it.

[LAVA 1.0 Content]

QUOTE (jdunham @ Oct 28 2008, 11:57 AM)

...The Dynamic VI should force-destroy the queue, because if you let the Main VI Close the queue, then it may clean up the data before the dynamic VI can receive it.

Yup!

Reciever kills the queue. If there was an error trying to add something to the queue, it indicates the recipient is not listening. This lets the Q-er know early there is nobody listening.

Ben

[Thang Nguyen]

How do you think about my event structure with the solution of using register node? Is it fine?

[PaulL]

QUOTE (Thang Nguyen @ Oct 28 2008, 10:58 AM)

How do you think about my event structure with the solution of using register node? Is it fine?

This is quite similar to what you can do with shared variables. I think what you are doing is fine, but as I've been reading this topic I keep asking myself, "Why not used shared variables?" There are pros (networked communication with logging and alarming built in) and cons (one of which is that one needs the DSC module for full functionality) but I think a mention of this solution belongs here.

[Thang Nguyen]

QUOTE (Paul_at_Lowell @ Oct 28 2008, 01:08 PM)

This is quite similar to what you can do with shared variables. I think what you are doing is fine, but as I've been reading this topic I keep asking myself, "Why not used shared variables?" There are pros (networked communication with logging and alarming built in) and cons (one of which is that one needs the DSC module for full functionality) but I think a mention of this solution belongs here.

Yeah, I did work with DSC before. But we don't want to buy it. Just use fundamental features of LabVIEW.

[jdunham]

QUOTE (Thang Nguyen @ Oct 28 2008, 10:58 AM)

How do you think about my event structure with the solution of using register node? Is it fine?

I'm a big fan of notifiers. To me they seem easier than dynamic events, but if you already need the event structure it's probably a good solution. I don't really like to mix the GUI code with the process messaging code.

[Thang Nguyen]

QUOTE (jdunham @ Oct 28 2008, 01:21 PM)

I'm a big fan of notifiers. To me they seem easier than dynamic events, but if you already need the event structure it's probably a good solution. I don't really like to mix the GUI code with the process messaging code.

The dynamic VI is actually a Map with an image of vehicle which the position is updated continously from the Main VI. The user can interact with this VI also. That is the reason why I need to use the event structure as well as receive the data continously from another VI.

[jgcode]

QUOTE (Thang Nguyen @ Oct 28 2008, 11:11 PM)

Hi,

In my project I have one Main VI called A, and a dynamic VI called B. To pass data continously from A to B I use set variant control value node. To generate event from A to B, I send a reference of a boolean and use the register event node connect to event dynamic registration in B and set the value(signal) in A. To generate event from B to A, I also send a reference of a boolean and use the register event node connect to event dynamic registration in A and set the value(signal) in B. Do you think I did right or not? Is there any better way?

Thanks,

Hi Thang

If you are just going VI to VI all you need is for vi B to run a FGV that accesses the queue for vi A and queues method(s) into it (Queue Manager).

Therefore this approach may be the easiest also if you require high speed updates.

In fact if vi A did all the processing and vi B was just displaying a point(s) on the map you could queue directly into a display loop (if you have one).

I use the above when I know exactly:

1. Who/where I want to send the data to and

2. I know 100% that this vi is in memory.

3. For within VI loop-to-loop messaging.

But when I don't know, I use use events.

IMHO events are the king at doing this, so what you are doing is great however, an event manager might help with flexibility and scalability in the future:

I do the above in most medium size apps that have a GUI.

I have a main template that stays in memory all the time.

It hosts the RTM, toolbar, status bar and a subpanel.

Dynamic VIs are loaded into a subpanel (serially loaded) that go in and out of memory.

I also have other screens that can be loaded at any time (e.g. setup screens, data screens) that are generic where any Dynamic VI may want to call them in parallel.

I prefer to have these other screens not to be dynamic and are in memory with the template at all times (I just show/hide FP).

But the below will work the same.

About me:

I prefer events to polling.

I like to think of a screen as an object.

I use type-def enums a lot.

I like polymorphic VIs

This is how I have implemented communication.

I call it publisher/subscriber cause that is the easiest way to describe it - but you can call it want you want

When the user changes data on a screen (e.g. selects a plot color in settings-type screen) I need to notify every other VI that is using that object data that it needs to update.

To not do this via events and use polling is inefficient IMO

Also as in this example a plot color change would cause a graph to have to update (which is expensive) I want to know exactly when this happens.

In order to pass data to and from VIs I create a MFVI\Module that handles all events registering.

The event is dynamically registered to all VI's GUI loop.

So all VIs can potentially receive each notification however, you have to statically set which ones it is allowed in the event structure.

This method is easy, flexible and scalable. I do not have to know what is in memory (e.g. by loading to a specific queue(s) manager etc.. - is the queue is memory is it not?).

So when you have 10-20+ VI's with screens this is great.

In the figure above - vi B is subscribed to an event from vi A

The data passed is an enum. Which means the setup can publish an infinite number of messages.

In this case there is only one message in the enum, but use the NewVal input wired to a case structure so you can choose which published messages to listen to and then load different local methods.

Once vi B receives the message in it's GUI loop it loads its own state in a parallel main (working) loop (by using a Queue Manager via a FGV approach for loop-to-loop messaging)

This state accesses vi A's object data, & vi B then updates its local temp data and runs any local methods it needs (e.g. update plot colors) [not shown]

The biggest reason for me going this way was:

1. To share the RTM, button toolbar with all VIs from the template VI.

2. Communicating with screens in parallel - the user can potentially have open the main app, setup screen, admin setup screen, calibration screen, plot-manager-for-graph screen etc.. at the same time.

So as soon as one screen is changed that another screen is dependent on and its in open (but you con't need to care either way), the dependent one updates immediately.

A more efficient way for the above method that I have taken from the release of the JKI state machine (thank you) is to include the UI Structure in EVERY main loop.

As having the GUI receive a message then load a state in parallel to a main loop I have recently come to see as it a bit of a wasted two-step process.

Also any QSM's running in the background headless can receive notifications without needing to have a GUI loop in parallel.

But i have not implemented this yet into my template.

Check out the JKI SM which uses strings and and an event structure here

[Thang Nguyen]

Hi,

Could anyone please give me an example of a OOP template with dynamic process? I created one but I don't think that it is good enough. It has a queue to send data to the dynamic VI which is a private function of the object. This dynamic VI have a state machine and a dequeue VI in the default state to get data which include a command message. Depending on the command message it will drive the state machine to the correspondent state or just waiting at the default state. The issue is the time frame is not fashion in this VI. It based on the command and the data. What I want is the dynamic VI always run at 200ms rate with a certain task and other option tasks.

Best regards,

Thang Nguyen

[PaulL]

Thang,

In OOP terms I use and like the State Pattern, which works quite well. As far as timing my controller does what it does and just changes state in response to triggers. The controller is ready for a new command at pretty much any time, since the operations it takes directly in response to state changes can execute quite quickly.

Paul

[Thang Nguyen]

QUOTE (Paul_at_Lowell @ Nov 3 2008, 02:54 PM)

Thang,

In OOP terms I use and like the State Pattern, which works quite well. As far as timing my controller does what it does and just changes state in response to triggers. The controller is ready for a new command at pretty much any time, since the operations it takes directly in response to state changes can execute quite quickly.

Paul

Paul,

Could you please tell me more detail about the State Pattern? Could you provide me any example of it?

Best regards,

Thang

[PaulL]

QUOTE (Thang Nguyen @ Nov 6 2008, 03:14 PM)

Paul,

Could you please tell me more detail about the State Pattern? Could you provide me any example of it?

Best regards,

Thang

The essence of the State Pattern is this: State Pattern Diagram. (The best reference is GoF Patterns Book, and another user-friendly guide is Head First Design Patterns.) I should write a good example I can post on this forum sometime, but in words:

We have a Context, maybe a device, that has certain states. It responds to external signals according to the current state, and may change states as a result.

Create a class for the Context. Then create a State class and then child classes representing the individual possible states. Each state inherits from the State class. (A hierarchy of states is possible so you can have superstates and inherit behavior.)

Now set up a way to respond to external signals (e.g., an Event Structure). When an event occurs, call a corresponding method on State (e.g., turnOnDevice) that is implemented in the child classes (you can have default behavior in State). This is a dynamic call that depends on the which descendant of State is on the wire. The methods always output the state (same or different) for the next iteration.

Hmm.... I can see an example would be helpful. Unfortunately, I can't make one today, but I should take some time to do this soon....

[Thang Nguyen]

Paul,

Thank you for your answer. I guess I did something simular which is a class with a private thread created by a dynamic call VI. This VI has a state machine which the state is designed base on the input data. This class is a call by reference and the data communication is implemented by a queue name. What I wonder is the state machine itself will affect to the real time requirement. I just worry about the performance of this pattern. I did use this pattern in a data acquisition system and when the rate requirement is high, the performance of this pattern will be limited.

Best regards,

Thang