Pause Print: Move Out of Range (Tool-Changer)
Hi,
I've encountered this problem a few times before, but never knew what the cause was. Now I'm relatively sure what the problem is, but don't know how to fix it in RatOS/klipper-config.
I have a V-Core 500, but added a custom Tool-changer (similar to e3d's tool-changer). Now, I had to set offsets (X,Y and Z) for each printhead in the config, so that the nozzle is actually printing where I want it to print. The problem is that when I call a RatOS macro (e.g.: CANCEL_PRINT, PAUSE, etc...), it wants to move the printhead to a position that it cannot reach, because of the X or Y offset. My question is, if it is somehow possible to make the RatOS macros use the "original, non-offsetted (Z-Probe) Coordinates" instead of the coordinates of the printhead that is currently in use.
I attached an image. You can see that in the dashboard, there are always two values shown for the toolhead position. The smaller one in brackets is the position of my Z-probe. That's also the position that is always used for the min. max. XYZ positions. You can for example see, that there is a 36,5mm offset in Y for the printhead that I used. I could for example move that nozzle to Y=-30 without any problem, because the min. Y coordinate always references the value in the bracket (the one from my z-probe), and at Y=-30, the value in brackets would be [Y=6,5], so no harm. I can however not reach the full Y=500 with the nozzle. And that's causing the problem here. It is good that it doesn't go there, because it would crash.
I've already gotten lost in the klipper config many times and I'm still not sure which "params" are stored when and where. So maybe someone has an idea how to fix oder overcome this issue.
Otherwise I'd have to write all of those fancy RatOS macros from scratch and with fixed XYZ values, that are all within the boundaries for all of my printheads. Would do the job, but is not really sophisticated 😉
16 Replies
because the min. Y coordinate always references the value in the bracket (the one from my z-probe), and at Y=-30, the value in brackets would be [Y=6,5], so no harm.That's not correct. All movements use nozzle coordinates unless otherwise specified, you cannot move to -30 if you haven't set your position_min to -30.
I can however not reach the full Y=500 with the nozzleThen you should change your position_max to the position you can actually reach. If you set up your position_min and position_max correctly to match your physical limits on [stepper_x] and [stepper_y] you shouldn't have any issues. And forget your probe position / offsets. Those are not relevant outside of z_tilt and bed mesh settings.
metropolitan-bronze•16mo ago
Yes, all the movements use nozzle coordinates. But the "non-offsetted coordinates" (is there a better term for that ? :D) are used to see if the physical limits (position_min and max) are reached or not. That's why I can tell my nozzle to move to Y=-30, because the Z-Probe (non-offsetted coordinate) is then still above 0, namely Y=6,5. And that also makes sense, because my printheads are parked at Y=-52 (non-offseted coordinates), which translates to Y=-88,5 in nozzle coordinates.
I set the physical limits for my Z-Probe (which is part of the permanent Toolhead). I mean the physical limits really change with each printhead. So It's not really possible to define physical limits that work for all of the printheads, unless I set them really conservatively. That would then also limit the movement of the permanent toolhead though, when no printhead is attached. But yeah, I can try to do that and see how it works.
Is there any other way of including an if-else statement in the RatOS macros to ask for which printhead is currently in use ? I store that info in a variable anyways, so should be an easy thing to ask. According to that info, the positions for the parking of the prinhtead ("back","front", etc.) could be adjusted to each of the printheads, no ?
for example: if variable_extruder == 1: "back" is defined as X=250, Y=450
if variable_extruder == 2: "back" is defined as X=245, Y=480
I just don't know how to write it in a way that klipper understands me 😄
can we see a photo of the printer?
But the "non-offsetted coordinates" (is there a better term for that ? :D) are used to see if the physical limits (position_min and max) are reached or not.Ah, i know what you're talking about here, you're talking about runtime gcode_offsets not probe offsets. I'm sorry i misunderstood your description. You'd have to subtract the current g-code offsets from any parking positions, since this is rarely what you want in single toolhead mode, it needs to be something multitoolhead specific and at this point RatOS Macro's do not support that.
you can try the idex macros for ratos, all ratos macros are toolhead aware
https://github.com/HelgeKeck/vcore-idex
i am pretty sure, with minimal changes it will work for you as well
and the offset change is working perfectly
compatible with the new ratos 2 beta
only thing you would need to change is the
_SET_OFFSET macro a tiny bit, atm it works with just 2 toolheads, but with an easy change this works for you as well
important is to reset the assign offset when the printer starts, the script does this with the _INIT_TOOLHEADS delayed macro
instead of telling the macro that the offset is applid, you just need to save which toolhead is assigned, this way you can revert the previous setted offset
also improtant is the new printable area variables in ratos
# idex ratos variables
variable_min_printable_y: 0 # prinatable area min y
variable_max_printable_y: 300 # prinatable area max y
variable_min_printable_x: 0 # prinatable area min x
variable_max_printable_x: 300 # prinatable area max x
let me know if you have any questions, i dealed with this stuff the last weeks
this is not a official ratos version, its just ratos macros override
as an example, here is the resume macro:
[gcode_macro RESUME]
description: Resumes the print if the printer is paused.
rename_existing: RESUME_BASE
gcode:
# get current toolhead
{% set ns = namespace(t=printer["gcode_macro RatOS"].toolhead_default|int) %}
{% set toolhead_count = printer["gcode_macro RatOS"].toolhead_count|int %}
{% for i in range(toolhead_count) %}
{% if printer.toolhead.extruder == ('extruder%s' % '' if i==0 else i) %}
{% set ns.t = i %}
{% endif %}
{% endfor %}
# Prime
{% set E = printer["gcode_macro PAUSE"].extrude|float %}
{% if printer['extruder%s' % ('' if ns.t==0 else ns.t)].can_extrude|lower == 'true' %}
G91
G1 E{E} F2100
G90
{% else %}
{action_respond_info("Extruder not hot enough")}
{% endif %}
RESTORE_GCODE_STATE NAME=PAUSE_state MOVE=1
RESUME_BASE
the macros expect that your extruders are namend extruder, extruder1, extruder2,.....
when you do your macros, be careful with save and restore gcode commands, they do reset the applied offset, and depending where you added them in your code in can create these kind of issues
dont ask me how i know that 😬metropolitan-bronze•16mo ago
I can share one in the toolchanger-workgroup later. I'm not sure I am allowed to share all of the currently used printheads, because it's part of a university project and I don't what's confidential and what not. Can share an overview from 2 months ago though, no problem 😉 It's pretty much just a V-Core 3 500 with a prolonged Y-Axis and a Jubilee-ToolChanger mechanism. Currently 4 tools, a fifth one in the making
Yeah I already kind of expected that RatOS is not designed for multi-tool machines 😉 I guess I'll try to adapt some of Helge's code
Wow, you really put some effort into this 🤩
My problem is that I have not yet fully understood all of the RatOS commands or even in general the programming language. That's why some of the macros are still quite hard to read for me. Do you just adjust the offset, or also the position_max and position_min values ? Because I already have something to adjust offsets as in that the nozzle of Printhead 1 is exactly at the same point in space as the nozzle of printhead 2 for a specific coordinate X1,Y1,Z1. My issue really is that some of the offsets are so big (40mm) that when I pause the print or cancel the print, the RatOS macro wants to move the printhead to the "back" or "front", but it fails, because it would be outside of the position_max or position_min. Because position_max and position_min are evaluated based on the "non-offsetted" variables.
If I understand you correctly, you just override these non-offsetted variables, right ? But then my printer would Actually Crash ! Because then it thinks it can go to the "back", but it still physically cannot ! That's why I thought, I need some sort of code that defines the "back" or "front" in the RatOS macros more precisely for each printhead. Or am I thinking something wrong here 🤔 Oh and btw. I don't think I've updated RatOS ever since I've added my custom scripts and commands. If I update, all of my files will be overriden/deleted, right ? So It would make sense to have just one ***.cfg file, where I have all of my printer specific commands and scripts, so I can easily just copy and include that into the main printer.cfg after updating
My problem is that I have not yet fully understood all of the RatOS commands or even in general the programming language. That's why some of the macros are still quite hard to read for me. Do you just adjust the offset, or also the position_max and position_min values ? Because I already have something to adjust offsets as in that the nozzle of Printhead 1 is exactly at the same point in space as the nozzle of printhead 2 for a specific coordinate X1,Y1,Z1. My issue really is that some of the offsets are so big (40mm) that when I pause the print or cancel the print, the RatOS macro wants to move the printhead to the "back" or "front", but it fails, because it would be outside of the position_max or position_min. Because position_max and position_min are evaluated based on the "non-offsetted" variables.
If I understand you correctly, you just override these non-offsetted variables, right ? But then my printer would Actually Crash ! Because then it thinks it can go to the "back", but it still physically cannot ! That's why I thought, I need some sort of code that defines the "back" or "front" in the RatOS macros more precisely for each printhead. Or am I thinking something wrong here 🤔 Oh and btw. I don't think I've updated RatOS ever since I've added my custom scripts and commands. If I update, all of my files will be overriden/deleted, right ? So It would make sense to have just one ***.cfg file, where I have all of my printer specific commands and scripts, so I can easily just copy and include that into the main printer.cfg after updating
no, you have one toolhead thats your default toolhead, for all other toolheads you set the X Y and Z offset, thats it
no need to define min and max for every toolhead, the script takes care of that
and if you make a toolchanger, you should learn GCODE, its not that hard
even better woud be python for that case if i am honest
let me know if you have any questions
also, we have a user who already has a working toolchanger, @psyvision can probably help you out as well
Yea I don't mess around with macros. I use the Klipper_ToolChanger plugin, much easier. For PAUSE I simply just overwrite the RatOS macro with one that just lifts the nozzle 10mm, but it would be trivial to implement offset adjusted parking if needed due to the extra info the plugin gives.
https://github.com/TypQxQ/Klipper_ToolChanger - It's also written by someone who has a Jubilee and runs Klipper
metropolitan-bronze•16mo ago
Thank you guys for the help. I'll have a deep dive into the Plugin and macros then. Btw. I used mostly this (https://github.com/Xonman/JubileeKlipper) as a template for my Tool-Changing commands and macros.
Do you know if there is an overview somewhere of all the parameters that klipper uses ? especially the printer.toolhead.position etc. ? and the "params." ? That's one thing that keeps confusing me. And then I just have to learn to read the Jinja 2 syntax I guess 😉
GitHub
GitHub - Xonman/JubileeKlipper: Klipper configuration for Jubilee3d...
Klipper configuration for Jubilee3d toolchanger using Duet2 & Duex5 hardware - GitHub - Xonman/JubileeKlipper: Klipper configuration for Jubilee3d toolchanger using Duet2 & Duex5 hardware
particularly https://www.klipper3d.org/Status_Reference.html
metropolitan-bronze•12mo ago
Is the
extruder%s part of your code working flawlessly for you ? I adapted that part into my code, but for some reason, it only changes the ns.t to the current active extruder number once. After the following (Tool)-changes, it remains the same. If I don't use a "namespace", but just a normal variable, it never writes the current active extruder number to it. Do you have any idea why ? The only option that is working for me right now is using many IF-statements, e.g.:
I thought your version is way smoother and more sophisticated and shorter, but for some reason it's not working properly for me :/works perfectly for me
maybe bc extruder1 doesnt exsit
normaly the primary extruder is just called extruder
and not extruder1
not sure how you have configured that
metropolitan-bronze•12mo ago
yes, i have 4 extruders: extruder, extruder1, extruder2, extruder3
Sometimes this Jinja syntax really confuses me 😄
yeah, debugging issues is not that easy
i usually put some M118 in the code to know exatcly what happens
maybe @miklschmidt knows a better way to debug
{ action_respond_info("debug message") }
But it's essentially the same thing