Usually august is a good time to think on refactorings. During the year normal operation there is never enough time to look back. The sentence "I want all, and I want it now" it's a classical sentence from clients and bosses (many times followed with a "I want it fix, but don't touch any thing").
Also is good because too many managers doesn't care about refactoring. They don't really understand what this means and didn't give to it the real value of this action. For them, often, the maintenance of some code is sort of magic, they don't know how this can be made. Furthermore they don't care, and only think in do it fast an cheap.
In the case of the scope, we are currently using the scope waveforms in a Filling Pattern calculation using the Fast Current Transformer signal. This was the fpFCT project. In this case, we went far away from the original design of the access to the scopes. This original design was already improved long a go, and looks that now it's time to remade it base on the newer requirements.
The current bottleneck is the Visa middlemen. The agent that shows the user the interface of an instrument like an scope doesn't know about protocols. This agent knows the language to talk with the instrument, but not the channel used to have bidirectional communication with it.
From Max IV, there is a proposal to talk directly via socket. This will remove from the scene one of the actors, and for sure will improve.
The second proposal, should be helped by a new feature requested in tango: give the information to the device that someone is listening (or not) over the events on an attribute. This is, avoid to request information to the instrument if noone is listening.
Current idea of the refactoring is to use proposal one, and by commands (until the mentioned feature is available) configure the attributes that are being updated by an isolated thread, optimizing the scope access, in an approach to proposal two.
Update 20130806: Max IV has contributed with their nice idea in a branch.
Showing posts with label tango. Show all posts
Showing posts with label tango. Show all posts
2013/07/29
2013/07/09
(more) frustraited @ work
Alba is broken like since eastern. When we come back from that shutdown at the end of March. Water cooling problems, the water flow was unstable; sponges were found in the "clean water" cooling pipes, together with other dust; a weekend instrument hang causes a temperature increase and bad quality of hoses become vulcanized (below the specs) and caused a disaster in one of the two main power supplies of the booster; a TLD wrong placed in a weird space and when an Insertion Device was moved, it bends the beam pipe blocking the beam orbit, requiring to vent and replace a section. It's like we stomp shit.
This is one of the issues in this accelerator complex, but there are others that may interact.
Panic reaches the management at the beginning of this years when 12 people announces their new positions in other institutes. If you take into account that we are 145 workers, you can realizes the magnitude of the problem. From the people that says goodbye, 8 were from the computing division (around 50) and from those 4 were from the controls section (of 14). This panic didn't mention the 1 or 2 per month that has announced that the left during the past two years.
Management has announced 3 months later the creation of a commission from work behaviour improvements. Now, in July, this commission has made the first meeting by last week.
As I mention in the previous post, another reason of personal sadness: my bosses didn't case about a worker that has been called to do a talk in the university.
I didn't write here since then. I didn't found any reason to write about software design here.
But last reason to get one step further in frustration went last week.
Starting 2 months a go, in the tango meeting, there was a request to the tango community to introduce security embedded inside the tango implementation. From the last 4 years I've been trying to start a PhD in cryptology (but too busy due to the work at Alba), and I've been getting closer and closer to the field of the RFIDs and the smartcards. During the presentation where this was requested, I thought that many of the schemas to ensure RFID can be also valid to be applied in between the communication of the agents in a distributed system, like tango.
I thought it can be interesting for Alba and the tango community, to exploit that one of the workers has a hobby in cryptology and security. In this terms I've talked to my boss.
For that, I need 3 weeks to talk to my boss (this is already one problem). During this time, I've been able to, out side working hours, explain this idea to the research group in the university (they are in another city, 150 km away). I found a great acceptance about "Ensuring Tango control system", even more I've seen enthusiasm about the idea of a PhD based on an application of all the cryptological work made by the whole group (many things about public key -specially elliptic curves- symmetric cyphers, stream ciphers, secret sharing, homomorphic encryption and field like that).
At work, the response wasn't that good. The answer was like: "do what ever you like in your free time, but this must not affect your current duties at all. It's not possible to dedicate any of your working hours in such a thing". Clearly have said, if I do a PhD, is not meaning anything for Alba at all. Ooh!! This is a very clear way to motivate a worker. For my partners, also fun when was said "if you do, others would ask to do this", what's the problem on workers training?
Went I talked to my boss, I said many time to him and have to point here, that my duties have been increase every time that a partner left. Last Friday, there was a presentation about the Alba's controls system, and when the subsystems of the machine was listed, half of the elements on that list are on my behalf (and not all my duties were there).
When I went to talk about this with my boss, I went there offering my free time to work in a industrial PhD. My proposal was not to stop doing my job and disappear for full time dedication to this, my proposal was mostly the free time, but being realistic that the brain thinks at any time. As a collaboration between the university and the industry, all the involved has to put something, specially the PhD candidate.
Well done, with this deal, the simpler solution is that Alba will not appear at all in my PhD. Or if it appears will be to be mention explicitly that they haven't contribute at all; even worst Alba's position was opposition to doing a work like that.
This is one of the issues in this accelerator complex, but there are others that may interact.
Panic reaches the management at the beginning of this years when 12 people announces their new positions in other institutes. If you take into account that we are 145 workers, you can realizes the magnitude of the problem. From the people that says goodbye, 8 were from the computing division (around 50) and from those 4 were from the controls section (of 14). This panic didn't mention the 1 or 2 per month that has announced that the left during the past two years.
Management has announced 3 months later the creation of a commission from work behaviour improvements. Now, in July, this commission has made the first meeting by last week.
As I mention in the previous post, another reason of personal sadness: my bosses didn't case about a worker that has been called to do a talk in the university.
I didn't write here since then. I didn't found any reason to write about software design here.
But last reason to get one step further in frustration went last week.
Starting 2 months a go, in the tango meeting, there was a request to the tango community to introduce security embedded inside the tango implementation. From the last 4 years I've been trying to start a PhD in cryptology (but too busy due to the work at Alba), and I've been getting closer and closer to the field of the RFIDs and the smartcards. During the presentation where this was requested, I thought that many of the schemas to ensure RFID can be also valid to be applied in between the communication of the agents in a distributed system, like tango.
I thought it can be interesting for Alba and the tango community, to exploit that one of the workers has a hobby in cryptology and security. In this terms I've talked to my boss.
For that, I need 3 weeks to talk to my boss (this is already one problem). During this time, I've been able to, out side working hours, explain this idea to the research group in the university (they are in another city, 150 km away). I found a great acceptance about "Ensuring Tango control system", even more I've seen enthusiasm about the idea of a PhD based on an application of all the cryptological work made by the whole group (many things about public key -specially elliptic curves- symmetric cyphers, stream ciphers, secret sharing, homomorphic encryption and field like that).
At work, the response wasn't that good. The answer was like: "do what ever you like in your free time, but this must not affect your current duties at all. It's not possible to dedicate any of your working hours in such a thing". Clearly have said, if I do a PhD, is not meaning anything for Alba at all. Ooh!! This is a very clear way to motivate a worker. For my partners, also fun when was said "if you do, others would ask to do this", what's the problem on workers training?
Went I talked to my boss, I said many time to him and have to point here, that my duties have been increase every time that a partner left. Last Friday, there was a presentation about the Alba's controls system, and when the subsystems of the machine was listed, half of the elements on that list are on my behalf (and not all my duties were there).
When I went to talk about this with my boss, I went there offering my free time to work in a industrial PhD. My proposal was not to stop doing my job and disappear for full time dedication to this, my proposal was mostly the free time, but being realistic that the brain thinks at any time. As a collaboration between the university and the industry, all the involved has to put something, specially the PhD candidate.
Well done, with this deal, the simpler solution is that Alba will not appear at all in my PhD. Or if it appears will be to be mention explicitly that they haven't contribute at all; even worst Alba's position was opposition to doing a work like that.
2013/02/14
fpFCT: bugfixing
After the development of this study of the filling pattern using the fast current transformer it was time to search for bugs. From a result like:
This calculation doesn't have good sense and looks like there is a bug. This only 2 groups doesn't look nice. Even worst when we execute the code under an scripting way, the result was different. And we found the error: the number of giga samples used in the calculation. We've seen a 10th factor and we found that using the scripting mode, it reads the attribute from the scope, but from the device server it uses a default initial value of 4e10.
We've been lucky that the default value wasn't the same than what was expected, or we would get crazy if some day it changes. For example if the scope samples at 20GS/s instead of 40.
After last bug search we can see results like:
There are things to review, we didn't finish completely this development. But what is true is that the scientist already have usable data for their studies.
This calculation doesn't have good sense and looks like there is a bug. This only 2 groups doesn't look nice. Even worst when we execute the code under an scripting way, the result was different. And we found the error: the number of giga samples used in the calculation. We've seen a 10th factor and we found that using the scripting mode, it reads the attribute from the scope, but from the device server it uses a default initial value of 4e10.
We've been lucky that the default value wasn't the same than what was expected, or we would get crazy if some day it changes. For example if the scope samples at 20GS/s instead of 40.
After last bug search we can see results like:
There are things to review, we didn't finish completely this development. But what is true is that the scientist already have usable data for their studies.
2013/01/25
fpFCT: with beam
A month a go I have work in simulate the beam of the storage ring by its bunches in the Fast Current Transformer (FCT). Well now we are in a run of 3 weeks (the operation calendar is available on the web site), and we can see the signal in the scope from the FCT and apply the algorithm developed in accelerators using the device server developer by the controls group.
To see those inputs and those outputs we need our Tango Graphical User Interface (GUI) called Taurus. And with a "simple" command line like:
$ taurusform sr/di/FillingPatternFCT-01/{nAcquisitions,StartingPoint,Threshold,ScaleH,OffsetH,TimingTrigger,resultingFrequency,FilledBunches,SpuriousBunches} sr02/di/sco-01/{Channel1,CurrentSampleRate,ScaleH,OffsetH} sr/di/FillingPatternFCT-01/{BunchIntensity,State,Status} &
This command line, looking so complicated is only listing all the attributes (and their sorting) to be set in a taurusform, by using a feature of bash to write the (almost) minimum.
For example, first parameter is: sr/di/FillingPatternFCT-01/{nAcquisitions,StartingPoint,Threshold,ScaleH,OffsetH,TimingTrigger,resultingFrequency,FilledBunches,SpuriousBunches} An this means to get from the device server sr/di/FillingPatternFCT-01, the attributes listed.
That command will open a small window like:
There are two button in the attribute space because they are 1D data (spectrum in tango), Clicking them a taurusplot will be launched for each. One for the FCT signal:
And another for the Bunch Intensity calculated:
With Taurus, it's so easy to have a little simple gui to start with. Also the General Taurus Gui is neither so difficult.
To see those inputs and those outputs we need our Tango Graphical User Interface (GUI) called Taurus. And with a "simple" command line like:
$ taurusform sr/di/FillingPatternFCT-01/{nAcquisitions,StartingPoint,Threshold,ScaleH,OffsetH,TimingTrigger,resultingFrequency,FilledBunches,SpuriousBunches} sr02/di/sco-01/{Channel1,CurrentSampleRate,ScaleH,OffsetH} sr/di/FillingPatternFCT-01/{BunchIntensity,State,Status} &
This command line, looking so complicated is only listing all the attributes (and their sorting) to be set in a taurusform, by using a feature of bash to write the (almost) minimum.
For example, first parameter is: sr/di/FillingPatternFCT-01/{nAcquisitions,StartingPoint,Threshold,ScaleH,OffsetH,TimingTrigger,resultingFrequency,FilledBunches,SpuriousBunches} An this means to get from the device server sr/di/FillingPatternFCT-01, the attributes listed.
That command will open a small window like:
With Taurus, it's so easy to have a little simple gui to start with. Also the General Taurus Gui is neither so difficult.
2012/12/20
fpFCT: simulating the bunch current
fpFCT is an smaller name of the Filling Pattern from Fast Current Transformer. As I've said I didn't know how to simulate the signal that is in coming from the scope, and I found a solution.
This is a reused image of the scope signal from the storage ring FCT and what I found how to simulate using PySignalSimulator is:
There are only 4kpoints instead of the 40k that the scope is giving but it looks quite similar.
But how this has been set up in the PySignalSimulator properties? The initial idea was the amplitude modulation but with this what is represented looks like:
But what if the carrier wave, better than a sinusoid looks like a quadratic waveform. With this I have started to play with harmonics. The formula that likes more to be a carrier has been:
In red is plot the carrier over the modulated signal in blue. The signal that is being modulated has been omitted because is almost a sinusoid.
The formula of the carries is:
=a_1 + a_{11}sin(2\pi w_1t)+ a_{13}sin(2\pi 3w_1t)+ a_{15}sin(2\pi 5w_1t)+ a_{17}sin(2\pi 7w_1t)+ a_{19}sin(2\pi 9w_1t) "c(t)=a_1 + a_{11}sin(2\pi w_1t)+ a_{13}sin(2\pi 3w_1t)+ a_{15}sin(2\pi 5w_1t)+ a_{17}sin(2\pi 7w_1t)+ a_{19}sin(2\pi 9w_1t)")
With parameters values:
The formula of the modulated signal is:
=a_{2}sin(2\pi w_{2}(t+sin(x_2))) "x(t)=a_{2}sin(2\pi w_{2}(t+sin(x_2)))")
With a_2 = 1; w_2=0.065. The x_2 is a value that is changing from time to time to introduce a drift in the signal in order to have a "dancing" bunches like in the scope.
Lets see the result:
This is a reused image of the scope signal from the storage ring FCT and what I found how to simulate using PySignalSimulator is:
There are only 4kpoints instead of the 40k that the scope is giving but it looks quite similar.
But how this has been set up in the PySignalSimulator properties? The initial idea was the amplitude modulation but with this what is represented looks like:
But what if the carrier wave, better than a sinusoid looks like a quadratic waveform. With this I have started to play with harmonics. The formula that likes more to be a carrier has been:
In red is plot the carrier over the modulated signal in blue. The signal that is being modulated has been omitted because is almost a sinusoid.
The formula of the carries is:
Lets see the result:
2012/12/18
Fast Orbit FeedBack
One of the necessary improvements of Alba is the top up system. With this, the beam accumulated in the storage ring can be restored under a continuous re-injection precisely on the buckets here it bunch is losing charge. Recovering an old snapshot of the machine status:
This is an example where the stored beam had decay from 60mA to a bit more than 30 in around 6 hours (this was a year a go, by now we are having more current and a longer beam live time). This lost of current requires re-injections like what is in the middle of the red plot.
This re-injection, afaik, produces perturbations on the beam orbit that at the end means drifts in the x-ray beam in the beamlines. This re-injection, due to radiation safety reason have to be done with the frontends closed. That is with the beamlines in a standby, without light and waiting that this re-injection finishes. This re-injection causes an interruption on the experiments, and the longest experiment you can do is the one that can be performed between re-injections. You can imagine the consequences if the most insignificant thing fails in the middle of an experiment.under this conditions.
Well, to make this re-injection possible with the frontends open, the orbit of the beam must be very static. The beam has to be thine characterised and its oscillations below some microns.
How the orbit is corrected? In the sextupoles, there are the coils for each of the poles, but it is also another pair of thinner coils that sets the corrector component. I imagine it like a tiny little bending (they have like 3 orders less of magnitude in terms of current).
Those correctors can change its current very fast for a small modifications. That can be, in the order of the hundreds of miliamps can change it with a 10kHz frequency.
With this, together with a beam position monitoring at this speed, and if you can process all this data, the orbit perturbations can be controlled good enough to allow to re-inject with the necessary safeness to implement the top up system and have the plot of the current as an straight horizontal line (negligible ripple).
Main issue: with in a ring of around 400m of perimeter share between 88 beam position monitors all their sets of data, plus the sniffers we have to take this data to calculate those corrections, and stablish the new setpoints to another 88 corrector power supplies. All this at 10kHz: read, calculate, write: simple operations.
Filling Pattern From Fast Current Transformer
As I explain the a previous post we have a Fast Current Transformer in the storage ring and we are able to see the signal in an oscilloscope. Many years a go I have started a project to have the features of those scopes we have in the control system.
In the next video, the oscilloscope signal has been simulated using this simulator. You will see it as the top-right blue plot with an amplitude that oscillates between 0 and a maximum. The variables of the formula that simulates this are below this plot, on the left side.
On the left side of the screen some data are revealed about the cpu, memory, network use and so one. After send the Start() command the image below the plot (on its middle) start to collect each one of the waveforms from above. And already with non complete buffer the data is being processed. On the right of this cyclic buffer image representation, there are the attributes to adjust the algorithm and then the output. The green plot on the top is the filtered output.
It has been started as a Tango Device server in C++ many years a go, but from a refactoring it have changed to be a python device using PyTango. Also this new release have suffered many changes, specially the one that expands this server to more classes to be able to control, not only scopes, but also Spectrum analysers, Signal generators, and later on Radio frequency generators.
But this device have been more used in this "extensions" than in the original scope class. The Signal generator has been used in the booster tune excitation together with the spectrum analyser in the booster tune measurement (I didn't have time to write about those projects here, I hope soon). This devices works fine and the quality was good enough to change the storage tune measurements to be like the booster ones.
Due to Linac's needs to archive some scope measurements, the scope tango class was improved giving as an output here three posts. This was the real trigger that have launched this device server class.
A few weeks a go, more requests have been receiver about scope acquisition: It has been requested to have available the signal from an FCT in the control system, Also this required to improve the acquisition of the waveform from the scope and after some tries help has been requested to the manufacturer. With this I have reduced the network transition of 40kpoints as 300kB to 80kB or 40kB depending on the float precision. This allows to start polling the scope waveform at 3Hz.
This have boosted the project of the Filling Pattern studies using this FCT signal and a device server is available to perform this calculation. Just now that there is no beam, there is no signal in the FCT, only electronic noise like:
)Instead of the usual signal we have when there is beam:
Like often happens I had to ask what this mean and I had try to explain. But, to test the development of the FCT signal analysis, it's necessary to simulate a bit it. No necessary to have the same signal but I should complain that have to change from time to time to have something alive to be analysed.
The solution is to use a simulator of signals, and the best way is using the incredibly versatile PySignalSimulator device server. Creating a device with one property "DynamicAttributes" with something like:
A1=float(READ and VAR('A1') of WRITE and VAR('A1,VALUE)This sets an scalar attribute with a float value that than be read or write. Combining this with an attribute that contains an array of elements:
Channel1=[ (sin(VAR('W1')*x)*sin(VAR('W2')*x)) for x in range(4096)]With those simple lines you can have an spectrum value with a amplitude modulated signal. It's not the same than the beam signal, but it can acts to show how this bunch analyser works.
In the next video, the oscilloscope signal has been simulated using this simulator. You will see it as the top-right blue plot with an amplitude that oscillates between 0 and a maximum. The variables of the formula that simulates this are below this plot, on the left side.
On the left side of the screen some data are revealed about the cpu, memory, network use and so one. After send the Start() command the image below the plot (on its middle) start to collect each one of the waveforms from above. And already with non complete buffer the data is being processed. On the right of this cyclic buffer image representation, there are the attributes to adjust the algorithm and then the output. The green plot on the top is the filtered output.
2012/11/21
How to see the beam in the storage ring
I have written some times about how a synchrotron works (underlining that I am not a physicist and what I write is what I understood from the explanation of other people). Also I have wrote about how can we saw the beam or its effects: visible beam, first xrays or fluorescent screens
But there is another way to see the beam: using an scope.
Today I have ask to know a little bit more what we can see from an scope that we are reading the signal:
This signal is get from a Fast Current Transformer (FCT) located in sector 02:
Very close to the dcct that is giving us the current of the beam in the machine status. This FCT is an inductor surrounding the vacuum chamber and what we see in the scope is the inducted current by the primary current given by the electron bunches.
In the scope picture we can see the bunches in one turn (about 900ns). But a bunch is not one of this eleven groups in the signal. They are composed by bunches.
May can help to see that by plots taken with taurus:
Zooming on one of this groups:
With this last picture we can see the bunches themselves. The bunches are separated by 2ns, and the linac is shutting in groups of 32 consecutive bunches and a gap of 24ns.
Also I have ask why this groups of bunches have different shapes like:
This 3 examples has been taken over different times during today's start up of the machine. This shapes can be explained because fine configuration or how the equipments works and their efficiency. In the best case, in a world of the theory, this groups would be absolutely squared.
But there is another way to see the beam: using an scope.
Today I have ask to know a little bit more what we can see from an scope that we are reading the signal:
vncviewer of an Agilent DSO80804B
But, 2 questions: who this signal is get and what does this mean?This signal is get from a Fast Current Transformer (FCT) located in sector 02:
In the scope picture we can see the bunches in one turn (about 900ns). But a bunch is not one of this eleven groups in the signal. They are composed by bunches.
May can help to see that by plots taken with taurus:
Equivalent to the vnc, but getting the data from a tango device server.
Also I have ask why this groups of bunches have different shapes like:
2012/08/16
DevEncoded and Basler Ace in Taurus
Sometime a go, I have received the request to control a new model of cameras The Basler Ace acA1300-30g{m,c}. Yes both types: monochrome and colour. The most common cameras to look at the beam are the Basler Scout scA1000-30gm and the scA1300-32gm (yes until now we have only supported monochrome cameras in the service of beam diagnostics by imaging.
To take the pictures of this Basler Scout we have used and contribute using the Soleil's device ImgGrabber, and to analyse those taken pictures we have used the ImgBeamAnalyzer (also originally from Solei).
How we look at the images? Long time a go we have start working with Qt and as a result we have used Qub widget from esrf. This widget has been integrated in tau that has been renamed to taurus.
As an example, I have saved hundreds of snapshots of the gui with beam. The latest publish here was to celebrate the first x-ray beam at alba, but I can share much more of those pictures:
But the software we used doesn't support the Ace cameras. There is a newer software that makes deprecated this software and many of the synchrotrons that are using tango are migrating to LImA (Library for Image Acquisition). This is a very powerful software specially focussed in detectors.
This ccds that I'm talking here are not usually "detectors" in a synchrotron sense. They are not the end of the beamline from where the data of the experiment is collected. The most often activity of this cameras is beam diagnostics previous to the experiment to make sure that everything is on the expected place and the shape of the beam have the desired characteristics. Then they are used very often as a live video image in the graphical user interface (gui) from which I have placed images before.
Another situation is during beam commissioning when this cameras are used much more like a detector during a scan using Sardana. On this situation is not that important the image availability during the measurement, the most important this is the beam study of each picture and the statistical characteristics from the beam.
Then we have two very different user cases. In the upgrade to LImA both must be implemented, and yes they already are.
In the LImA Basler device the Ace cameras are already supported and there are some attributes that allows the possibility to have a gui like we have. But what was the problem? This attribute are from the "new" tango data type DevEncoded. Our system didn't support yet this data type and this has been an august development (almost the best month to work, almost every one on holidays and no one is bothering your development).
What make this data type special? This data type can contain almost anything: basically is a list of an string together with a list of bytes, where the string says what and how the things are codified in the list of bytes.
In the case of the LImA's "video_last_image" attribute, the DevEncoded is given as a "VIDEO_IMAGE" format. An issue of this flexibility is the naming, we are starting putting names without a rule and in the future this will be very difficult to unify and harmonise.
LImA is hosted in a git repository and in the file "applications/tango/LimaCCDs.py" there is a method 'read_video_last_image()' where this "VIDEO_IMAGE" is codified.
Recently this DevEncoded format has been integrated in taurus.
And as we want to see the images using guiqwt who is integrated in taurus using an extension of this software, we have integrated this DevEncoded as a interpretable data from taurus.
The result: we've been able to take and show images from a monochrome Basler ace camera:
To take the pictures of this Basler Scout we have used and contribute using the Soleil's device ImgGrabber, and to analyse those taken pictures we have used the ImgBeamAnalyzer (also originally from Solei).
How we look at the images? Long time a go we have start working with Qt and as a result we have used Qub widget from esrf. This widget has been integrated in tau that has been renamed to taurus.
As an example, I have saved hundreds of snapshots of the gui with beam. The latest publish here was to celebrate the first x-ray beam at alba, but I can share much more of those pictures:
But the software we used doesn't support the Ace cameras. There is a newer software that makes deprecated this software and many of the synchrotrons that are using tango are migrating to LImA (Library for Image Acquisition). This is a very powerful software specially focussed in detectors.
This ccds that I'm talking here are not usually "detectors" in a synchrotron sense. They are not the end of the beamline from where the data of the experiment is collected. The most often activity of this cameras is beam diagnostics previous to the experiment to make sure that everything is on the expected place and the shape of the beam have the desired characteristics. Then they are used very often as a live video image in the graphical user interface (gui) from which I have placed images before.
Another situation is during beam commissioning when this cameras are used much more like a detector during a scan using Sardana. On this situation is not that important the image availability during the measurement, the most important this is the beam study of each picture and the statistical characteristics from the beam.
Then we have two very different user cases. In the upgrade to LImA both must be implemented, and yes they already are.
In the LImA Basler device the Ace cameras are already supported and there are some attributes that allows the possibility to have a gui like we have. But what was the problem? This attribute are from the "new" tango data type DevEncoded. Our system didn't support yet this data type and this has been an august development (almost the best month to work, almost every one on holidays and no one is bothering your development).
What make this data type special? This data type can contain almost anything: basically is a list of an string together with a list of bytes, where the string says what and how the things are codified in the list of bytes.
In the case of the LImA's "video_last_image" attribute, the DevEncoded is given as a "VIDEO_IMAGE" format. An issue of this flexibility is the naming, we are starting putting names without a rule and in the future this will be very difficult to unify and harmonise.
LImA is hosted in a git repository and in the file "applications/tango/LimaCCDs.py" there is a method 'read_video_last_image()' where this "VIDEO_IMAGE" is codified.
Recently this DevEncoded format has been integrated in taurus.
And as we want to see the images using guiqwt who is integrated in taurus using an extension of this software, we have integrated this DevEncoded as a interpretable data from taurus.
The result: we've been able to take and show images from a monochrome Basler ace camera:
Using a fake beam (a image of the beam printed in a paper and placed in front of a ccd) we can check how it behaves with different beam types:
Very glad and satisfied when you see this images. It doesn't look special, but knowing the effort behind that the view is different.
2012/08/08
Refactoring
The software has its live cycle during which the development and bug fixing are link to several variables, some under control or the developer but many are out of this control. I'm not talking much about the time dedicated to the development during a project, but too. Those variables are out of control specially in the bug fixing time, when the speed and extreme programming are more present.
When some day, some how, some one decides that something is urgent, or more urgent than the other urgent things. At that time, the development will done because of an heroic effort and all bugs will be fixed fast (hopping that the bug fix will not produce any other side effect).
How old must be a code to consider refactoring? It could depend on the number of requirements coming from the heaven. I mean when the number of times that some one is very urgent to codify, the developer does it, but with a price. And this price is a quality loss, until it becomes untenable. When any bug fix requires longer and longer time due to the side effects of the modification.
But there is a moment, that triggers an alert for the project manager that says refactoring is mandatory: when the design have almost nothing in common with the code: when code smell.
Then I found a book that looks nice for this task: "Refactoring: Improving the Design of Existing Code" Fowler, Martin (1999). More than ten years old book, older than the code I want to refactor, live irony.
When some day, some how, some one decides that something is urgent, or more urgent than the other urgent things. At that time, the development will done because of an heroic effort and all bugs will be fixed fast (hopping that the bug fix will not produce any other side effect).
How old must be a code to consider refactoring? It could depend on the number of requirements coming from the heaven. I mean when the number of times that some one is very urgent to codify, the developer does it, but with a price. And this price is a quality loss, until it becomes untenable. When any bug fix requires longer and longer time due to the side effects of the modification.
But there is a moment, that triggers an alert for the project manager that says refactoring is mandatory: when the design have almost nothing in common with the code: when code smell.
Then I found a book that looks nice for this task: "Refactoring: Improving the Design of Existing Code" Fowler, Martin (1999). More than ten years old book, older than the code I want to refactor, live irony.
2012/01/26
Ring magnetic field compensation
A long time a go we have seen that when the magnets of the storage ring are cycling the beam on the linac "moves". I remember a day in the control room of Alba doing a test on the cycling procedure (no beam in the storage, the machine was mine) I hear the scientist working on the linac, just in a computer besides the one I was using, saying "We are not changing anything and the beam is moving horizontally!"
AFAIK the problem is coming from the thing that the bending magnet of the storage ring (and the same thing with each family of sextupoles) are powered from the same power converter. There is one power converter in sector 1 for all the (32) storage ring bending magnets. Each magnet is a solenoid, but the cable to distribute the power to all of them can be saw globally like on big solenoid with one turn.
In the storage ring, there are also 9 families of sextupoles, each of them powered by converters also placed in sector 1, with the same situation than the bendings. This means that, globally, we have 10 solenoids of one turn of 268.8 meters.
(There are also 14 families of quadrupoles, but in that case there is one power converter per sector and is not contributing to this problem.)
How to compensate this? The problem is not when the storage ring magnets are cycling, the issue is when this magnets have set different currents due to many different purposes forces to reconfigure the linac. The easy and smarter solution perhaps is to install another turn to compensate the effect.
Then when the setting of the storage changes, the current of one extra power converter changes to cancel the effect on the linac. But calculate and apply new current values it's a boring thing for a human. Often I say the repetitive and boring task are good for computers, and gives free time to humans.
One detail more, some of the magnet turns goes clockwise direction in the storage ring, and some others goes in counter-clockwise direction. That means that they already cancels some of their effects but 0 effect is not grant. That the goal of this compensation turn.
AFAIK the problem is coming from the thing that the bending magnet of the storage ring (and the same thing with each family of sextupoles) are powered from the same power converter. There is one power converter in sector 1 for all the (32) storage ring bending magnets. Each magnet is a solenoid, but the cable to distribute the power to all of them can be saw globally like on big solenoid with one turn.
In the storage ring, there are also 9 families of sextupoles, each of them powered by converters also placed in sector 1, with the same situation than the bendings. This means that, globally, we have 10 solenoids of one turn of 268.8 meters.
(There are also 14 families of quadrupoles, but in that case there is one power converter per sector and is not contributing to this problem.)
How to compensate this? The problem is not when the storage ring magnets are cycling, the issue is when this magnets have set different currents due to many different purposes forces to reconfigure the linac. The easy and smarter solution perhaps is to install another turn to compensate the effect.
Then when the setting of the storage changes, the current of one extra power converter changes to cancel the effect on the linac. But calculate and apply new current values it's a boring thing for a human. Often I say the repetitive and boring task are good for computers, and gives free time to humans.
One detail more, some of the magnet turns goes clockwise direction in the storage ring, and some others goes in counter-clockwise direction. That means that they already cancels some of their effects but 0 effect is not grant. That the goal of this compensation turn.
A device server class with the name "RingMagnetCompensarion" is the responsible in the control system to calculate the current to set in the power converter for the compensation turn. This device has some properties:
- [Counter]ClockWise: two lists of magnet device server names
- MagnetAttr: name of the attribute to read/subscribe on the magnets of the lists
- CompensationMagnet: name of the device server where the calculated compensation current will be written
- AttrThreadSleep: Expert property to fine adjust of the refresh on the threaded option of the magnets current refresh
This Magnet class, checks if the attribute to read in the power converter device server have events or not. In case of event, it subscribes to it, but if not, if does a polling to read if the current have changed.
When a magnet object receives from its attrManager the notification of a readback change, this is propagated to the magnetGroup parent object. Why? Because this with update the cw/ccw list of currents and update the summatory. With this summatory updated, it's time to notify the RingMagnetCompensation device to calculate the formula:
Then only rest the event propagation and to write in the compensation power converter device if it's necessary.
Issues: One detected issue that has been already fix is when the magnets are cycling. The compensation power converter range is between 50A to -50A, and during cycling procedure this can be out of this range. Then each magnet object checks if the subdevice have received a command Cycle() to cut the propagation of readback change.
Another issues is the SlewRate of all the power converters involved. This has not tested yet, but it's possible that the speed changing the current in the compensation power converter would be not faster enough to a live response against the current changes on all the magnets in the lists.
2011/12/22
Sardana control application
Yesterday, one of the gurus of Tango and project leader of Sardana presents an internal seminar for the control system section in Alba:
One of the images that I like more to represent the meaning of this Sardana package is one:
In the upper layer we have the area of the presentation layer, where we develop taurus. Is the screens with the user interacts. How you manage the coordination of the movements together with the acquisition in not the business of the final user. Even more, they don't case about how you did it, they only want the thing running with reliability.
Also there is the possibility for the user to have a user interface based in a command line screen, and for this there is spock (is an ipython console with the philosophy of spec):
But furthermore than a console usage of a beamline, the GeneralBeamlineGui is the best example of the use of taurus, together with Sardana to have a full control of a beamline to do the experiements. With a layout of the beamline the user can click on the elements to know the details of each instrument in the beamline.
One of the images that I like more to represent the meaning of this Sardana package is one:
In the upper layer we have the area of the presentation layer, where we develop taurus. Is the screens with the user interacts. How you manage the coordination of the movements together with the acquisition in not the business of the final user. Even more, they don't case about how you did it, they only want the thing running with reliability.
Also there is the possibility for the user to have a user interface based in a command line screen, and for this there is spock (is an ipython console with the philosophy of spec):
But furthermore than a console usage of a beamline, the GeneralBeamlineGui is the best example of the use of taurus, together with Sardana to have a full control of a beamline to do the experiements. With a layout of the beamline the user can click on the elements to know the details of each instrument in the beamline.
2011/09/04
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?
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.
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.
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 |
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.
Subscribe to:
Posts (Atom)
