MECCANICA e DINTORNI

Appunto...

Partecipo volentieri a questa discussione e vi metto a conoscenza di quello che sono riuscito a fare fino ad ora, vado a memoria dato che non ho sotto mano il programma:
- motore nema 34 wantai diretto su un bv 20 con vite passo 3 alimentato a 60v (starato alimentatore fino a 70v ma non migliora molto):
velocita' "affidabile" circa 180 giri a 1/2 passo e 160 a 1/8 di passo , per avere una risoluzione decente io userei 1/8 di passo
diciamo che ho risoluzione devente e volocita' di 160x3=480mm/min ovvero se filetto passo 1 ho il mandrino a circa 480 giri (comunque pochi se devo fare un m6
..ma ci accontentiamo, diciamo che gli inserti sono utili solo perche' anno il profilo corretto ma come velocita' l'hss va ancora alla grande alla grande)
- fino ad ora ho fatto solo l'avanzamento manuale con interruttore avanti indietro e potenziometro per la velocita' con rampe accellerazione messe in un array che
viene scalato mano amano che procedo. Posso gestire anche inversioni di marcia con decelerazione-inversione senso-accellerazione.(questo mi ha un po
incasinato la linearita' del programma).
- il programma sostanzialmene si concentra in una funzione di avanzamento che viene sfruttata in tutti i movimenti sia di filettatura , sia tornitura sia ritorno rapido.
in questa ho inserito un contatore che fa scalare l'array per sommare il tempo di accellerazione, in esso contenuto, al tempo di passo.
- il tempo di passo e' per ora gestito dal timer che attiva l'inerrup per far fare il passo con la tempistica corretta.
basta sostituire l'ingresso di clock con quello dell'encoder mandrino e ci siamo.
- problema... l'encoder deve essere in relazione alla capacita' del timer 16 o 8 bit abbastanza grande per filettare passi grossi e abbastanza preciso per quelli piccoli.
per ora sono incasinato sulla gestione dell'encoder in quadratura dato che mi impegna un'altro timer e ora non ricordo bene il motivo ma no avevo trovato soluzione
migliore che demandare ad un'altro micro il compito di contare gli impulsi e determinare il verso di rotazione e, al raggiungimento del valore presettato, dare il
segnale all'arduino di gertire il passo ecc..

Scritto frettolosamente
Ora devo andare ma la prossima volta vi porto informazioni piu' dettagliate.

Mandi Mecha

Grazie Mecha, informazioni preziose!
Io oggi ho pensato un po' all'algoritmo ed a tutti i conti da fare per aggiustare il passo. Sto approntando un file EXCEL con tutti i conti in funzione del passo della vite e di eventuali de/moltipliche su encoder e vite. La difficoltà sta nel trattare i conti in modo che siano facilmente gestibili dal firmware senza appesantire troppo il ciclo; soprattutto mentre di lavora visto che, in quel caso, la velocità di rotazione verrebbe pesantemente condizionata dal momento che il micro dovrà gestire continuativamente l'ingresso encoder.
Ho fatto l'esercizio considerando la vite del mio CASER che purtroppo è 8 filetti per pollice quindi con una complicazone in più; la vite in millimetri per fare passi metrici è sicuramente più semplice da gestire. Alla fine quello che cambia è la precisione delle approssimazioni che per forza di cose vanno fatte, soprattutto quando si fanno passi "dispari"... e se la vite è in pollici si parte da una vite "dispari"

Io sto pensando di legare mandrino e vite da una relazione numerica statica e predefinita piuttosto che temporale; le relazioni temporali inseriscono un errore che a mio avviso è troppo per le precisioni richieste; in pratica come se fisicamente avessimo un vincolo meccanico tra mandrino e vite, indipendente dalle variazioni di velocità o non-linearità dovute a variazioni di carico (tipo ad esempio eccentricità che causano accelerazioni e decelerazioni continue).

quindi ogni tot impulsi encoder si ha uno step del motore vite giusto?

si. il problema é che non hai sempre relazioni pari... per fare un determinato passo potresti aver bisogno di fare, ad esempio, 153 passi di motore sulla vite per ogni giro del mandrino.... quindi vuol dire che l'incremento del passo-vite avviene una volta ogni, ad esempio, 5 passi encoder e la volta successiva ogni 6..... oppure due incrementi ogni 5 passi e il terzo ogni 6..... chiaramente il calcolo é un delirio. poi si puó fare anche piú facile ma la precisione é quella che é; e su un filetto lungo l'errore si accumula.

questo si può risolvere non azzerando il contatore impulsi (mi pare che arduino uno abbia il pin 5 degli ingressi digitali che fa un conteggio hardware che non occupa cicli macchina e quindi suscettibile di ritardi) ad ogni passo della vite.

Vittorio il problema non é contare gli impulsi bensí gestire la routine che incrementa il passo della vite ogni tot passi del mandrino.... se gli incrementi sono sempre alla stessa "distanza" non é un problema (tipo, se ogni 4 passi del mandrino devo fare un passo vite é semplicissimo).... se invece il rapporto tra passi mandrino e passi vite non é intero: ad esempio, devo eseguire un passo vite ogni 4,5 passi mandrino, iniziano i problemi. con 4,5 é semplice, faccio alternativamente uno ogni 4 e uno ogni 5.... ma potrei ad esempio dover fare un passo vite ogni 4,18 passi mandrino..... e i conti si complicano. resta poi il fatto di come gestire la routine; se ricalcolo ad ogni ciclo rischio di rallentare troppo l'esecuzione; la pensata che stavo facendo era quella di utilizzare un array da 10 valori, che utilizzeró caricandovi all'interno i valori della sequenza che intendo utilizzare, eseguendo tutti i conti prima dell'avvio della macchina. con una sequenza a 10 riesco a coprire con buona precisione tutti i rapporti possibili.
Certo, se avessi avuto la vite in millimetri.....

max, tiriamo giu' uno schema a blocchi dell'algoritmo di gestione?

io ancora non ci sto pensando perchè mi manca roba per sperimentare....


potremmo iniziare a ragionare su quali sono i valori da rilevare, cosa ci serve sapere e magari creare alcune costanti impostabili da programma per rendere il tutto personalizzabile e non vincolato ad una determinata configurazione della macchina...

alla fin fine penso che l'unica vera variabile sia il passo della vite oltre ad eventuali demoltipliche su encoder o pp..

Non mi sono spiegato, adesso funziona con il timer e clock del processore ma l'intento finale e' usare come ingresso per il timer il segnale dell'encoder del mandrino e cosi' avrei un collegamento tra mandrino e motore con un rapporto gestito dall'interrup del timer e che posso aggiornare ad ogni interrup caricando il registro con il valore che mi serve.
Io per ora lo carico con quello che mi arriva dalla lettura analogica del potenziometro sommato all'eventuale accellerazione che prelevo secondo il caso dall'array che ho gia' preconfezionato (questa parte puo' rimanere per la tornitura in manuale).
Non avevo pensato all'array per i fatttori di correzione per i passi non divisibili...mmm ma non so come si potrebbe gestire,
La sostanza e' che io devo contabilizzare un impulso encoder in piu' solo quando la somma delle frazioni di impulso (non intere) "contenute in ogni singolo impulso encoder" (non ancora eseguite fisicamente) raggiungono o superano l'unita'.
Dopo di che, fatto il passo, sottraggo l'unita' dalla somma e ricomincio.

mandi Mecha

io sto preparando la routine di calcolo con EXCEL; di solito faccio così.
Le variabili sono:
1 - passi endcoder
2 - eventuale moltiplica encoder
3 - Passi stepper
4 - eventuale demoltiplica stepper
5 - passo della vite

Queste si impostano e si salvano nella EEPROM visto che non è necessario variarle di continuo.
Poi abbiamo due modalità operative: avanzamenti e filettatura.
Per gli avanzamenti non vedo grossi problemi visto che non abbiamo necessità di sincronizzare il mandrino.... oddio si può anche fare ma di certo non richiedono conti di precisione come per la filettatura.
Per la filettatura sto elaborando l'algoritmo e più ci penso più la soluzione dell'array con i valori pre-calcolati mi sembra la migliore. Devo solo fare i conti sulla velocità di elaborazione e sui tempi richiesti per la lettura dell'encoder; questo porrà il limite sulla massima velocità di lavorazione possibile.
Considerando ad esempio un encoder da 2000passi, abbiamo che a 500 giri al minuto dobbiamo essere in grado di leggere il passo encoder ed eseguire tutto il codice conseguente in 60 microsecondi, ovvero con un ciclo di 16,6Khz. E fino a qui problemi non ne vedo.

Poi, eventuali avanzamenti per lavorazioni a velocità più elevate si possono fare svincolando il mandrino e quindi senza bisogno di leggere l'encoder... potremmo ad esempio prevedere la possibilità di impostare un avanzamento in metri al minuto oppure dotando di un index aggiuntivo il mandrino in modo da leggere la sola velocità di rotazione; nel caso avremmo un solo impulso al giro e potremmo andare a velocità folli senza preoccuparci di nulla.

Per i calcoli si , un array va bene dato che, per un determinato passo reso disponibile dal programma, io mi calcolo prima tutto (cosa che a fatto anche il russo) e non ho capito in che modo ma ci ha anche aggiunto l'accellerazione necessaria in relazione all'avanzamento impostato.
Non capisco come gestire con l'array la parte frazionaria di un dato avanzamento.
Se si utilizzia l'encoder in quadratura in modalita' x2 abbiamo un segnale di clock e una direzione che possono essere gestiti dal timer piu' un bit di direzione.
Se lo si utilizza in x4 le cose sono piu' complicate ma raddoppio la risoluzione e non ho incertezze sul conteggio (presenti in modalita' x2 nell'inversione di direzione).

Mecha

io vi leggo capisco poco, devo andare a studiare e ripassare elettronica! vi seguo

Mecha la difficoltá, come giustamente dici, sta nella gestione di rapporti frazionari.
Ipotizzando di dover eseguire un passo di stepper ogni 3,1 passi di encoder come procedi?

devi eseguire 1 passo di stepper ogni 3 di encoder ma cosí stai facendo un rapporto 1:3; non a 3,1....
per eseguire il 3,1 bisognerá fare che, per ogni 10 passi di stepper, ne facciamo 9 ogni 3 passi di encoder e 1 ogni 4 passi. ecco il nostro rapporto 3,1 con una media su 10 valori!
Questi 10 valori si ripetono di continuo creando una sequenza.... questi sono i valori che caricherei nell 'array...

questro lo avevo immaginato..ma se lavoriamo ad esempio in pollici e sue frazioni non penso otterremo mai un intero anche suddividendo ľerrore su piú passi.
Per questo non so se sarebbe meglio trovare una strategia generale che possa risolvere tutte le casistiche.
Non ho ben capito come il russo ha gestito questo aspetto, avevi provato a dare un'occhiata ai suoi sorgenti?

Mecha

No i suoi sorgenti non li ho guardati; ma sangue dalle rape non ce lo cavi. Più passi hai e più aumenta la risoluzione; per rapporti frazionari bigona capire quale è la massima tolleranza accettabile su un filetto... con il mio file EXCEL sto cercando di capire proprio questo: ovvero qual'è il passo reale che sto facendo una volta attuati gli arrotondamenti obbligatori. Io ho vite da 8 filetti per pollice, quindi 3,175mm.... e mi va ancora bene che la conversione si ferma a 3 decimali

Ad esempio, ipotizzando la mia configurazione come segue:
Vite da 8 filetti per pollice (3,175mm)
Encoder da 1000passi in presa diretta
Stepper da 400 passi in presa diretta (motore standard da 200 passi con half step)
Volendo eseguire un passo 2mm vuol dire che lo stepper deve eseguire 252 passi ad ogni giro completo del mandrino (400/3,175)*2=251,96.

Essendo il mandrino da 1000 passi il rapporto è 1000/252=3,96825
Arrotondiamo a due decimali abbiamo un rapporto di 1:3,97. Ovvero, devo far fare 1 passo allo stepper ogni 3,97 passi del mandrino.
Utilizzando la mia approssimazione a 10 valori, devo arrotondare necessariamente 1:4.
Il passo reale che mi viene arrotondando 1:4 sarà di 1,984mm, ovvero 1,6 centesimi di errore sul passo voluto.

Ora la domanda è: è accettabile questa tolleranza o dobbiamo fare di meglio ?