MECCANICA e DINTORNI

Il problema rimarrebbe meccanico , ovvero il bloccaggio preciso del mandrino....

Esiste una funzione che restituisce la posizione angolare del mandrino e per fare fori sulla circonferenza o radiali va benissimo. Purtroppo la risoluzione è limitata a quella dell'encoder pertanto, con un econder da 250 passi (1000 nel software) si ottiene una risoluzione di 0,36°.

Ottimo, allora mi sa che darò fondo al portafogli e ordinerò tutto, il carrello amazon è già pronto, per me 0,36 gradi sono anche troppi come risoluzione!

Per il bloccaggio del mandrino vorrei prendere in prestito una idea che ho visto su un forum dei cugini francesi, dove su un Multitech 800 come il mio, hanno installato un freno a disco da mtb sulla puleggia del motore

Secondo il mio punto di vista è un'enormità , sbagli di meno disegnando con il compasso le divisioni....

se il software indica con precisione il fronte di salita o discesa l'errore e'piccolissimo

Il problema non è l'errore ma la risoluzione. Il sistema è completamente digitale quindi l'eventuale errore è solo dettato dai tempi ed è assolutamente trascurabile; pesa molto di più la precisione intrinseca nell'encoder ovvero nel disegno del disco ottico che c'è al suo interno.
0,36° sono tanti per un divisore perché non ti permette di dividere finemente come faresti con un divisore normale a dischi che, oltre alla risoluzione dei dischi stessi (che varia in funzione del numero dei fori) ha anche una demoltiplica 40:1.
In realtà il grosso problema è che, essendo un sistema discreto, non ti permette di variare finemente il numero di divisioni perché 0,36° (o la risoluzione eventuale con numero di passi differente) è il minimo movimento che riesci ad effettuare quindi se il valore in gradi della singola divisone che devi ottenere non è divisibile per un multiplo qualsiasi di 0,36° introduci un errore.

diciamo che usi un 250 perche' poi andresti troppo veloce per le letture del sistema quando fai avanzamenti mentre se facessi solo posizionamenti la risoluzione potrebbe essere molto piu' elevata.
Gli encoder oggi non costan molto, la frequenza derivante dai giri max di un tornio li regge anche uno da 2500
be' usi un encoder da 2500, un divisore X10 quando filetti ecc e leggi diretto quando posizioni esiston divisori x10 poi eletronicamente e' piu' comodo dividere per 2 e multipli ,se si puo' direttamente fare sul micro, quindi magari e' meglio un 4000 un 3600 ecc
Su arduino non so come funzioni ma su altri sistemi puoi dividere come moltiplicare gia' via software quindi potresti giocartela in vari modi senza nulla cambiare a livello hardware.
Certo leggerai sempre 2 fronti per sapere la direzione e va' considerato anche questo

lelef non è così semplice. L'encoder esce con un segnale in quadratura e per mia esperienza è sempre meglio far leggere i fronti direttamente al micro senza interporre alcuna logica, questo perché, soprattutto in filettatura, i passi vanno letti precisamente senza il rischio di perderne durante inversioni o stop. L'altro motivo per cui è importante che sia il micro a leggerli è che nei due segnali di quadratura hai l'informazione sul verso di rotazione che, in caso di logica esterna, dovresti trattare separatamente.
Un encoder da 2500 passi con arduino non ce la fai a leggerlo alla velocità di rotazione di un tornio... o meglio, l'econder potresti anche leggerlo ma non ti avanzerebbe tempo per fare altro....

Credo che il vero problema di quei 0.36 gradi sia il fatto che sono cumulativi...Se fai 10 divisioni l'errore diventa 3,6 gradi ...Su 100 divisioni 36 gradi....inaccettabile...

un problema simile lo risolsi sui PIC di fascia alta di 20 anni orrsono ed avevo scritto tutto in assembler, il C per i micro non mi e' mai piaciuto ma oggi ormai van tutti comodi
Un interrupt ogni tot eventi su un contatore per dividere il segnale e non perdersi il cambio di direzione a piena risoluzione? hai lo stesso tempo di calcolo di prima

@Davide: no assolutamente non è come dici. 0,36° non è l'errore ma la risoluzione, ovvero il minimo spostamento apprezzabile dal sistema. Ti faccio un esempio: poniamo che ti vuoi spostare di 20°; 20 non è divisibile per 0,36 quindi la posizione su cui puoi fermarti sarà:
20/0,36 =55,55555
arrotondi il divisore all'intero più prossimo quindi 0,36*56=20,16°

Nel caso specifico il tuo errore sarà di 0,16°.
E comunque l'errore massimo sarà rappresentato dalla metà di 0,36, quindi 0,18.

@lelef: anche io ho usato assembler finché ho potuto ma ora non è umanamente possibile. Non è una questione di andar comodi ma proprio del fatto che le funzioni sono talmente complesse che hai bisogno di un linguaggio più strutturato. Poi se ci sono delle routine dove vuoi controllare meglio i tempi di esecuzioni quelle puoi comunque scriverle in ASM: il compilatore le lascerà invariate.
Il cambio di direzione te lo da la fase del segnale in quadratura questo significa che ad ogni cambio di stato devi intercettare entrambi i segnali e, sulla base dello stato attuale e del precedente devi decidere se incrementare o decrementare.
Se ti interessa ti spiego come lo faccio io con arduino.

Max, a quando il nuovo ELS? magari su piattaforma STM32Nucleo...
se non sbaglio ci stavi facendo un pensiero....

Hai Ragione max, ho letto male , comunque anche 0,16 non è poco...se fai 100 divisioni per avere un nonio con i cent come ho fatto sull'affilatrice ti viene 100/0,36 =277.777777777 arrotondi a 278 che moltiplicato 0.36 da 100,08.
ora resta da capire se quello 0,08 è l'errore totale oppure cumulativo . se è totale è trascurabile ma se è cumulativo son c...zzi
con 100 divisioni avremo una tacca ogni 3.6 gradi , con 8 gradi di errore totale si sbaglia di due tacche e un po'...

Si, capisco benissimo che con sistemi complessi scrivere la stessa cosa in C ma da zero in ASM e' mostruoso, il C cominciava ad esser presente anche ai tempi solo che per quello che facevo e a cui ero abituato uscivan cose mostruose.
Per un apparecchio che faceva varie misure usavo righe ottiche centesimali ad un certo punto ne' il mio fornitore ne' il concorrente ne fornivano piu' ,solo millesimali! e l'intefacciamento col micro divenne un problema, i dati potevo visualizzarli su un alfanumerico o inviarli a pc tramite seriale dove un programma faceva grafici analisi e confronti tra piu' curve misurate.
c'era il C e delle routine di calcolo belle e pronte in ASM... dei mostri! mangiavan tempi e meoria in modo pazzesco mi son scritto il mio codice all'osso giusto per cosa doveva fare semplice ed efficace.
Una riga ottica o un encoder eletronicamente sono identici, se devi dividere per 10 sempre solo per 10 ed il riporto da considerare per l'inversione e' da parcheggiare in un buffer non sara' mai oltre tot bit come non lo sara' mai il risultato, un compilatore C generera' un mostro generico che magari potrebbe dividere per 256 con un riporto enorme che pero' non si usera' mai.
Le differenze le vedi in simulazione riportato nel mondo PC e' come se lo stesso calcolo invece che in 3 secondi lo fa in 3 giorni
c'e' chi se ne frega e invece di andare a 4Mhz va a 20 per guadagnare tempo solo che a 20 tirarsi dentro un disturbo e' un'attimo e ti ritrovi errori che se vuoi sistemare devi lavorare di hardware e comunque a mio vedere il sistema sara' sempre piu' debole e potenzialmente erratico di quello che potrebbe essere.
Visto che puoi inserire ASM forse se ti scrivi la parte di divisione in asm ci stai coi tempi per un encoder con molta piu' risoluzione ,se ho capito la velocita' per ricevere i dati c'e' ,e' il tempo di calcolo che manca
vedo se trovo quello che ho scritto all'epoca sarebbe solo da tradurlo da ASM Microchip a quello per Arduino piu' i ritocchi del caso

Lelef credimi avevo le tue stesse identiche convinzioni sulla pesantezza del codice scritto in C rispetto all'ASM ma mi sono dovuto ricredere. I compilatori attuali hanno dei livelli di ottimizzazione tale che un blocco complesso conviene scriverlo in C e farlo ottimizzare al compilatore piuttosto che avere la presunzione di scriverlo in ASM pensando di riuscire a fare meglio.
Riguardo alle divisioni il problema é che ogni fronte di ogni segnale sta sotto interrupt quindi più passi devi leggere e meno tempo avrai per fare il resto, ivi compresi controlli importanti tipo tracciatura della posizione del carro per fermare la filettatura alla posizione desiderata e, ancora più importante, la divisione dei passi per rispettare il passo del filetto.

@AlBi si l'idea ce l'ho già... ma mi manca il tempo