MECCANICA e DINTORNI

"Uhm no, non c'entra niente. McMax aspetta mezzo giro per essere sicuro di intercettare l'index. Una volta intercettato l'index, lo stepper parte a piena velocita'."

Hummm sicuro ? io dicevo proprio il contrario, quando si da "fuoco alle polveri" il mandrino parte a manetta mentre lo stepper impiega un attimo, in quell'attimo il sincronismo si può perdere ,aspettando un attimo in modo che il mandrino sia a regime ed intercettando l'index lo stepper può partire tranquillo . Per spiegarti meglio vedi qui come ha implementato l'accelerazione dello stepper per sincronizzarla con il mandrino https://youtu.be/beT8312k3yI?t=804

Oh magari non centra nulla per davvero e mi sono incasinato io

No, non c'entra niente
Nel caso dell'els il problema e' far partire lo stepper a bomba da 0rpm a xxx rpm in tempo (teoricamente) 0, quindi senza rampe di accelerazione/decelerazione. Il mandrino e' sempre in moto e a regime (vedi: https://youtu.be/dKnNOhTi_-8?t=116 scusa la schifezza di video, devo rifarlo quanto prima).

Se vedi, lui implementa delle rampe di accelerazione, lo vedi nel grafico che fa nel video.
La linea blu e' il mandrino, quella arancione lo stepper. Se il mandrino parte troppo cattivo e/o la rampa di accelerazione dello stepper e' settata troppo blanda, lo stepper raggiungera' i giusti giri in ritardo. Per quello fa correre di piu' lo stepper, recupera il "ritardo" rispetto al mandrino e poi procede.
Pero' e' curioso come implementa la cosa.
Devo provare a vedere se capisco qualcosa dal codice assembly...

Ottimo lavoro! Non so se è un effetto del video, ma addirittura sembra che avanzi più velocemente di come retrocede.
Che micropasso hai impostato sullo stepper?

Si, avanza più velocemente di quando ritorna.
Non è voluto però. Le rampe del ritorno le ho fatte con un delay variabile (impulso, delay da 1500us, impulso, delay da 1490us, fino ad arrivare a 400us tra due impulsi, cioè circa 150rpm).
La funzione delay, però, non continua a contare durante l'esecuzione di una isr. Quindi, più veloce gira il mandrino, più interrupt avrò e più lento il carro ritornerà alla partenza.
Avevo pensato di usare un timer invece del delay oppure direttamente un timer come pwm.
Vedrò, per intanto devo provare a fondo quanto fatto.

Per evitare il delay puoi usare il timer in "fast PWM mode". Se vuoi puoi anche giocare aumentando e diminuendo il periodo dell'impulso così vedi come si comporta e quali sono i limiti, soprattutto in velocità. Attenzione che in funzione del driver potresti avere problemi con impulsi troppo brevi: alcuni driver potrebbero non leggere correttamente impulsi troppo corti. Impostando l'interrupt di fine periodo del PWM puoi anche tenere traccia della posizione incrementando (o decrementando) il contatore dei passi.

Per Mimoletti: ho usato 1/4 di micropasso, 800 passi per giro.

Per McMax: secondo il datasheet del driver, gli impulsi devono durare minimo 4uS. Io li faccio durare 8uS. Massima frequenza 200KHz (e ci sto dentro ampiamente, 1000rpm di stepper - che non ci arrivera' mai neanche in discesa - a 800 passi per giro sono 13KHz).
Poi, a nasometro, il collo di bottiglia nel driver dovrebbero essere i fotoaccoppiatori pero', secondo il datasheet (dei fotoaccoppiatori), funzionano con impulsi ben piu' brevi (2uS o giu' di li'). Quindi si sono gia' tenuti larghi loro (anche se e' un driver cinese).

Non mi e' ancora chiaro il discorso delle variabili modificate dall'isr e lette nel main del tuo programma

Visto che stai cercando di filettare alla massima velocità possibile ti consiglio di aumentare il micropasso. Per esperienza diretta sulla mia cnc (premettendo che la rampa di EMC2 probabilmente è più sofisticata della tua), ho impostato 1600 di micropasso, e se la porta parallela me lo avesse permesso, mi sarei spinto oltre. Per quanto riguarda l'impulso di step, è importante sopra tutto che il dir non coincida con lo step.
Tanto provare non ti costa nulla.

Ciao matteou,
ti do la mia interpretazione di accelerazione / decelerazione. Dal mio punto di vista, non dovresti usare delay, ma variare la frequenza del PWM.
Oggi in coda a questa spiegazione https://docs.arduino.cc/tutorials/gener ... rduino-pwm ho implementato il PWM con rampe di accelerazione e decelerazione.
L'ho testato su arduino uno con attaccato un piccolo stepper e drv8825. I collegamenti sono banali puoi vederli online :

volatile byte accel_step = 100;
volatile byte accel_counter = 0;
volatile byte ocr2a_value = 250;
volatile bool decel = false;
volatile int passi = 0;

void setup()
{
pinMode(3, OUTPUT);
pinMode(11, OUTPUT);
pinMode(13, OUTPUT);
TCCR2A = _BV(COM2A0) | _BV(COM2B1) | _BV(WGM21) | _BV(WGM20);
TCCR2B = _BV(WGM22) | _BV(CS22);
OCR2A = ocr2a_value;
OCR2B = 50;
TIMSK2 = (1 << TOIE2); // interrupt when TCNT2 is overflowed

}
ISR ( TIMER2_OVF_vect )
{
if (decel) {
accel_counter++;
if (accel_counter >= accel_step ) {
ocr2a_value = ocr2a_value < 250 ? ocr2a_value + (accel_counter / 100) : 250;
OCR2A = ocr2a_value;
accel_counter = 0;
}
} else {
accel_counter++;
if (accel_counter >= accel_step ) {
ocr2a_value = ocr2a_value > 190 ? ocr2a_value - (accel_counter / 100) : 190;
OCR2A = ocr2a_value;
accel_counter = 0;
}
}
passi++;
if (passi == 10000){
decel = true;
digitalWrite(13,HIGH);
}
}
void loop()
{

}

Il sistema è abbastanza semplice, ho configurato il PWM in fast PWM e variando OCR2A vario la frequenza del PWM. Per variare la frequenza go agganciato un interrupt sull'overflow del timer2 in modo da incrementare / decrementare un contatore che aumenta / decrementa OCR2A. A scopo di esempio ho aggiunto una variabile passi per conteggiare dopo quanti passi deve avvenire la decelerazione. La variabile accelstep setta la pendenza dell'accelerazione in un ipotetico grafico __/---\__.
Dacci un occhio!
my 2 cent!

Grazie Umbez per la dritta.
Pensavo di fare anch'io una cosa simile, fin'ora ho usato i delay perche' ho scopiazzato dal programma di McMax e il suo lavoro lo faceva (ma era gia' in programma di cambiare).
Ho modificato un po' il tuo codice, adattandolo alle mie esigenze.
Al solito avevo messo l'incremento di passi_effettuati nell'isr ma mi dava risultati strani (solo a McMax non crea problemi modificare una variabile in una isr e leggerla nel main ).

Il timer 2 e' impostato per mettere alto OC2B al match e metterlo basso al bottom. Il top e' OCR2A. OCR2B e' sempre uguale a OCR2A-1 cosi' ho il mio bell'impulso che resta alto per 8uS (prescaler 1/128) indipendentemente dalla frequenza del pwm.

Alla funzione StepperMoveToPosition passo il numero di step che mi servono. Se il movimento che devo fare e' piccolo, parto senza rampa, altrimenti parto in rampa.
Il ciclo while dura finche' non ho effettuato tutti i passi che mi servono. Resto in attesa dell'avvenuto match (quindi ho un impulso pwm), se sono in accelerazione vado a diminuire progressivamente OCR2A/B cosi' aumenta la frequenza del pwm. Se sono quasi arrivato al numero di passi voluto, aumento OCR2A/B in modo che la frequenza aumenti e il motore deceleri.
Alla fine reimposto il timer2 per poterlo usare nella modalita' "one shot".
Al simulatore funziona e all'oscilloscopio funziona.
Anche ne programma intero non dovrebbe avere problemi (spero).

Per comodità, allego la traduzione di quella spiegazione sul PWM.
L'ho realizzata mentre la studiavo, quindi se c'è qualche errore, siate clementi.

Ciao!

In questi giorni ho avuto tempo di provare per bene il mio programma.
Purtroppo non funziona. Ad alti giri (800rpm circa) non riesce a riprendere il sincronismo.
Ho indagato un po' e sbaglia a leggere l'encoder. Ricordo che uso un encoder da 2000 impulsi, lo leggo x1.
Il canale A dell'encoder e' collegato al pin2 di arduino uno (che corrisponde all'interrupt 0). Il canale B e' collegato al pin9.
L'interrupt e' attivato sul fronte di salita del canale A. All'interno dell'isr leggo il canale B (pin9) e cosi' determino il senso di rotazione.
Quello che succede, immagino, e' che intanto che viene chiamata l'isr il canale B cambia di stato.
Quindi ho provato a fare un codice di prova, il piu' snello possibile:


Lo provo al banco, generatore di funzioni collegato a due flipflop per generare due onde quadre sfasate di 90°.
Finche' sto sotto i 26KHz tutto bene, quando salgo di frequenza la variabile "inc" cambia di valore (anche se non dovrebbe).
Il problema e' che 26KHz a 2000 impulsi/giro sarebbero 780rpm e il codice non sta facendo praticamente niente oltre che leggere l'encoder...
Sono gia' arrivato al limite del micro?

non ho seguito tutta la progettazione che hai fatto, ma come mai non hai usato entrambi i pin interrupt come Max?

Ciao.

McMax usa un encoder da 300 impulsi a giro e lo legge in quadratura (ogni cambio di stato di ogni canale genera un interrupt). In questo modo quadruplica la risoluzione dell'encoder.

Io avevo gia' un encoder da 2000 impulsi al giro e non mi serve piu' risoluzione, quindi genero un interrupt ogni fronte di salita di un solo canale (l'altro canale lo uso solo per capire la direzione)

Considera che quando si scatena un interrupt c'è sempre un context switch, quindi avrai un set di cicli "persi", probabilmente quando si alza la frequenza il segnale di dir viene perso. La tecnica utilizzata da McMax per la lettura dell'encoder non viene utilizzata per l'aumento di risoluzione, quella ne è la conseguenza, ma per questioni appunto di velocità, infatti Max va in lettura diretta sulla porta non a caso. Anche tu puoi utilizzare la stessa tecnica di lettura direttamente sui fronti di salita leggendo la porta e discernendo lo stato dei pin in and logico con maschere di bit opportune. Detto questo, nel caso tu avessi bisogno di più più input per hw interrupt è il caso di riconsiderare la piattaforma su cui stai sviluppando passando magari al 2550. Alla lunga gli artifici software non ti porteranno su una strada buona, ma ti costringeranno a peggiorare il tuo codice, rendendolo critico dal punto di vista della manutenibilita'. Questo è un parametro fondamentale che troppe volte non si considera. Se tu scoprissi un bug fra 1 anno, voglio vedere come ti ricordi del perché hai fatto un arzigogolo per gestire un caso particolare (in questo caso il tuo encoder con troppa risoluzione). Una delle regole fondamentali è che il codice "deve essere parlante" (fonte uncle bob "the clean code")

aggiungo che quando fai girare l'encoder va anche considerato per quanto tempo i fronti restano nello stato che "fotografi" con l'nterrupt.
Mi spiego meglio: l'encoder girando continua a cambiare lo stato delle uscite in quadratura e la durata di questi fronti (siano alti o bassi) sarà tanto minore quanto maggiore sarà la velocità. E questo non cambia se leggi un solo pin oppure entrambi, la durata dei fronti è funzione solo della velocità di rotazione e del numero di passi. Questo per dire che a velocità elevate il tempo che il micro ci mette ad entrare nella ISR ed arrivare all'istruzione che controlla il DIR (verificando lo stato dell'altro segnale, non associato ad interrupt) potrebbe essere maggiore del tempo in cui il tuo segnale DIR resta nello stato che ti interessa. Ricordati che i segnali in quadratura cambiano di stato simmetricamente e sfasati di 90°, questo vuol dire che quando intercetti un passo hai la metà del tempo del fronte per leggere l'altro segnale e capire in che direzione stai andando. Se trascorre più tempo il pin cambia di stato e il software lo interpreta come un cambio di direzione.

Due conti al volo:
encoder da 2000 passi
Ogni pin cambia di stato 4000 volte al giro
A 800 g/min (13,33 giri/sec) hai 53333 cambi di stato in un secondo (quindi uno ogni 18,75 microsecondi) per una frequenza appunto di 53,33Khz.
Ma per via del fatto che l'altro pin è sfasato di 90°, tu hai solo 9,375 microsecondi per leggere l'altro pin, quello che ti da la direzione, in modo corretto. Se trascorre più tempo l'latro pin cambia di stato e la direzione corretta è persa...
E attenzione, tu stai ragionando con 26Khz che è la frequenza del tuo interrupt ma in realtà il tempo che hai per leggere l'altro pin non è il periodo di 26Khz (38,4micosecondi) ma un quarto di quello...