This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
A key need for my application is to be able to stall the motor, holding accurate position (with force). To this end, we have implemented a Hall sensor override for low-RPM conditions. This is all tested and working, interpolating the vector angle from hall sensor inputs, then injecting into FOC using EST_setAngle_pu(…)
In total, we have both FOC and SpinTAC Velocity engaged during this process, with a SpeedRef_krpm set to 0. 10kHz update rate with 20kHz PWM.
During testing, I've noticed something very odd...
When the motor is stalled, we are seeing a disturbance / jitter occurring at ~1sec intervals. This jumps 1-2 Hall sensor positions (8polepair motor = 7deg per jump). The jitter is recovered quickly via the halls, but I can see from debug that the hall sensors are following this jump: not injecting it to begin with. The more current ceiling used, the bigger the jump (set by gMotorVars.SpinTAC.VelCtlOutputMax_A)
This means somewhere in the FOC/SpinTAC system we have a disturbance being generated almost every second. (Caveat: I need to accurately time this: so assume around 1sec).
I've timed our codebase and can confirm we've nothing overrunning the 100uS update or interrupt which could cause this. I've also run this on multiple, different, motors and it happens on them all.
Is there anything in FOC/SpinTAC velocity which is kicking-off at around ~1sec intervals which could cause this disturbance?
Mat
The resolution of the feedback speed is not enough by using hall sensors, you should tune the speed controller or disable the velocity loop during the stall.
Can you elaborate on this issue?
To overcome the resolution problem I'm already interpolating between halls quadrants, which means I'm calling EST_setAngle_pu(…) at 10kHz. Obviously under stall conditions this is being set to the same value every time.
Assuming I continue to have the FOC + SpinTAC Velocity setup active in my system, what else would I need to override to stabilise the system during a stall?
I need to find a solution which doesn't need a massive reconfiguration of the system: its a live application which needs to transition between velocity control and stall conditions.
thanks
Mat
We don't have any reference InstaSPIN-FOC and SpinTAC using a hall position sensor. I don't know how do you calculate the feedback speed using the hall sensor, but its resolution is not enough for SpinTAC at zero speed or very low speed if there are only 6 pulses ever electrical period from the hall sensors as I know.
You might monitor the angle and speed during the stall and low speed, to see if the angle and speed are correct as your expectation.
I have monitored the angle that we're generating from the Halls. Although there are only 6 quadrants, we are interpolating at 10kHz between these. Apart from having monitored this signal (and it looks ok), at zero RPM the interpolation is very easy :).
What I'm saying is that the angle feedback via halls IS stable, but something else within the system is causing the disturbance: which isn't related to the angle feedback we're providing
The interpolating method is good for running the motor with a higher speed if the feedback speed is not changed very fast, but it's not enough for zero speed and very low speed if the feedback speed is not correct.
The correct rotor position and feedback speed are key factors for InstaSPIN, especially InstaSPIN-Motion using SpinTAC. You might try to implement a braking way to stall the motor.
You might post some current waveforms captured by the scope and the related code to show how do you stall the motor if you still have an issue with this. Thanks!