Best practices with examples

# 5 years ago
Diego	Hello everyone. We discussed how to write distributed Device Servers with hundreds of attributes on ICALEPCS conference, but I also want to clarify some details and get more opinions and advice. So, let me describe some examples of hardware that we have. First example is a CAEN SY4527 crate with up to 16 different modules - different number of channels, output maximums, resolution, polarity, etc. And we want at least read values from these modules and archive them. If we have 32-channel module and about 10 different variables (Iset, Imon, Vset, Vmon …), there are about 320 scalar attributes for one Device Server. How can I organize reading process from the crate and modules for better performance and to make it more Tango-ish way? Reading must be fast enought to detect changes, e.g. for Imon. I've drawn three options (pictures 1, 2, 3) that came to my mind, can anyone comment every picture and help me choose the best way? Another example - custom HV system, it's distributed and has controller with only one active Socket connection and 48 modules connected to one RS-485 bus. Every module has 16 channels with Vset and one status variable (in bits), which means I have to read the board 17 times to get all the data. So there are more than 800 variables, which means >800 attributes. I think it's to much for one DS. Maybe it's better to separate all modules to distinct DS, but we will have 2400 modules (50 controllers x 48 modules) for detector in total -> 2400 device servers and 40k+ attributes only for one system! The reading can be not so fast, but reasonable to have up-to-date values. Pictures 4 and 5 are attached for this options. I'm a bit confused with such numbers, because we used spectrum attributes for the same type of data, but it's the waste of disk space and Tango was not designed to work like that. Any thoughts, ideas, examples from your experience and comments are appreciated. Edited 5 years ago Attachments:

# 5 years ago

Hello everyone.

We discussed how to write distributed Device Servers with hundreds of attributes on ICALEPCS conference, but I also want to clarify some details and get more opinions and advice.

So, let me describe some examples of hardware that we have.

First example is a CAEN SY4527 crate with up to 16 different modules - different number of channels, output maximums, resolution, polarity, etc.
And we want at least read values from these modules and archive them.
If we have 32-channel module and about 10 different variables (Iset, Imon, Vset, Vmon …), there are about 320 scalar attributes for one Device Server.

How can I organize reading process from the crate and modules for better performance and to make it more Tango-ish way? Reading must be fast enought to detect changes, e.g. for Imon.
I've drawn three options (pictures 1, 2, 3) that came to my mind, can anyone comment every picture and help me choose the best way?

Another example - custom HV system, it's distributed and has controller with only one active Socket connection and 48 modules connected to one RS-485 bus.

Every module has 16 channels with Vset and one status variable (in bits), which means I have to read the board 17 times to get all the data.

So there are more than 800 variables, which means >800 attributes. I think it's to much for one DS.
Maybe it's better to separate all modules to distinct DS, but we will have 2400 modules (50 controllers x 48 modules) for detector in total -> 2400 device servers and 40k+ attributes only for one system!
The reading can be not so fast, but reasonable to have up-to-date values.
Pictures 4 and 5 are attached for this options.

I'm a bit confused with such numbers, because we used spectrum attributes for the same type of data, but it's the waste of disk space and Tango was not designed to work like that.

Any thoughts, ideas, examples from your experience and comments are appreciated.

Edited 5 years ago

# 5 years ago
lorenzo	Diego Hello everyone. We discussed how to write distributed Device Servers with hundreds of attributes on ICALEPCS conference, but I also want to clarify some details and get more opinions and advice. So, let me describe some examples of hardware that we have. First example is a CAEN SY4527 crate with up to 16 different modules - different number of channels, output maximums, resolution, polarity, etc. And we want at least read values from these modules and archive them. If we have 32-channel module and about 10 different variables (Iset, Imon, Vset, Vmon …), there are about 320 scalar attributes for one Device Server. Hi Diego, this is not completely correct, as in Tango physical variables (e.g. I, V,…) correspond to Attributes and Attributes have both read and set; thus in your example you'll have some 2 (maybe 4?) Attributes per channel. If you model each module into one device (that's what I'd do), your device will have some 64 Attributes… Diego How can I organize reading process from the crate and modules for better performance and to make it more Tango-ish way? Reading must be fast enought to detect changes, e.g. for Imon. I've drawn three options (pictures 1, 2, 3) that came to my mind, can anyone comment every picture and help me choose the best way? Well, this also depends on the device driver support for the board… will the driver support asynchronous (e.g. interrupt based) I/O? Will it allow to read all the channels in one access? Also depends on the bandwidth of the signals you want to sample (remember Nyquist-Shannon…). So, "fast" is very subjective. Diego Another example - custom HV system, it's distributed and has controller with only one active Socket connection and 48 modules connected to one RS-485 bus. Every module has 16 channels with Vset and one status variable (in bits), which means I have to read the board 17 times to get all the data. As before, will your controller allow to read all the data in one single block? If yes, this could be a typical case where you access the controller once in the read_attribute_hardware() method and fill all the attributes… As before, remember that reading/setting requires just one Attribute per physical variable. Diego So there are more than 800 variables, which means >800 attributes. I think it's to much for one DS. Maybe it's better to separate all modules to distinct DS, but we will have 2400 modules (50 controllers x 48 modules) for detector in total -> 2400 device servers and 40k+ attributes only for one system! The reading can be not so fast, but reasonable to have up-to-date values. Pictures 4 and 5 are attached for this options. Maybe one device per module on the low layer, with an additional device per controller aggregating just the relevant information/readings? Diego I'm a bit confused with such numbers, because we used spectrum attributes for the same type of data, but it's the waste of disk space and Tango was not designed to work like that. Any thoughts, ideas, examples from your experience and comments are appreciated. Using spectrum attributes provides a much more compact interface, but compromise on the "visibility" you have of your channels… can be acceptable, however, depending on your requirements… Cheers, Lorenzo Edited 5 years ago

# 5 years ago

lorenzo

Diego
Hello everyone.

We discussed how to write distributed Device Servers with hundreds of attributes on ICALEPCS conference, but I also want to clarify some details and get more opinions and advice.

So, let me describe some examples of hardware that we have.

First example is a CAEN SY4527 crate with up to 16 different modules - different number of channels, output maximums, resolution, polarity, etc.
And we want at least read values from these modules and archive them.
If we have 32-channel module and about 10 different variables (Iset, Imon, Vset, Vmon …), there are about 320 scalar attributes for one Device Server.

Hi Diego,
this is not completely correct, as in Tango physical variables (e.g. I, V,…) correspond to Attributes and Attributes have both read *and* set; thus in your example you'll have some 2 (maybe 4?) Attributes per channel. If you model each module into one device (that's what I'd do), your device will have some 64 Attributes…

Diego
How can I organize reading process from the crate and modules for better performance and to make it more Tango-ish way? Reading must be fast enought to detect changes, e.g. for Imon.
I've drawn three options (pictures 1, 2, 3) that came to my mind, can anyone comment every picture and help me choose the best way?

Well, this also depends on the device driver support for the board… will the driver support asynchronous (e.g. interrupt based) I/O? Will it allow to read all the channels in one access? Also depends on the bandwidth of the signals you want to sample (remember Nyquist-Shannon…). So, "fast" is very subjective.

Diego
Another example - custom HV system, it's distributed and has controller with only one active Socket connection and 48 modules connected to one RS-485 bus.
Every module has 16 channels with Vset and one status variable (in bits), which means I have to read the board 17 times to get all the data.

As before, will your controller allow to read all the data in one single block? If yes, this could be a typical case where
you access the controller once in the read_attribute_hardware() method and fill all the attributes… As before, remember that reading/setting requires just one Attribute per physical variable.

Diego
So there are more than 800 variables, which means >800 attributes. I think it's to much for one DS.
Maybe it's better to separate all modules to distinct DS, but we will have 2400 modules (50 controllers x 48 modules) for detector in total -> 2400 device servers and 40k+ attributes only for one system!
The reading can be not so fast, but reasonable to have up-to-date values.
Pictures 4 and 5 are attached for this options.

Maybe one device per module on the low layer, with an additional device per controller aggregating just the relevant information/readings?

Diego
I'm a bit confused with such numbers, because we used spectrum attributes for the same type of data, but it's the waste of disk space and Tango was not designed to work like that.
Any thoughts, ideas, examples from your experience and comments are appreciated.

Using spectrum attributes provides a much more compact interface, but compromise on the "visibility" you have of your channels… can be acceptable, however, depending on your requirements…

Cheers,
Lorenzo

Edited 5 years ago

# 5 years ago
Diego	lorenzo Hi Diego, this is not completely correct, as in Tango physical variables (e.g. I, V,…) correspond to Attributes and Attributes have both read and set; thus in your example you'll have some 2 (maybe 4?) Attributes per channel. If you model each module into one device (that's what I'd do), your device will have some 64 Attributes… Actually there are two Iset and Vset variables for every channel and users can switch between them if they want to save settings in the hardware for another setup. And Imon and two Iset are read differently from device, so I think it is better to have one RO attr for Imon and two RW attrs for Isets (read value from device and set value from users). Currents and voltages are not the only attributes, also Channel status, RampUp, RampDown, Trip, etc. So, as I said, more than 300 attributes for one device server. lorenzo Well, this also depends on the device driver support for the board… will the driver support asynchronous (e.g. interrupt based) I/O? Will it allow to read all the channels in one access? No, it is synchronous and I can read only one variable at once, and that's the problem. I've made some tests and average time for board to response is about 20 ms, which means for 16 variables >300 ms for one board => about 15 seconds for 48 boards on one controller… lorenzo Maybe one device per module on the low layer, with an additional device per controller aggregating just the relevant information/readings? I think that's the only way, but the question is how to transfer data fast and easy from the device server which reads hardware and servers which represent data for monitoring and provide it to the EventSubscriber. lorenzo Using spectrum attributes provides a much more compact interface, but compromise on the "visibility" you have of your channels… can be acceptable, however, depending on your requirements… It is the way how we worked by now, but it use much more disk space comparing to the distinct scalar attributes, and archiving shares first place with monitoring in our case.

# 5 years ago

Diego

lorenzo
Hi Diego,
this is not completely correct, as in Tango physical variables (e.g. I, V,…) correspond to Attributes and Attributes have both read *and* set; thus in your example you'll have some 2 (maybe 4?) Attributes per channel. If you model each module into one device (that's what I'd do), your device will have some 64 Attributes…

Actually there are two Iset and Vset variables for every channel and users can switch between them if they want to save settings in the hardware for another setup. And Imon and two Iset are read differently from device, so I think it is better to have one RO attr for Imon and two RW attrs for Isets (read value from device and set value from users).
Currents and voltages are not the only attributes, also Channel status, RampUp, RampDown, Trip, etc. So, as I said, more than 300 attributes for one device server.

lorenzo
Well, this also depends on the device driver support for the board… will the driver support asynchronous (e.g. interrupt based) I/O? Will it allow to read all the channels in one access?

No, it is synchronous and I can read only one variable at once, and that's the problem.
I've made some tests and average time for board to response is about 20 ms, which means for 16 variables >300 ms for one board => about 15 seconds for 48 boards on one controller…

lorenzo
Maybe one device per module on the low layer, with an additional device per controller aggregating just the relevant information/readings?

I think that's the only way, but the question is how to transfer data fast and easy from the device server which reads hardware and servers which represent data for monitoring and provide it to the EventSubscriber.

lorenzo
Using spectrum attributes provides a much more compact interface, but compromise on the "visibility" you have of your channels… can be acceptable, however, depending on your requirements…

It is the way how we worked by now, but it use much more disk space comparing to the distinct scalar attributes, and archiving shares first place with monitoring in our case.

# 5 years ago
lorenzo	Diego No, it is synchronous and I can read only one variable at once, and that's the problem. I've made some tests and average time for board to response is about 20 ms, which means for 16 variables >300 ms for one board => about 15 seconds for 48 boards on one controller… …if this is the way the hardware has been designed/integrated, there's no way you can overcome with software. But, are the boards in the SY4527 interfaces by RS485 or by ethernet? In the latter case you can run each device board as a separate instance for pseudo-parallel access, but in the former you just have to acknowledge that you'll be able to refresh your reading once every 15 seconds the fastest.

# 5 years ago

lorenzo

Diego
No, it is synchronous and I can read only one variable at once, and that's the problem.
I've made some tests and average time for board to response is about 20 ms, which means for 16 variables >300 ms for one board => about 15 seconds for 48 boards on one controller…

…if this is the way the hardware has been designed/integrated, there's no way you can overcome with software. But, are the boards in the SY4527 interfaces by RS485 or by ethernet? In the latter case you can run each device board as a separate instance for pseudo-parallel access, but in the former you just have to acknowledge that you'll be able to refresh your reading once every 15 seconds the fastest.