karetka z własną elektroniką

[dragonn]

Trzeba jeszcze rozwiązać problem synchronizacji czasu. CAN to jakoś tam wspiera (nie wiem, nie używałem).
Do podobnych systemów stosujemy drugi zestaw linii (sprzętowo na bazie RS485) na którym leci zegar.

Oczywiście dobrze by było to zrobić na bazie RS232/RS488 wtedy żeby transmisja była odporniejsza na zakłocenia.

RS232 nie jest odporny. Poza tym RS485 jest lepszy pod wieloma względami

Klipper załatwia synchronizację (jakoś).
RS232 jest bardziej odporny na zakłócenia niż zrobienie UART na poziomach TTL/3.3V .
RS485 nie podałem bo wydaje mi się że Klipper wymaga łącza full-duplex, nie half-duplex.

[Robin]

RS485 nie podałem bo wydaje mi się że Klipper wymaga łącza full-duplex, nie half-duplex.

Można konwertować UATR TTL na RS422.
Jakby był dostępny schemat tego rozszerzenia Duet to można by pokusić się wcisnąć tam klippera

[Holgin]

Dobór warstwy fizycznej komunikacji to najmniejszy problem wyzwaniem będzie spięcie tego czasowo-programowo.

[dragonn]

Jakby był dostępny schemat tego rozszerzenia Duet to można by pokusić się wcisnąć tam klippera

Schematy na pewno są dostępne na ich githubie, jak że te płytki na pewno też są opensource.

Dobór warstwy fizycznej komunikacji to najmniejszy problem wyzwaniem będzie spięcie tego czasowo-programowo.

Dlatego piszę o klipperze który powonień to załatwić

[etet100]

Chyba zapomniałem wspomnieć, że silnik akurat zostawiam po staremu. Inaczej to by była misja samobójcza.

[Holgin]

W takim razie można to zrobić spokojnie bez ingerencji w Marlina czy cokolwiek innego, tylko pytanie czy będzie z tego jakiś zysk?

[etet100]

Zysk pewnie nieduży.

Jak bez ingerencji? Chyba aż tak łatwo nie będzie.

[dragonn]

Zysk pewnie nieduży.

Jak bez ingerencji? Chyba aż tak łatwo nie będzie.

Mam wrażenie że nie słuchasz tego co się pisze.
Holgin miał pewnie na myśli że obeszło by się bez ingerencji w Marlina jak by użyć Klippera który bez żadnych modyfikacji powonień to obsłużyć.

[Holgin]

Nie, nie miałem Klippera na myśli - raczej jeden dodatkowy mały proc, który by "tłumaczył" sygnały jak PWM z płyty głównej i wysyłał je do drugiego proca w głowicy i vice versa. Trzeba robić dwie płytki i dwa razy programować, ale jest się kompletnie niezależnym od Firmware.

Tak czy inaczej nie widzę za dużego sensu w ogóle robienia takiego modułu poza bardziej profesjonalnymi rozwiązaniami z CAN jak w Duet.

[Robin]

Początkowo zapaliłem się do pomysłu ponieważ mam drukarkę na klipperze z podwójną głowicę, więc bat przewodów jest dość pokaźny.
Z klipperem jest pewien problem - endstop Z musi być podłączony do tego samego mcu co motory osi Z. Można więc zapomnieć o podłączaniu czujników montowanych na głowicy.
Pomysł Holgina ma sens, ponieważ przesyłane sygnały nie są krytyczne czasowo.