Welcome! Log In Create A New Profile

Advanced

MK 4.3.8 problemi strani ed incomprensibili, forse corruzione memoria fw a runtime

Posted by FabryR 
MK 4.3.8 problemi strani ed incomprensibili, forse corruzione memoria fw a runtime
March 17, 2019 02:38PM
Questi ultimi 5gg ho passato a compilare (Arduino IDE 1.8.8 prima e poi anche 1.8.9 con medesimi risultati) il firmware 4.3.8 per la mia 3DRag e per una Geeetech G2S di un mio amico ed ho problemi su entrambe, ma questo post è per la 3DRag.

Il problema è molto strano e fa pensare a FW che si corrompe a seconda dei moduli/funzioni attivate.

Ho preso la mia config 4.3.6 e l'ho importata (con FW Configurator) sul 4.3.8 e alla prima build sembrava tutto ok (o almeno le poche cose provate).

Poi ho deciso di aggiungere 3 cose (EndStop IRQ, QuickHome e M43) e sono iniziati i problemi.
Con gli IRQ attivi non compila (o meglio non linka) neppure segnalando un riferimento non risolto (mi pare SoftSerial ma vado a memoria), togliendoli ottengo il firmware che apparentemente sembra funzionare (ma testato pochissimo e nessuna stampa) finché non provo la funzione Manual Bed Levelling.

Ecco quando dovrebbe iniziare il posizionamento sul primo punto (di 9) ottengo una oscillazione sull'asse Y con il carrello che continua a sbattere (come se volesse andare a valori negativi ignorando pure l'endstop, poi tornasse indietro per riprovarci in un loop infinito o quasi dato che entro un paio di sec resetto per evitare danni).

Tolgo le due opzioni aggiunte ma nulla da fare NON va più il bed levelling.
Poi sperimentando scopro che se metto solo QuickHome torna a funzionare.

Riassumendo (ho fatto un sacco di prove)

Config Base : NON va e sbatte a martelletto a fondo corsa sull'asse y
Config Base + QuickHome : funziona e mi fa la procedura di calibrazione normale
Config Base + QuickHome + Testing_M43 : NON va e sbatte a martelletto a fondo corsa sull'asse y ma con una frequenza diversa
Config Base + QuickHome + Testing_M43 (non sicuro di averla lasciata) + DriverMonitorTMC2130: NON va o va ogni tanto con un comportamente diverso

Nell'ultimo caso dopo qualche reset di stampante (solo reset di stampante senza ricaricare il fw) è capitato che abbia funzionato facendo la procedura solita ma di solito no va
In questo casi però tiene un compormento diverso, invece di andare a Home prende un asse (pare a caso dato che è capitato sia su Y che su X, più spesso X) e lo spara al max (schiantandosi poi alla fine dato che non c'è endstop ed ignora i softEndStop).

Sembra assurdo però si comporta così ed riproducibile (almeno sulla scheda), forse è legato alle dimensioni del FW.

Quote

4.3.8 senza QuickHome
Lo sketch usa 165010 byte (64%) dello spazio disponibile per i programmi. Il massimo è 253952 byte.
Le variabili globali usano 5311 byte (64%) di memoria dinamica, lasciando altri 2881 byte liberi per le variabili locali. Il massimo è 8192 byte.

4.3.8
Lo sketch usa 165338 byte (65%) dello spazio disponibile per i programmi. Il massimo è 253952 byte.
Le variabili globali usano 5311 byte (64%) di memoria dinamica, lasciando altri 2881 byte liberi per le variabili locali. Il massimo è 8192 byte.

4.3.8 QuickHome + M43
Lo sketch usa 169974 byte (66%) dello spazio disponibile per i programmi. Il massimo è 253952 byte.
Le variabili globali usano 5291 byte (64%) di memoria dinamica, lasciando altri 2901 byte liberi per le variabili locali. Il massimo è 8192 byte.

PS
Ho provato a compilare con la stessa config (almeno un paio di quelle sopra non ho provato tutte le combinazioni) sul 4.3.7 ed il difetto non appare (sul manual Bed levelling, poi se c'è altro che malfunziona non lo so)

Edited 2 time(s). Last edit at 03/18/2019 03:59PM by FabryR.
Re: MK 4.3.8 problema con bed levelling, fw corruzione memoria forse
March 17, 2019 08:47PM
Come scritto nell'altro thread ho provato la config Bed Level TMC Sensor Less anche sul 4.3.8 per vedere se cambiava qualcosa (già non mi va sulla 4.3.7) ed ho gli stessi difetti, anzi di più.

A stampante resettata do il comando G28 Z ed ottengo che fa 3 spostamenti (con 2 velocità direi visto che cambia il rumore) verso l'alto dell'asse Z (nessun tentativo verso il basso) e poi mi restituisce
X:0.00 Y:0.00 Z:16.000 E:0.0000

Se do un altro Home Z va ancora verso l'alto della stessa quantità (ma rimane 16 come valore di Z)

Però i comandi verso il basso funzionano (non c'è il motore invertito), se do G1 Z-50, l'asse Z davvero scende
Oddio in realtà questo solo sul 4.3.7 funziona bene, sul 4.3.8 qualunque comando G1 fa muovere ANCHE l'asse Y
Es. G1 Z-50 fa partire l'asse Y (ed anche quello Z) fino ad arrivare a fondo corsa YMax (dove si ferma per SoftEndStop, se non avevo fatto l'homing Y invece si schianta e spinge)
G1 X50 fa spostare l'asse X a 50 ma contemporaneamente anche Y parte come prima
G1 Y50 fa spostare solo Y ma non si ferma a 50 ma prosegue a fine corsa

Per il momento alla 4.3.8 ci rinuncio e provo a fare funzionare la 4.3.7

PS
Da schermo LCD invece i movimenti funzionano correttamente.
Se sposto X si sposta solo X e correttamente (sia in avanti che indierto), lo stesso per Z e pure con Y (che si muove solo della quantità chiesta ed in entrambe le direzioni).
Il comando di Homing Z (o Homing di tutti gli assi) non funziona uguale, alias Z va verso l'alto con 3 movimenti.
Però posso fa scendere Z distattivando i SoftEndStop e chiedendo posizioni negative per Z.

Edited 2 time(s). Last edit at 03/17/2019 08:51PM by FabryR.
Attachments:
open | download - Configuration_Overall.h (56.2 KB)
open | download - Configuration_Pins.h (8.6 KB)
Re: MK 4.3.8 problema con bed levelling, fw corruzione memoria forse
March 18, 2019 06:39AM
é in triggered il driver quando scende.. Quindi o devi cambiare la logica dell'endstop o diminuisci la sensibilità..
Devi provare con M119 poi non te lo dico più Non so quante volte l'avrò scritto, prima provare e gli endstop sono apposto poi verificare che funzioni tutto..


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
La config allegata la compila ed apparentemente sembra funzionare in semplici test da LCD o semplici comandi da seriale.

Ma in realtà non funziona bene, ogni tanto impazzisce nella gestione dei movimenti.

E una cosa assurda è che la stessa config caricata sul fw 4.3.7 (ovviamente downgradata tramite fw configurator online) genera un FW che non è in grado di eseguire NESSUN comando G1.
Il primo comando G1 che la macchina riceve si traduce nell'accensione dell'asse Z con movimento verso l'alto a max speed (rispettando il limite impostato per l'asse) senza più fermarsi (va a sbattere se non si resetta in tempo).
Lo stesso avviene pure lanciando una stampa da SD (parte asse Z e solo lui).

Ok lasciamo perdere pure il difetto grave del 4.3.7 e concentriamoci sul 4.3.8 dove questo difettone non succede ed apparentemente la macchina sembra OK (anche se ogni tanto impazzisce il bed levelling), però appena si lancia una stampa si vede che non ci siamo.
Ho lanciato delle stampe in DryRun per vedere i movimenti della meccanica ed ogni tanto (e mi pare sempre nello stesso punto a parità di oggetto) si mette a fare movimenti non presenti nel gcode.
Principalmente si vedono escursioni lungo l'asse X fino ad arrivare al bordo (e l'oggetto non si estende così tanto) e poi torna indietro o fa altri movimenti in diagonale per tornare nella zona dove stava stampando.

Un po' di comandi (la maggior parte) eseguiti correttamente e qualcuno che fa movimenti assurdi.

Lo stesso succede pure caricando il file (modificato per avere il dryrun nel sorgente) da SD e bypassando l'uso della seriale usb (pilotata da RepetierHost).

Così ad occhio mi pare che l'errore (a parità di sorgente gcode) compaia sempre negli stessi punti, però dovrei mettermi ad eseguire una riga alla volta per identificare la riga gcode che non esegue come dovrebbe essere.

Magari domani se ho voglia e tempo libero (ci ho perso davvero già troppo tempo negli ultimi 3gg, per ora basta) provo a ricompilare togliendo sia Junk Deviation che Bézier Jerk Control per vedere se influiscono (come pure Hysteresis Feature), ma le stesse opzioni sono attive anche sul 4.3.6 e lì mi pare che non ho questi problemi (oddio è mesi che non stampo, ma in passato stampavo e me ne sarei accorto del bug sul 4.3.6)

Edited 1 time(s). Last edit at 03/18/2019 04:19PM by FabryR.
Attachments:
open | download - Configuration_Overall.h (56.2 KB)
open | download - Configuration_Pins.h (8.6 KB)
Quote
FabryR
E una cosa assurda è che la stessa config caricata sul fw 4.3.7 (ovviamente downgradata tramite fw configurator online) genera un FW che non è in grado di eseguire NESSUN comando G1.
Il primo comando G1 che la macchina riceve si traduce nell'accensione dell'asse Z con movimento verso l'alto a max speed (rispettando il limite impostato per l'asse) senza più fermarsi (va a sbattere se non si resetta in tempo).
Lo stesso avviene pure lanciando una stampa da SD (parte asse Z e solo lui).
Rettifico per maggiore precisione, oggi ho riprovato il 4.3.7 perché ho rifatto un cavo SPI migliore (prima era a stella ora è seriale) e volevo per sfizio vedere se potesse influire (anche se era probabile un no come risposta, come poi è stato).

Non è vero che si schianta a oltre Z max, non avevo notato il display che mi indicava chiaramente che comando di spostamento sarebbe stato eseguito ossia che ogni comando G1 viene tradotto in realtà in un comando G1 con minimo Y12 Z215 (215 è il mio ZMax), quindi se lasciato andar (se era stato fatto Homing corretto) non si schianta ma si ferma a ZMax.
In pratica tutte le coordinate Y e Z se non specificate o di valore inferiore prendono valore 12 e ZMax

Ossia digito G1 X50 F3000 e sul display mi appare
X:50 Y:12 Z:215

digito G1 Y60 F3000 (con prima un G28) e sul display mi appare
X:0 Y:60 Z:215 (Y va a 60 perché 60 > 12)

digito G1 Z30 F300 (con prima un G28) e sul display mi appare
X:0 Y:12 Z:215 (Z va sempre a ZMax ed Y se non impostato va a 12)

digito G1 X100 Y10 Z30 F300 (con prima un G28) e sul display mi appare
X:100 Y:12 Z:215 (Z va sempre a ZMax ed Y va a 12 perché 12 > 10)

C'è un evidente errore in qualche puntatore alle strutture in memoria (ma chissà cosa lo causa), ad esempio se lancio il comando M43 l'output è:

Quote

EGMENT_TIME> S VEGMENT_TIME> S V Port: E0 RXD protected
EGMENT_TIME> S VEGMENT_TIME> S V Port: E1 TXD protected
EGMENT_TIME> S VEGMENT_TIME> S V Port: E4 Input = 0 TIMER3B MM> WGM: 1 COM3B: 0 CS: 3 TCCR3A: 1 TCCR3B: 3 TIMSK3: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: E5 X_MIN_PIN EGMENT_TIME> S V TIMER3C MM> WGM: 1 COM3C: 0 CS: 3 TCCR3A: 1 TCCR3B: 3 TIMSK3: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: G5 SERVO3_PIN EGMENT_TIME> S V TIMER0B MM> WGM: 0 COM0B: 0 CS: 3 TCCR0A: 0 TCCR0B: 3 TIMSK0: 5 non-standard PWM mode compare interrupt enabled overflow interrupt enabled
EGMENT_TIME> S VEGMENT_TIME> S V Port: E3 SERVO2_PIN Input = 0 TIMER3A MM> WGM: 1 COM3A: 0 CS: 3 TCCR3A: 1 TCCR3B: 3 TIMSK3: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: H3 SERVO1_PIN Input = 0 TIMER4A MM> WGM: 1 COM4A: 0 CS: 3 TCCR4A: 1 TCCR4B: 3 TIMSK4: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: H4 Input = 0 TIMER4B MM> WGM: 1 COM4B: 0 CS: 3 TCCR4A: 1 TCCR4B: 3 TIMSK4: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: H5 HEATER_BED_PIN Output = 0 TIMER4C MM> WGM: 1 COM4C: 0 CS: 3 TCCR4A: 1 TCCR4B: 3 TIMSK4: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: H6 FAN0_PIN Output = 0 TIMER2B MM> WGM: 1 COM2B: 0 CS: 4 TCCR2A: 1 TCCR2B: 4 TIMSK2: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: B4 HEATER_0_PIN Output = 0 TIMER2A MM> WGM: 1 COM2A: 0 CS: 4 TCCR2A: 1 TCCR2B: 4 TIMSK2: 0
EGMENT_TIME> S VEGMENT_TIME> S V Port: B5 SERVO0_PIN Input = 0 TIMER1A MM> WGM: 4 COM1A: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode compare interrupt enabled
...

Edited 4 time(s). Last edit at 03/19/2019 06:25PM by FabryR.
Disabiliti il pins debugging che non ti serve, disabilita solo per prova i TMC, naturalmente saranno impostati di default, quindi microstep e vref, solo per provare.
O la parte software SPI fa un casino da qualche parte, o hai problemi nelle celle di memoria del processore... Sono comportamenti inspiegabili senza alcun senso...


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
La parte Soft_SPI l'ho tolta proprio ora ed ho rimosso fisicamente (ma a livello di codice è ancora abilitato) LCD e SD e connesso i cavi a HW SPI

Non è cambiato nulla (non vedo più il display, ma vedo l'asse Z andare su anche se non coinvolto).

EDIT:
Provato ora pure a ricompilare senza pins debug (M43), cambiano un po' i malfuzionamenti ma sempre male (4.3.7) va.

Dato
G28
G1 X30 F3000
M114 (quando i motori si sono fermati)

ed ottenuto risposta.
X:30.00 Y:0.75 Z:215.000 E:0.0000

e tra l'altro non ha rispettato il feedrate per X che si è mosso lentissimo (forse 20 sec per fare i 3 cm)

Edited 1 time(s). Last edit at 03/19/2019 07:58PM by FabryR.
Come ti ho detto ora i microstep non sono quelli che hai settato, quindi il movimento è sbagliato e anche il feedrate... Quello che ancora non capisco è perché si muova anche y e z...


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
No non avevo ancora disattivato i TMC come hai chiesto (ho solo tolto M43 + SoftSPI e null'altro) quindi i passi sono giusti.
Infatti asse Z va al max esattamente nei tempi giusti è X che non si muove più alla velocità giusta (o almeno ad una velocità decente) ma solo con i comandi G1 (se ricollego il display LCD in qualche modo scommetto che si muove giusto ed alle velocità giuste con il controllo manuale)

Comunque appena ho tempo provo a cambiare l'aduino mega (clone) con la versione che usavo prima del salto a TMC (che ha su tuttora i DRV8255 ma scambiando le Ramps e ricaricando il fw ...) sperando tanto che con lui il problema sparisca (e quindi problema alla scheda)

Perché se rimane allora diventa più complicato (ed è un problema sw o almeno lo fa pensare)

Edited 4 time(s). Last edit at 03/20/2019 08:39AM by FabryR.
Ma firmware non è possibile lo uso tutt'ora con schede a 8 bit e funziona tutto perfettamente, l'unica differenza è che non uso tmc 2130 in software spi, per il resto è tutto identico..

Edited 1 time(s). Last edit at 03/20/2019 09:36AM by MagoKimbra.


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
Ho detto che lo farebbe pensare (a problema sw, compilatore che scazza ? downgrade ambiente ?) e spero tanto che sia un problema hw di questa scheda (che è pure in garanzia) però se lo facesse ancora (e speriamo di no) anche con l'altra scheda allora il problema verrebbe da pensare che debba essere a livello sw (toh al più mi sbilancio ancora ad un problema di alimentazione o a qualche altre fonte di disturbo hw che fa malfunzionare il processore di qualunque scheda, cambio anche la ramps ? ne ho altre 2 nuove ma meno belle)

Perché si può dire, c'è un guasto ai driver, hai collegato male alcuni cavi, ...ecc quanto si vuole ma se dai comando G1 X50 Y0 Z0 e la stampante invece va (invento ora) a X50 Y15 Z150 e se chiedi pure alla stampante "ora dove sei" (M114 mi pare) e lei di dice "sono a X50 Y15 Z150" hai voglia ad aver guasti o fili collegati male.
Se inverto le spine dei motori e collego (per assurdo) X ed Y scambiati, mi si muoverà fisicamente Y quando chiedo di spostare X, ma poi se interrogo la stampante risulterà che si è mosso X
Non so che dire ma credo sia un problema di eeprom (o dei dati che contiene).

Oggi ho cambiato l'arduino mega e ci ho flashato il fw (sempre 4.3.7 visto che gli ultimi test erano stati fatti su quello e per coerenza del confronto ho mantenuto la versione, che poi è quella che dà i problemi più evidenti).
Non ho ricompilato ho proprio flashato il .hex precedente.

Bene ottengo una scheda che non sia avvia, da log seriale vedo un continuare a rebootare e come stranezza evidente (ma non so se è anormale, non ci avevo mai fatto caso prima) ci sono valori assurdi nelle stats:
Quote

Stats: Total:65535, Finished:65535, Failed:0
Stats: Total print time:136y 70d 6h 28m 15s, Longest job:136y 70d 6h 28m 15s
Stats: Power on time:136y 70d 6h 28m 15s
Stats: Filament used:63389Km 65053m 65472cm 65528mm

Provo a ricompilare (senza cambiare nulla) il fw invece di caricare la vecchia build, stesso risultato.

Nel frattempo ho saldato in pin per HW Spi sull'adattatore LCD e quindi posso rimettere lo schermo LCD tenendo la modalità spi in hw (sharata con SD).
Bene dopo che l'ho fatto noto che sullo schermo non arriva nulla (vuoto).

Ok visto che ci sono due comportamenti diversi (con 2 schede diverse) penso a problema hw e vado a ricontrollare tutti i cablaggi, ne trovo uno connesso sbagliato (ma inifluente alla fine) ma a parte quello non c'è nulla di strano (comunque correggo l'errore).

Visto che anche Marlin con la 2.0 è abbastanza avanzato (oddio mi sa che molte opzioni che mi servivano ci sono pure nella 1.1.9) decido per sfizio di provare a configurarlo e compilarlo.
Bene lo carico su e questo FUNZIONA senza apparenti problemi.
Fatti pochi test, ma :
  • Parte regolarmente
  • Se dai un G1 X50 F5000 lo esegue perfettamente ed alle velocità giuste (mentre il 4.3.7 sull'altra scheda andava pianissimo per l'asse X e poi c'erano gli offset per Y e soprattutto Z)
  • Se lanci da SD la stampa di test (in dry-run) lo esegue apparentemente, mentre il 4.3.8 (sempre sull'altra scheda) ogni tanto faceva movimenti assurdi sull'asse X o Y

Ok le due config non sono uguali e MK è più ciccione, quindi riprendo il fw configurator e spengo tutte le opzioni che non ho messo nel Marlin (più o meno almeno), riscarico i sorgenti (perché il fw configurator ti dà sempre un pacchetto completo di sorgenti) e ricompilo.
Carico il fw ottenuto (sempre più ciccio del Marlin, ma meno di prima) e questo parte!

Mi dà il solito messaggio di errore eeprom ed allora faccio un bel M500 (mai usato M502) da console e poi resetto per vedere se l'errore è sparito.
Ottengo di nuovo un boot infinito e la macchina non parte più.

Altro tempo da perdere oggi non ce l'ho e rimetto su il Marlin 2.0

Una spiegazione razionale completa non mi viene, ma come detto in apertura sembrerebbe che sia il contenuto eeprom (l'unico che credo possa cambiare tra due schede) a dargli fastidio.
Poi quando avrò più tempo controllerò anche le tensioni della linea 5V durante il funzionamento per vedere se sono stabili o fluttuano, ma credo che le troverò stabili (e poi Marlin e MK 4.3.6 Agosto version funzionano).

PS
La seconda scheda arduino (clone) messa in pista oggi conteneva una build di agosto (mi pare) di MK 4.3.6 fatta però per i DRV8255 (dato che quella scheda montava prima dello scambio un'altra ramps con quei driver e non i TMC) e quindi presumo che ci fosse la eeprom salvata da lei (sul Marlin non ho mai dato M500)

Edited 1 time(s). Last edit at 03/24/2019 02:45PM by FabryR.
Sorry, only registered users may post in this forum.

Click here to login