Lima controller "moving" when lima server restarted

[tiagocoutinho]

Hi,

1. I start lima device server.
2. start sardana with a pre-configured lima ctrl and a lima channel
3. in spock, read the state or status of the lima ctrl or lima channel gives "MOVING"

IMHO, it should be ON.

[tiagocoutinho]

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

[jordiandreu]

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

[tiagocoutinho]

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.

[jordiandreu]

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?

[rhomspuron]

I will check it

[tiagocoutinho]

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

[jordiandreu]

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.

[rhomspuron]

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 :)

[tiagocoutinho]

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 ;-)

[reszelaz]

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.

[reszelaz]

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!

[reszelaz]

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.

[tiagocoutinho]

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

[tiagocoutinho]

This should be fixed since #11