Rat Rig Community [Unofficial]•2y ago

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

miklschmidt•2y ago

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 nozzle

Then 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.

automatic-azureOP•2y 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 😄

Helge Keck•2y ago

can we see a photo of the printer?

miklschmidt•2y ago

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.

Helge Keck•2y ago

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 😬

automatic-azureOP•2y 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

Helge Keck•2y ago

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

psyvision•2y ago

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

automatic-azureOP•2y 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

Helge Keck•2y ago

https://www.klipper3d.org/ https://en.wikipedia.org/wiki/G-code

miklschmidt•2y ago

particularly https://www.klipper3d.org/Status_Reference.html

automatic-azureOP•2y 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.:

{% if printer.toolhead.extruder == extruder1 %}
    {% set active_extruder = 1 %}
  {% elif printer.toolhead.extruder == extruder2 %}
    {% set active_extruder = 2 %}
etc...

{% if printer.toolhead.extruder == extruder1 %}
    {% set active_extruder = 1 %}
  {% elif printer.toolhead.extruder == extruder2 %}
    {% set active_extruder = 2 %}
etc...

I thought your version is way smoother and more sophisticated and shorter, but for some reason it's not working properly for me :/

Helge Keck•2y ago

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

automatic-azureOP•2y ago

yes, i have 4 extruders: extruder, extruder1, extruder2, extruder3 Sometimes this Jinja syntax really confuses me 😄

Helge Keck•2y ago

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

miklschmidt•2y ago

{ action_respond_info("debug message") } But it's essentially the same thing

Gaming

Programming

Pause Print: Move Out of Range (Tool-Changer)