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

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

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?

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.

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

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

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: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ę.

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.

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.