Replies: 2 comments
-
I answer some of your questions below (and pose my own), but I want to start by suggesting we reconsider using the 372's built-in PID functionality, rather than doing the PID loop in software within the agent. satp3 is doing that (albeit with an entirely separate 372.) That comes with the advantage that you don't lose lock if the agent goes down for some reason.
The 372's max sample rate is 10 Hz. We used to limit the message rate in the drivers, but removed that a couple years ago now. If I recall correctly we then saw query rates as high as ~40 Hz (which over sampled the sensor), at which point we put the pacemaker in place to keep a 10 Hz max rate. This is also what #687 is doing for the custom PID loop, but it sounds like you're seeing a rate slower than 10 Hz, is that right?
My advice here is to send the fewest commands possible. If my ~40 Hz number above is correct then this should be possible in less than 0.1 s if it's less than four commands.
What's a typical value for |
Beta Was this translation helpful? Give feedback.
-
Next round of testing PIDs we plan to test the 372 settings to see if those work as well as better than the custom. |
Beta Was this translation helpful? Give feedback.
-
The custom pid function here: https://github.com/simonsobs/socs/blob/main/socs/agents/lakeshore372/agent.py
Had its origins in lab testing and was ported over as we have used the loop for some time with SAT_MF1 in the lab. However, it has several short comings that should be addressed.
Part of moving the PID loop off of the 372 was to separate the functionality but as written this doesn't seem to be occurring as intended. I would expect the 372 can sample resistance and temperature at 10Hz without involving the PID loop. The PID would then need to get the temperature information to calculate the correct heater value to apply.
What is the fastest way to get temperature values for the period update_time? This may end up limiting how fast the loop can run, it needs to grab temperature from somewhere and then command a heater value from the 372, can that be done in less than 0.1 s?
It also seems update_time should be restricted to something divisible by 10 Hz otherwise it won't actually be performing as expected. To that end the two values I was attempting to test were 1 s and 0.1 s which are the two I would like to demonstrate work.
I expect the structure would set data acq to sample on the PID thermometer channel at 10 Hz then the PID loop would run on the update_time and grab a number of temperature samples based on the update_time to calculate the heater parameter.
It would be nice to test this on a lab setup before implementing it on SATP1.
Beta Was this translation helpful? Give feedback.
All reactions