Ecco anche la mia cnc

[MarcoMi]

Complimenti!

Dove hai trovato i motori? Anche io vorrei fare prove in tale senso, ma non trovo motori sufficientemente potenti...

Ho avuto la fortuna di poter smontare 2 plotter, quindi 6 motori che vedi in foto, e guide a ricircolo come nuove.

Alcune domande specifiche: il pic deve leggere sia l'encoder del motore che gli impulsi di comando (clock e direzione). So che la serie 18 ha in alcuni modelli il contatore encoder integrato, ma devi sempre contare gli impulsi di riferimento via software giusto?
Tu come hai fatto a contare gli impulsi di riferimento e gli impulsi encoder? Fino a che frequenza riesce ad arrivare il tuo sistema (motore a parte)?

Ciao e ancora complimenti!

Ho usato il pic18f2431 con lettura encoder hardware 16bit, contatore software a 32 bit per la posizione reale data dalla lettura encoder e contatore software a 32 bit da ingresso STEP(+/- DIR).Il P.I.D. si preoccupa di portare il motore in posizione corretta.Comunque nell'applicationNote di microchip c'è qualche esempio se non ricordo male.Da leggere il datasheet del pic anche.L'hw che gestisce l'encoder
arriva fino a 625khz in quadratura.Il PID ogni 300microsec controlla la posizione, impiega 80 microsec circa, idle per 220, quindi mi tengo a 1600 mm/min max (0.01 mm), circa 2,6 khz, ma può andare oltre cambiando i tempi e il conteggio dell'encoder, per il tipo di fresa che ho costruito è più che sufficiente. Vedremo quando farò delle prove reali con vari materiali.

Grazie e Ciao.

[Bit79]

Quindi conteggio encoder con hardware integrato nel pic e conteggio step via software, suppongo in interrupt, giusto? Quale interrupt usi?

[MarcoMi]

Quindi conteggio encoder con hardware integrato nel pic e conteggio step via software, suppongo in interrupt, giusto? Quale interrupt usi?

Tutto in interrupt, Timer0 per il pid e Int1 per step (ccs c).

Saludos.

[Bit79]

Io ho fatto alcune prove con un pic 16f876 a 20 Mhz, conteggio encoder software in interrupt su portab, conteggio step software in interrupt pin int, pid ogni 2 us (scanditi da timer1).
Piloto un motore cc con clock fino a 60 khz (15 khz encoder x4).
Vorrei realizzare qualcosa di più veloce, pensavo appunto ad un pic serie 18.

Relegando al software solo il conteggio degli step, tra l'altro più semplice rispetto al conteggio encoder, e utilizzando clock fino a 40 Mhz dovrebbe migliorare di molo in prestazioni...

[MarcoMi]

20 mhz PIC16

per fare una somma int32 3 us
* int32 132 us
/ int32 239.2 us


40 mhz PIC18

per fare una somma int32 0.6 us
* int32 22 us
/ int32 106 us

Il pic18 è tutta un'altra cosa.

Per PID intendo questo + o -:

Error_now = Set_point - EncPos
P = Kp * Error_now
I = I + Ki * Error_now
D = Kd * (Error_now - Error_last)
Error_last = Error_now
PID = P + I + D

più controlli vari.

come fai a calcolare il tutto in meno di 2 us.
Eppoi cosa devi fare per andare così veloce ?

Ciao.

[Bit79]

Il pic18 è tutta un'altra cosa.

Naturalmente, infatti volevo passare a questi.

Per PID intendo questo + o -:

Error_now = Set_point - EncPos
P = Kp * Error_now
I = I + Ki * Error_now
D = Kd * (Error_now - Error_last)
Error_last = Error_now
PID = P + I + D

più controlli vari.

come fai a calcolare il tutto in meno di 2 us.

L'algoritmo mi torna, trascurando le somme e le differenze sono in tutto 3 moltiplicazioni da fare.
A 32 bit mi sembra eccessivo, un errore così grande non dovresti averlo mai (si verificherebbe sicuramente un allarme prima) e le costanti kp ki e kd non credo serva esprimerle a 32 bit, possono bastare a 16 o anche a 8.
La moltiplicazione a 16 bit impiega molto meno e in 2 us ne puoi fare diverse. Non vi è molto margine, ma in 2 us l'algoritmo ci sta comodo.

Quello che spreme il pic sono i cicli di conteggio per l'encoder e gli step in interrupt. Sono riuscito a arrivare a 60 Khz. Sembra tanto, ma con un motore da 3000 rpm e un encoder da 256 impulsi/giro (x4) si ha una frequenza di funzionamento di 51200 hz, un po' al limite. Dipende da che controllo si deve fare. Per una cnc potrebbe anche bastare, per altre applicazioni forse no.

Comunque sono contento della discussione, verrà  fuori qualcosa di buono!

Ancora ottimo lavoro!
Ciao!

[MarcoMi]

Ciao,
I 32 bit li uso solo per la posizione, uso 16 bit e 8 bit per il resto ...

40 mhz PIC18

tempo moltiplicazione 16 bit 3.2 us (ccs compiler)

Usando il C e riducendo all'osso la routine del PID (senza controlli e debug seriale) ottengo 16 us circa.
Tu usi l'assembler quindi ? Io uso solo il C ed è il secondo progetto che faccio (per hobby), l'assembler mi rende nervoso.
Comunque usando la serie 18 non dovresti avere problemi di velocità . 625 khz in quadratura bastano e avanzano.
Con il motore che ho io da 3500rpm 1000cpr X4 sono 233 khz circa. In pratica a me bastano 800 rpm.
Con 300 us di campionamento impulsi ottengo circa 78 come valore max di spostamento ed errore(3500 rpm), con la mia meccanica sono
0.04 mm (0.01 a 800 rpm circa), ma potrei scendere a 150 us. Ma per la mia fresa hobbistica è eccessivo, sarei soddisfatto di ottenere un decimo
di precisione (0.1 mm) calcolando errore meccanico ed errore software.Troppi numeri ho il mal di testa.Per fortuna adesso inizia DR. House.
Speriamo di non avere fatto errori nei calcoli, ma se trovo il tempo controllo con l'oscilloscopio per bene.

Grazie e Saludos.

[Bit79]

Si, uso solo assembler. Voglio avere il pieno controllo di quello che faccio. Spesso capita di riprendere in mano subroutine già  fatte e di trovare il modo di velocizzarle o semplificarle, magari adattandole allo scopo. Subroutine generiche come quelle che crea un compilatore potrebbero non essere ottimizzate al 100 %.

Comunque ho ordinato un po' di Pic18, aspetto che arrivino!

Ciao!

[Bit79]

Sto continuando alcune prove con il PIC16F876. Sono arrivati anche i 18F, ma non ho tempo di studiarli con calma.

Vorrei usarli per una cnc e stavo visto che l'algoritmo pid funziona egregiamente stavo raffinando il programma e volevo introdurre anche la gestione di tutti gli allarmi utili:
-errore di posizione
-massima velocità 
-saturazione integrale
-alimentazione encoder ok

Vorrei anche introdurre un allame di mancanza encoder, che è il caso praticamente più pericoloso, perchè in tal caso la scheda perde il controllo del motore, ma ho dubbi su come farlo nella migliore maniera.
Il problema è se si ha un guasto su un encoder quando un motore è fermo. Infatti se un encoder viene a mancare mentre il motore gira si avrà  quasi immediatamente un allarme di errore di posizione; infatti il conteggio di posizione effettiva si blocca, mentre gli impulsi di riferimento continuano e mandano fuori range l'errore di posizione.
A motore fermo invece non si hanno impulsi di riferimento, quindi la posizione di riferimento resta la solita. Mancando la reazione dell'encoder, anche un piccolo errore di posizione porterebbe l'asse ad avanzare lentamente, seguendo l'errore che si aveva al momento del guasto all'encoder. Ho fatto la prova e succede proprio così.

Non so però come rilevare una tale situazione.
Qualche idea? Tu come hai fatto?

[MarcoMi]

Sto continuando alcune prove con il PIC16F876. Sono arrivati anche i 18F, ma non ho tempo di studiarli con calma.

Vorrei usarli per una cnc e stavo visto che l'algoritmo pid funziona egregiamente stavo raffinando il programma e volevo introdurre anche la gestione di tutti gli allarmi utili:
-errore di posizione
-massima velocità 
-saturazione integrale
-alimentazione encoder ok

Vorrei anche introdurre un allame di mancanza encoder, che è il caso praticamente più pericoloso, perchè in tal caso la scheda perde il controllo del motore, ma ho dubbi su come farlo nella migliore maniera.
Il problema è se si ha un guasto su un encoder quando un motore è fermo. Infatti se un encoder viene a mancare mentre il motore gira si avrà  quasi immediatamente un allarme di errore di posizione; infatti il conteggio di posizione effettiva si blocca, mentre gli impulsi di riferimento continuano e mandano fuori range l'errore di posizione.
A motore fermo invece non si hanno impulsi di riferimento, quindi la posizione di riferimento resta la solita. Mancando la reazione dell'encoder, anche un piccolo errore di posizione porterebbe l'asse ad avanzare lentamente, seguendo l'errore che si aveva al momento del guasto all'encoder. Ho fatto la prova e succede proprio così.

Non so però come rilevare una tale situazione.
Qualche idea? Tu come hai fatto?

I controlli su errore posizione, velocità  max(pwm) e saturazione PID li faccio, ma il caso dell'encoder che si guasta da fermo non l'ho considerato ... devo verificare, anche da fermo, comunque, c'è sempre attività , infatti si sente un debole ronzio nel motore, con 4000 cpr il pid è sempre al lavoro, staccando l'encoder a caldo, quel piccolo errore incrementa poichè il pid non riesce, tramite il movimento del motore, a correggerlo, siccome io accumulo l'errore non azzerandolo mai in pochi cicli della routine PID sforo di sicuro la soglia di errore max, tenendo conto della riduzione meccanica, pulegge e chiocciola-vite, la meccanica non farà  molta strada, comunque devo verificare in pratica. Sto ultimando anche il mandrino, quindi farò delle prove sull' alluminio, vedremo come si comporterà  il tutto.

Saludos.

[Dino]

I controlli su errore posizione, velocità  max(pwm) e saturazione PID li faccio, ma il caso dell'encoder che si guasta da fermo non l'ho considerato ... devo verificare, anche da fermo, comunque, c'è sempre attività , infatti si sente un debole ronzio nel motore, con 4000 cpr il pid è sempre al lavoro...

Sinceramente non mi sembra quello della rottura dell' encoder a motore fermo un vero problema, secondo me neanche vale la pena prenderlo in considerazione, tanto il software se ne accorge non appena tenta un movimento dell' asse.

Dino

[Fui]

Sinceramente non mi sembra quello della rottura dell' encoder a motore fermo un vero problema, secondo me neanche vale la pena prenderlo in considerazione, tanto il software se ne accorge non appena tenta un movimento dell' asse.

Dino

Il fatto è che quello che per il software è un motore fermo con l'encoder è rotto può benissimo NON ESSERE UN MOTORE FERMO... Il motore CC non sta "in equilibrio" in un preciso posto come uno stepper... è molto probabile che se l'encoder si rompe a motore fermo cominci ad andare a spasso... Non sono un esperto magari ho detto solo cagate. Ma perchè si dovrebbe rompere da fermo un encoder?

[Bit79]

Purtroppo è proprio come dice Fui. Provare per credere.
A motore fermo, cioè senza che arrivino impulsi di clock e direzione, il pid lavora comunque per mantenere fermo il motore, e può darsi benissimo che debba erogare una piccola coppia per contrastare eventuali spostamenti o semplici offset dell'elettronica.
Se viene a mancare l'encoder in un momento in cui l'errore di posizione è diverso da zero, anche se nei limiti impostati, tale errore non può più cambiare (non si hanno più ne impulsi encoder ne impulsi di riferimento, poichè il motore è richiesto fermo) e, pur restando nei limiti (quindi l'allarme di massimo errore non interverrà  mai), continuerà  a sollecitare il regolatore PID, portandolo a correggere una posizione che non rileverà  mai.
E' quindi possibile che il motore cominci a muoversi lentamente spsotandosi dalla posizione e provocando gravi danni. L'unico allarme che potrebbe rilevare il problema è una saturazione del regolatore integrale, ma probabilmente, in caso di errori piccoli, ci mette un po' di tempo a saturare e i danni potrebbero essere già  fatti.
Inoltre, anche se il regolatore restasse perfettamente in equilibrio e non correggesse per nulla, l'asse potrebbe muoversi per vibrazioni o altre cause e ciò non verrebbe rilevato. Pensate all'asse Z di una fresatrice mentre sta facendu una grossa spianantura, che rimasto senza encoder, comincia a scendere piano piano per via del suo peso....

Il problema resta...