approach to syncronise data between 2+ VIs

[Bob_Schor]

UDE = User-Defined Events, Tim might be Crossrulz's first name (I, myself, am unsure of Crossrulz' non-Forum identity).

Bob Schor

[crossrulz]

---

Bob_Schor wrote: Tim might be Crossrulz's first name (I, myself, am unsure of Crossrulz' non-Forum identity).

---

It's not much of a secret: https://decibel.ni.com/content/docs/DOC-26476

[crossrulz]

---

Vasilich2004 wrote:

So if you would add next VI then you will must update all VIs! It means you try to support MxM matrix!!! Good luck 😉

---

Which is exactly why I would use User Events.  When you make a new VI, it just registers for the User Event and then everybody gets the event.  To make it really safe, add in an element to the cluster for the event to say who sent it.  That way a VI can just get the event but do nothing if the sender of the event was itself.  Then you just need 1 event for everybody.  No need for a matrix.

[Vasilich2004]

I made way which uses Event per Device. Disadvantages:

- if dialog uses one control out of N controls it will be fired Event in M dialogs

- any change in Device will require changes in each M dialogs

- I don't know how easy to avoid firing event in dialog which send the Event.

If I would use Event per Device control then I will need to take care about a lot of Events ...

I don't think that looks well ...

[crossrulz]

---

@Vasilich2004 wrote:

I made way which uses Event per Device. Disadvantages:

- if dialog uses one control out of N controls it will be fired Event in M dialogs  So?  You want those other M-1 dialogs to update that value, right?  As far as recieving other controls, not a big deal,  You just have the default case do nothing and the event structure will be done super fast.  We are dealing with GUIs here.  They do no need to be fast.

- any change in Device will require changes in each M dialogs  Don't you already have this problem?  SubVIs can help A LOT here or you can just have seperate modules also recieve these events and do whatever communications is required with the device.  So all of your device control should be in one location.

- I don't know how easy to avoid firing event in dialog which send the Event.   Again.  GUIs are slow.  Not a big deal.  If you follow the advice from the second bullet, really not a big deal.

---

[Vasilich2004]

Dialogs don't use all parameters. For example, if Device dialog has 10 parameters and each of 10 dialogs uses 1 parameter which are different then

- there are 10 times more event processing

- I don't see how to make single SubVI. It looks SubVI should have output per parameter but Device dialog could have 10-20-30 parameters.

By the way, UI is slow but it could use a method where a loop, for example, can change stepper motor position once per 20 mc. Of course, it is possible to "disable" event but it will bring additional complicity ...

[Vasilich2004]

Hi!

I created more realistic exampe (see attachment). Is it possible to have simpler system?

Thanks, Andrey.

[Vasilich2004]

When I started to apply the Event approach in my program I met couple issues and made changes. Now system has Device with 3 parameters Double, DoubleRb, Integer) and 2 Dialogs which controls subscribe to parameter events.

There are 2 issues

1. as I wrotre before if parameter name (Double, DoubleRb, Integer) would be cnanged then all subscribers must be changed. 

2. all dynamic events have the same name "<Event>:User Event" in Event structure.

[beccamir]

Vasilich2004,

What do you mean by subscribers? Could you ellaborate more on the 2 issues you are having? Are you getting errors? Is it not functioning as expected? If not, how?

For more information on dynamically registering for events see this resource: http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/dynamic_register_event/

Also some general suggestions:

1. If you comment your code, it will be easier for the community to follow and understand what you are trying to do.

2. Placing your files in a LabVIEW project can really help with organization of your files (http://www.ni.com/white-paper/7197/en/)

Hope this helps!