search

luni64 / TeensyStep4

MIT License
17 stars 15 forks source link

rotateAsync fixes #10

Closed cbradburne closed 1 year ago

cbradburne commented 1 year ago

Fixes rotateAsync after 'group move'. When running "doStep()", checks that the current mode is 'target' before doing steps across all motors.

Fixes overrideSpeed for rapid -ve and +ve moves. While running "rotISR()" keep mode as 'rotate' otherwise upon moving quickly from -ve to +ve, through zero and therefore mode = 'stopping', rotateAsync doesn't have time to change mode from 'stopping' to 'rotate' again. This meant that "overrideSpeed" wasn't run as it's "if (mode == mode_t::rotate)" statement wasn't running.

luni64 commented 1 year ago

Thanks a lot! Unfortunately I don't have time to test your PR, but I'll rely on your testing and push it :-)

luni64 commented 1 year ago

When running "doStep()", checks that the current mode is 'target' before doing steps across all motors.

Looks like I need to undo this since it disables group rotation.

cbradburne commented 1 year ago

ok, that's fair. To be honest, I didn't even know that group rotation was an option.

Like I originally said, my "fix" was a bodge / hack. Ultimately the real fix needs to only move the motors that are being told to move. This bit of code shows that when you move motors s1 and s2 in a group move, moving one of the motors then causes the other to move, when it shouldn't.

Is there a way to remove how the 2 motors are joined? I guessing it's an issue with while (stepper != nullptr) // move slave motors if required part of doStep().

void loop() {
  s1.moveAbs(10000);    // moves 1 motor
  delay(1000);

  s1.setTargetAbs(2000);
  s2.setTargetAbs(5000);
  StepperGroup{ s1, s2 }.move();  // moves 2 motors
  delay(1000);

  s1.moveAbs(0);    // MOVES 2 MOTORS!!!
  delay(1000);
}

2motors