Field Weakening and MTPA support

[nitrousnrg]

This is a major feature that will demand some careful review, its tested and crafted to be mergable.

The control scheme has been adopted from here

Here is a video of FW working, injecting a negative Id current to produce torque beyond base speed.

https://youtu.be/02jA0u5V-X0

FW unlocks the full constant power region of the machine, wich was not used up until now:

In speed control mode there are some integrator issues, it takes too long to "forget" the error signal and an anti-windup didn't work very well.

Before trying this you may want to merge #90 as it comes with a fix for proper simulation of this. Hum, it seems that commit is getting included here. The simulation was super useful and allowed to test the new control. The real motor behaved just like the simulation.

Id current will be limited to a % of the max motor current, its hardcoded for now.

This also simplifies the virtual motor command, as now it fetches the motor parameters from the stored motor configuration. It wasn't possible before because vesc wasn't aware of Lq and Ld inductances.

To enable this feature, VESC Tool requires this patch:
vedderb/vesc_tool#34

If approved this will close #73 and #76

Have fun!

[vedderb]

This is very nice!

I'm currently looking through the diff, here are some comments so far:

• The virtual motor should probably be re-initialized in mcpwm_foc_set_configuration in case the address of the configuration changes (does not happen currently, but it can potentially become a future bug). Re-registering the same terminal commands is no problem.

• The axis decoupling is nice, but it currently works on random parameters unless they are set manually, and is always active. The best way probably is to remove L and replace it with Ld and Lq. I can look into that.

Field Weakening
For the field weakening (FW) I think a completely different strategy might be better. I need to think about it more, but I imagine something like this:

• FW is only active if the q axis modulation is greater than 95% of maximum and the q axis current is lower than the set current. Thus there is no room left for regulation. If that is not the case, the d axis current is gradually ramped back to 0.
• The error is based on the difference between iq and iq_set. We try to always reach the q axis set current.
• The total current has to be truncated to lo_current_max.
• The mechanism for releasing the motor when a current lower than the minimum current is requested has to be changed. If there is d axis current we need keep the modulation on until it is ramped back to 0.
• FW has to respect the speed limits. If it respects lo_current_max that can happen automatically, as lo_current_max is updated by the speed limits in mc_interface.
• There should be an option to limit FW to an RPM where the motor just is below the RPM where it would push current back if all FETs are released (which probably is close to the maximum BLDC RPM). I think this option is very important, and should be enabled by default. It would mean that FW keeps the motor in a safe speed at all times, and still allows to generate torque all the way until that speed is reached. For most motors that should be a significant improvement.

I think this approach will be stable even when requesting low(er) or negative currents at high speed (I hope this makes sense). Even when the set current is negative and the current is more negative and modulation is at maximum, FW will activate and prevent unwanted braking.

To test FW and make sure that it is stable I would recommend the following:

• Use the arrow keys and push the current to a speed that requires FW. When releasing the key, modulation should stay on until the motor has slowed down enough for id to go back to 0, after which modulation should be switched off (motor released).
• Manually push the motor to a speed where it generated back emf higher than the input voltage when the modulation is off. I think that modulation should not switch on in this case, as that might cause strange behavior during faults.
• Test what happens when a fault occurs during FW.

[maxicor88]

Thanks Benjamin for your comments, I will try to answer point by point.

About reinitializing virtual motor, it is easy and I will add it in a next commit.

About axis decoupling parameters, I agree with you it can be better to have only Ld and Lq but I did not want to touch the measurement of inductance functions, maybe it's better you touch that. What I have done related to this in Vesc Tool PR is to charge Ld and Lq with the same value as L once you got the apply button.

About Field Weakening comments, I tried to follow a similar strategy I have seen in many papers and in Texas Instruments approach. I think that your concerns can be solved modifying some lines.

For instance, I am taking as input error signal the absolute modulation, I can change that for q axis modulation only easy. I am taking as limiting current the absolute max current, I can change that for lo_current_max and test.

About your comments of taking care of the id current if the system is stopped, or a low current is set, it was something I did not remember to add and I agree it is very important. I will try to think in a way to control this.

We will test the code further considering your observations. What I have done so far is to always test the code first with the virtual motor attached, and once I was sure it was running well, I tested with out lab motor test bench. What I was very happy about is that many times I have seen the same behavior with the virtual motor and with the real motor, so it is very useful. This way, with the virtual motor, I could change the load while running and see how the speed or current changes.

I am sending this message now, because I am running low battery at the cell phone...then I will add some more comments when I reach the laptop.

Thanks again for considering our PR.

[maxicor88]

Hello Benjamin, in last commits I started to add some of the changes you proposed lately.

1. Virtual_motor is reconfigured when a new motor config is set. To do this in a cleaner way, I created a function inside virtual_motor library that grouped all the variables that should be updated when motor configuration changed. This also helped me to clean up the code and delete an auxiliary function in mcpwm_foc.c that now it is unnecessary to have.

2. Now Field Weakening error signal is taken from the difference between the modulation in the q axis and a threshold value.

3. Total current is limited at lo_current_max.

4. We are still working on your comments of how to control id when a low current command is set. The way we implemented so far is very simple and will be upgraded. We are adding a new motor control mode called CONTROL_MODE_RAMP_DOWN_ID, that will be in charge of this operation, and will need to replace the different calls that stop the pwm signals and stop the motor (as that might be dangerous under field weakening) to a function that activates this new control mode. Once inside that mode, we will try to make the current drop at the same rate as the speed does, if this speed can cause dangerous voltages.

But we wanted to show you how are we dealing so far.

Thanks

[rushi-jariwala]

Hi,

Is there a code available for measuring Ld and Lq inductance? Or is there any plan to implement that?

Also, any idea what would be the impact of Ld, Lq saturation with higher currents?

[nitrousnrg]

No plan to implement Ld Lq parameter detection on my end. We focus on big machines which are few and high quality, you can manually measure the inductances once and use the values for all motors of the same model.
Nothing stops you or Benjamin from developing Ld and Lq detection, its likely to gain a % of extra torque in some motors.
You would need to make the motor rotate while you measure the inductances.

Saturation behavior is yet to be seen, the observer struggles with saturation, but in our case these motors usually come with a resolver or encoder.

[rushi-jariwala]

Thanks Marcos for the quick reply.

Regarding field weakening, I believe the block diagram showed in TI document should work. I have seen it in more papers. MATLAB also follows the same approach in their simulation (pe_pmsm_field_weakening_control). It is similar to the concept shown in Fig 3(c) of the attached paper.
Full paper - EPE 2011.pdf

[rushi-jariwala]

Hi Marcos and Benjamin,

I am working on a motor controller from some months now. I have a few queries which I tried searching on a lot of forums on endless sphere or Github discussions. I did not find much success.

1. How do you size a DC-link capacitor for FOC control? Do you have any documents or is there any discussion that I can go through? I know the rms ratings of the current is the deciding factor. However, I am not sure how to analyze/calculate it. Any help from your side would be great.

2. Is there any explanation on the sensorless algorithm used in VESC controllers or any documents/discussions I can go through?

There are a lot more queries which I keep for some later time.

You'll have done a great job in making the VESC controller open-source. I will try to contribute as much as I can with my knowledge in the field of power electronics and motor control.

[nitrousnrg]

I'm glad to see you on board, but this is not the place for those questions. Please head to the forums for that, this place is created for the sole and specific purpose of discussing the Field Weakening and MTPA integration into the vesc codebase. Anything else is noise for the developers.

[gowrav]

Just adding the note to the discussion of safety implementation in Inverter Circuit under Field Weakening Mode.

https://patents.google.com/patent/US7554276B2/en

[gowrav]

Field Weakening on Deceleration blew the MOSFET.

https://vesc-project.com/comment/3801#comment-3801

[nitrousnrg]

I'm following your case. There is a key missing feature in this branch, as maxi commented, which is the lack of a controlled rampdown while FW is active.
Let me know when the images in your post are fixed so we can take a look

[gowrav]

I'm following your case. There is a key missing feature in this branch, as maxi commented, which is the lack of a controlled rampdown while FW is active.
Let me know when the images in your post are fixed so we can take a look

The images are now visible...

[maxicor88]

I'm following your case. There is a key missing feature in this branch, as maxi commented, which is the lack of a controlled rampdown while FW is active.
Let me know when the images in your post are fixed so we can take a look

The images are now visible...

I am trying to replicate your case, I answered your post at vesc forum.

[javmarina]

Any update on this?

[Teslafly]

Now that HFI is working in fw 4.0, and with it a way to measure ld and lq directly, this may be worth progressing further?

Would field weakening be a better solution than overmodulation in all cases? Even in motors that are poorly suited to field weakening? Overmodulation would at least be able to match the maximum speed of the bldc mode.

[nitrousnrg]

Yes, the time has come. I merged master to this branch locally and will be testing this week starting with a small IPM motor and then a large one.

All I know is field weakening performance depends on motor construction, not all motors have a flat constant power region.

[nitrousnrg]

So a small update, I have basic FW working, going 50% beyond base speed with id=-30A, small IPM motor. Its being limited by the phase current limit set at 60A, it can go faster with higher limits.

The code now calculates the base speed ( vbus*flux linkage / sqrt(3) ) and when you command 0amps it will set iq=0 and wait until rpm is below base speed to fully stop pwm.
Previously it had a id rampdown that stopped pwm in a wrong place which I think is why gowrav got some blown fets.

Waveforms look ok with the motor unloaded

When I load it it stops working but I think its poor observer tuning, I still don't dare trying this in the bigger motor with resolver to check loaded operation.

Next week I will spend some time tuning sensorless operation and preparing a push to get this remote branch a bit more in sync.

FW will need an extra fault management mode in which when a DC Link overvoltage is detected, SVM is set to v0 so all bottom mosfets are ON and the motor phases get shorted until the overvoltage is gone. This should have priority over an overcurrent fault.

[rushi-jariwala]

Great work!

Just a query - when u turn on all the lower FETs during over voltage condition - will it cause the motor to brake suddenly? Or will it just coast down to 0 speed?

[nitrousnrg]

Just a query - when u turn on all the lower FETs during over voltage condition - will it cause the motor to brake suddenly? Or will it just coast down to 0 speed?

It would be a dramatic braking, with possible loss of vehicle control. The energy dumped into the motor windings would be massive and the event should be short, as it only needs to slow down to non-destructive speed. Possible loss of vehicle control is usually better than a certain fire.
A similar thing would happen if pwm stops for some reason during FW, in this case the energy would be dumped into the battery instead of into the motor, and braking power would be smaller.

This motor short event would be very rare, because I don't think vesc will allow FW speeds capable of blowing a powerstage. For example if you have 12s batt with 60V fets, you don't have headroom to safely increase the top speed.

[gowrav]

So a small update, I have basic FW working, going 50% beyond base speed with id=-30A, small IPM motor. Its being limited by the phase current limit set at 60A, it can go faster with higher limits.

The code now calculates the base speed ( vbus*flux linkage / sqrt(3) ) and when you command 0amps it will set iq=0 and wait until rpm is below base speed to fully stop pwm.
Previously it had a id rampdown that stopped pwm in a wrong place which I think is why gowrav got some blown fets.

Waveforms look ok with the motor unloaded

When I load it it stops working but I think its poor observer tuning, I still don't dare trying this in the bigger motor with resolver to check loaded operation.

Next week I will spend some time tuning sensorless operation and preparing a push to get this remote branch a bit more in sync.

FW will need an extra fault management mode in which when a DC Link overvoltage is detected, SVM is set to v0 so all bottom mosfets are ON and the motor phases get shorted until the overvoltage is gone. This should have priority over an overcurrent fault.

🤟🏽Nice to see things coming together., can you share the updated code on a branch for us to fork and test with our motor [unloaded] currently., we are using A200Sv2 from Euan Mutch , so the IRF7769 can handle upto 100v Vds while braking.

My rig is not IPMSM , but I can give my feedback if it helps with a 6kW SPMSM water cooled motor with hall sensors.

[nitrousnrg]

I'm working on a push. Yesterday I was setting up a vesc75/300 paired with a turnigy 6364 outrunner to see how it works there.

Base speed was 20kerpm, with id=-10A it reached 22kerpm

After some real use we will find out if this is ok, right now the FW controller is running very limited, you can see I commanded 14.5A but iq is only 3.5A. The goal is to follow the commanded iq=14.5A even if it maxes out the phase current limit with a very large id, which may require a bit of algorithm change.

This test was done because I can't get this to run with my small encoderless IPM motor under load. I think Ortega's observer doesn't work with IPM machines so now I'm looking for observers made for high-saliency motors.

[vedderb]

I found that with an unloaded motor, with brake/regen current set to 0, the motor tends to stick at max duty when field weakening current is set, any current / duty control stops responding with the motor stuck at max rpm

I guess this is not a big problem since most applications are loaded and with regen current, but this can be kinda scary

That should not happen unless your current measurements have some bad offsets and/or the motor inductance is really low. Can you give some details about your setup and configuration?

[Kezii]

That should not happen unless your current measurements have some bad offsets and/or the motor inductance is really low. Can you give some details about your setup and configuration?

I'm testing with a dual fsesc 6.6 and a 120100 35kv freerchobby motor, I did the offsets calibration several times and maybe one time the motor managed to shut down properly, the fsesc current sensing is not very high quality to be fair

Detected motor inductance is 26,46 µH with 17,1 mΩ

It exhibits this behavior even with only 1A of field weakening, I have to brake the motor with my hand to exit the field weakening region and then it starts responding again

the rest of the setup is everything default, with low-ish motor and battery current and no regen (i'm from an ac power supply)

[vedderb]

I'm testing with a dual fsesc 6.6 and a 120100 35kv freerchobby motor, I did the offsets calibration several times and maybe one time the motor managed to shut down properly, the fsesc current sensing is not very high quality to be fair

Detected motor inductance is 26,46 µH with 17,1 mΩ

It exhibits this behavior even with only 1A of field weakening, I have to brake the motor with my hand to exit the field weakening region and then it starts responding again

the rest of the setup is everything default, with low-ish motor and battery current and no regen (i'm from an ac power supply)

Can you try to allow 5A or so regen? If the current measurement is bad it might not allow the modulation to decrease when that violates the regen limit. I have seen that happen on hardware with poor current measurement.

[Kezii]

After a long power cycle now it works smoothly, I tested for several minutes without issue, if it happens again I'll increase the regen current, indeed the current measurement is very noisy and it tops at about 5A

Thanks

[maxicor88]

I run some tests today with latest code from dev 5_03 branch in Axiom board, and the results were promising.

I did not push it too hard, used a max duty of 40% and start field weakening at 30%, and a field weakening current of 2Amps. The max speed went from around 8000 erpms to 8600 erpms. This was unloaded.

I will try to run some tests during the week using the dyno.

I will eventually also try to use the algorithm we were working on, and compare results of both.

Great work so far.

[nitrousnrg]

My vesc throw fault codes at the moment otherwise I would give it a try. Let me know if you need me to do some tests after the fault issue has been worked out.

The fault issues can't be worked out, its part of the intrinsic safety risks of running FW.

From the ~25 fault codes we have, I think we could gracefully manage only 3 of them with a coasting instead of pwm shutdown:
FAULT_CODE_OVER_VOLTAGE
FAULT_CODE_OVER_TEMP_FET
FAULT_CODE_OVER_TEMP_MOTOR

The rest of the faults compromise current measurement, angle measurement, or code integrity which renders the firmware unable/unsafe to keep id under control so the safest action is to shut down the PWM, with the consequence of uncontrolled regen current (and breaking) through the body diodes.

[bj97301]

Got it. Just trying not to brick it. Sounds like the fault code issue will always be a problem, right?

[vedderb]

Got it. Just trying not to brick it. Sounds like the fault code issue will always be a problem, right?

Yes, there is no way around that. The fault codes are triggered and switch the entire power stage off as a last effort to save the hardware when there is nothing more that can be done. With field weakening that is still the best that can be done in those situations, but it is much more likely to lead to hardware damage. Therefore you should make sure that your setup and all settings are stable and work well with rapid current changes before activating field weakening.

The things I have with VESCs that I use almost daily (longboards, electric motorcycle, rc car, ebike) never generate fault codes after they are configured properly. I only see them when e.g. one of the motor cables on the longboard unplugs itself or something shorts out, which is quite rare.

I have also been pushing this rig to its very limits for 3 days now while testing the field weakening, and it is still alive:

The white brackets are polycarbonate, so they can take over 100C without getting soft. The motors have been running with 50A FW current until thermal throttling many times now while I was provoking them with current commands, and so far everything is alive. One reason for that though is that I used a lab power supply at 20V, and when it tries to push current back the capacitance is quite limited and the diodes in the FETs are fine charging them to 30 or 40V. With a battery on the input it would probably be dead by now, but that is mostly due to my first implementation. In this entire process I got 0 fault codes, so a proper motor configuration, good hardware with decent current measurement and proper connections usually don't generate fault codes. Very low inductance motors are the exception, but I don't think field weakening is too useful on them anyway (if my understanding is correct).

[maxicor88]

We tested this code 998bc17 in our big dyno setup (Axiom board + Leaf Motors + Resolver position feedback).

Without Field Weakening, the code works OK, but once we tested Field Weakening, the motor spins to full speed and keeps it there while letting off the throttle.

This was with a FW current of 100Amps, FW start at 90%, FW delay 200ms, and Max duty of 95%.

It is worth noting, that we had this same behaviour a week ago with our own FW approach, and we were trying to figure out what was causing it.

Our guess is that we might have some misconfiguration in the resolver, or something that generates an small error in the position feedback, that might cause that when the systems is trying to control 0A Iq current, and 100A Id current, in fact our position error is making 1A Iq and 99A Id (for example), and that is enough Iq to make it go full speed in an unloaded situation.

If that is the case, I guess we should consider that this might be a pretty common situation (a tiny error in position feedback), so having some algorithm that can still lower down the speed should be useful.

We will try to run some more tests, to get more info and get back to you soon.

[vedderb]

That sounds very likely. Sensorless probably has a very small position error at full speed, which most likely is why I didn't see that problem. Do you have a way to command a negative current? Then you can see if you slowly can bring it out of that situation and how much negative iq is needed to overcome the offset.

I have also seen that even without field weakening, when the motor has very low friction and modulation is left on with 0A current set, the motor can still stay running because the current offset is enough to overcome the friction. Without field weakening the modulation is switched off completely when 0A is commanded, which always will slow down the motor as the current truly becomes 0A. To test if this is what happens you can disable FW and command a current of 0.1A, which should keep the modulation running. If that also keeps the motor running then current offsets and low friction are likely to be the cause.

One way to work around this would be to add some fraction of the FW current to iq so that it will always tend to slow down the motor when the throttle is released. A new parameter could be a percentage of the FW current that is added to iq (e.g. 10% by default). Then if you have, for example 50A fw current and command 0A iq, iq will be set to -5A (10% of 50A) to ensure that the motor slows down even when unloaded.

[Kezii]

That sounds very likely. Sensorless probably has a very small position error at full speed, which most likely is why I didn't see that problem.

FWIW i got that bug with the AS5047 encoder, I remember that I thought about that too and tried sensorless, and the problem remained

[nitrousnrg]

So I tried this code in Luna hardware and I can note 2 things:

• In sensorless mode it works great, it reaches max FW speed and comes back to 0rpm even completely unloaded.

• In hall sensored mode, if the motor is completely unloaded (mid-drive spinning backwards) it will stick to max rpm and I have to reboot the code to stop the motor. In the same test but spinning forwards the drive unit provides a bit more mechanical drag (there is a clutch involved) that is enough to slow it down.

Test was done with a 76V battery but max duty reduced to 35% and FW engagement at 30%. I want to test deeper FW with a 52V battery soon and with more inertia.

This is consistent to previous FW testing I did about a year ago, its pretty easy to mistune the motor and not be able to slow it down.

The code seems to be working, in my case it sounds like I could tune a bit better the hall sensor offset.

With Axiom its misbehaving badly but to me it looks like a wrong resolver offset, will keep you posted. Fun note is that disconnecting the 120V battery at FW speeds increased the input voltage to 330V.

[ddosoff]

First attempt done! feb1be5

Thanks Benjamin!

A question about FW.
In current mode, If overcome motor moment and rotate it backward the motor will act as brake. Brake moment will become less intensive when speed up in FW mode? Until zero at max speed?

[vedderb]

Thanks Benjamin!

A question about FW.
In current mode, If overcome motor moment and rotate it backward the motor will act as brake. Brake moment will become less intensive when speed up in FW mode? Until zero at max speed?

The braking torque should never be limited by FW. As soon as you start braking the modulation will drop, which moves you out of the FW-region the more you brake.

[maxicor88]

Good news on Axiom , we confirmed the issue we were having was related to an small difference in the Resolver offset angle. We run several tests, and we were getting offsets from 24 to 31 degrees. We noticed that with some angles, at a large FW current the motor was kept running at high speed, but if we tweak that angle, the motor could successfully slow down. So we end up at around 27 degrees to be the perfect setup.

Here is a video of our last tests hosted by our partner Arlin.

https://www.youtube.com/watch?v=5DzFZv0SP9U

We still believe that it might be a good feature to have a percentage of braking setting (like 1% of Id or so), as in some applications might be hard to setup the perfect angle.

It is interesting though, that making this tests, it is like a perfect way to realize properly if the Iq you are setting up is actually generating torque or not. It seems like an indirect measurement of the angle, setting Iq as 0, and seeing if it actually generating torque or not.

We will run more tests next to see the behaviour of FW at large power levels.

Cheers

[vedderb]

Nice test, thanks for the video!

A few comments:

• Field weakening duty start is not an absolute duty, but a percentage of max duty. You can leave it at 90% or so even when you limit the maximum duty.
• The reason that the FW-current decreased for full throttle is probably that the current limit was close the the FW-current. The magnitude of both set currents was limited together, so when commanding a higher current the FW-current would get limited as well. I have now changed that so that the D-axis current has priority over the Q-axis current, so hopefully full throttle should not suddenly bring the FW-current down.

I will add the Q-axis negative current percentage tomorrow.

[vedderb]

I have added the negative Q-axis current parameter now. The beta build is updated:
https://vesc-project.com/node/2859#comment-7398

[hicham-barhoumi]

I did some basic test on un ebike hub motor vesc 4.12, it work perfectly with up to 7 amps of fw. no issue recovering down from fw.

[maxicor88]

I wrote the algorithm we have been testing in Axiom boards last year, based on a PI regulator here #289.

I tested it successfully in Axiom boards with an small motor. We will run more tests on the big dyno setup and comment.

Something to point out, is that in one of our controllers in the big Dyno, the Motor cannot slow down even at 10% of Q current. We run the encoder detection several times to discard any issues with this angle, but the issue persists.

Will keep you posted when we run further tests.

[ddosoff]

I tested FW on 75300 with QS205 4kw hub.

Without FW it have 16200 ERPM at 62.5V. With 100A FW it have 18800 ERPM with disabled 'Sample in V0 V7'. And 19800 with enabled Sample in V0 V7.

Why Sample in V0 V7 affects max ERPM?

[jokucale]

Hello, I have one question. Were can i found the VESC Tool wich support the FOC Feature? The public VESC Tool support not the FW 5.03 <dev> Version. Can somebody send me a link to a VESC Tool which support FW 5.03 or give me some advice? Kind regards Jochen Kudicke Gesendet von Mail für Windows 10 Von: Kirill Kostyuchenko Gesendet: Donnerstag, 8. Juli 2021 11:19 An: vedderb/bldc Cc: jokucale; Manual Betreff: Re: [vedderb/bldc] Field Weakening and MTPA support (#91) I tested FW on 75300 with QS205 4kw hub. Without FW it have 16200 ERPM at 62.5V. With 100A FW it have 18800 ERPM with disabled 'Sample in V0 V7'. And 19800 with enabled Sample in V0 V7. Why Sample in V0 V7 affects max ERPM? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[electricrt]

I've been doing extensive road testing with field weakening and MTPA with a small IPM motor.

it seems FW is quite smooth, I'm running 90A of FW.

Was getting brake surge when lifting off the throttle at high speeds but enabling Current Control Decoupling- BEMF reduced brake surge significantly.

[maxicor88]

We have been running some more tests in our dyno setup, using Field Weakening and MTPA.

We found and issue under Field Weakening in which we see duty drops (in fact Duty changing its sign). We tried a couple of solutions but could not found a proper way to deal with this.

Here is a video showing our issue. https://www.youtube.com/watch?v=npjrCQJNEbc

You may see that when the duty drops happen, Vq is near 0.

And I see from this

bldc/mcpwm_foc.c

Line 2978 in 5ad0c88

motor_now->m_motor_state.duty_now = SIGN(motor_now->m_motor_state.vq) *

That it might be an issue with noise in Vq that it might be changing its sign.

We tried putting an extra filter on Vq prior to taking its sign, but with no improvements.

I even think this might be causing some drop in performance because it might be affecting the system getting out from field weaking for a short period of time because of this:

bldc/mcpwm_foc.c

Line 3090 in 5ad0c88

duty_abs > motor->m_conf->foc_fw_duty_start * motor->m_conf->l_max_duty) {

We wanted to bring this up to see if we can get any ideas, maybe a better way to calculate the sign of Duty, instead of using Vq (which might get always very close to 0 under Field Weakening.

Thanks for the help.

[ddosoff]

I found it's easy to cause ABS_OVER_CURRENT or DRV_FAULT if you use FW, push some strong current and then change
direction from fastest speed.

Also I got FAULT during towing when cable is free enough and motor run with fastest speed and then applying moment.

I tested with QS180 8kw mid motor, 22s battery, 100250 Trampa VESC.
Also I tested on custom VESC hardware and got hardware 450A drv faults.

Set FW current to 100A, push 100A in one direction with key UP, then press key DOWN to reverse direction result with DRV fault on my hardware or ABS_OVER_CURRENT on 100250.

[vedderb]

@maxicor88
I had a look, and I think the problem is that the voltage vector approaches being 90 degrees ahead of the rotor. The duty cycle represents the percentage of voltage modulation and the direction relative to the rotor. If it turns negative it means that a scaled down version of that voltage from standstill would cause the motor to rotate backwards. Maybe the voltage lag from the inductance * current * rpm + the FW current cause the voltage to be more than 90 degrees ahead of a high inductance motor under high load and field weakening.

In most places in the code only the absolute duty cycle value is used. One problem is where the absolute value of the filtered duty is used, as it will start to decrease when these negative pulses appear. One of these is actually my FW implementation, so there might be some problems caused by that. Here is a fix:
4603ff5

[ddosoff]

Hello Benjamin,

I spent some hours to find good current KP KI for my 8kw qs mid with 120A FW current. It's not easy to find them good for no FW and FW regions.

I think good solution is different KP1 KI1 for Q axis and KP2, KI2 for D axis. This should solve the issue.

[patrolbav]

Good news on Axiom , we confirmed the issue we were having was related to an small difference in the Resolver offset angle. We run several tests, and we were getting offsets from 24 to 31 degrees. We noticed that with some angles, at a large FW current the motor was kept running at high speed, but if we tweak that angle, the motor could successfully slow down. So we end up at around 27 degrees to be the perfect setup.

Here is a video of our last tests hosted by our partner Arlin.

https://www.youtube.com/watch?v=5DzFZv0SP9U

We still believe that it might be a good feature to have a percentage of braking setting (like 1% of Id or so), as in some applications might be hard to setup the perfect angle.

It is interesting though, that making this tests, it is like a perfect way to realize properly if the Iq you are setting up is actually generating torque or not. It seems like an indirect measurement of the angle, setting Iq as 0, and seeing if it actually generating torque or not.

We will run more tests next to see the behaviour of FW at large power levels.

Cheers

Hi guys!
Keep in mind that motor torque depends not only Q-axis current.
This is valid only for non-salient pole motors in which inductances Lq = Ld.
This is not the case for real engines. And the torque is created not only by the Q-current, but by D-Current too.
And the greater the difference between Ld and Lq, the higher at this torque.
Here is the moment formula for a salient pole rotor:

M = 1.5 * Zp * (Iq * W + Id * Iq * (Ld-Lq))
where W- flux linkage PM.

Therefore, even with Iq = 0 and FW turned on, there will be an accelerating torque and it can be higher than the friction torque.
The engine will not stop at the same time.

Sorry for my english :-)

[vedderb]

Some updates:
We have put some major work into getting all scaling and equations right in the firmware. The main improvement is that the inductance measurement as well as the ld-lq-diff measurement is much more accurate now (they were off by more than a factor of 2 before). The observer also takes motor saliency into account now and tracks a bit better when Ld-Lq != 0 (verified with encoder). The Ld-Lq setting is now separate from MTPA and only affects the observer if MTPA is not used. The MTPA mode is now moved to the FOC->Advanced page.

I have also been working on a motor comparison tool that takes saliency and MTPA into account. It can be used to e.g. calculate how much field weakening current is required to reach a given speed at a given maximum voltage. The tool takes a desired torque and RPM and calculates all motor currents and voltages at that torque output. To deal with the effect of saliency and MTPA on the torque it runs a fixed point iteration loop to calculate the currents such that the desired torque is reached.

You can right-click (and drag) in the graph to update all values below it at that point. It also updates the plots and values live when any setting is changed.

Here is a field weakening example with the trampa 160 kv motor with an RPM sweep from 0 to 7000 RPM at 5 Nm load:

The current is adjusted so that the output torque is fixed in the test. As you can see, with 40A field weakening current it takes 52.4V bus voltage to reach 7000 RPM at 5 Nm. Without field weakening, the same would take 60V. Also note that the Q axis current is lower with field weakening active, as the D-axis current contributes with some torque because Ld-Lq is set to the measured value of the motor. Note that this tool applies the field weakening current in the entire plot, so it is intended to see what field weakening does to every operating point. I might add a mode some time where the input voltage can be fixes and field weakening is applied in the same way as in the firmware.

To attempt estimating core losses and calculating efficiencies the no-load current has to be set in the Additional Info -> Setup page. Also set the number of motor poles while you are there:

If MTPA is active in the config it will be used in the comparison tool as well. Here is a comparison with the trampa motor with vs without MTPA:

MTPA only gives a slight efficiency increase on this motor, but more importantly the bus voltage requirement goes down by quite a bit (47.6V to 43.5V) when using MTPA on it.

As usual, you can have a look at the commits in the development branch to see the changes and download a precompiled test version of vesc tool here:
https://vesc-project.com/node/2859

[nitrousnrg]

I just gave it a try and its very cool. With the motors I have here it seems to provide reasonable results, but I know my detected motor parameters are not ideal (had to avoid going sensorless for a long time). I'm gearing up for testing the latest code with improved motor detection to test this better