Rat-OS / RatOS-configurator

The RatOS Configurator
11 stars 19 forks source link

Prusa MK3S: display_rs_pin is not a valid pin name on mcu #27

Open kronflux opened 3 weeks ago

kronflux commented 3 weeks ago

Using RatOS-v2.1.0-RC2, Prusa MK3S does not generate configuration properly. It is missing definitions for the display and filament sensor. It also assumes, regardless of having selected no accelerometer, that there is an adxl345 controlboard. but tries to use them anyway. Reverting to RatOS-v2.0.2 does not have these issues, after a lot of tinkering and investigating, this appears to be an issue with the configurator.

miklschmidt commented 3 weeks ago

Thanks for reporting! It's likely there's a few issues as we don't have a lot of people testing the mk3s community printer. Can you please provide a debug-zip so i can take a look?

kronflux commented 2 weeks ago

This may be more info than needed, and may need to be added to another issue on one of the other repos, but for reference sake, upon initial installation, if you go to ratos.local, you get a bed_mesh error (I assume due to not having run configurator yet) moonraker.log klippy.log

Upon running configurator, then going back to ratos.local, I get "display_rs_pin" is not a valid pin name on mcu "mcu" moonraker_after_configurator.log klippy_after_confiurator.log

Here is the Debug Zip: ratos-debug.zip

miklschmidt commented 2 weeks ago

The reason is that the mk3 implementation uses non-standard pin aliases that get stripped. I have removed the display and filament sensor includes for now, as we currently don't have a solution for those. RatOS does have a way to manually set up filament sensors however.

That would result in the following, using a Prusa Einsy:

[filament_switch_sensor toolhead_filament_sensor_t0]
pause_on_runout: False
event_delay: 3.0
pause_delay: 0.01
switch_pin: ^!PK0
runout_gcode:
    _ON_TOOLHEAD_FILAMENT_SENSOR_RUNOUT TOOLHEAD=0
insert_gcode:
    _ON_TOOLHEAD_FILAMENT_SENSOR_INSERT TOOLHEAD=0

For the display, you'll manually have to add the following to printer.cfg:

[display]
lcd_type: hd44780
rs_pin: PD5
e_pin: PF7
d4_pin: PF5
d5_pin: PG4
d6_pin: PH7
d7_pin: PG3
encoder_pins: ^PJ1,^PJ2
click_pin: ^!PH6

[output_pin BEEPER_pin]
pin: PH2
pwm: True
value: 0
shutdown_value:0
cycle_time: 0.001
scale: 1000

[menu __filament __load]
type: command
name: Load Filament
gcode:
    LOAD_FILAMENT

[menu __filament __unload]
type: command
name: Unload Filament
gcode:
    UNLOAD_FILAMENT

Note: the above will only work with the Prusa Einsy board.

I have added this to the default printer.cfg generated for the mk3s, so users can uncomment them if they're using the Prusa Einsy, and either leave them or modify them for other boards. The configurator should be ready to be updated in 10 minutes. This is the commit with the fixes: https://github.com/Rat-OS/RatOS-configurator/commit/069dee1e54d8d8b1c5b4470a4479e255cd7da662

miklschmidt commented 2 weeks ago

I have also fixed the bed_mesh error (it only happens on unconfigured printers, but still annoying)

kronflux commented 2 weeks ago

Unfortunately the configurator in this state results in multiple definitions of "PE6" pin, I believe this is due to an invalid pin definition in heater_fan toolhead_cooling_fan, where the pin is set to PE6 as is the tachometer pin. The pin should be PH5, and the tachometer pin should be PE6.

After resolving that, I get "Section 'fan part_cooling_fan' is not a valid config section" which seems to correspond to the generated printer.cfg, where we've used "fan part_cooling_fan" where previously it was simply "fan" although I'm not positive on that one. Here is the debug zip: ratos-debug (1).zip

I liked in the stable release of RatOS where it used a separate cfg file for various things, such as display. A modular approach would be ideal for every component, including filament sensor for each printer, display for each printer, etc

kronflux commented 2 weeks ago

It's also not selecting the correct definition for the pi, in my configuration I have a pi4 hooked up to the printer via USB. In 2.x it detects this and flashes appropriately, and everything sort of just "works" but in RC2 there seems to be a lot of issues. Here's what I'm getting: mcu 'rpi': Starting connect Loaded MCU 'rpi' 119 commands (?-20240727_132503-fv-az659-741 / gcc: (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110 binutils: (GNU Binutils for Raspbian) 2.35.2) MCU 'rpi' config: ADC_MAX=4095 CLOCK_FREQ=50000000 MCU=linux PCA9685_MAX=4096 PWM_MAX=32768 STATS_SUMSQ_BASE=256 Sending MCU 'mcu' printer configuration... Configured MCU 'mcu' (600 moves) MCU error during connect Traceback (most recent call last): File "/home/pi/klipper/klippy/klippy.py", line 135, in _connect cb() File "/home/pi/klipper/klippy/mcu.py", line 742, in _connect config_params = self._send_get_config() File "/home/pi/klipper/klippy/mcu.py", line 728, in _send_get_config raise error("Can not update MCU '%s' config as it is shutdown" % ( mcu.error: Can not update MCU 'rpi' config as it is shutdown Can not update MCU 'rpi' config as it is shutdown ratos-debug (2).zip

I'm happy to test anything you throw at me, I love the idea of RatOS, it's simple, well structured, and the modular approach of 2.x was awesome(albeit a few settings are a bit off, and the printer is incredibly slow), I think the new approach is a bit messy, but I can see it's potential. It would be great to get this all sorted.

FYI the sort of "gold standard" klipper configuration for the mk3s is here: https://github.com/dz0ny/klipper-prusa-mk3s We can also pull a lot of the stock values from here: https://github.com/prusa3d/Prusa-Firmware/tree/MK3

miklschmidt commented 2 days ago

@kronflux i'm sorry i haven't had time to look at this as we've been working on a new post-processor, which ended up having some rather complicated implications. I'll try and get this sorted once it's been merged.

I don't think there's anything wrong with the rpi config (there isn't anything to select), that error you're getting is likely a symptom of another error. Will investigate further when i get back to this!

Regarding the tach pin, the pin definition for the board hasn't changed since 2.0 so there's likely some more unorthodox stuff going on with the old 2.0 config to make it work that i've missed.