<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:12px"><div id="yui_3_16_0_1_1422073672965_12377">Sounds like you are making progress.<br class="" style=""><br class="" style="">
What is the frequency of the PWM timebase, maybe a multiple of 2MHz ?<br class="" style=""><br class="" style="">
I was playing with a PID controller with grunty-motor a while and resolved the torque-peaks issue by implementing a simple slew-rate limiter. An interrupt timer compared set point with current velocity, if the difference was greater than the allowable rate-of-change then maximum rate-of-change was added. Eventually the set point is reached and everyone is happy. Motor was a 2kg brushed unit, with a 500g load on the shaft. Feedback was via an optical shaft encoder and FPGA. PSU was 24V/30A with a 28V clamp. Managed to get the unit run from+3600RPM to -3600RPM in 85ms with 30A supply peaks. Had to clamp the motor to the bench (17mm ply) which was flexing every time the motor changed direction. H bridge was a 30A three phase / 600V IGBT , but only using 2 phases. Most impressed that none of the fixture got hot, let alone fried.<br class="" style=""><br class="" style="">
<a href="http://idesignz.org/mc/motorsetup.jpg" eudora="autourl" class="" style="" id="yui_3_16_0_1_1422073672965_12500">http://idesignz.org/mc/motorsetup.jpg<br class="" style="">
</a><a href="http://idesignz.org/mc/motorsetup.pdf" eudora="autourl" class="" style="" id="yui_3_16_0_1_1422073672965_12501">http://idesignz.org/mc/motorsetup.pdf<br class="" style=""><br class="" style="">
</a>Also, it is possible to feed the A side of the H bridge with PWM, and the B side with /PWM (with an invertor between A and B inputs). At 50:50 PWM, the inductive load will not see any current flow (since both sides have an average of VCC/2). Change the PWM to 40:60, and average one side rises, the other side falls and there is movement etc.<br class="" style=""><br class="" style="">
-the-other-mark<br class="" style=""><br class="" style="">
<br class="" style="">
At 03:54 p.m. 24/01/2015, you wrote:<br class="" style="">
</div><blockquote type="cite" class="" cite="" style="" id="yui_3_16_0_1_1422073672965_12502">Thought I'd report on a couple of problems that have arisen since I<br class="" style="">
demo'ed the motor controller for my walnut washer.<br class="" style=""><br class="" style="">
1. Looking at the waveform with a 'scope showed a one clock 0.5uS glitch<br class="" style="">
when zero was set in the PWM compare register in Fast PWN mode. Its a<br class="" style="">
silicon bug!! Rather than add an errata for the AVR Mega, Atmel have<br class="" style="">
incorporated the behaviour in the main body of the specification that<br class="" style="">
indicates that for a no pulse output the register should be set to the<br class="" style="">
'TOP' value. The problem with that is that the signal is now up-side-down.<br class="" style="">
Good job I'm a hacker when it comes to coding :)<br class="" style="">
I noticed that the 328 as used in the Arduino Uno and even the ATMega8 and<br class="" style="">
ATMega169 (Butterfly board) have the same problem. One to watch out for<br class="" style="">
especially if using a slower clock to the PWM timer.<br class="" style=""><br class="" style="">
2. As Mark questioned, what do the H-bridges do when there is no input.<br class="" style="">
That is actually 2 conditions - setting a PWN ratio of all off or all on<br class="" style="">
and then flicking to the opposite state (eg. hitting the stop button)<br class="" style="">
keeps the output MOSFETs engaged and the commutating diodes clamping any<br class="" style="">
back emf off the motor at it screeches to a halt.<br class="" style="">
The second condition is nothing like as severe. In the case of a switch<br class="" style="">
off, the enable lines of the H-bridge are de-activated, so the output<br class="" style="">
stages float, so the motor just coasts to a halt in a 1/2 to 1 second.<br class="" style="">
Another coding change for the former condition now takes a running average<br class="" style="">
of the value required so that step changes are 'smoothed'. The motors no<br class="" style="">
longer fall over when started or stopped :)<br class="" style="">
-- <br class="" style="">
Robin Gilks<br class="" style="">
Internet: robin@gilks.org <a href="http://www.gilks.org/" eudora="autourl" class="" style="">http://www.gilks.org</a><br class="" style="">
Tel: (+64) (3) 347 4370</blockquote><div id="yui_3_16_0_1_1422073672965_12377" class="" style=""><br class="" style=""></div></div></body></html>