Add G0, G90, G91

[IhorNehrutsa]

No description provided.

[CAP1Sup]

This needs acceleration calculations. All linear movement commands support acceleration and jerk. We'd probably just be best to steal reference code from a project such as Marlin. That way, the code we're getting is known to work. I was going to add this, but I was concerned with the work of acceleration control

[IhorNehrutsa]

Ready for merge

[CAP1Sup]

We need acceleration control for G0. With G6, it doesn't matter, as that command is supposed to just execute the steps without caring. However, G0 needs acceleration. We need to have some kind of planner implemented on the step schedule timer that helps to ensure that the correct rates are being used

[CAP1Sup]

It shouldn't reset the default rate every time. scheduleSteps will handle the rates

[IhorNehrutsa]

https://marlinfw.org/docs/gcode/G006.html

[R]	Step rate per second. Last value is cached for future invocations.

It will use the previous rate value

                int32_t rate = parseValue(buffer, 'R').toInt();
...
                if (rate <= 0) {
                    rate = motor.gm_code.rate;
                }
                else {
                    motor.gm_code.rate = rate;
                }

[IhorNehrutsa]

I agree about the acceleration, but I propose to make it in another PR.

[CAP1Sup]

I have some changes to finish up and push, then I'll merge

[CAP1Sup]

Needs M92 and flash saving of steps/mm. I'll do it over the weekend (hopefully). Steps/mm should be float

[CAP1Sup]

Just needs M92 now

[IhorNehrutsa]

It will be well if the rate in Hz or the feedrate in deg/m or mm/m is possible.

G0 [R1000 | F10] A123.45

[CAP1Sup]

It will be well if the rate in Hz or the feedrate in deg/m or mm/m is possible.

G0 [R1000 | F10] A123.45

I'll add that back then

[CAP1Sup]

I think that we should hold off on the movement gcode for now, just because we have a lot of work to do in the features already implemented. The step correction is still lacking, which I think is the highest priority after the minor step loss issue.

[jlmxyz]

please have a look at the comment on top of parser.cpp in #120, I wanted to perform the same but allow "broadcasting" of move commands on CAN and have the motor select what it requires :

   //  - G20 (ex G20) - set unit to inches
   //  - G21 (ex G21) - set unit to mm
   // - M92 (ex M92 X87.489 Y87.489 Z87.489 E1:34) - Set axis_steps_per_unit
   //  - M579 (ex M579 X1.0127 Y0.998) Scale Cartesian axes (to have motor handle only X commands M579 X1 Y0 Z0)

=> this allow to configure the motor to be able to compute the required move according to it's settings (hardware angle, microstepping and if the Z axis is for example 45deg instead of 90 (for endless printers....) as well it can be used to have the motor ignore information it don't require (for example a X motor don't care about Z move but if the command is broadcasted (for bus efficiency and avoid having to have a master that know what CAN ID is assigned to what axis....) this allow the motor to know what is the information it need to perform the move

   //  - M400: Wait for current moves to finish
   //  - M410: Quick-Stop
   //  - M1000 (ex M1000 234667211432) set or get time information in nanoseconds, not related to an "absolute time" like 2022-05-18 21:03:54.123456, but like a relative time reference
    //  -         setting time can allow slave to compute local clock drift and eventually correct clock settings, getting time will allow master to compute clock drift of slaves and 
    //  - M1001 (ex M1001 234667219999) wait for time - continue move commands processing only after this time others commands are still processed

for synchro >=1000 are non standard but can be used to compute clocks drifts and fix clocks of multi drivers system (needed if distributed motor system)

    //  - M575 (ex M575 P1 B57600 S1) Set serial comms parameters
for allowing to use a stepper as a serial to CAN bridge and use 3Mb/s serial....