FERMI@Elettra: First coherent emission

Last year we put beam in the booster ring (at December 21th, from the linac transfer line to a few meters in the booster) and this year we cannot do the injection to the storage ring due to reasons that are only rumours listened in the corridors of Alba.

But the good news arrives from Elettra, and one of their on going projects: the Fermi. Also they have a third generation light source, but they are doing a fourth generation one: a FEL. Last Monday they get the goal like we did with the booster, but with next generation machine (and all of this next generation are under construction).

scopes device server improve (III)

Again, new commit (r2509) to the tango-ds svn. This have some improvement more, trying to alow the user to do what they want, but with some reliability about it.

The initial design when many attributes (read_attributes([]))was requested at the same time, they was Ask() to the lower level device PyVisa, one by one. And this means one query per attribute:

On the last improvement, the device does one query to the instrument when many things are requested at the same time:

But with this, the issue is when you use a small scope (and I mean small, one with a small embedded system inside) some types of measurements block the instrument. When this multiple request is too big for this scope, a time out occurs. But for a bigger scope this can be not a problem, or the problem in a different number of multiple requests.

What has been committed today add a new attribute ('QueryWindow') to the device class to group this multiple query in smaller requests. Then configuring it, this allows to query one by one, in a really small scope; or all at the same time if the scope can support it. The image of the design can be:

Also another attribute has been introduced ('TimeStampsThreshold'). Even if the requests are grouped or not, if the client starts with many requests of the same value too often, the problem is shown again. Only requesting one attribute, but 10 times per second, depending on the scope can be an issue or not.

The solution I propose is cache values, with an attribute saying expiration time of the value. This means, when the client likes to read a value that has been never before read, this will be included in the list of attribute to read. When the answer is back, the data is saved with the time stamp of when it was read.

Some time in the future, the client can ask again for this value. This could happen 100ms after the first read, or 10minutes. The device will check the time stamps of the last read, and if it is too old, this will be read like in the case before. But if this is too short, the answer will be the previous value, and the tango attribute will have the time stamp of when this was read. This last part is really important to avoid confusion to the user: if the value is from the past, the user should be able the realize that. Also if more than one client request values to the device, this doesn't increase the number of hardware reads if they are asking the same thing.

I hope with this changes, the usage of this device class will be better. We will see if something has to be change, and I'm open to other ways to solve this.

Update (2010/12/21): commit 2510

• When a measurement is not possible, incomplete or stopped, the result is 9.99999e+37. Before this triggers an exception, but is better to returns NaN.
• Fix the dictionary set for the cache on the start up
• Add a filter for the spectrums attributes
• After a time out the PyVisa goes back to its default value, check it before ask to it.

Update (2010/12/22): commit 2511

• Bug fix in the group method. It cuts the last elements if they wasn't in the same length of the cut. ex: group([1,2,3,4],3) was excluding the last incomplete element, now it is returning [(1, 2, 3), (4,)].
• Reduce the filters to one iteration instead of one per filter.

Wikileaks pursuit

There is a lot of information about the wikileaks pursuit on the web. Just I read this funny comic.

Don't kill the messenger. After Wikileaks revelations, it seems that the problem is when secret information is shown. The problem is that the citizens are able to have proves of what we suspect: too many times our democratic representatives lie us. This informations, with many more revelations, are the final proof that they lie on purpose!

air traffic controllers

After some days with much information about the air traffic controllers in Spain, I start to google a little bit more about this thing.

The first thing I miss in the tv and newspapers is the "explanation" of this workers. Many times I can see in the tv images of passengers in the airports with problems to fly, or angry people screaming about this, and the government explanations of what they did. But where is the voice of the militarized workers because of a declared "state of Alarm" of the country? On the internet is the place, I don't know why this is not also said in the news.

There is another page with information from this group. The mass media are saying very different things about them. The explanations on the press says that this air traffic controllers lives in a paradise and they have unconfesable privileges. I have listened in many tv news that their salary is 4 times bigger to the Spanish government president, in average 350k€/year. But seems that they are answering that this is very far from real because it's between 50k€ and 120k€. But I didn't listened that in the news.

Neither I have listened about the number of hours they work per year. And important, what means the work our or what counts as a work ours. In my job, I do in my journey what I have to do, if the company want's me after this time, is on my decision. They explain this is not like that.

Also I like to point about the information that they are blocking the contract of new workers. I don't understand this point. I never saw in a company that the workers representation have voice in the interviews (much less to have vote in the contract process). This link also explains something about that.

If you are ill? As the media says, a big number of them was ill at the same time last Friday. But the air traffic controllers explains that if they are ill they have to work this our in another moment. Do you have this condition in your job? If you have a flu or you broke your leg, do you have to compensate next months for the time that you are offline?

Finally I don't understand why the journalist are not telling this. At least to contrast the information. And also this problem with the air traffic controllers is not new from this year. Even if the AENA's benefits or losses are not from this year, why this government likes to fix it just now? Aren't there any other urgent things in this country to fix? Or is because the privatization of this AENA company. Do we only make a public company work before sell it? I think is better to do always and then the benefits can be from the beginning...

Other information about this, can be followed using the alternative press medias, like:

Abajo el Estado de alarma. Solidaridad con los controladores

El Soylent Green es gente

Militarizar los mercados

scopes device server improve (II)

New commit to the repositori of tango device servers for the PyVisaInstrumentWrapper, in particular for the scopes class. This improvement will be also propagated to the other classes, but first I like to understand some behaviour.

Stressing an instrument with this code, I realize that something depends on the instrument capabilities. In one model of the scopes I test it (the expensive one) it works correctly. With something like:

import PyTango

scope = PyTango.DeviceProxy(scope_name)

attributes = scope.read_attributes(scope.get_attributes_list())

That means "ask everything to the scope" there is one request per channel (the plot data) and one request for all the other scalar values. The response is very much faster than before.

The issue is when I try it with another simpler scope (a cheaper one). I receive a timeout because of the reading. This make the device to decay to fault state, and the reconnection procedure relives it to on state.

Looking on the screen of the scope the messages, after the timeout, are: "Undefined Header" and later on "Query Interrupted". But with less attributes concurrent to read (about 10) it works. A probable solution is subdivide the queries, but how to know the number of possible attributes to be read once?

scopes device server improve (I)

There is a tango device server for remote control of oscilloscopes and similar instruments. This has been written a long a go (first commit in may 2009) and extended a few times adding other types of instruments (last commit is from august this year, 2010). Now this server has not only the "scope" class, also includes "RealTimeSpectrum" analyser, arbitrary "FunctionGenerator", and "RfSignalGenerator".

But now the issue is in the attributes readout. I general, for all this classes, when you ask many things this is asking to the low level "Visa" device and transmitted to the hardware. Even if you ask many things at the same time (this often happens with the oscilloscopes) each is ask separately.

First improvement: multiple readings.

Apart from the read_attribute() method of the device API, there is a read_attributes([]). Doing a call to the first option, the flow calls previous methods like always_executed_hook() and read_attr_hardware(). This last one, have a list of the attributes who can do a pre-read action. With the current release, the multiple attribute read, is not optimum.

The real read is when the internal methods read_XXX() (where XXX means the name of the attribute) is called. This is, when the multiple-reading is executed, the device acts in the same way than do a simple-reading n times.

The visa protocol, allows the possibility to concatenate queries to the hardware below. With this read_attr_hardware() we can centralize in the code the common way to read and optimize it.

The input parameter of the read_attr_hardware() is a list of integers. With the MultipleAttribute class I would have the attribute objects to know to who the read action is requested.

Time to code and test it.

Machine start up

How many times we should wrote this subject to a post? This project of a blog has been a bit abandoned due to a time with a hard work, where fast was one of the goals.

I hope, now, with the project delayed for reasons not related with the workers and the work we do, I'll find time to write a little bit about software design, cryptology and this things that I prefer that fight a despot management.

The start up is delayed, but every thing is prepared, there is no official explanation for it.

ALBA synchrotron back to normal

This Monday, the workers assembly gives the ok to a negotiated salary cut according to the decree law that affects the public sector in Spain. This negotiated solution is progressive and minimizes the impact of the cuts to the lower salaries.

I hope, the management finally realizes that the good behaviour with the workers is the best way to have a synchrotron working. All of us have the same objective: to have a synchrotron facility online!

Strike and protest actions at ALBA synchrotron

After a long time without write here I like to reactivate it, but not for good news. After a long time trying to focus and speed up the synchrotron project, we had a "Drop of water that spills the glass".

https://sites.google.com/site/comitedempresacells/

This is not because of the salary cut, this is because of the management of the synchrotron how doesn't like to negotiate the progression of this cut. They said a "proposal" or a 5% cut equal for all. They said, my proposal or my (worst) second proposal, without accept any type of negotiation.

The issue is not the cut, the issue is the attitude of the management against the workers.