Open sf-migrator-bot opened 11 years ago
Original comment by: cpascual (http://sf.net/u/cpascual)
Original comment by: reszelaz (http://sf.net/u/zreszela)
Original comment by: reszelaz (http://sf.net/u/zreszela)
Original comment by: cpascual (http://sf.net/u/cpascual)
Original comment by: cpascual (http://sf.net/u/cpascual)
Original comment by: cpascual (http://sf.net/u/cpascual)
Original comment by: reszelaz (http://sf.net/u/zreszela)
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:
Reported by: guifrecuni ( http://sf.net/u/guifre )
Original Ticket: sardana/tickets/22