Page 1 of 1

New layer gantry exceeds end stops

Posted: Fri Feb 19, 2021 4:47 pm
by crisiM
If new layer is detected, "move gantry out of the way" exceeds end stops and crash. There must be an error in my gcode, but i can not figure it out.
Printing works well, just for one layer.

I print 2 times over each line. Tried it with/without Z<mm> for each G1 command.

Code: Select all

G1 Y65.12 Z0.00 D1
N0 X84.50 T1
N1 X85.00 T1
N1 N0 X95.25 T0
G1 Y65.12 D1
N0 X84.50 T1
N1 X85.00 T1
N1 N0 X95.25 T0
G1 Y65.12 Z0.10 D1
N0 X84.50 T1
N1 X85.00 T1
N1 N0 X95.25 T0
G1 Y65.12 D1
N0 X84.50 T1
N1 X85.00 T1
N1 N0 X95.25 T0
Many thanks in advance for your help.

Re: New layer gantry exceeds end stops

Posted: Sat Feb 20, 2021 11:22 am
by dragonator
The movement of the gantry out of the way is handled in the firmware, not in the Gcode. There is not really any data in the gcode which moves the gantry. You modified this firmware to handle a single feed piston? Can you either share what you changed or attach your current firmware? I can then take a look at why it moves beyond the limit.

Re: New layer gantry exceeds end stops

Posted: Mon Feb 22, 2021 8:50 am
by crisiM
Now i use both pistons.
I changed the markforged kinematics to coreXY, using "HyperCube Evolution"
I only changed Step_X() and Step_Y. My CoreXY has the same behaviour as your markforged kinematics.

Code: Select all

void Step_X()
{
  if (X_enabled == 1)
  {
    digitalWrite(X_motor_step, 1);
    digitalWrite(X_motor_step, 0);
    boolean tmpY_dir = Y_dir;
    Set_Y_direction(X_dir); // CoreXY -> both axis need to move for straight X movement
    digitalWrite(Y_motor_step, 1);
    digitalWrite(Y_motor_step, 0);
    Set_Y_direction(tmpY_dir);
    if (GHomed == 1)
    {
      if (X_dir == 1)
      {
        X_step_pos++;
      }
      else if (X_dir == 0)
      {
        X_step_pos--;
      }
    }
  }
}

void Step_Y()
{
  if (Y_enabled == 1)
  { 
    digitalWrite(Y_motor_step, 1);
    digitalWrite(Y_motor_step, 0);
    digitalWrite(Y_motor_step, 1); // CoreXY-> if only one axis move, diagonal movement, multiply by 2 to get same distance as in markforged-kinematics
    digitalWrite(Y_motor_step, 0);
    if (GHomed == 1)
    {
      if (Y_dir == 1)
      {
        Y_step_pos++;
        X_step_pos++;
      }
      else if (Y_dir == 0)
      {
        Y_step_pos--;
        X_step_pos--;
      }
    }
  }
}
It looks like, that the printer is loosing the position when entering "void New_layer(int NL_X_target, int NL_Y_target, int layer_thickness)".
Homing works, but when new layer the gantry tries to move behind the endstops.
Am i right: G1 Y65.12 Z0.10 D1 -> this line triggers "New_layer(<NL_X_target>, 65.12, 0.10)"?

Re: New layer gantry exceeds end stops

Posted: Mon Feb 22, 2021 11:27 am
by dragonator
Changing the kinematics will probably be the cause of the issues. This code is not really designed for easy kinematics changes.

Step X and Step Y do not really handle the kinematics, they handle the movement and position of the motors for X and Y. This is why you do not see a compensation for the actual steps, but simply see that Y also changes the current X position. In any movement function I calculate how many steps I need to set, and the delay between each step. This takes into account that Y also influences X.

I will assume that you have pure coreXY machine handling this. Any linear movement requires both motors the turn at the same speed, either in the same direction or in opposite directions.

Pure CoreXY is different in that Y influences X, but X also influences Y. You cannot perform 2 steps on Step_Y in one call, this makes the motor driver step twice, and then delay, which it is not designed to handle. You can only change which "X_step_pos--;" and "Y_step_pos--;" are set. The function is designed to simply step a motor and log the position, not to correct the kinematics themselves. From what I understand of coreXY, one of the motors makes both x and y ++ or --, and the other motor makes x++ and y--, or x-- and y++. Which is which depends on how you set your system up. Step X and Step Y should only handle a single step for their respective motor.

In tab "movement" around line 328, line "//calculate step delay times" the movement towards the endstop is determined. X direction was already set in line 279. In my kinematics only X needs to move to move X, but in your kinematics Y also needs to move.

In line 406 "//Y-step target" you see what you need to do more. Here you see both X and Y movements. Here is set both motors and both directions. In line 479 you see the actual steps being made. Something like this is also needed at 328 and within any block that has a "if (micros() - G_target < 10000000)"

I also cannot guarantee that in the "gantry_update", "gantry_set_target" and "X_start" everything will continue to work. Printing is done through "X_constant_movement".

I am sorry that this will not be this simple, but Plan B was not designed for this, and changing kinematics properly will not be as simple as adding 3 lines.