Compact Field Oriented Controller, ASI + Grin, limited run

Received my controller today!

I tried it on the few motors that I have and everything did spin up in sensorless after a quick buzz with the motor discovery mode :D The software is nicely laid out and easy to use. No shortage of settings to play around with. I was worried about the 60A phase limit being a bit wimpy but it seems like it will be ok. Still plenty enough for the EV grin. It does make up for it with good acceleration at all speeds.

Unfortunately I've been having problems getting it to run smoothly on my daily setup with a cyclone motor.
The basic motor setup has been smooth. The autotune gives consistent results for hall mapping and motor resistance and inductance. I have pole pairs set correctly to 4 and motor rpm is reported accurately in bacdoor. From this I've set the rated motor rpm at the rated system voltage. I haven't set up gear ratio since this will constantly change anyway using derailleur gears? Without load, power consumption is as it should be though the startup could be a bit smoother in sensored and sensorless.

The problem I've been having is that the motor stutters pretty badly at cruising speed if I stop pedalling. Also stutters spinning up the motor while the bike is already moving, making it difficult to maintain a cruising speed in higher gears. Feels the same in sensored, sensorless and sensored start modes. Its not so bad that the controller trips into fault mode but it does feel rough as the motor spins on and off. I'm thinking this is the controller having a brainfart as it takes up the slop in the crank freewheel and freehub? If I go WOT throttle and maintain pressure on the cranks to keep the freewheel engaged I can accelerate smoothly up to top speed of the motor in pretty much any gear on the bike. Often I can WOT out of the stutters. Probably not a good idea to ride around everywhere WOT but at least I have a backup plan.

I get the feeling there is a setting my new years addled brain is overlooking. And no its not the cycle analyst. I've got all the limits opened up fairly generously and they aren't coming into play during the stuttering.
 
district9prawn said:
I haven't set up gear ratio since this will constantly change anyway using derailleur gears? Without load, power consumption is as it should be though the startup could be a bit smoother in sensored and sensorless.
Click to expand...

The gear ratio is a reference to an internally geared motor. If your motor has no gears inside of it, then put 1 for the reduction ratio.

district9prawn said:
The problem I've been having is that the motor stutters pretty badly at cruising speed if I stop pedalling. Also stutters spinning up the motor while the bike is already moving, making it difficult to maintain a cruising speed in higher gears. Feels the same in sensored, sensorless and sensored start modes. Its not so bad that the controller trips into fault mode but it does feel rough as the motor spins on and off. I'm thinking this is the controller having a brainfart as it takes up the slop in the crank freewheel and freehub? If I go WOT throttle and maintain pressure on the cranks to keep the freewheel engaged I can accelerate smoothly up to top speed of the motor in pretty much any gear on the bike. Often I can WOT out of the stutters. Probably not a good idea to ride around everywhere WOT but at least I have a backup plan.

I get the feeling there is a setting my new years addled brain is overlooking. And no its not the cycle analyst. I've got all the limits opened up fairly generously and they aren't coming into play during the stuttering.
Click to expand...

The reduction ratio, pole count and rated RPM are important settings. Play around with the pole count and observe the autotune Ls and Rs measurements, they fluctuate pretty heavily depending on various settings, especially the pole count. If you have the pole count wrong, nothing else is going to work out correctly.

If you have a reduction ratio other than 1 you must multiply the pole count by the reduction ratio and use that number for the pole count. I'll illustrate. Lets pretend you have a motor that has a reduction ratio of 10:1 and a motor that has 20 permanent magnets. Firstly, be sure to divide the number of permanent magnets by 2, so in this case we come up with 10. Now we multiply 10(poles) by 10(reduction ratio) and get 100. In this scenario we would use 100 for the pole count.

The RPM I use is whatever they say the motor is rated for at a specific voltage, so lets pretend your motor is rated for 201RPM at 36v. Lets pretend your battery voltage is usually around 60v. Divide 60(volts) by 36(voltage a theoretical motor is rated to run at), you'll get 1.67. You then multiply your RPM by 1.67, which in this case is 201, which gives you 336. I use this idea for finding an appropriate RPM to enter when using a voltage other than what the RPM of the motor is at a specific voltage. This is a work around way of finding the RPM to use when you don't know the RPM/v

What helped me understand some things is what Justin just suggested in this thread, externally measuring the motor RPM. The external motor RPM measurement should match what bacdoor says.
 
I'm coming in late to this party but better late than never! I ordered one today. The ebikes.ca website shows single digit quantities left so if you plan on getting one, bow is the time to grab one before they're gone!
 
Lebowski said:
can you influence the ki and kp of the controller ? Maybe the control loop is unstable ?
Click to expand...

Aha that was it! :p

The default Ki and Kp are based on the measured motor L and R. I reduced the Ki about 20 fold and started adjusting the Kp from a fairly low value. Perfectly smooth! Throttle response is a bit sluggish but I can dial it in from here.
 
The default for some controllers are regen, which is not good if you are using a freewheel. My Kelly was and after I set it to coast, it was much smoother coming off the the throttle.
 
I did not see a response .. but has anybody confirmed the Astro motors for use with the FOC ..
I like to proceed with acquiring the two items.. but $800 is a good chunk of change.. and IF Im not getting to use the top end of the Astro motor .. then I like to find the right controller for the job.. thnx
 
myzter said:
I did not see a response .. but has anybody confirmed the Astro motors for use with the FOC ..
I like to proceed with acquiring the two items.. but $800 is a good chunk of change.. and IF Im not getting to use the top end of the Astro motor .. then I like to find the right controller for the job.. thnx
Click to expand...

Not even Astro would answer me on performance with a sine wave... they just ignored my email

Maybe go RV-120 or a Plettenberg Nova?
 
Maybe go RV-120 or a Plettenberg Nova?
Click to expand...

Ya I like the RV-100 but NOW no FOC - controller option`s ideas
 
Rouckie said:
All gone
Click to expand...

Hey everyone, yes sadly all gone, thanks to everyone who jumped in on this and the great feedback so far. There's actually been a lot less support overhead than expected required to get people using the well in a range of different ebike setups, and we're really keen to try and bring both this and a higher power equivalent into general production sometime this year.

For those who missed it, we DO have a couple units that had issues in our initial testing and QC which time allowing we might be able to sort out and get running 100%, so if you want to be on a bit of a waiting list one should they be available then send an email to info @ ebike.ca

We've also got a more recent copy of the Bacdoor software available here:
http://www.ebikes.ca/downloads/BacDoorSetup_1_5_3_0.zip
It's not necessary to upgrade this if you've got everything configured and running fine with the previous software, but if you want the most recent build with a few additional tabs then there it is. Just be sure to fully uninstall the previous version of bacdoor before running the setup with this V1.5.3 release. I'm going to be away for the next 2 weeks but Robbie will be here help with any setup related questions.

There is also some new _firmware_ available for the BAC500+ controller, and in this V1.5.3 software you have the option to update the controller firmware as well as just set the parameters. The newer firmware file itself is here:
http://www.ebikes.ca/downloads/BAC_Application_28027_5844.ehx
You click file->Bootloader to put the controller into bootloader mode where it will prompt you for the .ehx file.
 
Definitely some improvements in the new controller firmware.

Precision and smoothness of the throttle current limits seems improved. Some settings needed tweaking despite the parameters being preserved from the old firmware.

justin_le said:
There's actually been a lot less support overhead than expected required to get people using the well in a range of different ebike setups, and we're really keen to try and bring both this and a higher power equivalent into general production sometime this year.
Click to expand...

I really hope we see more of these in the future!
 
how does this controller compare to an adapto mini-e controller? it also has ability to go faster and auto detect phase/hall combination. very small too and proportional regen
 
cwah said:
how does this controller compare to an adapto mini-e controller?
Click to expand...

I can't answer that directly since I haven't seen an adaptto mini up close and firsthand, though maybe it's time to order one since they seem pretty sweet, (plus it's rad to see a Russian enterprise take an active lead here in supplying cutting edge ebike parts). I'd suspect all the performance/efficiency/torque tests and phase advance tests that I did earlier comparing the ASI FOC with the infineon controllers would turn out very much the same if done with the Adaptto units, but if we were pushing to higher power levels then the higher max phase current of the Mini-E would certainly put it in a different performance class.

Does anyone who purchased one of this pilot run of Grin/ASI controllers also have an adaptto to comment or compare? The size of ours is a fair bit smaller (140 cm^3, vs 416 cm^3 for the mini-E), but the volume density when normalized by max phase amps is similar. 75A / 140cm^3 = 0.54 A/cm^3, vs. 180A / 416cm^3 = 0.43 A/cm^3

*********************************

To update this particular thread. The bad news is that we won't be able to get more of this particular controller design manufactured, but the good news is that we'll be able to get one that is even better. Namely, it will now have 85A peak phase current capability and work with 72V battery systems as well. The board layout has changed sufficiently that the the hard coat anodized enclosures will require a complete redesign though, which could take us some time to experiment and get right.

We'll also be stocking the much larger BAC1000 controller devices, as someone asked about earlier, and at the other end are looking to do an even tinier all-potted option based around the Ne35 (formerly BAC350), for 350-500 watt setups. In this case there is just a heatsink strip on the bottom rather than a full metal enclosure, so the continuous current handling before overheating is a lot less, but still more than adequate for 15-20A setups. Here's one of the original Ne35 devices from ASI on the left, then after a bit of resurfacing by us on the right in preparation for adding the cable harness with CA and Throttle and Ebrake plugs and all that:
BAC350 Image.jpg

And an example of it mounted on the fender of a bromtpon ebike, controller volume of ~100 cm^3


In any case I'll update this thread as there is relevant progress in each of those 3 controller types, so we should then be able to have a FOC option for the 3 main power classes,
  • a potted one for the 350-500 watt range and 24 to 48V batteries,
  • another in machined enclosure for the 500-1500 watt range and 36-72V batteries,
  • and finally the BAC1000 for 2000+ watts and 48-72V packs.
 
circuit said:
It is actually interesting how this FOC works. Does it "draw" an ideal sinewave, or does it adapt to exact BEMF shape of motor?
Click to expand...

FOC controllers by their nature don't attempt to "draw" any kind of voltage waveform. Rather, they are controlling the flow of current through each of the phases, in an attempt to maintain a net stator flux that is (generally) perpendicular to the rotor flux for most efficient torque generation. The resulting voltage waveform on the phases is incidental to what the controller is trying to achieve, since it's actively driving current instead, but it generally winds up being pretty sinusoidal.

With normal "sine wave controllers", then yes the controller is drawing a sinewave voltage output based on a lookup table, sync'd to the motor hall sensors, and in that case it's the resulting current flow through the windings that is incidental. The normal sinewave controllers don't know the actual phase current flowing through the windings, and they won't automatically phase advance to account for winding inductance etc. unless programmed to do so in an open loop fashion.
 
Glad to hear you decided to pursue this. It's great that FOC has become accessible over the past few years, with multiple commercial and DIY options at reasonable cost and power levels with relatively straightforward configuration. Although the cost is still a factor of 5-10 above cheap Chinese controllers and 2-3 above a solid Grinfineon, it's worth it to some now and the discrepancy is sure to shrink over the next few years.

We're headed for a future of silent operation, true torque control, and no worries about position sensor robustness. Thanks for adding a push in the right direction!

PS I'm going to have to read up on that spark-gap current sensing you're using there... :)
 
Hi all!

I'm new to this forum, but since I also am trying to work with some BAC500+ controllers I thought it would be a good idea to sign up here. I love the open discussion and documentation of the BAC500+ and the direct support of the community by the initiators of this great product. Thanks for everything!

So far, I was able to get the controller up and running with BacDoor 1.5.0.0 and the original firmware. Because of the reported improvements with the new software and firmware, I tried to install BacDoor 1.5.3.0 on several machines (all Windows 7). I tried all possible compatibility modes, replacing .NET libraries and UAC settings, but to no avail. When I try to start BacDoor 1.5.3.0, the program crashes immediately and Windows simply states "this program has stopped working...". Has anyone else had this problem with the updated software so far?

Re-installing BacDoor 1.5.0.0 works, as long as I use the Windows XP SP3 compatibility mode. But having updated one controller with the new firmware, it doesn't seem to work with BacDoor 1.5.0.0 anymore. The LED flashes some error codes, but in the software I can't see anything beeing wrong. (Using the old software with a controller with the old firmware still works however.)

Any help is highly apreciated.

\pedaler
 
Hi,

It's also my first post, despite I'm following ES for a while, so first thanks a lot to all of you for tons of quality technical info around there.

As I faced the exact same issue as you while upgrading BacDoor and firmware, It's time to add my two cents:

BacDoor 1.5.3 seems to have internationalisation issues (I figured that out while trying to run it under wine which is slightly more verbose than Windows...)
Changing locale to en-us fixed the issue for me (in control panel/region and language, change format to English/US)

New firmware appears to flash led for warnings in addition to errors, you can get them by adding "warnings" parameters to display.
Mine was warning about Vdc/SOC foldback, which were fixed by changing battery fault and protection thresholds.

Additionally, I also faced another issue with the new firmware: there were lots of hiccups at low speed and sometimes motor even refused to start.
It turned out to come from "Hall stall fall time" that was cutting power off, I changed it from 10 to 100ms and everything went fine.

I don't clearly understand why previous firmware wasn't faulting with a stall fall time of 10ms, whenever I didn't changed any parameters...

There seems to be some changes in current regulation PID between two firmwares as some parameters are automatically updated by new firmware.
Here is what I get while pushing old config to controller and save it back without changes, and compare both configs (using some xslt and ASIObjectDictionary):

Code: 
Parameter: Current regulator Kp
    Description: The current regulator's proportional gain
    Old Value: 0.883056640625
    New Value: 0.8828125
Parameter: Pll Kp old
    Description: The old phase locked loop's proportional gain
    Old Value: 3000
    New Value: 2965
Parameter: PLL bandwidth
    Description: When non zero sets the PLL Kp and Ki terms 
    Old Value: 0radians
    New Value: 129radians
Parameter: PLL damping
    Description: When non zero sets the PLL Kp and Ki terms 
    Old Value: 0
    New Value: 3.37109375
Parameter: Pll Kp 
    Description: new PLL Kp gain
    Old Value: 0
    New Value: 869
Parameter: Pll Ki
    Description: new PLL Ki gain
    Old Value: 0
    New Value: 16640
Parameter: Saved software revision
    Description: Software version when parameters were last saved to flash memory
    Old Value: 5.519
    New Value: 5.844

I tried to play around PLL bandwidth (which automatically updates gains) without success, I definitively have to increase Hall stall fall time...

Any Idea on what could have changed between two versions?
 
Current regulator bandwidth is 1000 radians (the inital value), I tried various values from 100 to 2000 without changes on stall fall.

With 60A phase current, it gives the following parameters: (phase current and PLL Bandwidth automatically updates Kp & Ki)
Current regulator Kp: 1.9028
Current regulator Ki: 645.75

I don't clearly understand what this PID controls, is it controlling throttle torque like CAv3, or is it used internally to control the phases with shunts?

Stall fall may also have nothing to do with this PID... Maybe Hall stall fault time wasn't cutting off power in previous version. I'm using an old clyte 409 motor, which only has 8 poles pair, is it unreasonable to wait 100ms for the first hall change?
 
When you say stall fall, I'm going to assume you mean stall fault time...

Its worth giving sensorless a try to narrow down the cause of your problems. The default sensorless settings can be a bit slow and inefficient, but they should be able to spin the motor up reliably.

On the PID loops, have you tried plugging in some values and seeing how it behaves? Not sure if you have tried this but setting the current regulator or pll bandwidth to 0 allows the use of your own Kp and Ki values. All the PLL values you had are very similar to mine, so perhaps those are better left alone.
 
You must log in or register to reply here.

Similar threads

G
Phaserunner replace PMAC controller?
Replies
0
Views
484
goatman
G
thorlancaster328
Designing the ultimate (400A+) motor controller - what features should it have?
Replies
11
Views
1,828
SammyMc
S
A
50KW controller with field weakening
Replies
10
Views
1,387
Lebowski
Lebowski
owhite
    • Like
  • Locked
building the BESC - 100V, 400A motor controller [NOT RECOMMENDED]
2 3 4 5
Replies
120
Views
20,251
owhite
owhite
markz
Hacking Controller LVC
Replies
5
Views
2,382
jordanjozsef
J
Back
Top