Multiple Pools per Door

[dschick]

We are currently setting up a new experiment with Sardana which is charging some harware with an existing Sardana setup.

Right now we started to have one Door having one MarcorServer and one Pool for each of the two experiments. Now I would like to create one Pool that is linked to both Doors/Macroservers, which includes the shared hardware, e.g. the beamline components.

Is there any documentation available for this? My first guess would be to start the shared pool either by hand Pool beamline Or start a third Door Sardana beamline And then link the Pool to both other doors using e.g. Jive.

When adding/reorganizing the hardware, how do I set the target pool when defining new controller and element? There seems to be a known bug: https://github.com/sardana-org/sardana/issues/589

Best

Daniel

[reszelaz]

Hi Daniel,

You can configure your MacroServer device to connect to multiple Pool's with the PoolNames property.

We at ALBA are running these architectures and for example run a2scans with motors (BL and ID) from different Pools.

Before going into this setup be aware that:

• you can not define measurement groups with channels from different Pools *
• you can not define neither pseudomotors nor pseudocounters with elements from different Pools

* You can still add Tango attributes from the distant Pool to one measurement group. You could have two measurement groups in two different Pools, and in the pre-acq hooks start the non-active measurement group and in post-acq wait for it. The readout of the Tango attributes could then provide the data to the recorder. Yes, I know, this sounds like an ugly hack, but I think it should work in step scans..

When adding/reorganizing the hardware, how do I set the target pool when defining new controller and element? There seems to be a known bug: #589.

Yes, there was not advance on it. But if you decide on going into this direction we will evaluate how much work is needed to fix it.

Cheers!

[dschick]

Hi Zibi,

thanks for the detailed explaination. I think I will have to problems with the motors.

However, the limitation with the measurement group seems a bit more complicated. Regarding that, may I ask how you would solve the following situation at ALBA:

You have a beamline with two endstations. Every endstation has a Pool defined for motors and counter that are only relevant for each endstation. Then you have another Pool of the actual beamline including some optics and shutter etc. One important counter might be an I0 signal from the beamline that you always want to access in any measurement group for both beamlines.

As this I0 signal comes most likely from a TangoDS you can of course add it once to every pool of each endstation instead of to the pool of the beamline. But the, because both endstation run on the same TangoHost, you would need to name the I0 counter in each Pools differently, right?

Are there any other solutions than the hack you mentioned above?

[reszelaz]

I think in the current design there is no way to overcome the problem that you point. So you will need two "mirror" controllers in each of the pools (end station #1 and end station #2) that would point to either the channel from the optics Pool or directly to the Tango device that controls the hardware. And as you point you will need to use a different name. Or maybe someone else has another idea?

For the different name problem you may use the renameelem macro and in the end-station start-up procedure rename the element so it is always called I0 when you work at any end-station (I assume you never work at both, cause there is only one I0 hardware which can not be used simultaneously).

At ALBA we always use one Pool per beamline. The only scenario where we use two Pools is this BL and ID separation.

If at some point we want change the current Sardana design we could think of either:

• moving the measurement group concept to the MacroServer
• leave the measurement groups in the Pool but allow multiple active measurement groups in the MacroServer.

I think the second one will be much easier to implement, but it would need to be carefully evaluated.

[dschick]

alrighty, for now I am fine with the solution you pointed out. So running Sardana's Macroserver with multiple Pools seems to work fine for us as well.

We are starting to understand a bit more about the, at first sight, rather complex structure of the complete Sardana system :)

Thanks, I am closing

[dschick]

Hi Zibi,

I was wondering if there have been any changes in this context here?

1. are there plans to allow for elements from different Pools in one Measurement Group or allow for multiple meas_grps?
2. are there any workaround to allow for pseudomotors using elements from different Pools?

Regarding the later point some more info: We have some components in our setup which are movable and are not present at any time. We wanted to create a dedicated Pool for this hardware, which works pretty well. However, as this Pool also contains the theta motor for our sample, the HKL pseudomotorcontroller cannot be spanned across multiple Pools. Is there any blueprint for such situation?

Best

Daniel

[reszelaz]

Hi @dschick,

I was wondering if there have been any changes in this context here?

1. are there plans to allow for elements from different Pools in one Measurement Group or allow for multiple meas_grps?
2. are there any workaround to allow for pseudomotors using elements from different Pools?

No, unfortunately, we could not advance on them yet.

Regarding the later point some more info: We have some components in our setup which are movable and are not present at any time.

What do you mean by "not present at any time"? Do you mean that the hardware is sometimes not present e.g. removed for maintenance?

[dschick]

What do you mean by "not present at any time"? Do you mean that the hardware is sometimes not present e.g. removed for maintenance?

actually we share some sample manipulators between different labs/end stations. As an example we have a motorized cryostat which includes all sample stages x, y, z, and theta. In case the cryostat is moved from one lab to the other, I need to reconfigure my setup to use or disable the default sample manipulator. I thought that creating deticated pools for both sample manipulators would be a smart idea, but then I painfully (re-)learned that all pseudomotors (e.g. HKL) across different pools do not work anymore.

For now I can either write some macros to add/delete the corresponding hardware elements or create two different Doors for each setup. For the later case I need to take care that the Pools and Macroservers are always "synchronized" in terms of configuration.

[reszelaz]

Many thanks @dschick for the clarification. I think that I got it now. I will try to simplify your example a little bit more.

Let's assume we have two Pools: Pool01 and Pool02. In Pool01 we have the following two Sardana motors: mot01 and mot02, and one pseudo motor gap01 based on the former two motors (from the Slit controller) In Pool02 we have the following two Sardana motors: mot03 and mot04, and one pseudo motor gap02 based on the former two motors (from the Slit controller). While motors: mot02 and mot04 represent two different hardware axes, mot01 and mot03 point to the same hardware axis - by analogy with your motorized cryostat.

From the first solution you've mentioned:

write some macros to add/delete the corresponding hardware elements,

I understand that both Pool01 and Pool02 are defined in the same Tango DB and you would like to use the same name instead of mot01 and mot02 but you are limited by the fact that the Tango alias must be unique, right?

or create two different Doors for each setup. For the later case I need to take care that the Pools and Macroservers are always "synchronized" in terms of configuration.

This second solution I still do not understand.

[dschick]

thanks for simplifying my thoughts :)

Of course your example would work, but as most of my motors are permanent (~30) I would need to duplicate all of them and need to give them unique names. I think this is really anoying. I would also always need to "sync" the settings of both pools in case I add permanent new hardware to any of them, so I need to add it always to both of them. I think this is not really the idea of having the pools available.

When using dedicated Doors together with dedicated Pools I would also need to "sync" the Macroservers, with which I mean, I would need to keep track of always adding all macros to both Doors.

So I fear the (only) most elegant way of solving this issue is to allow for pseudo motors across different Pools.

[dschick]

I had a discussion with my colleague @dscran who told me about the ability to dump and load configuration files for Sardana Doors at DESY. Maybe this a way for me to easily switch between my two configurations.

@dscran noticed that the DESY way of doing it is rather complex. So I am wondering if there are also other implementations around for dumping and restoring Sardana configurations to files? (This might be moved to a dedicated issue if needed)

[reszelaz]

Maybe this a way for me to easily switch between my two configurations.

Yes, it looks like a good idea.

So I am wondering if there are also other implementations around for dumping and restoring Sardana configurations to files?

I'm not really into details of the DESY tool to start Sardana from an XML file. I'm not even sure if it works in both directions (also for dumping).

I know there is another tool called dsconfig which was developed at MAXIV and actually gained a lot of interest in the Tango community. I'm pretty sure this one works in both directions. I think they have even developed a Sardana flavor of this tool, but may be better if @13bscsaamjad explain to you that.

Recently a student joined ALBA for a one-year internship. Continuing work on the Sardana configuration tool is one of the possible projects for him.

Also related to that, I have learned from the last Tango Kernel follow-up meeting about:

Tango Database Backend with Yaml files

ESRF Beamline Control Unit developed an implementation of the Tango Database server using Beacon, stored using yaml files. This version currently does not work with some Tango devices and is tightly coupled with BLISS but if this project is of any interest to the Tango community, they might do the work to remove the dependency to BLISS and make it available to the community. The benefits to the community appear clearly to ease the setup of some CI tests or to configure easily a small Tango control system.

This may also shortly become an option for the Sardana configuration. But we would need to see if it provide all the current Tango Database features we use, and also to check its performance.

(This might be moved to a dedicated issue if needed)

Yes, probably you are right:) Sorry to spam here with all the above details. I have found this issue https://github.com/sardana-org/sardana/issues/815. Maybe we could move there this comments and continue there?