reprapy.pl

Cześć,

od jakiegoś czasu zastanawiam się czego ludzie używają częściej w drukarkach 3D, Marlin czy Repetier? Mówimy tutaj głównie o reprapach bo drukarki np. Zortrax czy Ultimaker mają swoje oprogramowania . Wiem że zarówno są fani Marlina jak i Repietier ma swoich zwolenników. Chętnie posłucham opinii obu stron
Ja osobiście w obu drukarkach mam Marlina, ale zastanawiam się czy nie spróbować Repetier

Pozdrawiam

Repetier - łatwa konfiguracja online

Repetier z powodu prostego w użyciu konfiguratora online

Marlin bo wolę edytować kod niż klikać .

Sory, ale ja też Marlin. Według mnie kod jest czytelniejszy.

Repetier, bo ma bardziej rozbudowane meny z panelu, oraz więcej przydatnych funkcji dostępnych z panelu, podczas druku z karty.

Ultimaker ma Marlina od zawsze.

Używam i Marlin, i Repetier.
Zaryzykuję stwierdzenie, że są równie dobre.

Nie ma to jak smoothieware

Jak zawsze gdzie dwóch Polaków tam trzy opinie

T.

trochę wczoraj pokompilowałem firmwerów. Zgłosiłem parę bugów, coś od razu naprawiłem.

I pozwalam sobie na takie podsumowanie:

Repetier, Merlin, Mk4Due, (inne mało się rozwijają) idą w stronę rozbudowy HAL (hardware abstraction layer) niby dobrze, ale postawienie tej granicy, gdzie jest HAL a gdzie konfiguracja nie jest oczywiste. Przykład z wczoraj. W Merlinie ktoś zaproponował dodać parametr FAN_INVERTED_PINS. Dla elektroniki z odwróconą logiką. No i spoko. ale w mojej akurat wentylatory nie mają odwróconej a grzałki mają. mam dwa wentylatory podpięte pod dedykowane wyjścia a trzeci podpięty po nieużywaną trzecią grzałkę ekstrudera. I własnie ten trzeci muszę odwrócić. OStatecznie raczej trzeba wywalić ten parametr lub konfigurować osobno każde wyjście. Ostatecznie ktoś odpowiedział, że da się to też ustawić gcodem, czyli całkiem nie w warstwie HAL. .... co za bałagan!

Trzeba by iść w kierunku dalszej specjalizacji na poziomie sprzętowym. Czyli coś w stylu Motion Controler odpowiedzialny jedynie za ruchy np na AVRze drugi kontroler odpowiedzialny np za grzałki, wentylatory. Wszystko sterowane przez Raspberry i kod np w Pythonie. To jest dobra strategia dla OpenSource. Zintegrowane kontrolery to ja widzę już tylko dla komercyjnych zastosowań. Społecznościowo są już nierozwojowe.
Kod znanych nam firmwarów jest tak zabagniony, że nic z niego nie będzie w dłuższym czasie. Jeszcze jakimś wysiłkiem uda się dodać obsługę TMC, może coś jeszcze.

Czyli czas przetestować Klippera? , tak sobie myślę że jak by do niego dorobić obsługę wyświetlacza to to już całkiem używalne by było.

w sumie. popatrz. przy takim rozwiązaniu, było by łatwiej np dodać silniki poprzez podłączenie dwóch zwykłych arduino z RAMPSEM, gdy pomyslisz o podwójnym Z, podwójnym X i Y na przykład. Mogło by być tanio i wydajnie.

Przy rozbiciu obsługi silników na różne uC pojawia się problem synchronizacji jazdy. Imho wszystkie silniki powinny być zawsze z jednego urządzenia.

Też tak myślę, ale rozbicie obliczeń i sterowania na różne uC to moim zdaniem prawidłowy kierunek.

Jak jest przymus korzystania z Arduino to tak. Natomiast współczesne uC typu Cortex M4 czy M7 spokojnie sobie z tym radzą na bieżąco.

Natomiast do takiej pracy wystarczy przejściówka USB<->I/O, coś typu FTDI FT4232H. Wysyłasz na głupa dane a on z zadaną częstotliwością je wystawia na linie OUT i zwraca IN. Załatwiasz tym całą jazdę. Arduino nie jest tu potrzebne.
Takie rozwiązanie ma też wady: m.in modyfikacja parametrów pracy (jak już masz wygenerowane wszystkie kroki na cały cykl pracy) na bieżąco (np flow) jest dość trudne, lub wręcz niemożliwe,

I pytanie czy takie przekombinowanie faktycznie da jakieś pozytywne rezultaty dla samego druku.

[zapomniałem ;p]
Smoothieware.

dziobu pisze:modyfikacja parametrów pracy

W Marlinie jak zmienisz flow czy speed też trzeba czekać aż się buffor zwolni , nie jest to "od razu". Tak że nie byłby to jakiś problem. Oczywiście masz rację że takie Cortexy sobie poradzą z wszystkim ale jak mówił rafaljot łatwiej rozwijać kod w społeczności jak jest on podzielony na osobne "moduły" które tylko z sobą się komunikują.

dziobu pisze:Jak jest przymus korzystania z Arduino to tak. Natomiast współczesne uC typu Cortex M4 czy M7 spokojnie sobie z tym radzą na bieżąco.

Natomiast do takiej pracy wystarczy przejściówka USB<->I/O, coś typu FTDI FT4232H. Wysyłasz na głupa dane a on z zadaną częstotliwością je wystawia na linie OUT i zwraca IN. Załatwiasz tym całą jazdę. Arduino nie jest tu potrzebne.
Takie rozwiązanie ma też wady: m.in modyfikacja parametrów pracy (jak już masz wygenerowane wszystkie kroki na cały cykl pracy) na bieżąco (np flow) jest dość trudne, lub wręcz niemożliwe,

I pytanie czy takie przekombinowanie faktycznie da jakieś pozytywne rezultaty dla samego druku.
[zapomniałem ;p]
Smoothieware.

1. Sam tego firmwaru nie sprawdziłem ale zamierzam wnet. Główną zaletą, którą się chwali autor jest właśnie jakość druku. Możliwość napisania znacznie bardziej złożonych algorytmów.

2. Kłopot jaki widzę, ten o którym napisałem wyżej, fajnie było póki Merlin był na AVRa ale teraz chcą ogarnąć go na różne architektury i obstawiam że nie ogarną tak by było stabilnie. Kombinacje/permutacje architektury/wyświetlaczy/teraz jeszcze stepstików nie koniecznie tylko ze sterowaniem step-dir to o jeden rząd za dużo. PRzy takiej architekturze jak klipper. CZęść softu jest w uniwersalnym języku, który sam z siebie zapewnia przenaszalność na dowolną architekturę bez jakiegokolwiek kombinowania. A część sprzętowa jest na tyle odchudzona, że spokojnie dalej może wrócić do atmegi.

btw: coś czuję, że Prusa kombinuję w tę stronę.

rafaljot pisze:

dziobu pisze:Jak jest przymus korzystania z Arduino to tak. Natomiast współczesne uC typu Cortex M4 czy M7 spokojnie sobie z tym radzą na bieżąco.

Natomiast do takiej pracy wystarczy przejściówka USB<->I/O, coś typu FTDI FT4232H. Wysyłasz na głupa dane a on z zadaną częstotliwością je wystawia na linie OUT i zwraca IN. Załatwiasz tym całą jazdę. Arduino nie jest tu potrzebne.
Takie rozwiązanie ma też wady: m.in modyfikacja parametrów pracy (jak już masz wygenerowane wszystkie kroki na cały cykl pracy) na bieżąco (np flow) jest dość trudne, lub wręcz niemożliwe,

I pytanie czy takie przekombinowanie faktycznie da jakieś pozytywne rezultaty dla samego druku.
[zapomniałem ;p]
Smoothieware.

1. Sam tego firmwaru nie sprawdziłem ale zamierzam wnet. Główną zaletą, którą się chwali autor jest właśnie jakość druku. Możliwość napisania znacznie bardziej złożonych algorytmów.

2. Kłopot jaki widzę, ten o którym napisałem wyżej, fajnie było póki Merlin był na AVRa ale teraz chcą ogarnąć go na różne architektury i obstawiam że nie ogarną tak by było stabilnie. Kombinacje/permutacje architektury/wyświetlaczy/teraz jeszcze stepstików nie koniecznie tylko ze sterowaniem step-dir to o jeden rząd za dużo. PRzy takiej architekturze jak klipper. CZęść softu jest w uniwersalnym języku, który sam z siebie zapewnia przenaszalność na dowolną architekturę bez jakiegokolwiek kombinowania. A część sprzętowa jest na tyle odchudzona, że spokojnie dalej może wrócić do atmegi.
Ta uwaga nie dotyczy tego, że się nie da inaczej. Tu chodzi o to jak jest łatwiej rozwijać oprogramowanie w sposób uniwersalny, z dużym zaangażowaniem społeczności, która z natury będzie mieć różny sprzęt.

btw: coś czuję, że Prusa kombinuję w tę stronę.

ps: mam dwa repetiery, jednego merlina, niestety nie da się tego wpisać w ankiecie. Przeważa Repetier. wpisuję zatem Repetiera. Zaraz moze się to zmienić

dziobu pisze: I pytanie czy takie przekombinowanie faktycznie da jakieś pozytywne rezultaty dla samego druku.

popatrz tu:
https://github.com/KevinOConnor/klipper ... ematics.md

Kurcze trzeba to przetestować w końcu .

Wiem, czytałem (Zawsze czytam bo czasem można się czegoś ciekawego dowiedzieć.)
Tyle że podobne rozwiązania stosuję w profilometrze/kształtografie bez potrzeby użycia PC i CM4 świetnie sobie radzi (a tam jest problem rozhuśtania/rezonansu igły pomiarowej). W swojej frezarce mam to samo - zawsze krokami zarządza uC. Ale fakt, jest to rozwiązanie dopasowane do sprzętu i zmiana procesora nie jest przesadnie łatwa. Z HALa też nie korzystam, bo w przypadku STMa powinno być to karalne. Ale coś za coś.

Wracając do tematu - imho dużo prościej użyć FTDI do takiej jazdy. Jest o niebo szybsze i samo dba o buforowanie danych.

dziobu pisze: Wracając do tematu - imho dużo prościej użyć FTDI do takiej jazdy. Jest o niebo szybsze i samo dba o buforowanie danych.

prawda. Jednak buforując komendy "samemu" można oddzielić komendy sterujące ruchem od innych. na przykład HALT. i taką wykonać od razu.

Zawsze haltem można odcinać zasilanie takiemu FTDI, lub ogólnie odcinać zasilanie .

rafaljot pisze:

dziobu pisze: Wracając do tematu - imho dużo prościej użyć FTDI do takiej jazdy. Jest o niebo szybsze i samo dba o buforowanie danych.

prawda. Jednak buforując komendy "samemu" można oddzielić komendy sterujące ruchem od innych. na przykład HALT. i taką wykonać od razu.

Czyszczenie bufora daje ten sam efekt: stop w czasie <1ms. No chyba że potrzebujesz szybciej ale tego USB Ci już nie da
A jak puścisz transmisję synchroniczną to z FTDI wróci dokładnie to co on zdążył wystawić na nóżki. Innymi słowy - nie ważne jaki masz bufor (scalak ma 64kB, w PC sterownik nie ma ograniczeń) i jak z niego korzystasz, zawsze dokładnie wiesz gdzie jesteś.

I kolejny plus - FTDI ma sterowniki i przykładowe programy na chyba każdy dostępny system operacyjny i nie wymaga pisania dodatkowego softu na uC. A to spore ułatwienie.

no to luz:
2x chińskie mega2560 bo one mają FTDI a nie megę na USB. ...... 2x$7
2x chińskie rampsy .....2x$4 (albo zaszalejmy ramps 1.5 za $6)
OrangePi zero .........$9

wszystko razem daje 10 gniazd na stepstiki, 6 mosfetów, wifi, bluetooth, czterordzeniowy procesor do obliczeń i interfejsu użytkownika. Kupę wolnych pinów i Wszystko za $31

Klipper obsługuje kilka strumieni danych do AVRów i ich synchronizację.

Da się czymś przebić taką konfigurację np. pod multikolor?

Marlin - do początku zabawy z drukiem 3D - teraz z przyzwyczajenia

rafaljot pisze:Wszystko za $31

Z takim podejściem nie wygram, przyznaję.

I zupełnie mi nie przeszkadza że ktoś chce tak robić - do domu można cuda wianki na tym odpalić. Po prostu jestem przeciwnikiem takiej "chały", tzn odpalania urządzenia (obojętne jakiego) na jakimś zestawie klocków co właśnie leżały pod nogami. W tym temacie jestem raczej estetą
(A wkurweł maksymalny osiągam jak ktoś w przemyśle wyskakuje z arduinem lub raspberry ;p)

rafaljot pisze:Klipper obsługuje kilka strumieni danych do AVRów i ich synchronizację.

Nie ma synchronizacji. Wylicza opóźnienia bazując na zegarach.
Bardzo ciekawe rozwiązanie sztucznie stworzonego problemu ;p
(w takich sytuacjach puszcza się linię synchronizacji lub pędzi się wszystkie uC magistralą ze wspólnym zegarem)

rafaljot pisze:Da się czymś przebić taką konfigurację np. pod multikolor?

Taniej? Zapewne nie.
Tylko czy drukarka ma być tania czy ma działać? W sumie odpowiedź znam - to forum reprapów a to z definicji ma być tanie ;p Niemniej ja wolę jak coś po prostu działa i tej wersji będę się trzymać.

A sterowanie jazdą przez FTDI uznałem po prostu za technicznie lepsze, z tym że tam masz max 4 napędy (8 bitów na 1 porcie). No chyba że w nowszych jest już synchronizacja wyjść ale tu nie jestem na bieżąco; wiem że takie miało być ale wcześniej przeszedłem na ARMy i nie jest mi to potrzebne ).

no wiesz. napisałem w pierwszym poście że to nie do komercyjnych rozwiązań. Ktoś kto by na to chciał dać gwarancję, CE musiał by być szalencem

Fak ;p
Napisałeś Jakoś mi umknęło.

dziobu pisze:W sumie odpowiedź znam - to forum reprapów a to z definicji ma być tanie ;p

Nie, "reprapy" się skończyły kilka lat temu.
Teraz jest epoka chińskiej taniochy niestety, ale to nie przeszkadza (moim zdaniem), żeby od czasu do czasu dobre praktyki praktykować
Nie zawsze musi być tanie. Czasem powinno być solidne, bo czas też pieniądz.
Dlaczego w przemyśle ma być solidnie? Dlaczego ci się Raspberry tam nie podoba? Bo przestój kosztuje? (a malina niejako z definicji jest awaryjna?).

Malina moim zdaniem jest taka awaryjna jak soft który na nią załadujesz.

dragonn pisze:Malina moim zdaniem jest taka awaryjna jak soft który na nią załadujesz.

jest tak bezawaryjna jak daleko leży od suwmiarki

dragonn pisze:Malina moim zdaniem jest taka awaryjna jak soft który na nią załadujesz.

Ale nie napisałeś tego chyba poważnie?

McKee pisze:

dragonn pisze:Malina moim zdaniem jest taka awaryjna jak soft który na nią załadujesz.

Ale nie napisałeś tego chyba poważnie?

Do zastosowań nieprzemysłowych/nieprofesjonalnych całkiem poważnie . Przemysł to inna sprawa.

virgin71 pisze:Ultimaker ma Marlina od zawsze.

No ja wlasnie sie zastanawiam jak bede mogl edytowac Firmware w UM2 bo pewnie jak zainstaluje Standardowy Firmware z CUry dla UM2 Extended Olson Block to kroki z extrudera beda sie pewnie roznic i wiele funkcji ktore bede chcial zmienic . Nie majac Ultimakera nigdy sie nie bawilem w.w firmware (no chyba ze z panelu LCD mozna zmienic wszystko)

PrzemoS pisze:

virgin71 pisze:Ultimaker ma Marlina od zawsze.

No ja wlasnie sie zastanawiam jak bede mogl edytowac Firmware w UM2 bo pewnie jak zainstaluje Standardowy Firmware z CUry dla UM2 Extended Olson Block to kroki z extrudera beda sie pewnie roznic i wiele funkcji ktore bede chcial zmienic . Nie majac Ultimakera nigdy sie nie bawilem w.w firmware (no chyba ze z panelu LCD mozna zmienic wszystko)

JAk zainstalujesz tinkergnome to wszystko wyedytujesz z LCD. Jak nie, to ustawisz gcodem.

RepRapFirmware. Nie wyobrażam sobie ponownej kompilacji i wgrywania softu przez kabel za każdym razem gdy chcę cokolwiek zmienić. W RRF wszystkie ustawienia są zmieniane za pomocą gcode w jednym pliku na karcie SD.