sardana-org / sardana

Moved to GitLab: https://gitlab.com/sardana-org/sardana
39 stars 51 forks source link

Pseudomotor misbehaviour (SF#22) #22

Open sf-migrator-bot opened 11 years ago

sf-migrator-bot commented 11 years ago

From RT ticket https://rt.cells.es/Ticket/Display.html?id=32166

Fri Apr 26 18:08:49 2013 fbecheri - Ticket created

An exception appears everytime we write the position of the pseudomotor Gap. (this is what we have tested)

The motors Z1,Z2,Z3,Z4 have not any software limit

The Pseudos Gap, Taper, Offset and Symmetry have software limits.

For some reason during the write-procedure there are some strange write-values that lay out of the limits (always 675, 1250 or 2500!)

The movement starts and ends correctly but the exceptions always are launched.

We should investigate it.



Fri Apr 26 20:41:32 2013 gcuni

The problem is still there, but we did a workaround that catches the exception so there are no more side effects.

We will investigate next week which is the root of the problem that computes a wrong 'w_value' for the pseudomotors


Thu May 02 16:25:52 2013 zreszela

Hi,

the issue which I mentioned on the todays's controls meeting is not true.

At bl04, we do not have any problems with the pseudomotors after doing an upgrade of sardana.

Our problem was related with loosing the position of the physical motor.

Saludos!

Zibi


Fri Jun 07 10:06:55 2013 fbecheri

We have found that when we write the pseudo motor Gap of the AppleII an exception is launched but not catched:

SardanaDevice.py _set_attribute_push attr.set_write_value(w_value)

Step by step the process is: 1) We write the Gap pseudomotor 2) The method “calc_physical” of the motor-controller “PseudoAppleII” is called four times; once for each index = 1,2,3,4 3) At the same time, the method “calc_pseudo” is called with a new-Z1 but the old Z2, Z3 and Z4. Then with the new-Z1 and the new-Z2 but the old Z3 and Z4. And so on

The pseudo are calculated according to some formulas: gap = (z1+z2)/2.0 - (z3+z4)/2.0 symmetry = (z2-z1)+(z3-z4) offset = (z1+z2)/4.0 + (z3+z4)/4.0 taper = (z2-z1)-(z3-z4)

If we write only the new value Z1: write value w_z = z1+d we find these partial write-values: w_gap = (z1+d+z2)/2.0 - (z3+z4)/2.0 = gap+d/2 w_symmetry = (z2-z1-d)+(z3-z4) = symmetry - d w_offset = (z1+d+z2)/4.0 + (z3+z4)/4.0= offset+d/4 w_taper = (z2-z1-d)-(z3-z4) = taper-d

The software limits on the pseudo “taper” and “offsets” cause an exception because the value tape-d is out of the sw-limits.

When all the new-write-Z-motors arrive everything works fine.

The problem is due to the combination:

“calc_pseudo”  faster than the four “calc_physical” (the four physical motor are calculated in a sequence , not at the same time)
software limits on pseudos

Reported by: guifrecuni ( http://sf.net/u/guifre )

Original Ticket: sardana/tickets/22

sf-migrator-bot commented 11 years ago

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

sf-migrator-bot commented 11 years ago

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

sf-migrator-bot commented 10 years ago

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

sf-migrator-bot commented 10 years ago

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

sf-migrator-bot commented 10 years ago

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

sf-migrator-bot commented 9 years ago

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

sf-migrator-bot commented 8 years ago

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