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

horiba-ihr320: state changes on restart #10

Open
ddkohler opened this issue Sep 13, 2022 · 7 comments · May be fixed by #19
Open

horiba-ihr320: state changes on restart #10

ddkohler opened this issue Sep 13, 2022 · 7 comments · May be fixed by #19

Comments

@ddkohler
Copy link

User complaint

Sometimes when you restart the monochromator daemon, the settings change (e.g. slit position)

This has been problematic because such property changes are easily missed when restarting daemons. It's likely that the slit position changes to some hardware default position after a hard restart, and state is updated with the position it reads.

I am proposing, that, on daemon startup, we actively set slits/whatever else to positions in the daemon state (if state has valid positions). Of course open to other suggestions...

@ksunden
Copy link
Member

ksunden commented Sep 13, 2022

the thing is, we do try to do that, soooo

@ksunden
Copy link
Member

ksunden commented Sep 13, 2022

@untzag
Copy link
Member

untzag commented Sep 13, 2022

We should loop and retry until correct. We do this in other daemons. Hardware sucks, make it work 😢

@usui-bluec
Copy link

usui-bluec commented Feb 3, 2023

Hello! I faced the same problem when i tried to operate micro-hr using this program.
I don't know if this works at all, but I was able to initialize it successfully by using

loop.run_until_complete(self._reset_position()) 

at the end of the home function in _horiba_mono.py to call the task.
I hope this works !

@untzag
Copy link
Member

untzag commented Feb 3, 2023

I'm not quite sure why you would want to do that @usui-bluec, but I'm willing to listen if it seems to be improving things for you.

We already call _reset_position at the end of home

I've never used run_until_complete, but it seems like it does the same thing it just waits for the coroutine is finished. Just the same as if you put an await in front of it?

I feel like I have a concrete, ugly solution to this problem. I'm going to make a PR.

@untzag untzag linked a pull request Feb 3, 2023 that will close this issue
@untzag
Copy link
Member

untzag commented Feb 3, 2023

@ksunden @kameyer226 @usui-bluec please checkout #19 and see what you think

@ksunden
Copy link
Member

ksunden commented Feb 3, 2023

The difference between run until complete and await is that run until complete is called from a synchronous method (and spins up an event loop of one doesn't exist) await cannot be used directly in init

We use the alternative of create task (because we know that an event loop exists)

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

Successfully merging a pull request may close this issue.

4 participants