stancecoke said:
OK. In the torque-simulation fork, the (perhaps useful) redundant control of the duty cycle in the fast loop is disabled. All tuning of the duty cycle value happens in the update_setpoint.c, following the motto "keep it simple"
I really don't like that idea because:
- reading and controlling max motor current is needed to protect the motor controller/mosfets from burning
- reading and controlling max regen current is needed to protect the battery cells from overcharge and the controller/mosfets from burning
- ramp up/down of duty_cycle at fixed frequency is important to guarantee the motor will not accelerate to much fast and avoid FOC fail
On slow loop, we will be developing/adding features that are yet to be implemented and need heavy code with floats operations, that will slow more and more that very important motor control tasks. Also, it is easy to have a bug on the new features on the slow loop code and that will impede to run that motor tasks.
On the fast loop, we have guarantee that code will run every time at fixed frequency, fast. I added the protection of watch dog timer to that code, the system will reset if for some reason PWM cycle code don't run -- on the slow loop, I think will be to much difficult as the time will be varying as we will adding/changing new features.
And I think the motor control tasks should be near to be finished. We just need to have a robust FOC, motor max current controller, motor regen current controller and the duty_cyle ramp up/down. I think that only FOC may no be so robust and need rework for fine adjustment in angle values for each motor so we can get the best efficiency possible for each motor.
For my new Q11 direct drive motor, I need to see if FOC is work well - for what I could understand, what fails sometimes is the transition from no interpolation to interpolation. I wish there was a way to detect that fail and stop the motor...