Come mandare la casa a fuoco per colpa di un GCODE corrotto

E' da un pò di tempo che sto avendo problemi con CURA, come tocco qualche parametro nella configurazione, e non saprei dire quale e come, il gcode che viene generato mi manda in tilt la stampante.

Tipicamente dopo lo zero assi, nel momento in cui deve iniziare a estrudere, arduino si freeza, e non va avanti.

Oggi però ho quasi mandato a fuoco casa, per fortuna ero nella stanza accanto e ho sentito un forte odore di bruciato..entrando nella stanza ho trovato questo spettacolo

[www.youtube.com]

stampa ferma e il display segnava 190gradi ma era chiaro che non era così...ho resettato arduino e il display mi ha visualizzato la reale temperatura..oltre i 300°C...

Prestando attenzione ho riavviato la stampa 2 volte e in entrambi i casi al layer 10 accadeva la stessa cosa...arduino congelato ma con il pin collegato al circuito dell'hotend rimasto a 1, quindi temperatura al massimo senza la logica a controllarla.

C'è qualcuno che può dare una occhiata al gcode per capire cosa avviene oppure sa darmi indicazioni??

Scheda andata, assolutamente da cambiare, con una possibilmente fatta appositamente, o se proprio non vuoi cambiare arduino originale e ramps presa da un venditore con tanti feedback positivi..

---

Andrea Lillia
Lillia.net
Pagina Facebook

Andrea fammi capire meglio..tu attribuisci il difetto all'elettronica? Quello che non capisco è perchè il difetto lo fa solo con alcuni gcode (poco prima avevo terminato una stampa lunga e abbastanza complessa senza problemi, e se la rimetto in stampa è sempre ok)

Edited 1 time(s). Last edit at 02/28/2019 06:09PM by VittorioMX.

Se non stampi da SD, probabilmente il "blocco" di Arduino" potrebbe essere causato dal blocco della comunicazione seriale.

però se non posti il gcode diventa complicato analizzarlo :-D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

eccolo

[drive.google.com]

purtroppo il file risulta troppo grande per allegarlo..

io stampo da usb tramite repetier server che quando accade questa cosa mi ritorna il timeout sulla comunicazione..ma arduino non è più vivo, infatti si congela all'istante in cui "muore".

il problema è che non è attivo neanche un watchdog per resettarlo quando accade quindi è molto pericoloso

ripeto non lo fa con tutti i gcode

ho provato ad abilitare il watchdog e almeno sembra risolvere il problema della temperatura incontrollata...va correttamente in reset e così non vado a fuoco...resta capire la causa

C'è da dire comunque che ci sono diversi controlli nel firmware, che bloccano tutto proprio in casi come il tuo.. quando vedono che la temperatura non varia ma continuano a dare corrente alla resistenza, o quando i motori dovrebbero muoversi ma le coordinate rimangono sempre quelle, la stampante dovrebbe bloccarsi.. dotarsi di un firmware con questi minimi criteri di sicurezza èquantomeno obbligatorio.. pretendilo dal tuo venditore se l'hai comprata o fattelo, ma assolutamente è indispensabile..

Detto questo, potrebbe essere un falso contatto dell'ntc che misura la temperatura che viene fatto casualmente..

ci sono troppe variabili che possono portare a quello che hai mostrato nel video.. scheda andata, problema di firmware, problemi di corrente..pomeriggio provo a vedere dal gcode se risulta qualcosa di strano

---

Andrea Lillia
Lillia.net
Pagina Facebook

Andrea metto un pò di dati visto che non ho specificato quale stampante uso.

COREXY autocostruita, volume 400x400x400
Arduino mega + ramps1.4
pololu 8825 + motori nema17 da 2.5A
estrusore direct sempre autocostruito
hotend e3dv6 (clone) ugello da 0.35
Rapsberry con repetier server
firmware MKDUO 4.3.8 con eeprom abilitata

temperatura di stampa 190°C attualmente con filamento tomas 3d

per la questione dell'NTC ho provato a simulare staccandolo ma mi va si in errore ma me lo segnala restando vivo, mentre in questo caso arduino va proprio in fault tanto che interviene in watchdog.
Proprio il fatto che va in errore arduino è l'origine del problema...il firmware non girando più non ha nessun controllo sulla temperatura che sale all'infinito (per dire) a causa del pin di controllo dell'hotend che resta alto nel momento in cui il firmware va in blocco...


P.S: adesso sta in stampa lo stesso oggetto ma ho fatto lo slicing sempre con cura ma impostando il layer a 0.1 invece di 0.2 ..e sta andando bene...
per questo motivo credo che sia qualcosa nel gcode

Edited 1 time(s). Last edit at 03/01/2019 06:07AM by VittorioMX.

se può servire..questo file l'ho generato da poco ed è più o meno uguale al precedente ma funziona senza problemi

[drive.google.com]--

Leggendo il primo gcode ci sono diverse cose strane..imposti la temperatura a 190° ma poi parte a stampare a 255.. perchè?

---

Andrea Lillia
Lillia.net
Pagina Facebook

Perché dici parte a stampare a 255, vedo un M106 S255 ma quello setta la ventola a 255.
Togli invece M105 che è un comando che deve dare l'host e non il gcode.
Non serve a nulla dire i comandi in sequenza M104 S195 e poi subito dopo M109 S255.
Non risolve il problema, ma è una logica errata...
Per il resto non c'è nulla che non va..

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

ieri ho passato il file incriminato ad un amico che ha la corexy più o meno gemella alla mia...a lui è andata a buon fine la stampa fino alla fine.
L'unica differenza sta nel firmware..io ho l'ultima 4.3.8 lui ha lasciato la 4.3.2.

Oggi provo ad usare la stessa versione giusto per restringere il campo

P.S. i comandi
M104 S190
M105
M109 S190
non li ho messi io, a quanto sembra li mette cura.. il mio start gcode è questo:

;Layer height: {layer_height}
;Walls: {wall_thickness}
;Fill: {infill_sparse_density}
;Top\Bottom Thickness: {top_bottom_thickness}
M530 S1
G28;
M420 S1;
G90 ;absolute positioning
M82 ;set extruder to absolute mode
G92 E0 ;zero the extruded length
G1 F200 E3 ;slowly extrude 35mm of filament to clean the nozzle and build up extrusion pressure
G92 E0 ;zero the extruded length again
G1 F{speed_travel} ;Set travel speed
;print

Al momento ho caricato la 4.3.6 e uno dei file che dava il problema è ok, la stampa è ancora in corso ma ha passato il punto in cui andava in fault

Il discorso e' molto interessante, in effetti in caso di blocco di arduino il firmware serve a ben poco, e allora come difendersi da situazioni di pericolo in cui le cartucce riscaldanti restano alimentate e magari noi siamo fuori casa ?
Cosi' su due piedi mi viene in mente una seconda sonda di temperatura per piatto e hotend collegate a un secondo arduino o raspberry, in modo che intervengano se i valori superano una soglia di alert, spegnendo tutto con un rele.

---

Stampante CoreXY BLV mgn 30X30X22 con estrusore diretto E3D V6 originale
Duet 2 wifi
BLTouch originale
Ugello 0,4
Filo 1,75

Se il blocco è dell'arduino basta abilitare il watchdog, dopo 3-4 secondi in caso di fault va in reset e al massimo trovi tutto fermo. Diversamente se dovesse rimanere a attivo l'estrusore (fet in corto hw) allora arduino lo rileva e spegne ma il problema resta.
Si potrebbe fare un circuito semplice con una termocoppia aggiuntiva con soglia impostata con componenti discreti, direttamente sulla 12V in uscita.

Prima di cercare esotiche spiegazioni trattandosi di Arduino Mega + Ramps , uno dei suoi prproblemi più noti oltre ai MOSFET dimensionati male è quello del blocco del regolatore a +5V per troppa corrente assorbita, in genere si risolve spostando le alimentazioni a 5V degli utilizzatori con un alimentatore esterno, ovviamente deve esserci un solo collegamento tra la massa della Ramps e quella degli utilizzatori, sotto alimentazione esterna, per evitare strani giri di massa.

Altro problema comune è il collegamento tramite USB che potrebbe generare strani "giri di massa" o meglio problemi di masse non alla stessa "differenza di potenziale" se alimenti ad esempio la stampante e il computer da due prese a muro separate.

Ovviamente se si blocca l'arduino per problemi di alimentazione il processore è ovviamente bloccato ma le uscite potrebbero tranquillamente rimanere all'ultimo stato in cui erano settate, causando il problema descritto.
Altrettanto ovviamente non è un problema facile da diagnosticare perché il regolatore a 5V è sulla scheda Arduino che sta sotto la Ramps e quindi non è raggiungibile anche solo per "mettere un dito sopra" al regolatore per vedere se scalda.

Problemi simili al regolatore in genere sono relativamente comuni, perché in genere viene dato per circa 800ma max se non erro ed è facile superarli se hai LCD attaccato e magari alimenti endstop elettronici o altri utilizzatori come sensori di livello o simili che potrebbero portare la somma degli assorbimenti oltre il livello massimo del regolatore.


Il fatto del Watchdog settato o meno però complica le cose.

In genere il circuito di watchdog è un timer esterno al processore con un ingresso di reset per cui se non resettato ogni tot secondi manda un impulso di reset al processore, se tutto va come deve il processore resetta periodicamente il timer e l'elaborazione non viene interrotta, se qualcosa va storto il timer resetta il processore facendolo ripartire.


Non ho sottomano le specifiche di Arduino Mega, (o meglio del suo microprocessore) per cui posso solo suggerire una spiegazione "teorica".

Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

Onekk perdonami ma in quel che dici ci sono cose che non quadrano..
1) di esotico c'è poco, è elettronica
2)la 5v nel mio caso già è esterna.
3) la terra delle prese di casa è la stessa, come fase è neutro. Diversamente il discorso degli alimentatori.. Non puoi fare un parallelo essendo switching.. A meno che non siano espressamente dichiarati come parallelabili. Ad ogni modo io non ho il pc collegato ma il raspberry
4) il watchdog deve proprio resettare il micro, è quello, in questo caso che almeno non mi fa andare in fiamme la casa, poi per le cause del suo intervento.. Poi si vede

Ad ogni modo vorrei riportare l'attenzione sul fw.. Il 4.3.6 funziona ma con il 4.3.8 quei files non li stampa in nessun modo.

Edited 1 time(s). Last edit at 03/03/2019 12:07PM by VittorioMX.

Ok, Il parallelo degli switching, non l'ho proprio consigliato, si parlava solo di massa comune e di alimentazione a 5V separata, fatto con la scheda in firma, dove il 5V esterno tranne LCD e scheda sono alimentati con una step-down (switching da 12V a 5V) e le masse sono in comune.

La 4.3.8 non la ho provata, preferisco non usare la versione ancora in sviluppo perché il software che usa il mago non isola le transazioni ed è molto facile incappare in versioni aggiornate a metà con problemi di compilazione.

La terra "non è la stessa", ci possono essere problemi di ddp tra due prese servite dalla stessa "palina di messa a terra" per il modo con cui le terre sono cablate, a meno di impianti esotici cablati a stella dove da ogni presa parte un cavio che va ad un cavo di grossa sezione nelle scatole di derivazione e da lì i cavi vanno alla palina, in genere l'impianto di terra è cablato con i cavi che girano per le prese per cui un cavo ha x metri per andare a terra con la resistenza diversa da una presa e l'altra, e in più ogni cavo corre vicino a fase e neutro con incrocio capacitivo diverso da punto a punto, per cui l'impianto di casa è una somma di reti LC, se sai di cosa parliamo.

Per cui se metti un tester ad alta impedenza tra il pin di messa a terra e la fase o il neutro ti trovi una lettura di tensione e se provi tra prese diverse dello stesso impianto quasi sicuramente avresti letture diverse, ovviamente la corrente in gioco è trascurabile, (a meno di grossi problemi sull'impianto).

Sui forum di macchine a CNC dove il problema dell'interferenza elettromagnetica è presente per via dei motori di fresatura a volte alimentati a frequenza variabile, il problema è molto presente e le trattazioni sui cablaggi specie delle schermature di segnali digitali è trattato in modo esaustivo, con link anche molto interessanti relativi agli anni '70 e '80 e "consigli di implementazione" fatti da dipartimenti statali americani del calibro della NASA e dei vari laboratori della GE e compagnia cantante, che risultano in una lettura molto interessante e proficua, a dispetto degi decenni trascorsi molto illuminante anche oggi.


Da qui il consiglio di usare la stessa ciabatta per alimentare computer e stampante, ovviamente con cavi di opportuna sezione, cioè non le ciabatte cinesi con i cavi da 0,50mm2 ma almeno da 1mm2.

Comunque se alimenti il raspberry Pi dalla stessa 12V della stampante, non dovresti avere giri strani di masse, io uso una soluzione comparabile per la CNC è non ho mai avuto problemi (a meno del chip CH340G cinese del clone di arduino uno che a volte si perde un byte e incasina il lavoro), la mia soluzione usa una scheda Olimex alimentata a 12V e un arduino uno alimentato dalla stessa 12v attraverso però qualche diodo di caduta in modo da non far lavorare il regolatore dell'uno a palla, un diodo di caduta fa perdere 0,7V ne metti 4 è perdi 2.8v e da 12V scendi a 9 e rotti e stai sul sicuro con il regolatore dell'uno, per il mega dovresti vedere se è fattibile e mi pare ce lo sia staccare il diodo che è gia montato sulla ramps e sostituirlo con una cascata di quattro diodi in modo che la scheda sotto sia alimentata 9/10V facendo scendere di circa il 15/20% la dissipazione totale del regolatore dell'arduino, impiegando componenti "passivi" non si dovrebbero generare strani loop.

Tenere pià al fresco il regolatore del Mega dovrebbe giovare anche alla stabilità totale dell'insieme.


Saluti

Carlo D.

Comunque dei difetti della Ramps, specie nei forum in inglese trovi discussioni a iosa, alcuni adirittura consigliano di usare una USB "galvanicamente isolata", il problema è che costa una paccata di soldi ed è più economico usare una rs232 optoisolata verso l'arduino collegandola poi agli ingressi rx e tx dell'arduino, e un convertitotre da usb a rs232 verso il computer.

L'alternativa è usare una comunicazione WiFi tra stampante e host oppure stampare semplicemente da SD.




Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]