reprapy.pl

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