Controllo "asse In Fuga"

[emanuele.croci]

Ciao a tutti,

Ultimamente mi diletto a rimpiazzare azionamenti brushless+scheda asse con inverter+encoder+controllo asse fatto da me nel PLC.

(i risultati per ora sono promettenti...)

Ovviamente mi devo creare un set personalizzato di funzioni di controllo per rimpiazzare quelle che erano prima presenti nella scheda asse.

Stavo inserendo nel mio set di funzioni di controllo anche quella di "asse in fuga": praticamente voglio monitorare il funzionamento dell'encoder e dare un errore se, ad esempio, si è rotto l'encoder o il suo cavo.

Ho a disposizione:

- analogica "retroazione di velocità" dall'inverter (fatta in anello aperto, trasmessa con bus di campo)

- conta-impulsi dell'encoder incrementale.

La mia tecnica è molto semplice:

- definisco un tempo di campionamento, ad es. 0.1 secondi

- integro durante questo tempo il segnale di velocità per avere lo spazio percorso

- confronto lo spazio percorso con la variazione del segnale encoder

- mi fermo se c'è in percentuale una grossa differenza tra i 2

Che ne dite? qualcuno ha già affrontato lo stesso problema in modo diverso o con altri algoritmi?

accorgimenti particolari? consigli?

Grazie e Ciao,

Emanuele

Modificato: 22 novembre 2004 da emanuele.croci

[andrea.fa]

Se hai implementato un controllo di posizione penso che da qualche parte già dovresti avere una variabile per l'errore di inseguimento (e se non l'hai ci vuole poco a ricavarla...) e comparandola con il valore di massimo_errore_inseguimento saresti già a posto. Poi puoi aumentare la sicurezza testando lo "stato" delle linee dell'encoder, se il tuo hardware lo permette, per accorgerti immediatamente della mancanza di collegamento plc-esncoder.

Andrea

[walterword]

il controllo encoder lo avevo fatto cosi :

ogni tot tempo , per esempio 100 ms , faccio la copia del valore encoder in una variabile .

Ai prossimi 100 ms , se il valore encoder e' uguale al valore della variabile precedentecmente memorizzata , ho i flags di marcia , ho i valroi di riferimento velocità sufficienti al movimento allora vuol dire che mi sto muovendo ma non sto contando ;i motivi potrebbero essere anche l arottura encoder o fili dell'encoder ect .

Certo e' una cosa grezza , ma per le mie necessita piu che sufficiente .

Poi al limite si puo semrpe perfezionare

ciao

walter

Modificato: 22 novembre 2004 da walterword

[Livio Orsini]

A parte la verifica Hw del cavo di connessione e dell'encoder l'unico metodo che coniughi affidabilità e sicurezza di funzionamento con praticità e semplicità d'uso è il limite sull'errore di inseguimento. Si si vuol rendere maggiormente affidabile il sistema si pone in AND valore limite con tempo limite. In altri termini se, per esempio, ho impostato l'errore massimo <= 150 impulsi ed il tempo di soglia <= 100ms avrò l'allarme di servo guasto quando l'errore permane maggiore di 150 impulsi per più di 100 ms.

[emanuele.croci]

Grazie per i vostri consigli,

In effetti la mia tecnica è simile a quella di Walter.

La verifica hardware sul cavo di connessione non credo di poterla fare (uso gli ingressi veloci a bordo della CPU S7-300, quindi roba abbastanza economica).

L'errore di inseguimento ...per il momento non l'ho implementato: in effetti per ora non chiudo l'anello di posizione, l'unico mio controllo in posizione riguarda la rampa di frenatura.

Dopo aver visto tanti brushless che danno una botta mostruosa per recuperare l'errore di inseguimento, ho deciso così... (stiamo parlando di un'applicazione con N assi singoli, senza interpolazioni o alberi elettrici)

Ciao e Grazie,

Emanuele

[Livio Orsini]

L'errore di inseguimento ...per il momento non l'ho implementato..

Stai dicendo che ti limiti a dare una rampa di accelerazione e, raggiunta una certa quota, deceleri e fai l'ultimo tratto in lento? Se è così verifica almeno che il tuo asse sia vivo, cioè che tra un campionamento e l'altro della quota l'asse abbia percorsco una distanza diversa da zero.

[beppeconti]

Avevo fatto anch'io una cosa simile a quella fatta da Walterword. Campionavo la differenza sul valore letto dell'encoder esterno in un certo tempo e se la differenza era minore di una soglia e avevo il segnale di asse in movimento allora segnalavo l'allarme. Questa soluzione molto semplice mi permetteva naturalmente di rilevare solo la rottura cavo o encoder e non la fuga del motore che nel mio caso non era necessaria.

CIAO

[emanuele.croci]

verifica almeno che il tuo asse sia vivo

...è una buona idea; secondo me questo controllo ce l'ho già: passo un riferimento di velocità a un inverter vettoriale e immagino che in presenza di un DELTA V importante l'inverter stesso mi generi un errore.

Quindi mi fermo sull'errore generato dall'inverter.

Può stare?

Ciao, Emanuele

Modificato: 24 novembre 2004 da emanuele.croci

[Livio Orsini]

Dovrebbe funzionare solo in un senso. Cioè se dai il riferimento ed il motore non gira. Però se l'encoder non da impulsi a livello posizionatore sei sempre fermo e non lo sai, a meno di fare anche un confronto sulle quote progressive.

[emanuele.croci]

Però se l'encoder non da impulsi a livello posizionatore sei sempre fermo e non lo sai, a meno di fare anche un confronto sulle quote progressive.

scusa... non ho capito cosa vuoi dire....

Ciao, Emanuele

[Livio Orsini]

Probabilmente sono stato troppo telegrafico.

Se l'inverter è reazionato non ci sono problemi: se c'è differenza tra riferimento e reazione da segnalazione di guasto.

Se, come presumo, l'inverter è senza reazione la segnalazione di guasto è più grossolana. Inoltre se hai una rotture dell'encoder o del cavo alla scheda di conteggio non arrivano impulsi ed il tuo asse, a livello controllo posizione, risulta essere fermo.

Il controllo "asse vivo" si basa sul fatto che, con asse in movimento, due letture consecutive della scheda di conteggio, a distanza di tempo, devono dare due valori diversi. Se i valori coincidono l'asse è guasto.

Ovviamente l'ontervallo di lettura deve essere tale che, in funzione della velocità e della risoluzione (impulsi), la differenza sia almeno un impulso. Si può anche complicare il controllo introducendo un criterio di proporzionalità tra velocità di riferimento e differenziale di lettura.

In pratica Walter fa il controllo semplice di asse vivo. E' grossolano ma sicuro. Se prendi come intervallo di tempo 100ms può essere un buon compromesso tra rapidità di intervento e sicurezza del controllo.

Fidarsi solo dell'inverter per l'allarme di asse vivo non è, secondo me, molto affidabile. D'altro canto implementare un sempice controllo a differenziali è abbastanza agevole e non comporta gran dispendio di risorse di CPU

[weather]

Il controllo "asse vivo" si basa sul fatto che, con asse in movimento, due letture consecutive della scheda di conteggio, a distanza di tempo, devono dare due valori diversi. Se i valori coincidono l'asse è guasto

..ho' utilizzato questo sistema per anni , poi l'anno scorso mi è successa una cosa che mi ha' fatto ricredere sulla efficacia al 100% di questo metodo : motore + encoder incrementale con classici segnali A e B + scheda di conteggio s7 fm350 , mi chiama il cliente dicendomi che muovendo il motore il conteggio non cambia e non compare nessun allarme ; era l'encoder difettoso, solo che il difetto era tale per cui il bit meno significativo del contatore variava continuamente tra 0 e 1 quindi l'allarme non interveniva in quanto il conteggio era sempre diverso da quello della lettura precedente

da allora abbino un altro controllo : faccio un test sul secondo bit del conteggio (per intenderci , se il conteggio è appoggiato sulla mw10 faccio il test sul bit m11.1) , se dopo un intervallo di tempo non vedo un fronte di salita di questo bit , vado in allarme.

ciao

[emanuele.croci]

OK Livio,

se ho capito bene quello che tu dici è analogo a quello che faccio io:

in pratica....

- io passo all'inverter un riferimento di velocità Vset: se lui non riesce a raggiungere questa velocità mi darà lui stesso un errore; l'inverter è in anello aperto, ma ha una retroazione di velocità dal suo modello matematico, in quanto è vettoriale;

- se l'inverter non mi dà errore e mi restituisce quindi sul profibus una velocità effettiva Veff (che sarà circa uguale a Vset) io applico la tecnica illustrata nel mio primo post (integro Veff ad ogni ciclo di scansione -di 15ms- per un tempo di 0.1 secondi e confronto "l'integrale della velocità" con la distanza percorsa che mi dà l'encoder)

Questa tecnica è analoga a quella che dice Walter, è solo un po' più "raffinata": ad esempio risolve automaticamente anche il problema di weather, in quanto nel tempo di 0.1 s ricevo da 30 a 200 impulsi encoder e non è il singolo impulso che mi fa la differenza.

Ho provato questo sistema perché volevo provare a "prendere dentro" anche errori sulla catena cinematica (ho l'encoder su un albero lento), ad es. se si era allentato un calettatore, ma mi pare che sia troppo impreciso. Comunque, nelle poche prove fatte, se si rompe l'encoder funziona bene.

Grazie e Ciao,

Emanuele

Modificato: 25 novembre 2004 da emanuele.croci

[Livio Orsini]

Si Emanuele come controllo "va o non va" è poù che efficace, specie in unione con la diagnostica dell'inverter.

Se invece vuoi fare un controllo più sofisticato e completo devi per forza lavorare sull'errore di inseguimento.

Non so che CPU stai usando e con quale carico di lavoro, però sei assi non interpolati non dovrbbero richiedere molte risorse di CPU anche per un controllo di posizione canonico.

Prova a dare un'occhiata al mio tutorial sui controlli, nella sezione in cui affronto i principi dei posizionatori potrsti, forse, trovare qualche spunto interessante.

[emanuele.croci]

OK Livio, ti ringrazio.

La mia CPU è una 314C-2DP ed il programma è leggero, se ne può aggiungere a iosa.

Ti farò sapere gli ulteriori sviluppi...

Ciao, Emanuele

Modificato: 26 novembre 2004 da emanuele.croci