Stepper motor Speed Ramp

[Skaptor]

hello, as the title says i´m trying to do a speed ramp for a slo-syn stepper motor.

I´m using DEMO9s08LL16 board, an example of my code (not speed ramp):

PTCD_PTCD4 = 0;

delay(10)   //cpu cycles 10 multiplies 100 cycles

PTCD_PTCD4 = 1;

delay(10); //cpu cycles

PTCD_PTCD4 = 0;

delay(10)   //cpu cycles

PTCD_PTCD4 = 1;

delay(10)   //cpu cycles

PTCD_PTCD4 = 0;

delay(10)   //cpu cycles

PTCD_PTCD4 = 1;

delay(10)   //cpu cycles

If I decrement the delay time the motor will go faster, but in order to speed it, i need to have a speed ramp.

I know speed ramps change the starting delay and decrement it.

greetings,

Skaptor

[bigmac]

Hello Skaptor, and welcome to the forum.

For ramping a stepper motor, you will need to achieve a linear output frequency control.  Varying the delay value will give non-linear frequency control.  A method of achieving linear control can be found https://community.freescale.com/message/73208#73208.  The thread provided an ADC controlled stepper speed, however linearly ramping the speed should also be simple to achieve.  What ramp slope (Hz per second) do you require?

Regards,

Mac

[Skaptor]

Thanks for the reply bigmac.

I believe I achieved linear  output frequency (I saw that within an oscilloscope).

The slope I need should be arround 10 Hz per sec, I need that to speed the motor to its maximmum speed.

regards

[rocco]

Hi Skaptor,

Mac is right in that the frequency is non-linear. To be specific, the frequency will be the reciprocal of the delay time. At lower frequencies, it will look pretty linear, but the curvature will increase as the speed increases.

I did the same thing as what you are doing  back in the 80's, (using an MC68701) and I simply indexed through a table of delay values. I built the delay table using MathCad, and imported it into my firmware. I indexed forward through the table to ramp-up to speed, and backward through the table to ramp-down. I used the output-compare function to generate the step pulses (similar to what you have now with the S08 timers).

[Skaptor]

Thanks for the reply.

Please bear with me i´m just 16 and don´t know lots of things yet.

ok i´m trying to use the TPM module to make the acceleration, I want to do it in 2000 mS but I can´t get the timer working here´s an example:

// Timer1 overflow about every 1ms
  TPM1MOD = 8000;
  TPM1SC = 0x54;

The timer ISR wont execute. any ideas? I appreciate your help.

the ISR:

interrupt VectorNumber_Vtpm1ch0 void timer1_CH0(void)
{
    // Clear CH0F flag
  TPM1C0SC &=0x7F;


      //Clear the 16-bit timer1 counter
    TPM1CNT = 0x00;    
 
}

regards,

[bigmac]

Hello Skaptor,

There are two different methods of achieving a linear frequency control.  The method that Rocco has used might be described as a "table lookup" method.  The method that I previously referenced is a direct digital synthesis (DDS) method, with square wave output.  Either method would require the use of two timers, one for generating the output frequency, and a second one for the slow ramp output control.

My personal preference is the DDS method, for which the timer interrupt period remains constant.  This represents the DDS clock.  The method would utilize a 16-bit accumulating register, with a value N added to the accumulator during each interrupt.  Each overflow of the accumulator represents one cycle of the output frequency.  Therefore, the higher the value of N, the more quickly will the accumulator overflow, and the higher will be the output frequency.  The output frequency will be given by the formula:

Fout = Fclk * N / 65536

The incremental frequency step will be:

delta_F = Fclk / 65526

Let's assume delta_F = 0.1 Hz.  The will result in Fclk = 6553.6 Hz (or Tclk = 152.6 us).  Assume that the TPM1 module is used, with software output compare on channel 0, for this purpose. Your current interpretation of TPM operation seems to be incorrect.

For the frequency ramp control, I have assumed that TPM2 module is used, again with software output compare on channel 0.  In this case, an interrupt would occur each 10ms, where the current N value would be incremented, decremented, or remain unchanged, depending on the current speed setting for the stepper.  This will result in a frequency ramp of 0.1 Hz per 10ms, or 10 Hz per second.

The following snippet shows the ISR code for each interrupt.  I have not shown the initialisation required for each TPM module, nor the code required to set the speed value.

.

// For following output compare intervals, 8 MHz bus frequency is assumed
#define INCR_VAL  1220        // TPM1C0 Output compare period 152.6us with prescale 1
#define RAMPTIME  19999       // TPM2C0 Output compare period 10ms with prescale 4
#define STEP_CLK  PTAD_PTAD0  // GPIO pin
 
word ramp, speed;             // Global variables

interrupt void ISR_TPM1C0( void)  // 152.6us intervals
{
   static word accum = 0;
 
   TPM1C0SC_CHOF = 0;    // Clear flag
   TPM1C0V += INCR_VAL;  // Set next compare value

   accum += ramp;        // Update accumulation count
   if (accum & 0x8000)   // Test MSB
      STEP_CLK = 1;
   else
      STEP_CLK = 0;
}

interrupt void ISR_TPM2C0( void)  // 10ms intervals
{
   TPM2C0SC_CHOF = 0;    // Clear flag
   TPM2C0V += RAMPTIME;  // Set next compare value
  
   if (ramp < speed)  ramp++;
   if (ramp > speed)  ramp--;
}
.

In practice, the maximum value within the global variable speed would be limited to about 2000, giving an upper frequency limit of 200 Hz.  This will minimize short term frequency jitter.

Regards,

Mac

[kef]

Mac,

I don't know it will be useful, but it is possible to improve jitter of your DDS pulse generator a lot in the case one has spare output compare channel.

In your code, accum variable is in fact the phase of the signal. When it's a time in Fdds ISR to generate pulse or toggle the pin level, phase error is known and we can calculate delay needed to generate pulse more precisely. We can either check if on the next Fdds ISR phase will overflow and calculate positive phase correction Ph_togo in timer ticks units and generate pulse on +Ph_togo. Or, we can wait while phase overflows and calculate negative phase correction Ph_late, and generate output compare pulse on +Tdds-Ph_late.

interrupt void ISR_TPM1C0( void)  // 152.6us intervals
{
   word accum;

   static word old_accum;

   TPM1C0SC_CHOF = 0;    // Clear flag
   TPM1C0V += INCR_VAL;  // Set next compare value

   accum = old_accum + ramp;        // Update accumulation count
   if( (old_accum ^ accum) & 0x8000) // was there an phase oveflow?

   {

      generate_toggle_on(TPM1C0V - (unsigned long)INCR_VAL * (accum & ~0x8000) / ramp);

   }

   old_accum = accum;

}

Yes, division in 6.5kHz interrupt is not nice thing. But we can eliminate division precalculating INCR_VAL / ramp * 65536 multiplier on change of ramp and eliminate division in Fdds interrupt.

word mramp; // precalculated mramp

   mramp = (unsigned long)INCR_VAL * 65536 / ramp;

Then expression in ISR should be this

  generate_toggle_on(TPM1C0V - ((unsigned long)(accum & ~0x8000) * mramp) >> 16);

I tried it on S12, so my apologies for no code for generate_toggle_on(). Using the same Fdds=6.5kHz and Fout=200Hz, jitter dropped from ~150us down to 60ns.

[bigmac]

Hello Kef,

Your approach to compensate for the DDS output jitter is very interesting, although I would be concerned about the extra bus cycles for the additional processing, and the ability to use higher DDS clock rates.

I happened to look at the details of the Slo-syn products, named in the OP.  I note that the typical lower power models have the torque specified up to 10,000 steps per second, and the basic model has 200 steps per revolution (1.8 deg/step).  To achieve the maximum speed, it would seem that there would be problems with either control method.  I think that the DDS method is out of the picture for the HCS08.

With the lookup method, the minimum interrupt period would be 50us or 400 bus cycles, requiring an output compare interrupt twice per cycle.  Without allowing for multiple timer overflows, and the extra code to do this, the minimum allowable frequency would be about 62 Hz.

If we assume each frequency step 2 Hz, there would be nearly 5000 steps over the full frequency range, therefore requiring a linear interpolation process to reduce the 10 kbyte table size.  For the HCS08 there is no hardware assistance for doing this, compared with the HCS12.  I am guessing that the ISR code will require significantly more than 200 bus cycles, (allowing 50 percent processor usage).

However, a different strategy might be feasible - one that does not require interrupts at twice the output rate, and is an adaption of the lookup method.

The frequency only needs to change at each speed ramp step, and remains constant between steps.  If I were to assume a ramping rate of 1kHz per second (I don't know whether this is realistic), and with a 2 Hz speed step, would represent 500 output compare interrupts per second for the timer controlling the ramp.

Therefore, the proposal would be to utilise 50 percent PWM output for the drive, and to simultaneously change the modulo and PWM channel settings as a consequence of each ramp interrupt.  I have not examined the synchronising process required to prevent any gliches or discontinuities, so might require an additional interrupt on the PWM channel, at the ramp interrupt rate.  Of course, the new settings must be calculated during the ramp ISR.

Regards,

Mac

[kef]

Mac,

yes, DDS with jitter compensation doesn't seem practical, it is more like academic excercise. But if calculated phase adjustment almost removes jitter, then what about calculating approximate adjustment? Higher, but still acceptable jitter could be OK and could allow to use lower Fdds for the same output frequency. Hope it is possible to estimate fractional multiplier on change of speed with just one DIV instruction call, and maybe calculate phase adjustment on phase overflow with just 1-2 MULs.

[bigmac]

Hello Kef,

I did some simulation tests on your method of DDS phase correction adapted for a HCS08 device, with some rather interesting observations.

Whether doing the full calculation of phase correction within the 153us ISR, or using the "mramp" version, nearly the same number of cycles were required for each method.  The full calculation required 941 cycles, whereas the second method required 923 cycles for its calculation.  In addition, the "mramp" calculation within the ramp ISR required an additional 303 cycles.  Therefore actually better to do the full calculation within the ISR.

The worst case phase correction, to be subtracted, could approach INCR_VAL.  Therefore, the delay to the output transition on the second TPM channel should be increased by a fixed amount, so that its channel register will have been updated before the transition is required to occur in the worst case situation.  A period equivalent to the ISR execution cycles would be appropriate.

I have not done exhaustive tests over a wide range of speed values, but the following total interrupt execution periods were simulated, which might just "scrape in" with 153 us between interrupts.

Intermediate interrupts between output transitions:  106 cycles (14us)

Transitional interrupts (twice per output cycle):  1063 cycles (133us)

With phase correction applied, it should now be possible to operate at a much higher output frequency, relative to the DDS clock.  I am not sure how far this can be pushed, but maybe up to one-quarter the DDS clock rate, which would be an eight times improvement over previous assumptions.  Conversely, for a given output frequency, the DDS clock rate could be reduced to ease the ISR situation.

Here is the ISR code that I used for the simulation.

// TPM1: channel 0 ISR__interrupt void ISR_TPM1C0( void) // 152.6us intervals{   static word accum = 0;   word old;      TPM1C0SC_CH0F = 0;              // Clear flag   TPM1C0V += INCR_VAL;            // Set next compare value   old = accum;   accum += ramp;   if ((accum ^ old) & 0x8000) {   // Phase transition      TPM1C1V = TPM1C0V + ISR_CYC - (word)((dword)(accum & 0x7FFF) * INCR_VAL / ramp);         if (accum & 0x8000)         TPM1C1SC = 0x5C;          // Output high on next compare      else         TPM1C1SC = 0x58;          // Output low on next compare   }}

The TPM1C1SC values that I used above had the interrupt enabled.  However, I don't think this is actually necessary - the hardware output compare does not require its own interrupt.  Why am I mentioning this here?  Because it is not possible to edit the code window with the current version of the forum engine.

Regards,

Mac

[kef]

Hi Mac,

Maybe you used small ramp divider in mramp calculaion? Division by small divider <256 in CW08 is done using DIV instructions and takes ~300 cycles (while long multiply takes about 600 cycles). But when divider is >=256, division takes over 3000 ctcles. So I think that mramp precalculation is indeed required.

• The worst case phase correction, to be subtracted, could approach INCR_VAL.  Therefore, the delay to the output
• transition on the second TPM channel should be increased by a fixed amount, so that its channel register will have
• been updated before the transition is required to occur in the worst case situation.  A period equivalent to the ISR
• execution cycles would be appropriate

You are right. I forgot to take into account interrupt latency and that OC setting should be delayed by some fixed vaalue.

Yes, it is interesting to try output frequencies up to and above Fdds/4. Also I wonder if it will work to do rough approximation of phase adjustment, expecting in return shorter Fdds ISR at a cost of not much worse jitter.

[bigmac · Accepted solution]

Hello Kef,

I take your point about the value of the ramp  divisor.  But maybe this leads to a "rough approximation" method - which is to scale both the divisor and the dividend so that the divisor is within the range 128 - 255.  A further point would be to eliminate the phase correction for very small values of the ramp  variable, since the percentage jitter will be very small anyway.  The following ISR code might be a possible contender, although I have not yet done a cycle count to ascertain the extra overhead involved.

// TPM1: channel 0 ISR__interrupt void ISR_TPM1C0( void) // 152.6us intervals{   static word accum = 0;   word old, mult, div;      TPM1C0SC_CH0F = 0;              // Clear flag   TPM1C0V += INCR_VAL;            // Set next compare value   old = accum;   accum += ramp;   if ((accum ^ old) & 0x8000) {   // Phase transition      if (ramp >= 128) {           // No phase correction for small values         mult = INCR_VAL;         div = ramp;         while (div >= 256) {            mult /= 2; div /= 2;   // Scale values         }         TPM1C1V = TPM1C0V + ISR_CYC - (word)((dword)(accum & 0x7FFF) * mult / div);      }      else         TPM1C1V = TPM1C0V + ISR_CYC - INCR_VAL / 2;         if (accum & 0x8000)         TPM1C1SC = 0x1C;          // Output high on next compare      else         TPM1C1SC = 0x18;          // Output low on next compare   }}

So far I have not been able to estimate the worst case phase correction error.  But this does raise the question for a "typical" small size stepper application, of what the maximum allowable percentage jitter might be?  I think that the intitial uncorrected example had about 3 percent peak jitter at the stipulated maximum speed.

Regards,

Mac

[kef]

[For some reason edit message succeeds, but I see old contents. ]

Jitter dropped to one timer tick.

[kef]

It is of course interesting to use DDS, but I'm not sure if it's a good idea to use DDS for step motor velocity profiles. For slow speeds yes, it should be ok. But let's consider the case of 200Hz step rate, which is not high, and 6.5kHz DDS clock, please correct my if I'm wrong.

DDS output clock of 200Hz means that you should see 200*2 toggles per second or 200Hz of average frequency. But instant frequency in fact may change from period to period (of Fout). Outputing the same 200Hz signal, period will sometimes change by +1/Fdds or -1/Fdds, which is +-152us in our case. This is because Fdds/Fout ratio is not integer, it's between 32 and 33. So the instant output freqency will vary from Fdds/32=204.8Hz to Fdds/33=198.6Hz to produce average Fout of 200Hz. 5Hz difference may be too big step for some motors and loads. 

It is more difficult to calculate output compare delays on the fly, from step to step. But 200Hz interrupt rate is >30 times lower than in the case of 6.5kHz DDS. As another bonus you should be able to accelerate your motor to higher speeds.

[bigmac]

Hello Kef,

I agree with your observations about the limitations of the DDS method for higher speed applications, including the amount of jitter that you calculate for the frequency waveform.  However, my assumption was that the motor and load would provide inertia for "low pass filtering" the jitter component, resulting in a significantly lower modulation of the motor speed.  Otherwise, there would not be the requirement for the speed ramping of a low inertia system.

For the example that I posted, I purposely chose rather conservative speed requirements with a frequency resolution of 0.1Hz for the average frequency, which would be accurate.  Still assuming the 8MHz bus, it should be feasible to quadruple the interrupt rate, because of the simplicity of the ISR code.  Without increasing the length of the accumulating register beyond 16 bits, this would also have increased the frequency increment to 0.4Hz.  But perhaps this would be OK for many 800Hz stepper applications, thus retaining the code simplicity, and not having to revert to assembly coding.

A major advantage of the DDS method is the ability to control down to zero frequency, for applications where this is important.  This would appear to be a major weakness of the lookup table method with frequency to period conversion.  In fact, there would always be a minimum frequency, below which the timer would overflow.  Of course, you can fiddle with prescale rates on the fly, or handle multiple overflows, but I will assume this would greatly increase code complexity within the timer ISR and elsewhere, and maybe ramping would be virtually impossible. 

There is also likely to be the situation where the minimum speed requirement will dictate a given period interval, so that the speed resolution at high speeds could be considerably degraded.  Using the previous example, a 200Hz stepper with at most 0.1Hz resolution, would require a period resolution of 2.5 us (1/199.9 - 1/200) and a TPM interval of 2000, with appropriate prescale factor.  Therefore TPM overflow will occur for frequencies less than about 6.1 Hz, or a speed control ratio of approximately 32:1.

Neither method is ideal for all applications - the best method will likely depend of the finer detail of each application.  I posted the DDS snippet as a basis for experiment, because of the simplicity of the code, and to also provide an example of TPM output compare operation, which seemed to be needed.  Maybe you could similarly post a snippet for the alternative method, as a means of comparison.

Regards,

Mac

[kef]

Hi Max,

no doubt, your code is great and made me wondering if I could use DDS for my SM(step motor) application, where I'm acceleratting it to 20kHz. It would simplify calculations a lot. But high ISR rate, high jitter and output clock makes DDS impractical. I doubt it is possible to accelerate SM to high speeds with 3% jitter/T(period). Jitter causes extra vibration(acceleration) and SM loose their torque on higher speeds. But I may try.

In the past on HC11 I was using 2 or 3 lines interpolation of output compare delay vs step# curve for linear velocity profile like in attached xls file. ISR code is quite simple. When accelerating I was decrementing T by smaller or higher dT, depending on current T.

On S12 I'm calculating T and deceleration/acceleration paths on the fly. This allows to accept new position, acceleration or target speed commands at any time, motor smoothly accelerates/decelerates and changes direction without extra momevents or idling.

Long T is no problem at all. Yes, I'm counting timer overlows. Bad cases like T%65536 < interrupt latency are divided into two parts 0x8000 ticks and 0x8000+T%65536. Here's my code for S12, I didn't use the same approach on S08 yet:

#pragma TRAP_PROCvoid smisr(void){static unsigned long period;static char half; // extra +0x8000 interrupt   // is overflow counter > 0   if( (period >> 16)!= 0)   {      if(half)      {         // timer compare value += 0x8000         TCh(STEPPINNO) += 0x8000;         half = 0;      }      else      {         // decrement overflow counter         period -= 0x10000;               if( (period >> 16) == 0 )         {            // set compare mode to SET            SETCOMPMODE(STEPPINNO, COMPSET);         }      }   }   else   {      // set compare mode to CLEAR      SETCOMPFROMSETTOCLEAR(STEPPINNO);      // force compare output      CFORC |= (1<<STEPPINNO);      // calculate new period here      period = ???;      if( (unsigned short)period < latency )      {         half = 1;         TCh(STEPPINNO) = 0x8000 + TCh(STEPPINNO) + (unsigned short)period;      }      else         TCh(STEPPINNO) = TCh(STEPPINNO) + (unsigned short)period;            // should we set OC pin on next ISR?            if( (period >> 16)!= 0)      {         SETCOMPMODE(STEPPINNO, COMPSET);      }   }   // clear flag   TFLG1 &= (1<<STEPPINNO);}

[rocco]

Hi Mac,

---

bigmac wrote:

A major advantage of the DDS method is the ability to control down to zero frequency, for applications where this is important.  This would appear to be a major weakness of the lookup table method with frequency to period conversion.  In fact, there would always be a minimum frequency, below which the timer would overflow.

.

.

Perhaps I am missing something, but your code snippet appears to commence with a hard-coded frequency of 500 Hz at TPM1C0 pin output, and then increases the frequency until a frequency of 40,000 Hz . . .
 

---

What hasn't been mentioned is a stepper-motor's "base" speed: the step-rate that the motor needs to start ramping from. This rate is never zero, and 500 Hz seems like a reasonable value. Any step-rate slower than the base-rate causes the motor to "lurch" from step to step, causing vibration and noise. The frequency is below that mechanical low-pass filter that you mentioned.

And speaking of that mechanical low-pass filter, you are correct in that it should compensate for the jitter in the step-rate. However, a motor-driver circuit that contain anti-resonant circuitry (compensating for the mid-band resonance problem) typically cannot handle the jitter. The jitter appears as repeating changes in acceleration, causing the driver circuit to not know what to do.

[bigmac]

Hello Rocco,

---

rocco wrote:

What hasn't been mentioned is a stepper-motor's "base" speed: the step-rate that the motor needs to start ramping from. This rate is never zero, and 500 Hz seems like a reasonable value. Any step-rate slower than the base-rate causes the motor to "lurch" from step to step, causing vibration and noise. The frequency is below that mechanical low-pass filter that you mentioned.

---

I had assumed that zero minimum velocity would be a requirement for those applications requiring open-loop position control.  The provision of speed ramping might still be important to prevent missed steps.

My understanding was that "lurching from step to step" was fundamental to the operation of a stepper motor.  This should obviously not be a problem for the stepper motor itself.  If this is problematic for the load, at low operational speeds, perhaps a motor type with more steps per revolution is needed, or a more complex microstepping drive could be employed.

Regards,

Mac

[rocco]

---

bigmac wrote:

I had assumed that zero minimum velocity would be a requirement for those applications requiring open-loop position control.  The provision of speed ramping might still be important to prevent missed steps.

---

It is a reasonable assumption, and one I also made at first. But very quickly you learn that 1) the beginning chunk of your ramp can be tossed away and you can get up to speed quicker, and 2) you can avoid a lot noise and vibration.

The physics is that, regardless of how fast you issue step pulses, the motor can make a single step rather quickly. Any step-rate below the base-rate will allow the motor to step and then come to a full stop before the next step pulse. Hence noise and vibration.

And you are right, the load can affect the base rate, if it is tightly coupled to the motor. But most stepper applications use soft-coupling to the load to protect it against vibration. The driver circuit can also effect the base-rate.

[rocco]

I agree that DDS is a great algorithm for generating rates, but as Kef mentioned, a firmware implementation could be either too slow or too inaccurate. When I need DDS, I do it in an FPGA, with a minimum add-rate of 1 MHz.

The approach I took only needs a single timer (that's all I had in 68701). I simply loaded a table value into the output-compare register, and on each OCR interrupt, I would load the next value from the table. It was just a couple of instructions per step, and I could get step-rates up to 40kHz twenty years ago.

A big disadvantage over DDS is the lack of flexibility. With DDS, you could generate any ramp you need on the fly, whereas the table uses a "canned" ramp. If a canned ramp is all you need, the table approach is quick, easy and extremely smooth.

Building the table is the challenge. The output-compare circuit generates delays, which is the reciprocal of rate. On top of that, the velocity update rate is based on that same variable delay, so that is a second level of non-linearity. Also, I did not use a linear ramp, built built a ramp derived from the motor's torque-curve, for a third level on non-linearity.

So I used the three equations in MathCad to generate the table, and programmed that into the microcontroller's EEPROM separately (allowing me to program different tables for different motors).

Hope that helps.

[Skaptor]

I have done it. thanks for your help!

this is my initialization:

//////////////////////////////////////////////////////////////////////////// 
// Init TPM
////////////////////////////////////////////////////////////////////////
     
 // Timer1 overflow about every 1ms
  TPM1MOD = mod;
  // Stops timer2 and select 1 as prescaler divisor
  TPM1SC = 0x0C;  //4C

  TPM1C0SC =0x54; 
  TPM1C1SC =0x10; 

 
   // Timer2 overflow about every 1ms
  TPM2MOD = 0;
  // Stops timer2 and select 1 as prescaler divisor
  TPM2SC = 0x00;
  TPM2C0SC =0x10;  //with these i have enabled the isr
  TPM2C1SC =0x10; 

interrupt VectorNumber_Vtpm1ch0 void timer1_CH0(void)
{
  msec++;
 
  
  if(msec > 5)
  {
    msec = 0;
   
    if(mod > 100)  //this is the ramp
    {
      mod -= 20;
    }      
  }
 
  TPM1MOD = mod;
 
    // Clear CH0F flag
  TPM1C0SC &=0x7F; 


      //Clear the 16-bit timer1 counter
      //TPM1CNT = 0x00;
 
}