sf-migrator-bot
commented
8 years ago Answer from Carlos Pascual on Tue Mar 01 10:00:39 2011:
Short answer: In some simple cases you can get a rough estimation. In the general case it is impossible to give an estimation.
For example, in a ascan, you can sum the acquisition times, but in the general case of scans, the number of steps or the acquisition times may not even be fixed when launching the macro.
Regarding moving motors (e.g. in scans), it is only possible to estimate the time if they provide a "velocity" parameter (also the pseudomotors).
So it must be clear that any estimation will not be reliable except in certain specific cases (e.g. scans with well defined number of steps and well defined acquisition times and using motors which provide velocity info).
Maybe we could add a method in the macro class that can be called to provide an "ETA". Then we could implement an API in the macroserver/door so that clients can make a query by sending the macro command. Also, if we included such a method, it could also be used by scans in order to provide an updated ETA on each step. But in my opinion it is too much trouble for something that will only work in trivial situations (i.e., in those in which the user could do the calculations him/herself).
I personally prefer to see a progress bar telling me that X steps out of Y have been done instead of seeing an ETA that I can trust no more than I trust Windows' copy file remaining time estimation.
Original comment by: reszelaz (http://sf.net/u/zreszela)
This was requested by Konstantin Klementiev (see internal Alba's ticket RT#15420).
It would be nice to have a mechanism to estimate a time of a single macro, before starting its execution/
Also other method for estimating the time of sequence.
Reported by: reszelaz ( http://sf.net/u/zreszela )
Original Ticket: sardana/tickets/419