MKS SBase - reset? podczas druku

[dziobu]

Setki ludzi mają MKS Sbase w podobnych konfiguracjach. Tylko że to jest software, w którym są dziesiątki tysięcy zmiennych i nikt nie jest w stanie przetestować wszystkich ich iteracji, dlatego mamy dziwne bugi.

Nie prawda. To open-source rozwijany po części "na hura". To powoduje że niektóre rozwiązania są, delikatnie mówiąc, beznadziejne.
Mam oryginalne smoothieware i grzebię sobie trochę w starszej wersji softu - szacuję że 15-20% zasobów leci w gwizdek z powodu organziacji softu. Dużo jak na uC.

Ja nie wymagam serwisowania sprzętu, tylko pomocy z softwarem, bo jestem na 90% pewien, że to problem software'owy. To jest jednak open source. Ja im się trochę nie dziwię, bo Makerbase to cwaniaki, które nie przestrzegają otwartych licencji. Niestety nie wiedziałem tego, kiedy kupowałem płytkę. Z drugiej strony - cena czyni cuda Najpewniej uzbieram i kupię DuetWiFi, ale chciałbym już stabilnie drukować na moim HEVO.

Open source też nie gwarantuje wsparcia. A imho logiczne jest że wspierają tylko swoje, no bo co mają wróżyć z fusów kto co spieprzył w innym sprzęcie. Jak w oryginalnym działa to na tym powinna się sprawa skończyć. Imho.

A pamiętasz w jakim miejscu wydruku smoothie się wiesza? Czy zawsze w tym samym dla tego samego gcode? Jesteś w stanie określić jakie dane wtedy poszły?
Wiem że S3D potrafił generować nieprawidłowy gcode (ale slic3r też ;p). Z tym że firmware powinien sobie z tym poradzić, no ale to open-source...

[tig33r]

Spróbuj ten sam wydruk puścić na marlinie zamiast smoothie, wykluczysz problem sprzętowy.

[zen]

Setki ludzi mają MKS Sbase w podobnych konfiguracjach. Tylko że to jest software, w którym są dziesiątki tysięcy zmiennych i nikt nie jest w stanie przetestować wszystkich ich iteracji, dlatego mamy dziwne bugi.

Nie prawda. To open-source rozwijany po części "na hura". To powoduje że niektóre rozwiązania są, delikatnie mówiąc, beznadziejne.
Mam oryginalne smoothieware i grzebię sobie trochę w starszej wersji softu - szacuję że 15-20% zasobów leci w gwizdek z powodu organziacji softu. Dużo jak na uC.

W ogólności nie mogę się zgodzić, 20 lat siedzę we FLOSS i w większości przypadków QA jest lepsze niż w komercyjnych projektach. Ale co do smoothieware to niestety prawda Jest parę miejsc, gdzie Artur i Jim wiedzieli lepiej

Ja nie wymagam serwisowania sprzętu, tylko pomocy z softwarem, bo jestem na 90% pewien, że to problem software'owy. To jest jednak open source. Ja im się trochę nie dziwię, bo Makerbase to cwaniaki, które nie przestrzegają otwartych licencji. Niestety nie wiedziałem tego, kiedy kupowałem płytkę. Z drugiej strony - cena czyni cuda Najpewniej uzbieram i kupię DuetWiFi, ale chciałbym już stabilnie drukować na moim HEVO.

Open source też nie gwarantuje wsparcia. A imho logiczne jest że wspierają tylko swoje, no bo co mają wróżyć z fusów kto co spieprzył w innym sprzęcie. Jak w oryginalnym działa to na tym powinna się sprawa skończyć. Imho.

Jasne, że nie gwarantuje, ale jest jeszcze kwestia tego, jak traktują użytkowników swojego softu. Nigdzie nie jest napisane, że masz tego używać tylko ze smoothieboard. A obrzucanie użytkowników wyzwiskami jest jednak słabe, a oni są z tego wręcz sławni. Przeczytaj sobie konwersację w bugu, który wrzuciłem wyżej. Ciekawa

A pamiętasz w jakim miejscu wydruku smoothie się wiesza? Czy zawsze w tym samym dla tego samego gcode? Jesteś w stanie określić jakie dane wtedy poszły?
Wiem że S3D potrafił generować nieprawidłowy gcode (ale slic3r też ;p). Z tym że firmware powinien sobie z tym poradzić, no ale to open-source...

Nie ma znaczenia jaki wydruk, wiesza się losowo. Najpierw po 30 minutach, potem po 5, 10 - ogólnie różnie. Bug z S3D został ponoć naprawiony, zresztą ciąłem i S3D i slic3rem i kurczakiem. Ta zmiana czasu jest mocno podejrzana, bo może wymagać z temperatury. Ale jak polecali koledzy w ostatnich testach chłodzę wszystko, puszczałem nawet z odpiętymi silnikami, nic to nie zmienia, ale czyni problem jeszcze bardziej zagadkowym.

[zen]

Spróbuj ten sam wydruk puścić na marlinie zamiast smoothie, wykluczysz problem sprzętowy.

No właśnie puszczę to chyba na 2.0, ale mam na widok Marlina mdłości Liczyłem, że w 2.0 coś się zmieni, ale jest taki sam bajzel.
Przydałaby się konfiguracja pod HEVO do Marlina 2.0, nigdy na tym corexy nie robiłem.

[dziobu]

W ogólności nie mogę się zgodzić, 20 lat siedzę we FLOSS i w większości przypadków QA jest lepsze niż w komercyjnych projektach. Ale co do smoothieware to niestety prawda Jest parę miejsc, gdzie Artur i Jim wiedzieli lepiej

Otwarty kod ma szereg zalet jeśli korzysta z niego ktoś posiadający mózg. Niestety to co raz rzadziej spotykane za sprawą Arduina. Ale też dzięki niemu docenia się indywidualne wsparcie i systemy zamknięte.
Mój zakres działalnośći jest po prostu dość zamknięty - przemysł, laboratoria, jednostki badawcze. Inni klienci, inne wymagania

Jasne, że nie gwarantuje, ale jest jeszcze kwestia tego, jak traktują użytkowników swojego softu. Nigdzie nie jest napisane, że masz tego używać tylko ze smoothieboard. A obrzucanie użytkowników wyzwiskami jest jednak słabe, a oni są z tego wręcz sławni. Przeczytaj sobie konwersację w bugu, który wrzuciłem wyżej. Ciekawa

Tak, zgoda. W sumie to nie czytałem tegoż forum (sam grzebię w sofcie, bo lubię ;p) ale rzeczywiście w wielu miejscach leci po bandzie. To dobrze - kolejny impuls żebym w końcu swój zaczął kończyć ;p

Nie ma znaczenia jaki wydruk, wiesza się losowo. Najpierw po 30 minutach, potem po 5, 10 - ogólnie różnie. Bug z S3D został ponoć naprawiony, zresztą ciąłem i S3D i slic3rem i kurczakiem. Ta zmiana czasu jest mocno podejrzana, bo może wymagać z temperatury. Ale jak polecali koledzy w ostatnich testach chłodzę wszystko, puszczałem nawet z odpiętymi silnikami, nic to nie zmienia, ale czyni problem jeszcze bardziej zagadkowym.

Jak jest w róznych losowych miejscach to obstawiam że jednak nie jest to błąd programowy. Mimo wszystko smoothie aż takim syfem nie jest i nie ma cech polimorfizmu więc konsekwentnie powinno wykładać się w tym samym miejscu.

Trochę się też pogubiłem - na mikrokroku 16 wszystko działa prawidłowo?

[dziobu]

Jeszcze jedno - nie masz w konfigu "planner_queue_size" a to dość istotne. Nie wiem jaką to ma wartość domyślną - dodaj na wszelki wypadek:

Kod: Zaznacz cały

planner_queue_size 32

[zen]

Jeszcze jedno - nie masz w konfigu "planner_queue_size" a to dość istotne. Nie wiem jaką to ma wartość domyślną - dodaj na wszelki wypadek:

Kod: Zaznacz cały

planner_queue_size 32

Też się nad tym zastanawiałem, ale konfiguracja przykładowa też tego nie ma. Dodam i zobaczę. Dzięki za hinta

[skmskm]

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ć).

[zen]

Jak jest w róznych losowych miejscach to obstawiam że jednak nie jest to błąd programowy. Mimo wszystko smoothie aż takim syfem nie jest i nie ma cech polimorfizmu więc konsekwentnie powinno wykładać się w tym samym miejscu.

Trochę się też pogubiłem - na mikrokroku 16 wszystko działa prawidłowo?

No ja się pogubiłem Tak, na 16 wszystko działa cacy. Zastanawiam się jak to może wpływać jednak na ilość operacji do przeprowadzenia i możliwość wywalania się. Podepnę się jeszcze jak znajdę czas pod MRI i zrobię zrzut, obiecali mi, że w to zajrzą.

[zen]

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.