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

GEM oscillating radial collimator not responding #3167

Closed
4 tasks done
AdrianPotter opened this issue May 8, 2018 · 4 comments
Closed
4 tasks done

GEM oscillating radial collimator not responding #3167

AdrianPotter opened this issue May 8, 2018 · 4 comments
Assignees

Comments

@AdrianPotter
Copy link

AdrianPotter commented May 8, 2018

We received a support call from Ivan on GEM. The oscillating radial collimator had stopped responding. On investigation, the VI and OPI responded equally so a hardware fault was suspected.

On visiting the instrument, with help from Graham Burgess, we power cycled the hardware. This requires physically unplugging the power cable at the back of the controller as the power switch doesn't completely turn it off. This fully reset the hardware and normal operation resumed. We also added a block for the number of cycles to make it easier to see when the hardware stops responding in the future.

Also while we were there, they started their Mercury cryostat. The data from the device didn't appear on the OPI and required manually starting the VI. From the st*.cmd files, it appears the appropriate option flags aren't sent to start the necessary VIs.

For this ticket:

  • Record the information above on the instrument's wiki page
  • Fix the Mercury startup files
  • Hotfix to GEM
  • Add shutdown task to update GEM
  • Make sure the hotfix is recorded in the wiki
@kjwoodsISIS
Copy link
Contributor

You say "From the st*.cmd files, it appears the appropriate option flags aren't sent to start the necessary VIs.". Does this imply that there ought to have been a check that the correct option flags are set? Should we update the relevant documentation to make sure that such a check is explicitly performed?

@AdrianPotter
Copy link
Author

Yes, it's interesting that wasn't caught in testing. I'll try and determine the root cause and update the documentation for LvDCOM IOCs if necessary.

@FreddieAkeroyd
Copy link
Member

Maybe it was tested without the hardware being present, which is why autostart got missed?

@AdrianPotter
Copy link
Author

AdrianPotter commented May 9, 2018

I will add the hotfix to the shutdown tasks. Ivan said they're unlikely to stop the ibex server in the mean time so the problem with the Mercury's shouldn't reoccur before then

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

No branches or pull requests

4 participants