Current SimonK build here - Afro NFET binary: afro_nfet_reschedule.hex also source for the Afro NFET, (note why I included the afro_nfet.inc file - watch out for board .incs clobbering settings, as afro_nfet.inc would do to MOTOR_ADVANCE!)
This is by no means a SimonK tuning workflow, or anything. Just the directions my experimentation took:
- MOTOR_ADVANCE = 13
Previous to the last post about it, I had nailed down static phase advance (MOTOR_ADVANCE) at 13 degrees. One click higher or lower gave more rotor position losses at the transition to run mode, and the powerskipping to recover from those would result in less consistent spinups.
Next were startup mode parameters. Some N.b.'s about SimonK startup mode: Not only does that change the input filtering, but it forces maximum phase advance. This is, as far as I can tell, unavoidable, because BEMF zero-cross detection with only phase voltage feedback can only tell us which segment of the 6-step modulation diagram we ought to be in. We don't know where we are within that (60 degree) segment. So, applying an angular phase advance requires also knowing the speed of the rotor and that requires knowing the last few timings. If the speed is zero or unknown, it's undefined and all we can safely do is immediately slam the correct space vector at the motor. Now, something about these particular motors and highly advanced timing at low speed - that is very nonideal (I found out by setting MOTOR_ADVANCE to 30 in order to observe it in run mode) and makes VERY little torque. It follows; of course shifting things way too heavily toward the direct-axis current component at low speed. Thus, what matters to us is to enable timing control and set phase advance to something sane that (1) Is reasonably MTPA-ish (because, you know, we're trying to accelerate here) and (2) Ensures reliable sync holding, as soon as possible by quickly getting the hell out of startup mode:
- ENOUGH_GOODIES = 6
What the fridge are "goodies" you ask? That's some dense SimonK jargon. Good zero-cross detections, good commutations, that's all. Stock setting is 12. This cuts the current-inefficient, sluggish startup mode window in half. Seems to have no negative impact, 6 commutations must be enough goodies for these motors to have stabilized a timing measurement for run mode. Also, how long we keep startup mode on appears to have no impact on run-mode reliability and current control considerations - it doesn't sound like these motors are managing to accelerate much in startup mode to speak of anyway.
With the change, acceleration is definitely more prompt. Stock SimonK can "sit there whining at 8 kHz" (it IS turning, just not making much torque and not increasing in speed very fast) for a brief but tangible moment before it really gets rolling. You probably know what I mean. That moment is startup mode staying on until there are enough goodies.
Also messed with:
- START_DELAY_US = 0 (stock)
That adds blanking time before looking for zero-crosses during startup mode (there is also an algorithm that adds steps of delay on every failed start, which would auto-unbreak certain mistuned setups if you just keep trying to start the motor) - anyway; leave the above alone. You can try messing with it, but on my motors and boards, startup mode itself seems to perform well already and cranking this parameter worsened glitchy starts.
So that leads me to working with run mode, which turned out to be a source of some of the glitches.
The key thing here is current control. The back-EMF that is being measured for rotor angle detection is very low at low speed. Slamming too much phase current at the motor can cause too much noise to reliably follow. Sure, it MAY produce harder accelerations to crank the shit out of all the duty schedule parameters, but a harder acceleration that might follow a aync loss and powerskip and thus become a delayed harder acceleration (taking more time overall) 3% of the time, is flatly useless if we are trying to make a blaster more responsive. At the same time, there is saturation in the stator, so past a certain point it won't help as much as you think. And also at the same time, the current control in SimonK is not current control, it is a frequency-based duty (voltage command) schedule, so actual currents scale with bus voltage, and thus with my motor and 4S, it is already considerably more aggro with stock SimonK than, for example, a FDL drive on 3S.
Detour to overview of late SimonK duty scheduling:
* PWR_MIN_START (stock: POWER_RANGE/6) and PWR_MAX_START (stock: /4) set the endpoints of a "ramp" used in startup mode. Normally, PWR_MIN_START is all that matters unless you fail a startup (which like the start delay deal above, modulates more power within this "ramp" on every occurrence, which can help to auto-unbreak problem cases and get motors to at least run).
* PWR_COOL_START is used if a whole shitload of start attempts fail. This is normally set to /24, it is for locked-rotor protection and shouldn't be changed.
* PWR_MAX_RPM1 (stock: /4) sets the lower run mode duty limit, which is associated with TIMING_RANGE1.
* PWR_MAX_RPM2 is deprecated and isn't used anymore, I don't know why that is still there in the source. That was for the old versions, which shifted duty like an automatic transmission in discrete hard steps. Later versions do a ramp that is more refined.
* TIMING_RANGE1 (stock: 0x4000) sets the speed under which the lower run mode duty limit PWR_MAX_RPM1 applies, in steps of 0.25us per commutation step (stock=4096us). Above this speed, the main run mode ramp applies.
* TIMING_RANGE2 is unused, see above.
* TIMING_RANGE3 (stock: 0x1000) sets the ramp endpoint speed at which the duty limit becomes 100%.
* TIMING_MAX is the governor.
And my settings:
- PWR_MIN_START = POWER_RANGE/6
- PWR_MAX_START = .../6
- PWR_MAX_RPM1 = .../6
- TIMING_RANGE1 = 0x6000
- TIMING_RANGE3 = 0x1000
Non-stock settings bold.
Logic behind these:
* We know we have a startable drive and not some random motor (stock SimonK is set up to reliably make any random PMSM/BLDC type thing that anyone might hook up to the controller start and run). Thus, there is no need for the startup mode ramp. Thus, it is disabled by PWR_MAX_START = PWR_MIN_START.
* PWR_MAX_RPM1 being set at /4 produces too much phase current at low (LOW low, like sub-300rpm low) speed, and causes glitchy sensorless operation, so this is chopped back to /6 resulting in MUCH more stable transitions into run mode and effectively no "unpredictable spinup" incidents. Also, it being /6 mates up smoothly with the PWR_xyz_START and prevents a hard step in duty from happening there (which is also a phase and bus current step and can result in problems with noise).
* TIMING_RANGE1 is moved back from 0x4000 to 0x6000. This just about compensates for the previous by starting the ramp sooner.
The difference between the problem drive with my old Model Pandora era build and the problem drive with the new build is night and day and puts the formerly buggy Serial One setup right back on par with or better than the Model Pandora on its preferred battery.
It also has the side effect of better current-efficiency and less heating during startup. The motors are definitely cooler after a series of 0 rpm starts.
The tune should be generally applicable to any 14-pole flywheel drive situation with maybe only a timing tweak for different motor families, and should have the impact of reducing the sensitivity of the drive to battery, wiring, motor and controller variations.
Don't understand as much of this as I like but definitely appreciate what it's doing for raising the platform to a refined level of reliability beyond what I'd ever have the patience to do.
ReplyDelete