Obsługa 3 anet z jednego PC.

[stawiniakPOL]

Z przyczyn organizacyjno-technicznych drukowanie z komputera może spowodować braki danych i przestoje podczas druku; poza tym jakakolwiek niestabilność komputera i masz wydruk w plecy.

No o tym nie pomyślałem z tej perspektywy. A wydruki wykonuję spore z powodu mojego zajęcia. I faktycznie 20 godzin druku jak przepada to boli

[dziobu]

Drukowanie z PC może mieć sens jak drukujesz półgodzinne pierdółki. Ale przejście się raz dziennie do drukarki z kartą SD raczej nie powinno być problemem.

[stawiniakPOL]

A drukowania przez USB z PCta dlaczego nie polecasz??

Są dwa powody:
- drukowanie przez USB potrafi nie wyrabiać przy skomplikowanych wydrukach/dużej szczegółowości pliki STL, drukarka wtedy przycina i robi bloby na wydruku. Są rozwiązania żeby to obejść, np. niektóre slicery mają parametr który ustawia maksymalną szczegółowość generowanego g-codu, zastępie Marlina Klipperem (ale to już w ogóle inna jazda) itp. Dla ścisłości, to nie tak że USB jest za wolne, za wolna jest komunikacja UART której jest symulowana po USB oraz g-code to strasznie nieefektywny protokół do pchania dużej ilości danych.
- zakładając że używasz Windowsa a szczególnie dotyczy to 10, to system które potrafi robić sobie co chce czasami jak widzi że jest nie zajęty przez użytkownika. Wystarczy durna aktualizacja systemu i wydruk do kosza, a w twoim przypadku 3.

Ooooo spoko, dzięki za merytorykę.

To postanowione - drukowanie będzie z kart zdecydowanie.

Połączenie USB do celów serwisowych jednak musi być.

BTW, bardzo sprawnie Forum działa - DZIĘKI BARDZO Już jakiś zarys mam i widzę mniej więcej w którą stronę patrzeć

[stawiniakPOL]

Drukowanie z PC może mieć sens jak drukujesz półgodzinne pierdółki. Ale przejście się raz dziennie do drukarki z kartą SD raczej nie powinno być problemem.

Tak tak, masz rację. Tzn, ogólnie macie wszyscy którzy tak mi przedstawiają sprawę mają rację, jak widzę "złożoność problemu w eksploatacji" i tak głębiej się nad tym zastanawiam

[mpk]

@1, to moim zdaniem nie do końca.
jak zestawisz tą komunikację na powiedzmy 115200 bodów, to tyle ma być. to nie jest best effort.
odpada nam z tego bit startu, stopu i (chyba niekoniecznie) jeden na kontrolę parzystości. Zostaje zatem ~60% pasma na "mięso".
Czyli koło 9KB/s. Czyli dobrze ponad 300 linii przeciętnego gcodu.
żeby urządzenie obrabiało >300 linii poniżej sekundy, to musiałby to być absurdalnie wysoki poziom szczegółowości;)

Ale żeby nie było - nie twierdzę, że na usb z drukarkami problemów nie ma. Sądzę tylko, że przyczyna jest inna - badziewne chińskie konwertery, badziewniejsze kabelki, niefortunne rozmieszczenie na PCB itp..

[dziobu]

[OT]

Czyli koło 9KB/s. Czyli dobrze ponad 300 linii przeciętnego gcodu.

115200/(start+8+stop) -> ~11KB.

Ale żeby nie było - nie twierdzę, że na usb z drukarkami problemów nie ma. Sądzę tylko, że przyczyna jest inna - badziewne chińskie konwertery, badziewniejsze kabelki, niefortunne rozmieszczenie na PCB itp..

To transmisja cyfrowa. I nie jest ona zrywana ani też problemem nie są zakłócenia. D*py daje głównie firmware i organizacja odbioru danych.

btw.
Trzeba by się trochę napocić żeby ułożenie elementów na prostej PCB wpływało na cyfrowe sygnały z zegarami rzędu ~100kHz

[mpk]

nie jest zrywana, ale mogą być retransmisje.

Disclaimer: nie znam się na tym;) Nie żyję z tego. Ale czasem coś mi się zdarza zlutować, czasem coś narysować i wytrawić, więc pofilozofuję bo może się czegoś nauczę;)

~100kHz z jednej strony konwentera, ale z drugiej to już bodaj 3 rzędy wielkości więcej. A na takim pierwszym z brzegu SKR gniazdo usb masz wśród mosfetów i bezpieczników. Myślę, że jest potencjał coś wyszumieć.

D*py daje głównie firmware i organizacja odbioru danych

Z tym nie handluję. Sam utknąłem nie dawno z issue na ~200 komentarzy do marlina;)
ale chciałbym wierzyć, że obsługa odbioru danych w FW jest wspólna, niezależnie na którym porcie przydchodzą dane

[dziobu]

nie jest zrywana, ale mogą być retransmisje.

Jakiś czas już w tym nie grzebię, ale nie widziałem tam ani retransmisji ani sum kontrolnych. Na głupa leci tekst.
Przesyłanie jest sterowane sprzętowo (tak, to jedyny przypadek od bardzo dawna gdzie spotykam się ze sterowaniem przepływem ;p) i pomiędzy uC a kontrolerem USB-UART jest tak szybko jak się da. Bolączką jest firmware pisane dość otwarcie, tak ogólnie żeby kompilowało się dla wszystkiego. Tymczasem uC (a zwłaszcza słabe uC jak AVR) wymagają dedykowanych rozwiązań które wykorzystają w 100% możliwości sprzętowe.

No i zostaje jeszcze kwestia tego jak wygląda soft od strony PC. Nigdy nie patrzyłem jak jest realizowana wysyłka.

~100kHz z jednej strony konwentera, ale z drugiej to już bodaj 3 rzędy wielkości więcej. A na takim pierwszym z brzegu SKR gniazdo usb masz wśród mosfetów i bezpieczników. Myślę, że jest potencjał coś wyszumieć.

Większość tych kontrolerów działa w trybie USB 1.1, czyli ~10MHz. Trochę dużo żeby wentylator czy grzałka coś mogły zakłócać. Poza tym USB jest transmisją różnicową dość mocno odporną na zakłócenia i jeśli kabel nie jest z g*wna (a uczciwie przyznam że mam jeszcze takie choć dziś już ciężko je dostać) to bardzo ciężko jest coś tu namieszać sprzętem drukarkowym.

Zresztą nawet jeśli to efektem jest reinicjalizacja połączenia z PC co wiąże się ze zniknięciem urządzenia z systemu; nie jest to już coś co łatwo można pominąć.