reprapy.pl

Wgrałem testowo do Lume
https://github.com/KevinOConnor/klipper

użyłem oryginalnego RAMPSA + raspberry zero wifi

Nawet bez większych problemów zgodnie z instrukcją wszystko odpaliłem. Coś tam jedynie chyba więcej restartów niż jest opisane musiałem zrobić.
Nie trzeba nawet mieć Arduino. sama kompilacja i wgranie firmware przebiega z poziomu Raspberry.

kilka zmian w przykładowym pliku konfiguracyjnym. Od razu zaproponowałem lekkie rozszerzenie opisu i pullrequest na gitthubie, bo nie wszystko było intuicyjne.

Na przykład, że "!" obraca kierunek ruchu

[stepper_x]
step_pin: ar54
dir_pin: !ar55

..... i leci kosmonauta. Faktycznie słychać, że drukarka wydaje na tym firmware inne dźwięki w trakcie druku. Nie ma Jerku. ciekawe.
Widać że jeszcze muszę podkalibrować. Potem się dokładniej poprzyglądam różnicom

Nie ma jerku w sensie że w tym sofcie nie powinno być tak? Bardzo ciekawe.

Wysłane z mojego K10000 przy użyciu Tapatalka

tak. jerk, jak ja rozumiem, jest tylko potrzebny gdy firmłer nie wyrabia z gęstą zmianą, prędkości na początkowym krótkim odcinku ruchu. Jak wyrabia to normalna płynna, dynamiczna akceleracji powinna być lepsza.

W klipperze nie ma czegoś takiego jak jerk.

może wrzucisz jakiś filmik? chętnie bym to zobaczył. Klipper nie ma obsługi LCD? Tego mi trochę brakuje. oczywiście jak najbardziej obsługa wyświetlacza powinna być po stronie Pi

Wysłane z mojego K10000 przy użyciu Tapatalka

nie ma obsługi LCD. inna filozofia. Ekran dotykowy + jakaś apka na raspberry. Patrząc na moje aktualne problemy w HC 1/128 kroku a chce dać 1/256 native na tmc2130. to widzę że to ma sens. Szybsze CPU,32bity niby mam w HC ale co z tego jak go spowalnia obsługa wyświetlacza i najlepsze co można zrobić, to wywalić.

No ale jak by dodać obsługę wyświetlacz może nawet nie do killipera tylko do octoprint. Oczywiście można dotykowy ale mi jakoś się podobają takie monochromatyczne. I dodatkowo tanie to jest. Jeszcze jedna rzecz, ma klipper autoleveling? Jak ostatnio patrzyłem chyba nie było.

Wysłane z mojego K10000 przy użyciu Tapatalka

Mógłbyś opisać jak to zainstalować i skonfigurować? Może jakieś zdjęcia porównanie jakości wydruku?

dragonn pisze:No ale jak by dodać obsługę wyświetlacz może nawet nie do killipera tylko do octoprint. Oczywiście można dotykowy ale mi jakoś się podobają takie monochromatyczne. I dodatkowo tanie to jest. Jeszcze jedna rzecz, ma klipper autoleveling? Jak ostatnio patrzyłem chyba nie było.

Wysłane z mojego K10000 przy użyciu Tapatalka

w zasadzie to bez kombinowania dużo chyba dało by się użyć mks tft

Wreszcie coś nowego

Taka hybryda trochę w sumie... Trochę słabo jakby ten demon klippera sie powiesił albo brakowało zasobów np przez ffmpeg z octoprinta

ale może jakiś nice niski by rozwiązał sprawę.
Fajne czekamy na efekty testów

ffmpeg nie działa przecież w trakcie wydruku, jedynie po jego zakończeniu.

Wysłane z mojego K10000 przy użyciu Tapatalka

jakkolwiek wyświetlaczem na razie się nie przejmuję chce sprawdzić czy:
1. łatwiejszy może być kod w dorobieniu czegoś. Na oko wygląda na mniej linii i bardziej czytelne
2. czy faktycznie jest szybszy
3. czy przekłada się to na jakość druku

jakby co, to nie było nigdzie w przykładach ani doku PIDu dla stołu
mam kanapkę: 3mm korek+MK2b+2mm szkło :

Kod: Zaznacz cały

[heater_bed]
heater_pin: ar8
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog14
control: pid
pid_Kp: 53.40
pid_Ki: 0.56
pid_Kd: 1271.58
min_temp: 0
max_temp: 120

PID tuning działa ale zapisuje wynik w logu /tmp/klippy.log i można znaleźć wynik na przykład tak:

Kod: Zaznacz cały

cat /tmp/klippy.log |grep Autotune

no mogło by być bardziej user friendly ale mniejsza o mniejszość.

Nie odpowiedziałeś co z autolevelingiem

, nie widzę nigdzie nic na github :/.

nie odpowiedziałęm, bo nie mam autolevelingu i nie sprawdzałem.

rafaljot pisze:nie odpowiedziałęm, bo nie mam autolevelingu i nie sprawdzałem.

wiem że nie masz, ale myślałem że mogłeś wiedzieć jakaś opcję.

EDIT

Ok na 99% nie ma jak pisze "Unfortunately the support for z-probe hardware has not been written yet.". Ale podobno ma coś być nie długo

.

o kurde... szkoda że tego nie widzicie. Lume na 200mm/s z napędem bloczkowym , czyli przełożeniem 2:1 i 16u ząbkowych rolkach. (To tak jak by w HyperCube było 500mm/s) i przyspieszenie 3000.
na a4988, na małych silniczkach ze złomu i Arduino Mega+RAMPS. w dodatku cicho jak na lv8729

Ooo nie wpada Ci nic w rezonans

? U mnie łożyska na stole zaczynają wydawać dziwne dźwięki powyżej 100mm/s xD, chociaż może z 200mm/s to znowu przestrzeliłeś daleko poza to

.

nic, cichutko. ale przesmaruje, dawno tego nie robiłem

https://www.youtube.com/watch?v=X2bYn47-snU znalazłem, jedyne chyba na youtube

. Coś czuję że zaraz będę próbował na LUME xD.

rafaljot pisze:o kurde... szkoda że tego nie widzicie. Lume na 200mm/s z napędem bloczkowym , czyli przełożeniem 2:1 i 16u ząbkowych rolkach. (To tak jak by w HyperCube było 500mm/s) i przyspieszenie 3000.
na a4988, na małych silniczkach ze złomu i Arduino Mega+RAMPS. w dodatku cicho jak na lv8729

Movie or it didn't happen

https://www.dropbox.com/s/18hsg8enel3v2 ... 9.mp4?dl=0

rafaljot pisze:https://www.dropbox.com/s/18hsg8enel3v2 ... 9.mp4?dl=0

OMG za to Pi Zero w folio antystatycznej masz mistrza

. A jak to zasuwa

i pomimo tego nie ma jakiś szarpnięć ani nic, jejku mega

.

zauważ, że podniosłem do 300 i przyspieszenie 4000

powtórzę, przełożenie 2:1 i zębatki 16zębów. dla silników to jest tak jak w HyperCube bez przełożenia i 20o ząbkowe by było 750mm/s
Wszystko na Mega2560 i zwykłym A4988

Zauważyłem

. A tak z ciekawości, możesz odpalić top w trakcie wydruku na Pi? Ciekawy jestem ile CPU to bierze.

niemal nic. Całe pi chodzi na 11% z czego chyba procesy kwork to są te od Klippera . odpalone są cztery i każdy poniżej 1%
Octopi jest na pierwszym miejscu

Wha nice

, to cieszy. To jest Zero W co nie?

tak. Zero Wi-fi.

Ok to super bo właśnie go planowałem wziąć, nawet mam już przygotowane miejsce na niego w obudowie RAMPS-a w Evo.

BTW

Korzystając z tego softu myślę że byłby dużo łatwiej ogarnąć TMC2130 - SPI podepniesz pod Pi i na Pi możesz napisać sobie nawet całkiem osobny program do konfiguracji 2130

Widze, ze w ToDo ten firmware ma wpisane zrobienie zabezpieczen przed zle dzialajacym termistorem.
Także radzę ostrożność

Wysłane z mojego ONEPLUS A3003 przy użyciu Tapatalka

"experimental"

Czy trzeba by dużo kombinować aby to zainstalować na laptopie z linuxem?

normalnie to bym odpowiedział że spoko. Jednak skoro zadales takie pytanie to znaczy że raczej sporo kombinowania.

Hmmm jeszcze nie instalowałem ale moim zdaniem tyle samo roboty co instalacji na np. Pi.

no tak. trzeba tylko przeczytać instrukcję instalacji octoprinta i klippera. ew. dodać brakujące pakiety, pewnie od avr-tool-chaina.

Rafał masz jakąś kostkę dla porównania repetier/marlin VS klipper?
Na filmiku lume śmiga nieziemsko

Właśnie, jakieś zdjęcia gotowych wydruków

?

Najlepiej jakąś benchy chociaż żeby nie było że tylko kostki potrafi drukować

Zapowiada się bardzo dobrze, oby było systematycznie rozwijane.

rafaljot pisze:no tak. trzeba tylko przeczytać instrukcję instalacji octoprinta i klippera. ew. dodać brakujące pakiety, pewnie od avr-tool-chaina.

Wrzucisz swoje printer.cfg do LUME? Zaczynam się powoli bawić

.

Konfig w załącznkiu.
coś zepsułem i Klipper nie gada ze swoim firmwarem. Wrrrrr nie wiem co.

Log coś mówi?

żadnego śladu w logu :/

ps konfig dla:
- a4988 czyli 1/16
- silniki 200 kroków, ale bloczki czyli tak jakby były 400 kroków
- ekstruder titan
- standardowa trapezówka skok 8mm.

Kroki dostosować to nie problem, po prostu chciałem mieć całość jak to wygląda na początek

, dzięki.
A port jest widoczny w systemie? Może coś rozłączyło.

jest, ale jakby były błędy w transmisji.

A w dmesg widzisz coś z rozłączaniem USB? Mi czasem LUME rozłącza z octoprint jak podłączam zasilacz stołu lub przekaźnik włącza główny zasilacz, zakłócenia lecą.

zanim wgrasz, chyba że już wgrałeś wydrukuj kostkę. Na przykład tę, tylko 150% boki a 50% wysokość (szkoda czasu)
https://www.thingiverse.com/thing:1278865

na dość dużej prędkości. 80mm/s - 100mm/s

zauważ, że w konfigu coś zacząłem kombinować z tym preasure advence. Powinno być widać róznice na rogach kostki.
Na razie ustawiłęm je tak jak w przykładzie ale na pewno to trzeba dobrać.

Wiem że to trzeba dobierać praktycznie pod każdy typ filamentu, czyli ABS, PET-G, PLA będą mieć inny parametr bo to zależy od sztywności filamentu.

tak sobie pomyślałem teraz, że skoro silniki krokowe wraz ze wzrostem prędkości obrotowej (czy częstotliwości jak inni wolą) mają coraz mniejszy moment,to przyspieszenie nie powinno być stałe, tylko spadać wraz ze wzrostem prędkości. Wtedy można by zacząć od większego przyspieszenia.

Po lewej Marlin, po prawej Klipper. Lume 80mm/s. głowica 0.4, 4 obrysy.

Widać wyraźnie działanie dwie rzeczy:
- działanie preasure advence - mniejsze albo wręcz brak zgrubień na krawędziach
- mniejsze echo dzięki mniejszym wibracjom

Coś popsułem wcześniej trapezówkę, przez co na obu kostkach warstwy nie są równe

No nooo różnica naprawdę niezła. Trzeba zacząć popularyzować ten firmware bo to chyba najlepsze co jest na rynku, ja to wręcz się zastanawiam czy nie napisać gościowi żeby założył patronite czy coś w tym stylu. Mam ochotę go wesprzeć

, popatrzę też w kod może uda mi się coś samemu zrobić ^^, tak ogólnie jak wstępnie patrzyłem to wydaje się to dużo bardziej czytelne niż w Marlinie

dokładnie.

sprawdzisz, czy masz podobne wyniki. Wygląda na prawdę obiecująco.

popatrzcie. Na kostce z lewej wyraźnie widać, że na warstwach, na których nie było Y głowica przesuwała się szybciej i filament wypływał przez to szybciej. W konsekwencji powstaje większa grucha na rogu niż tam, gdzie za Y rozpędziła się mniej bo odcinek krótszy.
Mimo, że to Direct. Głowica leciała od lewej do prawej.
Na Bowdenie pewnie było by bardziej.
Klipper sobie z tym elegancko poradził. Może nawet za bardzo poprawił bo rogi są jakby wklęsłe na tych samych warstwach. Kwestia dobrania parametrów zapewne.

To teraz podstawowe pytanie:

Czy Ramps i atmega pociągną 128 kroków na XY z kliperem?

mysle ze tak

rafaljot pisze:tak sobie pomyślałem teraz, że skoro silniki krokowe wraz ze wzrostem prędkości obrotowej (czy częstotliwości jak inni wolą) mają coraz mniejszy moment,to przyspieszenie nie powinno być stałe, tylko spadać wraz ze wzrostem prędkości. Wtedy można by zacząć od większego przyspieszenia.

Czyli należało by porzucić trapez z tego https://github.com/KevinOConnor/klipper ... ematics.md a stworzyć coś jak układ RC? Dobrze myślę?

EDIT

Jak byś był ciekawy to kod za to odpowiedzialny jest tu https://github.com/KevinOConnor/klipper ... ead.py#L70 xD

no tak, czytac do konca, potem gadać.....

rafaljot pisze:no tak, czytac do konca, potem gadać.....

co masz na myśli? Wrzuciłem coś głupiego xD?

nie no, teraz źle popatrzyłem na ten trapez. Jakoś tak pomyślałem że na osi Y jest przyspieszenie. Tak też by mogło być.

Mam pytanie za 100 punktów.

Czy Smoothieboard (lub coś innego z podobnym procesorem) + Smoothieware nie będzie mieć takich samych zalet i nie da takiej samej poprawy pracy drukarki jak Arduino + komputerek jak malinka + Klipper?

Może, smoothie też nie ma chyba Jerku. Tylko znajdź tak elastyczną platformę w tej cenie

. MKS SBASE nie liczę, z względu na wbudowane DRV jej nie kupię.

dragonn pisze:Może, smoothie też nie ma chyba Jerku. Tylko znajdź tak elastyczną platformę w tej cenie . MKS SBASE nie liczę, z względu na wbudowane DRV jej nie kupię.

MKS base ma wyprowadzone piny do zewnętrznych stepstickow. I wspinasz się po prostu w ramps-a.

Smoothie ma coś w rodzaju jerk.

Coś rodzaju, z tego co wiem właśnie to się różni od typowego jerku i działa podobnie jak w Klipperze.

mcxmcx pisze:
dragonn pisze:Może, smoothie też nie ma chyba Jerku. Tylko znajdź tak elastyczną platformę w tej cenie . MKS SBASE nie liczę, z względu na wbudowane DRV jej nie kupię.
MKS base ma wyprowadzone piny do zewnętrznych stepstickow. I wspinasz się po prostu w ramps-a.
Smoothie ma coś w rodzaju jerk.

Smoothie ma jerk, nazywa się to:
junction_deviation 0.03
# Similar to the old "max_jerk", in millimeters, see : https://github.com/grbl/grbl/blob/master/planner.c#L409
# and https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.8 . Lower values mean being more careful, higher values means being faster and have more jerk

A tu fajny przewodnik jak podłączyć zewnętrzne stepsticki:
http://www.instructables.com/id/Setup-E ... se-12-Con/

W Klipperze też jest właśnie coś takiego https://github.com/KevinOConnor/klipper ... tion&type= i właśnie o ile wiem to to różni się w działaniu od takiego jerku z Marlina.

EDIT

Nawet identyczna opcja jest junction_deviation

http://forums.reprap.org/read.php?1,739819 tutaj można zobaczyć porównanie, przy czym jeszcze się nie wczytałem. W sumie to nie porównanie, ale wyjaśnienie co to.

FlameRunner pisze:Mam pytanie za 100 punktów.
Czy Smoothieboard (lub coś innego z podobnym procesorem) + Smoothieware nie będzie mieć takich samych zalet i nie da takiej samej poprawy pracy drukarki jak Arduino + komputerek jak malinka + Klipper?

Nie sądzę, by Smoothieboard dało sobie radę. Myślę, że głównym problemem jest brak koprocesora arytmetycznego.
Poza tym to też nie jest w mojej ocenie kwestia tego, czy się da. Ale tego by to zrobić w miarę skończonym czasie. Jednak programowanie w Pythonie, jest o rząd wielkości mniej złożone i dostępne dla ludzi niż C. Jedynie prosty firmware realizujący komendy w lewo , w prawo jest w C a cała rzesza zapaleńców nie koniecznie znających się na automatyce teraz może dalej kombinować. Tu widzę zaletę.

Jeszcze tego nie sprawdzięłem, ale autor Klippera robił jakiś symulator, ruchu, który można podpiąc zamiast płytki. Debugować to w normalnym środowisku, na symulatorze, czy na drukarce, bez wgrywania co chwilę firmware, ryzyka upalenia pinów przy pomyłce. Sporo argumentów przemawia mi za takim podziałem zadania jakim jest tworzenie oprogramowania dla drukarki.

Tu też gość pisze, ża na AVR pojechał przyspieszenie

Tak dla ścisłości Smoothieboard2 będzie miało podobną strukturę jak Klipper, będą dwa CPU, jeden od wykonywania ruchów a drugi od obliczeń a wersja Pro dla ruchów będzie miało FPGA, to już w ogóle full wypas.

A jak komuś się nie podoba opcja RAMPS + Rassberry Pi to może klippera załadować na BeagleBone Black które poza głównym procesorem posiada dodatkowo wbudowane PRU http://beagleboard.org/pru które w tej sytacji wykorzystuje klipper. A do tego można kupić płytkę CRAMPS która jest nakładką typu RAMPS na BeagleBone.

HaHa, chłopak dzielnie walczy.

https://github.com/KevinOConnor/klipper ... -342300085

Nie wypada nie przetestować.

jakieś inne życzenia ?

No ja czekam na autoleveling

, ale nie poganiam bo wiem że to jest na to do list

.

Czekamy na 3d BENCHY!

wyjechany jestem, to trochę poczekacie

ale wiesz na Benchy nie spodziewam się jakiegoś efektu. Benchy wolno się drukuje, kształt nie jest zrobiony z bardzo drobnych odcinków. Poza tym Lume, na której testowałem ostatnio ma jakiś kłopot z Z. A jak już robię benchy to ma być dobre

Następnym razem sprawdzę jak idzie Klipper na Hypercube i czy działa podwójne Z.

https://github.com/KevinOConnor/klipper/pull/45 naprawdę zaczynam lubić jak ten soft jest napisany

. Dorobienie tego zajęło mi jakieś 3-4h a zaczynałem niewiedząca nic

.

Jak myślicie? Raspberry Pi Zero uciągnie Klippera i transmisję wideo przez OctoPrinta?

Jak tam Panowie po paru tygodniach? Macie nadal klippera "onboard"?
Chetnie wyslucham opini a niestety nie mam drukarki z brancha dev obecnie

Ja może dziś podepnę z powrotem do Evo, miałem niestety pewne pechowe zdarzenie z Zero (magic smoke

) i muszę przenieść na Rassberry Pi 2 które akurat miałem pod ręką.

Dzieki

Swoja droga sprawa nad ktora sie nie zastanawialem

step_pin: ar54
dir_pin: ar55
...

jak sobie zmapowac definicje pinoutu majac input z repetierowego pins.h

Kod: Zaznacz cały

*****************************************************************
* DUE3DOM MINI Board
* http://www.due3dom.pl
******************************************************************/
#if MOTHERBOARD == 411
#ifndef __SAM3X8E__
#error Oops! Make sure you have 'Arduino Due' selected from the 'Tools -> Boards' menu.
#endif

#define KNOWN_BOARD
#define CPU_ARCH ARCH_ARM

#define ORIG_X_STEP_PIN       17
#define ORIG_X_DIR_PIN        16
#define ORIG_X_MIN_PIN        38
// on expansion port
#define ORIG_X_MAX_PIN        36 
#define ORIG_X_ENABLE_PIN     22

#define ORIG_Y_STEP_PIN        2
#define ORIG_Y_DIR_PIN         3
#define ORIG_Y_MIN_PIN        34
// on expansion port
#define ORIG_Y_MAX_PIN        32 
#define ORIG_Y_ENABLE_PIN     26

#define ORIG_Z_STEP_PIN       64
#define ORIG_Z_DIR_PIN        63
#define ORIG_Z_MIN_PIN        30
// on expansion port
#define ORIG_Z_MAX_PIN        28 
#define ORIG_Z_ENABLE_PIN     15

#define ORIG_E0_STEP_PIN      61
#define ORIG_E0_DIR_PIN       60
#define ORIG_E0_ENABLE_PIN    62

// on expansion port
#define ORIG_E1_STEP_PIN      -1 
// on expansion port
#define ORIG_E1_DIR_PIN       -1
// on expansion port
#define ORIG_E1_ENABLE_PIN    -1

// on expansion port
#define ORIG_E2_STEP_PIN      -1 
// on expansion port
#define ORIG_E2_DIR_PIN       -1 
// on expansion port
#define ORIG_E2_ENABLE_PIN    -1 

// hotend1 heater
#define HEATER_0_PIN          13 
// bed heater
#define HEATER_1_PIN           7
// on expansion port 
#define HEATER_2_PIN        -1 

// hotend1 thermistor
#define TEMP_0_PIN             7 
// bed thermistor
#define TEMP_1_PIN             6 
// thermo fan thermistor
#define TEMP_2_PIN             5 
// onboard thermistor NTC100K Beta3950
#define TEMP_3_PIN             2 
// on expansion port
#define THERMOCOUPLE_0_PIN     3 
// on expansion port
#define THERMOCOUPLE_1_PIN     4

#define SDSUPPORT              1
#define SDPOWER               -1
#define SDSS                   4
#define ORIG_SDCARDDETECT     14
#define SDCARDDETECTINVERTED   0
#define LED_PIN               -1

// hotend1 cooler
#define ORIG_FAN_PIN           9 
// print fan
#define ORIG_FAN2_PIN         11 
// thermo fan
#define FAN_THERMO_PIN        12 
// 4-pin header FAN0 - only for 4-pin fans !!!
#define FAN_BOARD_PIN          8 

#define ORIG_PS_ON_PIN        40
#define KILL_PIN              -1
#define SUICIDE_PIN           -1

#define SDA_PIN               20
#define SCL_PIN               21

//servo pins 5, 6, 13

#define E0_PINS ORIG_E0_STEP_PIN,ORIG_E0_DIR_PIN,ORIG_E0_ENABLE_PIN,
#define E1_PINS ORIG_E1_STEP_PIN,ORIG_E1_DIR_PIN,ORIG_E1_ENABLE_PIN,
#define E2_PINS ORIG_E2_STEP_PIN,ORIG_E2_DIR_PIN,ORIG_E2_ENABLE_PIN,

#define TWI_CLOCK_FREQ 400000
// see eeprom device data sheet for the following values these are for 24xx256
#define EEPROM_SERIAL_ADDR 0x50   // 7 bit i2c address (without R/W bit)
#define EEPROM_PAGE_SIZE 64     // page write buffer size
#define EEPROM_PAGE_WRITE_TIME 7  // page write time in milliseconds (docs say 5ms but that is too short)
// specify size of eeprom address register
// TWI_MMR_IADRSZ_1_BYTE for 1 byte, or TWI_MMR_IADRSZ_2_BYTE for 2 byte
#define EEPROM_ADDRSZ_BYTES TWI_MMR_IADRSZ_2_BYTE
#define EEPROM_AVAILABLE 1
#endif
//End DUE3DOM MINI Board

@dragonn, skoro przyglądałeś się możliwości implementacji S-shape acceleration, to może wiesz też, czy była by możliwość implementacji w hoście korekty nierówności stepów DVR8825 ?
Nie wiem jak wygląd ramka, czy coś wysyłane do uC więc nie potrafię sobie odpowiedzieć.
To by dało jakieś nadzieje dla takich płytek jak sbase.

EDIT: już wiem. Tak sobie.

Kod: Zaznacz cały

queue_step oid=%c interval=%u count=%hu add=%hi : This command schedules 'count' number of steps for the given stepper, with 'interval' number of clock ticks between each step.

Znaczy tak ale bardzo by to zwiększyło komunikację. Count zawsze musiało by być =1. Prędzej po stronie uC jednak.

Hmmm nie no to byś musiał robić raczej w hoście, przecież do uC wysyłasz jakiego kroki chcesz zrobić. Wystarczy że wyślesz już skompensowane wartości. Myślę że możliwość zrobienia tego na pewno jest.

rafaljot pisze:@dragonn, skoro przyglądałeś się możliwości implementacji S-shape acceleration, to może wiesz też, czy była by możliwość implementacji w hoście korekty nierówności stepów DVR8825 ?
Nie wiem jak wygląd ramka, czy coś wysyłane do uC więc nie potrafię sobie odpowiedzieć.
To by dało jakieś nadzieje dla takich płytek jak sbase.

EDIT: już wiem. Tak sobie.
Kod: Zaznacz cały
queue_step oid=%c interval=%u count=%hu add=%hi : This command schedules 'count' number of steps for the given stepper, with 'interval' number of clock ticks between each step. 
Znaczy tak ale bardzo by to zwiększyło komunikację. Count zawsze musiało by być =1. Prędzej po stronie uC jednak.

Ale sbase ma wyjścia na stepsticki i zamiast mnożyć problemy wkładasz zewnętrzne na plytce, jakie życzysz, na dowolne napięcie etc.
Jedynie tracisz ustawianie prądu, ale potencjometr albo serial i naprzód.

@mcxmcx ależ właśnie chodzi o to by mnożyć problemy - by móc je potem rozwiązywać.
Przynajmniej w tym wypadku.

Bez sensu grzebać cokolwiek z tymi parchowatymi drv. Szkoda zachodu.

Bedzie ta benchy z klippera?

korci mnie zeby wyprobowac ale nie mialem czasu ogarnac pinout pod due3doom mini, probowal ktos cos?

Też chętnie zobaczę benchy najlepiej z porównaniem pod avr. Jeśli robi dużą różnicę to przesiadam się na klippera i zasiadam do klepania kodu do niego ;]

do mnie to pytanie?!

no dobra... będzie. Puszczam na tym samym profilu najpierw na Marlinie 1.1.8
Jednak Benchy to akurat nie jest jakiś mega dobry model testowania tego co daje Klipper. główne zalety spodziewam się zobaczyć na narożnikach 90' czy na fragmentach, co robią echo. W Benchy zakładam będzie to widać głównie przy futrynie drzwi, krawędziach kluz.

Tak z czystej ciekawości - zapisz sobie czas wydruku na Marlinie i Klipperze.

Czekam z niecierpliwością na porównanie.

no i co mam powiedzieć. Największa różnica polega na tym, że lewe Benchy, ma zielony daszek, bo się skończył filament.

z lewej Klipper:
acc 3000 (ustawia się tylko przyspieszenie)

z prawej Marlin 1.1.8
jerk 20, acc 1500

parametry z Cury:
warstwa 0.2
dwa obrysy
dysza 0.35
speed 40, zewnętrzna 20, travel 140
jerk,acc - kontrolowane przez drukarkę

drukarka:
Lume z przełożeniem bloczkowym na X i Y
tmc2100 na X i Y
RAMPS
Titan
dysza 0.35

1. Widać, żę klipper nieco bardzeij podgrzał filament. Pewnie inny termistor ustawiłem, inną tabela.ale bez żartów:
2. trzeba się bardzo przypatrzeć, by zobaczyć jakiekolwiek echo na obu. Ale jak się uprzeć, to na Klipperze mniejsze
3. Mam wrażenie, żę z Merlina nieco bardziej ostre krawędzie. W obu napis na rufir jest całkiem czytelny. OStrość krawędzi może jednak wynika z temperatury
4. Marlin wydrukował szybciej. No i w sumie nie dziwne. Za małe prędkości dałem jerk 20 i prędkość 20/40, no to wiele akceleracja się nie na akcelerowała.
5. Największa różnica była w tym, czego nie widać na fotkach. kultura pracy, dzwięki z drukarki mega na korzyść Klippera

Trzeba by puścić coś większego i szybciej. Wklejałem wcześniej zwykłą kostkę kalibracyjną na niej było widać większe różnice na korzyść Klippera.

W kliperze też da się ustawić "jerk" tylko nazywa się to junction_deviation o ile mnie pamięć nie myli - wyższa wartość ma ten sam skutek co wyższa wartość jerku na Marlin. Ustaw sobie 0.1 to zobaczysz różnice.

Wysłane z mojego K10000 przy użyciu Tapatalka

w zasadzie czemu nie miało by być wsparcia dla kontrolera z LCD i pokrętłem.
wystarczyło by:
1. w trakcie druku by działał przycisk halt. Na ekranie może być napisane tylko "printing", po zakończeniu "end, print time:...."
2. za to jak nie drukuje to mogły by być wszystkie funkcje związane z przygotowaniem:
- homeing,
- ruchy osiami,
- preheat,
- zmiana parametrów,
- status połączenia z hostem i Pi z wifi.

rafaljot pisze: drukarka:
Lume z przełożeniem bloczkowym na X i Y

Czy możesz napisać o co chodzi?

rafaljot pisze:w zasadzie czemu nie miało by być wsparcia dla kontrolera z LCD i pokrętłem.
wystarczyło by:
1. w trakcie druku by działał przycisk halt. Na ekranie może być napisane tylko "printing", po zakończeniu "end, print time:...."
2. za to jak nie drukuje to mogły by być wszystkie funkcje związane z przygotowaniem:
- homeing,
- ruchy osiami,
- preheat,
- zmiana parametrów,
- status połączenia z hostem i Pi z wifi.

Nadal uważam że obsługą wyświetlacza powinno się zajmować Pi a nie AVR. A przycisk halt też da się wtedy obsłużyć.

Marcin1415 pisze:
rafaljot pisze: drukarka:
Lume z przełożeniem bloczkowym na X i Y
Czy możesz napisać o co chodzi?

nie.

Bo już 10 razy pisałem, wrzucałem foty itd

wiem, trudna sprawa trzeba znaleźć w zamkniętym wątku o Lume, sam się nie podejmuję

.

@Marcin1415
https://www.thingiverse.com/thing:2155595 aktualnie jest wersja z Titanem i i tulejkami z brązu.

Mam Klipper. Jest świetny. Oczywiście gdyby nie Dragon to nie ustawił bym go.

W moim wątku viewtopic.php?t=2359 wrzuciłem zdjęcia 3dBenchy drukowanego 100mm/s. Wydruk trwał 58 min.

Pytanie dla obeznanych w temacie. Czy ten pr będzie wykorzystywał podobny algorytm do tego w klipperze? https://github.com/MarlinFirmware/Marlin/pull/10337

tig33r pisze:Pytanie dla obeznanych w temacie. Czy ten pr będzie wykorzystywał podobny algorytm do tego w klipperze? https://github.com/MarlinFirmware/Marlin/pull/10337

Na dany moment nie, dyskusja o czymś zbliżonym jest tutaj https://github.com/KevinOConnor/klipper/issues/57 wrzuciłem im linka do tego co Ty znalazłeś też.

Czyli ten algorytm z marlina jest krok dalej przed klipperem rozumiem? To byłby chyba duży krok jeśli chodzi o kulturę pracy drukarek.

tig33r pisze:Czyli ten algorytm z marlina jest krok dalej przed klipperem rozumiem? To byłby chyba duży krok jeśli chodzi o kulturę pracy drukarek.

No tak, udało im się szybciej zaimplementować.
Trochę mnie wkurza ta cała sytuacja z tym algorytmem bo podobnie jest w Duet, wiele ludzi się wypowiada i dyskutują czy w teorii ma to w ogóle sens ale nikt jeszcze tego nie sprawdził

. Propsy dla Marlina że to zaimplementowali

może w końcu ruszy też to w innych firmware a nie będą się tylko zastanawiać

Panowie, ten marlin jest na razie na etapie geekow, a ja jestem konsumentem.

Ale zapytam, i wszystkie pytania dotyczą MKS sbase 1.3

Że chodzi na plytkch smoothie to wiem,
tylko czy obsłuży 3 termopary na spi i wyświetlacz 12864?

Czy jakiś konfigurator jak w repetier jest, czy zmieniamy wiele wpisów w setce plików?

Czy ma web serwer?
Czy obsługuje wyświetlacz 2004 i kartę ad z niego? Ten najpopularniejszy (reprapdiscount)

Czy upgrade oznacza skopiowanie plików i zachowanie konfigu, czy trzeba od nowa wszystko klikać.
Czy ma obsługę wentylatora od przewietrzania obudowy?

Ktoś coś wie?

mcxmcx pytasz teraz o Marlina czy o Klippera? Jeśli o Marlina to FlameRunner wydziel to

, bo to aż nooo wiadomo

.

dragonn pisze:mcxmcx pytasz teraz o Marlina czy o Klippera? Jeśli o Marlina to FlameRunner wydziel to , bo to aż nooo wiadomo .

No oczywiście o Marlina.

Czy klipper na thermal runaway? Żeby nie trzeba było dla ramps gaśnicy trzymać.

Wysłane z mojego Redmi 4X przy użyciu Tapatalka

Ma. Przynajmniej według kodu, możesz łatwo przetestować włączając grzanie bez podpietej grzałki

Wysłane z mojego K10000 przy użyciu Tapatalka

Właśnie ostatnio coś często mam problem z wybudzeniem.

Po wybraniu pliku do druku po chwili error bo nie grzeje. I muszę robić restart.

Wysłane z mojego Redmi 4X przy użyciu Tapatalka

Robiłeś PID Tune?

Tak ale już chwilę temu. Pewnie trzeba powtórzyć. Po aktualizacji nie robiłem

Wysłane z mojego Redmi 4X przy użyciu Tapatalka

Jak malinkę połączyć z rampsem?

malyhenio1 pisze:Jak malinkę połączyć z rampsem?

Kablem USB

Czyli nadal przez arduino?

No tak ale jest tylko jako tak jakby przekaźnik

Wysłane z mojego Redmi 4X przy użyciu Tapatalka

Czy klipper ma już wszystkie "core" funkcje, o których była tu wcześniej w wątku mowa? Przeglądałem trochę github i widzę, że tmc2130, lpc176x i bezier jerk są już w osobnych branchach czyli są wstępnie napisane i pewnie prędzej czy później wejdą do kodu.

Jakby kogoś interesowało to ogarnąłem już Filament RunOut sensor i mam w Octoprint już zrobioną wymianę filamentu tak jak w repetier

tig33r pisze:Czy klipper ma już wszystkie "core" funkcje, o których była tu wcześniej w wątku mowa? Przeglądałem trochę github i widzę, że tmc2130, lpc176x i bezier jerk są już w osobnych branchach czyli są wstępnie napisane i pewnie prędzej czy później wejdą do kodu.

TMC2130 o ile widzę właśnie wpadły do głównego brancha.

Już się rozejrzałem w temacie i wygląda na to, że fork cruwallera jest dużo bardziej obfity w zaawansowane funkcje.

Coraz bardziej mnie to interesuje, ale poczekam na instrukcje instalacji , bo to nie na moje siły

Kopytko pisze:Coraz bardziej mnie to interesuje, ale poczekam na instrukcje instalacji , bo to nie na moje siły

Instalacja nie jest taka straszna jak się wydaje. Nawet ja dałem jakoś radę

Widzę zę temat ucichł, a ja się dalej bawię KLipperem.

Obecnie mamy menu ekranowe do podstawowych funkcji, mamy plugin do octopirnt https://plugins.octoprint.org/plugins/klipper/

no i ciągle jest rozwijany

Czy ktos wie jak w klipperze ustawic bltouch na enderze 3 - podpiete mam przez pin27 lcd board i chcialbym uzwyac go jako z endstopa i do mesh bed levelingu

Teraz ci nie powiem, ale jest przykładowy config dla ender to szukaj, wieczorem może będę miał więcej czasu

mój config niby BLtouch działa ale tylko do zerwoania osi z mam problem jak sie zaczyna wydruk bo wysuwa sie nozka i wadzi o stol :/

https://gist.github.com/banolka/870b5a3 ... 20f6d89f30

Kod: Zaznacz cały

# Define the BLTouch servo
[servo bltouch]
pin: ar11
maximum_servo_angle: 180
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024

# Define a probe using the BLTouch
[probe]
pin: ar18
z_offset: 0.15
activate_gcode:
    SET_SERVO SERVO=bltouch ANGLE=10
    SET_SERVO SERVO=bltouch ANGLE=60
    G4 P200
deactivate_gcode:
    SET_SERVO SERVO=bltouch ANGLE=90
    G4 P100


# Mesh Bed Leveling. One may define a [bed_mesh] config section
# to enable move transformations that offset the z axis based
# on a mesh generated from probed points. Note that bed_mesh
# and bed_tilt are incompatible, both cannot be defined.
[bed_mesh]
speed: 120
#   The speed (in mm/s) of non-probing moves during the
#   calibration. The default is 50.
horizontal_move_z: 10
#   The height (in mm) that the head should be commanded to move to
#   just prior to starting a probe operation. The default is 5.
samples: 1
#   The number of times to probe each point.  The probed z-values
#   will be averaged.  The default is to probe 1 time.
sample_retract_dist: 5.0
#   The distance (in mm) to retract between each sample if
#   sampling more than once.  Default is 2mm.
min_point: 30,10
#   An X,Y point defining the minimum coordinate to probe on
#   the bed. Note that this refers to the nozzle position,
#   and take care that you do not define a point that will move
#   the probe off of the bed. This parameter must be provided.
max_point: 295,260
#   An X,Y point defining the maximum coordinate to probe on
#   the bed. Follow the same precautions as listed in min_point.
#   Also note that this does not necessarily define the last point
#   probed, only the maximum coordinate. This parameter must be provided.
probe_count: 5,5
#   A comma separated pair of integer values (X,Y) defining the number
#   of points to probe along each axis. A single value is also valid,
#   in which case that value will be for both axes. Default is 3,3
#   which probes a 3x3 grid.
fade_start: 300.0
#   The z-axis position in which to start phasing z-adjustment out.
#   Default is 1.0.
#fade_end: 300.0
#   The z-axis position in which phase out is complete. If this
#   value is less than or equal to fade_start then phasing out
#   is disabled. Default is 10.0.
split_delta_z: .025
#   The amount of Z difference (in mm) along a move that will
#   trigger a split. Default is .025.
move_check_distance: 5.0
#   The distance (in mm) along a move to check for split_delta_z.
#   This is also the minimum length that a move can be split. Default
#   is 5.0.
mesh_pps: 2,2
#   A comma separated pair of integers (X,Y) defining the number of
#   points per segment to interpolate in the mesh along each axis. A
#   "segment" can be defined as the space between each probed
#   point. The user may enter a single value which will be applied
#   to both axes.  Default is 2,2.
algorithm: bicubic
#   The interpolation algorithm to use. May be either "lagrange"
#   or "bicubic". This option will not affect 3x3 grids, which
#   are forced to use lagrange sampling.  Default is lagrange.
bicubic_tension: .2
#   When using the bicubic algorithm the tension parameter above
#   may be applied to change the amount of slope interpolated.
#   Larger numbers will increase the amount of slope, which
#   results in more curvature in the mesh. Default is .2.

u mnie jest tak porównaj

Mam pytanie bo właśnie konfiguruję klippera pod due i napotkałem na problem że nie mogę ustawić 2 pinów jako te samo wyjście- 2 mosfety, 2 maty od heatbeda.
Błąd który wywala

Kod: Zaznacz cały

Recv: // Printer is halted
Recv: !! Unknown pin chip name 'multi_pin

W configu mam to opisane tak jak znalazłem na githubie że powinno być

Kod: Zaznacz cały

heater_pin:  multi_pin:my_heater_pin
[multi_pin my_heater_pin]
pins:  PC8, PA19

Ktoś miał okazję korzystać z multi pinów i mógłby pomóc?

A czy to czasem nie jest dodatkowy moduł który trzeba sobie najpierw włączyć?

Nigdzie nie widziałem takiej opcji.
Info z przykładowego configa

Kod: Zaznacz cały

# Multiple pin outputs (one may define any number of sections with a
# "multi_pin" prefix). A multi_pin output creates an internal pin
# alias that can modify multiple output pins each time the alias pin
# is set. For example, one could define a "[multi_pin my_fan]" object
# containing two pins and then set "pin=multi_pin:my_fan" in the
# "[fan]" section - on each fan change both output pins would be
# updated. These aliases may not be used with stepper motor pins.
#[multi_pin my_multi_pin]
#pins:
#   A comma separated list of pins associated with this alias. This
#   parameter must be provided.

Wariant pin=multi_pin:my_fan sprawdzałem też nie działa i na którymś issue na githubie znalazłem zapis jak u mnie

A jesteś pewny że masz najnowszą wersję softu?

Tak, wczoraj instalowane octopi i klipper prosto z repo + aktualizacja octopi.

https://github.com/KevinOConnor/klipper ... ppy/extras to jest w extras, nic z tego nie jest domyślnie włączone. Gdzieś na pewno pisze jak włączać rzeczy z extras.

Tmc2130 też są w extras i tak jak w przykładowym configu tylko dodałem linijkę ze stepperem i działa więc nie wiem za bardzo o co chodzi.

Doczytałem i faktycznie powinno ładować automatycznie jak znajdzie daną sekcję w configu, sugeruję najlepiej zapytać na githubie czemu nie działa.
Wrzuć od razu wtedy cały swój config.

Dobra przespałem się z tym i udało mi się dojść o co chodzi.
W pierwszej kolejności ustala się definicję multi pinu, a potem jego wykorzystanie (co w sumie jest logiczne

) , a nie jak jest napisane na githubie że wykorzystanie, a potem definicja.
W moim przypadku

Kod: Zaznacz cały

[multi_pin my_heater_pin]
pins:  PC8, PA6
[heater_bed]
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PB19
control: pid
pid_Kp: 76.60
pid_Ki: 8.27
pid_Kd: 177.27
min_temp: 0
max_temp: 130
heater_pin: multi_pin:my_heater_pin

Postanowiłem że podzielę się tym tak dla potomnych, co by ktoś inny nie musiał się męczyć

PS. Jeśli ktoś będzie sobie dziergał config na smart ramps na due to nie przypisujcie pinu D42(PA19) do czegokolwiek, bo pomimo że jest wyprowadzony na złącze aux to powoduje reset uC i bootloop.

A no tak, ładowanie modułów extra polega na tym że jak znajdzie sekcję danego modułu to go ładuje. Jak masz użycie modułu przed jego definicją to się wyspie

.

Ogólnie to miałem jeszcze problem z tmc2130 i dziwnymi zachowaniami pinów - sygnałowe wejścia endstopów łapały same z siebie stan wysoki jak by były wyjściem (mierzone multimetrem) i już byłem gotów rzucić to w diabły, zainstalować marlina 2.0. Ale udało się wszystko włącznie z wyświetlaczem ustawić. A na piny pomógł reset maliny zamiast samego FW cholera wie czemu.

Cały dzień spędziłem na dłubaniu i nic.

Po kilkunastu minutach error i staje.

Wymieniłem kanapkę, sprawdziłem wszystkie połączenia.

Pozostaję sprawdzić termistor, albo to wina softu, aktualizowałem kilka dni temu. PID robiony przed wydrukiem.

To jest druk z PLA? Chłodzenie na 100%? Spróbuj owinąć blok taśmą kaptonową albo załatwić jakąś osłonę silikonową. Bo wygląda tak jakby nadmuch chłodził dyszę a ta nie wyrabiała z grzaniem.

temperatura stołu też zaczęła spadać w tym samym czasie.
jeśli nie to co pisze @Zepco to może problem z zasilaczem. Możesz sprawdzić napięcie na zasilaniu elektroniki w momencie gdy przestaje grzać?

Stół raczej przestał grzać, bo przez błąd hotendu wszystko zostało wyłączone.
Możesz puścić wydruk bez chłodzenia wydruku i zobacz co się dzieje. Wydruk wyjdzie paskudny ale przynajmniej będziesz wiedział co się dzieje.
Zasilacza raczej nie brałbym pod uwagę, bo widać że coś ewidentnie jest nie tak z temperaturą grzałki. Te wahania mają na moje oko więcej niż 5st.

Robiłem pid bez nadmuchu, to popierwsze, pod drugie muszę sprawdzić jak tam ułożenie kanału czy się nie przestawiło i wali prosto na blok.

To wydruk z pla, a ze sunon daję 10m3/h to tak wychodzi.

Zrobię jeszcze raz pid z chłodzeniem i jeszcze mam gdzieś wełnę to owine blok

Stół przestał grzać po błędzie, bo cały wydruk przerwało

Ok. Pid z nadmuchem nie został ukończony bo złapał błąd.

Przyjrzałem się hot endowi i zobaczyłem że termistor wystaje z bloku

Poprawiłem termistor, owinąłem bawełną

Mój problem rozwiązany.
problem tkwił w niedomaganiach grzałki ekstrudera. wsztsko działało dopóki nie włączył się wentylator chłodzenia wydruku. Grzałka nie miała doś mocy aby utrzymac temperaturę, poprostu sie zurzyła. Wymiana na nową rozwiazła problem. Teraz ekstruder trzyma temperaturę.

Czyli wychodzi na to że akurat aktualizowałeś soft jak padła grzałka

.
Ah ta złośliwość rzeczy martwych

Tak jak by ktoś był ciekawy:
https://github.com/Stephan3/dwc2-for-klipper

@Dragon możesz mi przybliżyć co to jest dwc2?

Marcin.KnD pisze:@Dragon możesz mi przybliżyć co to jest dwc2?

Duet Web Control prosto z RepRapFirmware/DuetWifi. Moim zdaniem wygodniejszy od Octoprinta (pomijając brak wtyczek).

Znikoma szansa, żeby to weszło w główny branch, więc sprawa do pominięcia.

tig33r pisze:Znikoma szansa, żeby to weszło w główny branch, więc sprawa do pominięcia.

Jeśli będzie w miare rozwijane wraz z rozwojem samego klippera to nie widzę problemu w tym że będzie to poza główny repo. To było pewno że czasem pojawią się zewnętrzne wtyczki do klippera i możliwe też że klipper jeśli zacznie się ich pojawiać więcej postara się o ustabilzowanie API do tego typu rozszerzeń.

czytam że jest już wsparcie dla "filament runout senso"r oraz "bed screw" do ustawienia śrób stołu na kartkę

spoko. soft się rozwija

Da się to połączyć z enderem 3 ze stockową płytą? I gdzie szukać instrukcji?

W pierwszym linku z google.

Wie ktoś jak zrobić by na wyświetlaczu znakowym 20x40 w menu SD Card wyświetlały się pliki z jakiegoś katalogu? Jest to menu ale nie rozumiem jak działa jak miało działać. U mnie zawsze jest puste.

hmm. chyba to jest jakieś niedorobione. Zmieniłem:
1. w pliku web_dwc2.py w linni 61:

Kod: Zaznacz cały

#<-----><------>self.sdpath = self.configfile.getsection("virtual_sdcard").get("path", None)
<------><------>self.sdpath = config.get( 'sd_path', self.configfile.getsection("virtual_sdcard").get("path", None))

2 w pliku konfiguracyjnym:

Kod: Zaznacz cały

[virtual_sdcard]
path: /home/pi/sdcard/gcodes

3. w sekcji web_dwc2 nowy parametr "sd_path:"

Kod: Zaznacz cały

[web_dwc2]
printer_name: Prusa mk3s
listen_adress: 0.0.0.0
listen_port: 4750
web_path: dwc2/web
sd_path: /home/pi/sdcard

Małe pytanie ogarnął ktoś może komendę M600 i/lub M500 w klipperze i chciałby się podzielić ustawieniami? Bo M600 trochę ogarnąłem:

Kod: Zaznacz cały

[pause_resume]
recover_velocity: 50

[gcode_macro M600]
default_parameter_X: 200
default_parameter_Y: 170
default_parameter_Z: 10
gcode:
    SAVE_GCODE_STATE NAME=M600_state
    PAUSE
    G91
    G1 E-.3 F900
    G1 Z{Z}
    G90
    G1 X{X} Y{Y} F3000
    G91
    G1 E-50 F1000
    RESTORE_GCODE_STATE NAME=M600_state

Ale działa tak średnio. Raz zatrzymuje się we wskazanym miejscu, a raz jakby to ująć? O! Odpływa z powrotem nad wydruk.
A m500 - niby jest SAVE_CONFIG ale chyba nie działa. Na końcu pliku printer.cfg nic nie dopisuje.

pobawiłem się dzisiaj:
1. upgrade Klippera w K8400
2. instalacja Mainsail zamiast dwc2-for-klipper
3. tuning shapingu https://www.klipper3d.org/Resonance_Compensation.html

druk 80mms, kostka 150%, 30x30

Kod: Zaznacz cały

[printer]
kinematics: cartesian
max_velocity: 200
max_accel: 3500
square_corner_velocity:10
max_z_velocity: 5

echo przed i po dodaniu:

Kod: Zaznacz cały

[input_shaper]
shaper_freq_x:25.5
shaper_freq_y:25.5
shaper_type: mzv

@rafaljot używałeś ADXL345 akcelerometru ?

nie. Zrobiłem tuning tak jak tu opisano. https://www.klipper3d.org/Resonance_Compensation.html

z tym, najpierw robiłem ten wydruk testowy. Jednak on jest wielki i bez sensu. Można równie dobrze użyć dowolnego detalu, np forumowej kostki powiększonej 200% w trybie wazy i na parametrach na których wiemy, że wychodzi wyraźne echo. Nie ustawiać tej komendy od testów typu tower - TUNING_TOWER, czyli pominąć krok 1,2 i 6
Po prostu wydrukować i zmierzyć echo. obliczyć częstotliwość ze wzoru.

U mnie lepsze echo wychodzi na square_corner_velocity:10 . Inaczej niż napisał gość w instrukcji, a acc 7000 drukarka nie wytrzymuje

O co chodzi z tym "shaper_type"? To są różne modele "dzwonienia"?
Tam powinna być częstotliwość, amplituda i współczynnik tłumienia, może nawet bez amplitudy, ale drgania mogą być bardzo złożone przy różnych konstrukcjach.

@mie3yslav wszystko jest opisane w artykule, który wrzuciłem powyżej i zawartych w nim linkach.

No patrzyłem na to, ale z praktyki - testowałeś na różnych shaper_type?
A na różnych prędkościach? Bo ja rozumiem, że przy konkretnej prędkości może być dobrze... żeby się nie okazało, że wolniej będzie gorzej, bo nie jest idealnie zamodelowane i będzie chciał tłumić drgania, których nie ma.
Generalnie na zdjęciach wygląda spoko, denerwuje mnie tylko ta linia od góry Y - też często tak wychodzi mi na wydrukach. Czy to są luzy, czy mniejszy wypływ po "uwolnieniu" materiału w "dziurze"?
Jedno i drugie też można by kompensować (rozumiem, że pressure advance tego nie rozwiązuje?)

zdziwiłem się taż że to tak od starła zadziałało. Nie testowałem innych typów shapera skoro wygląda że pierwszy zadziałał.
Korekta robiona jest na podstawie częstotliwości, która z założenia powinna być stała.
Można się pobawić i porobić wieże testowe z różnymi prędkościami albo np stożek.

ta linia od góry Y to błąd slicera. Cura w tym miejscu odwala jakiś przejazd mimo, że ma tryb wazy.
Slic3r robi ładnie.

Inna sprawa, że jak są luzy (szukaj tematu "backlash tower") to też wychodzi podobna kreska, tylko trochę inna przesunięcie potem ciągnie się na kolejnych warstwach. Niestety w Klipperze umarł temat korekty backlash. W Repetierze była od zawsze a w Marlinie od jakiegoś czasu.

EDIT: przecież nawet to opisałem tu: viewtopic.php?t=1069 pkt. 1.

Nie widać żadnego negatywnego wpływu tego tłumienia (brak szczegółów, zaokrąglone rogi) ? Ja miałem podłączony ADX345 i po skonfigurowaniu wszystkiego nie zauważyłem żadnego pozytywnego działania. Wydawało mi nawet, że jest nieco gorzej.

https://github.com/KevinOConnor/klipper/issues/3741
to może być niezłe

to mi przypomniało, że gdzieś powinienem mieć czujniki wstrząsu, które dawno temu używałem jako detektor próby włamania do skrzynki z automatyką.
Może dało by się też je użyć.

@Berg kilka pytań przy okazji:

Jak startuję drukarkę, to za każdym razem muszę zrobić "restart firmware" - też tak masz? Podejrzewam, że coś startuje za późno i się nie dogadują - włączam jednocześnie Pi i płytkę drukarki. Później jest już wszystko OK, do następnego włączenia.

Ten interfejs co masz to jest Fluidd?,
Ja mam Fluidd - wygląda podobnie, ale chciałbym sobie zmienić parę rzeczy, np ostatnia aktualizacja zmieniła sposób bazowania osi (Home), i trzeba teraz najechać na domek, potem w prawo i wybrać oś. A ja mam deltę, więc wsio ryba - nie potrzebuję tego.
Druga sprawa to chciałbym sobie zmienić kolorki (wyróżnić co nieco) tego co jest wyświetlane. Próbowałem zmieniać to w css, ale nic to nie daje.

I jeszcze Orange Pi - którą masz płytkę i czy miałeś jakieś problemy z długoterminową stabilnością? Ja próbowałem używać Orange Pi Zero do innego projektu i niestety poległem. Prędzej czy później (godzina... kilkanaście dni) miałem zwiechę. Nic się nie dało ustalić - ot po prostu zamarzał.

1. OrangePi - nie mam problemów ze stabilnoscią,
2. ale najbardziej jestem zadowolony z BananaPi Zero,
3. nie, to nie jest normalne, że trzeba restartować,
4. interfejs - teraz używam MainSail.

1. Czy jeżeli w Marlin'ie włączę DIRECT_STEPPING, to będzie to działało równie dobrze jak gdybym wgrał na płytę firmware od Klipper'a?
2. Które UI są godne zainteresowania? Na chwilę obecną korzystam z Octoprint, ale chcę zaprząc do roboty stary telefon, który będzie "przypięty" na stałe do drukarek, a Octoprint na małych ekranach jest średnio wygodny.

2. Mainsail na komórce działa fajnie.

1. Absolutnie nie.

A to szkoda strasznie, więc muszę zaczekać aż dodadzą do Klippera obsługę wyświetlaczy TFT.

Hm, Klipper obsługuje niejeden ekran... sprawdź czy na pewno nie obsługuje.

Nie znalazłem MKS TFT 35 v1.0 - chyba, że jesteście w stanie mi pomóc.

cyfron pisze:A to szkoda strasznie, więc muszę zaczekać aż dodadzą do Klippera obsługę wyświetlaczy TFT.

Nie ma i nie będzie (w/g twórcy) Kilppera.
Mi udało się podłączyć TFT do Rpi a nie do płyty. Mam "pełną" funkcjonalność choć wydruki z karty są trochę "kwadratowe" z powodu ograniczeń transmisji, ale na tym mi zbytnio nie zależało. Jest na forum gdzieś wątek gdzie to wstępnie opisałem ale z powodu zerowego zainteresowania dawno nie aktualizowałem.

cyfron pisze:Nie znalazłem MKS TFT 35 v1.0 - chyba, że jesteście w stanie mi pomóc.

Dokładnie, obsługi tego nie będzie. Cały kłopot z tym wyświetlaczami jest taki to to że one wcale nie działają jak wyświetlacz a bardziej jak taki octoprint, wysłają one g-code do drukarki i odbierają odpowiedzi a przy drukowanie z karty SD to już w ogóle, wyświetlacz czyta g-code z sd i wysyła do drukarki.
Wywraca to do góry nogami całą architekturę klippera.
Jeśli koniecznie musisz mieć fancy wyświetlacz w drukarce to popatrz na https://github.com/jordanruthe/KlipperScreen

MKS TFT35 v1.0 nie ma czytnika kart - to tylko wyświetlacz na ILI9341.

Nie chodzi o bajerancki wyświetlacz, tylko o to, że taki już mam razem z Robin nano do którego zwykłego LCD12864 nie ma jak podłączyć. Nie wiem jak to jest z wyświetlaczami TFT w Klipper ale Marlin sobie z nimi radzi i rozpoznaje je jako FSCM - cokolwiek to znaczy. Generalnie Klipper na chwilę obecną chyba nie obsługuje natywnie żadnego wyświetlacza TFT? Szukałem też obsługi wyświetlacza do Alfawise U30 i również nie znalazłem.

@Cyfron , był osobny wątek poświęcony TFT+Klipper viewtopic.php?f=14&t=7399&p=121675
Ja tak jak koledzy uważam, że podłączanie MKS TFT do Klippera nie ma sensu. Lepiej go po wywalić do kosza i za 35zł kupić zwykły tekstowy 2004 a za kolejne 60zł elektronikę która będzie z nim działać (skoro Robin nie potrafi).

Jakkolwiek dalszą dyskusję na temat tego TFT sugeruję prowadzić w tamtym wątku.

No nie lepiej, bo drożej, biorąc pod uwagę że mam jeszcze Alfawise U30, którą również chciałbym pogonić na Klipper'ze. Nie da się, to się nie da, więc zostanę tymczasem przy Marlin'ie, nad czym niestety ubolewam, bo w moim Złomku Klipper pozytywnie mnie zaskoczył.

@cyron, a czytałeś co napisałem wyżej i ten wątek co podlinkowałem?

Czytałem. O ile dobrze zrozumiałem wyświetlacz podpina się do malinki. Nie urządza mnie takie rozwiązanie, ponieważ do jednej malinki mają być podpięte 3 drukarki (3 instancje klippera), więc każda drukarka musi mieć swój wyświetlacz.

trzy seriale trzeba zdefiniować na malince. Tez się da.

Jak dla mnie robi się z tego rzeźba w kupie.

Za pomocą KIAUH mam zainstalowanego Klipper+Moonraker+Mainsail, 3 instancje dla 3 drukarek. Niby wszystko działa ale borykam się z dwoma niedogodnościami.
1. Mainsail nie zapamiętuje dodanych drukarek. Po każdym nowym uruchomieniu muszę dodawać drukarki od nowa. Fluid zachowuje się tak samo.
2. Nie można wyłączyć systemu z poziomu WebUI, nieważne czy Mainsail czy Fluid. Wcześniej w Octoprint wpisałem komendę zamykania w ustawieniach (sudo /usr/sbin/shutdown) i było OK.

Użytkownik który u mnie uruchamia klippera nazywa się klipper

- jest dodany do sudoers, dla /usr/sbin/shutdown oraz /usr/sbin/reboot ma dodane NOPASSWD, z konsoli użytkownik klipper zamyka system bez podawania hasła. Sprzęt to OrangePi lite z Armbian Debian.

Zna ktoś rozwiązanie na w/w dolegliwości?

cyfron pisze:MKS TFT35 v1.0 nie ma czytnika kart - to tylko wyświetlacz na ILI9341.

Nie chodzi o bajerancki wyświetlacz, tylko o to, że taki już mam razem z Robin nano do którego zwykłego LCD12864 nie ma jak podłączyć. Nie wiem jak to jest z wyświetlaczami TFT w Klipper ale Marlin sobie z nimi radzi i rozpoznaje je jako FSCM - cokolwiek to znaczy. Generalnie Klipper na chwilę obecną chyba nie obsługuje natywnie żadnego wyświetlacza TFT? Szukałem też obsługi wyświetlacza do Alfawise U30 i również nie znalazłem.

Dla siebie robiłem takie coś (akurat nie pod MKS tylko działający na podobnej zasadzie BigTreeTech 3.5).

https://github.com/KevinOConnor/klipper/pull/3885

Ale jest to gotowe w 10% i nie zapowiada się żeby poszło dalej. Choć u siebie używam i jeśli się nie powiesi to nawet działa.

Obecnie bardziej dokuczają mi w/w niedogodności niż brak wyświetlacza.

cyfron pisze: 2. Nie można wyłączyć systemu z poziomu WebUI, nieważne czy Mainsail czy Fluid. Wcześniej w Octoprint wpisałem komendę zamykania w ustawieniach (sudo /usr/sbin/shutdown) i było OK.

Pokaż `/etc/ sudoers`. Może być tak, że te polecenia masz przypisane do grupy `sudo`, ale uruchomiony proces nie ma tej grupy przypisane. Opcje są dwie:

- zmienić z grupy na użytkownika w `/etc/ sudoers` (prostsze, zalecane)
- zmienić definicję usługi w systemd dodając `SupplementaryGroups=sudo` do procesu (niezalecane)

Co ciekawe, nie można postować jak się wpisze: `/etc/ sudoers` bez spacji.

plik w /etc/ sudoers.d/

Kod: Zaznacz cały

klipper ALL=(ALL) NOPASSWD: /sbin/poweroff, /sbin/reboot, /bin/systemctl

komendy pisane w konsoli przez urzytkownika klipper działają jak należy, w Octoprint też działały.

Możesz jeszcze spróbować:

Kod: Zaznacz cały

/usr/bin/sudo /sbin/reboot

. Może kwestia jest przypisanych `PATH` do procesu.

Masz jakiś output z Monsail z wykonania sudo?

zmienna PATH:

Kod: Zaznacz cały

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

log moonraker po naciśnięciu shutdown w WebUI:

Kod: Zaznacz cały

[shell_command.py:_check_proc_success()] - Command (sudo shutdown now) exited with return code 1

chętnie bym podał ścieżkę bezpośrednią do polecenia, ale nie wiem gdzie to zrobić w Moonraker lub Mainsail - być może to by pomogło?

Jeszcze jedna rzecz, która mi przychodzi do głowy, to że Moonraker działa w przestrzeni wirtualnej pythona i dlatego nie zamyka systemu? Jak wyjść poza python-env?

OK, ale powyżej masz: `/sbin/poweroff, /sbin/reboot, /bin/systemctl`, a tu jest wykonywane `sudo shutdown now`

Według tego skryptu: https://github.com/Arksine/moonraker/bl ... _fix.sh#L3

Kod: Zaznacz cały

Cmnd_Alias REBOOT = /sbin/shutdown -r now, /bin/systemctl "reboot"
Cmnd_Alias SHUTDOWN = /sbin/shutdown now, /sbin/shutdown -h now, /bin/systemctl "poweroff"
Cmnd_Alias APT = /usr/bin/apt-get
Cmnd_Alias SYSTEMCTL = /bin/systemctl
  
%GROUPNAME ALL=(ALL) NOPASSWD: REBOOT, SHUTDOWN, APT, SYSTEMCTL

User `klipper` jest nadal OK.

Generalnie zakochałem się w Klipperze

Aż zacząłem dodawać skrypty pythonowe z dodatkowymi funkcjami.

Faktycznie głupia sprawa. Patrzyłem i nie widziałem, że w sudoers mam poweroff a w logach jest shutdown

dodanie NOPASSWD: /usr/sbin/shutdown załatwiło problem zamykania systemu.

Pozostał jeszcze problem nr 1, czyli gubienie adresów drukarek przez Mainsail po każdym restarcie.

Nie wiem. Logi? Jak wygląda konfiguracja, itd.?

Konfiguracja mooraker'a taka jak mi zrobił KIAUH:

Kod: Zaznacz cały

[server]
host: 0.0.0.0
port: 7126
enable_debug_logging: True
config_path: /home/klipper/klipper_config/printer_2
klippy_uds_address: /tmp/klippy_uds-2

[authorization]
enabled: True
api_key_file: ~/.moonraker_api_key
trusted_clients:
    127.0.0.1
    192.168.0.0/16
    ::1/128
    FE80::/10
cors_domains:
    http://*.local
    https://*.local
    http://my.mainsail.xyz
    https://my.mainsail.xyz
    http://app.fluidd.xyz
    https://app.fluidd.xyz
    http://192.168.1.55
    http://192.168.1.55:*

[update_manager]

[update_manager client mainsail]
type: web
repo: meteyou/mainsail
path: ~/mainsail

[update_manager client fluidd]
type: web
repo: cadriel/fluidd
path: ~/fluidd

#[update_manager client KlipperScreen]
#type: git_repo
#path: /home/klipper/KlipperScreen
#origin: https://github.com/jordanruthe/KlipperScreen.git
#env: /home/klipper/.KlipperScreen-env/bin/python
#requirements: scripts/KlipperScreen-requirements.txt
#install_script: scripts/KlipperScreen-install.sh

w logach tym razem nie bardzo wiem czego mam szukać?

Zakładam, że raczej musisz mieć wiele moonrakerków z wieloma konfigami skonfigurowanych. To jest jeden z nich.

Zakładam, że jeden może obsługiwać jedneo Klippera.

Instalacja Klippera i Moonraker'a jest jedna, po prostu są uruchomione w osobnych procesach dla każdej drukarki z indywidualnymi konfiguracjami. Mainsail jest wspólny dla wszystkich i odwołuje się każdej instancji Moonrakera po różnych portach. Zasadę działania rozumiem, tylko nie wiem czego szukać w logach, żeby znaleźć przyczynę gubienia adresów drukarek w Mainsail. Klipper i Monraker uruchamiają się poprawnie, to Mainsail ma problem z zapamiętaniem konfiguracji.

Czy jest jakaś wymierna korzyść z połączenia malinki z mcu bezpośrednio przez UART zamiast przez USB?

nie ma

Berg pisze:nie ma

w teorii nie ma. W praktyce jak spotkałem się z dwoma:
- SKR 1.4 Turbo, z jakiegoś powodu połączenie bezpośrednie USB zrywało bardzo często, testowane różne kable itd. połączenie bezpośrednie UART + FT232RL działa stabilnie
- "mniejsze kable" przy samej elektronice

Jeżeli użyłeś FT232RL to to już nie jest połączenie bezpośrednie UART-UART. W jakim celu i gdzie użyłeś FT232RL?

cyfron pisze:Jeżeli użyłeś FT232RL to to już nie jest połączenie bezpośrednie UART-UART. W jakim celu i gdzie użyłeś FT232RL?

Bo Klipper nie działa na Rassberry Pi tylko na starym tablecie Lenovo Mix jakiś tam który nie ma wbudowanego UART. Tak że było to najbardziej "bezpośrednie" połączenie jakie dało się uzyskać z wykorzystaniem UART.

Czyli nic nie zmieniłeś w samej idei połączenia, jednie zamieniłeś konwerter CH340 na FT232RL - w jednym i drugim przypadku transmisja idzie przez konwerter USB-UART.

Pytanie drugie. Czasem Klipper zrywa mi połączenie - połączenie jest na stosunkowo długim kablu USB i podejrzewam, że to może być przyczyną. Czy jeżeli obniżę baudrate z 250000 na 115200 to UART nadąży za poleceniami klippera, czy będzie się zapychał?

cyfron pisze:Czyli nic nie zmieniłeś w samej idei połączenia, jednie zamieniłeś konwerter CH340 na FT232RL - w jednym i drugim przypadku transmisja idzie przez konwerter USB-UART.

Zmieniłem, SKR 1.4 nie ma konwertera CH340, usb jest tam obsługiwane bezpośrednio przez procesor LPC na którym leci firmware drukarki.

reprapy.pl

Klipper Firmware

Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: RE: Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: RE: Re: Klipper Firmware

Re: Klipper Firmware

Re: RE: Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware

Re: Klipper Firmware