Add fast_brake command for HWP rapid spindown #787
Conversation
for more information, see https://pre-commit.ci
socs/agents/hwp_supervisor/agent.py
Outdated
| elif isinstance(state, ControlState.WaitForFastBrake): | ||
| f0 = query_pid_state()['current_freq'] | ||
| time.sleep(5) | ||
| f1 = query_pid_state()['current_freq'] | ||
| if f0 < 0.2 or (f1 > f0): | ||
| self.log.info("Turning off PMX and putting PCU in stop mode") | ||
| self.run_and_validate(clients.pmx.set_off) | ||
| self.run_and_validate( | ||
| clients.pcu.send_command, | ||
| kwargs={'command': 'stop'}, timeout=None | ||
| ) | ||
| time.sleep(5) | ||
| return |
There was a problem hiding this comment.
This block of code seems largely similar to the block of code handling ControlState.WaitForBrake in lines 1149-1165, with the only difference being that this block doesn't wait for the rotor to completely spin down. It might be simpler to add a boolean attribute to ControlState.WaitForBrake named fast which determines whether or not to run lines 1160-1164.
There was a problem hiding this comment.
Also whenever the ControlState.WaitForFastBrake finishes, it should set the state to ControlState.Done
|
In terms of content this all seems perfectly reasonable to me (although we should definitely test the fast brake process with an actual device before merging). However, structurally it might be best to merge the fast brake control states into the normal brake states, as they seem to share many of the same lines of code. |
| if state.fast: | ||
| time.sleep(5) | ||
| return |
There was a problem hiding this comment.
This is not very safe. We should do WaitForTargetFreq.
But I think the motivation of this PR is to change the rotation direction quickly for special calibration, and you may not want to add WaitForTargetFreq. Therefore, it might be better to have a separate function that will change rotation direction, which will be faster than doing fast brake and spin up.
There was a problem hiding this comment.
Yes I agree. Just wondering what is the behavior if you PID to -2 Hz by changing the PID direction while sitting at 2 Hz? If we can get something like that to work I agree we should make it a specialized operation.
There was a problem hiding this comment.
what is the behavior if you PID to -2 Hz by changing the PID direction while sitting at 2 Hz?
This command will also rapidly change the rotation direction.
Changing PID direction flips the direction of acceleration and the HWP slows down. As the absolute PID frequency stays at 2 Hz, the PMX serves the highest voltage and current to recover 2 Hz, which results in a strong brake. Then the HWP speeds up to opposite direction and reaches -2 Hz.
But the current hwp_supervisor looks it doesn't expect this procedure so this will require some changes anyway.
Which looks better @ykyohei ?
Description
Update
brakecommand ofhwp_supervisor.Motivation and Context
WG team is trying to measure the time constant by changing the hwp frequency rapidly e.g. +2Hz to -2Hz.
Current
brakecommand is designed for gentle spindown and it takes >10 min to start inverse rotation.New option of brake command is expected to take <2 min to spindown.
https://docs.google.com/presentation/d/1-kgAFn2sVR3R_Hp8_HcEYgZ8_SoNihm-UwsMn-Skxto/edit?usp=sharing
How Has This Been Tested?
Not tested yet
Types of changes
Checklist: