home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / robotics / 1746 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.3 KB
  1. Path: sparky!uunet!mcsun!uknet!comlab.ox.ac.uk!michael
  2. From: michael@uk.ac.oxford.robots (& Stevens)
  3. Newsgroups: comp.robotics
  4. Subject: Re: Stepper motor programs wanted
  5. Message-ID: <MICHAEL.92Sep9002510@lucrece.uk.ac.oxford>
  6. Date: 8 Sep 92 23:25:10 GMT
  7. References: <gate.LJuLqB1w165w@toz.buffalo.ny.us> <1992Sep8.202500.27325@oswego.Oswego.EDU>
  8. Organization: Dept. Engineering Science, Oxford University, UK
  9. Lines: 36
  10. In-reply-to: nacs4160@Oswego.EDU's message of 8 Sep 92 20:25:00 GMT
  11.  
  12. In article <1992Sep8.202500.27325@oswego.Oswego.EDU> nacs4160@Oswego.EDU ( Marc F. Houde) writes:
  13.  I'm looking for programs to run a stepper motor accurately at high speeds. It 
  14.  is to be used for a project in holography. Please send any info to:
  15.  
  16. Three years ago I was also looking to control steppers. At the time I
  17. had varying velocity demands coming in to a drive motor, simple I
  18. thought.  Open loop positioning, so all you have to do is work out from
  19. the velocity demand what the step interval should be.
  20.  
  21. When implemented things actualy looked harder. The system had a fixed
  22. time quantisation interval (tick). This tick quantisation could be
  23. quite significant compared to the step period.
  24.  
  25. An addition all this had to be done very quickly, the only time was on
  26. the interupt period of a simple 8 bit microprocessor. This made me
  27. think of Breshenham's line draw algorithem. Fast, integer only,
  28. naturally fitting to a quantisation problem.
  29.  
  30. The stepper motor problem required that the velocity (gradient) could
  31. be varied on the fly, and could also be +ve, and -ve. Two descision
  32. variables are required to cope with this modified case. The big
  33. advantage of this was the algorithm has no residual error. If the
  34. velocity required doesn't quantise in time exactly the output will
  35. still run at the correct velocity 'on average'. The residual error is
  36. carried over to the next time step and added to whatever the new
  37. velocity is.  Formally: The stepper will be exactly at the same
  38. position as the integral of the velocity demands to get position.
  39.  
  40. At the time I did a quick literature survey to see if others had
  41. applied a Breshenham like method, but nothing came up. Has anyone else
  42. done something similar? Anyone interested in the algorithm?
  43.  
  44.  
  45. --
  46. Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
  47. INTERNET: michael@robots.oxford.ac.uk
  48.