Loading ...
Sorry, an error occurred while loading the content.

Re: Stepper Motor Controller Question

Expand Messages
  • himykabibble
    It is *extremely* important the steps be evenly spaced, unless you ll be content with slow, unreliable operation. Jitter in the step pulse train will limit
    Message 1 of 7 , Sep 30, 2009
    • 0 Attachment
      It is *extremely* important the steps be evenly spaced, unless you'll be content with slow, unreliable operation. Jitter in the step pulse train will limit your top speed, as it *will* cause the stepper to stall.

      Regards,
      Ray L.


      --- In GrizHFMinimill@yahoogroups.com, Reza Naima <reza@...> wrote:
      >
      > I'm working on a stepper motor driver that takes g-code directly over
      > USB so a dedicated pc is not required. I'm trying to figure out how
      > important it is to get the steps evenly spaced. The way the current
      > algorithm is configured, steps occur at a frequency determined by the
      > axis that must travel the furthest, and the other axis either steps at
      > the same time or skip steps. For example, X3 Y2 Z1 results in this
      > pattern of steps
      >
      > https://photos-1.getdropbox.com/i/o/3D4g36h_nvJXOdebGAJsIg3y1n_fjm5r45rsq-yUoSM
      >
      > notice that the z-axis is a multiple of the x axis (the one that moves
      > furthest) so it's steps are spaced out evenly, but the y axis is not, so
      > it skips a step every so often.
      >
      > My question is : is this acceptable, or must they be spaced out evenly?
      >
      > Thanks,
      > Reza
      >
      > p.s. this will be released to the public domain when I'm finished.
      > Email me personally if your interested.
      >
    • Reza Naima
      Thanks for the articles, though the one that describes the 3d Bresenham s uses variables without defining them which was irritating so I gave up after reading
      Message 2 of 7 , Oct 1, 2009
      • 0 Attachment
        Thanks for the articles, though the one that describes the 3d Bresenham's uses variables without defining them which was irritating so I gave up after reading for a bit.  I thought about the problem of more even spacing, and I realized that I needed to think of the problem in a temporal sense rather than a spacial/pixel sense, which these algorithms deal with.  I modified the code such that it computes the the distance and duration of motion based on the feedrate.  Then, each axis has the number of steps computed, from which we derive the time between steps per axis.   I then simply keep track of elapsed time, and step the motor at the halfway point of this duration.  I wrote some python code to test out the new algorithm :

        maxtime = 100.0; #duration of motion in microseconds
        steps = 41.0;  #number of y steps
        timePERstep = maxtime/steps; #time per step
        y=0;
        stepped = 0;
        oldTimeIntoSlice = 0;
        for time in range(0,int(maxtime)):
                timeIntoSlice = (time%timePERstep);
                if (timeIntoSlice < oldTimeIntoSlice):
                        stepped = 0;
                oldTimeIntoSlice = timeIntoSlice
                if (timeIntoSlice >= 0.5*timePERstep) and (stepped == 0):
                        #print 'step'
                        stepped = 1;
                        y = y + 1;
                print '%d,%d' % (time,y)


        And it seemed to do a reasonable job of stepping...



        The x-axis would be time, the y-axis would be steps.  The blue is the steps generated from my algorithm.  The red is a perfect line.  I would love some feedback on this approach.  I've not been able to test it out yet as my test setup was messed up when someone tripped over some USB cables.  I'll try it out tomorrow.

        I've moved my code into an open-source repository on google's servers.  You can find it here : http://code.google.com/p/rsteppercontroller/

        -Reza





        Russ R wrote:
         

        Sounds like you are using Bresenham's Algorithm. There are many write-ups of this on the web. It has also been extended to three dimensions. See eg:

        http://cat.inist. fr/?aModele= afficheN& cpsidt=13583955

        It has also been extended to circle drawing.

        These should pretty well encompass all simple G-code moves.

        Here's an interesting article on a somewhat different approach:

        http://www.angelfir e.com/space2/ m_kaykobad/ publications/ J30.pdf

        I look forward to release of your code/design. Would be lots of fun to play with!

        Russ

        --- In GrizHFMinimill@ yahoogroups. com, Reza Naima <reza@...> wrote:
        >
        > I'm working on a stepper motor driver that takes g-code directly over
        > USB so a dedicated pc is not required. I'm trying to figure out how
        > important it is to get the steps evenly spaced. The way the current
        > algorithm is configured, steps occur at a frequency determined by the
        > axis that must travel the furthest, and the other axis either steps at
        > the same time or skip steps. For example, X3 Y2 Z1 results in this
        > pattern of steps
        >
        > https://photos- 1.getdropbox. com/i/o/3D4g36h_ nvJXOdebGAJsIg3y 1n_fjm5r45rsq- yUoSM
        >
        > notice that the z-axis is a multiple of the x axis (the one that moves
        > furthest) so it's steps are spaced out evenly, but the y axis is not, so
        > it skips a step every so often.
        >
        > My question is : is this acceptable, or must they be spaced out evenly?
        >
        > Thanks,
        > Reza
        >
        > p.s. this will be released to the public domain when I'm finished.
        > Email me personally if your interested.
        >

      • Russ R
        hi again... Where s the image of the approximation to straight line? I think the basic Bresenham Algorithm would work fine and produce uniform and stable
        Message 3 of 7 , Oct 1, 2009
        • 0 Attachment
          hi again...

          Where's the image of the approximation to straight line?

          I think the basic Bresenham Algorithm would work fine and produce uniform and stable pulses. Actually, I *know* it will... it's used by John in his "Electronic Lead Screw" project and I used it in two projects way back in 1975 or so.

          That was pre-microprocessor days, so we did things in pure hardware and minicomputers (Data General NOVA in this case). I made an interface board that connected mainly via DMA (Direct Memory Acess). The software would fill a memory area with command data (speed, number of steps on major and minor axes, etc) and the hardware would constantly look for info in this memory space.

          The hardware used a VCO (Voltage Controlled OScillator) driven by a D/A converter to set speed of pulse train sent to the steppers. So it was very uniform, but could also accelerate from zero to max as controlled by the software's ramp rate info. Bresenham's Algorithm was implemented with numerous counters/comparators in hardware to determine when a pulse was needed on the minor axis. The major axis was uniformly stepped at the VCO rate.

          Software was also responsible for interpreting the G-codes and converting these into move data which was simply dumped into memory and automatically acessed by the hardware over DMA.

          We used this on two projects: one to cut Mylar film masters using an NC cutter (much like a big flat-bed plotter) and another to drill PC boards at high rate. Both performed flawlessly and very rapidly, as you might expect since the bulk of the low-level stuff was done in 74xx series TTL logic chips!

          Russ K1HOP

          --- In GrizHFMinimill@yahoogroups.com, Reza Naima <reza@...> wrote:
          >
          > Thanks for the articles, though the one that describes the 3d
          > Bresenham's uses variables without defining them which was irritating so
          > I gave up after reading for a bit. I thought about the problem of more
          > even spacing, and I realized that I needed to think of the problem in a
          > temporal sense rather than a spacial/pixel sense, which these algorithms
          > deal with. I modified the code such that it computes the the distance
          > and duration of motion based on the feedrate. Then, each axis has the
          > number of steps computed, from which we derive the time between steps
          > per axis. I then simply keep track of elapsed time, and step the motor
          > at the halfway point of this duration. I wrote some python code to test
          > out the new algorithm :
          >
          > maxtime = 100.0; #duration of motion in microseconds
          > steps = 41.0; #number of y steps
          > timePERstep = maxtime/steps; #time per step
          > y=0;
          > stepped = 0;
          > oldTimeIntoSlice = 0;
          > for time in range(0,int(maxtime)):
          > timeIntoSlice = (time%timePERstep);
          > if (timeIntoSlice < oldTimeIntoSlice):
          > stepped = 0;
          > oldTimeIntoSlice = timeIntoSlice
          > if (timeIntoSlice >= 0.5*timePERstep) and (stepped == 0):
          > #print 'step'
          > stepped = 1;
          > y = y + 1;
          > print '%d,%d' % (time,y)
          >
          >
          > And it seemed to do a reasonable job of stepping...
          >
          >
          >
          > The x-axis would be time, the y-axis would be steps. The blue is the
          > steps generated from my algorithm. The red is a perfect line. I would
          > love some feedback on this approach. I've not been able to test it out
          > yet as my test setup was messed up when someone tripped over some USB
          > cables. I'll try it out tomorrow.
          >
          > I've moved my code into an open-source repository on google's servers.
          > You can find it here : http://code.google.com/p/rsteppercontroller/
          >
          > -Reza
          >
          >
          >
          >
          >
          > Russ R wrote:
          > >
          > > Sounds like you are using Bresenham's Algorithm. There are many
          > > write-ups of this on the web. It has also been extended to three
          > > dimensions. See eg:
          > >
          > > http://cat.inist.fr/?aModele=afficheN&cpsidt=13583955
          > > <http://cat.inist.fr/?aModele=afficheN&cpsidt=13583955>
          > >
          > > It has also been extended to circle drawing.
          > >
          > > These should pretty well encompass all simple G-code moves.
          > >
          > > Here's an interesting article on a somewhat different approach:
          > >
          > > http://www.angelfire.com/space2/m_kaykobad/publications/J30.pdf
          > > <http://www.angelfire.com/space2/m_kaykobad/publications/J30.pdf>
          > >
          > > I look forward to release of your code/design. Would be lots of fun to
          > > play with!
          > >
          > > Russ
          > >
          > > --- In GrizHFMinimill@yahoogroups.com
          > > <mailto:GrizHFMinimill%40yahoogroups.com>, Reza Naima <reza@> wrote:
          > > >
          > > > I'm working on a stepper motor driver that takes g-code directly over
          > > > USB so a dedicated pc is not required. I'm trying to figure out how
          > > > important it is to get the steps evenly spaced. The way the current
          > > > algorithm is configured, steps occur at a frequency determined by the
          > > > axis that must travel the furthest, and the other axis either steps at
          > > > the same time or skip steps. For example, X3 Y2 Z1 results in this
          > > > pattern of steps
          > > >
          > > >
          > > https://photos-1.getdropbox.com/i/o/3D4g36h_nvJXOdebGAJsIg3y1n_fjm5r45rsq-yUoSM
          > > <https://photos-1.getdropbox.com/i/o/3D4g36h_nvJXOdebGAJsIg3y1n_fjm5r45rsq-yUoSM>
          > > >
          > > > notice that the z-axis is a multiple of the x axis (the one that moves
          > > > furthest) so it's steps are spaced out evenly, but the y axis is
          > > not, so
          > > > it skips a step every so often.
          > > >
          > > > My question is : is this acceptable, or must they be spaced out evenly?
          > > >
          > > > Thanks,
          > > > Reza
          > > >
          > > > p.s. this will be released to the public domain when I'm finished.
          > > > Email me personally if your interested.
          > > >
          > >
          > >
          >
        • Reza Naima
          Strange, I sent the image inline and i got a copy, but none exist on the yahoo groups website (?) It s the second image here
          Message 4 of 7 , Oct 1, 2009
          • 0 Attachment
            Strange, I sent the image inline and i got a copy, but none exist on the yahoo groups website (?)

            It's the second image here

            https://www.getdropbox.com/gallery/103257/1/rStepper?h=0f99fc

            -reza

            Russ R wrote:
             

            hi again...

            Where's the image of the approximation to straight line?

            I think the basic Bresenham Algorithm would work fine and produce uniform and stable pulses. Actually, I *know* it will... it's used by John in his "Electronic Lead Screw" project and I used it in two projects way back in 1975 or so.

            That was pre-microprocessor days, so we did things in pure hardware and minicomputers (Data General NOVA in this case). I made an interface board that connected mainly via DMA (Direct Memory Acess). The software would fill a memory area with command data (speed, number of steps on major and minor axes, etc) and the hardware would constantly look for info in this memory space.

            The hardware used a VCO (Voltage Controlled OScillator) driven by a D/A converter to set speed of pulse train sent to the steppers. So it was very uniform, but could also accelerate from zero to max as controlled by the software's ramp rate info. Bresenham's Algorithm was implemented with numerous counters/comparator s in hardware to determine when a pulse was needed on the minor axis. The major axis was uniformly stepped at the VCO rate.

            Software was also responsible for interpreting the G-codes and converting these into move data which was simply dumped into memory and automatically acessed by the hardware over DMA.

            We used this on two projects: one to cut Mylar film masters using an NC cutter (much like a big flat-bed plotter) and another to drill PC boards at high rate. Both performed flawlessly and very rapidly, as you might expect since the bulk of the low-level stuff was done in 74xx series TTL logic chips!

            Russ K1HOP

            --- In GrizHFMinimill@ yahoogroups. com, Reza Naima <reza@...> wrote:
            >
            > Thanks for the articles, though the one that describes the 3d
            > Bresenham's uses variables without defining them which was irritating so
            > I gave up after reading for a bit. I thought about the problem of more
            > even spacing, and I realized that I needed to think of the problem in a
            > temporal sense rather than a spacial/pixel sense, which these algorithms
            > deal with. I modified the code such that it computes the the distance
            > and duration of motion based on the feedrate. Then, each axis has the
            > number of steps computed, from which we derive the time between steps
            > per axis. I then simply keep track of elapsed time, and step the motor
            > at the halfway point of this duration. I wrote some python code to test
            > out the new algorithm :
            >
            > maxtime = 100.0; #duration of motion in microseconds
            > steps = 41.0; #number of y steps
            > timePERstep = maxtime/steps; #time per step
            > y=0;
            > stepped = 0;
            > oldTimeIntoSlice = 0;
            > for time in range(0,int( maxtime)) :
            > timeIntoSlice = (time%timePERstep) ;
            > if (timeIntoSlice < oldTimeIntoSlice) :
            > stepped = 0;
            > oldTimeIntoSlice = timeIntoSlice
            > if (timeIntoSlice >= 0.5*timePERstep) and (stepped == 0):
            > #print 'step'
            > stepped = 1;
            > y = y + 1;
            > print '%d,%d' % (time,y)
            >
            >
            > And it seemed to do a reasonable job of stepping...
            >
            >
            >
            > The x-axis would be time, the y-axis would be steps. The blue is the
            > steps generated from my algorithm. The red is a perfect line. I would
            > love some feedback on this approach. I've not been able to test it out
            > yet as my test setup was messed up when someone tripped over some USB
            > cables. I'll try it out tomorrow.
            >
            > I've moved my code into an open-source repository on google's servers.
            > You can find it here : http://code. google.com/ p/rsteppercontro ller/
            >
            > -Reza
            >
            >
            >
            >
            >
            > Russ R wrote:
            > >
            > > Sounds like you are using Bresenham's Algorithm. There are many
            > > write-ups of this on the web. It has also been extended to three
            > > dimensions. See eg:
            > >
            > > http://cat.inist. fr/?aModele= afficheN& cpsidt=13583955
            > > <http://cat.inist. fr/?aModele= afficheN& cpsidt=13583955>
            > >
            > > It has also been extended to circle drawing.
            > >
            > > These should pretty well encompass all simple G-code moves.
            > >
            > > Here's an interesting article on a somewhat different approach:
            > >
            > > http://www.angelfir e.com/space2/ m_kaykobad/ publications/ J30.pdf
            > > <http://www.angelfir e.com/space2/ m_kaykobad/ publications/ J30.pdf>
            > >
            > > I look forward to release of your code/design. Would be lots of fun to
            > > play with!
            > >
            > > Russ
            > >
            > > --- In GrizHFMinimill@ yahoogroups. com
            > > <mailto:GrizHFMinim ill%40yahoogroup s.com>, Reza Naima <reza@> wrote:
            > > >
            > > > I'm working on a stepper motor driver that takes g-code directly over
            > > > USB so a dedicated pc is not required. I'm trying to figure out how
            > > > important it is to get the steps evenly spaced. The way the current
            > > > algorithm is configured, steps occur at a frequency determined by the
            > > > axis that must travel the furthest, and the other axis either steps at
            > > > the same time or skip steps. For example, X3 Y2 Z1 results in this
            > > > pattern of steps
            > > >
            > > >
            > > https://photos- 1.getdropbox. com/i/o/3D4g36h_ nvJXOdebGAJsIg3y 1n_fjm5r45rsq- yUoSM
            > > <https://photos- 1.getdropbox. com/i/o/3D4g36h_ nvJXOdebGAJsIg3y 1n_fjm5r45rsq- yUoSM>
            > > >
            > > > notice that the z-axis is a multiple of the x axis (the one that moves
            > > > furthest) so it's steps are spaced out evenly, but the y axis is
            > > not, so
            > > > it skips a step every so often.
            > > >
            > > > My question is : is this acceptable, or must they be spaced out evenly?
            > > >
            > > > Thanks,
            > > > Reza
            > > >
            > > > p.s. this will be released to the public domain when I'm finished.
            > > > Email me personally if your interested.
            > > >
            > >
            > >
            >

          Your message has been successfully submitted and would be delivered to recipients shortly.