Multiple UIs connected to one target

[MarkCG]

Hi all. Is it possible to have multiple UI instances interacting with one target? I have not delved deeply enough to figure it out for myself but I though I would ask before I commit myself too deeply to using the framework. 

[johnboydni]

The short answer is yes!

I'd like to know a little bit more about your application before giving specific advice.

Will your UIs be running on the same host? Or multiple hosts?

[MarkCG]

Multiple hosts. Basically two operators will be controlling at once! They will each control separate subsystems of the apparatus 

[BeCeGa]

Hi Mark especially for remotes systems you must be careful with having more client controlling the system at the same time, to actual hardware. As John mentions depending the application there are multiple ways to do it and the best one would depend on your application.   The 2 more common ones are either using tags for communication or messages.
  If you go with the tags approach, what you will do is you create 2 instances of the communication module, one for each interface. In this case, you could use the UDP module to send and receive information from both. This will manage the communication to both clients and allow them to be receiving updates.
 The critical part comes in the writing the values to the system. You don’t want operator one telling the system to go right while the other is telling it to go left. In systems that are controlling hardware this is a safety issue.  Because of this DCAF is designed with a single writer for a tag.  For example, if you have the tag DO0, you can’t have both modules writing directly to it.  To allow both modules to write to the tag, you will need to create a module that reads the 2 possible sources (UDP1 and UDP2) and selects which is actually writing to the output. An example of this is the Tag Select Module. 
  The main advantage you get with this is that you can explicitly arbitrate data going into your system. In most cases the recommended practice is that you have a lock and the panel that currently has the control lock is the one controlling the system. While this protects the writing, both can still receive updates from the system.  In this cases is also good to have some way to override the lock or have a timeout, in case something happens to the terminal that has the control of the system.
  When talking about messages you will still need to arbitrate who is writing to the module but in this case both clients write to the same module.  An example of this could be JSON RPC module. Still is important to do the arbitration but in this case this the arbitration and the communication are inside of the same module.
Best Regards

[MarkCG]

Thank you Benjamin this does clarify things quite a bit.  Yes I immediately was thinking of the mechanisms to prevent two users from inadvertently trying to control the same thing at once. It sounds like the Tag Select Module is the way to go. In fact it will be a little more complicated than just one user taking control of the whole thing- I am going to split up the system into subsystems, each represented by a particular tab in the GUI (actually a VI in a subpanel). Each tab will have some icons to show locked/unlocked status and to assert and release a lock. Control buttons will be grayed out and disabled when a particular panel is locked. 

There will be a few command type actions the system will need to do so I will really be dealing with both types if methods for dealing with multiple users. 

[MarkCG]

One thing about using the tag select module is that it seems to limit you to only two possible users- what if you need to select between 3 sources? Gets a bit trickier there

[BeCeGa]

If you need more users, you can extend or create a new DCAF module using the Tag Select as a starting point. In here if you have 3 you might also want to add some additional logic to the module to handle permissions.

 The general concept is the same regardless of how many clients you have. 

• an input to channel select which input is being mapped to the output. (In here you could change it from Boolean to numeric, some of the base code in the runtime already supports arrays.
• multiple inputs channels mapped to the tags coming from your clients
• outputs channels that are writing to the final tag

Specific to your application you could add control timeouts to prevent a client that is not connected to keep the permission.

Best Regards

[MarkCG]

Thank you. Yes the tag select module does look amenable to being modified to use numeric to select tags. The select index could be a numeric instead of a boolean. Although making a configuration VI interface will be some work.

[BeCeGa]

It would depend on how many Clients can connect. If we go with the example of 3 clients as you were mentioning, you wouldn't need to many changes, you would need to add an extra column for client 3, and its override (which is a copy of the inputs are but using a different index. 

If you are expanding this to a bigger number of clients, you could create a module that manages all the clients and just outputs the right value. This will be a good use case for a webservice, the module will receive information from the different clients, and internally will filter what information is publish as a tag for the rest of the system.

Best Regards