Cycling magnets

Since I've been in charge of the control of the power supplies of Alba synchrotron, I have discover many new things. After more than four years an absolute new world is in front of me.


One special thing that we do with the magnets is to cycle them. But what does this mean?


The magnet hysteresis is the reason of this procedure: the magnetic field produced by an electromagnet is function of the current applied by the power converter, but it has a path dependency. Or is not the same to arrive to one position if you come from different places. Also it have dependency on the length of the magnet but this is constant, at least in our ones.


From a very simplistic view, what I understand about this is a graphic like:

Where to arrive to one position on the green line, for example 0.95T you have to set a current of  480A (assuming a magnet of 1m to simplify, and all the numbers are my inventions). But depending from where you arrive to this current you will be on one of the black lines. Then you will have a magnetic field between 0.89T and 0.98T, but not exactly what you want.


The solution is to cycle the magnet, this means, from the current where you know the green line for the magnetic field you want do a procedure to the maximum current to the minimum and to the maximum again to run in the red line. Do it again and you will be in the green line to finally go the the setpoint and you have the expected magnetic filed.


The procedure it's easy: setpoint-max-min-max-min-max-setpoint. But how to make this automatic?

Cycling of all the storage ring magnets (with the new approach)

The first approach we did was using the Sardana Control User Environment. A very abstract view of a magnets can be like a motor: you have many positions not in distance unit (meters, millimeters  microns,...) , but in current unit (Amperes) of the electromagnet.


This has been working well for a long time. The users can do this procedure in a automatic way, but the read back of the power converters some times is a bad player.


The approach using a macro have some implications and a collateral damage. A macro is launched and the MacroServer is the device in charge to run this together. All the magnets selected by the user have a controller in a Pool of motors, and the MacroServer is able to coordinate motors from many different Pools. This pool motor controller is the one who bridges the communication to the power a supply device server offering a interface to the upper layers.


The issues appears when the device of the power converter shows glitch on the current read back. Is not a thing that changes the magnetic field, but is a thing that changes the state of the device to moving. The controller is propagating this to the pool.


If due to any casual planet alignment the pool receives the move command, during a glitch it trigger an exception because it can not distinguish the glitch to a real movement commanded from somewhere else. This has a very small probability, but if you add enough magnets this can happen more often. And if you add that when this happens, the cycling of all the other magnets is cancelled the cycling would be restarted and is possible that next time another magnet has a glitch.


How this can be fix? Who has the responsible to cycle the magnets in the old solution? The macro. But it has some problems with the bad guys of the magnets. Even if we mask this glitch behavior (thing that we did), the main design issue is that a problem of one participant, disturbs all the others. Sardana needs this feature because it is a feature need for coordinated movements.


The new approach:
Each magnet  is responsible of itself.


Further than coordinate the cycling, why not make each magnet (the tango device of the power supply) responsible of itself cycling?


Introducing a command to the device we have what was the macro in side of this power converter control. A problem in one magnet will only affect this magnet. All the others will continue their procedures. If the operator saw something in one of the magnets can abort the cycling of this one, letting the others cycling.


In the second image of this post, of a taurustrend, with the cycling of the storage ring magnets is possible to see that the quadrupoles and sextupoles are independent to the bending. They have a smaller current range for cycling, and they finish early. Even more, if you look the quadrupoles and sextupoles, they are accumulating a shift during this cycle, and the ones with a smaller range finishes a bit early that the others.

Cycling the booster to storage transferline

More evident can be in the booster to storage transferline. The correctors, with a range of [-5A,5A] finishes about a minute before than the other big magnets. And between the other big magnets, here they have different currents and show this shifting better.


The result on the real hardware test of last Friday was succeed (also testing many abort cases) for Hazemeyer storage ring power supplies and for the Bruker linac to booster and booster to storage transferlines power supplies.


As far as I know, we reduce a procedure that can take very long by hand to a 4 minutes automatic process. That is an example of what the controls section tries to do: make scientist "lives" easier to allow them to focus in what they like, do research, do science.


Update 20110907: As usual, asking you get more info. Why this cycling procedure is working? It's not, like I said a max-min iteration: it's a sinusoidal function approach. Due to the ramp (speed of the current motion in Amperes per second) and the acceleration and deceleration close to the setpoint this procedure does somenthing quite similar to a sinusoidal function and give this property to fix the hysteresis.