CAP1Sup / Intellistep

A rework of the terribly coded firmware from the BTT S42B v2 boards
GNU General Public License v3.0
45 stars 10 forks source link

Add G0, G90, G91 #88

Open IhorNehrutsa opened 3 years ago

CAP1Sup commented 3 years ago

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 commented 3 years ago

Ready for merge

CAP1Sup commented 3 years ago

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

IhorNehrutsa commented 3 years ago

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

CAP1Sup commented 3 years ago

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

CAP1Sup commented 3 years ago

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

CAP1Sup commented 3 years ago

Just needs M92 now

IhorNehrutsa commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

please have a look at the comment on top of parser.cpp in https://github.com/CAP1Sup/Intellistep/pull/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....