Dump configs on IV

[jlashner]

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.

[msilvafe]

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

[BrianJKoopman]

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

[jlashner]

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]

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]

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]

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

[BrianJKoopman]

@tristpinsm / @dpdutcher / @msilvafe is there still interest in this?

[dpdutcher]

Meh? It wouldn't hurt.
My preferred solution would be to have sodetlib.util.get_metadata do a version of this instead, so all config info is present in the sodetlib data files to which they pertain. But merging this is easier.

[msilvafe]

Meh? It wouldn't hurt. My preferred solution would be to have sodetlib.util.get_metadata do a version of this instead, so all config info is present in the sodetlib data files to which they pertain. But merging this is easier.

Ya happy to defer to @dpdutcher on this one.

[BrianJKoopman]

Meh? It wouldn't hurt. My preferred solution would be to have sodetlib.util.get_metadata do a version of this instead, so all config info is present in the sodetlib data files to which they pertain. But merging this is easier.

Hmm, alright, I suspect it might be easier to test a modification to sodetlib.util.get_metadata though. Is someone able to test this change (either as is here, or in sodetlib) on a lab system?

[tristpinsm]

I should be able to test this change or one to sodetlib on the SLAC system.

[BrianJKoopman]

I should be able to test this change or one to sodetlib on the SLAC system.

Great, thanks! Let me know how it goes and we can either merge this or close it and update sodetlib instead.

[tristpinsm]

I don't really know what this is about though, so I will need to read through and get up to speed.