PicOx - Open Source Motor Controller
For Light Electric Vehicle PMDC Motors -
Part 2 ...
Feb 2008
Disclaimer
- This project is in a preliminary state of development, every effort is being
put forth to share it's progress, and note issues as they arise... Though
theworkshop.ca and parties noted in the development of the PicOx Open Source
Controller are held blameless and without liability with regard to how this
information is used.
With
that said, I want to add to the previous section's
progress by building a simple but robust driver stage.
The
symbols to the right are for the IRFB4110 MosFets that were part of the BFx
Add-on and will move to the PicOx in the same proven configuration.
As
this is Supposed to be an "Open Source" project, really the only constraint on the design
is that you stick with N-Channel Fet's and that you compare the parts that you
have handy with the IRFB4110 and what you need the circuit to do.
The
Parameters that should warrant consideration (but not limited to...) are Rds,
Vdss and Id... Most Data sheets have those parameters at the very top of the
page in bold letters...
For
comparison sake consider;
MosFet
|
Rds
|
Vdss
|
Id
|
IRFB4110
|
4.5 mOhms
|
100 V
|
180 A
|
IRF530
|
44 mOhms
|
100 V
|
33 A
|
Both
are rated for the same voltage, but the 4110 has 1/10th the Rds AND can handle
over 5 times the current. The cost is reflected in their respective
capabilities.
What
isn't quite so obvious is that neither rating should be taken at face value, in
that the specs typically are for a component operating at an internal temp of
25C, this is an ideal situation that is less than likely to match reality.
With
that in mind, my personal standard of controller rating will be to heavily err
on the side of caution and conservatively assign 1 IRFB4110 per each 25Amps of
continuous load current being sourced to the motor.
Since
we're still using only a single 12V battery X 25Amps Max Continuous Load =
300Watt continuous power.
Without
getting into heavy inductor theory, for now just take my word for the fact that
the Mosfets will be exposed to a reverse voltage (and current) that would
potentially damage them in short order if they didn't have a critical component
called a free-wheel diode.
Per
the schematic below, you'll notice that actually there are 4 diodes. These are
oriented to allow current to flow when the "Back-EMF" of the motor is
higher than the battery voltage. If the term "Back-EMF" sounds foreign
and/or is new, just by searching the term on the web you should get a good
understanding of it's properties and how to mitigate it's effects with a minimum
of effort.
The
spike of electricity is absorbed by a large capacitor (as the size of the
controller grows more capacitors will be needed.) It appears to be a general
practice to distribute several capacitors along the length of a controller
rather than installing just one Large Capacitor that would be the sum of the
numerous caps, this seems to be a requirement to balance the Back-EMF
suppression physically over the surface/length of circuit.
The
"Free-Wheel" diode pairs shown are a "Generic" 20200 fast
recovery diode, if you search on that description you'll find tens of models to
choose from, in my case I have been able to scavenge some from Computer
power-supplies, just be sure that they are matching part #'s but especially sure
that
their "Reverse recovery times' are also the same.
In
the case of this circuit I used 35nS rated diodes, though 40nS may work equally
well.
Since
these diodes are rated in a similar fashion to MosFet's at 20Amps each,
there would be 2 for 25Amps, 3 for 50 Amps and 6 for a 100 Amp controller.
The
"Back-EMF" clamping capabilities of the diode pairs is not a mirror of
the MosFet's rating and as such does not require a mirror of the Id
specification.
Right-Click
and select "Save-As" for a local copy of the schematic (it is saved at
200DPI and should print legibly).
Again
given the disclaimer above about the thermal rating of these parts please note
that they MUST HAVE a Heat Sink applied.
The
link below is to a very comprehensive overview of heat-sinks (if you're unsure
if their needed).
http://sound.westhost.com/heatsinks.htm
This
waveform is of the MosFet Drain lead and it displays a nice clean transition from "On" to "Off"...
The
vertical snap on & off of these parts are related to their ability to
tolerate being neither on nor off, and having to dissipate that energy as heat...
If
your Waveform is angled like a Saw-Tooth, or curved like a sine wave, than you
may want to find out why before going much further... or install bigger heat
sinks (that's a joke...)
The
motor being used as a load for the controller is a MY-68 JX Motor Co. model,
just a cheap scooter motor that I know is working properly.
It is
rated at 24V and 6 Amps.
Approx
100W (per the data label).
To
determine the current that the controller is sourcing a 10AMP Digital
Multi-Meter (DMM) is placed in series with the V+ line of the motor.
A
pair of pliers are used to lock the armature/rotor of the motor to exercise the
current sourcing capabilities of the controller.
In
this configuration the PicOx is able to source between 6 to 7 Amps to the motor
for as long as you're willing to hold the pliers in place to keep the motor from
turning.
After
approx 10 minutes the motor is getting warm, but nowhere near uncomfortable to
hold... I would think that your hands would cramp and have to quit long before
the controller or motor would suffer any prolonged damage...
This
is progress, at this point the PicOx is a close to being a real
controller.
The
last item to add to the circuit above is some form of current limiting that is programmable
on the controller via software that would allow the controller to operate within
a defined window of operation.
The
current limiting parts that have been spec'd and ordered for this project have not arrived yet...
So I decided to try an experiment to keep up some of the momentum achieved at
this point.
Bear
in mind that there are numerous emails between Eastern Ontario and L.A.
resolving naming conventions in the code, some basics about programming (that
I'm learning from Eric C. as we go along) on a daily basis and occasionally
hourly.
This
is an inductor scavenged from (again) a dead PC Power Supply, though you'll find
these donut shaped parts in just about any Switch Mode Power Supply (SMPS).
All I
want is the ferrite core that is called a "Torroid".
The
shape makes it a useful component for capturing magnet fields.
A
narrow slot is cut into the ferrite core with the band saw.
This
is not my favorite type of work, as you have to hold the core securely with your
fingers in close proximity of the blade...
With
a slow feed rate the saw glides through the core and leaves a very clean cut.
The
slot is just wide enough to allow a UGN3503 Hall effect sensor to sit in
the broken path of the magnet flux of the core.
Initially
I tried 5 (five) turns of AWG#20 wire around the core...
But
found that the resolution out of the sensor was coarser than 1.5 to 2 amps per
increment on yet another ADC port of the 08M micro controller.
Since
our test model here is only 6 to 7 Amps total scale more turns were added.
The
snippet of the schematic (as it existed at this point in time) shows the sensor,
the torroid and it's relative position between ground and the Source pin of the
MosFet.
NOTE:
this requires additional components DO-Not Build as illustrated, please read to
end to see what happens next.
The
UGN3503 is similarly cannibalized from the thumb-based throttle as I didn't care
for it's design.
Pictured
to the right is the 30-turn AWG#20 current sensor in-circuit.
Without
going into the numerous iterations of the code as it evolved to this point, to
the left is a sample of the "Terminal Data" that was being captured
between the 2 (two) Hall Sensors...
At 30
turns of wire like the throttle sensor some scaling maths had to be invoked to accommodate
a 120ma reading per increment of the ADC conversion of the Hall Sensor.
For
reference the Hall sensor sits at an 8-bit value of 127 at 0 (zero) current flow
and rises on positive flow and decreases below 127 with negative flow.
The
implications of this relate to the potential of logging and working with data relating
to "Regenerative Braking" as the PicOx matures to that point.
This
data sample illustrates the crude state of the current-limiting procedure
that is taking shape in the software.
The
DMM is reading a steady 4.5Amps with the throttle pinned at max and the rotor
locked.
With
the limited experience I have with this type of work, it seems that it ebbs and
flows between Hardware for a few hours (or days) and then software gets changed
like crazy over the static hardware model.
As I
have been working on closing the loop between the throttle and a current limiting
scheme, Eric C. has been working on a simple power regulation circuit that would
extend the PicOx beyond 24V, and protect the ucontroller circuitry.
After
considerable research he settled on an LM317 adjustable voltage-regulator that
can source up to 1.5Amps of current over a range of 1.2V to 37V output voltage
that is selected by a 2 resistor voltage divider per the data sheet.
After
working out the details and building a test circuit in L.A. I adopted it to this
project. I should note that the LM317 has one of the most counter intuitive
pinout schemes for a 3 lead device that I've ever seen...
Eric
did caution me that he cooked his first circuit due to improper wiring, though
that didn't stop me from likewise wiring the LM317 incorrectly as well. For
reference, as you power-up the circuit listed below, keep one hand on the power
lead, and the other on the LM317... If it begins to generate a measure of heat
that you can easily detect within seconds of the power being applied, there is a
good chance that you have it wired wrong.
The
Reason we need a primary Voltage regulator (LM317) and then a secondary Voltage
Regulator (LM7805 for the +5V supply), is that the PicAxe chip and it's
associate sensors work at +5V, and the Gate driver logic works at +12V to +18V
(I've opted for a conservative figure of +15V).
The
Battery Voltage will now move to 24V, then 36V and lastly 48V for this iteration
of the PicOx project. If we just used the generic LM78xx series of fixed voltage
regulators ie; LM7805 & LM7815 respectively the Vin parameter would become a
limiting factor at 36V, the LM317 removes that limitation.
Unfortunately
I broke one of the cardinal rules of design in that I opted to cut some corners
by trying to implement 3 (three) changes simultaneously without implementing
them individually and noting how they affected the circuit before moving on. Predictably
I was re-paid in kind by destroying a series of parts and losing 2 days in
trying to get the circuit back on track.
1)
introduction of the LM317 regulator, for the 24V supply
2)
replace the TC4468 with the appropriate TC4427 driver that finally arrived
3)
test a complete revision of code with the new hardware config.
To
the right is the unholy mess that is starting to evolve and is a good example of
what a breeding ground for circuit errors would look like.
In
the cycle of code updates and power-on sequences, at one point I foolishly
applied power to the circuit without physically having a firm hold on the motor.
It
powered-up at full speed (this is 24V now) and jumped off the table taking
the proto-brd and an entire tray of loose parts and jumper wires with it to the
floor.
It
never worked again in this configuration after that point...
In
the course of trouble shooting the problem(s), I found that the TC4427 was
running way too hot...
56.9C
at half throttle...
I
burnt up 2 of them in under an hour, and was beginning to question if the driver
was up to the task.
(to
be clear they were not at fault...)
To
the right is a very useful piece of diagnostic gear, a touchless thermometer.
I
picked-up this unit for under $15 Cdn @ Princess Auto a couple of years ago...
The
only criticism I have is that it chews through the CR2032 button batteries very
quickly so I opted to add a bulky but effective solution by adding a AAA battery
holder and using rechargeable cells.
The
waveforms below are of the MosFet's "Source" pin and illustrate an anomaly
that I never expected. The image to the left shows a negative going voltage
spike that is just under 15V minus (relative to ground) being generated by a
Back-EMF from the current sense coil, which is an inductor after-all.
The
image to the right illustrates that the negative going spike is easily
suppressed by adding a common 1N4001 or 4002 diode oriented per the schematic
below.
The
destructive fall-out from the exercise above entails 1 picAxe processor that
still runs it's program but can't be re-programmed any more, 2 (two) TC4427's
that were being destroyed by the 2 (two) IRF4110's that also were destroyed by
the brief but lethal spikes that were hammering the source pin at 15khz.
I
think that one of the reasons that it was so hard to track down this problem was
that so much had changed at once on the project at the same time I didn't know
if it was a code issue, a hardware issue or damage to the circuit as a result of
the fall off the table.
And
to make matters worse, given the specs on the IRFB4110 MosFet's it was hard to
reconcile the fact that it was being destroyed at such comparatively low
voltages and currents given that I'd taken such care to impose conservative
operating parameters on the output.
It
would seem that at 12V there wasn't quite enough Back-EMF on the Source pin to
adversely effect the circuits performance but at 24V the 4110 is taken down with
less than 15sec of locked rotor testing at full throttle.
The
images above are the waveforms of the UGN3503 current sensor as it sends it's
output to the uController's ADC input. The voltage scale is set to 0.2V/div so
we're talking about very low output values.
The
one to the left is of the motor running freely at half throttle, while the image
to the right is of the motor at full throttle with a locked rotor (the current
limiting is set and working properly at approx 6Amps via the software in the
PicAxe).
The
pronounced spikes at the leading edge of the waveforms are a point of concern as
the current sensing circuit is producing values via the ADC that are not
necessarily linear. As the current increases to the motor the scaled current
reading being streamed to the PC via the RS232 interface are in step up to about
7 or 8 Amps after which they start to drift higher and higher.
If
the current limiting routine is disabled in the software, the motor can draw
approx 16Amps per the DMM while the PC terminal program is logging a draw of
over 21Amps.
The
quest for insight into a possible solution to this and some other issues has
drawn feedback from the PicAxe Forum website mentioned on the previous page, so
now the PicOx is starting to truly be an international endeavor spanning L.A. to
Renfrew and parts of the U.K.
One
possible solution per the U.K. contingent is to add an RC (resistor-Capacitor)
circuit called an integrator that would smooth the spikes. But as the current
sense circuit shown above is a temporary feature until the right parts arrive
(Allegro ACS75x series) I don't want to get too hung-up in resolving the
non-linearity of readings on a device that hopefully will be ditched in a few
days...
This
is the revised proto-brd layout that more clearly illustrates the various
sections of the circuit per the schematic listed below.
The
Voltage regulation circuit is in the upper left corner supplying +15V and +5V
reliably, the logic and gate drive circuit is to the lower left section and the
drive electronics and current sensing is on the lower right section.
The
code listed below has been tested fairly extensively as described above and is
the state that it is in as of this posting. In the course of it's evolution Eric
and I came to a consensus on points such as variable definition starting with
byte sized values allocated from B0 incrementally first and word sized values
starting at W6 and decrementing in their allocation to avoid over-lap of
register resources.
Similarly
the naming of constants and variables has been tuned over time to reduce the
amount of commenting required on the edges of the code to make it as
comprehensible as possible.
The
basic structure of the program flow was largely influenced by the PicAxe Forums
input from the U.K. where the aim has been to establish a tight fast loop that
is constantly trying to massage the PWMMark variable efficiently.
Similarly
the SerTx command has been removed from the main flow with a rough averaging
function on the individual current samples to smooth the readings such that they
are more consistent relative to the DMM readings. This routine is still in limbo
as it will likely be rethought and revised to accommodate the output of the
Allegro ACS75x series of current sensors that will replace the
"Home-Brew" sensor that was just a stop-gap solution to make some
headway towards larger voltages.
Note
the remaining comments have been stripped from the code to make the text
formatting more legible.
;PicOx Ver 1.01 Feb 22/08
SYMBOL CurrentAmps = b0
SYMBOL CurAvg = b1
SYMBOL LCDAvg = b2
SYMBOL ThrottleADC = b4
SYMBOL CurrentADC=w5
SYMBOL PWMMark=w4
SYMBOL ThrottleADCMax = 215
SYMBOL ThrottleADCMin = 50
SYMBOL ZeroCurrentMark = 133
SYMBOL CurLim = 6
main:
for LCDAvg = 0 to 10
readadc 1, ThrottleADC
readadc 4, CurrentADC
if CurrentADC > ZeroCurrentMark then
CurrentAMPS = Currentadc - ZeroCurrentMark / 2
endif
PWMMark = ThrottleADC MAX ThrottleADCMax
PWMMark = PWMMark MIN ThrottleADCMin
PWMMark = PWMMark - 50 * 16 / 10
if CurrentAmps > CurLim then
PWMMark = PWMMark / 4
endif
pwmout 2,66,PWMMark
CurAvg = CurAvg + CurrentAMPS
Next LCDAvg
gosub LCD
goto main
LCD:
CurAvg = CurAvg / 10
sertxd ("ThrottleADC " , #b4, "
| CurrentAvg ", #curAvg, cr, lf)
return
end
Just
for clarification, the "LCD" routine is named to accommodate an LCD
display that will be added shortly, but the output of the SerTx command is still
to the laptop that is used as the program loader.
And
lastly, the position of the PWMOut command relative to the body of the loop can
have a significant effect on the controller's ability to limit the current to
the motor effectively. This not to say "Don't Move the code about" but
rather, that if things stop working as expected that would be a good place to
start to trouble shoot.
The
diagram below like the code above is the current state of the PicOx as of this
posting, it has been checked and double checked against the Proto-brd image
above a number of times... If you find a glaring error or an element of the
schematic that is inconsistent with the results posted here Please Don't
hesitate to bring it to my attention... I would be most grateful.
Right-Click
and select "Save-As" for a local copy of the schematic (it is saved at
200DPI and should print legibly).
So in
closing I feel that the progress has been good to this point as the above is a
digitized Controller that is capable of sourcing up to 16Amps @ 24V and has a
proven current limiting feature that reliably maintains a 6Amp limit to the
motor under test.
My
most sincere thanks to Eric C. in L.A. California for his patience and
thoughtful replies with regard to questions on software and doing the leg work
for the LM317 Regulator circuit, and to the respondents on the PicAxe Forum in
the UK that took the time to point us in the right direction with regard to
current averaging and the timing of instruction cycles through the code.
The
next installment (hopefully the last before migrating to an 18X class PicAxe
processor) will include the replacement of the Home-Brew Current Sense circuit,
revision of code to accommodate it, a PCB layout and etching for a sturdier
platform (there have already been melted wires) with the addition of a second
IRFB4110, a third 20200 free-wheel diode pair and a second capacitor.
Target
voltages are 36V and then 48V with a larger motor (actually several different
motors to start to amass a good base of operations at currents approaching the
50Amp design criteria).