Ritardo nell'esecuzione di comandi con MK4duo 4.3.3-5

Ciao a tutti,
anche se è il mio primo post, seguo da tempo il forum e ho sempre trovato nelle discussioni aperte da altri utenti le risposte ai miei dubbi e innumerevoli spunti di miglioramento. Stavolta sembra che io sia l'unico con questo problema, quindi eccomi qui a chiedere.
Ho una prusa i3 rework che fino a pochi giorni fa aveva la versione 4.3.03_dev di MK4duo con la quale tutto andava liscio. Poi mi sono deciso ad aggiornare il firmware alla 4.3.5 e sono iniziate le stranezze: ogni comando prima di essere eseguito da repetier host impiega diversi secondi.
Il log di repetier mostra i tempi che intercorrono tra l'invio del comando e l'ack (che coincide con l'esecuzione effettiva):

Home asse x: 15 secondi

23:07:41.398 : wait
23:07:42.455 : wait
23:07:43.477 : wait
23:07:44.055 : N30 G28 X0*104
23:07:49.096 : busy:processing
23:07:54.122 : busy:processing
23:07:59.232 : busy:processing
23:07:59.232 : X:-10.00 Y:0.00 Z:0.000 E:0.0000
23:07:59.247 : ok
23:07:59.247 : wait
23:08:00.828 : wait
23:08:01.862 : wait


G1 x10: 5 secondi

23:07:18.820 : wait
23:07:19.826 : wait
23:07:20.905 : wait
23:07:21.546 : N22 G1 X10 F4800*11
23:07:26.586 : ok
23:07:26.586 : wait
23:07:27.586 : wait
23:07:28.602 : wait


G1 x20: altri 5 secondi

23:07:30.155 : wait
23:07:31.170 : wait
23:07:32.164 : wait
23:07:33.188 : N26 G1 X20 F4800*12
23:07:38.216 : ok
23:07:38.216 : wait
23:07:39.383 : wait
23:07:40.384 : wait


Ripristinata la versione 4.3.03_dev per fare un paragone ottengo questo:

23:22:23.770 : N24 G28 X0*109
23:22:23.913 : X:-10.00 Y:0.00 Z:0.00 E:0.00 Count X:-1600 Y:0 Z:0
23:22:23.914 : ok
23:22:29.860 : N27 G28 Y0*111
23:22:31.877 : busy:processing
23:22:33.639 : X:-10.00 Y:0.00 Z:0.00 E:0.00 Count X:-1600 Y:0 Z:0
23:22:33.639 : ok

quindi niente delay paragonabili e nessun "wait" ogni secondo

Ho testato a ritroso anche le versioni 4.3.4 e 4.3.3 e ho la stessa situazione.

Qualcuno ha un'idea di quale possa essere il problema?

Grazie mille

---

Prusa i3 rework custom, Arduino mega 2560 + Ramps 1.4, Hotend IeC 0.4, MK4duo 4.3.03_dev

I wait li manda con NO_TIMEOUTS > 0 forse prima avevi 0...
Ma non c'è nessun delay nell'esecuzione...

---

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

Ciao Mago, grazie per la rapida risposta.
Ho modificato il NO_TIMEOUTS ed il log di repetier non dà più i wait. Ovviamente questo non ha variato il comportamento nell'esecuzione dei comandi.
A questo link c'è un video che mostra il problema: link
come vedi, alla connessione di repetier raggiunge anche i 14 comandi da scodare (il massimo numero visto nella 4.3.03_dev era 7, come se fosse più veloce ad eseguirli e non generasse una tale coda).
poi alla richiesta di home x in pratica "spezza" il comando in 3: 1) muove il carrello fino all'endstop; 2) si sposta a destra di 5mm (bump); 3) infine si appoggia di nuovo all'endstop. il tutto in appena una quindicina di secondi... (dal sec.24 al sec.39)
se poi sposto a destra di 100mm ho tutto il tempo di girare la telecamera prima che il comando venga eseguito, anche in questo caso "spezzato" in due con un tempo di 5 secondi tra i due movimenti. esattamente come mostrato dal log di repetier che ho postato prima...

il comportamento è analogo se digito i comandi dalla casellina GCode di repetier o se li impartisco tramite display.

La stranezza è che il problema ce l'ho anche con le versioni 4.3.4 e 4.3.3 ma non con la 4.3.03_dev...

non saprei proprio che pesci pigliare...

Purtroppo Alberto,
stesso identico problema... te l'ho notificato ieri sera in PVT su messenger.

Come ha detto qui sopra fabios, si nota anche semplicemente con un G28, i movimenti sono lentissimi e spezzati... come appunto ci fossero dei busy o wait o che altro.

Quello che posso aggiungere io è questo: con la 4.3.4 i movimenti non vengono spezzati, ma già si nota una lentezza nell'acquisizione del comando da HOST e nell'esecuzione, che però poi non sembra spezzata.


Rende la stampante letteralmente inutilizzabile

Edited 1 time(s). Last edit at 03/06/2018 06:14AM by Romulus76.

ciao romulus,
in un certo senso sono contento di non essere il solo.
posso farti un paio di domande?

- ha provato altre versioni oltre alla 4.3.4? hai lo stesso problema anche con quelle?
- qual è la versione che invece ti funziona correttamente?

La mia ultima funzionante è, come scrivevo, la 4.3.03_dev.
stasera, se ho tempo, volevo confrontare il configuration_overall della versione funzionante con quella non funzionante.

Aggiungo una domanda per Alberto: ma se devo apportare una modifica devo farla nel configuration_overall o nel configuration_cartesian? il codice del file cartesian è presente nell'overall, ma non ho capito "chi comanda" e sinceramente non mi sono preoccupato di tenere allineati i due file.
potrebbe essere un problema di "disallineamento" tra i due file?

Altra cosa che notavo è che il configuratore, se carico un configuration_overall, utilizza le stringhe di testo in fondo al file. purtroppo però io ho variato solo i parametri del codice e non le stringhe sotto... non vorrei aver creato casini per questo motivo...

Edited 1 time(s). Last edit at 03/06/2018 06:35AM by fabios.

Come già detto overall sovrascrive tutto. Il configuratore prende le stringhe dai vari configuration e li mette nel file overall modificando il parametro o eventualmente togliendo le due // se la funzione è stata attivata, quelli non previsti dal configuratore vengono copiati cosi come sono nel file overall.

Il file overall è quello che appunto sovrascrive tutte le altre definizioni. Overall sopra a tutto.

Il configuratore non prende le modifiche fatte a mano, che per carità si possono fare, ci mancherebbe non si possa fare, ma solo il database finale è quello che viene importato, quindi se fate modifiche a mano dovete segnarvele ed eventualmente poi ripeterle sul configuratore in modo da avere il file overall comprensivo di tutte le vostre scelte, l'aggiornamento è molto più facile in questo modo.

Arriviamo al punto fondamentale, quando scaricate nella vostra scheda il file compilato, IDE vi dice se la memoria è a rischio oppure no, a voi capita questo...
Provate con host a collegarvi con la scheda, diminuite i baudrate, controllate con m503 l'esattezza dei valori in memoria.
La 4.3.5 ce l'ho su una Wanhao (8 bit) e non ho rallentamenti, stessa cosa sulla delta con alligator (32bit)..

---

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

Quote
MagoKimbra
Arriviamo al punto fondamentale, quando scaricate nella vostra scheda il file compilato, IDE vi dice se la memoria è a rischio oppure no, a voi capita questo...
Provate con host a collegarvi con la scheda, diminuite i baudrate, controllate con m503 l'esattezza dei valori in memoria.
La 4.3.5 ce l'ho su una Wanhao (8 bit) e non ho rallentamenti, stessa cosa sulla delta con alligator (32bit)..

Il problema l'ho verificato con la MKS Gen (con la coreXY che hai visto in video ieri sera) sia da host che da display grafico ed il rallentamento è identico (ci sono stop di secondi fra ogni azione).

Aggiungo che ho verificato la stessa configurazione in pausa pranzo con la 4.3.2 STABLE, ed ho un feedback istantaneo sui comandi sia host che display.


Compilando la 4.3.5 con Arduino 1.8.1 mi dice questo:

Lo sketch usa 132594 byte (52%) dello spazio disponibile per i programmi. Il massimo è 253952 bytes.
Le variabili globali usano 5339 byte (65%) di memoria dinamica, lasciando altri 2853 byte liberi per le variabili locali. Il massimo è 8192 bytes.

La velocità impostata fino ad ora (posso provare a 115200 stasera) è 250000b/s

Cosa intendi con "controllate con m503 l'esattezza dei valori in memoria"??? Cosa devo verificare?

Edited 1 time(s). Last edit at 03/06/2018 09:48AM by Romulus76.

Quote
fabios
- ha provato altre versioni oltre alla 4.3.4? hai lo stesso problema anche con quelle?
- qual è la versione che invece ti funziona correttamente?

Come detto qui sopra, ho questo comportamento:
- 4.3.2 stable, nessun rallentamento, movimenti immediati e feedback lag zero
- 4.3.4 parziale rallentamento nella ricezione del comando, ma poi movimenti lineari senza interruzioni (come sugli endstop)
- 4.3.5 totale rallentamento, sia nella ricezione del comando, sia nei movimenti spezzati da pause di secondi

Mi linki la tua configurazione...

---

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

Quote
MagoKimbra
Mi linki la tua configurazione...

Dovrebbero bastare, nel caso aggiungo...

Perché feature cosa serve??

---

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

Come mai sensore camera DHT11 Ma poi non lo hai attivato??

---

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

Quote
MagoKimbra
Perché feature cosa serve??

Ti ho allegato tutto, poi verifica tu nel caso ti serva (basta verificare con un File Compare)....

Quote
MagoKimbra
Come mai sensore camera DHT11 Ma poi non lo hai attivato??

Perchè pensavo potesse essere causa di rallentamento e l'ho disattivato, anche perchè non ha mai comunicato correttamente.

E ma non hai disattivato la camera cosi fa un controllo che non c'è intanto prova a disabilitare tutto... Il DHT11 funziona bene solo con il DUE, perché usa gli interrupt sul mega solo alcuni pin possono avere gli interrupt sul due tutti, quindi sul mega bisogna scegliere pin adatti...

Poi cambia il pin per il case light mettilo sul pin 5 il 4 ho scoperto che ha lo stesso registro di timer che HAL_AVR usa per il controllo temperature e vanno in conflitto...

Si come ti ho detto gli altri file configurazione non vengono caricati proprio quindi è inutile, ma cmq è uguale all'originale..

---

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

Quote
MagoKimbra
E ma non hai disattivato la camera cosi fa un controllo che non c'è intanto prova a disabilitare tutto... Il DHT11 funziona bene solo con il DUE, perché usa gli interrupt sul mega solo alcuni pin possono avere gli interrupt sul due tutti, quindi sul mega bisogna scegliere pin adatti...

Poi cambia il pin per il case light mettilo sul pin 5 il 4 ho scoperto che ha lo stesso registro di timer che HAL_AVR usa per il controllo temperature e vanno in conflitto...

Si come ti ho detto gli altri file configurazione non vengono caricati proprio quindi è inutile, ma cmq è uguale all'originale..

In realtà la discussione per quel pin D4 l'hai fatta con me ieri... sono Alessandro.

Mi pare di aver disabilitato già la chamber nel confiuration_overall.h, o forse manca qualcosa? Cosa sarebbe, "#define TEMP_SENSOR_CHAMBER 11" da mettere a 0? (ovviamente riporto anche sotto nel file)

Quali sono i pin funzionali per poter utilizzare il DHT11 quindi?

Edited 1 time(s). Last edit at 03/06/2018 10:36AM by Romulus76.

A ok... Facciamo un passo alla volta poi vediamo come utilizzare DHT11, intanto si metti a 0 e disabilita il pin d'uscita della camera...
A questo punto, fai un'altra prova disabilita per un attimo anche la eeprom e verifica che tutto va poi abilita l'EEPROM e vediamo anche come 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

Quote
MagoKimbra
A ok... Facciamo un passo alla volta poi vediamo come utilizzare DHT11, intanto si metti a 0 e disabilita il pin d'uscita della camera...
A questo punto, fai un'altra prova disabilita per un attimo anche la eeprom e verifica che tutto va poi abilita l'EEPROM e vediamo anche come va...

Ok.. per le 18 sono a casa e riverifico, ci metto poco.. poi ti aggiorno.

Nel frattempo aggiungo per confronto la casistica che riscontro io.

Quote
Romulus76
- 4.3.2 stable, nessun rallentamento, movimenti immediati e feedback lag zero
- 4.3.4 parziale rallentamento nella ricezione del comando, ma poi movimenti lineari senza interruzioni (come sugli endstop)
- 4.3.5 totale rallentamento, sia nella ricezione del comando, sia nei movimenti spezzati da pause di secondi

Nel mio caso 4.3.3, 4.3.4 e 4.3.5 si comportano tutte allo stesso modo, cioè come la tua 4.3.5.

la compilazione con arduino ide 1.8.5 dela 4.3.5 mi dà:

Quote

Sketch uses 149630 bytes (58%) of program storage space. Maximum is 253952 bytes.
Global variables use 5464 bytes (66%) of dynamic memory, leaving 2728 bytes for local variables. Maximum is 8192 bytes.

Mentre con la 4.3.03_dev (versione correttamente funzionante):

Quote

Sketch uses 139092 bytes (54%) of program storage space. Maximum is 253952 bytes.
Global variables use 5720 bytes (69%) of dynamic memory, leaving 2472 bytes for local variables. Maximum is 8192 bytes.

Anche io ho impostato 250000b/s. Non ho capito se serve fare un test a 115200.
Mi pare di capire invece che Alberto suggerisca di provare a disattivare la EEPROM. Faccio un test stasera.

Ultima cosa: non voglio affatto aggiungere caos ma allego anche il mio configuration_overall della 4.3.5

Ok trovato il bug entrambi usate il power on, e li il problema ora lo guardo e vedo che problema c'è, si chiude in qualche loop... Per ora se potete disabilitatelo altrimenti aspettate la patch...

---

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

Quote
MagoKimbra
Ok trovato il bug entrambi usate il power on, e li il problema ora lo guardo e vedo che problema c'è, si chiude in qualche loop... Per ora se potete disabilitatelo altrimenti aspettate la patch...

Dopo provo disabilitando il PS_ON (connetto temporaneamente il PIN a +5).

Per la DHT11, come posso provare con la MKSGEN?? Parlavi di interrupt/PIN disponibili... mi spieghi, magari una dritta..

Grazie Mago, stasera provo con #define POWER_SUPPLY 0

Quote
MagoKimbra
Ok trovato il bug entrambi usate il power on, e li il problema ora lo guardo e vedo che problema c'è, si chiude in qualche loop... Per ora se potete disabilitatelo altrimenti aspettate la patch...

Confermo, disabilitando funziona tutto regolarmente.

Ora vorrei capire per la DHT11...

Altra domanda: D1 e D2 presenti sul connettore AUX-1 pare non siano utilizzabili, controllando corrispondono a RX/TX. Sono parte della seriale che va all'FTDI USB?

Ok fixato e messo su, potete scaricare e provare anche con il power on. In planner accendevo l'alimentatore anche se era già acceso qualora ci fosse pianificazione di movimento, ma quando si accende c'è il delay di 5 secondi quindi a ogni movimento accendeva (anche se acceso) con delay.. Messo il controllo...
No D0 e D1 sono RX e TX della porta seriale USB, D2 mi sembra che puoi usarlo, ma devo verificare, per ora lascia disattivo che poi vediamo...

---

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

Anche se io non ho di quei problemi... un grazie per quello che fai....caro MAGO .... te lo sei proprio meritato....

Dario

Edited 1 time(s). Last edit at 03/06/2018 04:04PM by Dariuzzo.

Grazie di che?? Sono io che faccio le minchiate che poi risolvo...

---

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

solo chi non mette le mani in pasta non fa minchiate.
quindi grazie anche da parte mia per aver messo le mani in pasta, non solo questa volta ma sempre.

comunque anche io confermo la risoluzione del problema disabilitando il power on.
domani scarico anche la versione fixata da configuratore, intanto ancora mille grazie

Alberto...beato te...al lavoro... gli altri fanno minchiate.... io le devo risolvere... e grazie... nemmeno per sogno....

ahahah, sembra la mia giornata lavorativa di oggi...