Ciao a tutti .
Vorrei leggere un valore sinusoidale che varia da 1volt a -1 volt . Pensavo ad usare un convertitore analogico digitale ma non so bene quale scegliere.
Ho visto che molti costruttori usano convertitori a 20 bit, una risoluzione mostruosa a pensarci. Il programma sarà concettualmente molto semplice.
Controllo e mantenimento di una posizione memorizzata in una variabile e raggiungimento nuova posizione quando viene comunicata.
Per raggiungere la nuova posizione ci sarà un calcolo in più da fare che consiste nel risolvere un equazione di primo o secondo grado che non dovrebbe appesantire troppo il ciclo.
Il ciclo deve essere molto veloce e bisogna che si chiuda nel minor tempo possibile.
Obbligatoriamente in meno di mezzo millisecondo.
Dico subito che l'Arduno Due non va bene. a dispetto di quanto ci si possa aspettare è molto più lento del Leonardo.
Si accettano consigli su un eventuale altro processore, anche da programmare con avr stutio.
Se poi questo processore avesse fosse adatto alla comunicazione tramite fibra ottica sarebbe davvero perfetto.
Applica all'uscita del resolver un condensatore da 1μ e l'altro estremo di questo al centro di un partitore composto da due resistori da 10k con un estremo collegato ai 5V di Arduino e l'altro a ground.
In questo modo potrai misurare con un ingresso analogico di Arduino a 10bit il segnale 2Vpp con zero a 2.5V.
Riguardo al fatto che DUE sia più lento di Leonardo, ho i miei dubbi...
Per collegarlo alla DUE ovviamente devi usare sul partitore i 3.3V, quindi lo zero diventa 1.65V, ma in compenso hai una risoluzione a 12bit.
cyberhs:
Applica all'uscita del resolver un condensatore da 1μ e l'altro estremo di questo al centro di un partitore composto da due resistori da 10k con un estremo collegato ai 5V di arduino e l'altro a ground.
In questo modo potrai misurare con un ingresso analogico di Arduino a 10bit il segnale 2Vpp con zero a 2.5V.
Questo funziona solo se il segnale non é riferito a massa (terra) del Arduino ma é isolato.
Ciao Uwe
cyberhs:
Applica all'uscita del resolver un condensatore da 1μ e l'altro estremo di questo al centro di un partitore composto da due resistori da 10k con un estremo collegato ai 5V di arduino e l'altro a ground.
Sta usando un resolver e parla di tempo ciclo minore di 0.5 ms, non puoi mettere nessun condensatore sul segnale altrimenti te lo perdi per strada.
Tocca vedere il tipo di resolver, ovvero se l'out è AC oppure DC con offset, nel secondo caso c'è dell'elettronica in mezzo che provvede alla cosa dato che un resolver nudo e crudo esce solo AC.
cyberhs:
In questo caso non resta che usare un operazionale, anzi due visto che le uscite dal resolver sono due.
Sopratutto serve un ADC molto veloce con almeno 12 bit reali di risoluzione altrimenti il resolver non lo gestisci, di sicuro l'ADC standard di Arduino non va bene.
Più in generale non va bene Arduino per gestire un BLDC con resolver, ci vuole come minimo un dsPIC serie MC o ic dedicati a questo tipo di controllo.
Scusate seu non l'ho specifcato, il segnale da 1vpp va da -1 a +1, quindi si, passa per lo zero.
I due segnali sono sfasati di 90 gradi e sono sinusoidali. Siamo all'incirca sui 50 000 cicli al secondo come velocità massima. Il fabbricante dice 150 000, a me bastano 50 000.
In questo caso specifico bastano 18 000 cicli, forse anche qualcosa in meno.
Ho pensato anche di usare un ADC per schede audio; il segnale audio infatti può essere 1vpp, 1.5vpp o 2vpp a seconda dei casi.
Una cosa molto importante da considerare è che se il resolver gira molto veloce non è necessario avere un interpolazione moltoalta del valore delle sinusoidi.
Se la frequenza è alta significa che si sta facendo uno spostamento rapido. Sara quindi suff. contare le oscillazioni. In questo modo a fine movimento non conosco la posizione reale ma so che è compresa tra un valore massimo ed uno minimo. sarà poi l'ADC a leggere il voltaggio esatto e quindi decidere la posizione vera.
Durante il moto di lavoro invece è necessaria una elevata sincronia tra i vari motori, quindi l'ADC dovrà leggere il valore costantemente. Posso dire che difficlmente si va oltre i 10 000 cicli in fase di lavoro e comunque la massima precisione è richiesta solo al di sotto dei 5000.
Faccio un esempio pratico per maggior chiarezza:
Abbiamo un calibro tradizionale, con la lancetta. Se sposto velocemente il cursore conto i giri della lancetta mentre quando lo sposto lentamente leggo i centesimi che la stessa lancetta mi indica.
Posso conosce la posizione anche senza leggere ogni singolo centesimo, l'importante è che si contino i giri della lancetta e solo alla fine leggere il valore preciso.
Quindi astrobeed dici che arduino è da escludere. Lo immaginavo, quindi quale sarebbe la scelta migliore?
Preferirei un Atmel perchè mi trovo bene con Avr Studio. però se è proprio indispensabile va bene anche un pic.
Di ic dedicati non ne ho trovati se non per pilotare motori da floppy, hard disk o simili.
Fanno tutti riferimento a dei sensori hall per sincronizzare le fasi oppure utilizzano direttamente un feedback dalle fasi stesse.
Nessuno riceve in ingresso nativamente un resolver.
Ovviamente non ho trovato neanche un ic specifico per la lettura dei resolver, altrimenti mezzo discorso sarebe già concluso.
Per cyberhs: Non dico che il Leonardo sia più potente del Due, però è più veloce a chiudere il ciclo.
Se li hai entrambi prova tu stesso a fare un programma che salvi una lettura di micros() in una variabile e al ciclo successivo stampi tramite seriale la differenza tra una nuova lettura di micros() e il valore salvato nel ciclo precedente. vedrai che il Due impiega almeno venti volte il tempo che impiega il Leonardo.
Se vogliamo calcolare il pigreco però è un altro paio di maniche.
Il MC ATMEGA328 è perfettamente in grado di muovere un BLDC in posizione, vedi questa CNC_ULTIMATE V2: CNC2 ...........legge un encoder incrementale fino a 160.000 fronti in quadratura e in qualsiasi condizione almeno fino a 50.000 impulsi di step/sec per il comando di posizione, usa un ATMEGA8 programmato in assembler che comunica mediante porta asincrona con un altro MC programmato in C per pilotare LCD e tastierino, l'assembler è necessario per ottenere le massime prestazioni da un MC così piccolo.
In questo progetto se avessi voluto collegare un resolver al posto dell'encoder avrei usato la strada più breve anche se un pò più costosa, cioè usare un chip di interfaccia esterno tipo AD2S1200 di analog devices oppure AU6802N1 di tamagawa, esistono anche altri chip che convertono da resolver ad encoder ma in questo momento non li trovo. Non li ho mai usati però siccome il resolver è più costoso di un encoder incrementale , nel mio range di schede sono sprecati.
Se invece tu intendi usare un'altro tipo di resolver , molto più economico che serve per pilotare il motore BLDC solo in velocità e NON in posizione (come ad esempio nel FLOPPY DISK DRIVE) allora cancella tutto, il resolver si trova sempre già integrato nel motore e la sua lettura non desta particolare cura, si può fare tutto in C, in queste applicazioni comunque si preferisce usare la terna di sensori HALL, oppure in extremis il pilotaggio sensorless senza nessun sensore come negli ESC dei giocattoli radiocomendati.
Ho scritto questa carellata di applicazione anche a beneficio di altri non solo del tuo
Ti ringrazio, dal sito vedo che facciamo quasi lo stesso lavoro. Per quanto riguarda l'encoder incrementale, ho già fatto molte schede usando per comodità l'Arduino Pro Mini, che si presta bene ad essere saldato sul circuito come se fosse un componente.
Si trattava di motori elettrici in corrente continua, abbastanza piccoli, con encoder da 2000 impulsi giro. Encoder dell'Avago se non ricordo male.
Questa applicazione è su un altro livello di precisione. Questi resolver sono montati sui motori brushless d'alta gamma per le macchine utensili o l'automazione in generale.
Un encoder incrementale equivalente sarebbe improponibile, stiamo parlando di 20 bit, quindi 1048576 combinazioni. Non esistono encoder da oltre un milione di impulsigiro. O almeno non sono stato capace di trovarne uno. Quello che per comodità chiamo resolver, potrebbe benissimo essere una riga ottica lineare. In entrambi i casi il segnale d'uscita e la frequenza massima sono le stesse. Quindi ai fini della lettura non cambia niente.
C'è una differenza nella risoluzione necessaria in bit però. Mentre il resolver emette un segnale sinusoidale il cui perido corrisponde ad una rotazione in una riga ottica il periodo corrisponde ad un avanzamento di (esempio) 2 centesimi di millimetro.
Mentre nel primo caso è necessario un ADC con una risoluzione molto alta per avere della precisione, nel secondo caso è suff. un ADC più modesto.
Resolver: un giro corrisponde a 20bit - 1048576 divisioni/giro (più che buona)
riga ottica sin. 2cent : con un ADC da 8 bit dividiamo 2 centesimi in 256 parti. ( ben oltre necessità).
Esiste anche un tipo di encoder, che io chiamo impropriamente sinusoidale, che divide il giro in più periodi. Ne consegue che aumentando le divisioni diminuisce la risoluzione in bit dell ADC per avere la stessa risoluzione del resolver prima nominato.
Anch'io ho adottato il PRO-MINI per lo stesso motivo, l'UNO e il MEGA2560 per popolarità e il DUE perchè a 32 bits, ovviamente tutti compatibili altrimenti sarebbero stati improponibili come prezzo, prima avevo disegnato delle schede dove alcune si possone vedere alla voce CUSTOM3 / PROTOTYPE ,avevo 3 schedine , una dove montavo il ATMEGA8-328 , una dove montavo il ATMEGA8U2-16U2 e una dove montavo il AT90CAN32-128, erano semplici, le prime 2 avevano 32 pin connessi ai 32 pin del micro con il xtal-reset-rs232-ISP e un led , la seconda una cinquantina di pin con xtal-reset-rs232-ISP-il led e il driver CAN, la prima la ho sostituita con la pro-mini ......praticamente identica, la terza la puoi vedere montata su CUSTOM4 / Terminale CAN-BUS
Ritornando al tuo problema come saprai nell'ultimo decennio si usa una coppia MC-CPLD ad esempio una XILINX XC9572XL o una ALTERA MAXII, come MC uno da 16bit tipo MSP430F133 o un 32bit oppure va bene anche un atmega328 , come interfaccia resolver vedi la disponibilità dei chip che ti ho indicato sopra, o cercane di altri, ci sono, ci sono, nei primi anni 90 le ditte come okuma, fanuc, mitsubishi etc dovevano per forza progettarli da zero mediante operazionali e ADC , non era certo un problema per loro ma oggi si trovano già pronti, se proprio vuoi progettarli con componenti discreti come allora, ..."allora" dovresti procurarti uno dei primi azionamenti , ad esempio okuma tipo VACI o VACII e fare il reverse engineering dell' interfaccia resolver