Pid Regolazione Velocità

[bleny]

Ciao a tutti,

mi aggiungo anch'io alla schiera dei "martiri" del PID...

Premetto che ho cercato per mari e per monti, ho letto i vari documenti nella sezione didattica (grazie Livio...), ma proprio non ne vengo a capo.

Ecco il problema.

Utilizzo abitualmente vari regolatori PID di posizione e/o temperatura implementati con i soliti FB41 o FB58 e tutto è sempre andato bene (al limite qualche piccola rogna col tuning).

Adesso mi è venuta la malsana idea di implementare un PID per il controllo di velocità, ovvero ho una valvola idraulica proporzionale e più la apro più il mio cilindro si muove velocemente.

La parte che non riesco a risolvere è l'uscita della grandezza regolante. Mi spiego: con un controllo di posizione o di temperatura più mi avvicino al setpoint più l'errore diminuisce e, di conseguenza, la grandezza regolante tende a zero.

Con un controllo di velocità questo comportamento non va bene, perchè più mi avvicino al setpoint più la grandezza regolante diminuisce e, quindi, l'errore torna ad aumentare perchè l'attuatore rallenta: il sistema comincia a "pendolare" e non se ne viene più fuori.

Il comportamento del PID dovrebbe essere che, al diminuire dell'errore, la grandezza regolante invece di andare verso lo zero rimanga stabile su un valore adatto al mantenimento della velocità.

Grazie a tutti per la collaborazione.

Massimo

[mazzinga]

Il comportamento del PID dovrebbe essere che, al diminuire dell'errore, la grandezza regolante invece di andare verso lo zero rimanga stabile su un valore adatto al mantenimento della velocità.

Per fare quello che vorresti fare tu oltre all'azione Proporzionale e Integrale devi aggiungere il contributo Feedforward calcolandoti la velocita in funzione della grandezza di arrivo.

Il PI deve solamente correggere è quindi tenere un profilo quanto piu fedele.

Spero di essere stato chiaro

[Livio Orsini]

Se hai letto il mio tutorial dovresti sapere che, in un regolatore PI(D) errore e riferimento, a regime, non sono correlati.

Teoricamente l'errore è zero, la parte porporzionale di conseguenza è nulla. Tutto il riferimento grava sulla parte integrale che annulla l'errore.

Se questo non avviene significa che il regolatore non funziona.

Da quello che scrivi ho l'impressione che il sistema di regolazione non sia configurato correttamente.

Dovresti spiegare meglio come ha implementato la regolazione; cosa usi come reazione di velocità, i tempi di campionamento del PI(D), etc.

Per fare quello che vorresti fare tu oltre all'azione Proporzionale e Integrale devi aggiungere il contributo Feedforward calcolandoti la velocita in funzione della grandezza di arrivo.

Non è strettamente necessario. Un feedforward ben ottimizzato riduce la necessità di Integrale, quindi aumenta la velocità di risposta del regolatore. Però anche usando esclusivamente le componenti PI senza feed forward l'errore deve tendere a zero.

[bleny]

Effettivamente qualche dato in più non guasta....

La rilevazione della velocità e il PID lavorano assieme, ovvero ho buttato tutto in un unico OB che viene richiamato ogni 500 msec; mi rendo conto che non è il massimo dell'accuratezza ma ho scoperto solo da poco (non mi era mai venuto in mente di controllare) che il modulo ET200 che uso per rilevare la posizione (ingresso 0-10V) cicla con la strabiliante velocità di 130ms. In attesa di sostituirlo con la versione veloce (e di abbassare il tempo dell'OB) devo cercare di barcamenarmi come posso.

La velocità viene quindi calcolata misurando quanto si è mosso il pistone tra due richiami successivi dell'OB e subito dopo passo il dato al PV_IN dell'FB.

L'altro problema è che il processo da controllare avviene in un tempo abbastanza breve (diciamo 4/5 secondi) e, in teoria, avrei bisogno di una velocità di risposta particolarmente pronta, anche perchè in questi 4/5 secondi la velocità deve cambiare, anche se non in modo esagerato.

Di conseguenza, se non ho capito male, sarebbe meglio non usare la componente integrale per migliorare la risposta, però dovrei usarla per far funzionare correttamente il sistema

L'alternativa potrebbe essere il feedforward di cui parlava Mazzinga? Se sì come lo implemento negli FB Siemens?

Grazie a tutti per la pazienza...

Massimo

[Livio Orsini]

Non ti offendere ma credo che tu abbia le idee un poco confuse su come si debba affrontare questo problema.

Prima cosa 500 ms di tempo di campionamento, per controllare la velocità di un pistone pneumatico o oleodinamico non è un tempo, ma un'era geologica .

Anche senza conoscere i dati, perchè tu ti guardi bene dal pubblicarli , penso che non si dovrebbero superare i 10 ms - 20 ms di tempo di campionamento, ma è una stima ottimistica. In molti casi il tempo di campionamento per il controllo di velocità di un pistone deve essere minore di 1ms.

Poi dovresti rendere noti almeno:

- velocità massima del pistone

- modo di misurare la velocità, in altri termini quale trasduttore hai usato, come è accoppiato, etc.

- tempo di risposta e modo di risposta della valvola proporzionale, meglio se scriva marca e modello della valvola così si può consultare il relativo foglio tecnico.

Per il momento lascia stare il feed forward, cerca di mettere a punto il PI.

Personalmente, poi, non userei il PID di libreria della Siemens. E' stato pensato per impieghi generali e non è ottimizzato per un impiego ababstanza specializzata come questo.

Modificato: 21 marzo 2011 da Livio Orsini

[bleny]

Ciao Livio,

che abbia le idee confuse è innegabile, il problema, però, è che in questo momento devo fare i conti con l'hardware che ho a disposizione; come ho scritto nel precedente messaggio, infatti, sono perfettamente consapevole che il campionamento sia a dir poco "vergognoso", ma in attesa che mi consegnino il modulo nuovo di meglio non si può fare: se aumento la frequenza dell'OB, infatti, arrivo a un punto in cui, anche se la posizione cambia, io leggo sempre la stessa quota e quindi ho dei picchi di velocità uguali a zero che non sono reali e il cui quantitativo aumenta con il diminuire della frequenza dell'OB.

Giusto come esempio sulla stessa macchina ho un cilindro oleodinamico del quale controllo la posizione con un encoder SSI e campionando a 20 ms tutto funziona egregiamente.

Per quanto riguarda il caso specifico la velocità massima del pistone non supera i 130 mm/sec e per rilevare la velocità uso un trasduttore di posizione magnetostrittivo lineare assoluto con uscita 0-10V. Premetto subito che non è una soluzione che mi mandi in visibilio ma il pistone mi è arrivato con il trasduttore "annegato" all'interno e, quindi, essendo un blocco unico non ho avuto molta scelta.

Per quanto riguarda la valvola è una Moog D633-317B con pilotaggio -10/+10V, appena trovo il data sheet ti do le caratteristiche, ma la risposta dovrebbe essere abbastanza "performante".

In alternativa al PID Siemens hai qualcosa da suggerirmi (magari freeware )?

Grazie e ciao.

Massimo

[Livio Orsini]

In alternativa al PID Siemens hai qualcosa da suggerirmi (magari freeware smile.gif )?

Se hai letto il mio tutorial ci trovi gli esempi scritti in pseudo C. Negli esempi allegati trovi un controllo per un pistone oleodinamico, valvola MOOG e trasduttore di posizione analogico (0-10 V). IL controlo PID è scritto in AWL per S7-214, il PID viene richiamato ogni 10 ms.

Attenzione! La lettura del trasduttore deve essere fatta nel blocco PID, così come il rinfresco dell'uscita, e deve essere effettuata a tempo rigorosamente costante! Quindi il tutto deve essere gestito da OB35 se usi una CPU 3xx.

Modificato: 22 marzo 2011 da Livio Orsini

[bleny]

Grazie Livio

Vado, "colpisco" e torno.

Ti confermo che, come da te suggerito, tutto quello che riguarda il funzionamento del PID (lettura del trasduttore e calcolo della velocità prima e rinfresco dell'uscita dopo) è all'interno di un OB a tempo (OB33).

Ti farò sapere come va a finire.

Ciao e grazie.

Massimo

[batta]

il modulo ET200 che uso per rilevare la posizione (ingresso 0-10V) cicla con la strabiliante velocità di 130ms

Non capisco.

Cos'è che cicla a 130 ms?

E' una CPU ET200S o è un problema di comunicazione in rete Profibus?

Perché non descrivi meglio il tuo hardware?

Se si tratta di una CPU che gira così piano, ci deve essere qualche problema. E' difficile riempire così tanto una CPU tipo ET200S (IM151-7 per esempio, se di questo si tratta) da farla girare su questi tempi.

Se il caso è questo, c'è sicuramente qualcosa da rivedere nel programma.

In ogni caso però, non sarebbe un problema. Potresti configurare OB35 a 10 o 20ms e richiamare da OB35 il PID e relative letture/scritture dei valori analogici.

Se invece quei 130 ms riguardano una lentezza di aggiornamento della periferia, direi che per arrivare a simili tempi su quella rete ci deve essere ogni cosa possibile immaginabile, a anche qualcosa di più.

E ritorniamo quindi al punto di partenza: perché non descrivi l'hardware?

Nel caso non fosse possibile risolvere il problema di tempi così lunghi solo con l'ottimizzazione di quello che hai a disposizione, come soluzione potresti pensare ad una piccola cpu (inserita in rete Profibus o Profinet come slave) alla quale far gestire solo il pistone.

[bleny]

Ciao Batta,

i moduli in questione sono quelli analogici dell'ET200 con ingresso in tensione o in corrente.

Li ho sempre usati senza particolari problemi, questa volta, però, l'applicazione era abbastanza critica e mi sono accorto che c'era qualcosa che non quadrava con l'aggiornamento dei valori.

A questo punto sono andato a dare un'occhiata ai dati tecnici e ho scoperto con discreta sorpresa che il tempo di conversione per ciascun canale è di 65 ms; inoltre il tempo di ciclo del modulo è dato dal tempo di conversione moltiplicato per il numero di canali attivi; dato che io uso tutti e due i canali il risultato è che per passare alla cpu i valori aggiornati servono 130 ms (cosa che dà un senso alle letture "strane" che vedevo).

Dovrei riuscire a risolvere il problema sostituendo i moduli con quelli HS (tempo di ciclo 1 ms).

Ciao.

Massimo