1

I am working with a MEGA2560 trying to implement velocity ramps for three steppers at the same time. The goal is to move to different positions applying accelerations and decelerations while finishing all of them at the same time.

In order to do so, from the distances to move of each of the motors, I calculate the amount of steps to do and the velocities for each of those steps in order to ensure that all the motors finish at the same time. For so, I use timers 3, 4 and 5 in compare mode. This way, at each interruption, I make the motors do one step and, after that, I set the new compare value for the timer in order to reach the new velocity to move at.

My problem is that, at some point, my interruptions crash and one of the motors stops working. This only happens under one condition: when motor 1 has to do 18 steps and motor 2, 34. In this case, both motors 1 and 3 finish but motor 2 gets stuck and does not move any more. Although, if its motor 1 who has to do 34 steps and motor 2, 18, everything works. Motor 1 is related to timer 3 and motor 2 to timer 4. This makes me think this must be related to the priorities of the interruptions.

In the following code you can see my interruptions:

ISR(TIMER3_COMPA_vect) {
    m1_step();
    m1_steps_done++;
    m1_configure_vel();
}
ISR(TIMER4_COMPA_vect) {
    m2_step();
    m2_steps_done++;
    m2_configure_vel();
}
ISR(TIMER5_COMPA_vect) {
    m3_step();
    m3_steps_done++;
    m3_configure_vel();
} 

While, in the velocity configuration I have:


void m1_configure_vel() {

  if (m1_steps_done < m1_acceleration_steps) {
    m1_temp_vel = m1_temp_vel + acceleration;
  }
  else if (m1_steps_done <= (m1_steps - m1_acceleration_steps)) {
    m1_temp_vel = m1_temp_vel;
  }
  else if (m1_steps_done < m1_steps) {
    m1_temp_vel = m1_temp_vel - acceleration;
  }
  else {
    m1_temp_vel = 0;
    m1_finished = true;
  }
  if (m1_temp_vel <=0){
    m1_temp_vel = 0;
  }

  OCR3A = frequency_to_compare_value(m1_temp_vel);
}

As you can see, all I do here is, depending on the steps done by the motor and the amount of steps to do, I increase, maintain or decrease the motor's velocity and set the compare value for the timer.

The whole thing is that this code works fine, the ramps are calculated properly and motors move correctly. The problem is that, under the condition I explained before, interruptions may collide due to their priorities and one of them just stops to happen.

I was wondering if anyone had any idea or have faced something like this before.

6
  • Thats a weird problem. As I know, there is no interrupt priority on AVR chips. If an interrupt happens, while another ISR is currently running, the corresponding flag is set and the ISR execution will happen after the first ISR finishes. Do you have access to an oscilloscope or a logic analyzer? It might be good to check, if the expected signal is getting outputted on the motor2 pin. Maybe there is a hardware problem. Or are you having any code, that might use one of the timers?
    – chrisl
    Commented Feb 25, 2021 at 10:45
  • Thanks for your response @chrisl . I discard hardware problems since the whole system does work in all other situations. I have now tried to change the prescaler of the timers. They were set to 1 but now I have configured them to 8, so timers how a frequency of 2MHz now. Surprisingly, the system does not fail now, the whole sequence is done with no errors and none of the interruptions freeze. I suppose that by reducing the timers' frequency, they may now be working under less "pressure" so that they may not be hitting each other. Commented Feb 25, 2021 at 13:02
  • @chrisl There is what is called "natural priority" - each intrerupt has a number, and they are checked in sequence - interrupts with lower numbers happen before those with higher numbers. If a lower numbered interrupt re-occurs before the higher numbered one has a chance to run it will be responded to in preference to that higher numbered one. Which is why ISRs need to be as short as possible.
    – Majenko
    Commented Feb 25, 2021 at 13:02
  • @Majenko I have implemented these timer interruptions at a frequency way higher than the one the crash I mentioned before happens. When this situation happens and my interruptions stop, none of them have a frequency higher than 500Hz, while, with the same code, they can make simultaneous movements at 4kHz. With this I mean that my code inside interruptions doesn't last enough for not letting other interruptions to happen. In my critical case, the ISR frequencies are low enough to run all the code inside but, with no sense, one of them simply gets stuck. Commented Feb 25, 2021 at 13:08
  • @Majenko Oh, interessting. Didn't know that, thanks :)
    – chrisl
    Commented Feb 25, 2021 at 13:30

2 Answers 2

1

I think the problem is being caused by the size of your ISR's. When using ISR's, it's important to make the code as short as possible and you should certainly avoid using any functions!

I would change each of your ISRs to:

ISR(TIMER3_COMPA_vect) {
    m1_steps_done++;
}
ISR(TIMER4_COMPA_vect) {
    m2_steps_done++;
}
ISR(TIMER5_COMPA_vect) {
    m3_steps_done++;
} 

then, in the main loop of your code, you can change it so that if m1_steps_done, or m2_steps_done or m3_steps_done has increased, execute the step and configure functions

0

Another approach might be to use a single timer instead of 3 separate ones. Maintain 3 software counters and increment all of them on each interrupt, with separate limit tests and resets. This will be slightly slower, but there will be no possibility of collisions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.