Already discussed in this thread: http://vedder.se/forums/viewtopic.php?t=639
Benjamin wrote in that thread that Field Weakenig is on his todo list, but I cant see it on the todo list available here http://vesc-project.com/node/110. Maybe that would be something to add to the list.
As far as I know it seems to be partly implemented, but I don't know how to use it.
Have a Nice Day.
Added to the todo list.
any news on Field Weakening yet ?
I'm also interested in field weakening. I build a dynastarter for a combustion engine.
In my application I need as much torque as possible from stand still (within restricted space available). This is why a higher number of windings is desirable. On the other hand, when the combustion engine is running at high revs the generated voltage can rise up too high, above supply voltage and the battery will be damaged.
I think field weakening could solve this problem. Or I'm wrong?
When the VESC encounters an error, it will stop driving all FETs and hope that this is a safe situation. When braking is required going down a hill, that may not be the best situation for the rider, but the electronics stays safe.
This suddenly doesn't work when the motor can be driven at much higher speed than what the battery allows. The VESC uses 1.2 mOhm mosfets. At 50A the voltage drop will be about 60mV, so at 50A there will be about 3W of power dissipated. When the motor turns faster than the battery allows, the six mosfets will coincide with six diodes in a three fase bridge rectifier and start charging the battery. But now with a voltage drop of 0.6V, at 5A average you'll already hit the 3W power dissipation that the fets can handle without overheating.....
When things go wrong, (you hit the reset on the CPU, hit reboot in the gui, a fault triggers anything) you blow up hardware.....
field weakening is interesting when you have a low-inertia rotor that needs to go faster than the supply allows.
But why are a lot of ebike ESCs then use field weakening without blowing up? Just lucky that no faults happened in the period they are using a faster erpm then the normal battery max erpm or do they use special hardware preventing a blow up and dissipate the power in an other way?
The are at least 3 ways for fault handling during high speed field weakening
If a fault occurs at high speed, and the fault action is to output null vectors (all 3 phases to + or to Gnd), then the motor will do automatic field weakening. High currents will occur when doing this, but it will not exceed Ichar=Lamda/Ld. VESC firmware could easily calculate Ichar as a parameter during motor configuration, If Ichar is within safe range, then it could allow both high speed field weakening and null vectors as the default fault action.
You can feel a high braking torque if you try to rotate by hand a motor after connecting/shorting the 3 terminals. It may feel like the braking torque will increase forever while trying to rotate it a higher speed, but it will not -- the torque will reach a peak, and the braking power (torque*rpm) will approach a constant value (P=R*Ichar^2) over a wide speed range -- constant power means that torque decreases as rpm increases.
I recently added a few lines of code to mcpwm_foc to implement field weakening.
I set id_set_tmp based on the difference between iq_target and iq actual.
I also tried the lookup table method and manually recorded some data points of erpm and negative d axis current. I don't know much about programming so I just hard coded this table into mcpwm_foc and it also seems to work well enough. Some parts of the field weakening rpm curve are quite non linear, and I found it helpful to have a decent number of points defining the curve.
Many ebike controllers have field weakening but I don't believe any of them use any proper method of fault handling. The manufacturers of most of these controllers simply recommend against running very high fw currents and speeds. Most users are on 20s or below, so there is a little headroom with 100v components. Also most of SPM motors don't field weaken that well anyway. The fw current needed to push way above the voltage limit probably prevents most users from killings things.
Are there any plans to implement this feature? Do you need help with testing or could i do something else to speed up the process?
could you describe more in detail what you did or could you even share code for testing?
I do have experience with STM32 software development but no idea of electronic engine control.
lux, please take a look at this:
Field Weakening support is getting closer!
I like the plain notes on using field weakening.
I think a beefy diode paralell to the battery fuse is a must have to clamp the voltage in fault scenario.
I think another option would be to be able to set a Max RPM/ERPM specific to field weakening, so that you can run your motor over speed, but not beyond the rating of the components used in the controller, eg, if you build a controller with 200v rated devices, but only run to a max pack voltage of 151.5v your field weakening would only let you get to an RPM that would result in your open circuit motor voltage being 199.9v (or less if you want). It should be reasonably safe provided you use avalanche rated switching devices, because your MOSFETs will only need to dissipate the 1/2 L I ^ 2 energy of the parasitic inductances, not the kinetic energy.
Yes, currently during FW we limit rpm to ( flux_linkage / Vinmax ).
thank all for they're work on this amazing project.
As I see it, the pull request hasn't been merged yet, right?
Could i do something to help? Maybe testing beta versions?
Field Weakening blew the MOSFET on deceleration.
This is not a rant rather a way of sharing experience with FW/MPTA
> Following the discussion thread here https://github.com/vedderb/bldc/pull/91
I tried to implement the Field Weakening on my 6kw PMSM In runner on no load to achieve higher speeds.
The motor specs is as follows.
Poles : 8pole
Design Voltage : 60v
Operating Voltage : 48v
Design Current : 130Amps RMS
Operating Current : 100 Amps RMS
Nominal Speed : ~2300RPM @ 60v, ~1800kRPM @48v [Mechanical]
Nominal Speed : ~9kRPM @ 60v, ~7.0kRPM @48v [ERPM = Mechanical * Polepairs]
I was able to run the motor even upto 200Amps max current using the VESC75/300 board from TRAMPAhttp://www.trampaboards.com/vesc--c-1434.html
After all the trials I decided to try the MTPA / Field Weakening to exploit the full motor power., with the known hazards and dangers of the Field Weakening I removed the load and kept the motor on noload condition to initially check the higher RPM and then put load as the suddent collapse of ID can fuel explosive energy of the MOSFETs.
I cloned the reposhttps://github.com/powerdesigns/bldc/tree/FluxWeakening-MTPA-supporthttps://github.com/powerdesigns/vesc_tool/tree/FW_MTPA_support
modified the configuration and built the binaries to fit the board which in my case is
//#define HW_SOURCE "hw_75_300.c"
//#define HW_HEADER "hw_75_300.h"
I got the proper parameters for the motor as shown below...although I am a bit skeptical why the Ld and Lq are 20 ...!
I have used sensored FOC till 4000 ERPM to have good starting torque
MTPA / FW was enabled with default parameters
Current was limited to 90Amps as that would be sufficent for field weakening with -10amps for regenerative breaking
Both forward and reverse ERPM was limited to 10k
Once I ran the motor this was the response
... I started at 5000 RPM and then used the VESC tool to increase the RPM to 7000 and then to 10000.,
as can be seen in the picture below the ID didn't actually deviate significantly but rather stayed with an average 0 Amps.
but the sound of the motor became sharper and sharper showing the speed increase with 95% duty cycle remaining constant on speed change.
after a minute of this I clicked on STOP to bring the motor to a halt., which on the click fried the MOSFET s
the driver, controller and the rest of MOSFETs seems to be okay on the glance but needs careful testing
The controller UART link with the VESC tools got disconnected when the MOSFET failed.,
So here is the dilemma since the 10000 ERPM brings the regenerated voltage to < 70v which is within the boards [MOSFET] safety limits., why did the MOSFET burn on stopping the motor.
can i replace all the MOSFETs on the board with IRF7769L1TRPbF which can withstand voltage fluctuations till 100v .https://www.infineon.com/dgdl/Infineon-IRF7769L1-DS-v02_00-EN.pdf?fileId...
although package current is limited to 124Amps ., having 3 in parallel should be more than sufficient to achieve peak current of 200amps.
here is the RPM graph which also failed to show the higher RPM for some reason and shows the sharp declination of motor speed on stopping it .., before disconnecting completely
and the MOSFETs temperature...at this point it was hardly drawing any current from the battery... the Motor doesn't have any temp sensor so the plot can be ignored.
What should I do now to ensure safer ways to test and implement field weakening.??
I want to try the Field weakeing with VESC6plus until I could source and replace MOSFETs on the 300amps board., suggestions would be really helpful...
Would the virtual motor be of any importance in this test ?
The variation of duty cycle can be seen below.
Thanks for sharing your experience. I don't know if it's just me, but I can't see any of the pictures you've posted. Can you check your sharing settings to make sure everyone can see the pictures?
I can't see the images either...
Team thanks for the quick response and pointing out the issue with the pics...
I have updated the post ... hope its visible now...https://vesc-project.com/comment/3801#comment-3801
Now its updated > https://vesc-project.com/comment/3802#comment-3802
Thanks for reporting your experience . Its very helpful you have saved all those pictures, as I can try to replicate that configuration in virtual motor mode, and see what might happen and how to deal with that.
First of all, I did not try to add the motor configuration with the Wizard (as I think you did). I always load the configuration manually using the buttons available in the FOC window. So I programmed vesc-tool to make inductances Ld and Lq to match the L inductance (in a PMSM they are the same) when I pressed the "Apply" button. I did not realized that there was other place (using the Wizard config) where the L inductance was calculated, so that was why you saw that they were different.
I don't think that can make a big issue, because that only makes the current regulator to try to act in advance (axis decoupling), but it is a detail to modify.
Besides, you say that you heard the motor spinning faster when duty was at 95%, but in the graph of RPM it did not show it was increasing. Are you sure it was actually spinning faster?
can you help me and compile this vesc tool to work on mac?
i want to test Field Weakening and i will write my results
Thanks for the followup,
Your assumption and comment on the Inductance is valid, I needed the confirmation on the same.
The Inductance values from our simulation is supposed to be around 135uH..
This used to be properly identified by TI Instaspin using Wizard mode. [Identified Motor Parameters are in the green box]
Since the VESC Tool identifies the Inductance as 70uH is there a calculation that I am missing here or should I manually set this to the design values ?
I too decided to try with virtual motor but the ERPM mismatch compared to the real thing has stalled me there...https://github.com/vedderb/bldc/pull/82#issuecomment-515680414
I am very confident about the higher speeds as the pitch of the motor hum while spinning kept on increasing with newly set ERPM steps.., I am yet to receive new set of components for replacement however I can try the same with the VESC6+ within a reasonable ERPM change and measure the same using a handheld tachometer.
I believe a manually controlled ramp down will do the job for now..
As of today there is an official build for MACOS from Vedderhttps://github.com/vedderb/vesc_tool/blob/master/build_macos
you should be able to use the same Makefile to build it against the Field Weakening versionhttps://github.com/powerdesigns/vesc_tool/tree/FW_MTPA_support
just ensure you have the right branch [FW_MTPA_support] and not the MASTER checked out from the repo.
Field Weakening is a feature I plan to use heavily. My use case is described here. The short version is overspeeding e-bike wheels to 90mph, abuse plain and simple. I doubt Field Weakening will be enough to protect my batteries, so I also want Dynamic Resistor Braking. I cannot think of any use case for dynamic braking that would not also benefit from field weakening so I propose it here as a potential TODO.
I am brand new here so there are many things I am not up to speed on. My naive vision for dynamic braking seems like it could possibly be implemented completely outside VESC but would benefit from integration, or at least communication.
A program in an add on module physically close to battery, monitors battery voltage. If rate of rise suggests overvolt is immenent, short B+ to B- through nichrome wire until Bat voltage falls below hysteresis cut out voltage. If voltage fails to fall by short timeout, or continues rise, switch in additional resistive loads. Perhaps a few resisters switched by mosfet for high speed and one or more switched by relay for lowspeed redundancy.
If Dynamic Braking module is able to communicate w/VESC, and VESC is aware module is present and active, Field Weakening routines could trigger the OvervoltImminent signal and VESC could forestall some undesirable protection behavior.
Would such a dynamic braking module damage VESC? Would it even work?
When you are field weakening heavily, I'd be concerned about the controllers but not the battery. On the battery you have the fuse as well as current and voltage limits.
I personally think Benjamin needs to prioritize field Weakening. My buddy's ESC is a cheap China ESC, which greatly outperforms my vesc75/300 in top speed big time, because his ESC supports field weakening.
He has about 40% higher top speed with the same motor, gear ratio and battery voltage as me. That's massive, and I am considering to skip the vesc for a China ESC 😩
It has been on vedders to-do since 2017 so maybe this needs some priority?