1.3, to chyba ostatnia

Moja się sama wyleczyła

krzaku pisze:Sprawdzałeś na nowej karcie SD? Mimo że z niej nie drukujesz to może firmware próbuje coś czytać a jak karta jest uszkodzona to mogą być problemy. Ja miałem podobnie na Duecie, płytka się często resetowała podczas odświeżania WebUI, okazało się to być winą uszkodzonej karty SD.

Sprawdzałem 4 różne karty. Przyjąłem, że 4 próby eliminują możliwość uszkodzonej karty SD

No gwarancji nie ma, że jest elektrycznie ok, tylko wtedy smoothie musiałby w jakiś specyficzny sposób wyzwalać ten błąd. Jakoś nie mogę sobie tego wyobrazić. Wrzucę starszy firmware, a może nawet wersję MKS sprzed 2 lat i zobaczę

No i na marlinie poszło. Całkiem chyba nieźle jak na pierwszy wydruk bez żadnego tuningu

dziobu pisze: W sumie to może. Jest jeszcze jeden pomysł:
zwiększ mikrokrok x2 (do 32; tyle masz domyślnie?) i zmniejsz szybkość druku 2x.

Tak zrobiłem i niestety to samo. Teraz leci na Marlin 2.0. I leciiiiii. Nic się nie dzieje, zaraz koniec druku.

mcxmcx pisze:Skończą jak multikopter, jeżeli ktoś jeszcze ich pamięta

A kolega powinien sobie wrzucić jedna generację w tył software, i ówczesny, starszy konfig.

Może to jest powodem, większość ma bez problemowo działające płytki.

Co masz na myśli? W smoothie nie ma poprzedniej generacji, pracuje się tylko n edge. Chyba, że jakiś inny pomysł

dragonn pisze:zen widziałem Twój post na githubie. Rozumiem ich niechęć do MKS ale jak dla mnie z takim podejściem tylko więcej tracą niż to jest warte bo tracą potencjalnych klientów. Ja teraz już wiem że na pewno nie kupię nigdy smoothieboard. Z takim podejściem dev-ów nie warto się w to pakować, to już wolę Marlina xDDD.

No ja też musze się przeprosić z Marlinem. Ale smoothieware jest zajebiście fajne w konfiguracji, miałem nadzieję, że Marlin 2 też dostanie konf w pliku, a nie w zmiennych

Zrobiłem błąd kupująć MKS Sbase, ale nie znałem szczegółów i niechęci devów do userów Następny na pewno będzie DuetWiFi, ale tyle kasy poszło na HEVO, że musiałbym się wyprzedać.

dziobu pisze:

zen pisze:

skmskm pisze:Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).

Jesteś pewien? One są wykorzystywane tylko, kiedy robisz home do max, a nie min. W kodzie też tak to wygląda.

To również jest ograniczenie pracy jeśli nie masz krańcówki w daną stronę. Ja mam krańcówki przy min a tymi wartościami określam maksymalny ruch w danej osi. A Ty masz:

Kod: Zaznacz cały

gamma_max_endstop nc 

Spytam jeszcze raz: jesteście pewni? Smoothie nie ma software endstops. To jest wręcz niemożliwe, by działało, bo to jest oznaczenie pozycji po home do maksa:
"alpha_max 250 # This gets loaded as the current position after homing when home_to_max is set"

Czyli robisz home danej osi, i ta wartość się ładuje jako pozycja. Nie ma raczej możliwości, aby to działało tak jak mówicie, chyba że Smoothie ma błąd, o którym nawet twórcy nie mają pojęcia

skmskm pisze:Ja miałem dziwne problemy przez alpha_max , beta_max , gamma_max, nie mogą być puste musza mieć wartość(właśnie skończyło drukować).

Jesteś pewien? One są wykorzystywane tylko, kiedy robisz home do max, a nie min. W kodzie też tak to wygląda.