Simplify MG configuration by removing the units (SF#372)

[sf-migrator-bot]

MG dictionary (measurement groups dictionary) contains unnecessary complexity. In order to simplify it, we propose to go without the concept of 'units'. Actually the 'units' concept is not used. We are not sure about its original purpose, it could be one of these:

Handle complex controllers: example 1: Controllers like the MUSST counter card, which are programmable to work in several "units". For example, one could load the controller with program "tomo", in this way the controller would work under unit 0 with several counters. Loading with program "fluorescence" the controller would work under unit 1 with potentially other counters.

example 2: Controllers like the complex DAQ crates with multiple units e. g. multiple ADC cards.

---

The current structure of the MG dictionary is the following:

#----------------------------------------------
# Measurement Group (MG) Configuration information
#----------------------------------------------
# dict  with (at least) keys:
#    - 'timer' : the MG master timer channel name / master timer channel id
#    - 'monitor' : the MG master monitor channel name / master monitor channel id
#    - 'controllers' : dict  with one entry per controller:
#        - ctrl_object : dict with (at least) keys:
#            - 'units' : dict  with with one entry per unit:
#                - unit_id : dict with (at least) keys:
#                    - 'id' : the unit ID inside the controller
#                    - 'timer' : the timer channel name / timer channel id
#                    - 'monitor' : the monitor channel name / monitor channel id
#                    - 'trigger_type' : 'Gate'/'Software'
#                    - 'channels' where value is a dict
#                          - ...
#    - 'label' : measurement group label (defaults to measurement group name)
#    - 'description' : measurement group description

We propose to simplify the MG dictionary by removing the 'units' concept. This would result on a MG dictionary with the following shape:

#----------------------------------------------
# Measurement Group (MG) Configuration information
#----------------------------------------------
# dict  with (at least) keys:
#    - 'timer' : the MG master timer channel name / master timer channel id
#    - 'monitor' : the MG master monitor channel name / master monitor channel id
#    - 'controllers' : dict  with one entry per controller:
#        - ctrl_object : dict with (at least) keys:
#            - 'timer' : the timer channel name / timer channel id
#            - 'monitor' : the monitor channel name / monitor channel id
#            - 'trigger_type' : 'Gate'/'Software'
#            - 'channels' where value is a dict with (at least) keys:
#                - ...      
#    optional keys:
#    - 'label' : measurement group label (defaults to measurement group name)
#    - 'description' : measurement group description

Note: Code related with MG configuration dictionaries can be found in modules: sardana/pool/poolmeasurementgroup.py sardana/pool/poolelement.py sardana/pool/poolacquisition.py sardana/taurus/qt/qtgui/extra_sardana/measurementgroup.py sardana/taurus/core/tango/sardana/pool.py

Reported by: sagiss ( http://sf.net/u/mrosanes )

Original Ticket: sardana/tickets/372

[sf-migrator-bot]

This feature will be implemented and solved in SEP6; and will be solved in develop when SEP6 will be integrated into develop.

Original comment by: sagiss (http://sf.net/u/mrosanes)

[sf-migrator-bot]

After receiving feedback from DESY this feature was implemented in Alba's fork: git://git.code.sf.net/u/cmft/sardana-GenericSoftware . We hope to merge it into the canonical SEP6 branch in the following weeks.

It is still pending to discuss what is the desired backwards compatibility level. This could be:

In the following options old - means prior to the feature-372 implementation, new - means after feature-372 implementation

• ignore old measurement group configuration on the Pool's startup and substitute them by the auto-generated default configuration
• migrate the old configuration to the new configuration automatically on the Pool's startup
• provide external script which migrates the old configuration to the new

Original comment by: reszelaz (http://sf.net/u/zreszela)

[sf-migrator-bot]

Hi Zibi, about the backwards compatibility, I think it is better if it is done automatically. I do not see a problem for us if the first or the second solutions are used. We generate the Measurement Groups from scratch very often, based on configuration scripts. For us the point would be to change our tools, there is where we have to take care of the change. At least just now I do not see any other problem.

              Regards,
                         Teresa

Original comment by: teresanunez (http://sf.net/u/tere29)

[sf-migrator-bot]

• Milestone: Jan16 --> unassigned

Original comment by: reszelaz (http://sf.net/u/zreszela)

[reszelaz]

Implemented in SEP6 and already part of develop.