Open izadworny opened 7 years ago
It looks to me like a problem with the value returned by the 0D channel. I suspect that the ReadOne
method returned a string instead of a float.
Maybe answers to these questions will make us closer to finding the reason of this issue.
In active measurement group there are 8 0D channels:
Name Type Controller Axis
-------------- ----------------- ---------------------------- ------
IMONV1 ZeroDExpChannel BL-04BM-DIA-AMPMCU1 1
IMONV2 ZeroDExpChannel BL-04BM-DIA-AMPMCU1 2
IMONV3 ZeroDExpChannel BL-04BM-DIA-AMPMCU1 3
IMONV4 ZeroDExpChannel BL-04BM-DIA-AMPMCU1 4
M1TEMP ZeroDExpChannel bl-04bm-plc 1
SR ZeroDExpChannel TANGO-R1 1
grpitch-enc ZeroDExpChannel bl-04bmcab04-ctl-ipapenc01 4
plmpitch-enc ZeroDExpChannel bl-04bmcab04-ctl-ipapenc01 2
Name Type Class Module
---------------------------- ----------------- ------------------------------------- -------------------------------------
BL-04BM-DIA-AMPMCU1 ZeroDExpChannel TangoAttrZeroDController TangoAttrZeroDCtrl
bl-04bm-plc ZeroDExpChannel TangoAttrZeroDController TangoAttrZeroDCtrl
TANGO-R1 ZeroDExpChannel TangoAttrZeroDController TangoAttrZeroDCtrl
bl-04bmcab04-ctl-ipapenc01 ZeroDExpChannel IcepapEncoderZeroDController IcepapEncoderZeroDCtrl
IMONV1, IMONV2, IMONV3, IMONV4 - those are Keithley6482 picoammeters' channels. They read current from diagnostics elements, M1TEMP - mirror 1 temperature from PLC, SR - storage ring current from calculating device server, grpitch-enc, plmpitch-enc - monochromator grating and mirror encoders (IcePAP). First 6 0D channels read from Tango devices, grpitch-enc, plmpitch-enc read directly from IcePAP.
This issue has happened once. As you can see there are no errors or warnings on ascan output, it just froze. Ascan started at 22:49:34, the errors from Pool were reported at around 22:56 and the aborting took place next day in the morning at about 8am when we noticed that ascan stopped on 40th point.
Good, that means that it is is not related to the abort. It was aborted afterwards.
With so many channels it will be hard to track which one gave the wrong readout.
At some convenient moment to you could you test the following: Modify one of the controllers, so that it returns a string that can not be casted to a float e.g. "error". Make it return this string in the middle of the scan. Then, if you observe the same behavior i. e. frozen scan and the same exception traceback in the pool it would confirm my theory.
Yes, you are right. We can reproduce exact the same behavior when the controller returns a string instead of float. Now we can modify controller to avoid this error. Thank you for your help.
For the moment a fix on the controller level is a good workaround. As a general solution I think that we should protect that in the Sardana core. So at least the scan does not freeze. Let's keep this ticket opened until a proper solution is implement.
Thanks to you for the report!
There was a problem with ascan macro on out beamline. It froze unexpectedly. This is ascan output. Ascan was started at 22:49:34, should have 50 measurements and end after about 10 min but "Ctrl-C" was pressed after few hours.
I have checked:
Has anyone have similar issue? What could be the reason of this issue?