RatOS v2.1.0-RC 4 bugs and improvements

[limpid solstice]

Hello,
I recently upgraded my I'DEX 500 to 4.1 and installed the new RC4 also. I have discovered some bugs and I want to share my thoughts about the default settings.

list of bugs I found:

• if the runout sensor of t1 gets triggered, the toolhead t0 moves to the right side of the printer close to t1. this is not the correct parking position for t1. is there a way how to change this? you maybe have to look into the macros. maybe there is a bug or so.
• Load/Unload macro on Klipperscreen are not working

List of improvements:

• It would be good that the printer is not continuing on its own if the Runout sensor recognises filament. triggering the #load macro is ok, but continue the print directly afterwards could lead to potential danger or could cause unneccessary issues. Consider the load procedure faild and the filament is stuck inside the extruder. then the macro continues the print but the toolhead was not ready to do so. you still have your fingers inside the printer and this could cause injuries.
  therefore: please consider to deactivate this behaviour on default. always continue the print by let the customer press the button.

• could you please enable the network manager for the klipper screen? then you can easily find out the IP adress of the printer and you can change the network which could make it a bit easier if you have to change your router or your location.

[small beacon]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[split bobcat]

Re network manager, see this post from Mikkel (the original author and former maintainer of RatOS) #1337061364992180287 message

Re Load/Unload macro on Klipperscreen are not working - please be more specific - what happens, what state the printer was in when you tried, what you expected to happen.

Re the other points - we'll take a look, thanks for the report.

[limpid solstice]

ok, thank you. well.. As far as I know, RatOS is more or less an own OS build around the raspberry bullseye syste. Wouldnt it be possible to just swap the network manager or having another system which could serv as a network manager? that would be great.

Re Load/Unload macro on Klipperscreen are not working - please be more specific - what happens, what state the printer was in when you tried, what you expected to happen.
it simply doesnt work at all. not during idle, not during a runout. neither of the load or unload buttons are working. no matter in which status the printer is.

currently, I am loading new filament with extrude or retract. If I pull the filament out so that the runout sensor detects no filament, i can push it back in and the load macro gets triggered. however, trigger it manually over klipperscrean doesnt work.

[split bobcat]

Ok, so by "not working", you mean that you see absolutely nothing happen when you press the button? No message in the console, no heatup of the extruder, nothing at all? Can you screenshot what you are putting in the TOOLHEAD field, then what happens in the console when you click SEND?

[limpid solstice]

I am talking only about the klipperscreen. I havent checked if it woks on the web UI. The buttons on klipperscreen are definitely not working within the extrude menu. no heat up, no extrude nothing. the side buttons "extrude" and "retract" are working as expected. load and unload are not working.

[split bobcat]

Does klipperscreen ask you for a TOOLHEAD number when you click the button? It's quite possible that built-in buttons like that are not IDEX-aware and just won't work. Other than bundling klipperscreen pre-installed for user convenience, RatOS doesn't do anything else special for klipperscreen or claim to provide a refined/curated klipperscreen experience.

fyi, if you just issue LOAD_FILAMENT on IDEX with no arguments, you'll see this in the console:

[limpid solstice]

no, because you can see which one is selected. there is automatically one toolhead selected. by clicking the other toolhead, the other one gets selected.

however, it was working under RC3. now it isnt anymore under RC4

[split bobcat]

That seems very unlikely. I'm not aware of any relevant changes.

Anyhow, please check the console output, and see what happens from Mainsail.

[limpid solstice]

I used it all the time. now I have to select the toolhead, go to move, set it 25mm off, go back to extrude, click extrude and move the toolhead back to park. before upgrading to RC4 I just clicked load and the toolhead jumped to the side, does its loading (which by the way was a bit too fast) and jumped back to park.

I will check it in 2 hours when the print is finished

[limpid solstice]

RatOS: Please select toolhead! 0 = left, 1 = right toolhead
21:07

it was t0 selected. its asking which toolhead the macro should choose. i guess, there is a little information missing for the macro to work correctly. if the macro already recognises, that the toolhead is active, then it should choose the active toolhead and not asking which one it should select.

by selecting the other toolhead, the macro is also asking which one the macro should choose.

RatOS: Please select toolhead! 0 = left, 1 = right toolhead
21:11

INFO

Learn more about the RatOS Filament Macros
21:11
shaper_type_y:ei shaper_freq_y:53.600 damping_ratio_y:0.100000
21:11
shaper_type_x:mzv shaper_freq_x:44.600 damping_ratio_x:0.100000
21:11
Activating extruder extruder1
21:11
RatOS | IDEX: Selecting T1..```

i guess this is why the bug appears.

[split bobcat]

There is clearly specific intentional logic for this behaviour in that macro that's been there from when it was first committed, as originally authored by Mikkel. I don't consider it to be a bug in RatOS.

Klipperscreen has made some specific implementation choices which are limiting here. Notably, as per their docs, macros named LOAD_FILAMENT and UNLOAD_FILAMENT will be explicitly hidden from the general macro UI, and klipperscreen does not check if these macros accept arguments. That's arguably a klipperscreen bug.

You should be able to create some wrapper macros (eg below) that will show up as macros in klipperscreen, and then you can play with your klipperscreen configuration - but this is beyond what I can help you with. Maybe try #klipperscreen on the klipper discord.

[gcode_macro LOAD_FILAMENT_T0]
gcode:
  LOAD_FILAMENT TOOLHEAD=0

Or more generally:

[gcode_macro LOAD_FILAMENT_OPTS]
gcode:
  {% set toolhead = params.TOOLHEAD|default(-1)|int %}
  {% set temp = params.TEMP|default(220)|int %}
  LOAD_FILAMENT TOOLHEAD={toolhead} TEMP={temp}

[limpid solstice]

Well…. How can this explain that RC3 does work and RC4 doesn’t? There must be something which makes it work in RC3. And this is missing on RC4

[split bobcat]

Feel free to do some debugging/investigation and report back what you find out.

[limpid solstice]

If you can show me the relevant macros implemented in RC3 in comparison with RC4?

[shell dome]

I can confirm that when attempting to use the unload function from klipper screen there is no option to select toolhead or temperature. I tried switching from T0 to T1 on the screen and that worked as expected, but when I pressed unload I expected to see a temperature prompt but got nothing. Also can confirm that when pressing unload on the screen no error pops up, however on the console I get this (see picture)

[limpid solstice]

@split bobcat here is the solution
@shell dome please include this cfg to your printer.cfg and try again. does it work for you?

[shell dome]

Confirmed to work for loading filament, however there's no option to choose nozzle temperature, defaults to 230c (which may be ok in most cases). No change when unloading, still get no action or response on klipper screen but same error in console.

Also confirmed that when selecting T1 for IDEX machines the load filament command works.

[limpid solstice]

yes this is default. its set through this line:
{% set temp = params.TEMP|default(230)|int %}

I have to check if there is an option to preselect PLA/PETG or whatever material. and by selecting a macro first, you preset all the temps. the temps are then written into a variable wich then gets pulled over to this macro. unfortunately klipperscreen is not able to ask you about which temp you would like to have. the only option available would be to have no temp set and you have to set the temp manually

add this to your macro.cfg and the unload macro is working again. also with default temp of 230

[shell dome]

Confirmed working. I did notice that with the unload command the prompt on the screen is what you'd see in console

However with the load filament the prompt says unknown command. Not a big deal, but still a bug

Console still shows correct for both operations

Swapped the screeenshots, my bad

[limpid solstice]

I think the developers can work with it to improve it further. I just compared my RC3 setting with the RC4 setting. I took over the macro from RC3. That was my investigation what @split bobcat told me to do. I am not a programmer and not a macro enthusiast. I simply want to have a suitable workaround^^
@split bobcat can you please take a look and maybe take over that macro to your default settings? and if there is a way for selecting a temperature on klipperscreen or preselect something which activates specific filament settings please let us know.

[shell dome]

I appreciate the help. Good work!

[split bobcat]

The macro in RC3 is identical to the one in RC4. If you customized it in RC3, then you can use your customization with RC4/2.1.0 final.

Changing the behaviour of this macro is trivial, that was never the issue. I've already explained my reluctance to change the behaviour of this macro for all users. And I'm clear that it's not a RatOS bug, it's a design choice - the shortcomings are in klipperscreen, which RatOS does not try to go out of its way to pander to.

Anyhow, you have a workaround for your own use, so it's clearly not a blocking problem. You are welcome to log a feature request issue here https://github.com/Rat-OS/RatOS-configurator/issues so this does not get forgotten. But it's not high priority, and the main impediment to your request moving forward is considering the impact on non-klipperscreen users and if the change is desirable. This touches on my previous point that the current behaviour was clearly explicitly chosen and coded for - it's not an accidental side-effect.

Anyhow, I've spent enough time commenting on this issue now.

[limpid solstice]

Ok thank you for explaining.

However, the t0 still moves to the right side after the runout of t1 gets triggered.

[split bobcat]

Yes, will check the t1 runout behaviour, thanks.

[fierce maple]

Could you please write down the steps to trigger this? Is it during printing?

I just tried replicating and did not occur, but I only homed and pulled out the filament from T1

[limpid solstice]

yes, it appears while printing. the right toolhead (t1) detects a runout. then both toolheads are in park and moving to the front parking position. shortly after reaching this park position the left toolhead (t0) moves to the right side close to t1.

try doing a print with a cube or whatever and let the filament run out during the print. i am sure it then gets triggered.

[fierce maple]

Will do, thanks!

[fierce maple]

Ok, so the print on which this happened to you, was it a single toolhead print or a dual color/material one?

[fierce maple]

On which toolhead should the filament run out?

I tried replicating during a print and pulling the filament out of T1, triggered a park of T0, gantry moved to the front and unload of T0

[limpid solstice]

It was in mirror mode. Sorry, didn’t mentioned it.

The runout was on t1

You can simply cut the filament shortly before the sensor and let the extruder do the rest.

[limpid solstice]

Now I can’t reproduce it anymore. I changed something but I don’t know what I changed. It had nothing to do with any pause or whatever macro but now it’s gone. Maybe it was a RatOS personalised variable 🤷‍♂️

[fierce maple]

So I tried reproducing it just now with the new details, T1 ran out and it parked both toolheads normally, T0 did not move to the right

It moved to the right after I hit Cancel while in the Paused state