Command/Response - Monitoring parameters subscription on UI

# 8 years ago
TCS_GMRT	Hi Everyone, Need your suggestion for scenario mentioned below. We are having multiple independent Tango DS (IO-DS) which are interfaced to external hardware(s) to perform IO operations. Each of these DS receives multiple parameters in a single response. These parameters are required to be displayed on client UIs ( there can be <n> UI instances for same purpose). From UI commands can be sent to these device servers (IO-DS) but only through an additional device server i.e Level-1 DS ( command orchestrator). We need your opinion/suggestion to decide if these UI clients should directly subscribe to these multiple IO-DS for their IO response parameters or same Level-1 DS should be used to get response parameter. There would be approx ~100 monitoring parameters from single IO-DS which would required same number of Tango attributes. All these DS ( all IO-DS plus Level-1 DS ) would run on same computer. Attached is the diagram showing arrangement of essential components for reference. Thanks! Regards, TCS_GMRT Attachments:

# 8 years ago

Hi Everyone,

Need your suggestion for scenario mentioned below.

We are having multiple independent Tango DS (IO-DS) which are interfaced to external hardware(s) to perform IO operations. Each of these DS receives multiple parameters in a single response. These parameters are required to be displayed on client UIs ( there can be <n> UI instances for same purpose). From UI commands can be sent to these device servers (IO-DS) but only through an additional device server i.e Level-1 DS ( command orchestrator).

We need your opinion/suggestion to decide if these UI clients should directly subscribe to these multiple IO-DS for their IO response parameters or same Level-1 DS should be used to get response parameter.

There would be approx ~100 monitoring parameters from single IO-DS which would required same number of Tango attributes.

All these DS ( all IO-DS plus Level-1 DS ) would run on same computer.

Attached is the diagram showing arrangement of essential components for reference.

Thanks!

Regards,
TCS_GMRT

# 8 years ago
Ingvord	Hi, Here is a description how we deal with the similar situation at DESY. Our group operates several beamlines and for them we are developing a control system. Essential part of the system is to collect data from hundreds remote tango devices (the major difference from your scenario here - is that we read 1-2 attributes from each device, but in the end total number ~250). So this was quick introduction and the solution: We have developed an intermediate tango server (StatusServer) which collects all the data and serves as a cache. So each time we need an update we just take data snapshot from the StatusServer and display it. You can also setup a periodic event to get updates regularly. This solution is also nice if UI can dynamically change itself, so you only need to change StatusServer configuration to add or remove protocoled data. If you develop in C++ you can also benefit from broadcasted events Hope this helps a little.

# 8 years ago

Ingvord

Hi,

Here is a description how we deal with the similar situation at DESY. Our group operates several beamlines and for them we are developing a control system. Essential part of the system is to collect data from hundreds remote tango devices (the major difference from your scenario here - is that we read 1-2 attributes from each device, but in the end total number ~250). So this was quick introduction and the solution:

We have developed an intermediate tango server (StatusServer) which collects all the data and serves as a cache. So each time we need an update we just take data snapshot from the StatusServer and display it. You can also setup a periodic event to get updates regularly.

This solution is also nice if UI can dynamically change itself, so you only need to change StatusServer configuration to add or remove protocoled data.

If you develop in C++ you can also benefit from broadcasted events

Hope this helps a little.

# 8 years ago
Andy	Dear TCS, here is my 2 cents on this question: TANGO allows you to use both paradigms. It depends on the amount of information to send, the level of filtering you want to do, and the number of clients etc. At the ESRF we usually create higher level devices which regroup the information coming from the accelerator control system into higher level devices which act as facades for the control systems running the experiments. This allows us to present only the information required for that experiment to the experiment control system. It also make it easier for the experiment control system clients because they access only one device where they get all their information. Requests are also sent to this facade device. With Tango9 you could use forwarded attributes to make attributes visible from one device to another device. If you need to access the low-level IO devices directly from the centralised system then you could create a DeviceProxy for the sending write commands. The other approach is of course possible too i.e. you could also do do the reading of the IO device directly via events. But my preference is for building a hierarchy of devices and regrouping information as you go along. This way you reduce the coupling between control systems and changes in one system do not influence the other system. Andy

# 8 years ago

Andy

Dear TCS,

here is my 2 cents on this question:

TANGO allows you to use both paradigms. It depends on the amount of information to send, the level of filtering you want to do, and the number of clients etc. At the ESRF we usually create higher level devices which regroup the information coming from the accelerator control system into higher level devices which act as facades for the control systems running the experiments. This allows us to present only the information required for that experiment to the experiment control system. It also make it easier for the experiment control system clients because they access only one device where they get all their information. Requests are also sent to this facade device. With Tango9 you could use forwarded attributes to make attributes visible from one device to another device. If you need to access the low-level IO devices directly from the centralised system then you could create a DeviceProxy for the sending write commands.

The other approach is of course possible too i.e. you could also do do the reading of the IO device directly via events. But my preference is for building a hierarchy of devices and regrouping information as you go along. This way you reduce the coupling between control systems and changes in one system do not influence the other system.

Andy