Will have to change the homing routing to always home unhomed axes, or a G28 with parameters will only partially home the printer and thus put it in an invalid state.

Alhough nobody should edit cfg files provided by this repository, proper newline at the end of file (which is done automatically in any unix system) would be really appreciated.
If nothing, at least to avoid unnecessary diffs like:

--- pp/24v-0.7a-e.cfg	2022-01-05 19:32:14.000000000 +0100
+++ p/24v-0.7a-e.cfg	2022-01-05 19:33:00.000000000 +0100
@@ -6,4 +6,4 @@
 driver_TBL: 1
 driver_TOFF: 3
 driver_HEND: 9
-driver_HSTRT: 7
\ No newline at end of file
+driver_HSTRT: 7

where literaly no config change was made. The very same "error" is shown e.g. here:

In short, non-binary file shouldn't exists without proper newline at the end of file. EOL on every (text) line, including last line, is POSIX standard.

If someone is curious why it is bad, why (text) file with no eol at eof is ... corrupted, here is an example (one of many):
Let's say we have two files.
file_a:

first line of A
second line of A
third line of A

and file_b:

first line of B
second line of B
third line of B

If file_a wouldn't have (proper) newline at the last line, their concatenation (simple cat file_a file_b) would be like this:

first line of A
second line of A
third line of Afirst line of B
second line of B
third line of B

instead of this:

first line of A
second line of A
third line of A
first line of B
second line of B
third line of B

Thank you very much.

P.S.: This might explain better https://thoughtbot.com/blog/no-newline-at-end-of-file

I just managed to replicate the out-of-range motion -- I think what happened was that I did a manual move to max Z and accidentally went out-of-range while hitting the buttons. Once moved back up to the middle somewhere and starting the print, it seemed to start the print moved back in the Y and also hit the maximum Y position while beginning the print. Move out of range: 280.216 370.703 0.704 [1142.580]

I at least know how to avoid it now, but I'm guessing that last M91 in combination with restoring the state after the PRIME causes the XY to run in relative mode.

https://discord.com/channels/582187371529764864/843098069200666634/1039966075447672932

Toolboard's adxl is the same name as mainboard's.

My fix was to change [adxl345] to [adxl345 toolboard] in the ebb's config file.

If acceptable change, ill edit all files and create pull request.

As described inhttps://os.ratrig.com/docs/configuration/macros/ RatOS configuration has park X and park Y parameters for start/pause/end (ex: variable_end_print_park_x), but no "park Z" options.

It would be super useful, particularly for end of prints, I could tell my printer to always park at Z max, or ZMax-10, for example, to make the flex bed i have easier to remove without scraping it against the print nozzle.

Is your feature request related to a problem? Please describe

please add a inout shaoer toolbaord include to the minjon template

Describe the solution you'd like

make it possible to use this config:

Bed ADXL connected to MCU
Toolhead ADXL on toolboard

Describe alternatives you've considered

No response

Additional information

No response

What happened

The RatOS/4pin-fans/part-cooling-fan-25khz.cfg and RatOS/4pin-fans/toolhead-fan-25khz.cfg point to the same pin. The toolhead should be:

pin: 4p_toolhead_cooling_pin
tachometer_pin: ^4p_toolhead_cooling_tach_pin

Looks like the 100kHz config is correct

What did you expect to happen

NA

How to reproduce

NA

Additional information

No response

I updated my configurations, and after doing so my machine failed to home. I was doing screenshots for a review I am writing; but I realized that no matter which way I modified your new script it would not home.

The first axis will home, and then the second one will not even attempt. It will then immediately try to go to half of the max distance, and home the Z axis which results in crashing etc. I reverted to the old configuration and my system will home once again.

What happened

## Expansion ports
  # EXP1 header
  # EXP1_1=PB5,  EXP1_3=PA9,   EXP1_5=PA10, EXP1_7=PB8, EXP1_9=<GND>,
  # EXP1_2=PA15, EXP1_4=<RST>, EXP1_6=PB9,  EXP1_8=PD6, EXP1_10=<5V>,

What did you expect to happen

    # EXP1 header
    EXP1_1=PC13,   # BEEP
    EXP1_3=PC3,    # EN
    EXP1_5=PB1,    # D4
    EXP1_7=PC5,    # D6
    EXP1_9=<GND>,   # GND

    EXP1_2=PF3,   # BTN
    EXP1_4=PC2,   # LCD_NSS
    EXP1_6=PB0,   # D5
    EXP1_8=PC4,   # D7
    EXP1_10=<5V>, # +5v

    # EXP2 header
    EXP2_1=PA6,   # MISO
    EXP2_3=PE7,   # ENCA
    EXP2_5=PE8,   # ENCB
    EXP2_7=PE10,  # SD_DET
    EXP2_9=<GND>, # GND
    EXP2_2=PA5,   # SCK
    EXP2_4=PF7,   # SD_NSS
    EXP2_6=PA7,   #MOSI
    EXP2_8=<RST>, # REST
    EXP2_10=<NC>  # NC
   

How to reproduce

https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/boards/btt-skrat-10/config.cfg

Additional information

No response

Is there a typo in the GCODE macro for LOAD_FILAMENT??
M400e or M400??

[gcode_macro LOAD_FILAMENT]
.
.
.
\# Wait for purge to complete
M400e <<<< Is this correct or should it be M400 ??
M117 Filament loaded!
RESPOND MSG="Filament loaded!"
RESTORE_GCODE_STATE NAME=load_state

Hi, according to official klipper documentation the accelerometer must be installed respecting correct axis

On classic Eva3 mounting, the adxl axis should be remapped by : axes_map: x, y, z (default) to axes_map: x, z, y in RatOS.
In any case is better to warning user about alternative adxl mount

@miklschmidt what do you think?

18:40:56
echo: Firmware binaries compiled successfully! You can find them in the firmware_binaries folder in the machine tab!
18:40:56
Command {compile_binaries} finished
18:40:56
cp: cannot create regular file '/home/pi/klipper_config/firmware_binaries/firmware-btt-octopus-pro-446.bin': Permission denied

if you delete the firmware files before than it works...

Cause unclear, quote from discord:

I got the BTT display to work. I used the config from Fystec Mini 12864 from here: https://github.com/Klipper3d/klipper/blob/master/config/sample-lcd.cfg
But I needed to uncomment the software SPI to get it to work. Rest of the pins are the same as in your config above

Damn. Now when the communication with the steppers is broken. 
Unable to read tmc uart 'stepper_x' register DRV_STATUS
When I disable the software SPI for the display they work fine. But at least I know now that the SPI is missing or misconfigured.

As discussed on Discord, running the fan slowly during the heat-up procedure helps to heat the chamber faster. I do this for all filaments that require more than 85° bed temperature, they need a hot chamber.

[gcode_macro START_PRINT]
gcode:
SAVE_GCODE_STATE NAME=start_print_state
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
G28 ;home
{% if params.BED_TEMP|default(printer.heater_bed.target, true) > 85 %}
M106 S40 ; run Partsfan slow for ABS-like temperatures
{% endif %}
M117 Heating...
M190 S{params.BED_TEMP|default(printer.heater_bed.target, true) }; wait for bed to heat up
M109 S150 ; Wait for extruder to reach 150 so an inductive probe (if present) is at a predictable temp. Also allows the bed heat to spread a little.
Z_TILT_ADJUST ;Adjust bed tilt
G28 ;Home again as Z will have changed after tilt adjustment and bed heating.
BED_MESH_CALIBRATE ; Calibrate bed mesh
G0 X{printer.toolhead.axis_maximum.x -20} Y{printer.toolhead.axis_maximum.y -20} Z0.2 F6000 ; Park in the back and wait for extruder
M109 S{params.EXTRUDER_TEMP|default(printer.extruder.target, true) }; wait for extruder to heat up
M107 ; partsfan off again until Slicer commands it on.
M117 Printing...
RESTORE_GCODE_STATE NAME=start_print_state
M82
G92 E0

The adxl wiring from the diagram doesn't correspond with the pins from the config file.
The config file uses the I/O pins (which works btw :D ), but the wiring diagram utilizes the spi pins.

Hi,
in ~/klipper_config/config/scriptsklipper-mcu-update.sh is:

if [ "$EUID" -eq 0 ]
  then echo "ERROR: This script should not be run as root"
  exit
fi

and this script calls scripts "make-and-flash-mcu.sh".
But any "make-and-flash-mcu.sh" has:

if [ "$EUID" -ne 0 ]
  then echo "ERROR: Please run as root"
  exit
fi

Until Schrödingers "root" will be discovered, this can't be fullfiled.

In my setup for the BTT Octopus Pro 446 board, I have found that the the pins for the fans don't match the diagram.

I guess this could be fixed by generating a new diagram (https://github.com/Rat-OS/RatOS-configuration/blob/master/boards/btt-octopus-pro-446/v-core-3-wiring.png) or updating the pin mappings?

What happened

after first test

What did you expect to happen

d

How to reproduce

d

Additional information

d

What happened

https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/templates/v-core-3-printer.template.cfg#L114 should be Ratos instead of config

What did you expect to happen

NA

How to reproduce

NA

Additional information

No response

Is your feature request related to a problem? Please describe

No option for Manta M8P V2.0

Describe the solution you'd like

Can this be added to the config of the RatOS?

Describe alternatives you've considered

No response

Additional information

No response

Hi Mikkel, as per your request I've moved this issue over here. Thanks for looking into it!

Some users have detachable accelerometers that mount directly to the printer's hotend. Depending on the setup, this can end up closer to the bed than the ABL probe on the carriage, causing a crash if the printer homes after installing the accelerometer.

Currently, even if you have homed the printer beforehand and the printhead's location is known, the printer will still home all axes when the GENERATE_SHAPER_GRAPHS command is run, potentially causing a crash or cable snag.

This is not urgent, but would be a nice change when time allows.

Clearing things like Z Offset, The Mesh and Skew in the END_PRINT Macro might be useful.

SET_GCODE_OFFSET Z=0.00
BED_MESH_CLEAR
SET_SKEW CLEAR=1

Clearing the Skew is recomended in the Klipper Docs

Caveats

Due to the nature of skew correction it is recommended to configure skew in your start gcode, 
after homing and any kind of movement that travels near the edge of the print area such as a
purge or nozzle wipe. You may use use the SET_SKEW or SKEW_PROFILE gcodes to accomplish
this. It is also recommended to issue a SET_SKEW CLEAR=1 in your end gcode.

Keep in mind that it is possible for [skew_correction] to generate a correction that moves the tool
beyond the printer's boundries on the X and/or Y axes. It is recommended to arrange parts away
from the edges when using [skew_correction].

Personally I found I got a move out of bounds type error when I have a skew configuration loaded.

What happened

On RatOS 2.1, I have generated configuration for Prusa MK3S with Einsy board with the following parameters in the wizard:

It has following issues (I've repaired them step by step in the config manually in order to get complete list at once)

1. Option 'points' in section 'quad_gantry_level' must be specified (quad_gantry_level entry in the config is quite pointless there, it can be corrected by removing the entry completely)

2. tmc virtual endstop requires diag pin config
   corrected by adding

[tmc2130 stepper_x]
...
diag1_pin: !x_diag_pin
...

etc also for y, z, e
(note the !, otherwise the toolhead crashes violently)

3. MCU temperature not supported on atmega2560 (necessary to get rid of the [teperature_sensor Einsy] section)

4. Pin 'display_rs_pin' is not a valid pin name on mcu 'mcu' (none of the display pins are defined for Einsy)

5. Pin 'filament_switch_sensor_pin' is not a valid pin name on mcu 'mcu' (again, missing definition of pin names)

What did you expect to happen

The wizard should produce a valid and functional configuration

How to reproduce

As described above

Additional information

The pins are defined in the RatOS/boards/prusa-einsy/config.cfg, that file is not included in the config (I suppose that's the purpose of RatOS 2.1)

User reported same issue on 2 different M8P boards. Possible hardware problem, attempt to reproduce and contact BTT.

What happened

Currently the only settings available extruder temperature sensor is "Hotendthermistor".

But it doesn't work when using PT1000, as it is not setting the proper klipper configuration.

On Octopus Pro, for [extruder] , It is setting :

heater_pin: PA0
sensor_type: PT1000
sensor_pin: PF4
pullup_resistor: 3700

what is not correct.

what's more "pullup_resistor:3700" prevent any override in printer.cfg because klipper doesn't support this setting for MAX31865

What did you expect to happen

On Octopus Pro, for [extruder], It should set :

sensor_type: MAX31865
sensor_pin: PF8
spi_software_sclk_pin: PA5
spi_software_mosi_pin: PA7
spi_software_miso_pin: PA6
spi_speed: 4000000
rtd_nominal_r: 1000
rtd_reference_r: 4300
rtd_num_of_wires: 2
rtd_use_50Hz_filter: True

How to reproduce

Vcore 3
Octopus Pro V1.1
All latest version

Additional information

I would suggest to add in the UI a hotend tempreratur sensor selectbox , to allow the user to chosse the proper sensor chip. And then it would allow to restrict the current Thermistor select box only to valid values for the selected chip.

Is your feature request related to a problem? Please describe

I run a E3EZ together with the BTT Relay which means that i have to pull the PA9 to high on startup of the board to enable the PS_ON pin. When configuring that in klipper it is already too late and the relay has shutdown in the meantime (8 seconds to start is too low as a delay). As the pi is embedded on the board, everything is off by that time then.

When manually changing the config for the firmware to set the initial pin PA9 to high, the relay stays on. But with the next update this would be gone to my understanding.

Describe the solution you'd like

Allow for a pre-configuration of the setting CONFIG_INITIAL_PINS of the firmware configuration.

Describe alternatives you've considered

Dropping the auto-builder of RatOS and doing it manually.

Additional information

No response

Hi,
I believe BTT SKR2 board has mcu STM32F407, not STM32F446 (as defined in "boards/btt-skr-2-429/firmware.config") nor STM32F429 (or what "429" in "/dev/btt-skr-2-429" stands for).

And one small typo in "boards/btt-skr-2-429/config.cfg" where is:

serial: /dev/btt-skr-2-249

EBB installation instructions, getting the board into DFU mode. Please update step 4 to "press and release" to avoid confusion.

When having a fault in the process of Homing with stowable Probes the Z-Axes get's set to a homed status before it actually is homed and therefor when an error occurs in that process is afterwards on homed status in a random height

What happened

When the extruder is already heated over the preheat_extruder_temp temperature, the Macro _START_PRINT_AFTER_HEATING_BED waits until the extruder is cooled down to the pre-heat temperature and then only proceeds (basically to heat up again in my case). See here

What did you expect to happen

When the extruder temperature is already higher than preheat_extruder_temp, the Macros could be skipped entirely.

How to reproduce

Heat extruder over preheat_extruder_temp, then start a print. You will notice that the temperature will drop first while the macros is being awaited. See line at the top for this - which first drops to preheat_extruder_temp and then goes up again.

Additional information

No response

What happened

Installed RatOS 2.1 and immediately had issues with the 5160 drivers. After looking around for awhile, I noticed that the SPI pinouts in the RatOS.cfg are wrong. As of now, the SPI config is:

spi_software_mosi_pin: PC12
spi_software_miso_pin: PC11
spi_software_sclk_pin: PC10

This is wrong and they need to be changed to the following:

spi_software_mosi_pin: PG6
spi_software_miso_pin: PG7
spi_software_sclk_pin: PG8

What did you expect to happen

Get an error when I try to move the X or Y in Mainsail.

How to reproduce

Install and try to move the X or Y in Mainsail.

Additional information

No response

Is your feature request related to a problem? Please describe

Hi all,
on my V-Core i'm currently using an Euclid probe and a physical Z endstop (mounted on bed) in order to use auto z offset plugin.
Everything is working fine except for adaptive mesh and priming.
The three involved macros (PROBE_FOR_PRIMING, ADD_PRIME_PROBE_TO_OFFSET and SUBTRACT_PRIME_PROBE_FROM_OFFSET) use probe offset stored in config files. But since I'm using auto z calibration, I have nothing in configuration file. Macros consider a z_offset of 0 and resets my offset after priming.

Describe the solution you'd like

A quick change (it works for me but can of course be improved) can be to calculate z offset comparing "real" z position and "after offset" z position.
This way the offset obtained using auto z calibration can be used by those macros like an offset in file.

{% if printer.configfile.settings.bltouch is defined %}
{% set x_offset = printer.configfile.settings.bltouch.x_offset|float %}
{% set y_offset = printer.configfile.settings.bltouch.y_offset|float %}
{% elif printer.configfile.settings.probe is defined %}
{% set x_offset = printer.configfile.settings.probe.x_offset|float %}
{% set y_offset = printer.configfile.settings.probe.y_offset|float %}
{% elif printer.configfile.settings.beacon is defined %}
{% set x_offset = printer.configfile.settings.beacon.x_offset|float %}
{% set y_offset = printer.configfile.settings.beacon.y_offset|float %}
{% else %}
{ action_raise_error("No probe or bltouch section found. Adaptive priming only works with [probe] or [bltouch].") }
{% endif %}

may be replaced with

{% set z_position_real = printer.toolhead.position.z|float %}
{% set z_position_calculated = printer.gcode_move.gcode_position.z|float %}
{% set z_offset = z_position_real - z_position_calculated %}
{% if printer.configfile.settings.bltouch is defined %}
{% elif printer.configfile.settings.probe is defined %}
{% elif printer.configfile.settings.beacon is defined %}
{% else %}
{ action_raise_error("No probe or bltouch section found. Adaptive priming only works with [probe] or [bltouch].") }
{% endif %}

Describe alternatives you've considered

No response

Additional information

No response

Many times after a print is done, and enough time has passed, I wish I could just pull out the filament or use thumbwheel on some extruders to unload the filament, but the filament is "stuck" as the hotend has cooled down.

It would be great if the END_PRINT macro can also retract the filament from the hot parts of the hotend. This could be controlled by another user configured variable.
That way we can still change the filament, if needed, without warming the hotend.

And since the RatOS configuration already knows which hotend is in use, the length to retract could be added to each hotend cfg file.

What happened

Looks like the v2.0 release was supposed to rename the RatOS/boards/btt-skr-3-ez configuration to RatOS/boards/btt-skr-3-ez-h723 (see 526a9fb).

At some point though, it looks like the RatOS/boards/btt-skr-3-ez folder managed to sneak back in, and as a result there is a duplicate entry in the configure screen for BIGTREETECH SKR 3 EZ H723.

One of these will cause udev rules to create a symlink for btt-skr-3-ez, and the other will cause udev to create a symlink for btt-skr-3-ez-h723

What did you expect to happen

only one configuration for this board/chipset should exist.

How to reproduce

N/A, (visible in git repo)

Additional information

I would submit a PR to fix the regression (I'm assuming a rebase/merge from upstream or main re-introduced this at some point), but I'm thinking this could adversely affect users who chose the configuration that caused the btt-skr-3-ez symlink to be created.

We'd need to update udev rules for the btt-skr-3-ez-h723 to somehow unlink the btt-skr-3-ez, and then there'd be the issue of what happens if a user has a config include for any of the config files in btt-skr-3-ez.

What happened

You can see on the picture. I have this major problem of clicking the button status update it Won’t go further.
And I will not get any update about the status of the board. Do you have any of this problem or no way to solve it?

What did you expect to happen

Regularly I should step forward in the configuration to

How to reproduce

I tried several times and I have still the same issue. It doesn’t matter if I change the browser.

Additional information

No response

Is your feature request related to a problem? Please describe

A V-core 3 configured through the RatOS wizard to use a Beacon scanner will still use the standard Z-Tilt probing positions that are used with Pinda, BLtouch etc, where the probe is slightly left of the nozzle. These positions do not match where the standard location for a Beacon is, a few mm behind the nozzle.

So it is essentially by default taking readings from around 4 cm away from where it thinks it is, and this error might lead to unnecessary tilt retries.

Describe the solution you'd like

Setting a V-core up with the Beacon through the wizard should automatically override the Z-tilt positions to match where a Beacon probe would be mounted, since their position is as good as standard.

Below are points i use on my VC3.1 400 which work well, for an example.

[z_tilt]
points:
40,20
200,350
360,20

Describe alternatives you've considered

No response

Additional information

This might seem to be a nitpicky suggestion, the Z tilt operation does work despite the error, but also acknowledge that the goal of RatOS 2.1 configurator was that if using common parts, the configurator should be able to automatically generate perfect, functioning config files, and this seems like a further step toward that goal.

What happened

When I load the webpage it takes around 8-20 seconds to load. (Validated on multiple high-end devices). After talking to the Mainsail guys, they said its a RatOS issue as it has to load all the config items before it renders.

What did you expect to happen

The page to load a lot faster than it currently does

How to reproduce

Im not sure. Its a stock config. just with a lot of use time (438hours)

Additional information

What happened

Link in ReadMe (from Github.com) goes to an invalid page

What did you expect to happen

To go to os.ratos.com

How to reproduce

Click the link in the Read Me at https://github.com/Rat-OS/RatOS-configuration

Additional information

No response

the left bed screw is difficult to reach, the two right ones are much easier to access

to make the screw tilt adjust easier and more accessible please make the left screw the base screw

hail rat rig

The defaults in the RatOS macros are great for VCore 3 without an enclosure.
Ex. The default park while heating is in the back.

But accessing the back (Y>300) is hard with the enclosure, even when it is open.

So it would be great to have an overall variable to indicate that an enclosure is installed and then the macros could have different defaults that work better with the enclosure.

What happened

I tried to generate a mesh from the "Heightmap" menu after updating to a Euclid probe, and used the name "Euclid Mesh" which then threw an error that indicates the name is not being quoted properly:

Malformed command 'BED_MESH_CALIBRATE_ORIG PROFILE=Euclid Mesh'

When I rerun with a name that has no space, it works fine.

What did you expect to happen

I expected it to properly encapsulate the profile name with quotes so it doesn't treat the user-provided name as more than one argument.

How to reproduce

Do the stowable-probes thing and then try to generate a mesh from the "HEIGHTMAP" menu using a name that has a space in it.

Additional information

No response

Is your feature request related to a problem? Please describe

No problem but would streamline configuration for those using PT100 or PT1000 and the MAX31865 chip on toolheads or printer boards.

Describe the solution you'd like

To see an option for the MAX31865 in the Hotend Thermistor menu in the configurator. If this is not possible, an option for "none" in the menu would be great so that the MAX31865 can be added manually without any previous config for the Hotend Thermistor.

Describe alternatives you've considered

No response

Additional information

This would be mostly helpful on the toolheads. If anything, implementing this for the toolheads would be helpful as adding this for every printer board might be a more tedious task and not necessary.

Error: Klippy Option 'spi_bus' is not valid in section 'adxl345'

disabling adxl345 in btt-octopus-11 solve the problem.

BTT-EBB42-12 toolboard-config.cfg
[adxl345]
cs_pin: toolboard: adxl345_cs_pin
spi_software_sclk_pin: toolboard: adxl345_clk
spi_software_mosi_pin: toolboard: adxl345_mosi
spi_software_miso_pin: toolboard: adxl345_miso

OCTOPUS-11 config.cfg
conflit with others toolboards cfgs
#[adxl345]
#spi_bus: spi3
#cs_pin: adxl345_cs_pin

log file attached
test with:
enable adxl345 in btt-octopus-11
disable adxl345 in btt-octopus-11

klippy.log

homing_override 'middle' doesn't take into account the probe location, so the z homed middle is not in the middle of bed