add rrf3 option #2

Closed Alex9779 closed 1 year ago

I added the option to select RRF3+. No idea if I missed something somewhere and I hope I chose resonable values. Maybe you want to integrate, I published a test build on my private GitLab Docs instance: https://3d-printing.docs.alitecs.de/pa-calibration-tool/pa-calibration-tool/index.html

I did one print so far and it seems to work just fine: IMG_0078 (1)

Thanks for the contribution, I'll take a look soon

Hopefully my bodgy beginner's JavaScript wasn't too confounding :)

Well after your reorg it doesn't merge easily :D

Heh, yeah, still changing things around a lot. The new tuning guide site has sent me into overdrive

I rebased on your reorg, should be fine again...

nope it is not, changes some links to the scripts wrong... Going to fix...

now it seems to be fine, also updated link to my test deployment in the first post...

Testing this out and making some edits in the rrf3_test branch.

Question - can RRF3 not just do T[TOOL_INDEX] and then the following gcodes will assume that tool? Just hoping to simplify that M568 in the start g-code a bit. If I'm understanding the docs correctly, I think that's the case.

Also - the end gcode you had was just M0. I changed it to this:

G91      ; Relative XYZ
G0 Z5    ; Move up 5mm
G90      ; Absolute XYZ
M0       ; Stop`

Does that seem like it would work? As far as I can tell, M0 turns everything off, right? Does that include the part cooling fan?

And is there a way to restore the user's previous PA value in the end gcode? With Marlin you load from EEPROM, and with Klipper you issue a RESTART.

(I have never used RRF, so I'm having to poke through their docs)

Question - can RRF3 not just do T[TOOL_INDEX] and then the following gcodes will assume that tool?

Hmmm not really sure if that is the case for that special M command, I am using that one because normally I also set standby temperatures and this is not possible with the commands implemented for compatibility with other firmwares.

Also - the end gcode you had was just M0.

Yep because you can overwrite that with a 'stop.g', mine looks like this:

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
T-1

M568 P0 A0 ; disable hotend
M140 S-273.1 ; disable bed heater
M106 P1 S0 ; disable part cooling fan

M98 P"/sys/maintenance.g"

deselecting the tool with 'T-1' triggers 'tfree0.g':

; tfree0.g
; called when tool 0 is freed
;
G92 E0                         ; zero the extruder
G1 E-18 F800                   ; retract filament from meltzone

and 'maintenance.g' contains:

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
    G28 ; home

var centerx = move.axes[0].max / 2

if move.axes[2].machinePosition < 50
    G1 X{var.centerx} Y0 Z50 F10000
else
    G1 X{var.centerx} Y0 F10000

But I agree, some generic code lifting the nozzle might be better for publishing...

You are right: Pnnn Tool number. If this parameter is not provided, the current tool is used.

And is there a way to restore the user's previous PA value in the end gcode? With Marlin you load from EEPROM, and with Klipper you issue a RESTART.

Normally values are not stored, M500 'stores' some in a 'config-override.g' which you can load with M501 which can be part of 'config.g'. But I don't find anything that PA values are stored.

You'll need to add an M116 after the M568 to wait for the hotend temp to stablisise PA values also aren't stored with M500. If you want to restore the previous value you could create a variable in the start gcode and grab the value from the object model, then restore it at the end

You'll need to add an M116 after the M568 to wait for the hotend temp to stablisise

Not if you add 'A2', see https://docs.duet3d.com/User_manual/Reference/Gcodes#m568-set-tool-settings

You'll need to add an M116 after the M568 to wait for the hotend temp to stablisise

Not if you add 'A2', see https://docs.duet3d.com/User_manual/Reference/Gcodes#m568-set-tool-settings

from the notes of M568

Temperatures set with M568 do not wait for the heaters to reach temp before proceeding. In order to wait for the temp use a M116 command after the M568 to wait for temps to be reached.

sigh you are right, I don't know my own config :P

'A2' just activates that state...

I have M116 P0 in my tpost0.g. My machine is configure to be pretty much failsafe for preparing the machine before printing. My start gcode in the slicer just calls a macro just like it is in Klipper, which sets needed parameters, everything else is done on the machine...

Maybe it would be simpler to just use M109? They say it's technically deprecated but still works

No idea, do what you think is best for newcomers, I tried to change most of the commands to RRF style, though I skipped the accelerations too because in the native commands they are in a different unit.

Actually I just created that to provide the same options as you do for Klipper, I use the last option with the parametrized macro and let my config do the rest...

I will make the M109 the default, and only one that shows up in the error, but will not show the error if someone puts M568

Ok I think it's almost there. (in the rrf3_test branch) Can you please double check the start/end gcode makes sense for all 3 options and run another test print? You don't have to host it anywhere, you can just open index.html locally

Looks good to me, but running the "simple" modes won't work on my machine because of the things which have to be done before I covered with my macro, gantry leveling, auto Z, purging but as you do it for Klipper those are just starting points which have to be adjusted to the specific setup someone implemented...

Looks good to me, but running the "simple" modes won't work on my machine because of the things which have to be done before I covered with my macro, gantry leveling, auto Z, purging but as you do it for Klipper those are just starting points which have to be adjusted to the specific setup someone implemented...

Can you give me a list of the important g-codes you know of? Gantry leveling etc I will throw them in the canned manual gcode, commented out

Actually this is not so intuitive as with Klipper, the docs have tutorials how to do but but as everything is GCode in RRF my QGL looks like this and is covered in 'bed.g' which is called if you call G32:

; Gantry levelling
G30 P0 X10 Y35 Z-99999 ; probe near a leadscrew
G30 P1 X10 Y135 Z-99999 ; probe near a leadscrew
G30 P2 X140 Y135 Z-99999 ; probe near a leadscrew
G30 P3 X140 Y35 Z-99999 S4 ; probe near a leadscrew and calibrate 3 motors

You basically have to write your own homing macros for each axis and one that covers all axis at once... It is not like Klipper where you have builtin macros which just consume some standardized settings for common tasks.

i would just leave it as calling G32 for bed levelling

On Fri, 2 Dec 2022 at 20:47, Alexander Leisentritt @.***> wrote:

Actually this is not so intuitive as with Klipper, the docs have tutorials how to do but but as everything is GCode in RRF my QGL looks like this and is covered in 'bed.g' which is called if you call G32:

; Gantry levelling G30 P0 X10 Y35 Z-99999 ; probe near a leadscrew G30 P1 X10 Y135 Z-99999 ; probe near a leadscrew G30 P2 X140 Y135 Z-99999 ; probe near a leadscrew G30 P3 X140 Y35 Z-99999 S4 ; probe near a leadscrew and calibrate 3 motors

You basically have to write your own homing macros for each axis and one that covers all axis at once... It is not like Klipper where you have builtin macros which just consume some standardized settings for common tasks.

— Reply to this email directly, view it on GitHub https://github.com/AndrewEllis93/Pressure_Linear_Advance_Tool/pull/2#issuecomment-1335829188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBRT7WDZJ2PTR25FWV3WLJN57ANCNFSM6AAAAAASQ3XDWU . You are receiving this because you commented.Message ID: @.***>

If you are curious, my config for my Voron 2.4 150mm spec is here on GitHub: https://github.com/Alex9779/Voron-150-Config

i would just leave it as calling G32 for bed levelling

you can, but what that does depends on the specific config, it also can do nothin if 'bed.g' has no content...

nothing is fine. 99.9% of people doing bed levelling will use G32. if someone wants levelling but don't use it, they would be savvy enough to change their start gcode. and is it worth change G29 to G29 S1 (i know its commented out, but again, most people will just load a premade heightmap)

On Fri, 2 Dec 2022 at 20:50, Alexander Leisentritt @.***> wrote:

i would just leave it as calling G32 for bed levelling

you can, but what that does depends on the specific config, it also can do nothin if 'bed.g' has no content...

— Reply to this email directly, view it on GitHub https://github.com/AndrewEllis93/Pressure_Linear_Advance_Tool/pull/2#issuecomment-1335833253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBWEFXOWIPBCIMWE623WLJOJJANCNFSM6AAAAAASQ3XDWU . You are receiving this because you commented.Message ID: @.***>

Ya, I think configuring RRF for a machine without experience and no preset for a premade printer like a Caribou3D is nothing for a beginner. Dealing with only GCode is challenging, it took my a lot of evenings and nights to get it working and robust so that everthing works even if you do something out of a normal workflow. So expect someone coming to the site using it for RRF to know his machine at least so much that he is able to customize it so it will run on his machine.

and is it worth change G29 to G29 S1 (i know its commented out, but again, most people will just load a premade heightmap)

I have a personal conquest against saved meshes, hate the things, heh. I will throw G32 in there. One thing I'm confused about - does G32 usually contain G29? Or should I put both?

expect someone coming to the site using it for RRF to know his machine at least so much that he is able to customize it so it will run on his machine.

You overestimate people, hah. The sheer number of Klipper folks with overly complex setups / variable passing junk that have no idea how it works or what they did...

a default bed.g file from the config tool (which is called by G32) contains G29. so unless the end user has changed it, G32 will call G29

On Fri, 2 Dec 2022 at 21:14, AndrewEllis93 @.***> wrote:

and is it worth change G29 to G29 S1 (i know its commented out, but again, most people will just load a premade heightmap)

I have a personal conquest against saved meshes, hate the things, heh. I will throw G32 in there. One thing I'm confused about - does G32 usually contain G29? Or should I put both?

expect someone coming to the site using it for RRF to know his machine at least so much that he is able to customize it so it will run on his machine.

You overestimate people, hah. The sheer number of Klipper folks with overly complex setups / variable passing junk that have no idea how it works or what they did...

— Reply to this email directly, view it on GitHub https://github.com/AndrewEllis93/Pressure_Linear_Advance_Tool/pull/2#issuecomment-1335850499, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBTZFM3INSLOZFGI2XLWLJRB7ANCNFSM6AAAAAASQ3XDWU . You are receiving this because you commented.Message ID: @.***>

Ok added G32 (and a ~~g29~~g28 Z after, just in case). I think I'm happy with where it's at, if you guys agree with that, I will merge

looks ok to me

On Fri, 2 Dec 2022 at 21:23, AndrewEllis93 @.***> wrote:

Ok added G32 (and a G29 Z after, just in case). I think I'm happy with where it's at, if you guys agree with that, I will merge

— Reply to this email directly, view it on GitHub https://github.com/AndrewEllis93/Pressure_Linear_Advance_Tool/pull/2#issuecomment-1335857117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBQX723UN46LIYSJKGLWLJSE3ANCNFSM6AAAAAASQ3XDWU . You are receiving this because you commented.Message ID: @.***>

Ok I'm a bit inept at GitHub, I assumed that merging it to master from my test branch would consider this PR "merged" but apparently not

Anyway, just released into the wild! Your commit shows up in there, not entirely sure what I did wrong 🤷

This PR was against master because you had no other branch when I opened it, we should have rebound it to your new branch but I am also not absolutely sure what the correct workflow would have been...

AndrewEllis93 / Pressure_Linear_Advance_Tool

add rrf3 option #2