topic Re: Stepper motor Speed Ramp in 8-bit Microcontrollers

Stepper motor Speed Ramp

Skaptor — Sun, 22 May 2011 04:04:14 GMT

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

Re: Stepper motor Speed Ramp

bigmac — Mon, 23 May 2011 03:00:39 GMT

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

Re: Stepper motor Speed Ramp

Skaptor — Mon, 23 May 2011 05:58:30 GMT

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

Re: Stepper motor Speed Ramp

rocco — Mon, 23 May 2011 06:54:27 GMT

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).

Re: Stepper motor Speed Ramp

Skaptor — Tue, 24 May 2011 07:12:41 GMT

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,

Re: Stepper motor Speed Ramp

JimDon — Tue, 24 May 2011 07:40:31 GMT

If your MCU has the S08RTCV1 rtc in it you could do this. If you still want to use the TPM, tell me what the oscillator frequency is and I will show you.

void InitRTCInternalClock(void){ // Set RTIE to enable interrupts, select the 1KHz internal oscillator // set the divider to 1 for a 1ms interrupt. RTCSC = 0x18; RTCMOD = 0;}interrupt  VectorNumber_Vrtc void  RTC_InterruptHandler(void){       // Do your 1ms stuff here RTCSC |= 0x80;   // Ack the interrupt}

BTW You also need to ack the TPM interrupt as well. And did you enable processor interrupts? Use the EnableInterrupts macro.

Re: Stepper motor Speed Ramp

bigmac — Tue, 24 May 2011 12:40:04 GMT

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

Re: Stepper motor Speed Ramp

kef — Tue, 24 May 2011 18:11:58 GMT

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.

Re: Stepper motor Speed Ramp

rocco — Wed, 25 May 2011 03:34:40 GMT

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.

Re: Stepper motor Speed Ramp

Skaptor — Wed, 25 May 2011 06:25:44 GMT

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;

}

Re: Stepper motor Speed Ramp

bigmac — Wed, 25 May 2011 19:29:32 GMT

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

Re: Stepper motor Speed Ramp

bigmac — Wed, 25 May 2011 20:34:45 GMT

Hello Skaptor,

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 (200 bus cycle period) is reached - the frequency will be one half the interrupt rate. A frequency step occurs starting with 5 ms interval, and the final step interval is reduced to about 100 us. If my calculations are correct, the first frequency step would be 2.5 Hz, and the final frequency step would be 13.3 kHz, i.e. the ramp starts with a slope of 0.5 Hz/ms, and concludes with a slope of 133 kHz/ms. Deceleration of the motor is not covered by the code.

Firstly, the output frequency range seems rather high for a motor device. Secondly, the frequency ramp is non-linear to an extreme. There could also be a further problem because the execution of the ISR code may not be completed within 100 bus cycles, so some interrupts would likely be missed, giving erratic operation. There is always an upper limit to the rate at which interrupts may occur, dependent on many factors.

As a general comment, since you are changing the TPM modulo value, there may be a case for using the TPM overflow interrupt, rather than the channel interrupt. The channel output toggle on compare feature will still work, even when the channel interrupt is disabled.

Regards,

Mac

Re: Stepper motor Speed Ramp

rocco — Thu, 26 May 2011 03:03:10 GMT

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.

Re: Stepper motor Speed Ramp

kef — Thu, 26 May 2011 15:22:41 GMT

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);}

Re: Stepper motor Speed Ramp

kef — Fri, 27 May 2011 14:02:13 GMT

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.

Re: Stepper motor Speed Ramp

kef — Fri, 27 May 2011 14:16:05 GMT

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

Jitter dropped to one timer tick.

Re: Stepper motor Speed Ramp

bigmac — Fri, 27 May 2011 22:19:00 GMT

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

Re: Stepper motor Speed Ramp

bigmac — Fri, 27 May 2011 23:47:48 GMT

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

Re: Stepper motor Speed Ramp

rocco — Sat, 28 May 2011 01:49:54 GMT

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.

Re: Stepper motor Speed Ramp

kef — Sat, 28 May 2011 23:56:31 GMT

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.