Very dynamic speed changes let TeensyStep ignore overrideSpeed()

[baender]

Problem

The illustration below shows three tests with three periods each (horizontal) and increasing P of the PID controller (new program uploaded between each test). The bottom panel shows what is called delta in the minimal code example.

With a value of 7.3E-5 the behaviour is pretty good. Increasing it to 8.3E-5 lets TeensyStep overshoot a little, which is then corrected by the controller. However, when increasingn the value further to 9.3E-5, it appears that TeensyStep is overshooting even more but instead of correcting it by the controller, the position gets stuck. The rest of the program continues normally but TeensyStep does not react any more to overrideSpeed().

The minimal code example is the exact same as in issue #109 except targetInterval = 2000000 (to have more time to see what happens).

Setup

Plain Teensy 3.6, nothing attached other than USB

[luni64]

Interesting, I'll have a closer look in the next days.

[FlipEngineering]

@luni64 did you find any time to look into this? I seam to have the same issue. I tried to fix it within your library but now it's worse and I get (seemingly) random freezes.

[baender]

Hi @luni64

it has been some time since I worked with TeensyStep. I tried to get closer to the issue I am facing regarding freezes. For this example I managed to remove the PID controller and anything related to it.

So the code toggles the rotation direction via overrideSpeed() every 2 seconds to about 10% of the maximum speed. Every 5ms the currentPosition, targetSpeed and currentSpeed are printed.

When relativeTargetSpeedMax = 0.09 all three outputs seem to be alright. Setting the value to 0.10, suddenly stepper.getPosition() stays constant eventhough the rotateController continues to change rotation speed and direction as assumed. Somehow the link between Stepper and rotateController seems to break.

#include <Arduino.h>
#include <TimerOne.h>
#include <TeensyStep.h>


constexpr uint32_t toggleInterval        = 2000;    // milliseconds
constexpr uint32_t overrideSpeedInterval = 5000;    // microseconds
constexpr uint32_t maxSpeed              = 300000;  // steps per seccond
constexpr uint32_t maxAcceleration       = 250000;  // steps per second^2
constexpr float relativeTargetSpeedMax   = 0.09;    // (Point of failure between 0.09 and 0.10)

bool printDebug = true;

Stepper stepper(6, 7);
RotateControl rotateController;

bool direction = false;
elapsedMillis elapsedTime = 0;
float relativeTargetSpeed = 0.0;


volatile bool newTick;

// ISR for override speed
void tick() {
  newTick = true;
}


void setup() { 
  Serial.begin(115200);
  while (!Serial) { }

  stepper.setMaxSpeed(maxSpeed);
  stepper.setAcceleration(maxAcceleration);
  stepper.setPosition(0);
  rotateController.rotateAsync(stepper);
  rotateController.overrideSpeed(0);
  
  newTick = false;
  Timer1.initialize(overrideSpeedInterval);
  Timer1.attachInterrupt(tick);

  elapsedTime = 0;
}


void loop() {
  if (elapsedTime >= toggleInterval) {
    elapsedTime -= toggleInterval;
    if (direction) {
      relativeTargetSpeed = relativeTargetSpeedMax;
    } else {
      relativeTargetSpeed = -relativeTargetSpeedMax;
    }
    rotateController.overrideSpeed(relativeTargetSpeed);
    direction = !direction;
    
  }

  if (newTick) {
    newTick = false;
    if (printDebug) {
      int32_t currentPosition = stepper.getPosition();
      float relativeCurrentSpeed = rotateController.getCurrentSpeed() / static_cast<float>(maxSpeed);
      Serial.printf("%d\t%.2f\t%.2f\n", currentPosition, relativeTargetSpeed, relativeCurrentSpeed);  // For simulation of controller behaviour only
    }
  }
}

[baender]

Pleas see #150

[luni64]

I do not have a lot of time at the moment to do deeper tests, but I assume that your use of TimerOne causes problems. TimerOne on the Teensy3x boards internally uses one of the FTM timers. TeensyStep also uses the FTM timers to reset the step pin after the pulse time. So it is quite likely that this will conflict.
Can you test if the problem goes away if you do not use the TimerOne?

[EeeLo]

Hello baender, how about your freeze problem?
I have the same question now runing on stm32 nucleo-f446
already few days to findout what happened

[baender]

@EeeLo Check out #150