MECCANICA e DINTORNI

fra poco per far girare il programma spegni il motore del tornio lool
scherzo eh bene!

McMax, se vuoi modificare il tuo programma, alla luce di questa "analisi", io spegnerei il timer0, sostituirei attachinterrupt con la manipolazione dei registri e cambierei delay (che non funziona piu') con _delay_ms(). Veloce e facile e guadagni un bel po'. Anche a bassi giri (3-400rpm) ti eviti gli errori dovuti all'intervento dell'isr del timer0.
Il resto delle ottimizzazioni non so se valga la pena farle, dovresti rivedere un po' tutto il programma e, comunque, se non parti accelerando e finisci decelerando dubito che lo stepper riesca a partire in bomba (forse un nema17 che ha poca inerzia... il mio nema34 non ce la fa. Parte senza rampa fino a 150rpm. Oltre stalla).
Resterebbe il problema dell'int e del long modificato nell'isr e letto fuori, dovresti sistemare disabilitando l'interrupt quando vai a leggerle.

Una domanda: quando ho una variabile che viene modificata da una isr devo dichiararla volatile (cosi' il compilatore sa che deve ricaricarla ogni volta perche' potrebbe essere cambiata dall'isr a sua insaputa).
Ma se ho il contrario? Cioe' ho una variabile che viene modificata nel main e controllata nell'isr. Non penso serva dichiararla volatile (quando entra nell'isr il compilatore carica e scarica i registri che gli servono e, comunque, all'interno dell'isr va a leggere dalla memoria o dal registro, se una variabile e' fissata in quel registro). Io ho fatto cosi' e funziona ma non so se funziona per caso o perche' il mio ragionamento e' corretto. Anche qua, in ottica di ottimizzare piu' possibile il codice.

Altra curiosita': attivando l'ottimizzazione -O3 (massima velocita'), la mia isr ci mette circa 0.5uS in meno ad essere eseguita. Poca cosa ma quello che e' interessante e' che certe variabili restano fisse nei registri (probabilmente il compilatore vede quelle caricate e scaricate piu' spesso e dedica un paio di registri a quelle variabili) risparmiando tempo (non deve caricare e scaricare dalla memoria. Se l'indirizzo di memoria e' a 16bit, il comando lds occupa 2 cicli e il comando str altri 2. E questo per una variabile byte. Se fosse una int sarebbero 4+4 cicli. Una long 8+8 cicli).
Quindi anche nel resto del programma si ha un incremento di velocita' che, pero', si paga con un raddoppio della lunghezza del codice (se con l'ottimizzazione standard di arduino -Os il mio codice occupa il 35% dello spazio, con l'ottimizzazione -O3 occupa il 77%).

E infine un'altra cosa che sapevo ma non avevo realizzato di sapere. L'alu puo' fare operazioni solo sui registri. Se i registri sono a 8bit, devo caricare i dati dalla memoria un byte alla volta, fare l'operazione, salvare in un registro e scaricarlo in memoria, byte per byte.
A questo punto immagino che un processore a 32bit abbia registri da 32bit con tutti i vantaggi che si porta dietro.
Poi c'e' il discorso dei bus di memoria ma li' devo ancora interiorizzare il discorso.

Ultimissima curiosita': in C scrivo a++; (la variabile "a" e' un byte). Il codice compilato non fa una addizione ma sottrae ad "a" il valore 255 (0xff). Immagino sia per evitare l'overflow (se a=255 e facesse a+1=256, il bit in eccesso non saprebbe dove metterlo... sottraendo 255, invece, la variabile va in overflow ma restando sempre nel suo spazio di memoria di 8 bit. Intelligente!).

Butto ancora un po' di carne sul fuoco... il dubbio che mi viene e' che stia sbagliando qualcosa.
Come al solito diamo un po' di numeri, basandoci sui due programmini che ho fatto (il mio che legge l'encoder a x1 e quello di McMax modificato con la serie di if che legge l'encoder in quadratura) e che metto in allegato.
Per il programma test_velocita (che legge x1) consideriamo un encoder da 2000 impulsi a giro. Per il programma mod_isr (che legge x4) consideriamo un encoder da 500ppr.
In entrambi i casi avremo 2000 impulsi a giro.
Solito setup, generatore di funzioni->flipflop->arduino->analizzatore logico. Incremento di 10KHz alla volta finche', sull'analizzatore logico vedo che il segnale sul pin8 non e' piu' simmetrico (il pin8 cambia di stato ad ogni interrupt, se il segnale non e' piu' simmetrico vuol dire che il micro passa tutto il tempo nell'isr e non ha tempo di eseguire il main program. Nel grafico e' segnato come enc_step).
Fin qua il ragionamento e' corretto?

Adesso i numeri, gli screenshot in allegato:
- test_velocita arriva a 200KHz. A 2000 impulsi a giro (x1) sono 6000rpm
- mod_isr arriva a 40KHz. A 500 impulsi a giro (in quadratura) sono 4800rpm

Il test e il ragionamento sono corretti?
Se e' tutto corretto, perche' dovrei usare un encoder con meno passi e leggerlo in quadratura piuttosto che un encoder con il quadruplo dei passi e leggerlo a x1?
La risoluzione e' sempre la stessa (ogni passo che leggo sara' 1/2000 di giro). Un encoder da 500ppr e uno da 2000 costano praticamente uguale (omron cinese).
Tralascio l'ipotesi di dover leggerlo in quadratura perche' si ha necessita' di avere maggior risoluzione (chesso', l'encoder con maggior risoluzione disponibile ha 10.000ppr. A me ne servono di piu' e quindi lo leggo x2 o x4) ma non e' il nostro caso.

Matteo: "Un encoder da 500ppr e uno da 2000 costano praticamente uguale (omron cinese). "

Si è vero. Dicamo però che parlando di encoder di qualità, una volta un encoder ad alta risoluzione costava parecchio di più visto le tolleranze che la geometria del disco ottico interno deve avere. Oggi la roba cinese fa cagare uguale sia che sia da 500p che da 4000p quindi uno vale l'altro.... sempre fuffa stiamo usando

Comunque sono fisime: io preferisco usare la lettura in quadratura su entrambi i canali per sfruttare tutta la risoluzione, tu preferisci usare un canale e leggere l'altro in polling per la direzione. Possiamo stare a discutere giorni sulla durata delle ISR, con o senza if, con o senza la lettura ad indice dell'array, ma qui scendiamo veramente nel gusto personale. A me piace la roba simmetrica, e se posso evitare le istruzioni condizionali nella ISR preferisco. Ma se mi chiedi un motivo tecnico valido non ce l'ho.... diciamo che quando ho studiato io le risorse dei micro erano risicate quindi si cercava di avere un quadro esatto delle durate e le istruzioni condizionali non aiutano in questo. Oggi già che scriviamo in C il 90% del lavoro lo fa il compilatore quindi o ti fidi di quello che fa oppure, come hai fatto tu, vai a disassemblare per capire cosa sta succedendo.... a livello accademico va bene, ma a livello professionale ormai non c'è più nessuno che lo fa, se non per trovare un bug, e anche li è raro.

Ehm si, troppo abituato alle cinesate. Non avevo pensato ai prodotti seri (anche se, almeno nel mio settore, anche i prodotti considerati professionali di professionale hanno poco se non il prezzo... smetto che altrimenti vado molto offtopic).

Siamo d'accordo che siano, a livello pratico, seghe mentali. Io mi ritrovavo un encoder da 2000ppr (perche' mimoletti voleva che usassi quella risoluzione) e ho fatto il programma di conseguenza.
Se fossi partito usando la tua els, avrei avuto un encoder da 3-400ppr e avrei fatto il mio programma leggendo in quadratura.

Per il resto pienamente d'accordo col tuo discorso, a livello istruttivo a me e' stato molto utile ma se il mio programma avesse funzionato fin da subito non mi sarei mai sognato di andare a vedere il codice assembly

Il thread sull'els con l'stm32 mi ha messo la curiosita' di come interfacciare un encoder con mach3.
Con sorpresa mach3 si accontenta di un impulso a giro e, da quello che dicono, fa un buon lavoro ugualmente.
Non e' che puo' inventarsi quello che non c'e', quindi prende per buona la velocita' che ha letto e la usa per dare la temporizzazione al passo passo. Poi aggiusta (eventualmente) il tiro al giro di mandrino successivo.
E, sempre da quel che dice il manuale, ha una tolleranza sulla variazione di velocita' abbastanza ampia (+/-40%) mantenendo il filetto nei limite della tolleranza.
Non sono granche' convinto... pero' se funziona...

Quando mi sono documentato per sviluppare l'els avevo scoperto anch'io questa cosa; in pratica non ci vuole nemmeno l'encoder, basta un sensore hall e sei a posto. Concettualmente non fa una piega, se si calcola con precisione la velocità, anche considerando che l'inerzia della massa in rotazione (assieme fuso mandrino, autocentrante, pezzo) non consente grosse variazioni di velocità nell'ambito dello stesso giro, il sistema potrebbe pure stare in piedi. Alla fine se anche avessimo un errore sarebbe impercettibile ed il filetto farebbe comunque il suo lavoro. Diverso è se dobbiamo filettare con precisone una vite di manovra... li il discorso cambia un po'.... ed infatti non mi pare che mach3 venga utilizzato sui centri di lavoro professionali: un motivo ci sarà !

Amici che lavorano su centrini da qualche centinaia di migliaia di euro o su alesatrici da milioni mi dicono che i controller girano su windows 7 o 10.
I siemens sicuramente, mi pare anche fanuc e heidenhain.
Quello che segue sono mie idee, non ho voglia di cercare riscontri ma penso di non andare lontano dalla verita'.
Immagino che il controller sia usato solo come front-end per poi delegare a qualche micro le operazioni in real-time. Altrimenti la latenza di un s.o. non realtime sarebbe troppo alta.
I controller pro hanno hw esterno a cui dicono "sposta l'asse x di 300mm a 1mt/min" e l'hw esterno si occupa di generare gli impulsi correttamente temporizzati.

Mach3 deve generarsi gli impulsi usando l'hw del pc e, un po' per colpa dell'architettura e un po' per colpa del s.o., oltre un certo limite non ce la fa (in questo, macOS e' avvantaggiato, almeno cosi' mi racconta un tecnico audio, nel suo settore la latenza deve essere virtualmente 0).
Penso che se si collegasse un hw esterno che possa ricevere comandi da Mach3, le performance sicuramente aumenterebbero.

Poi, ovviamente, a livello professionale contano anche altre cose (in primis disponibilita' di assistenza e pezzi di ricambio a tempo record. Mi dicevano che siemens fa abbastanza cacarissimo come controller/linguaggio di programmazione, inutilmente cervellotico. Pero' tecnici e ricambi siemens si trovano anche in mezzo al deserto).

@ matteou
Mach3 deve generarsi gli impulsi usando l'hw del pc e, un po' per colpa dell'architettura e un po' per colpa del s.o., oltre un certo limite non ce la fa

credo sia così solo se si usa la parallela del PC.
in caso si utilizzi una scheda dedicata la generazione degli impulsi dovrebbe essere demandata a quella.

@matteou: nel mio piccolo ti confermo quanto hai ipotizzato.

Proprio ieri ho dato una mano a sostituire la batteria del BIOS di una macchina utensile 5 assi.
Sistema operativo Win7 installato su scheda madre di un PC standard.

Tramite i connettori del bus PCI, il PC dialoga con tre schede proprietarie che si occupano di gestire la macchina. Sulle schede proprietarie ci sono integrati dedicati tra cui alcune Altera. Sicuramente roba appositamente sviluppata per eliminare ritardi e problemi hardware vari.

Il PC gestisce l'interfaccia grafica. Se anche la grafica non dovesse aggiornarsi in tempo reale non morirebbe nessuno.

Ciao :-)

Mauro

@ gigathegiant: sulla parallela (che sia nativa o un convertitore usb->parallela) sicuramente fa tutto via sw.
Ho un vago ricordi di hw usb che si interfaccia con mach3 (schede mesa? mi gira sto nome) ma non ho mai approfondito.

@ billielliot: interessante. Demandare a windows (ma in generale a qualsiasi pc e s.o.) la gestione di una macchina, da quel che so, non e' conveniente. E tu me l'hai confemato.
Invece usare un pc per l'interfaccia utente ha i suoi vantaggi e se la quota su schermo si aggiorna ogni 1-2-x ms non e' un problema.

Anche mach 3 si comporta così, quello che manda al controller è prioritario rispetto a quello che si vede a video ...una delle prime volte che l'ho usato mi è venuto un colpo perchè quello che vedevo a video, era in notevole ritardo rispetto a quello che stava facendo l'utensile ... ma poi alla fine è tornato tutto ...