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

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.

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.

é 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.

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.

Poi non ho più scritto perché causa altre necessità con Aprile ho mollato l'uso della stampante.

Però avevo identificato che di certo c'è qualche problema (o non gestione di dati sporchi) nel codice di gestione della eeprom introdotto dal 4.3.7 (o anche dall'ultima 4.3.6).

Come già detto all'ultimo posti di Marzo avevo cambiato elettronica (mettendo un Arduino Mega originale, forse) per sfatare il mito che fosse la scheda la colpevole, ed il firmware (4.3.7) dopo il cambio non partiva neanche (vedi post precedente) e per farlo avviare andava ricompilato con disattivato la gestione eeprom.
Però non era solo quello perché anche così qualche difetto di quelli citati rimaneva.

Ma non avendo altro tempo da dedicare (nonché se mettevo Marlin 2.0 con config identica zero problemi) ho lasciato perdere anche se mi ero ripromesso di provare a simulare una esecuzione passo passo in debug mode per capire dove il software incontra problemi e perché.

Oggi ho ripreso in mano la scheda (configurata ora con DRV8255 ed opzioni al minimo, non ci sono più i TMC e le opzioni esoteriche) perché la dovevo cedere ad un nuovo proprietario, ho scaricato gli ultimi sorgenti del 4.3.8 ed ho compilato.
Il firmware è partito segnalando errore di versione eprom (ha trovato i dati del 4.3.7), al che ho dato M500 per fixare.
Ecco da lì è partito un boot-loop esattamente come era successo sul 4.3.7, la scheda parte segnala statistiche senza senso (invece che 0, valori alti di uso) e poi reboota e così via in un ciclo infinito.

Ho risolto (il boot loop almeno, ora mi resta da testare il funzionamento in stampa) caricando un sketch di clear della eeprom e poi ricaricando il firmware.
Anche questa volta ha dato errore di eeprom ma non è più impazzito dopo il M500

Ergo il codice che legge la eeprom non è proprio perfetto e non gestisce situazioni con dati sporchi (che poi in teoria non dovrebbero esserlo visto che ha fatto lui un M500 un attimo prima)

Edited 3 time(s). Last edit at 06/23/2019 11:31AM by FabryR.

Ok Ottima analisi... Vediamo se insieme ne usciamo fuori..
La eeprom viene letta cella per cella, ognuna da un byte. Non ha nessun collegamento con il dato al suo interno.
Detto ciò quindi il dato viene letto sapendo a cosa corrisponde, e per farlo il firmware ha una struttura di come è impostata la eeprom stessa.
Faccio un esempio immaginiamo di leggere le prime quattro celle.
So che la prima è una variabile a 8 bit quindi un byte e indica il numero degli estrusori, la seconda è un'altra variabile a 8 bit che indica se ho lo stesso numero di hotend o solo 1 (single nozzle), le ultime due sono due byte che insieme fanno una variabile a 16 bit che indica il numero degli step per mm dell'asse X. E' un sempio per capirci.
Ora leggo queste 4 byte e leggo (valori in decimale) 2 1 700. Quindi ho 2 estrusori 1 hotend e 700 step per mm, questo sono i valori che verranno messi nelle variabili, ma il firmware non ha alcun controllo se sono dati esatti o no!!
Quindi se leggo una eeprom diversa o errata non c'è modo di sapere se quei valori sono esatti oppure no..
Quindi la prima cosa che viene fatta è scrivere nelle prime celle il nome della versione della eeprom, MK scrive MKV68 (l'ultima versione), marlin invece scrive V67 (sempre l'ultima versione).
A questo punto sia marlin che MK confrontano i primi byte, 5 per MK e 3 per marlin con il define che hanno nel firmware.
#define EEPROM_VERSION "MKV68" -> MK
#define EEPROM_VERSION "V67" -> Marlin
Se questi valori non corrispondono allora carica nelle variabili i valori messi nei define quelli che sono nella configurazione. Fatto ciò la eeprom rimane ancora come era prima, solo facendo un M500 andremo a scrivere i nuovi valori...
Questo è il primo controllo che si può fare, ma se le versioni corrispondono i firmware legge i valori cosi come è la sua struttura creata e li va mettere nelle variabili...
Quindi se legge 2 estrusori perchè nella cella successiva a MKV68 c'è scritto 2 mette 2 non sa se sia giusto o meno quel 2 lo legge e lo mette nella variabile...
A questo punto sia MK che Marlin hanno un controllo di CRC cioè una somma totale degli 1 di tutte le celle che viene scritto nella eeprom stessa. Quindi quando io scrivo le celle 2 1 700 avrò in bit una serie di 1 e 0 e vado a sommare tutti gli 1 e vado a scrivere nella cella apposita questo valore.
Faccio un esempio 2 in byte è 00000010, 1 è 00000001 quindi per capirci il crc è 2. Ma se per un motivo qualsiasi le celle sono invertite, avrò quindi 1 estrusore e 2 hotend, il crc sarà sempre 2 quindi esatto e per lui i dati sono validi.. Ma sicuramente non per te...
Sia Marlin che MK fa esattamente le stesse cose sono simili quindi i passaggi sono uguali...
Ma può succedere che il crc corrisponda e non dia errore e quindi i dati vengono resi validi anche se non lo sono, è puramente casuale la cosa...
Quando MK carica la eeprom e trova un valore non uguale alla versione da quella scritta attenzione EEPROM cambiata etc etc, nel senso che ha rilevato che al eeporm che ha letto non è la sua versione e quindi i dati che va a mettere nelle variabili sono i define nella configurazione. E quindi senza fare nulla li hai esattamente quello che tu hai configurato. E deve funzionare per forza.
Quì entra in gioco alcune differenze tra MK e Marlin.
MK ha molte cose messe in eeprom tra cui diversi pin come quelli dei riscaldatori o dei sensori, delle fan e di altro. Quindi una volta che ha caricato questi pin li va a definire. Se sono output, se sono input, se hanno o no la pullup. Ma i processori non amano molto ridefinire i pin, sono registri, ora non entro nel particolare.
Quindi se ha messo nelle variabili quelli dei define, tipo #define X_MAX_PIN 8 il pin dell'endstop che sarà definito sarà 8, se invece avrà trovato nella eeprom il pin 7 definirà il pin 7.
Ora se il pin letto per l'endstop è un pin dedicato per fare altro tipo seriale o altre cose succede che si impalla e come ho detto prima se per puro caso il valore viene preso in maniera sbagliata potrebbe succedere...
Quindi più di quello che si è fatto per verificare che sia tutto giusto, purtroppo non si può fare. L'unica è fare un bel erase della eeprom mettendo tutti 0 in questo modo si è sicuri che sia tutto negativo e per forza di cose si vanno a caricare i valori di default...
Per farla breve sicuramente con Marlin il problema non capiterà mai, perché i pin non li salva in eeprom, ma vengono usati solo e soltanto quelli definiti nella configurazione. E' un pregio o un difetto non sta a me dirlo, io voglio un firmware completamente configurabile anche successivamente e questo porta sicuramente a qualche problema. Ma una volta che la eeprom è giusta pulita e non viene fatto un passaggio Marlin MK o viceversa non da più problemi...
Ecco perché dico a tutti mettete un bel programmino che azzera la eeprom e siamo sicuri che tutto va..
Tu mi dirai ma io ho messo un processore nuovo, non vuol dire nulla perché nei test viene provato tutto e viene scritta la eeprom per verifiche e potrebbe essere che nella casualità le cose corrispondono...
Cmq ho riverificato il tutto e non c'è nulla che non va, almeno nella procedura, poi sicuramente in qualche caso le variabili si allineano e non fanno funzionare perfettamente la procedura...

---

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

Io posso solo dire che quella scheda era stata usata per il precedente MK4 4.3.6 (e precedenti) e poi quando sono passato ai TMC sono passato ad un'altra scheda (e quella è finita nel cassetto tenendo i driver DRV8255, dato che per la scheda nuova ho usato pure una nuova ramps).
Poi l'ho rimessa in pista a fine Marzo scambiando le ramps (per avere i TMC) per vedere se i difetti che avevo potessero essere causati dall'Arduino clone, e caricandoci sopra il 4.3.7 (dato che era quello più problematico).
In seguito forse ci ho messo anche il Marlin (non sicuro, sicuro di averlo usato su almeno una delle schede meno sicuro di averlo fatto su entrambe) MA senza salvare mai l'eprom sotto Marlin.

Ed ho avuto avuto i problemi citati e mi pare pure da subito (non mi sembra di aver mai fatto M500 sul 4.3.7 ma vado a memoria).
Problemi che ho temporaneamente risolto ricompilando un firmware senza gestione eeprom (non ho fatto clear) e poi ci ho fatto altri pochi test (funzionava ma mantenendo ancora dei difetti di funzionamento) e poi ho accantonato tutto per cambio di impegni.

Poi ieri dovendo preparare quella scheda (+ ramps con DRV8255) per una persona che la voleva per la sua stampante, l'ho ripresa, ho compilato un 4.3.8 con la config del 4.3.6 (ultimo fw su cui avevo usato i drv8255 ed avessi una config già pronta) estesa dal web configurator e l'ho caricato.
Mi ha rilevato una versione non adatta di eeprom (mi pare di aver letto a memoria un 61 come versione) ed allora gli ho fatto M500 per fixare.
Appena l'ho fatto boom, boot-loop con dati corrotti.

Questa volta come già detto ho fatto il clear della eeprom e ricaricato il firmware ed ora apparentemente sembra andare correttamente
Mi manca solo di fare un paio di stampe per la certezza ma ad un primo test sembra ok (ma è base base, su richiesta del nuovo possessore tutte o quasi le features avanzate sono spente).

Purtroppo non ho pensato a farmi un backup della eeprom per tenere i dati ed avere un modello certo dove dà problemi.
Ho sempre al più l'altra scheda, però su quella non c'era il boot-loop ma comunque c'erano e ci sono ancora tutti i problemi citati nei vari post.
Posso al più provare a fare un clear anche lì e vedere se magicamente questo aiuta.

Il problema è che non ho tempo in questi gg e quindi non credo lo farò a breve e poi volevo pure montare un'altra elettronica che mi hanno regalato.

Edited 2 time(s). Last edit at 06/24/2019 07:21PM by FabryR.

Quote
FabryR
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 è:

Ho rifatto qualche prova ricompilando oggi il 4.3.7 dopo aver fatto un clear della eeprom ed aver usato librerie più recenti (es. quelle TMC)
E purtroppo non serve a niente con la config1 allegata il problema è deterministico ed è sempre esattamente come scritto nella parte quotata (l'assurdo andare a Z-MAX ed altro).
Usando la config2 dove invece ho spento quasi tutto il difetto NON si presenta (almeno il comando citato sopra, provato solo il primo, si comporta correttamente e fa solo un X:50)

Non ho fatto altri test per vedere se rimanevano altri bug tanto ormai il 4.3.7 è considerato vecchio.
In ogni caso aggiungendo i vari moduli impazzisce.
Ho usato il 4.3.7 perché era quello che faceva problemi evidentissimi da subito, ma purtroppo anche 4.3.8 con la stessa config malfuzionava e non era utilizzabile per stampare (con quella config)

Ora sto passando a 4.3.9 (con eeprom svuotata) per vedere se ancora ci sono problemi
E per ora, seconda seriale che non riesco ad attivare a parte, non ho notato grossi difetti (ma test irrisori per il momento)

Non so se può centrare qualcosa ma tra la config1 (che non va) e la config2 (che va almeno con i comandi del quote) tra le varie opzioni spente ci sono:
#define PROBE_MANUALLY
#define LCD_BED_LEVELING

Ecco queste opzioni ho dovuto toglierle dal 4.3.9 sennò non compila neanche (4.3.7 e 4.3.8 invece compilano regolarmente) dando errore:

In file included from c:\users\xxxx\appdata\local\temp\arduino_build_990647\sketch\mk4duo.h:153:0,

                 from C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp:27:

C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp: In function 'void menu_bed_leveling()':

C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp:285:45: error: 'class mesh_bed_leveling' has no member named 'z_offset'

     MENU_ITEM_EDIT(float43, MSG_BED_Z, &mbl.z_offset, -1, 1);

                                             ^

c:\users\xxxx\appdata\local\temp\arduino_build_990647\sketch\src/lcd/menu/menu.h:306:45: note: in definition of macro '_MENU_ITEM_VARIANT_P'

         MenuItem_##TYPE ::action ## VARIANT(__VA_ARGS__); \

                                             ^

C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp:285:5: note: in expansion of macro 'MENU_ITEM_EDIT'

     MENU_ITEM_EDIT(float43, MSG_BED_Z, &mbl.z_offset, -1, 1);

     ^

C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp:285:45: error: 'class mesh_bed_leveling' has no member named 'z_offset'

     MENU_ITEM_EDIT(float43, MSG_BED_Z, &mbl.z_offset, -1, 1);

                                             ^

c:\users\xxxx\appdata\local\temp\arduino_build_990647\sketch\src/lcd/menu/menu.h:310:99: note: in definition of macro '_MENU_ITEM_VARIANT_P'

         draw_menu_item ## VARIANT ## _ ## TYPE(encoderLine == _thisItemNr, _lcdLineNr, PLABEL, ## __VA_ARGS__); \

                                                                                                   ^

C:\Users\xxxx\AppData\Local\Temp\arduino_build_990647\sketch\src\lcd\menu\menu_bed_leveling.cpp:285:5: note: in expansion of macro 'MENU_ITEM_EDIT'

     MENU_ITEM_EDIT(float43, MSG_BED_Z, &mbl.z_offset, -1, 1);

     ^

Che fosse nel codice del probing la parte di codice che faceva impazzire 4.3.7 (ed in modo diverso 4.3.8) ?
Ipotesi un po' buttata a caso.