Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!csd4.csd.uwm.edu!markh From: markh@csd4.csd.uwm.edu (Mark William Hopkins) Newsgroups: comp.robotics Subject: Re: stepper motor sychronization: need help Keywords: stepper motor sychronziation Message-ID: <11900@uwm.edu> Date: 7 May 91 16:36:28 GMT References: <2350@wet.UUCP> Sender: news@uwm.edu Organization: University of Wisconsin - Milwaukee Lines: 44 In article <2350@wet.UUCP> smiller@wet.UUCP (Gregory Shane Miller) writes: >What would the algorithm look like during acceleration? > >If there were no acceleration, I could solve the problem; but the >fact that my application requires acceleration has confused me >greatly. If you're controlling the stepper motor by sending out (say 50 microsecond) pulses for each step then you've got to come to terms with the fact that the speed of the stepper motor at any time will be *inversely* proportional to the delay between pulses, and the length of time spent at that speed is then proportional to that delay multiplied by the number of pulses sent out. The best way to accomplish acceleration (if the controller can't do division quickly) is to use a look-up table for converting desired speeds into desired pulse delays, and to "accelerate" the motor by driving it incrementally at higher and higher speeds. I set up such a lookup table for an application that listed delays for multiples of 25 RPM, which comes out to 250/3 pulses per second at 200 encoder pulses per rotation, and listed values for speeds 25 RPM to 2000 RPM. The natural time unit in this application was 3/250 second (the inverse of 25 RPM). So if you wanted to drive the motor at N multiples of 25 RPM for T seconds, you'd send out 250/3 x N x T pulses. The machine's instruction cycle rate was 921600 Hz, so the delay for a 25 RPM pulse was 921600*3/250 = 11059.2 cycles. The delay for N multiples of 25 RPM was 11059.2/N. These were the numbers stored in the table. So accelerating the motor simply came down to driving it at 25 RPM for a small fraction of a second, at 50 RPM for the same duration, 75 RPM for the same duration, and so on up to the desired speed. If you try to express constant acceleration as a function of pulse delay versus number of pulses sent out, you come up with something involving square roots and such. You could set up a lookup table for this function too and use that to drive the motor at constant acceleration. THe way to figure out this function is to express the number of steps as a function of time (assuming constant acceleration), invert this function to get the time versus the number of steps and then take differences the time values at succeeding integer values of steps to get the corresponding delays.