rat-os / ratos-configuration Goto Github PK
View Code? Open in Web Editor NEWThe RatOS modular klipper configuration
The RatOS modular klipper configuration
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
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.
please add a inout shaoer toolbaord include to the minjon template
make it possible to use this config:
Bed ADXL connected to MCU
Toolhead ADXL on toolboard
No response
No response
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?
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
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
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
only one configuration for this board/chipset should exist.
N/A, (visible in git repo)
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
.
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
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.
https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/templates/v-core-3-printer.template.cfg#L114 should be Ratos
instead of config
NA
NA
No response
homing_override 'middle' doesn't take into account the probe location, so the z homed middle is not in the middle of bed
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
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.
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.
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 %}
No response
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.
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
NA
NA
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
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.
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.
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.
No response
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?
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
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.
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
When the extruder temperature is already higher than preheat_extruder_temp
, the Macros could be skipped entirely.
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.
No response
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?
Regularly I should step forward in the configuration to
I tried several times and I have still the same issue. It doesn’t matter if I change the browser.
No response
Link in ReadMe (from Github.com) goes to an invalid page
To go to os.ratos.com
Click the link in the Read Me at https://github.com/Rat-OS/RatOS-configuration
No response
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...
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.
Allow for a pre-configuration of the setting CONFIG_INITIAL_PINS of the firmware configuration.
Dropping the auto-builder of RatOS and doing it manually.
No response
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.
No option for Manta M8P V2.0
Can this be added to the config of the RatOS?
No response
No response
User reported same issue on 2 different M8P boards. Possible hardware problem, attempt to reproduce and contact BTT.
suggestion: After a GSTAT error.... you're left with a HOT hotend and no fan to cool it while
executing a restart. Heat creep and probable clogs a result if not there to clear it asap.
Turning that HE fan back on quickly supposedly can be accelerated by having the MCU turn it
back on asap, using the 'initial_pins' setting in 'make menuconfig' and then let Klipper override
that as it starts (processes configs as needed)
see https://discord.com/channels/582187371529764864/859890291591217162/1072355483249279037
and orig Q the Klipper Dev at https://discord.com/channels/431557959978450984/801826273227177984/1072065882811019315
and final clue at https://discord.com/channels/431557959978450984/801826273227177984/1072249552645656708
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.
The page to load a lot faster than it currently does
Im not sure. Its a stock config. just with a lot of use time (438hours)
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.
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.
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
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.
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.
## 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>,
# 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
https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/boards/btt-skrat-10/config.cfg
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.