Vai al contenuto
PLC Forum


Encoder virtuale


Ste92

Messaggi consigliati

Buongiorno a tutti, spero di scrivere nella sezione giusta. 

Volevo chiedere dei consigli o dei suggerimenti su dove sbaglio riguardo la seguente applicazione. 

In pratica vorrei creare un encoder virtuale da utilizzare temporaneamente nel caso si guastasse quello fisico, nello specifico è un braccio rotante. 

L ho creata utilizzando il feedback di velocità dell'azionamento, in un ob ciclico definito di 10ms, quindi ogni 10 ma leggo il fdbk di velocità e sapendo il rapporto di riduzione mi trovo il valore da scalare per i gradi da 0 a 360.. 

Tutto funziona, solo che confrontando con un registratore di segnali la posizione effettiva e quella calcolata trovo un errore, durante l accelerazione anche di 30 gradi. 

Ok che non mi aspettavo una precisione assoluta, ma neanche così significativa, quindi volevo a chiedere a voi esperti se sto commettendo errori.. Grazie

Link al commento
Condividi su altri siti


Che in accelerazione tu abbia una differenza di 30° può essere più che normale visto la misura di velocità da la velocità media.

 

Però potresti aver fatto un lavoro inutile perchè, probabilmente, la velocità la calcoli avendo come trasduttore l'encoder fisico.

Link al commento
Condividi su altri siti

No la velocità me la passa il drive, che la calcola ad anello aperto, il motore è un asincrono comandato in vettoriale.. 

Dovrebbe essere abbastanza precisa? Comunque correggo la campiono ogni 100 ms per fare il calcolo sul plc 

Link al commento
Condividi su altri siti

12 ore fa, Ste92 scrisse:

Dovrebbe essere abbastanza precisa?

 

Dipende da cosa intendi per precisa; se è in modalità vettoriale sensorless è un valore di velocità stimato quindi la precisione è funzione della bontà della stima, bontà che è influenzata da condizioni transitorie.

 

A mio parere puoi solo usarla come allarme in caso di rottura dell'encoder fisico.

Link al commento
Condividi su altri siti

Si sono d'accordo.. Ma a scopo didattico invece,la differenza potrebbe essere dovuto al ritardo della comunicazione del drive? 

Perché ho provato a shiftare il segnale sul grafico e la curva combacia perfettamente, è "solo" in ritardo.. 

Pensavo ad un piccolo ritardo, magari mi sbaglio.. La comunicazione è in profibus 

Link al commento
Condividi su altri siti

Di questo è questo ritardo?

Profibus permette di effettuare anche regolazioni ad anello chiuso; non credo che dipenda dal bus di campo, a meno di una configurazione non ottimizzata.

Link al commento
Condividi su altri siti

Domani rispondo con più precisione, ma circa 500 ms. 

Però mi chiedo il perché, richiamando nel ob a tempo di 100ms il valore di velocità e facendo il calcolo nello stesso ciclo come fa ad essere in ritardo? 

Non mi torna il ragionamento.. 

Link al commento
Condividi su altri siti

Per prima cosa chi richiama l'OB?

Poi dipende da come è stata stimata la velocità e da qaule priorità ha la trasmissione del dato da parte del drive.

Se sommi tutti i tempi puoi arrivare anche ad un tempo enorme come 0.5"

Link al commento
Condividi su altri siti

Allora io ho fatto la prova nell OB 35.. Ho spulciato un po' tutti i parametri del drive (abb acs 800) e ho trovato un filtro sul segnale di velocità proprio di 500 ms.. Sto pensando che sia proprio questo filtro la causa.. 

Non so come mai sia impostato a 500ms e non vorrei che cambiandolo si possa modificare in qualche modo il funzionamento.. 

Link al commento
Condividi su altri siti

3 ore fa, Ste92 scrisse:

Non so come mai sia impostato a 500ms e non vorrei che cambiandolo si possa modificare in qualche modo il funzionamento.. 

 

Chi ha configurato il drive?

probabilmente il filtro è una media per avere un valore di velocità stabile.

Link al commento
Condividi su altri siti

Non so chi l'abbia configurato, io mi occupo di manutenzione ed automazione, mi informo e cerco di imparare il più possibile.. 

Controllo che questo feedback non sia utilizzato per altre funzionalità e proverò a cambiare questo filtro per vedere se cambia qualcosa.. 

Link al commento
Condividi su altri siti

scusate la intromissione, stavo leggendo con interesse; ovviamente un filtro altera il segnale, ma non dovrebbe sfasarlo; a fine rampa di accelerazione i 2 segnali sono in fase o rimangono sfasati?
ma il mio post era per chiedere a che serve un "encoder virtuale" in un funzionamento ad anello aperto? per un asse elettrico con un altro motore? 😕

Link al commento
Condividi su altri siti

Leggi la discussione dall'inizio e capirai cosa vuol fare con l'encoder virtuale, anche se io sono piuttosto scettico sul risultato.

Link al commento
Condividi su altri siti

il 27/1/2019 at 08:42 , Livio Orsini scrisse:

Leggi la discussione dall'inizio e capirai cosa vuol fare con l'encoder virtuale, anche se io sono piuttosto scettico sul risultato.

si, avevo letto, ma quello che si vuole ottenere è una contraddizione nei termini.... : non può essere l'azionamento che genera un encoder virtuale poichè un encoder è un feedback di controllo dell'azionamento stesso e richiede un comando meccanico.... comunque resto interessato....

Link al commento
Condividi su altri siti

1 ora fa, GiroBo2 scrisse:

ma quello che si vuole ottenere è una contraddizione nei termini.... :

 

Certo, però non del tutto.

L'inverter, in modalità vettoriale sensorless, stima la velocità reale del motore piuttosto precisamente, perchè deve conoscere la posiizione relativa del rotore rispetto alla statore.

Integrando la velocità nel tempo si ottiene lo spazio percorso; conoscendo i rapporti di trasmissione si risale alla posizione "reale" dell'utensile quindi si può ricostruire la posizione dell'encoder.

 

Il confronto tra encoder reale ed encoder virtuale, potrebbe essere un buon strumento di controllo per segnalare eventuali rotture o "scalettamenti" dell'encoder.

 

Usare l'encoder "modellizzato" (termine che mi semnbra più appropriato di "virtuale") per effettuare il posizionamento non mi sembra corretto perchè ... è un cane che si modrde la coda.

Modificato: da Livio Orsini
Link al commento
Condividi su altri siti

  • 2 weeks later...
Sandro Calligaro

Dubito anch'io dell'efficacia della cosa, per due motivi:

- Come dice Livio, se la velocità è calcolata dal drive in sensorless, e se il motore è un asincrono, la precisione sarà tendenzialmente bassa proprio sul valore medio, mentre l'andamento potrebbe essere più o meno corretto. Integrandola hai un errore che potrebbe tendere a divergere;

- Acquisire la velocità con così poca risoluzione nel tempo (e con ritardo) non permette di approssimarla bene. In pratica si vanno a perdere pezzi e, in più, l'integrazione sarà molto approssimata.

 

Se la cosa serve solo per verifica o per emergenza, su tempi di percorrenza e distanze brevi, magari è anche accettabile.

Verificherei però se magari il drive si calcola una posizione che rende disponibile. Non si sa mai...
https://new.abb.com/news/de/detail/11034/abb-integrates-position-control-in-acs880-drives-for-cost-effective-simplicity

 

PS: @GiroBo2: un filtro passa-basso del primo ordine, con costante di tempo di 500 ms, a regime causa esattamente un ritardo di 500 ms, su una rampa.

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...