Termoregolazione Semplice Con Plc

[step-80]

Buonasera. Tutto chiaro per quanto riguarda i dubbi sulle termocoppie. Siemens ha in catalogo un modulo con quattro ingressi specifici per termocoppie ad un prezzo abbordabile e per me sarebbe perfetto.

Girovagando per il forum in cerca di informazioni su come implementare il regolatore PWM mi sono imbattuto in questo post:

"La costante di tempo termica del serbatoio, pur non conoscendone il contenuto, il volume, il tipo di liquido e la potenza dei riscaldatori, si può comunque stimare almeno dell'ordine di qualche decina di secondi.

Bene, in questo caso geenrare un PWM è semplicissimo.

Per prima cosa fai un temporizzatore preciso ad interrupt, che generi un interrupt ogni 100 ms

Consideri questo tempo come 0.1% di tutto il PWM, in altri termini l'intero periodo vale 100"

Ti costruisci un regolatore la cui uscita vari da 0.1% a 99.9% in funzione dell'errore di temperatura. Questo numero, espresso come 1 - 999 costituisce il contatore di PWM ON, la differenza a 1000 costituisce il contatore di PWM OFF

Ogni volta che scatta il temporizzatore verifichi se il contatore di PWM ON è >0; se è >0 metti a "1" l'uscita di comando degli interruttori statici, scrivendo direttamente nella periferia senza passare dai registri immagini del PLC; se il contatore è = 0, verifichi se il contatore PWM OFF è > 0; se sei in questa condizione metti a "0" l'uscita di comando degli interruttori statici con la modalità descritta in precedenza. Se entrambi i contatori sono = 0, ricarichi i due contatori con l'ultimo valore calcolato dal regolatore e metti a "1" l'uscita."

È un post di Livio in risposta ad un utente avente un applicazione analoga alla mia.

Sul fatto del temporizzatore ad interrupt non ci sono dubbi,quello che non capisco è questo passaggio:

"Ti costruisci un regolatore la cui uscita vari da 0.1% a 99.9% in funzione dell'errore di temperatura. Questo numero, espresso come 1 - 999 costituisce il contatore di PWM ON, la differenza a 1000 costituisce il contatore di PWM OFF"

Cosa si intende per "costruire" un regolatore?

E cosa si intende per contatore di PWM on e off?

Grazie a tutti coloro vorranno chiarire

Matteo

Modificato: 12 gennaio 2013 da step-80

[batta]

È un post di Livio in risposta ad un utente avente un applicazione analoga alla mia.

E quello che dice Livio è perfetto.

Però a te non serve, perché il PID dell'S7-1200 ti permette di gestire direttamente l'uscita PWM. In pratica, tutti i calcoli suggeriti da Livio sono già implementati nella funzione PID.

Il tempo totale del ciclo PWM lo imposti nella variabile "sRet.r_Ctrl_Cycle". Di default è 1 secondo.

Nel tuo caso, credo potrebbe andare bene un tempo da 1 a 5 secondi. Tutto dipende dall'inerzia termica del sistema.

[Livio Orsini]

Cosa si intende per "costruire" un regolatore?

E cosa si intende per contatore di PWM on e off?

Dovresti leggere bene tutta la discussione a cui fai riferimento.

Un regolatore PID può essere "costruito" al di fuori di quello già presente in libreria (o anche se non esiste ub suimile algoritmo di libreeria).

Perchè costruirlo se esiste già?

CI possono essere svariati motivi che possono spingere ad usare un regolatore "dedicato" in luogo di quello presente in libreria. Te li elenco in dordine sparso, non di priorità.

• Il regolatore di libreria è un blocco chiuso che non conosci e non puoi dominare appieno.
  
• Il regolatore di libreria, essendo previsto per impieghi generali, non pienamente ottimizzato.
  
• Il regolatore di librerira è un PID classico standard. Si possono realizzare praticamente infinite varianti di questo regolatore. Ogni variante permette di ottenere determinate prestazioni più favorevoli al problema specifico. Faccio un esempio di una variante banale ma che è abbastanza favorevole in molte regolazioni. La componente derivativa nella configurazione classica è ottenuta derivando l'errore. In altri termini si analizza la velocità con cui varia l'errore e da questa indicazione si aumenta o si diminuisce la correzione risultante dalle componenti proporzionale ed integrale. Se invece di ricavare la comnponente derivativa dall'errore la si ricava dalla reazione, cioè dalla misura della variabile controllata, gli effeti sono simili, tranne che nel caso in cui si effettui una variazione di riferimento. In molte apllicazioni come, ad esempio, parecchi controlli di temperatura, quest'azione risulta più favorevole. Nei controlli di posizione e velocità è prassi corrente usare un anticipo di razione, cioè ricavare la comnponnete derivativa dalla reazioen. Nei vecchi convertitori analogici si otteneva semplicemente mettendo un condensatore in parallelo ad un resistore del partitore di tachimetrica.
  

Ci sono ancora altri motivi che fanno preferire la soluzione personalizzata a quella standard, ma ho elencato i principali.

Però siccome nulla è gratuito e tutto si paga ci sono anche delle contro indicazioni.

la principale è che per costruirsi il proprio regolatore si deve spendere del tempo e poi è necessario metterlo a punto, cioè effettuare il così detto debug, mentre la funzione di libreria è già lì, pronta, sviluppata e debuggata.

Però anche qui ci sono .... svantaggi.

Se, come a volte capita, ci sono bugs nascoste che si manifestano solo in condizioni molto particolari (questo è tipico delle bugs nascoste, altrimenti sarebbero già state eleiminate ) diventa un problema praticamente insolubile perchè non sai come accade e non puoi ne ricercarlo ne emendarlo.

Poi, se hai una discreta esperienza, hai una tua libreria di regolatori già testati e ottimizzati, per cui non perdi tempo quando devi usarli.

E' charo che per un utente non molto esperto l'uso del regolatore di libreria risolve tanti problemi con poca spesa. Devi solo imparare a parametrizzarlo.

Io però ho una mia filosofia, cerco di non usare mai niente che non posso dominare completamente. Purtroppo non sempre è possible, però se appena appena ne ho la possibilità......

ma questa è solo un mia personale mania.

[Livio Orsini]

Batta rileggendo la discussione ho visto questo tuo intervento che stranamente mi era sfuggito.

Non tanto per polemica, ma solo per il semplice piacere di discutere mi sembra corretto risponderti.

Io continuo a non conoscere Katz e kuo, ma penso di conoscere lo stesso la teoria di come si debbano elaborare delle funzioni PID in un PLC.

Io ho citato due fra i primi studiosi che hanno affrontato i problemi dei controlli discreti, controlli che hanno cominciato ad affacciarsi nel mondo dell'elettronica industriale alla fine degli anni '70; prima i controlli erano esclusivamente di tipo continuo. Con questo non significa che non si possa aver studiato su testi successivi, solo che i due che cito sono una pietra migliare, un qualche cosa come i testi del Millman per chi ha studiato i semiconduttori e le loro applicazioni. (magari ci sarà qualcuno che preciserà che lui conosce i semiconduttori ma non ha mai sentito nominare Millman ).

Non è pensabile però, se devo gestire 40 o più PID, creare 40 diversi interrupt a tempo (o un interrupt con una sequenza per diversificare 40 chiamate ai PID).

Puoi benissimo, per assurdo, gestire anche 100 PID in un'unico interrupt senza che l'ultimo regolatore debba essere affetto da tutto il jitter dovuto alle variazioni dei tempi necessari alla risoluzione dei regolatori che lo precedono.

Esistono metodologie molto semplici, che i "vecchietti" come me sono cotretti a conoscere perchè un tempo le prestazioni dei processori non erano molto veloci. Usando queste metodologie non hai ritardi variabili, ma ritardi fissi e, soprattutto, esattamente quantificabili quindi perfettamente gestibili.

Purtroppo questi metodi non sono permessi con i regolatori standard di libreria.

E' dimostrabile analiticamente che una variazione, anche minima, del perido di campionamento e/o di aggiornamento causa dei disturbi ben precisi e ben quantificabili; similmente ai disturdi causati dagli errori di troncamento e di arrotondamento. Anzi a metà degli anni novanta c'è stata una specie di moda nel mondo accademico italiano, tanto che son comparsi parecchi articoli sulla stampa specializzata che discustevano di questi argomenti e sulle contromisure necessaria. A onor del vero parecchi eran solo aria fritta e questioni di alna caprina, però il problema è reale.

Che poi nella pratica corrente sia misconoscito e tamponanto con la taratura "non ottimizzata" dei parametri del regolatore, è tutto un altro ragionamento. Come è anche abbastanza reale che nel 99% dei casi il degrado delle prestazioni sia poco o nulla apprezzabile.

Però un conto è conoscere un problema e decidere che è possiible non tenerne conto, altro è ignorare che esiste il problema.

Io ritengo che una persona che è esperta abbia il dovere di informare chi si rivolge a lui, per consigli da apprendista, che il problema essite; magari, successivamente, potrà informare l'apprendista che il problema può essere ignorato nella pratica.

[batta]

Però un conto è conoscere un problema e decidere che è possiible non tenerne conto, altro è ignorare che esiste il problema.

Io ritengo che una persona che è esperta abbia il dovere di informare chi si rivolge a lui, per consigli da apprendista, che il problema essite; magari, successivamente, potrà informare l'apprendista che il problema può essere ignorato nella pratica.

Come potrei non essere d'accordo su questo?

Ma rimane il fatto che, nel caso in questione, richiamando i 4 pid uno in fila all'altro nello stesso interrupt, l'errore temporale dell'ultimo PID sarà probabilmente da valutare in microsecondi.

Quindi, non è che io voglia ignorare il problema, dico semplicemente che (sempre riferito al caso in questione) il problema è solo teorico. In pratica, l'errore che ne consegue è assolutamente irrilevante.

[batta]

Vorrei chiarire che non c'è nessuna vena polemica nella mia insistenza ad affermare che non c'è nulla di sbagliato a richiamare 4 PID in fila.

Solo ritengo che per l'elaborazione di una funzione PID, se non si cambia modo di operare (manuale/automatico, abilitazione/disabilitazione di integrale e/o derivata, ecc.) si impieghi sempre lo stesso tempo.

I PID successivi al primo verranno sempre elaborati con lo stesso identico ritardo, quindi, non c'è nessun errore temporale e non c'è jitter.

Ma magari mi sfugge qualcosa. Per questo, e voglio ripetere senza nessuna intenzione di polemizzare, ti chiederei di chiarire cosa c'è che non va in questo mio ragionamento.

[step-80]

Grazie a tutti per le risposte.

Mi fa molto piacere che siemens svolga già una parte di lavoro al posto mio,ma da una parte mi rode perchè vorrei capire comunque a fondo ciò che vado ad implementare senza mettere numeri dentro caselle che in realtà non so a cosa servano.

Forse sto chiedendo troppo e se lo sto facendo scusate la mia faccia tosta...ma sarei davvero grato a chiunque di voi si prendesse la briga di postare un semplice esempio numerico prendendo come riferimento-per esempio-il post di Livio nel quale aiutava un altro ragazzo.

Io un idea in testa di come dovrebbe essere ce l'ho,ma se avessi qualche esempio concreto davanti mi farebbe senz altro bene.

Visto che ci sono,chiedo ancora.

per quanto riguarda la parte proporzionale,come guadagno mi si chiede un numero da o a 1.

Ma cosa implica fisicamente il guadagno?cioè è un fattore da moltiplicare per esempio con l'errore?

Ho intuito che in un regolatore proporzionale il valore di uscita è proporzionale all'errore intercorrente tra setpoint e valore rilevato

ES imposto il mio termoregolatore perchè la mia pinza calda raggiunga i 190 gradi;lo accendo;in quel momento ovviamente la temperatura rilevata sarà grossomodo quella ambiente che poniamo essere 20 gradi.

In questo caso l errore risulterebbe essere 170 gradi giusto?

Ecco,da questo errore come si arriva al valore pwm da dare all uscita ?

Secondo quesito(e qui non mi bannate )

Per quanto riguarda la parte integrale,non ho proprio capito che influenza effettiva abbia sul processo.Mi sembra di aver capito che si tratta di una unità di tempo.

Infine una conferma: se non erro la componente derivativa effettua una sorta di "previsione" a seconda dell andamento dell errore..

Grazie in anticipo

Matteo

[batta]

per quanto riguarda la parte proporzionale,come guadagno mi si chiede un numero da o a 1.

Non ti chiede un numero da 0 a 1, ma un numero in virgola mobile, che può tranquillamente essere anche molto più di 1. Tutto dipende la sistema.

Ma cosa implica fisicamente il guadagno?cioè è un fattore da moltiplicare per esempio con l'errore?

Sì. Moltiplicando l'errore per il guadagno (o costante proporzionale), ottieni la parte proporzionale. Sommando poi (se abilitate) la parte integrale e la parte derivativa, si otterrà il valore di uscita.

ES imposto il mio termoregolatore perchè la mia pinza calda raggiunga i 190 gradi;lo accendo;in quel momento ovviamente la temperatura rilevata sarà grossomodo quella ambiente che poniamo essere 20 gradi.

In questo caso l errore risulterebbe essere 170 gradi giusto?

Ecco,da questo errore come si arriva al valore pwm da dare all uscita ?

Supponiamo, per comodità, che tu abbia impostato guadagno = 1.0 e che i limiti dell'uscita del PID siano tra 0.0 e 100.0

Partendo con un errore di 170 gradi, la parte proporzionale assumerebbe, da sola, un valore oltri i limiti impostati. L'uscita verrà quindi limitata a 100.0

Poi ti avvicini al setpoint. Supponiamo poi che tu abbia abilitato solo il proporzionale. Se l'uscita del PID è data dall'errore moltiplicato per la costante proporzionale, capisci subito che non potrai mai arrivare al valore di setpoint. Se raggiungi il setpoint infatti, significa che l'errore è zero e, quindi, anche l'uscita del PID sarà zero. Ecco quindi che interviene l'integrale. Ora ho la cena pronta e non ho tempo per dilungarmi su questo argomento. Ti dico solo che ci sono fondamentalmente due modi per impostare l'integrale: uno impostando una costante che più è grande maggiore sarà l'effetto dell'integrale, l'altro impostando un tempo (è questo il caso più frequente e quello usato nel PID Siemens). Più grande è il tempo, più lenta sarà l'azione dell'integrale.

C'è poi la derivata che, per il tuo sistema, direi che è meglio non usare.

[step-80]

Batta grazie mille per la spiegazione,stavo seguendo il tuo discorso con assoluta devozione,sono arrivato all integrale e poi....e poi.... Sono arrivato che sei andato a cena....!

A parte gli scherzi,spero vivamente avrai voglia/tempo di continuare il discorso,in caso contrario,grazie del tempo che mi hai dedicato.

P.s L integrale non l ho ancora capito che funzione ha...

[Livio Orsini]

P.s L integrale non l ho ancora capito che funzione ha...

Allora non hai letto il mio tutorial.

Leggi attentamente il primo capitolo, specialmente le prime pagine. L'esempio fa riferimento ad un controllo di velocità, ma il ragionamento è identico.

I PID successivi al primo verranno sempre elaborati con lo stesso identico ritardo, quindi, non c'è nessun errore temporale e non c'è jitter.

Batta ero quasi sicuro che ti stia sfuggendo qualche cosa, ora ne ho la conferma.

Premesso che sono d'accordo con te che nel caso in oggetto il disturbo causato dal jitter è praticamente trascurabile, vediamo perchè c'è sicuramente jitter nell'accodare più regolatorari.

Se i 4 regolatori impiegassero l'identico tempo di elaborazione non ci sarebbe jitter, ma solo un ritardo fisso e costante.

Purtroppo non è così.

Ad ogni elaborazione è più probabile che il tempo impiegato sia differente, vuoi perchè l'errore cambia, vuoi perchè i percorsi di elaborazione variano in funzione delle condizioni.

Proprio per verificare questi problemi sono uso, ad ogni nuova implementazione di un regolatore o prima applicazione di un regolatore su di un nuovo Hw, effettuare una serie di test Hw e Sw con svariati strumenti, per stabilire i limiti temporali di elaborazione.

Tanto per darti un'idea. Con una CPU S7-226 un PID non molto elaborato, girava tra un minimo di 1.8 ms ed un massimo di 2.6 ms. Quindi 800 µs di variazione. Presumibilmente con le nuove CPU, molto più veloci, questa variazione si ridurrà di molto, diciamo di 10 volte? son sempre 80 µs.

Prendiamo il caso pessimo. Elaborazione con tempo massimo per tutte e 4 i regolatori, seguito da un ciclo a tempo minimo: il primo regolatore ha una variazione di tempo di campionamento nullo perchè parte sempre sul fronte del temporizzatore, il quarto invece ha 320 µs di variazione.

Sono inifluenti? A volte si a volte no. Poi bisogna valutare che questo è il caso pessimio come ritardo. Però l'ultimo regolatore avrà sempre e comunque un'oscillazione temporale perchè i 3 regolatori che lo precedono mai avranno il medesimo tempo di elaborazione. Probabilemnte l'oscillazione media si attesterà nell'intorno dei 50 µs (+/- 25 µs). Non è molto se si fa riferimento ad un tempo di campionamento >100 ms; diventa rikevante se pensiamo ad un tempo di campionamento dell'ordine di 1 ms.

Poi bisogna considerare che questo jitter si va a sommare ad altre componenti che non sono eliminabili, peggiorando le cose.

[batta]

Ad ogni elaborazione è più probabile che il tempo impiegato sia differente, vuoi perchè l'errore cambia, vuoi perchè i percorsi di elaborazione variano in funzione delle condizioni.

E' proprio su queste differenze di tempo che io non sono convinto, non certo sulla teoria che una mancata costanza nel tempo di elaborazione porti ad errori.

Il fatto che cambi l'errore porta a differenze di tempo di elaborazione solo nei casi in cui questa differenza porti a modificare il funzionamento del PID.

Questo potrebbe avvenire, per esempio, quando entro ed esco dalla banda morta, quando entro ed esco dai limiti impostati per il valore di uscita, ed altri casi simili.

Questi cambiamenti però non avvengono ad ogni elaborazione del PID. La frequenza di questi cambiamenti, riferita al tempo di campionamento dei PID, è molto bassa. Non si può quindi parlare di jitter.

Quando non ci sono questi cambiamenti invece, le uniche differenze di tempo di elaborazione imputabili al fatto che la variabile di processo varia, sono quelle dovute ad un diverso tempo per i calcoli in virgola mobile.

Ma queste differenze dovrebbero essere, tra un ciclo e l'altro, dell'ordine di pochi microsecondi.

Chiaramente se stessimo parlando di PID con campionamento ad 1 ms, anche errori piccolissimi non sarebbero trascurabili. Ma qui entriamo in un campo che non è più quello dei PID gestiti in un normale interrupt a tempo di un PLC.

Nemmeno i PLC più performanti ti permettono di fare questo senza l'utilizzo di schede dedicate.

In linea di massima, con un PLC è difficile scendere sotto ai 10 ms. Poi, ovviamente, dipende dal PLC. Io nella maggior parte dei casi lavoro su CPU fino alla 315, ma mi è capitato anche di lavorare su 317 e 319, con programmi piuttosto pesanti e parecchie decine di PID. Il tempo di scansione era di 1-2 ms.

Tornando al caso in questione poi, con campionamento del PID sicuramente non più veloce di 100 ms e una uscita PWM con periodo di 1-2 secondi, anche un jitter piuttosto elevato avrebbe effetti difficili da avvertire.

Comunque, mi riservo di fare alcune prove con un S7-1200 per vedere, con una decina di PID, che errore temporale mi troverò sull'ultimo.

[Livio Orsini]

Questi cambiamenti però non avvengono ad ogni elaborazione del PID. La frequenza di questi cambiamenti, riferita al tempo di campionamento dei PID, è molto bassa.

Dipendi in che condizioni ti trovi.

Se, ad esempio, ti trovi in prossimità della banda morta puoi anche avere 2 percorsi completamente differenti tra due scansioni immediatamente seguenti.

Nella prima il mioerrore è dentro la banda morta, quindi nessuna elaborazione e durata minima dell'elaborazione.

Nel campionamento successivo l'errore è maggiore della banda morta quindi elaborazione completa del PID.

In queste due scansioni la differenza di tempo è la massima possibile.

Similarmente quando sei in condizioni prossime al limite di una componente, puoi avere percorsi differenti con più o meno istruzioni da elaborare.

In linea di massima, con un PLC è difficile scendere sotto ai 10 ms.

Concordo pienamente, anche perchè poi si lascia troppo poco tempo al resto del programma. A meno di casi particolari. Ad esempio con una S7-214 chiudevo due loop di posizionamento in 10 ms, ma il programma praticamente faceva solo quello.

Come ho scritto in precedenza, non usando funzioni di libreria ma funzioni dedicate, il problema del jitter per me non essite anche se eseguo più di una funzione di regolazione perchè le letture della variabile e gli aggiornamenti della correzione, avvengono sempre nel medesimo tempo. L'unico jitter è quello dovuto all'imprecisione del timer ed alla latenza dell'interrupt. Ma questo è impossibile da eliminare.

Comunque, mi riservo di fare alcune prove con un S7-1200 per vedere, con una decina di PID, che errore temporale mi troverò sull'ultimo.

Il problema è sempre nella misura.

Con una scheda dedicata è abbastanza facile. All'ingresso della funzione si alza un'uscita che sarà abbassata immediatamente prima del termine della funzione. Basta misurare il tempo con un contatore preciso e si possono apprezzare anche variazioni di 100 ns.

Con un PLC è un po' più difficoltoso. Io i risultati migliori li ho ottenuti facendo qualche cosa di simile, ma scrivendo immediatamente in un'auscita analogica; prima +10 V e successivamente 0 V.

Il tempo di conversione del D/A non è trascurabile, però è sufficientemente costante da elidersi.

Se puoi fare le prove e vuoi pubblicare i risultati, amgari anche descivendone le modalità, le leggerò con molto interesse anche perchè non conosco assolutamente il 1200 e sarebbe un buon termine di paragone.

Suppongo che le prove le farai con il PID di libreria.

[batta]

Nella prima il mioerrore è dentro la banda morta, quindi nessuna elaborazione e durata minima dell'elaborazione.

Nel campionamento successivo l'errore è maggiore della banda morta quindi elaborazione completa del PID.

Sì, certo.

Ma questa differenza non avviene ad ogni campionamento.

Solo per fare un'ipotesi, se con un PID con campionamento ogni 100 ms mi trovo con la variabile di processo che oscilla al limite della banda morta e che continua ad entrare ed uscire ogni 5 secondi (situazione già poco realistica per un controllo di temperatura), questo ci porterebbe ad avere l'errore ogni 50 campionamenti. Ecco che non si può più parlare di jitter. Questo diventa un piccolo errore occasionale assolutamente trascurabile.

Se puoi fare le prove e vuoi pubblicare i risultati, amgari anche descivendone le modalità, le leggerò con molto interesse anche perchè non conosco assolutamente il 1200 e sarebbe un buon termine di paragone.

Suppongo che le prove le farai con il PID di libreria.

Per ora mi dovrò limitare a misurare il tempo all'interno del plc con risoluzione di 1 ms, perché dispongo solo di una CPU senza uscite analogiche e con uscite digitali a relé.

Farò le prove con il PID di libreria e pubblicherò sicuramente i risultati.

[Giuseppe Signorella]

Piccolo O.T.

Farò le prove con il PID di libreria e pubblicherò sicuramente i risultati.

Se la cosa può essere di vostro interesse, è presente un progetto (aperto) per un PID "snello" per le CPU S7 1200, (proveniente da casa siemens) E' presente nella sezione PLC esempi di programmazione

Esempi S7 1200

Visto che si tratta di un progetto aperto, a questo punto della discussione sarebbe gradito un vostro parere da esperti in merito.

Un aiuto da parte vostra per tutti quei utenti che decideranno leggendo questa discussione di intraprendere la strada di non utilizzare i pid di libreria ma di farsene uno da soli ottimizzato per le proprie esigenze.

Forse per piccole e semplici applicazione, l'uso di PID meno complessi e più "snelli" rispetto a quelli di "libreria" può risultare più idoneo.

Modificato: 14 gennaio 2013 da Giuseppe Signorella

[Livio Orsini]

Ecco che non si può più parlare di jitter. Questo diventa un piccolo errore occasionale assolutamente trascurabile.

No anche questo è jitter, che poi sia trascurabile, se lo è, è un'altra questione.

Se poi è ricorrente può causare una vera propria modulazione. Ci sono casi di controlli di temperatura, per piccoli estrusori di materiale medicale, dove il risultato potrebbe anche avere conseguenze molto negative.

Per ora mi dovrò limitare a misurare il tempo all'interno del plc con risoluzione di 1 ms,...

(Quasi) Certamente misurerai un tempo di esecuzione costante. Se le prestazioni di queste CPU sono quelle che appaiono sulla carta eventuali variazioni di tempi di esecuzione si dovrebbero aggirare nell'ordine della decina o, al più di qualche decina di microsecondi.

Ognuno ha le sue filosofie. Io per principo evito che possa accadere il fenomeno che ho descritto. preferisco preoccuparmi prima, anche inutilmente, piuttosto che dever ricorrere.....agli esorcismi dopo.

Piccola nota di colore OT.

Alcuni decenni fa ho avuto come collega, un tizio che era convinto che gli errori software fossero dovuti a malocchio, ed influenze malefiche di suoi presunti nemici. Lo sorpresi una volta a recitare "giaculatorie" per togliere il malocchio.

ma questo non ha nulla a che vedere con eventuali jitters.

Modificato: 14 gennaio 2013 da Livio Orsini

[batta]

Se la cosa può essere di vostro interesse, è presente un progetto (aperto) per un PID "snello" per le CPU S7 1200, (proveniente da casa siemens)

Lo guarderò di sicuro.

Per ora pubblico quanto emerso dalle prove effettuate.

CPU S7-1200 (6ES7212 1BD30-0XB0 - Firmware 2.2)

Ho fatto due prove, una con OB ciclico a 100 ms, e l'altra a 1000 ms.

1) In una routine richiamata nel MAIN, sul fronte di salita dell'ingresso E0.0 leggo e memorizzo data-ora di sistema

2) Nel primo segmento dell'OB ciclico leggo e memorizzo data-ora di sistema con l'istruzione RD_SYS_T

3) Poi richiamo 10 diversi PID ai quali passo però lo stesso set point e lo stesso valore di processo. In realtà ogni PID lavora con variabili diverse, in modo quindi completamente indipendente. Passo però a tutte le variabili valori uguali per i 10 PID.

4) Alla fine dell'elaborazione dei PID leggo e memorizzo nuovamente data-ora di sistema

5) Fuori dall'interrupt calcolo poi la differenza (con l'istruzione T_DIFF) tra data-ora uscita interrupt e data-ora ingresso interrupt, e tra data-ora uscita interrupt e data-ora memorizzata con E0.0

Ho poi provato i PID nei seguenti modi operativi: 0 (inattivo), 3 (automatico), 4 (manuale).

Con PID disabilitati, la differenza di tempo misurata tra ingresso e uscita dall'interrupt è di 13-14 ms.

Con PID in manuale si passa a 16-17 ms.

Con PID in automatico la differenza diventa di 19 ms.

La differenza invece con il tempo fissato con l'ingresso E0.0 (controllata solo con interrupt a 1000 ms, perché non è possibile controllare visivamente una variabile che cambia 10 volte al secondo), ad ogni richiamo dell'interrupt viene incrementata di 999-1000 ms.

Non ho riscontrato nessuna differenza giocando con i valori di set point e della variabile di processo.

Ad essere sincero, due sono le cose che mi hanno un po' sorpreso: il fatto che l'elaborazione del PID in automatico richieda ben 1,9 ms, e il fatto che ci sia poca differenza cambiando modo di funzionamento. Anche con PID disabilitato, il tempo necessario per l'elaborazione è di ben 1,4 ms.

Non mi ha sorpreso, invece, la costanza dei tempi di elaborazione se non si cambia modo operativo.

C'è da dire che questa CPU (6ES7212 1BD30-0XB0 - Firmware 2.2) è stata sostituita con un nuovo modello (6ES7 212-1BE31-0XB0 - Firmware 3.0), molto più performante.

Secondo quanto indicato da Siemens, i tempi per eseguire operazioni booleane, con interi e in virgola mobile della CPU della prova sono rispettivamente di 0.1, 12 e 18 microsecondi.

Con la nuova CPU questi tempi diventano 0.085, 1.7 e 2.5 microsecondi, ovvero, per quanto riguarda i calcoli, ben 7 volte più veloce.

Essendo che i calcoli sono la parte principale di una funzione PID, penso sia ragionevole supporre che, con la nuova CPU, il tempo per l'elaborazione di un PID dovrebbe scendere a meno di 0.5 ms.

Dimenticavo...

Ora vi saluto perché devo andare a stappare, per farla respirare un po', una magnum di Summus del 2000 della cantina Banfi

Modificato: 14 gennaio 2013 da batta

[Giuseppe Signorella]

Ora vi saluto perché devo andare a stappare, per farla respirare un po', una magnum di Summus del 2000 della cantina Banfi

Per fortuna le prove sul PID le hai fatte prima............. Altrimenti la proporzionale, l'integrale e la derivata si miscelavano tra di loro......

Ti ho mandato un MP

Modificato: 14 gennaio 2013 da Giuseppe Signorella

[Livio Orsini]

Ora vi saluto perché devo andare a stappare, per farla respirare un po', una magnum di Summus del 2000 della cantina Banfi

Ma questa è pubblicità spudorata!

[batta]

(Quasi) Certamente misurerai un tempo di esecuzione costante. Se le prestazioni di queste CPU sono quelle che appaiono sulla carta eventuali variazioni di tempi di esecuzione si dovrebbero aggirare nell'ordine della decina o, al più di qualche decina di microsecondi.

Se vogliamo analizzare la questione da un punto di vista puramente teorico, non possiamo trascurare che anche l'interrupt a tempo non è preciso in modo assoluto. E questo causa jitter, ed è assolutamente impossibile eliminarlo.

In pratica però, quando un errore è così piccolo da non causare nessun tipo di problema, ci si può permettere il lusso di far finta che non esista. E questo è quello che avviene sempre nel mondo reale, in qualsiasi campo, in qualsiasi applicazione, dato che la precisione assoluta non esiste.

Come si fa a decidere se un errore è trascurabile? Io direi che, quando non riesco a percepirne gli effetti, lo posso trascurare.

L'errore causato dalla mancata perfezione del tempo di campionamento si ripercuote sull'uscita con scostamenti dal valore ottimale che hanno frequenza pari a quella di campionamento del PID.

In un sistema come quello in oggetto l'uscita del PID andrà ad agire su un attuatore. Se questo attuatore è una valvola modulante, probabilmente non riesce a seguire le variazioni di segnale in tempo reale e sarà l'attuatore stesso a fare da primo filtro. Se il controllo è fatto in PWM, già parliamo di una regolazione di tipo ON/OFF, possibile solo perché sarà l'inerzia termica del sistema a fare da filtro, ed anche il fatto che un ciclo possa tenere alta l'uscita per un tempo leggermente superiore a quello teorico ottimale, e il ciclo successivo si comporti invece al contrario, risulta irrilevante ai fini pratici.

Inoltre, l'errore maggiore si ha quando siamo lontani dal set point, il PID attiva l'uscita per avvicinarsi rapidamente al set point, e la variabile di processo varia rapidamente. Siamo però ancora in una situazione di messa a regime del sistema. Un eventuale estrusore medicale non sarebbe in produzione.

Quando siamo a regime, con la variabile di processo che oscilla lentamente intorno al set point, il fatto di rilevare la temperatura con un piccolo errore temporale, porta a rilevare un valore che si scosta di pochissimo da quello esatto. Anche l'errore sull'uscita sarà quindi piccolo.

L'effetto del jitter infatti, oltre che alla frequenza di campionamento del PID, è legato alla rapidità con cui varia il segnale (variabile di processo nel nostro caso). Se la variabile di processo è stabile, anche se campiono nel momento sbagliato leggo un valore che è esattamente uguale al valore nel momento esatto e, quindi, di fatto, non commetto nessun errore.

Per rendersi conto poi se il jitter presente (e, a livello teorico è sempre presente) sia trascurabile o meno, basta guardare come varia l'uscita del PID. Se non si notano irregolarità con frequenza pari alla frequenza di campionamento del PID, significa che è trascurabile.

P.S. Il Summus vecchio di 12 anni si è conservato benissimo. Ha avuto completa approvazione anche da un amico sommelier presente alla degustazione

Modificato: 15 gennaio 2013 da batta

[Livio Orsini]

Se vogliamo analizzare la questione da un punto di vista puramente teorico, non possiamo trascurare che anche l'interrupt a tempo non è preciso in modo assoluto.

Infatti scrivevo, nel #62:

L'unico jitter è quello dovuto all'imprecisione del timer ed alla latenza dell'interrupt. Ma questo è impossibile da eliminare.

Per rendersi conto poi se il jitter presente (e, a livello teorico è sempre presente) sia trascurabile o meno, basta guardare come varia l'uscita del PID. Se non si notano irregolarità con frequenza pari alla frequenza di campionamento del PID, significa che è trascurabile.

No. Il sistema è molto più complesso. Puoi anche non notare rumore sull'uscita del regolotare, perchè è mascherato da un'ottimizzazione blanda dei parametri.

C'è poi da osservare che un regolatore che sta lavorando bene in un sistema reale, non simulato, avrà continue piccole variazioni in uscita, conseguenza della compensazione proporzionale alle piccole variazioni della variabile controllata. Un sistema "fermo" deve subito far sospettare che c'è qualche problema nascosto.

Per similitudine. Se si controlla la posizione di un ballerino durante una fase di lavoro a velocità stazionaria si devono osservare piccole oscillazioni nell'intorno del punto di lavoro. Un ballerino "inchiodato" è un indicatore di ballerino molto inerte e di un sistema di controllo lento a reagire.

Comunque la trattazione di un problema molto complesso, come quello del jitter, non può essere esaurita nelle ristrettezze di alcuni messaggi di aun discussione sul forum.

Da ultimo, come ho scritto in precedenza, essendo possibile senza aggravi e complicazioni, eliminare il jitter dovuto ai tempi di elaborazione non vedo perchè debba trascurare di farlo.

Modificato: 15 gennaio 2013 da Livio Orsini

[batta]

Ho provato a simulare cosa capiterebbe nella seguente situazione:

Controllo di temperatura PI con:

Gain = 50

TI = 1 s

Tempo di campionamento = 100 ms

Ipotizzo di partire da una situazione di equilibrio e, all'improvviso, la temperatura inizia a variare con un gradiente di 1 °C/s.

Ho creato la curva di quella che sarebbe la variazione dell'uscita del PID nel caso di campionamenti effettuati esattamente a 100 ms, e con campionamenti con errori di ben ± 5 ms.

Siamo dunque in una situazione molto spinta, che non rappresenta, in realtà, nessun controllo di temperatura reale.

Abbiamo infatti un gradiente molto alto, un guadagno esagerato, un tempo integrale brevissimo e un errore nel tempo di campionamento enorme.

Non si può quindi parlare di simulazione in condizioni addomesticate per filtrare gli errori.

Il risultato della simulazione è quello che si vede di seguito:

Del resto, per quanto riguarda la parte proporzionale, che il tempo di campionamento sia o meno costante è ininfluente. Ad ogni ciclo, che il campionamento avvenga o meno nell'istante esatto, il proporzionale si occupa di correggere quello che è l'errore in quel preciso istante.

Un piccolo errore viene commesso solo sul calcolo dell'integrale, che si basa sul presupposto errato di aver letto la variabile di processo nel momento esatto.

Direi che, dopo questa piccola simulazione, la mia sorpresa è nel constatare che un tempo di campionamento non costante porta ad errori molto più piccoli di quelli che mi sarei aspettato.

essendo possibile senza aggravi e complicazioni, eliminare il jitter dovuto ai tempi di elaborazione non vedo perchè debba trascurare di farlo.

Se la mia simulazione è corretta, non si tratta quindi di fare o non fare qualcosa per eliminare il jitter, ma di fare o non fare qualcosa per eliminare un errore che non c'è.

Mi viene da pensare che l'accuratezza nel tempo di campionamento sia fondamentale per digitalizzare un segnale analogico, ma non per un PID.

Tengo a precisare che tutto questo non è per sostenere a spada tratta la mia tesi, ma solo per capire esattamente cosa succede.

Quindi, se ho sbagliato qualcosa, attendo solo che mi si faccia capire dove ho sbagliato.

Modificato: 16 gennaio 2013 da batta

[Livio Orsini]

E' la tua simulazione che non è sigificativa per lo studio del problema.

Un simulatore corretto modellizza esattamente il processo. Solo in questo caso si può parlare di simulazione.

Tanto per fare un esempio. Io uso alcunui programmi di simulazione per circuiti analogici. In quei programmi ogni componente attivo e passivo è perfettamente modellizzato e, ad ogni passo di simulazione, il pc risolve tutte le equazioni dei modelli dei componenti inserendo in ognua le variabili relatave all'evolversi del processo.

Per fare qualche cosa di accettabile avresti dovuto effettuare una simulazione con un programma specializzato come, ad esempio, simulink di mathlab. Se inserisci correttamente i parametri e definisci esattamente i vari blocchi, allora ottieni un risultato che approssima veramente il processo reale.

Peccato, si fa per dire, che uno dei punti fermi di simulink, ma anche di altri programmi, sia proprio ilperiodo di campionamento. Bisogna proprio inserire un disturbo apposito per simulare le condizioni di jitter.

Con la tua simulazione anche se il tempo di campionamento variasse del 20% ad ogni ciclo non noteresti nessuna anomalia, quindi potresti dedurne che la costanza del tempo di campionamento è ininfluente, anzi potresti dedurne che il campionamento potrebbe essere eseguito in modo quasi casuale.

Del resto lo affermi anche quando scrivi: "Del resto, per quanto riguarda la parte proporzionale, che il tempo di campionamento sia o meno costante è ininfluente." Cosa che non assolutamente vera, o almeno può essere mascherata se il guadagno proporzionale è molto basso rispetto all'ottimo o se il periodo di campionamento è molto piccolo rispetto al tempo di evoluzione della variabile.

Quindi, se ho sbagliato qualcosa, attendo solo che mi si faccia capire dove ho sbagliato.

Purtroppo c'è un modo solo per capirlo: studiare la teoria dei controlli discretizzati, e questo non può essere fatto nelle poche righe di un messaggio.

Se riesco a ripescare una serie di vecchi articoli di EDN (risalgono alla fine degli anni '70) sui fondamenti della regolazione quantizzata li scannerizzo e te li invio volentieri; pur essendo abbastanza pratici sono molto ben fatti e hanno anche degli esempi modellizzati in Basic per simulare dei semplici regolatori. ovvio che il tutto era dimensionato per i mezzi di allora.

Modificato: 16 gennaio 2013 da Livio Orsini

[batta]

Se riesco a ripescare una serie di vecchi articoli di EDN (risalgono alla fine degli anni '70) sui fondamenti della regolazione quantizzata li scannerizzo e te li invio volentieri;

Ti ringrazio in anticipo, anche nel caso non riuscissi a trovarli.

Però c'è sempre una cosa che mi lascia perplesso: nella mia simulazione io non ho fatto altro che riprodurre esattamente quello che avrebbe fatto un controllo PID in un PLC. Perché non dovrebbe quindi andare così anche nella realtà?

Del resto lo affermi anche quando scrivi: "Del resto, per quanto riguarda la parte proporzionale, che il tempo di campionamento sia o meno costante è ininfluente." Cosa che non assolutamente vera, o almeno può essere mascherata se il guadagno proporzionale è molto basso rispetto all'ottimo o se il periodo di campionamento è molto piccolo rispetto al tempo di evoluzione della variabile.

Secondo me è importante che sia vera la seconda condizione: periodo di campionamento molto piccolo rispetto al tempo di evoluzione della variabile.

In un controllo PID fatto con un PLC, direi che questo è sempre vero. Si sarà sempre lontani di alcuni ordini di grandezza dalla situazione, per esempio, di un CD audio dove si riproducono frequenza prossime ai 20 kHz campionate a 44.1 kHz.

[Livio Orsini]

Sono un po' di fretta quindi sarò sintetico

Batta devi esaminare la funzione di trasferimento del regolatore.

Se il regolatore fosse puramente proporzionale potrebbe anche essere vera, con alcune approssimazioni, la condizione dell'ininfluenza della variazione del periodo di campionamento e aggiornamento.

Nel caso di un regolatore con almeno 2 componenti non è assolutamente proponibile.

La funzione di trasferimento di un regolatore PID canonico e campionato è:

U_z/E_z = [(K_i T² +K_d +2K_p T)z² + ((K_i T² - 2K_p T - 4K_d )z +2K_d ] / [2Tz(z-1)]

Come vedi il tempo di campionamento, e la sua costanza, incide eccome.

Sono anni, anzi decenni, che rivedo la teoria dei controlli discreti quindi sono un poco arrugginito, però i fondamenti sono ancora ben chiari. Certe cose non te le dimentichi.

Secondo me è importante che sia vera la seconda condizione: periodo di campionamento molto piccolo rispetto al tempo di evoluzione della variabile.

In un controllo PID fatto con un PLC, direi che questo è sempre vero.

Anche questa è una semplificazione un po' troppo semplicistica.

Un po' come quella degli "apprendisti stregoni" (definizione non mia ma dek Katz) che assumento che il tempo di campionamento fosse trascurabile rispetto all'evolvere della variabile consideravano una regoalzione quantizzata alla stregua di una regolazione continua, analizzando il tutto nel dominio di "s" in luogo del dominio di "z". Peccato che non considerassero il limite di quantizzazione dei convertitori A/D e D/A, gli errori dovuti alla precisione finita dell'aritmentica e gli errori dovuti alla precisione finita dei regolatori. Poi si deve anche considerare la propagazione dell'errore nel sistema di controllo che è influenzato dall'errore del tempo di campionamento.

In una delle mie prime applicazioni di controllo totalmente discretizzato ( si trattava di u a regolazione ad albero elettrico a rapporti variabili, anno 1983) dovetti toccare con mano l'influenza del limite di quantizzazione del D/A. Il periodo di campionamento era pari a 30 ms.

Non riuscivo ad andare oltre un certo limite di stabilizzazione del motore asservito. Dopo aver considerato tutte le possiibli fonti di disturbo ed averle escluse, il collega anziano con cui stavo confrontando il ragionamento (un ottimo tecnico padre di numerosi covertitori a SCR) mi fece notare che, a suo giudizoio, il guadagno era troppo elelvato. Questo guadagno elevato era dovuto alla quantizzazione minima pari 4.88 mv, produceva una variazione di velocità, che integrata per il periodo di campionamento, dava luogo ad una variazione di fase troppo grande. Il controllo era solo in proprozionale.

Aggiunsi in somma un secondo D/A con guadagno 1/10, cioè il fondo scala quantizzato su 2048 passi era pari ad 1 volt, e riuscii a stabilizzare il controllo senza difficoltà.

Modificato: 17 gennaio 2013 da Livio Orsini

[batta]

Come vedi il tempo di campionamento, e la sua costanza, incide eccome.

Non ho mai messo in dubbio la teoria, come non ho mai messo in dubbio che incida.

Si tratta solo di capire quanto incida.

Non dobbiamo dimenticare che, almeno io, sto parlando di un controllo di temperatura, non di un asse elettrico.

L'unica cosa che hanno in comune è che da qualche parte c'è un controllo PID. Per tutto il resto, vista l'enorme differenza tra tempi di campionamento, guadagni, errori, velocità di variazione della grandezza fisica da controllare e velocità di risposta del sistema, sono entità che vivono su pianeti diversi.

Per quanto riguarda la mia banalissima simulazione poi, per definire se si possa considerare realistica o meno, dobbiamo pensare al tipo di applicazione che ho cercato, pur in modo approssimato, di replicare.

La mia simulazione non tiene contro dell'effetto della regolazione. Un piccolo errore quindi sul segnale di comando, non mi causa nessun effetto.

Però non possiamo dimenticare che non stiamo parlando di un asse elettrico. In un asse elettrico ogni singola regolazione del PID ha un effetto immediato sul sistema e, quindi, ogni singolo errore porta ad una regolazione sbagliata. Se a questo aggiungiamo un guadagno elevato, ecco che risulta evidente come sia impossibile fare un asse elettrico con errori nei tempi di campionamento.

In un controllo di temperatura però, l'effetto si sentirà dopo un numero elevato di elaborazioni del PID.

Per un controllo di temperatura, siamo in una condizione in cui affermare che "assumento che il tempo di campionamento fosse trascurabile rispetto all'evolvere della variabile consideravano una regoalzione quantizzata alla stregua di una regolazione continua", non è roba da apprendisti stregoni, ma solo buonsenso.

Anche il discorso della "quantizzazione dei convertitori A/D e D/A" in un controllo di temperatura è trascurabile almeno nel 99,99 % delle applicazioni. Un controllo di temperatura, nella maggior parte dei casi, lo potrei fare con un'uscita analogica da soli 8 bit.

A me la teoria è sempre piaciuta, e ho sempre cercato di affrontare i problemi pratici partendo dall'applicazione della teoria.

Ma ritengo che non sia assolutamente in contrasto con la teoria affermare che, in un controllo in cui i campionamenti sono molto elevati rispetto alla variazione della grandezza da regolare e dove l'effetto della regolazione si avverte dopo un numero elevato di campionamenti, la precisione assoluta sul tempo di campionamento non sia di importanza vitale.

È un po' come se usassimo il campionamento a 44.1 kHz del CD audio per riprodurre frequenze massime di 100 Hz. Gli attuali problemi di jitter sarebbero comunque presenti, ma impossibili da percepire.

Modificato: 18 gennaio 2013 da batta