[RISOLTO] problema movimento motori

[menniti]

Ho una CNC 2417 cinese, controller CNCCmini della Laseraxe(molto semplice con tre driver a4988, una board arduino nano montata su connettore) alimentata a 12V, tre motori anonimi spacciati come NEMA17 da 1,5A, uno spindle a 12V 5000 giri. Risolti i primi problemi di scatti nei movimenti (ho portato la VREF a 0.8V e aggiunta una ottima velntola per raffreddare tutto) e quelli di livellamento attivando la relativa funzione, con bulini da 0.1mm 10° e da 0.2mm 20° ho ottenuto dei risultati davvero eccellenti, sia con PCB tipo THT che con SMT.
Improvvisamente, una decina di giorni fa l'ho accesa e mi sono accorto che i tre motori (tutti nello stesso momento!) hanno iniziato a generare movimenti anomali degli assi, che non si muovono più passo passo ma è come se fossero pilotati da motori normali. P.es se do' un comando di spostamento di 50mm è come se il motore partisse e camminasse a fatica e poi si fermasse con una certa inerzia.
La cosa che ho subito notato è che se la porta USB è scollegata, fornendo alimentazione al controller i motori sono "bloccati" come dovrebbe essere, però appena collego il cavo USB proveniente dal PC, essi si "sganciano", mentre io ricordo che prima restavano comunque bloccati.
Ho provato a sostituire l'alimentatore, i driver, un motore (con un NEMA17 serio), la porta USB del PC, perfino un altro PC, ho ricaricato il firmware, ma non cambia assolutamente niente.
Allora ho comprato un nuovo controller, un woodpecker 3.2, sempre cinese e più o meno simile al precedente, ma più dotato di uscite e con il microcontrollore e l'interfaccia USB on board, sostanzialmente migliore, l'ho collegato ma fa la stessa identica cosa.
A questo punto sono davvero esterrefatto e non so più dove mettere le mani.
La mia speranza è che qualcuno possa aver sentito di un problema simile e darmi una dritta.
Grazie.

[turbina]

Prova a togliere tutti e 3 i motori dalla meccanica e mantenendoli separati dalla meccanica vedere come vanno

[menniti]

Ciao, ho fatto queste prove:
Collegando il motore sganciato dalla meccanica fa la stessa cosa, è una sorta di "swing" peraltro con l'inerzia arriva a spostarsi 2cm se imposto 10mm.

A questo punto ho programmato un Arduino e su una breadboard ho collegato un driver, la 12V ed il motore, così con la scusa ho creato una base di test. Risultato: pilotati via Arduino i driver funzionano regolarmente, i motori si muovono con la consueta precisione, sparisce quella specie di cigolio, insomma funziona tutto.

Ora sto cercando di usare allo stesso modo l'Arduino NANO montato sul controller, visto che i tre segnali di enable, step e dir sono collegati agli stessi pin che ho usato io per il mio test, però al momento così i motori non danno segni di vita, però i segnali sui 4 fili arrivano regolarmente.

Insomma sembrerebbe qualcosa sulle due schede oppure qualche comando software che fa sballare il pwm, continuo a fare prove, ma sto davvero impazzendo!

Grazie per l'aiuto.

[menniti]

Scusa Turbina, ma io l'immagine del tuo profilo la conosco bene, non è che ci conosciamo da molti anni sul forum di Arduino?

[turbina]

Probabilmente, di la sono icio alias maurizio il mio nome

[menniti]

Appunto Maurizio, sono Michele, ciao, non sapevo fossi così attivo e da così tanto tempo in questo mondo. Mi fa piacere. Complimenti!
Queste le nuove prove: Se uso l'Arduino del controller col mio sketch di prova, collegandolo ad un driver e ad un motore, funziona tutto regolarmente, se rimetto nel Nano il firmware originale della CNC e poi collego sempre un driver esterno ed un motore ecco che ricomincia il problema, poiché la presenza o meno del collegamento ENABLE è ininfluente e il comando DIR funziona, deduco a questo punto che sia la stringa che arriva all'ingresso STP che dà i numeri.
Infatti se copio/incollo G91G0Z-5.00 (o G91G0Z5.00 cambia la direzione) il motore parte col il cigolio e non come dovrebbe

[turbina]

G91 è il modo incrementale, usa G90, imposta anche il Feed con F500 ad esempio

[menniti]

Premesso che uso grblControl 0.9 in quanto richiesto dal firmware della scheda (ma ho provato 1.17 senza avere segni di vita...), la stringa prevista nel setting riguarda solo Z, l'ho comunque modificata, ma cliccando sulla freccetta della direzione X mi dà
$G < [G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F0. S0.]
ok
G91G0X5.00 < ok
G90 < ok
Se ripeto la sequenza di comandi manualmente, usando G90 al momento opportuno, non cambia nulla
$G < [G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F0. S0.]
ok
G90G0X5.00 < ok
G90 < ok

E comunque la cosa stranissima è che senza toccare niente questo problema è apparso da un giorno all'altro e me lo fa anche con il nuovo controller, peraltro diverso come modello, ed anche se collego il controller ad un altro PC, roba da impazzire!

[turbina]

Se il difetto lo ha fatto da un giorno all'altro e la versione del firmware in grbl non è cambiata e nemmeno i settaggi Allora il problema è sicuramente nel G code Probabilmente hai cambiato il cam o aggiornato il cam nel negli ultimi tempi

[menniti]

Aspetta, forse mi hai dato una indicazione interessante. Allora io uso FLATCAM ma non l'ho aggiornato, ho però aggiornato Eagle alla versione 8.7 che in effetti usa un CAM molto diverso dalla precedente 7.7. Secondo te potrebbe essere che l'ultima volta io gli abbia caricato un file creato a partire dal nuovo Eagle e questo file mi abbia in qualche modo "sporcato" qualcosa? Il discorso non farebbe una grinza, ma questo potrebbe ripercuotersi anche sul solo grblControl? Infatti io non sto provando a fare incisioni, apro il programma senza caricare file .nc e uso le frecce per far muovere gli assi.
Peraltro il nuovo controller, che mi è arrivato questa mattina sono assolutamente sicuro di averlo usato sempre senza file .nc.
Ora se comunque così fosse come potrei resettare il grblControl e i due controller? Nel vecchio controller peraltro ho più volte caricato il firmware ma senza che cambiasse niente.
Grazie.

[menniti]

Ho fatto un test caricando un file creato sicuramente col vecchio CAM, ho collegato solo il motore X ma purtroppo il movimento non cambia, si sente come se "spuntasse", poi prende velocità e al momento di fermarsi in realtà continua un poco per inerzia, si comporta come se fosse un motore normale invece di uno stepper. Ah, ho anche usato una cartella di grblControl scaricata fresca da Internet, quindi incontaminata, a questo punto potrebbe esserci qualcosa nella eeprom dell'Arduino.

[menniti]

Ho fatto ulteriori prove con un portatile, sempre con W10, sul quale non era mai stato caricato software per CNC, ho messo la sola cartella grblControl senza file provenienti da CAM. purtroppo non cambia niente. Ho reperito i driver aggiornati (ma probabilmente lo erano anche prima) per il CH340 montato sui due controller, ma anche qui nessun risultato.
In pratica, semplicemente inviando i comandi di direzione X-Y-Z mediante il grblControl i motori girano in modo anomalo, anche senza essere collegati agli assi, e, se collegati agli assi, fanno percorrere loro circa il doppio del valore impostato.
Ho notato questa cosa: se collego l'alimentazione di 12V al controller istantaneamente i tre motori si bloccano e cercando di ruotare gli assi a mano occorre molta forza e quando si riesce fanno appena uno scatto. Appena collego il cavo USB ad un qualsiasi PC i motori si sbloccano come se avessi tolto i 12V e gli assi girano liberamente. Tutto ciò torna con il comportamento del pin ENABLE, appena si collega l'alimentazione è a 0 e i motori sono bloccati, quando si collega l'USB va a 5V e i motori si sbloccano, appena do un comando di movimento l'ENABLE va a 0, però il comportamento dei motori è anomalo.
Ora a me pare di ricordare che quando funzionava tutto bene i motori si bloccavano fornendo l'alimentazione e si sbloccavano solo togliendola, mentre il collegamento USB era ininfluente, quindi forse l'ENABLE restava sullo 0 ma non capisco cosa possa essere cambiato visto che il software di controllo non è stato modificato. Comunque sia ho provato a collegare qualche istante il pin ENABLE dei driver a massa, in effetti i motori si bloccano ma il movimento non cambia.
Davvero non so più dove sbattere la testa, purtroppo non conosco il grbl né come fornire comandi via seriale senza usare il software di controllo altrimenti si potrebbe testare un comando di movimento diretto e vedere che succede.
Potete aiutarmi?

[menniti]

Ho fatto un video che ho inviato al cinese, https://www.dropbox.com/s/l0lrk7y1we71e ... d.mp4?dl=0 così si può vedere (o meglio ascoltare) esattamente la cosa strana che succede, alzate l'audio altrimenti non vi rendete conto.
PS: ho aperto un Topic anche sul Forum Arduino, la speranza è che possa leggerlo qualcuno che ha lo stesso mio problema, sper di non aver violato qualche regola.

[menniti]

Io continuo a postare aggiornamenti nella speranza che mi aiutiate a risolvere il problema.
Ho fatto un test su breadboard con Arduino Nano,un driver ed un motore nuovo. Ho provato sia il firmware originale che il grbl0.9j, che come avevo notato usano pin differenti, li ho localizzati e ho fatto funzionare entrambi con grblControl0.8 e Candle0.9. Il problema rimane, ma un piccolo passo in più l'ho fatto, analizzando tutto con il DSO.
EN: è HIGH, va il LOW appena arriva il comando, quindi OK
DIR: cambia da LOW ad HIGH in base alla direzione del comando, quindi OK
STEP: arriva una serie di impulsi alla frequenza di 2kHz e duty cycle 4% per tutta la durate del movimento, fatta eccezione per la parte iniziale, in cui la frequenza va da 0 a 2kHz e quella finale, in cui la frequenza va da 2kHz a 0; questi due passaggi hanno una durata costante e provocano appunto gli "swing" iniziale e finale del motore, per cui se ordino un movimento di 100mm si vedono gli impulsi incrementare durante lo swing iniziale, poi la frequenza è stabile per tutto lo spostamento ed infatti il rumore è normale, e quando finisce inizia il decremento degli impulsi e relativo swing finale.

In pratica se il segnale partisse in modo stabile e non incrementale e finisse sempre in modo stabile e non decrementale io avrei risolto il problema!

La stringa che parte dal software, in base alla direzione, è G91G0X-100.00 (o G91G0X100.00); TURBINA mi aveva spiegato che G91 è appunto il comando "incrementale", e mi aveva consigliato di usare G90; ho quindi inviato la stringa modificata dalla riga di comando del programma, ma purtroppo non è cambiato nulla.

[Pedro]

l'aumento, e la relativa diminuzione, della frequenza dipende dall'accelerazione impostata nel firmware, devi controllare li se vuoi cambiarla