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

Dump configs on IV #705

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Dump configs on IV #705

wants to merge 1 commit into from

Conversation

jlashner
Copy link
Collaborator

Dumps smurf configs on pysmurf-controller take_iv.

Description

Dumps smurf configs on pysmurf-controller take_iv.

Motivation and Context

During the smurf software town hall meeting I mistakenly claimed that smurf configs were dumped every operation. After checking the data, this turns out not to have been the case, and configs were only dumped each hammer. This changes it so that configs are dumped every IV, which I believe is roughly once a day. I think this is a good middle ground between every operation and every hammer.

How Has This Been Tested?

This has not been tested.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

Copy link
Contributor

@msilvafe msilvafe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should pay attention to how the size of the logs folder grows in time

Copy link
Member

@BrianJKoopman BrianJKoopman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems good to merge, but I was wondering if you planned on testing first.

@jlashner
Copy link
Collaborator Author

jlashner commented Aug 8, 2024

It would be good to test, but may be difficult to get time at site. @dpdutcher or @tristpinsm, is there any chance we can test changes like this in a testbed at princeton or SLAC?

@dpdutcher
Copy link

In theory yes, though right now isn't the best as we're about to have a 2-week DR shutdown due to building maintenance.
My software is also out-of-date, I may update it while the DRs are down.

@tristpinsm
Copy link

We currently have a UFM in the DR at SLAC, and before heading down to Chile, I think @tpsatt had set up a smurf server with the SO software. It might be a bit of work to get a test setup running as we haven't been using OCS before (AFAIK), but I don't see why we couldn't do it there. Right now Toby and I are busy at site.

@msilvafe
Copy link
Contributor

msilvafe commented Aug 9, 2024

We currently have a UFM in the DR at SLAC, and before heading down to Chile, I think @tpsatt had set up a smurf server with the SO software. It might be a bit of work to get a test setup running as we haven't been using OCS before (AFAIK), but I don't see why we couldn't do it there. Right now Toby and I are busy at site.

FYI, I used OCS for testing at SLAC in the past, so hopefully not too much work to revive

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 this pull request may close these issues.

5 participants