Paul & Sabrina's cheap DIY 144v motor controller

[NiHaoMike]

Originally Posted by jackbauer

Have to agree that usb is rubbish. Was at an arizona microchip training course a few years ago when they were first bringing out pics with onboard usb. Took the guys a day to get it to send simple ascii characters. Best bet is to get a pci rs232 card if you have a desktop or pcmcia card for a laptop. I have both and work fine with my own projects and rtd explorer. Trouble with most usb to rs232 adaptors is that they are implemented in software.

All of my USB to RS-232 adapters work great, but they're all based on the PL2303 or FTDI chips.

[bones007]

Originally Posted by MPaulHolmes

I tested out the newest version of the software today. version 1.7. Over-rev protection works perfectly while in neutral.

Originally Posted by adamj12b

So I have good news!! As of today the new firmware, v1.8, can control pre-charge time!!

This is great news! Looks like some new features are making it into the controller.

How about the "I forgot to unhook the extension cord from the car before driving away" lockout? I don't have an EV now, but I am guessing that I would probably forget to unplug before driving away at least once a month.

To make this feature available would not be that difficult. As I see it, if the car is charged by opening the "fuel filler" door on the side of the vehicle then all we need is a switch installed to detect the state of the door (open/closed) and hook that up to a digital input on the micro with a pull-up resistor. Then in the micro controller code, just check the value on that digital input to make sure the door is closed prior to engaging the contactor.

Is this feature planned? Any opinions?

[Oval_Overload]

How about the "I forgot to unhook the extension cord from the car before driving away" lockout?

Zap! implements this with a relay on the throttle. 110 VAC disconnects the throttle, and high-pedal lockout prevents any shenanigans if you were to unplug while in "drive" mode.

That is an option, but then again a relay is a mechanical part that can fail. Bones' method involves fewer mechanical parts and less 110VAC wiring.

~Jimbo

[bones007]

Originally Posted by MPaulHolmes

I tested out the newest version of the software today. version 1.7. Over-rev protection works perfectly while in neutral.

Paul, from what I remember the way you get around the over-rev protection without a speed sensor is by comparing the motor current to the PWM duty cycle. Am I right in thinking that the value of the constant you come up with for this comparison depends on the torque constant of your motor, the battery voltage, load on the motor and perhaps other considerations right?

Do you think there is an easy way to come up with different values for a wide variety of hardware configurations?

Or is it really not that crucial. I mean will one particular constant value limit RPMs to X plus/minus say 10% or 20% or so. Regardless of the hardware configuration. After all, having a precise limit to the RPMs to is not critical...as long as the limit is low enough to avoid having the motor blow apart, and high enough to be useful for the driver.

[MPaulHolmes]

Hey Bones!

c*RPM*current = pwm_duty

Let's say the current is large and the rpm is very very small. Then the voltage across the motor is going to be very small (almost a short circuit)

Now let's say the motor is turning almost infinitely fast. Then just when the current is about to get going in the coils one way, the brushes make it turn around and flow the other way, so the net result is that very little is flowing.

That's just a plausibility argument as to why current and rpm are inversely proportional to each other, and why RPM and pwm_duty are directly proportional to each other. I actually don't know why it's true in the case of series DC motors. But let's pretend that it is!

Then to limit the RPM, you just limit pwm_duty/current in software. hurray!

[bones007]

Originally Posted by MPaulHolmes

c*RPM*current = pwm_duty

Ok, so that's the general idea. Do you know how much will the value 'c' in your equation above must change depending on which motor you have (emf constant), battery voltage, vehicle load or other hardware characteristics?

I mean will this value need to be tuned for each case or is one value fine for everyone.

[MPaulHolmes]

If you double the pack voltage, you need to double that constant. Other than voltage varying, I don't know what other variations there are. That will be interesting to find out.

[bones007]

Originally Posted by MPaulHolmes

If you double the pack voltage, you need to double that constant.

I kinda thought so. If the pack voltage monitoring is in place then potentially the correct 'c' value could be chosen automatically. Eliminating the need to tune this parameter...assuming other factors don't affect the RPM limit too much.

[MPaulHolmes]

The form I listed was worthless though. In the software, we want to control RPM, so it would be better to have it written as

RPM = c*pwm_duty/current. In the code that's how it is, so if you double the voltage you need to cut that c in half! hehe.

[mrbigh]

Originally Posted by Oval_Overload

Zap! implements this with a relay on the throttle. 110 VAC disconnects the throttle, and high-pedal lockout prevents any shenanigans if you were to unplug while in "drive" mode.

That is an option, but then again a relay is a mechanical part that can fail. Bones' method involves fewer mechanical parts and less 110VAC wiring.
~Jimbo

My approach to the charging reminder issue is very simple, economic, from renewable sources, replaceable and STUPID proof, I know that because of experience thou.