Prusa i3 mk3s remake

[XisD]

1. Mam właśnie na biurku rPi3 i wyświetlacz 4'' Jak ostatnio coś na nim robiłem to działało pięknie. Parę dni temu wyjąłem z szuflady po pół roku i nie działa. Osobno LCD działa, rPi podłączone do TV działa. Razem nie. Po podaniu osobno zasilania do rPi i osobno do wyświetlacza, spięciu kablem HDMI - działa. Wniosek? Może zaśniedziały styki mikro-usb, może coś innego się stało, że teraz prądu potrzebuje więcej.

Jakkolwiek pasuje u Ciebie poprawić to zasilania oraz połączenie z Einsy.

rPi najlepiej zasilić podając napięcie bezpośrednio na piny. Już pominę kwestię tych złączek. One to do druta 2,5 są a nie kabelka 0,25...

Spiąć serial z Einsy najlepiej też pinami RX/TX. Właśnie Einsy specjalnie je ma. Opisane jest na stronie Prusy. Z tym, że trzeba użyć dwóch kabelków a nie wpinać, bo rpi3 za duże.

Generalnie będziesz miał mniej dziwnie odstających kabli i całość będzie lepiej wyglądać.

2. Jakkolwiek szansa, że to pomoże jest jak 1:10 Gubi kroki pewnie dla tego, że się przegrzewa . Obniż prąd na stepach, prędkości, max przyspieszenia i takie tam. Daj lepsze chłodzenie elektroniki.

Masz założone radiatory na stepstiki od spodu płytki ?

Co tam jeszcze do tego rPi masz podłączone? Co to za grube czerwone kable?

Hmm pomyślę nad tym podłączeniem do windy bezpośrednio, na einsy jak i raspberry mam radiatorki poprzyklejane od samego początku, szczerze prąd nie wiem naeet jak tu obiznyc, silniki i płyta główna są od Prusy i nic nie grzebalem tam nigdy ale dziwne że na kablu idzie wszystko dobrze a poprzez wifi się pierdzieli

Te kable to idą od zasilania do płyty einsy

[mpk]

/methinks
cała ta teoria o rpi jako przyczynie przesunięcia mi się nie spina, zwłaszcza w przypadku komunikacji USB.
toż to sygnał cyfrowy, ten z natury swej albo jest, albo go nie ma. nie ma, że jest trochę.
jeżeli jest gówniana jakość kabli, albo zakłócenia, to albo pójdzie retransmisja, albo komunikacja w ogóle się urwie.
Jeżeli retransmisji będzie niespotykanie dużo, to możnaby pewnie zaobserwować jakieś opóźnienia, głowica gdzieś przystanie czekając na kolejne instrukcje, ale przecież nie zacznie nagle drukować drugiej warstwy w innym miejscu.

Ten potworek zawinięty taśmą izolacyjną to skąd ciągnie prąd? może sieje ci to jakimiś zakłóceniami, i jeżeli współdzieli zasilacz z einsy, to może ma to jakiś wpływ na działanie silników (daleki strzał).

[mpk]

szczerze prąd nie wiem naeet jak tu obiznyc

https://marlinfw.org/docs/gcode/M906.html

[XisD]

/methinks
cała ta teoria o rpi jako przyczynie przesunięcia mi się nie spina, zwłaszcza w przypadku komunikacji USB.
toż to sygnał cyfrowy, ten z natury swej albo jest, albo go nie ma. nie ma, że jest trochę.
jeżeli jest gówniana jakość kabli, albo zakłócenia, to albo pójdzie retransmisja, albo komunikacja w ogóle się urwie.
Jeżeli retransmisji będzie niespotykanie dużo, to możnaby pewnie zaobserwować jakieś opóźnienia, głowica gdzieś przystanie czekając na kolejne instrukcje, ale przecież nie zacznie nagle drukować drugiej warstwy w innym miejscu.

Ten potworek zawinięty taśmą izolacyjną to skąd ciągnie prąd? może sieje ci to jakimiś zakłóceniami, i jeżeli współdzieli zasilacz z einsy, to może ma to jakiś wpływ na działanie silników (daleki strzał).

Przetworniczka bierze prąd z zasilacza tego samego gdzie podpięta jest drukarka (zasilacz->przetwornica->raspberry a potem od raspberry idzie kablem usb do Einsy) , uzywalem kiedys jeszcze ledow ale nie wlaczam ich wiec sadze ze zapasu pradu ma na pociagnieciego tego zwlaszcza jak rok nic jej nie bylo :#

[Berg]

Przy błędach komunikacji często zdarza się przesunięcie. przy czym wygląda ono ciut inaczej. Głowica odjeżdża w którąś stronę z normalną prędkością i drukuje dalej. Coś bardziej w tym stylu.

Drivery więcej ciepła oddają drugą stroną. od spodu płytki. masz tam radiatory, dziurki w obudowie, jakiś nadmuch i dobry przewiew? od wierzchu widzę, że ta wiązka kabli co idzie do głowicy też istotnie je zasłania, więc cyrkulacja powietrza też jest słaba.

Za to radiatory na rPi nie są potrzebne.

[morf]

Ej a pusc jakis monitoring zasobow, moze jest jakis proces na rpi ktory raptem robi peak CPU co wplywa negatywnie na komunikacje szeregowa z drukarka.
Octoprint przeszedl jakis czas temu wylacznie na pythona3, moze cos tam Ci sie dependences posypaly.

Najszybciej to chyba wziac czysta karte i zaflaszowac czystego raspbiana albo od razu jakies distro z octoprint, i puscic *dokladnie ten sam gcode* jesli to nie rozwiaze problemu to bedzie wiadomo ze hardware

[Berg]

@morf Klippera+MainSail... aż się prosi przy rPi+Einsy. A Octoprinta wywalić.

Popatrz na czwarte zdjęcie z wątku o mojej prusie.
viewtopic.php?t=4251

Przez czarne szczebelki zaraz na prawo od pomarańczowej klapki na małe rPi widać od spodu radiatorki. z resztą od drugiej strony, na piątym zdjęciu też są, tylko trzeba się lepiej przyglądnąć bo są czarne, też trochę zasłonięte przez kable ale mniej.

Widzę, że Twoja obudowa na elektronikę nie jest za dobrze pomyślana.

[mpk]

Przy błędach komunikacji często zdarza się przesunięcie.

Po USB? Po uarcie, bez kontroli błędów może. ale na usb jest i kontrola i korekcja. by design.

Głowica odjeżdża w którąś stronę z normalną prędkością i drukuje dalej. Coś bardziej w tym stylu.

Po czym przejdzie do kolejnej warstwy, gdzie znów będzie miała instrukcje by pojechać do bezwzględnych współrzędnych i wysrać jakiś plastik.

[morf]

jak masz przesuniecie warstwy to nie ma zadnego znaczenia czy masz absolute czy relative coordinates bo elektronika (tak standardowo o enkoderach/serwach nie mowie) nie jest "swiadoma" w którym miejscu jest.

Klippera+MainSail... aż się prosi przy rPi+Einsy. A Octoprinta wywalić.

ee za duzo zmiennych bedzie, 1 zmienna na 1 zmiane

[XisD]

Wyjalem raspberry i rpzetworncie umiescilem w miare daleko od siebei na kablach ale to nic nie zmieniło, nagralem 2 filmiki w czasie przeskoku nie jest to najlepsza jakosc no ale jakas jest


2 sekunda filmu skok
https://youtu.be/R26L8RSvybs

7 sekunda filmu skok
https://youtu.be/vTvdf_HLSug