Compact Field Oriented Controller, ASI + Grin, limited run

bowlofsalad said:
The light flashes 18 times. Any ideas on what 18 flashes means and a solution to get the controller out of this seemingly locked fault mode?

If anyone else runs into an LED flashing error, the flash count on the LED maps out to the "Faults" field in the controller debug tab. If you hover over the faults parameter, you can see the meaning of each flag bit, and the associated flash count will be the bit# plus one [EDIT, not always the case, if you hover over each bit it will tell you the associated flash count]

Faults1.jpg


Faults2.jpg
 
awesome results! Its good to see very equal efficiency at same RPM like trapez controller.
At higher levels of flux weakening efficiency definitely falls which leads to more heat in the motor. Using faster wound motors or higher voltage will be better in that case, buts its very nice to have that feature to squeeze out more speed :D

recently i have thought of what may happen when riding down a hill fast with very high flux weakening levels. any chance to simulate this (maybe less load on the dyno)?

justin_le said:
Right now, I'm using the "automatic field weakening" mode which I understand only uses the field weakening at higher speeds where it has benefit, rather than having it do it across the board which doesn't make much sense.

yes that makes sense. i know that adaptto flux weakening starts to work above 80% PWM or somewhere in this area, so no difference below there.

edit:

aBLF41.jpg
 
madin88 said:
recently i have thought of what may happen when riding down a hill fast with very high flux weakening levels. any chance to simulate this (maybe less load on the dyno)?

You mean, to see if you can have it so it won't automatically go into regen mode even though in principle the back-emf voltage is higher than the pack voltage? Yes, I'll definitely check this out too, because there are times when you just want to fly down a hill and not hit the voltage defined regen speed, or maybe even get a kick of extra power to help with what gravity is doing.

I just set the field weakening current to 100% as a quick test and it got spinning up to 910 RPM unloaded drawing some 570-580 watts. Normally I'd expect this motor to draw about 270 watts to run at that speed unloaded, so at these more extreme values the inefficiency becomes more and more pronounced. Unfortunately my dyno bench motor controller I have capped at 600 RPM so I can't do a loaded test faster than this, but it will still be well above the normal unloaded speeds and would give some neat results.
 
yep, while the trapez controller cannot produce any torque above ~475RPM here, the FOC with flux weakening sill does.
it would be interesting how high the FOC can spin up the motor with some little load on the wheel (riding downhill very fast) :twisted:
i think the "pre-ignition" of flux weakening keeps back-EMF lower than normal, so there is more room for higher rpm but im not sure. though there will be a point where the controller cannot spin the motor faster without self destruction (back current works against controller current?).
 
bowlofsalad said:
Yowza, I just about cooked a little geared hub motor not realizing how much heat was generated in this process. Do you have any advice on how to tweak these settings? I jumped around fairly randomly, swapped the phases a few times and while the results changed, I was still pretty unsure about what I was doing after a large number of tries.

Just checking in, have you had any more luck with this? After you autotune the phase impedance (Ls and Rs ), then it's really important to have the #poles and RPM parameters set correctly. The RPM is nominally referring to the speed that the motor spins at at the "rated voltage", which we've preshipped with them set to a 60V system rating. If you have a motor with say 16 pole pairs and a 4:1 gear reduction ratio, it's important to put a #pole pairs value of 64 in this case, rather than 16. From my records I have that the Cute Q100 motors was between 64-65 effective poles.

If you aren't totally sure of the RPM/Volt, then use a best guess for the RPM at 60V and it should still spin up fine. When you run it while plugged into the computer, you'll see your motor rpm on display in the BacDoor software, divide this by your battery voltage to get the RPM/V, then multiply it by 60V to get the "motor rpm" parameter at our 60V system voltage.
 
speedmd wrote:
What is causing the blip/ sweet spot just above 350 rpm.

That I really don't know. It's present on all the graphs that I've done with the FOC controller to a greater or lesser degree, but I don't see it on the tests with the infineon unit. On the last dyno I made a point to look closely at the behavior here and could definitely feel some oscillation and shaking in the dyno bench setup as it scanned through the 355-345 RPM band. So there is some kind of resonance at play

It seems to be at just above 350 and again above 400 rpm. Wonder if it is more motor related. Looks Interesting and potentially something that can be taken advantage of if it can be harnessed.
 
speedmd said:
It seems to be at just above 350 and again above 400 rpm. Wonder if it is more motor related. Looks Interesting and potentially something that can be taken advantage of if it can be harnessed.

No, there's nothing to be harnessed here. At 400 rpm what you see there is just the transition from the CA's current limit coming into play and the ensuing initial osscilations right as current crosses the current limit threshold. At 350 rpm there seems to be a bit of feedback or play between the dyno load motor and the test motor and the test bench, you can see and feel a bit of pulsation on the power output as the speed oscillates a bit but there is no sweet spot or special performance to exploit. The data on average is right in line.

bspalteh said:
Thanks for running all those test and producing the very interesting comparison graphs Justin!

I'm curious bernhard which motors have you been running this controller on, mostly direct drive hubs or some some of the eZee motors too?
 
Have you done a regression analysis to smooth the data or see if there is a carrier frequency to the noise? Is the master and slave both controlled with a CA? Slave using a Xie Chang ?
 
No, there's nothing to be harnessed here. At 400 rpm what you see there is just the transition from the CA's current limit coming into play and the ensuing initial osscilations right as current crosses the current limit threshold. At 350 rpm there seems to be a bit of feedback or play between the dyno load motor and the test motor and the test bench, you can see and feel a bit of pulsation on the power output as the speed oscillates a bit but there is no sweet spot or special performance to exploit. The data on average is right in line.

Thanks for explaining the setup play. Nice work.

Would this controller potentially work well- be a good match for a RC type motor such as a Astro 3220 or a scorpion running sensor less, or with a GNG1 450w type sensored motor?
 
I have been testing on a crystalyte 405 in a 20" wheel that is running my velomobile. 48v, 30ag three ezee batteries in parallel so I can do close to 15a regen. Haven't had a chance to test it on the eZee or outrider yet.
 
justin_le said:
Just checking in, have you had any more luck with this? After you autotune the phase impedance (Ls and Rs ), then it's really important to have the #poles and RPM parameters set correctly. The RPM is nominally referring to the speed that the motor spins at at the "rated voltage", which we've preshipped with them set to a 60V system rating. If you have a motor with say 16 pole pairs and a 4:1 gear reduction ratio, it's important to put a #pole pairs value of 64 in this case, rather than 16. From my records I have that the Cute Q100 motors was between 64-65 effective poles.

I really appreciate your efforts, thanks so much. I shamefully admit, I've been continually failing at this seemingly simple task.

If I understand you correctly, then maybe I should use 16(poles) multiplied by 12.6(reduction ratio of a Q100) and place 201.6 in poles instead of 16? I feel like I am misunderstanding something here, when you say 64-65 poles, where does this number come from?

On page 42 of the manual there is a flow chart, it says "Have 3 repeatable measurements been made?" For much of my previous attempts to use the autotune for the Ls and Rs measurements, the numbers can at come in pretty wild ranges much of the time. What qualifies as 'repeatable measurements'? If say I get 74-110 for the Ls, should I use the average, what I see most often or wait until I see something very close (103, 104, 102 for the three measurements) and use something closer to that? I don't know how important these numbers are in terms of accuracy, but I am sure there is some logic that would be better to use over another.

justin_le said:
If you aren't totally sure of the RPM/Volt, then use a best guess for the RPM at 60V and it should still spin up fine. When you run it while plugged into the computer, you'll see your motor rpm on display in the BacDoor software, divide this by your battery voltage to get the RPM/V, then multiply it by 60V to get the "motor rpm" parameter at our 60V system voltage.

The motor is rated for 201rpm at 36v. I divided 60 by 36 and get 1.67 and then multiply 1.67 by 201 to find the motor RPM at 60V, which would be 335.67. I don't know how much the rated RPM value accuracy matters, but my hot off the charger voltage is 58.4 and I usually have seen my battery packs running around 53v, perhaps it would make more sense for me to use 302 RPM, but maybe I don't really understand how this number influences the controller.

Without your information about changing the pole count to 64-65(from 16) and changing the motor RPM to 335(from 201), the motor was painfully jerky and the whole process of programming the controller went wrong. With these changes, this q100 runs and sounds wildly better. I am sure these changes are obvious to some, but I may not have ever figured this out otherwise.

I've played a little bit with the hall offset and Kv tuning per the manual. I haven't seen any mention of this but the manual seems like it's necessary. Should I simply follow the manual on this?

I imagine with this information in mind, I may be able to gain much more success with a Q75 (sensorless geared) as well. Sorry for writing so much. Thanks!
 
bspalteh said:
What happens if you increase the field weakening value beyond that 17%, say 30% or whatever?

We decided to see what would happen if you had a slow winding motor and then used field weakening to increase the top-end speed, since it's a scenario that we've seen quite often where people are mistakenly lead to purchase a slow motor wind under the generally false impression that it has extra torque, only to find that the performance at cruising speeds is quite underwhelming. The first thing we wanted to do was confirm the relationship between the field weakening current and the unloaded RPM.

RPM vs Field Weakening.jpg

In all these tests, we had the defined max motor current at 60A, so a 50% field weakening current is 30A and so forth. The unloaded motor starts off at about 310rpm with no field weakening. By the time we hit 20A of field weakening current, the RPM has increased to about 380 rpm, while the no load current increased from 1A to just under 3A. We don't get a 50% increase in the top speed until the field weakening current is at a full 40 amps, at which point the no load current just to spin the hub is about 7.5 Amps. To actually double the RPM of the motor in this setup required the full 60A of field weakening. The resulting 17A of no-load current shows that it's pretty wasteful, and you could just watch the motor temperature start to skyrocket on the CA readout at this point.

So based on this, I'd say that the field weakening is viable to get upwards of 20-30% boosts to the unloaded speed on a slow DD hub if a higher voltage pack isn't an option, but more than this has rapidly diminishing returns.

As far as the efficiency goes, we then did a dyno test of the hub at both 0% and 50% (30A) field weakening currents, and in both cases with a 25A battery current limit:
Comparison with 50% Field Weakening.jpg

With no field weakening, peak efficiency was around 88%. In the case of the setup with automatic field weakening, it was at 80% efficiency once the weakening kicked in, and then dropped steadily to the 71-72% range. While the power roll-off from back-emf voltage started at about 250rpm with no field weakening, it was able to pull the full 25A right until 340 rpm with the 30A weakening current. So here you are getting a ~33% boost to the top speed, but at 70-80% efficiency levels compared to the 80-88% efficiencies you'd have gotten with a higher voltage pack or a faster wind hub.

Here is a repeat of the same experiment but using a 15A rather than a 25A battery current limit, representative of running part throttle. Comparison with 50% Field Weakening at 15A limit.jpg
 
justin_le said:
riba2233 said:
Thanks for the answer! :D Do you have the info on the max erpm?
Still haven't hit the "max" yet, but I did just get it up to 1200 Hz or 72,000 eRPM, running a 7 pole-pair KV 210 turnigy motor with a 50V power supply.

OK, well we've done some more test with the Turnigy motor now and have got it spinning up to just a tad over 90,000 eRPM, but it doesn't seem to want to go any faster than this, even with field weakening and other stuff enabled. So I'd say that's the ceiling. We also got a chance to talk with ASI's technical team today and they said that they usually recommend keeping below 36000 eRPM or 600Hz, because as you get faster than that then the current waveform becomes increasingly distorted and more harmonics are present.

He did admit that it was still better than the waveform on a trapezoidal controller, so even though it's less than ideal it's still presumably an improvement over most of the alternative controllers that can cope with these speeds.
 
bowlofsalad said:
If I understand you correctly, then maybe I should use 16(poles) multiplied by 12.6(reduction ratio of a Q100) and place 201.6 in poles instead of 16?

Yes! Although I suspect you mean 16 poles and not pole-pairs, so assuming it is indeed 8 pole pairs then the correct effective pole count would be 101. For self starting to work well, the #poles and the "rated rpm" parameters do need to be fairly accurate, since the controller is using this to determine the expected motor kV for the open-loop drive. If you put in 8 pole-pairs rather than 100, then you would need to set your rated RPM as the actual rotor RPM (pre-gearing), rather than the hub rpm after the 12.6 to 1 reduction. That works fine too, so having 100 pole-pairs and a 400 rpm rating is functionally identical to 8 pole pairs with a 5000 rpm rating.

I feel like I am misunderstanding something here, when you say 64-65 poles, where does this number come from?

When I had the motor on the test bench I was comparing the wheel RPM with the electrical RPM that I saw on my oscilloscope and taking the ratio, although my notes from 2012 aren't particularly thorough here.

On page 42 of the manual there is a flow chart, it says "Have 3 repeatable measurements been made?" For much of my previous attempts to use the autotune for the Ls and Rs measurements, the numbers can at come in pretty wild ranges much of the time. What qualifies as 'repeatable measurements'? If say I get 74-110 for the Ls, should I use the average, what I see most often or wait until I see something very close (103, 104, 102 for the three measurements) and use something closer to that?

We almost always see values that vary by just a couple percent from one run to the next, not by +- 20% like you mention here. There are two auto-tune functions you can run, both '1' and '4' will do an autotune but with somewhat different methods. Do both of them give equally varying results?

Without your information about changing the pole count to 64-65(from 16) and changing the motor RPM to 335(from 201), the motor was painfully jerky and the whole process of programming the controller went wrong. With these changes, this q100 runs and sounds wildly better. I am sure these changes are obvious to some, but I may not have ever figured this out otherwise.

Don't feel bad it took us months of mucking around before we got a good handle on it too, the BacDoor software is meant for engineer level access to the controller and not end-user setup. ASI is planning a more end-user friendly "wizard" style software for 2015, and if this pilot release goes well and we make this into a product for next year then we'd probably package our own quick setup software too.

With the motor rpm and poles as you have it, does the displayed RPM in the bacdoor software match the rpm of the motor that you see with a tachometer or a bike speedometer? When you have the #pole pairs set correctly, then the running motor rpm shown on bacdoor will match identically with what you actually see on the motor.

I've played a little bit with the hall offset and Kv tuning per the manual. I haven't seen any mention of this but the manual seems like it's necessary. Should I simply follow the manual on this?

We've never bothered custom adjusting the hall offset, and the Kv tuning shouldn't be needed either. If you set the motor "Rated RPM" correctly, then the value for the autotune Kv will be very close to 1.0, and so it won't need any tweaking. I may be mistaken but I think that the normalized Kv parameter is only there to adjust if the nameplate RPM at the system voltage is off, but you might as well just get the RPM setting correct in the first place.

I imagine with this information in mind, I may be able to gain much more success with a Q75 (sensorless geared) as well. Sorry for writing so much. Thanks!

Let us hope, and please keep sharing your results one way or the other until we get this running perfectly.
 
justin_le said:
We don't get a 50% increase in the top speed until the field weakening current is at a full 40 amps, at which point the no load current just to spin the hub is about 7.5 Amps.


This 7.5A no-load tax is actually a bargain for the capability to have bursts of higher top speed to overtake traffic or whatever as needed. Maybe enable it in conjunction with the motor temp-sensor equipped CA, and it dials back advance as needed to stay inside same thermal bounds of the motor, but if you wanted to race a car up to speed at a stoplight or pass traffic or something, it would be available.

In industry, going to +50% RPM boost from timing advance is actually done in a ton of production EV's. In a Tesla for example, if you are going to be traveling at 155mph, does it really matter if you have an extra 50A of no-load or whatever? Just supply the cooling to handle it, or accept that it's only available for bursts.
 
Yes it certainly would be nice to enable and disable this feature on the fly. Then you get top efficiency during normal operation and higher top speed when you want it. Two profiles in controller....or...hmmm
 
bspalteh said:
Yes it certainly would be nice to enable and disable this feature on the fly. Then you get top efficiency during normal operation and higher top speed when you want it. Two profiles in controller....or...hmmm

A Cycle Analyst, and/or wrist control gives you the same limiting. Remember, it only penalizes efficiency while choosing to use the speed, it's no penalty having it available to use when not going fast enough to require it.
 
justin_le said:
As far as the efficiency goes, we then did a dyno test of the hub at both 0% and 50% (30A) field weakening currents, and in both cases with a 25A battery current limit:

With no field weakening, peak efficiency was around 88%. In the case of the setup with automatic field weakening, it was at 80% efficiency once the weakening kicked in, and then dropped steadily to the 71-72% range. While the power roll-off from back-emf voltage started at about 250rpm with no field weakening, it was able to pull the full 25A right until 340 rpm with the 30A weakening current. So here you are getting a ~33% boost to the top speed, but at 70-80% efficiency levels compared to the 80-88% efficiencies you'd have gotten with a higher voltage pack or a faster wind hub.

I find it interesting that the BAC500+ starts using field weakening that early. I looked into the add parameter selection and there appears to be some options labeled field weakening current and field weakening speed. Is there a reason why you can't use these additional parameters to tune when field weakening starts?

justin_le said:
We almost always see values that vary by just a couple percent from one run to the next, not by +- 20% like you mention here. There are two auto-tune functions you can run, both '1' and '4' will do an autotune but with somewhat different methods. Do both of them give equally varying results?

I have tried MDM1 (motor discovery mode 1) and MDM4, they each give mildly different results from one another from my experience and the MDM1 seems more sporadic if not the same. However, I think the wildly varying Ls results (Rs seems much more consistent no matter what) might relate to incorrect settings on my part, and maybe using the MDM4 in too rapid of succession. You clarified something for me earlier about if I should divide the pole count in half or not (they use for pairs, so divide by 2) and that seems to make the results come in a fair bit more consistent with MDM4. So I am sure that using the correct pole count setting has a large effect on the varying degree of the Ls measurement.

I got a Q75 going with this controller. This seems to work great, I've played with the appropriate sensorless settings per Robbie's instructions but I haven't really been able to determine much of a functional difference. I am guessing with much higher loads than what a gloved hand can deliver to a bare motor is where these settings would really come into play. With no load and giving just something around 5% throttle and above the motor spins up to RPM without any issues. It's very exciting and very pleasing.

I did a quick audible comparison with a Q100 using an 'S12S' and a BAC500+, the BAC500+ was substantially quieter all the way through the throttle percentages, lovely!

justin_le said:
We've never bothered custom adjusting the hall offset, and the Kv tuning shouldn't be needed either. If you set the motor "Rated RPM" correctly, then the value for the autotune Kv will be very close to 1.0, and so it won't need any tweaking. I may be mistaken but I think that the normalized Kv parameter is only there to adjust if the nameplate RPM at the system voltage is off, but you might as well just get the RPM setting correct in the first place.

I guess I didn't really notice before but MDM3 creates an autotune for halls offset and Kv, are we supposed to use the autotune values or use zero?

Maybe you could give the hall offset and Kv custom tuning a try to see if you observe any differences in things like RPM and efficiency.

justin_le said:
With the motor rpm and poles as you have it, does the displayed RPM in the bacdoor software match the rpm of the motor that you see with a tachometer or a bike speedometer? When you have the #pole pairs set correctly, then the running motor rpm shown on bacdoor will match identically with what you actually see on the motor.

I am working on externally measuring the motor's RPM, tachometer is in the mail.
 
@liveforphysics, that was my initial thought too, but I believe the field weakening kicks in at a lower speed than what the top speed would be without it. So that means unless you can change the settings that even if you limit to the same top speed using CA, you would be running at a lower efficiency? I will have to study the graphs more closely to verify. If I am wrong then of course there is an easy fix like you mention.
 
You can typically set the field weakening curve anyway you like.
 
any infos about the effect of motors back EMF waveform?
 
justin_le said:
With the motor rpm and poles as you have it, does the displayed RPM in the bacdoor software match the rpm of the motor that you see with a tachometer or a bike speedometer? When you have the #pole pairs set correctly, then the running motor rpm shown on bacdoor will match identically with what you actually see on the motor.

bowlofsalad said:
I am working on externally measuring the motor's RPM, tachometer is in the mail.

I got the tachometer, the RPM I am getting externally matches extremely closely with what the bacdoor says when I have the pole count at 101. When I say extremely close, I typically see within 1 or 2 RPM between bacdoor and external. A brief refresher, I was using 202 pole count for a bit involving a q100, and the motor sounded and seemed to work out fine, I changed this to 101. Although at no load functionally and audibly I can't tell a difference, the RPM reading through bacdoor gives 157~ instead of 315~ but externally the measurement stays the same.

I don't know if I am mistaken in my observations, but after doing this similar external RPM check with a q75 I noticed some slight variation in the numbers that my original understanding of a reduction ration of 13.4 may be incorrect. I changed the pole count from 107 to 105 and the external and bacdoor measurements became almost identical. So maybe the reduction ratio is 13.125, I doubt anyone cares or mentioning this matters, but I thought I might share this anyone in case I am wrong.
 
justin_le said:
justin_le said:
riba2233 said:
Thanks for the answer! :D Do you have the info on the max erpm?
Still haven't hit the "max" yet, but I did just get it up to 1200 Hz or 72,000 eRPM, running a 7 pole-pair KV 210 turnigy motor with a 50V power supply.

OK, well we've done some more test with the Turnigy motor now and have got it spinning up to just a tad over 90,000 eRPM, but it doesn't seem to want to go any faster than this, even with field weakening and other stuff enabled. So I'd say that's the ceiling. We also got a chance to talk with ASI's technical team today and they said that they usually recommend keeping below 36000 eRPM or 600Hz, because as you get faster than that then the current waveform becomes increasingly distorted and more harmonics are present.

He did admit that it was still better than the waveform on a trapezoidal controller, so even though it's less than ideal it's still presumably an improvement over most of the alternative controllers that can cope with these speeds.

Is eRPM poles * rpm?

So this controller would be no good for a 10-pole astro motor that goes to 12,000 rpm? :-(
 
Back
Top