Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

No problem. I have the flu right now, so it might take a day to get to it.

[jedsmd]

Originally Posted by Astro

Well they accepted my USD$50 (excluding postage) offer. Now i just have to wait for it to arrive.

I have ordered one also. Good news for Paul as my code we now be like everyone elses

[MPaulHolmes]

I'll get started on the extensive code changes for the hall effect sensor (like 2 lines haha).

For the hall effect throttle modification:
(The short black line that is just on the board is shorting that resistor)

[jhornbr225]

Hello All,

Longtime lurker, recently registered. I read this entire thread over the last week or so and can only say WOW.

Paul, you have made the difficult possible. You went from what seemed a complete electronic newbie, to a person who knows what they are talking about. (Because you've tried it!). Without your dedication, this open source project would have floundered, as many others have. Even though there were a few forks in eyes, and punches in the head, and naked Kim Jong. Your dedication and willingness to help others and the people who have ordered from you is incredible. It almost seems as if you have a unique connection to each controller out there, sending parts when needed, rebuilding others when needed, and continuous tech support, even to the point that if you don't know something, you find out the info, and pass it on.

The dedication of your family, with the long hours you manage to fit in, even with taking care of two children, job changes, moving out of the basement...etc., is amazing.

Also the base of knowledge from all the others who contribute to this project is amazing. The depth of knowledge in both electronics, programming, machining, etc. to make this project possible, has made this into a nicely polished project that is graspable for even a newbie.

I am a Controls Engineer, specializing in industrial controls and AC and DC drives. What you are building here rivals any commercial motor drive I have seen.

I do have one concern. With using the throttle to directly control the PWM into the power devices, you have basically set up a torque drive. In the applications I have seen, those that use torque drives are mostly winders, and Helpers.

Winders wind up some sort of material and the speed of the motor has to slow down, (or speed up) based on the diameter of whatever the material on the roll is. They are usually given a speed reference that exceeds the line speed of the material and then torque is limited based on whatever tension you want the material to wind up at. (Or Brake at)

Helpers usually are used for torque sharing. Same principles as winders. The helper section is given a speed reference based on the speed of the master section, then the helper itself adds to the speed reference. The current limit is then adjusted on the slave (Helper) to change how much "Help" the master section gets.

In both these applications, it is VERY EASY to overspeed the motor. If a coupling breaks, or the material that is being would up breaks, the motor basically, "Runs Away". Kind of like the apple tree incident.

Modern DC and AC drives usually incorporate multiple sections, each closed loop to get the desired motor speed.

1. Speed Loop. Receives Speed reference from operator to indicate desired speed. Also receives feedback from either a mechanical/optical device, or from Back EMF to indicate actual motor speed. The Mechanical/Optical device is preferred due to the fact the actual speed is indicated. Using BEMF does not account for the motors IR drop as load increases. If there is a difference between the reference and the feedback, an error is generated, and can be tuned with a PID Loop. The ouptut of this speed loop is known as speed error or current (Torque) reference, and is fed into the current loop.

2. Current Loop. Receives torque reference from speed loop, and current feedback. The difference between the current reference and the feedback drives the outputs sections to pulse motor whether it be IGBT's and a buss or capacitors in an AC drive, or an SCR to turn on and allow part of either a single phase or 3 phase waveform through (rectified so as to all be the same polarity) and fed to the motor.

What I'm getting at here, is that if you could incorporate a "Speed Loop" into your controller you would see many advantages.

You would probably not see the PWM runaway that you see when the pedal is requesting current and the contactor is not closed, so the PWM ramps to 100% quickly.

The speed of the motor would follow the pedal, regardless of the load, hills etc.

Ramp rates are based on speed RPM/unit time, not change of amps/time.

Cruise control could be activated.

What you have built here is an awesome torque controller. I feel that a little effort into adding a speed loop may pay off greatly in terms of driver comfort and ease of use.


Just my $0.02.

Either way, keep up the awesome work!

jhornbr225

[MPaulHolmes]

haha I forgot about the apple tree! Thank you so much for all the kind words. My Ebola-like symptoms felt slightly less ebola-like by reading it.

Is there an easy way to get an rpm signal to the controller? I know Damien did it, but I'm not sure how, or how easy it would be to repeat. Is there some sort of "out of the box" thing that you just add to a motor (or something that's spinning at the speed of the motor)? It sounds like it would really be worthwhile getting that addition. And in principle, it doesn't sound too hard. Just some sort of pulses that you count on the port, and make decisions based on how many per unit time. It would be nice not to have a panic attack every time someone tells me they have a contactor on their throttle. haha. I really appreciate a person of your expertise taking the time to write on here about this.

[Astro]

Wouldn't the encoder on the motor be enough to get this information?

[MPaulHolmes]

Oh that would be more than enough. But I was just planning on using it for the AC controller. They aren't that cheap, and you wouldn't need the 512 ticks per revolution. I think even 1 pulse per revolution would be fine for all the benefits in the DC case. I wonder if the tachometer info could somehow just be tapped into by the controller. I have never taken a tach apart, and don't really know how they work.

[Astro]

Some gearboxes may already have electronic sensors to drive the factory tacho but some may only have a cable drive to the tacho or no tacho at all.
Not sure where i read it but someone drove the tacho in their ev using a hall effect sensor mounted in the hole where the starter motor used to connect to the flywheel. There was some protrusions on the flywheel that allowed them to get a number of pulses per revolution of the flywheel.
Of course that would only work for those people that kept the flywheel and clutch. And as long as there was some anomaly on the flywheel that could trigger the hall sensor.
If required a small magnet could be bolted to the flywheel but keeping the flywheel balanced may be a challenge.

[jhornbr225]

A tachometer is just a little DC motor. Usually permanent magent, no field necessary. Ouput is relatively linear based on speed.

Cons: Can be electrically noisy, expensive.

In the old days they were used quite a bit. Modern systems use encoders. They are cheap and easy. In this application you don't need 1024 Pulses Per Rev (PPR) or 2500 is also common. Those are also Quadrature encoders. Essentially giving 4x the PPR. You're right, you don't need that kind of precision. We use those for high accuracy feed to position lines. Also for motor speed to gearbox speed comparisons, where on a hoist we want to be sure the gear train is intact.

I remember in one point of this thread someone talking about a Black and White tape and an optical sensor. Or a disc with notches that breaks a beam in an opto sensor. At low RPM however 1 PPR may not be enough. There is a tradeoff. You want a good pulse train at low speeds, but you don't want the Frequency of the pulses at high speed to exceed the working frequency range of whatever device you are counting pulses with. For example, a 5000 PPR Encoder traveling 10,000 RPM generates 833KHz. ((5000 x 10,000)/60) This may exceed the working range of the input device. Now I doubt your motors are traveling 10,000PRM, and that anyone will get a 5000PPR encoder. Even as low as 10PPR would be good. That way it's not too long between pulses at low speeds for a controller to be able to calculate RPM.

[flores]

Originally Posted by MPaulHolmes

No problem. I have the flu right now, so it might take a day to get to it.

Wouldn't it be a good idea to set up a github for the source of the firmware? then I could try to fix it myself and git push it if it works.