Issues with stepper motors controlled with serial

Hi, I'm trying to do a motorized equatorial mount for my telescope and I have ran into an issue when controlling the DEC and RA axis stepper motors with serial commands. Sometimes the motors stop moving in the middle of a command and the whole arduino "crashes" and I have to press the physical reset to get the motors moving again. This is more common when using negative number of steps for the motors. I'm using postep25-256 stepper motor controllers power by a Atx power supply. Im not sure if the problem is with the hardware or with the code.

#include <AccelStepper.h>


byte DIR_PIN = 2;
byte STEP_PIN = 4;
byte DIR_PIN2 = 9;
byte STEP_PIN2= 10;

AccelStepper RAmotor(AccelStepper::DRIVER, STEP_PIN, DIR_PIN);

AccelStepper DECmotor(AccelStepper::DRIVER, STEP_PIN2, DIR_PIN2);

long targetRA = 0;
long targetDEC = 0;
bool isGoTo = false;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(19200);
  RAmotor.setMaxSpeed(1000);
  RAmotor.setAcceleration(500);
  DECmotor.setMaxSpeed(1000);
  DECmotor.setAcceleration(500);

}

void loop() {
  // put your main code here, to run repeatedly:
    if (Serial.available() > 0) {
        String command = Serial.readStringUntil('\n');
        if (command == "R+") { 
            isGoTo = false;
            RAmotor.setSpeed(1000);
          
        } 
        else if (command == "R-") {  
            isGoTo = false;
            RAmotor.setSpeed(-1000);
            
            
        } 
        else if (command == "D+") { 
            isGoTo = false;
            DECmotor.setSpeed(1000);
            
        } 
        else if (command == "D-") {  
            isGoTo = false;
            DECmotor.setSpeed(-1000);
        
        } 
        else if (command == "RASTOP") { 
            RAmotor.setSpeed(0);
          
        } 
        else if (command == "DECSTOP") {  
            DECmotor.setSpeed(0);
          
        }
        else if (command.startsWith("RA")) {
          long newTargetRA = command.substring(2).toInt();
          targetRA += newTargetRA;
          RAmotor.moveTo(targetRA);
          isGoTo = true;
        }
        else if (command.startsWith("DEC")) {
          long newtargetDEC = command.substring(3).toInt();
          targetDEC += newtargetDEC;
          DECmotor.moveTo(targetDEC);
          isGoTo = true;
        }
    }

  
  if (!isGoTo) {
    if (RAmotor.speed() != 0) {
      RAmotor.runSpeed();
    }
    if (DECmotor.speed() != 0) {
      DECmotor.runSpeed();
    }
  } else {
    if (RAmotor.distanceToGo() != 0) {
      RAmotor.run();

    }
    if (DECmotor.distanceToGo() != 0) {
      DECmotor.run();
    }
    

  }
}

Serial.readStringUntil('\n'); will block until a timeout (1s by default) if the \n is not received

what is sending the Serial commands ?

And how often is it sending?

Show us what you mean by 'crashes' put any serial output in code tags.

In general, if all your "if" testes are mutually exclusive, there is no need for the "else" stuff. Get rid if it and just use the "ifs" by them selves.

In general this is a bad advice.

Not only the "else" clause helps a lot when you have mutually exclusive tests (as you don't evaluate all the other options once you've met one condition) but in this case it's all the more needed as they are not mutually exclusive and order matters.

Since the OP did not bother to track his logic, where did you find the problem?

I read the code...

for example testing first for "RASTOP" or "DECSTOP" before checking if a command starts by "RA" or "DEC" which would mean there is an expected parameter after the command, read by toInt().

Without the else, RASTOP would also trigger the "starts by RA" criteria and parsing the int would lead to an issue in the code (reading 0 and seeing isGoTo to true).

So order does matter and the else are critical.

This is what happens

    Serial.println("DEC");
    Serial.println(DECmotor.distanceToGo());
    Serial.println("RA");
    Serial.println(RAmotor.distanceToGo());
RA
-1542
DEC
-4762
RA
-1541
DEC
�

Rewrite to use switch case style it will be easier to understand and modify.