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

Smarter dealing with errors, so not every error causes a stop. #32

Open
philipstarkey opened this issue Apr 21, 2017 · 3 comments
Open
Labels
bug Something isn't working minor

Comments

@philipstarkey
Copy link
Member

Original report (archived issue) by Ian B. Spielman (Bitbucket: Ian Spielman, GitHub: ispielma).


Currently blacs stops on all error conditions. This is bad behavior. Our system requires that it be running constantly to stay in a stable "warm" configuration. So blacs should not stop submitting shots unless and "end of the world" bad event has occurred.

There are different degrees of badness. For example, in some cases a camera will miss an image for some reason. This type of error should just request blacs to ignore the error (or perhaps re-try the shot).

Blacs should switch to a "safe" script of too many errors accumulate.

@philipstarkey
Copy link
Member Author

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).


Although it's very hard to tell the difference between a very bad error and a not so bad error without the programmer anticipating each one and flagging it as such, we could make an option like "if encountering an error, restart the tab in question and retry the shot", and then something like "if there are still errors, go into repeat mode with a default shot" (the default shot likely obtained by a request to runmanager to please submit a shot with all the default values, once the "default values" feature is implemented there).

There could be increasingly aggressive recovery attempts each time one fails - first restart the offending tab. Then restart all tabs. Then do the "reset of hardware" functionality you mentioned in another feature request. Then even if there are errors during transition_to_static, keep running anyway to keep the experiment cycling. If there are persistent errors during transition_to_buffered, and restarting all tabs and doing hardware resets doesn't fix it, then there is no recourse left and BLACS will have to stop.

All the errors would have to be logged and the GUI prominently display that something went wrong earlier even if recovery was possible.

@philipstarkey
Copy link
Member Author

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).


Just want to flag a couple of things:

1 similar comment
@philipstarkey
Copy link
Member Author

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).


Just want to flag a couple of things:

@philipstarkey philipstarkey added minor bug Something isn't working labels Apr 5, 2020
Loki27182 pushed a commit to Loki27182/labscript that referenced this issue Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working minor
Projects
None yet
Development

No branches or pull requests

1 participant