G0 is always at max X speed!

[arcimede]

Hi My bid 3D printer was working just fine since we correctet the overflow issue. But it it was verry noisy! So i tried to change the microsteps (that needs to recompile the firmware) with no success... Then I made a PCB to fit an TMC2210 module. That made the printer running much smoother, BUT the disturbing noise was still there. Even changing the traveling speed without printing did not make any difference! So I analized the Gcode wit the result, that printing is done with G1 commands and moving with G0 commands... Then I was going to put mover manually, and G0 commands were always don with a very high speed! Looking at the gcode_process it is written that G0 and G1 commands are the same! BUT that is not the case; G0 commands are done with backingup the F-speed replacing it with X-maxspeed! That is stupid! Because of: a) this is deleting the possibility to handle the moving speed by the user. This can be important for different reasons! and b) maybe the other axes do not have the ability to move as fast as the X-axes (i.e. Z) and the system will never work fine or only limited...

Solution: comment the lines in the G0 process routine:

    switch (next_target.G) {
        case 0:
            //? G0: Rapid Linear Motion
            //?
            //? Example: G0 X12
            //?
            //? In this case move rapidly to X = 12 mm.  In fact, the RepRap firmware uses exactly the same code for rapid as it uses for controlled moves (see G1 below), as - for the RepRap machine - this is just as efficient as not doing so.  (The distinction comes from some old machine tools that used to move faster if the axes were not driven in a straight line.  For them G0 allowed any movement in space to get to the destination as fast as possible.)
            //?
    temp_wait();
            //? backup_f = next_target.target.F;            NO SPEEDUP -> its noisy!
            //? next_target.target.F = MAXIMUM_FEEDRATE_X * 2L;
            enqueue(&next_target.target);
            //? next_target.target.F = backup_f;
            break;

        case 1:
            //? --- G1: Linear Motion at Feed Rate ---
            //?
            //? Example: G1 X90.6 Y13.8 E22.4
            //?
            //? Go in a straight line from the current (X, Y) point to the point (90.6, 13.8), extruding material as the move happens from the current extruded length to a length of 22.4 mm.
            //?
    temp_wait();
            enqueue(&next_target.target);
            break;

So G0 and G1 are working the same way!

I hope sombody adjust this here in the correct way

Jörg (arcimede)

[phord]

I agree it's weird. But the code documents it this way, as shown in your issue report.

        //? G0: Rapid Linear Motion
        //? --- G1: Linear Motion at Feed Rate ---

And the RepRap wiki also spells out the distinction. Then it mentions that the RepRap firmware treats them as the same command since it's not able to do otherwise.

If your G0 motion is "too noisy", maybe it is because your MAXIMUM_FEEDRATE_X is too high. Did you try lowering it?

I don't know if anyone relies on this weird G0 behavior, but I don't want to accept your patch as-is simply because they might and this would be a regression. I think I would accept it if the behavior was optional and controlled by something like // #define G0_USES_FEEDRATE. Then you could choose to disable "weird G0 mode" by uncommenting the #define in your personal config file.

Don't forget to add it to the config tool, also.