I have recently been thinking my own impatience and negativity in internet discussions is sometimes due to my inability to help and resulting frustration… but I do think that the approach of sharing symptoms and asking for ideas does not work well in this particular domain. The system is too unconstrained, with all the different things that can be borked, a different approach is imo advisable and I hesitate to say it once again because I don’t want to just be a pain, but honestly if you try to poke in there and just see what’s going on with an oscilloscope, printing variables (or ideally a debugger of some kind), that sounds like more work but it’s actually pretty fast a lot of the time, and you are much less likely to spend a long time without result.
Just shed light by whatever means you can on each stage of the system, follow the operation of the system and the flow of information and soon enough you will see what’s not doing what you expect, and then you can have a true solution that addresses the problem at it’s root, is solid and lasts.
It’s the MKS dual FOC plus, which should be able to handle much more current.
I’ve limitted the current to 0.5A for a 20Ohm gimbal motor.
@Anthony_Douglas I agree with you, it’s often much better to find the cause of a problem yourself.
But I wouldn’t know where to start?
@Candas1 I reversed the sensor direction and the motor locks up. Put it back as it was and it spins as expected.
Although I’m familiar with this “running full speed in the wrong direction” phenomen.
I had seen it before when I told a motor to stop, but it overshoots so hard, that it spins backwards.
OK, I only saw a different behaviour when I changed the LPF-setting.
Which only leaves motor and sensor.
I will play with phase_resistance and kV values and maybe increase the bitcount of the sensor readout form 10 to 12. A bit of sensor noise might trigger something…
It’s still shooting in the dark:
Why does it start to spin from standstill, but not after a stall?
I didn’t limit the motor voltage to 50% of driver.voltage_limit
I thought, if I only set the target voltage it would be the same…
After I added the motor.voltage_limit, the motor now spins up after a stall
Playing with the kV value in the motor constructor showed some nice effect. When I reduced the value by factor 1.4, I could spin the motor by hand, like there was no cogging or stiction.
Someone here mentioned, the kV value was internally multiplied by sqrt(2), but IMHO that has a negative effect.
Still there is a question:
I tried to set the I2C constructor like that and wanted to play with the bitcount to introduce some sensor noise, but the motor completly blocked…
Why that? I’m using the dev-branch, FWIW.
// MagneticSensorI2C sensor = MagneticSensorI2C(AS5600_I2C);
MagneticSensorI2C sensor = MagneticSensorI2C(0x36, 12, 0x0C, 8);
// 0x0C = high byte of raw_angle register
// also tried 0x0E = high byte of the angle register
// also tried 9-11 bits
That’s a vary interesting observation, you’re saying with overmodulation eg motor limit equal to driver limit the problem occurs, and without it doesn’t.
That’s not the actual solution, but perhaps gives some sense of where to look.
You think it’s a software bug, or could the higher limit be leading to follow-on problems like tripping overcurrent protection or something along those lines?
Is there a overcurrent protection in voltage controlled torque mode? ( phase-resistance and kV provided)
I don’t have current_sensing enabled.
I’ve set the motor.current_limit to 0.5.
When i stall the motor, what does this limit trigger? Can I read out any error flags or do I have to reset them?