Quote:
Originally Posted by MPaulHolmes
So, the controller is controlling torque, and not RPM. So even though it seemed like something was going wrong, it was actually doing what it was supposed to do. A DC motor behaves exactly this way when you control torque rather than rpm. IF you held the motor post so it couldn't spin, Each time you would hit 1, it would put just a tiny bit more torque (and flux) through the motor.
|
OK - so I should hit 2, then pause to see the reaction, then 2 again ... so that it does not speed up and sound like a run-away.
Same deal with the series of 1s.
Decrementing the Id and Iq should have put it into regen and stopped it .. right? That's not what I saw.
Quote:
|
It's interesting that the hardware overcurrent is tripping. My guess is that at high speed, when the rotor flux angle gets out of sync, it viciously commands current in the wrong orientation and there's a current spike that trips the hardware.
|
Hmm. foc test 10 stopped normally - no encoder input
foc test 11 the run-rotor-test shut down on overspeed.
foc test 12 ran to completion and I used 1 and 2 (apparently too fast) to control speed. Then the controller wake-up message came on - no fault there but maybe there should have been?
Hardware overcurrent?
Do you mean when the controller is turned off? I thought that was a signal that needed to be ignored when you saw the 24V input voltage drop below minimum, or maybe the 5V regulator voltage. Not sure if I'm off base here?
Every time I turn off the 12V battery, I get part of the fault as the last thing that happens before the controller shuts down. You don't even get ALL of the message - the controller doesn't have enough power left to finish logging the message ...
Quote:
|
I think we need to get some data of Id and Iq and Vd and Vq and a bunch of other stuff at high rpm. The rotor flux angle may get out of sync because the rotor time constant changes as a function of RPM. I just learned today that as frequency goes up, the rotor inductance and stator inductance go down. I think we should get a set of data points for the phase current and phase voltage, and then plug the stuff into a formula and get the stator inductance at several rpms. The rotor inductance has the same percent of variation as the stator inductance. Then we can update the inductance for the rotor (and the rotor time constant) in real time, based on RPM. I think we also might need to one of those run pi tests for Id. I just assumed that the response for iq was the same as for Id, just because it was for my motor.
|
I think that the motor is more controllable when it is cool. All of the test sessions I have seen where the motor hunts are at the end of maybe 30 minutes or an hour of on-and-off testing. I can't locate my infra-red gun to see the motor temperature. Perhaps I should hook the motor up to a garden hose and just run water through it to keep the temperature relatively consistent?
It would also be great to locate my hand-held tachometer. A confirmation of the motor rpm would let me know if the encoder is operating as it should.
When you talk about capturing phase current and phase voltage - is that a stream of data from the controller?
I have no way of taking dynamic readings of 3 phase voltage and 3 phase current - but I could command a torque, measure one phase voltage and current as the motor accelerates, then check voltage and current on each phase in a semi-static condition. The torque command could then be changed and the readings taken again ... slow and painful but it should work.