Open reszelaz opened 6 years ago
This taurustrend of the measurement group and the physical motor state run in parallel to a step scan. It polls the state attributes with a very high frequency (every 10ms):
The blue areas are the measurement group acquisitions. We can already see that the second acquisiton on the trend happens while the physical motor changes its state - this should not happen. Fortunatelly the scan was not affected. However the move after the fifth acquisition does not finish, and the scan hangs. We can see that after these move, during a while, the motor state fluctuates between ON and MOVING.
At ALBA we have discovered a problem in the following scenario of pseudo motors:
The problem is that from time to time a sequence of very fast movements e.g. a loop of mv macros or simply a scan gets hung.
After debugging this problem we have discovered the following.
I believe that the same bug could be reproduced even if the exit_offset calc_pseudo would not read the position using the proxy, but another client could read the position e.g. PMTV widget in between the steps 2 and 4.
This problem was reported on the last Follow-up meeting, and now, since we already know the origin of it I report this issue just to share with you that this kind of deadlocks may happen. We have applied a local workaround, making the perp pseudomotor reading the bragg position from the Taurus cache, after a prior adding of a dummy listener to the position attribute. This forces Taurus to listen to the Tango events.
It is not sure if we can do anything in Sardana, well within the current design, in order to avoid this kind of problems. The tricky part is that the controller (plugin) by itself report that is MOVING. I propose to leave this issue open for a while so we get familiar with it but if there won’t be any ideas on how to improve it, we could close it as won’t fix. Meanwhile, @rhomspuron will investigate if there is any bug in the controller and hopefully report here any news about it:) Thanks!