Paul & Sabrina's cheap DIY 144v motor controller

[dcb]

Originally Posted by JayC

...Another benefit would be that you could port it to use Arduino boards versus rolling your own.

Take it from experience, putting a serious project in reach of a bunch of artsy fartsy types is of dubious benefit

"I chose these resistors because their colors complimented the board better"

[JayC]

LOL. I just meant he could take advantage of a pre-built module that cough plug into the rest of the controller.

[wolfraven]

For some reason, after the ... way some people choose resistors was pointed out...I couldn't help imagining someone somehow routing the power section into the inputs of the arduino and starting it...

[MPaulHolmes]

Hello! I have the PI loop working again, with Kp = 1/8, Ki = 1/8. It's as smooth as I've ever seen it, but too sluggish. I bet it would be a hair snappier on a larger motor. I wish I had both! Oh well... Here's a question:

If an interrupt handler takes too long, overlapping when the next interrupt would have happened, does the next interrupt get skipped, or does it get executed as soon as it's able to be? The simulator seems to indicate that the next interrupt gets run as soon as it can. That could have been part of the problem yesterday with the slow 32 multiplying.

[dcb]

Originally Posted by MPaulHolmes

If an interrupt handler takes too long, overlapping when the next interrupt would have happened, does the next interrupt get skipped, or does it get executed as soon as it's able to be?

my understanding of the 168 is that a flag gets set for each interrupt type so that interrupt will get triggered again once the interrupt routine returns. The "buffered" interrupt will happen at a slightly later time than expected of course, and if you get behind more than one then interrupts get missed completely.

[MPaulHolmes]

Kp = 1/4 and Ki = 1/8 give VERY VERY VERY good results on flat ground and on hills for driving with a 6.7" diameter 60 pound motor. It's the best I've had. Yesterday, I was using Ki = 100 or 500 or something ridiculous like that. Needless to say, that caused problems. I was using huge Ki values because a website suggested large Ki values, but that was for a very different situation where they were trying to control the RPM on a tiny motor.

It's optimized for speed, so a little hard to understand.
Here's the code piece (in case like a moron I erase it on accident again):
//////////////////////////////////////////////////////////////////////////////////
errorNew = _throttlePos - _current;
pwmDutyFine += (((int32_t)(errorNew - errorOld)) << 13) + (int32_t)(errorOld << 2);
errorOld = errorNew;
pwmDuty = (int16_t)(pwmDutyFine >> 15);
///////////////////////////////////////////////////////////////////////////////////
The whole thing takes 15 uS, whereas a single floating point multiply takes about 100 microseconds.

EDIT: The multiply isn't as slow as I thought. Oh dang it! I might be able to improve that time a bit. I'm going to try something.

[esoneson]

Interrupt Service Routines

If the amount of time to perform the critical task takes longer than the interim of the interrupt, then your design is flawed. Take note of the word critical. Paul, I think you have solved your problem by shortening the critical code to fit within the interim. If not, then you would have to break up your interrupt routine into states and run sub-portions of the critical code in some sort of state machine. But then again, if what you are doing HAS to be performed within a single interrupt interim, you would be continually getting behind so as to not meet the designed criteria, which is, to perform x number of interrupt routines each second of real time. If the interrupt was initiated on a non-regular basis, then saving critical information and queuing up tasks to be performed at a later non-critical time is proper. But this is not your case at all. Glad to see you got the instructions minimized.

Carry on my friend. You are doing fine.

Eric

[charlie_fd]

Originally Posted by MPaulHolmes

...
(in case like a moron I erase it on accident again)
...

That's one of the reasons source control was invented: you would not be able to erase the history of what you wrote even if you want to

Any news from down-under? Waiting for my new toy I've been busy building myself a AVR programmer/debugging board and I've been scavenging an old copy-machine for some large steppers so I will be able to cnc-mill my PCB's once we decide to update design.

Back home, the motor got mounted to the gearbox ...

P.S. Here's an example on how to quickly check all changes in a file fro an arbitrary revision to a more recent one (r2 to r6 here): http://svn.fastdigitech.ro/trac/open...constant.h%402

[MPaulHolmes]

It's going to take 8 days from a few days ago for the control section to be finished by Futurlec, then shipped from Thailand!!! to the U.S.. Testing and assembly would then begin in the fancy laboratory when the engineer back east has time available, then shipped to me. I'm finished with etching your power section, but not done with drilling the copper heatspreader. I haven't ordered the capacitors/diodes/mosfets/etc for the power section yet. I just wanted to order the parts for all 3 at the same time, to get the bulk discount.

I think I finally have the throttle the best I've ever had it. The inside of the ISR takes slightly too long once every 16 times. It then catches up after the next ISR call. I have reasons for doing everything inside the ISR. I'm not saying it's the best way to go, but it works the best of all the things I've tried.

Copy machines have stepper motors??!! I need to try that too! I've got to get me a CNC! Speaking of CNC, there are 2 volunteers that can help with etching the other 2 controllers, using super fancy CNC! There's Adam (hehe I remembered) and JayC. I want to see how a CNC does it too, so I think if they don't mind, I could ship each of them a PCB to try it out. No big deal! If something goes terribly wrong, I'll just ship them another one! We'll need to figure out gCode stuff, but it's all good!

[adamj12b]

Hey Paul,

I think that the notes that you use to mill a section now is almost enough to generate Gcode form. It is really a very simple process, so the code wont be very complicated. If you can upload that, I will get to work on the code and test it out on some veneer material to simulate a run.

-Adam