Lima controller "moving" when lima server restarted about sardana-limaccd HOT 14 CLOSED

Yes, it looks like a bug that we can acquire if the channel is MOVING. Most probably it is related to sardana-org/sardana#1316. I would even say the Tango state machine of the MeasurementGroup should prevent the Start command to be executed when it is in MOVING (even if sometimes it is a little bit tricky to keep in sync the Sardana kernel object state with the Tango device state).

Furthermore, on the last Sardana follow-up meeting @13bscsaamjad raised a similar issue about not allowing the MeasurementGroup to start when one of its channels is FAULT.

I suggest we move discussion on this particular point to the Sardana project. I think that sardana-org/sardana#1316 is a good starting point.

from sardana-limaccd.

Together with @rhomspuron, we found the following (at least when using lima 1.9.x):

As far as we understood, last_image_saved should report -1 after a prepareAcq() is executed.
However, after lima is restarted it also reports last_image_saved=-1. This makes it a little hard to identify the Lima state.

One suggestion is to maintain state in the controller to know if it has executed a prepareAcq or not.

Needs further investigation

from sardana-limaccd.

Hi, I'm not able to reproduce the MOVING state with current controller version (1042195), I got ON.

from sardana-limaccd.

What lima version do you have? I am using 1.9.x
I suspect (but I cannot confirm) that Lima behavior changed in the past concerning the initial value of variables like the last_image_saved.

from sardana-limaccd.

I'm using Lima version 1.9.7. Nevertheless, it looks like commit d9110de has also fixed this bug. Could some of you please confirm that latest controller version is now working as expected?

from sardana-limaccd.

I will check it

from sardana-limaccd.

Sorry @jordiandreu but the bug is still there in the latest master
AFAIK, the problem comes from the StateOne() method.

When I start sardana and ask the state of the lima channel i have the following state:

• acq_status = "Ready"
• last_image_saved = -1 (which implies images_to_save = True)
• _aborted_flg = False

In this state, the StateOne method should return MOVING

I don't know why when we tested before with your simulator we could not get it.
My first guess is that sardana needs to be restarted as well

from sardana-limaccd.

Certainly, now i can reproduce this error by:
1.- Start the LimaCCD server.
2.- Start Pool and Macroserver.
3. Start spock client and request controller and experimental channel states.

What I have found is that the experimental channel state is MOVING, but the controller state is ON.

from sardana-limaccd.

The state of the controller should no change. We can check the first implementation of the LimaCoTiCtrl to check if the logic is similar, maybe is a problem that we did not detect and Sardana has a bug which allows to start the channel in moving and for that reason it works :)

from sardana-limaccd.

Indeed @rhomspuron. I agree. I think I commented this to @reszelaz and he agrees that sardana should not start an acquisition if at least one channel is not ready (moving for example).
For now we profit from the bug ;-)

from sardana-limaccd.

Hi,

I also hit this problem. Could you advice if stopping the channel is a good workaound for this issue:

Door_moke_1 [2]: hamamatsu01.status()
        Result [2]: 'hamamatsu01 is Moving\nThe LimaCCD is acquiring'

Door_moke_1 [3]: hamamatsu01.stop()

Door_moke_1 [4]: hamamatsu01.status()
        Result [4]: 'hamamatsu01 is On\nThe LimaCCD is ready to acquire'

Many thanks!

from sardana-limaccd.

FYI, since sardana-org/sardana#1594 Sardana will prevent starting MeasurementGroup when its state different than On or Alarm. This includes the above discussed Moving state.

from sardana-limaccd.

FYI, since sardana-org/sardana#1594 Sardana will prevent starting MeasurementGroup when its state different than On or Alarm. This includes the above discussed Moving state.

Cool! Thanks @reszelaz

from sardana-limaccd.

This should be fixed since #11

from sardana-limaccd.