Sonic Pad e Ender 3 S1 Error 1 e 298

[linusmax1]

Buongiorno a Tutti, spero che un anima pia possa aiutarmi un po', visto che non saprei da dove iniziare. Ho acquistato una Ender 3 S1 e il Sonic Pad. Sono un sistemista, quindi di certo esperto di sistemi linux; non di klipper e delle sue modalità operative . ho un grande problema sul quale non possiedo esperienza.

Durante la stampa spesso il sonic pad (sistema klipper di base) di disconnette dalla stampante con un errore 1 e se chiedo il restart di klipper fuoriesce un errore 298, che parla di impossibilità di dialogo con la stampante, sino a quando non tolgo alimentazione alla stampante e la rimetto. Lei si riavvia a facendo un restart nuovamente di klipper il collegamento torna a ripristinarsi.

Nei .log di sistema non trovo nulla di più di una segnalazione di disconnessione dalla MCU.

Sto pensando se reinstallando il sistema operativo di serie della mia Ender 3 S1, smanettando un poco, posso interfacciarmi via UART, visto che tramite USB ci sono problemi ispiegabili. Non so'  se qualcuno lo ha fatto.

La USB è perfetta ! ho camiato completamente tipi di cavo, ma il problema si ripresenta ogni volta allo stesso modo.

Idee ?

 

[FoNzY]

32 minuti fa, linusmax1 ha scritto:

Idee ?

è un prodotto di nicchia quindi credo ben poche persone abbiano esperienza a riguardo e la maggior parte di esse non sa' nemmeno cosa sia "uart" 😆

proverei a contattare creality per avere un idea, difficilmente risolvono ma forse un idea ce te la danno

Modificato 16 Ottobre 2023 da FoNzY

[eaman]

Prima di tutto guarda che la scheda MCU non venga alimentata dal sonic via USB quando connessa, magari c'e' un jumper sulla scheda, se non si riesce prova almeno a farli passare per un hub usb alimentato. Si puo' anche modificare il cavo USB e metterlo in solo dati. Che non sia un problema di alimentazione.

 

Poi guarda a che device USB sei connesso, tipo:

Cita

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

Guarda poi che tipo di connessione seriale ha il MCU: se e' una schifezza via CH340 oppure se e' un USB vero del MCU, in alcune schede c'e' da fare delle saldature per ablilitare il processore principale.

Suppongo che tu stia facendo un tail -f su dmseg per vedere cosa dice il kernel quando si disconette.

Bisogna poi che la versione di klipper sul sonic e quella sul MCU corrispondano: non e' che hai scaricato il FW binario dal web a random? Guarda che versione di Klipper stai usando e compila un FW dalla stessa versione.

RANT: ma sei un sistemista e ti sei accattato il sonic? Ma pigliati una orangepi o un qualunque embedded e mettici una Debian pulita...

Modificato 16 Ottobre 2023 da eaman

[linusmax1]

38 minuti fa, eaman ha scritto:

Prima di tutto guarda che la scheda MCU non venga alimentata dal sonic via USB quando connessa, magari c'e' un jumper sulla scheda, se non si riesce prova almeno a farli passare per un hub usb alimentato. Si puo' anche modificare il cavo USB e metterlo in solo dati. Che non sia un problema di alimentazione.

 

Poi guarda a che device USB sei connesso, tipo:

Guarda poi che tipo di connessione seriale ha il MCU: se e' una schifezza via CH340 oppure se e' un USB vero del MCU, in alcune schede c'e' da fare delle saldature per ablilitare il processore principale.

Suppongo che tu stia facendo un tail -f su dmseg per vedere cosa dice il kernel quando si disconette.

Bisogna poi che la versione di klipper sul sonic e quella sul MCU corrispondano: non e' che hai scaricato il FW binario dal web a random? Guarda che versione di Klipper stai usando e compila un FW dalla stessa versione.

RANT: ma sei un sistemista e ti sei accattato il sonic? Ma pigliati una orangepi o un qualunque embedded e mettici una Debian pulita...

Grazie Eaman ! Veramente un reply per me molto interessante, anche se mi piacerebbe capire se effettivamente occorre fare un ponticello sulla mia scheda. In effetti il Chip è un CH340g e il processore è un STM32F401. Magari trovare maggiori info circa il ponticello.

Sonic Pad è un sistema integrato che produce in fase di wizard il binario da mettere nella stampante, quindi dovrebbe essere altamente improbabile che sia disaccoppiato. Faro delle verifiche su possibili errori segnalati dal kernel, certo che il log di klipper non dice quasi nulla a parte la disconnessione con la MCU.

In effetti ho sbagliato ad acquistare il sonic pad, ho pensato che probabilmente pagando una differenza di 70euro avrei acquistato una soluzione più testata e con display integrato.

faccio dei tentativi con una connessione usb passante per un hub alimentato e cerco qualcosa circa la mia scheda della stampante

[eaman]

Bisogna che cerchi su google se la tua scheda puo' far passare la seriale dall'STM, dovrebbe avere USB integrato. Magari guarda a che velocita' stai usano ora il CH340, prova a usare 115200 MHz come serial speed, non 250k, comunque un valore piu' basso di 250k.

Modificato 16 Ottobre 2023 da eaman

[linusmax1]

Ancora grazie Eaman, mi hai fornito degli ottimi spunti per diagnosticare cosa accade. Indagherò attentamente andando a comparare come lavora e cosa accade nello specifico quando si disconnette. Come elemento certo e' che quando si verifica la disconnessione la porta della stampante, quella connessa tramite il ch340g resta in uno stato di blocco o in dialogo aperto e non riavviabile via comunicazione. Sono costretto a spegnere la stampante e riaccenderla per instaurare una nuova comunicazione. Forse c' e' una prima fase di comunicazione tra Klipper e la stampante tale che se la porta e' restata aperta e in comunicazione non permette un nuovo collegamento. Del resto sono convinto che la connessione viene abbandonata da Klipper, perché esiste la solita soluzione che odiano i sistemisti, ossia reset del Sonic Pad a valori di fabbrica e il problema si ripresenta tra 20/30 giorni. Non ho capito perché , come se riempisse un fs o una memoria che alla fine lo blocca.

[eaman]

Ma te la seriale come la peschi nel printer.cfg?

It's common for each printer to have its own unique name for the micro-controller. The name may change after flashing Klipper, so rerun these steps again even if they were already done when flashing. Run:


	ls /dev/serial/by-id/*

It should report something similar to the following:


	/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

Then update the config file with the unique name. For example, update the [mcu] section to look something similar to:


	[mcu]
	serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

- https://www.klipper3d.org/Installation.html

Ce l'hai nei device / kernel  serial-by-id?

OMG https://klipper.discourse.group/t/sonic-pad-mainline-klipper/8832

Ma cosa minchia e' Tuna linux derivato da OpenWRT? Ma perche' vi dovete far del male con queste xxxxxx...

Guarda che il problema sta probabilmente li', come quell'aborto di kernel / sistema operativa rileva le periferiche USB. Per altro se e' veramente il kernel anche se fai un chroot non risolvi...

Ma mandalo indietro se puoi.

Modificato 17 Ottobre 2023 da eaman

[linusmax1]

Il 17/10/2023 at 07:40, eaman ha scritto:

Ma te la seriale come la peschi nel printer.cfg?

It's common for each printer to have its own unique name for the micro-controller. The name may change after flashing Klipper, so rerun these steps again even if they were already done when flashing. Run:


	ls /dev/serial/by-id/*

It should report something similar to the following:


	/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

Then update the config file with the unique name. For example, update the [mcu] section to look something similar to:


	[mcu]
	serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

- https://www.klipper3d.org/Installation.html

Ce l'hai nei device / kernel  serial-by-id?

OMG https://klipper.discourse.group/t/sonic-pad-mainline-klipper/8832

Ma cosa minchia e' Tuna linux derivato da OpenWRT? Ma perche' vi dovete far del male con queste xxxxxx...

Guarda che il problema sta probabilmente li', come quell'aborto di kernel / sistema operativa rileva le periferiche USB. Per altro se e' veramente il kernel anche se fai un chroot non risolvi...

Ma mandalo indietro se puoi.

I tuoi consigli sono stati molto utili, anche se ho trovato la soluzione dopo parecchio tempo. Ora ho risolto !

Il problema era la porta USB laterale del Sonic Pad, troppo lasca, che lascia tremare anche per un istante il cavo e la connessione si interrompe. Non è una questione di cavo, ho provato decine di cavi usb diversi, il problema è la porta femmina del Sonic Pad, troppo sporgente e lasca. Ho infatti stampato un modello 3d, che si trova facilmente in rete, per bloccare il cavo usb alla schocca del Sonic Pad, in modo da renderlo fermo e non oscillante. Fine ! Risolto.

In seguito è uscito un problema molto simile ma questa volta era dovuto dal cattivo raffreddamento della scheda interna del Sonic Pad, progettata per dissipare posteriormente, senza alcuna ventola di supporto e solo delle piccole fessure di sfogo. Già la temperatura del processore in estate era altissima da sola ...a questo io avevo aggiunto il calore proveniente dalla stampante, posizionando il sonic pad su una staffa agganciata alla ventola superiore...e così la temperatura diventava così alta che tutto si freezava.

Ho stampato un supporto laterale aggiungendo una ventola posteriore al Sonic Pad è da allora posso stampare anche una settimana di fila senza interruzioni.

Modificato 26 Settembre da linusmax1

[eaman]

7 ore fa, linusmax1 ha scritto:

Il problema era

Grazie per averlo riportato 🙂

Delle volte io metto un blog di resina epossidica sulle porte usb dei micro e schede per non sbragarli dopo 5 minuti.