I’m having some trouble setting up the simpleFOC library to get torque (current) control of a Maxon EC-max 272768 through a simpleFOCShield V2.0.3 and a STM32F446RE MCU.
The datasheet for that motor says that it has one pole pair, but when I initialize it with
BLDCMotor motor = BLDCMotor(1);
under a constant torque command, I feel two strong “detents” 180 out of phase through the rotation of the shaft. With
BLDCMotor motor = BLDCMotor(0);
I get one strong detent, and with
BLDCMotor motor = BLDCMotor(-1);
I get smooth rotation with constant torque. To me, this suggests that something is wrong (clearly, the motor can’t have a negative number of pole pairs) but I do get roughly the desired behavior. It occurred to me that I might have the phases of the motor wired wrong, but I tried every permutation of connecting the three terminals to the TB_M1 port and got the same behavior. Does anyone have any idea what is going on?
A few comments while I think about what might be going on and look at the code…
the motor is expected to get a little warm, it depends how quickly
if you keep the voltage_limit low, then you should be safe. Even better, set the power supply to 5 or 6V
switching the motor’s terminals will only change its direction. Any motor phase can be connected to any driver output, it does not matter.
I would expect “detents” at low velocity - after all, the motor only has 1PP - so you would expect significant cogging
Let me look at the code and see what -1 is doing when you pass it as the number of PP. May I ask in the meantime, are you using the motor’s hall sensors, or running in open loop mode?
[edit[
In terms of open-loop mode in sine modulation, it seems choosing a negative pole-count would simply change the electrical angle which the open loop is setting - X rad would become 2π-X rad
In terms of closed loop mode, it looks like it would reverse the direction of rotation…
Weird that it doesn’t make things blow up completely, I don’t think negative pole counts were ever intended to be used.
As for why it would run more smoothly, I can’t really see any reason for that from my brief look into the code around this. Are you sure you weren’t just running it more quickly?
I have it in closed-loop mode, with an AS5048 magnetic encoder. This motor is being specced for an application to a haptic device with essentially direct drive, so it is running very slowly. However, the motor was also chosen specifically for low cogging characteristics. If the motor isn’t hooked up to anything (or the board is turned off), the shaft turns extremely smoothly.
Also, the detents I’m describing only occur if I have commanded a torque. That is, if I command a motor current of 1A, I feel the detents, at no amps, I don’t.
I also didn’t mention this in my post, but I also tried setting the pole pair numbers to higher values, and found that this increased the number of detents. That is, at pp=2, I could feel three distinct detents separated by 120 degrees, at pp=3 I could feel four distinct detents separated by 90 degrees. So I’m pretty sure this is a behavior do to something happening in code, and not due to intrinsic properties of the motor.
You know, maxxon motors are great. So I definately believe you.
For us in the forum it is a more unusual motor, most users aren’t using this kind of motor due to the price.
This is all very interesting to me. If you try any of this with a say 7-PP motor you get terrible results. But I think because the motor is exactly 1-PP, any number is a multiple of 1 and you get motion in all kinds of situation that other users would see only noise and vibration.
This is perfect. While it might not be 100% physically accurate it is an upper bound and ensures the safety of your motor.
Since you have >3Ω winding resistance it isn’t such a big problem as with motors that have <1Ω winding resistance, where the currents can get pretty high pretty fast. But you still don’t want your motor getting hot slowly either, so setting this kind of limit is just the right thing to do IMHO.
About the detents I have to think some more on this. If I come up with something I’ll certainly post it, but maybe in the meantime one of our more knowledgable members has some ideas.
I may have figured it out! When I was running motor.initFOC();, the motor was consistently detecting a sensor direction of CW. By enforcing a sensor direction of CCW, the problem goes away. I think this makes sense, given the behavior I was seeing.
However, I am having trouble tuning my PI controllers for the current control, so maybe something is still wrong. If I use any non-negligible Ki, the plant becomes unstable. From what I understand, one PI controller should be driving the quadrature component of the current to the current command setpoint, while the other PI controller should be driving the direct component of the current to zero. I’m not seeing that behavior; instead with any non-negligble Ki, the magnitude of both i_q and i_d until their respective voltages saturate. Does this suggest that something in my setup is still wrong?
This is so fascinating. Clearly I have to bite the bullet and order one of these expensive things.
This kind of makes sense to me. I think you are crossing the sensor zero during the direction check, because with 1PP an electrical rotation == a full rotation. Probably our code doesn’t quite correctly account for this.
Regarding your questions on the current control, I will have to leave those to someone more knowledgable on this topic.
