Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lima controller "moving" when lima server restarted #5

Closed
tiagocoutinho opened this issue Feb 22, 2021 · 14 comments
Closed

Lima controller "moving" when lima server restarted #5

tiagocoutinho opened this issue Feb 22, 2021 · 14 comments

Comments

@tiagocoutinho
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@tiagocoutinho
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

I will check it

@tiagocoutinho
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

reszelaz commented Feb 24, 2021

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

This should be fixed since #11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants