SKR 1.4 i dylemat firmware Klipper czy RRF

[Pjoter]

RRF obsłuży kinematic bed???

A czym jest kinematic bed? Z ciekawych funkcji to RRF ma true bed leveling - mierzy stół przy śrubach trapezowych i wyrównuje je względem siebie (a nie tylko niweluje różnice poprzez jeżdżenie osią Z podczas druku).

[artur_n]

RRF obsłuży kinematic bed???

W klonie Prusy?

Podstawowa zaleta to jak chcesz coś zmienić to nie musisz od nowa kompilować jak w Marlinie. Zmieniasz, restartujesz i działa.

no ale rrf masz ten sam koncept "config as a code"

Tak ale zadałeś pytanie Marlin vs Klipper

[morf]

No tak ale jednak w kontekście tego wątku

[Mati]

Ja też +1 dla RRF. Ma wszystko co potrzeba, bez potrzeby pi

[artusiek]

Przyznam , że nie wiem co mam zdecydować . RRF jest OK . Ale gdzie nie spojrzę to Klipper jest polecany ( nie ma go tylko w Żabce ) .
Dodatkowo mam BTT LCD 3.0 ... Klipper ( a przynajmniej nie potrafię znaleźć ) tego nie obsługuje , RRF już tak .
Ale mając RRF w corexy z DuePanel może ze 2-3 razy z niego korzystałem , znaczy z panelu .
RRF mniej więcej ogarniam i działa dobrze , Klippera nie znam , ale bardzo kusi ...
Dokupiłem czujniki akcelerometru ( 2 wersje - pod RRF i pod Klippera - kiedyś się przydadzą ) - tylko nadal nie wiem czy w kinematyce Prusy akcelerometr w ogólne ma sens . W naprawianym hypercube pewnie założę (swoją drogą to moje hypercube to trochę jak pierwsze auto mojego taty ... więcej naprawiane / poprawiane niż używane do jeżdżenia) .
To co mi się nasunęło :
na Plus dla RRF
1. SKR 1.4T sam sobie dobrze poradzi bez Pi , boli tyklo transmisja przez ESP8266 ... trochę wolna
2. RRF znam ( tylko podstawy , ale działa )
3. Akcelerometr ( o ile ma sens ) zadziała .
Na minus
1. Raspberry Pi .... do pudła
2 . no sam nie wiem ... nowość goni nowość , a stere do pudła
Na plus dla Klippera
1. Klipper bardzo kusi ... trochę jak nowa zabawka
2. ładny interfejs www ( ale jest bez znaczenia użytkowego )
3. Przesył plików i szybkość www ...
4 posłuży do nauki ... octopus 1.1 czeka na instalację w hypercube ,a Marlina jakoś nie chcę ....co poprawka - kompilacja
5. Akcelerometr ( o ile mam sens ) zadziała .
Na minus
1. Nowość dla mnie ...
2. SKR będzie się nudził ... aż żal taki procek marnować ... może jakoś go do SETI podpiąć ?
3. nie obsłuży BTT LCD ... i co mam go do pudła schować ? ( kilka LCD i innych gratów już tam leży )
4. znowu będę prosił o pomoc na forum ... czyli więcej stoi niż drukuje ... trochę jak hypercube - a tego chciałem uniknąć

Jest jeszcze wersja Klippera z interfejsem RRF , ale już chyba pełna korba

Idę przespać temat ....

[sobal]

Z moich uwag:
1. Klipper to tylko firmware, potrzebujesz do niego frontendu - chyba, że chcesz edytować pliki konfiguracyjne z poziomu shella, co też da się zrobić. Możesz wybrać albo OctoPrint - masa funkcji i pluginów, w tym m.in. pomijanie wybranych fragmentów wydruku, gdy np. jeden z elementów ze stołu się odklei i nie chcesz go drukować, a na stole jest jeszcze kilka dobrych - albo wybrać Fluidd. Jeżeli lubisz RRF to nie masz nad czym się zastanawiać i wybierasz to drugie od razu. Więc pytanie nie powinno brzmieć RRF czy Klipper, tylko Fluidd czy OctoPrint.
2. Implementacja ADXL w RRF to wersja bardzo podstawowa w porównaniu do Klippera.
3. ADXL nie tylko można, go trzeba instalować.
4. Klipper na RPI będzie znacznie bardziej responsywny i wydajniejszy niż RRF na SKR.
5. @Pjtorer, true bed leveling, w Klipperze nazywa się to z_tilt_adjust. W konfiguracji definiujesz sekcję z_tilt, gdzie ustawiasz na stole dwa punkty (dwa, gdy masz dwa steppery dla Z) leżące jak najbliżej śrub i odpalasz komendę z_tilt_adjust.Klippera, nie ma co porównywać.