Go Back   EcoModder Forum > EcoModding > Fossil Fuel Free > Open ReVolt: open source DC motor controller
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 03-26-2009, 04:56 PM   #671 (permalink)
EcoModding Lurker
 
Join Date: Aug 2008
Location: Salt Lake City
Posts: 37
Thanks: 0
Thanked 0 Times in 0 Posts
Squeal and Growl

Just finished readying the whole thread (whew!). First, congratulations. Great accomplishment. I want one! I just need to learn how to solder now.

I have a question, and perhaps I just missed in an earlier post. The reason you hear the squeal from a Curtis controller (or the growl from a Zilla), is because at low throttle position, the controller cuts the PWM rate from 15K Hz to 1.5K Hz. This is because they found it harder to do current limiting fast enough at 15K Hz PWM. If you're staying at 16K Hz the whole time, how does your controller get around that when Curtis and Cafe Electric didn't?

Thanks. Keep up the great work.

Bill

  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 03-26-2009, 05:01 PM   #672 (permalink)
Master EcoModder
 
Join Date: Jun 2008
Location: London, Ontario
Posts: 1,096

2k2Prot5 - '02 Mazda Protege5
90 day: 33.82 mpg (US)
Thanks: 0
Thanked 12 Times in 9 Posts
Thanks for the input, Bill. Do you have any idea why it was harder to control current at high freq than at low? I would have expected high freq to have shorter ON times than low freq making current control easier. Alternatively, i could see the reasoning behind that being lower switching losses when less power is required by the motor...
  Reply With Quote
Old 03-26-2009, 06:35 PM   #673 (permalink)
EcoModding Lurker
 
Join Date: Aug 2008
Location: Salt Lake City
Posts: 37
Thanks: 0
Thanked 0 Times in 0 Posts
Re: Squeal and Growl

I'm thinking that because his controller has both software and hardware current limit protection, and because he's not using an excessively large motor on his VW, he'll probably be okay. Here's an amusing explanation about the 1.5 Khz from Godfather Lee Hart: Inside a DC Controller with Lee Hart

Bill
  Reply With Quote
Old 03-26-2009, 06:58 PM   #674 (permalink)
EV Converter
 
Join Date: Mar 2009
Location: Saugerties, NY
Posts: 51
Thanks: 0
Thanked 0 Times in 0 Posts
Paul, I finally finished reading this thread. You have accomplished so far more than some of the experts in the EV conversion field. While others just talk a good game you actually got off you A$$ and made it happen. Congrats on your accomplishment to date.

I have a few things that you may want to consider as you go forward. I'm not sure how much room you have available on the ATMEGA8, but some of these features may make a more complete controller.

1. As we discussed on the EVtech DL, motor overspeed failure is something that has happened to too many people, especially EV newbies. I think you are already working on this. The one thing to make sure of is that whatever sensor you use, it needs to stay isolated from the chassis ground for safety.

2. Pre-charge. I noticed in the video that you had a separate pre-charge switch. Do you plan to have this feature automated? IMO it definitely should be something that is automatic. For example, you get in the vehicle and turn the key to on. This closes a relay that feeds 12V power to the controller, then you turn the key to the start position and this engages another relay that pre-charges the caps, 2-3 second delay, and then the main contactor engages the traction pack. Good to go.

3. If you have the speed sensor feeding in the RPM information into the controller you may want to have the program multiply that signal by X times and then output it so that it can run a tachometer. Tachometers normally translate pulses to RPM the X depends upon the number of cylinders and the specific type of speed sensor the OEM used. However, having that output would be a nice feature. That may be tricky as you will need an optocoupler make sure the signal stays isolated from the chassis ground.

4. Failsafe is something to always keep in mind. There has been talk about what if the mosfets fail shorted. That is unfortunately not unheard of. It happens. If your controller sends the signals to the precharge relay and the main contactor (as suggested above), it can also turn off the main contactor if it finds that the current has surpassed the hardware current limiter. In the scheme of things I think its very unlikely that the hall effect current sensor it going to fail at the same time the mosfets fail.

5. If the current sensor does fail it will probably register 0 current, it should be easy enough to program the controller to be able to tell that something it wrong it the duty cycle is anything more than 0 there should be some current flowing.

6. Many controllers allow you to set the maximum battery current. This prevents you or someone you let drive your car from damaging the batteries. If you want your batteries to last you don't want to over amp them. This becomes more true for Lithium batteries than it is for lead, but there have been some EVers that have gotten almost 10 years out of their golf cart type batteries by babying them.

7. Don't know if you want to get this elaborate, but you can also monitor the pack voltage with a simple voltage divider and allow for a soft low voltage limit. Its really bad for batteries to over discharge them. You could have the controller lower the current limit when pack voltage starts to get too low. This way you will feel like your running out of power before you actually run out and murder a battery.

Anyway, just food for thought. Maybe things to implement down the line. You set out to make a cheaper controller, but you could end up making a cheaper, better controller than Curtis, Kelly, Logisystems, etc.
  Reply With Quote
Old 03-26-2009, 07:27 PM   #675 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
I read that hilarious story from Lee before starting this controller! Isn't Lee awesome!

Yes, you got it Bill. It has hardware and software current limiting. The hardware current limiting disables the mosfet driver in like 2-3 microseconds or so, and then the software doesn't just turn the mosfets on at the end of the cycle (which is what Curtis did! BOZOS! hahaha!!! Stop that, Paul.).

If you check out Lee's explanation, with the higher frequency, the time was too short (because of the inductance in the motor) to allow the current to decay much at all. So, when the curtis turned the mosfets on right after a SINGLE CYCLE, the current hadn't really fallen, and then it would continue to rise, then FIRE FIRE FIRE! So, they slowed down the frequency to give the current a chance to fall, because they wanted to wait for a single cycle for some weird reason before turning them on again.

Maybe I'm missing something, but in my software, I just wait until I hear back from the A/D channel that reads current that the current has fallen below 500 amps. Then I wait another couple cycles, just for gravy, and then I re-enable the mosfet driver. You can barely feel when the hardware current limiting kicks in. It feels like a very very faint loss of power (from the average of the delays and the 500amps). It's hard to get to the current limit. You have to be at low RPM and on a hill, and that's with my crappy control software. I'm done with the PI loop, but I haven't tested it yet to find the optimum P and I. Then, according to Fran (on EVTech) it will be unlikely that I will ever run into the hardware current limiting again, because the software current limiting on a well tuned PI loop is very good.

Another thing to note is that Curtis (maybe still does???) had throttle proportional to PWM duty, and not current!!! So, it would have very high current at low throttle, which is why the curtises would jerk when starting out, and why they had trouble with current limiting at low RPM. I know my curtis does. And I know the home-made one takes off as gentle as a feather dropping on the ground. Man that was poetic.

The Zilla is an IGBT based controller, and not mosfet. I don't know what goes into current limiting in that case. So maybe he can't get around lowering the frequency. A couple days ago Otmar was talking about his throttle control on the EVTech list. He hated how curtis would jerk, and made his so that throttle is related to current (but not linearly), and not PWM DUTY.

Otmar has a variety of motors that he has tuned his PI loops to, if I'm not mistaken, so the hairball either is inputted the type of motor, or it knows the type of motor through some sort of algorithm for finding the correct P and I in that situation. The latter wouldn't be terribly hard. It would be a "getting to know you" time when you first hook up the controller to the car. After a single acceleration from a stop, you could figure out a decent P and I for current limiting.

As it stands right now, a less optimal, but still good solution for me is to find the perfect P and I for my smaller motor (with a slightly larger inductance than a big beast motor), and then cut the P and I in half (or even 1/3), which will make my current limiting less responsive (but still totally un-noticeable), but will make it suitable for a larger motor (like Ben's).
__________________
kits and boards

Last edited by MPaulHolmes; 03-26-2009 at 07:42 PM..
  Reply With Quote
Old 03-26-2009, 07:30 PM   #676 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
Thank you Roger!!

I'm going to carefully read your comments after I get back from Sylvan. OH Well! I might be a few minutes late. hehe

I read your comments, Roger. Excellent ideas, All! I would need to move up to the ATMega16, which is like $5, instead of $3. Oh my. It has 8 A/D channels. I really like the idea of limiting current based on issues with the battery, and limiting battery amps, tach, etc... Monitoring battery votage. Awesome. It's nice to have something open-ended. I don't think most of them would be too hard to do.

The manual pre-charge resistor is just something I rigged that was supposed to be temporary when I first converted the car. I never got around to changing it. I really ought to do that.
__________________
kits and boards

Last edited by MPaulHolmes; 03-26-2009 at 07:40 PM..
  Reply With Quote
Old 03-27-2009, 09:30 AM   #677 (permalink)
Master EcoModder
 
Join Date: Jun 2008
Location: London, Ontario
Posts: 1,096

2k2Prot5 - '02 Mazda Protege5
90 day: 33.82 mpg (US)
Thanks: 0
Thanked 12 Times in 9 Posts
Paul, I've noticed two things lately - you are pulling people out of the EV woodwork into this forum and you're giving excellent answers to technical details!

When I saw someone mention the reason for the 15/1.5khz switch i was gitty that I could respond, but you beat me to it. The answer is - THIS CONTROLLER IS BETTER!!!! No silly 500 amps at 15% throttle! That's just silly! We do 15% of 500 amps at 15% throttle! ALWAYS! Here's the sweet part... if a duty of ONE on the PWM would generate an overcurrent, then this controller will actually pulse from 0 to 1 to 0 to 1 watching the current and maintaining it at a very low value. Silly "professionals" they need to learn how its done by the EcoModder hacks! Open Source FTW!
  Reply With Quote
Old 03-27-2009, 09:34 AM   #678 (permalink)
Master EcoModder
 
Join Date: Jun 2008
Location: London, Ontario
Posts: 1,096

2k2Prot5 - '02 Mazda Protege5
90 day: 33.82 mpg (US)
Thanks: 0
Thanked 12 Times in 9 Posts
So now we need to talk out auto PI tuning? I'll look it up and see if i can get the gist of it. I think simply going to a state-space control design may do the trick, but i honestly believe that your puny A8 isn't going to handle state space control.

Paul, i want you to do a test... I do this sort of thing all the time with timing-critical applications (such as motor control!). Pick an un-used IO pin on your chip. Set it to "output" in your chip init. At the start of your control algo, set it to 1 and at the end of your control algo, set it to 0. Then scope the pin to see exactly how long your controller is spending in the control and see exactly how frequently it is running. The duty cycle (on time %) of this control loop is critical in determining how much more you can do in that loop. This should be a quicky test for you.
  Reply With Quote
Old 03-27-2009, 10:34 AM   #679 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
Hey Matt! The software comes with a program simulator, with a cycle counter and total time used at whatever MHz you want to run things at. The datasheet says the system clock is pretty constant (like a few % plus or minus) so I ran some simulated time tests, and then ran it in real life, noting the times. This was a few weeks ago. They were very very similar. The simulator was very good about the times it gave.

So... I was thinking what you were thinking about how much time the control loop was eating up, given that a new interrupt was going to interrupt itself! (do they do that? hehe) I'm back! I just simulated it. According to the simulator, it was using about 15.5% of the time until the next interrupt under the worst case, where it ran as much code as possible. Code that is usually conditional and wouldn't all happen at the same time, but I made it all happen to make it take as long as possible.

I would expect real world results to fall in the range 15% to 16% based on previous tests.
__________________
kits and boards
  Reply With Quote
Old 03-27-2009, 10:42 AM   #680 (permalink)
EV Converter
 
Join Date: Mar 2009
Location: Saugerties, NY
Posts: 51
Thanks: 0
Thanked 0 Times in 0 Posts
I don't want to take this thread on a tangent, but I figured I would mention this. My business owns on of theses

PlasmaCAM Cutting Systems

Its a CNC plasma cutter, similar to a water jet, but it uses plasma instead of water. I was thinking it might help this open source controller effort in two ways.

1. It may be used to cut the copper bus bars. To be honest I have never tried to cut copper with it, but it does a great job on steel and aluminum. It could potentially cut a whole bunch of bus bars out in one shot out of a sheet of copper. The edges might have to be sanded a bit to make them nice an smooth, but it could save $. If you buy sheets of anything it is less than buying small pieces of bar stock.

2. The manufacturer has a optional tool holder that can be used to hold other tools like a drill, rotary saw, or router. This machine has an XY precision of 0.0005" and a X precision of 0.005". With an appropriate cutting tool attached it could also mill the boards. I don't know if that would be cheaper than buying them pre-etched, but its a consideration.

Also, this machine is great at making things like adapter plates and flanges. Any two dimensional shape that you can draw in CAD can be done in minutes. Its one of the most useful tools in our shop and sure beats sending things out to get cut.

  Reply With Quote
Reply  Post New Thread


Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control MPaulHolmes Fossil Fuel Free 3477 05-24-2021 04:28 PM
Paul & Sabrina's Cheap EV Conversion MPaulHolmes Fossil Fuel Free 542 11-12-2016 10:09 PM
Three Dirt Cheap DIY Electric Cars - Part 5 SVOboy EcoModder Blog Discussion 0 12-12-2008 05:10 PM



Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com