MECCANICA e DINTORNI

Sempre all'estero e con Paypal.... che pall !
Mi sa che per 47,58 prendo il mega in Italia...

Ciao raga, proprio in queste feste mi sono messo a spatacare con arduino, motori passo passo e sensori più per il controllo di valvole motorizzate che per automatizzare il tornio.
Ho preso un paio di driver (un tb6560 ed un tb6600 come quello di Luk).
Per far superare ai mot pp i punti critici di risonanza e salire coi giri occorre bloccare molto bene il motore alle strutture e montare sull'albero delle masse aggiuntive oltre alla puleggia (se usate un treno di riduzione) oltre naturalmente ad una rampa di accelerazione e decelerazione software.
Per ora il mio progetto legato al tornio prevede solo l'avanzamento automatico long (che già avevo, regolato da un potenziometro ed un piccolo oscillatore per pilotare un driver da 2A)
Mi piacerebbe usare arduino sul tornio per tenere costante l'avanzamento all'aumentare o al diminuire dei giri mandrino(ora utilizzo i valori ricavati da un grafico che mi sono appeso sopra il tornio), quindi è necessario un sensore che dica quanti giri faccia il pezzo per poi adeguare la velocità dell'avanzamento.
Io per filettare sfrutto il motore del tornio trifase (comandato da inverter) munito di freno elettromeccanico controllato da un interruttore di finecorsa che mi permette di filettare in sicurezza a 800giri con una gola di scarico da 2mm (testato anche su fori cechi).
Vi seguo con interesse.

zorki - per favore condividi un video?! Grazie.

purtroppo non utilizzo più youtube perché insistono a volere il mio numero di telefono mobile, già mi rompono i maroni quelli che cercano di venderti qualcosa a mezzogiorno, non vorrei che cominciassero anche sul cellulare...
Se ci fossero altri sistemi di condivisione video lo carico subito.

tu dagli il numero di Bvalk come ho fatto io

Ragazzi, secondo me se bon decidiamo che encoder comprare la cosa non si muove da qui...

Ho preso un encoder assoluto da 600 p/g perché costava nulla ma non credo sia quello che serve

Nessuno ha trovato altro più vicino??

Se non esce proprio nulla ordino quello indicato da mimmoletti e ci si risente fra un mese

Cmq scherzi a parte, penso che prenderò nel frattempo un encoder qualsiasi per iniziare a capire come interfacciarlo.. ;)

Saggia soluzione. Attendo aggiornamenti sul proto e la campagna R&D.

per gli encoder la cosa è più problematica di quanto sembra. quell'encoder cinese, da quanto leggo, ha come uscite due onde quadre, utile per definire il verso di rotazione del sistema. ci possono essere però dei problemi che fanno perdere un passo, o a volte addirittura può succedere che sbagli il verso di rotazione (come succede con i mouse per dire). quindi per evitare errori servirebbe un encoder assoluto, possibilmente con codifica gray, che sono anche i più diffusi. purtroppo occupano molto più che due pin della scheda. diciamo che gli encoder sono oggetti piuttosto costosi perchè non semplicissimi.

è per questo che volevo stabilire il senso di rotazione del mandrino in maniera indiretta e senza ulteriori complicazioni...

dando per scontato che il tornio sia comandato da un inverter, e comandando l'inverter da un banale pin dell'arduino, sara' lui a determinare il verso di rotazione e non dedurlo dalla decodifica dei segnali dell'encoder..

Sulla scelta dell'encoder, secondo me, dipende da come verrà gestito dal firmware.

Ho sempre pensato che il miglior metodo fosse l'utilizzo dei timers, poi ho dato un'occhiata veloce al progetto dell'amico tedesco (il link che ho postato sopra) e mi pare di aver capito che lui ha usato il metodo con un interrupt ad ogni cambio di stato. Pensavo che una soluzione del genere mandasse in palla tutto al superamento di una certa velocità. Mi sembra inoltre che lui ha usato un'encoder da 100 ppr che potrebbe essere la scelta ottimale per non rimanere inlooppati negli interrupt.

Mentre se si usa il metodo dei timers/interrupt dovrebbe essere meglio un encoder con risoluzione alta. Io ne ho uno da 360 ppr e proverò con quello.

Questo è un 400 ppr, costa il doppio che prenderlo in cina ma dovrebbe arrivare presto, anche se non sono sicuro che sia la scelta giusta, devo prima fare delle prove alle varie velocità con il mio.

http://www.ebay.it/itm/High-resolution-optical-rotary-encoder-for-DDS-module-VFO-etc-400-pulses-rev-/251773851997?pt=LH_DefaultDomain_3&hash=item3a9ee4195d

ecco ragazzi, è per questo che sto cercando di capire cosa ci serve realmente

si sta passando da 100 impulsi a giro a 2000 con sponda sui 400 600 800 ecc ecc ecc

ma ancora non capisco che precisione pensate sia quella ottimale


mi viene da pensare che volendo fare il passo + lungo 4 mm, per comodita' di calcolo


avendo un encoder da 400 impulsi giro, si ha che ogni impulso equivale a 1 centesimo di di movimento lineare del carro e 0.9° di rotazione del mandrino

con un encoder da 2000 impulsi si ha che ogni impulso sono 2 millesimi di mm e 0.18°

a intuito non capisco a cosa serva una precisione così elevata su macchine che di soli giochi e back slash parlano in decimi, gia' 400 impulsi giro mi sembrano + che sufficienti

pero' ribadisco che senza sperimentare le mie sono solo sensazioni...

inoltre non ho manco capito se ci serve un encoder incrementale o assoluto

sempre a naso penso che sia molto + importante sapere l'esatta posizione angolare del mandrino quindi dovrebbe essere un encoder assoluto il nostro targhet, vero che anche con i relativi è possibile, ma non in maniera diretta ma leggendo gli impulsi con 0 sull'home...

insomma, definiamo esattamente la minima precisione richiesta e il tipo di encoder, poi cerchiamo quello che fa al caso nostro ;)

io pensavo che di encoder ne fossero necessari 2, uno per la vite e uno per il mandrino. secondo me serve assoluto in ogni caso, giusto perchè non perde colpi. ma è vero che sono molto cari e occupano parecchi pin. ma i vantaggi sono indiscutibili e aumentano con il salire della velocità e con il diminuire del numero di impulsi dell'encoder, visto che un conto è sbagliare di 0.18° e un conto è sbagliare di 1.8°.

per quanto riguarda la precisione, è vero che le macchine hanno tanti giochi, ma filettando si lavora sempre in appoggio, i giochi danno più che altro problemi di ripetibilità, che comunque sono trascurabili. discorso diverso se fresiamo.

per la movimentazione della vite leggo che verrà usato il microstepping. mi hanno detto (sono ignorante in materia), che benchè si usi il microstepping l'incertezza di posizionamento non si riduce notevolmente rispetto all'utilizzo senza microstepping. se qualcuno ha qualche esperienza mi corregga.
quindi secondo me non conviene andare con numero di impulsi elevatissimi. direi che 800 impulsi vanno benissimo, ma secondo me pure 400 vanno bene. se qualcuno conosce qualche valore di tolleranza delle filettature possiamo stimare il numero di impulsi con maggior correttezza

@Zorki:

Vimeo, che tu sappia, com'è per caricare/condividere video?

Mauro

la miglior soluzione per l'encoder è quello con interfaccia in quadratura, ovvero le due onde quadre di cui sopra che permettono di determinare il senso di rotazione. Il miglior modo per leggerli è quello di usare gli ingresso del micro dedicati quando sono presenti: alcuni micro hanno già dei moduli chiamati QEI (Quadrature Encoder Interface) che accettano i due ingressi dell'encoder direttamente: restituiscono al firmware il conteggio dei passi e impostano un flag binario che determina il verso di rotazione; il tutto senza impegnare l'esecuzione del programma principale. Non ho ancora avuto modo di verificare se ARDUINO dispone di questi ingressi ma questo week end me lo studierò senz'altro.

Anche a me ha stupito quando Massimo (Mimoletti) ha detto di aver usato un encoder da 2000p/giro; po ci ho pensato ed in effetti con una risoluzione del genere i calcoli ti si semplificano notevolmente, non fosse altro per il fatto che i passi che lo stepper deve fare sono sempre MENO di quelli che fa l'encoder; in questo modo il firmware dovrà sempre aspettare almeno un passo dell'encoder prima di dare il passo allo stepper. Ma se noi avessimo un encoder con meno passi dello stepper dovremmo prevedere ad esempio 4 passi di stepper per ogni passo di encoder, e questo per forza di cose inserisce un ritardo e un'imprecisione. E' chiaro che non è impossibile; si fa... ma avendo un encoder con parecchi più passi rispetto allo stepper i calcoli del firmware sarebbero molto più semplici.

con l'incrementale però se c'è un problema si fanno errori anche grossi. con l'assoluto ci sono sempre delle onde quadre, ma in numero sufficiente da poter identificare in modo univoco la posizione angolare. si trovano anche a oltre 12 bit.

non so se ci siano gli ingressi di cui parla max, però si trovano parecchie librerie. a quanto pare ci sono problemi nell'usare la solita sintassi di arduino per la lettura degli impulsi, ma si preferisce far ricorso direttamente ai registri, molto ma molto più veloce. la sintassi è simile a quella usata con i pic.