Invertire Azione Uscita Pid

[Gapo]

Scrivere una variabile prima o dopo averla usata ci dovrebbe essere solo un ritardo di un ciclo, al massimo prende il valore vecchio di un ciclo.

NO: se parli di variabili temporanee il loro valore non viene mantenuto tra un ciclo e l'altro... non a caso si chiamano "temporanee"...

Leggere il valore di una variabile temporanea "prima" di scriverlo non significa leggere il valore che aveva al ciclo precedente, ma significa leggere il valore di una locazione di memoria libera e indefinita fino al richiamo della FC o FB: può esserci scritta qualsiasi cosa, e la riprova ce l'hai in quello che hai raccontato tu stesso.

Non voglio "bacchettare", ma è un errore molto grave, e non scherzo quando dico che ho visto gente fare grossi danni in questo modo...

[Mauro_lab]

ecco appunto, mi rendo conto del grave errore commesso

e come ho detto in precedenza ricorro alla maker.

sono solo due PID che hanno una funzione inversa, pertanto non è oneroso usare due maker.

[batta]

e come ho detto in precedenza ricorro alla maker.

Questa è una soluzione.

Non capisco però perché semplicemente non sposti le istruzioni dove inverti il guadagno appena prima del richiamo di FB41 e mantieni l'utilizzo della variabile locale.

Viste le dimensioni dell'impianto, sicuramente stai usando una cpu di un certo livello, con elevato numero di merker.

Di solito però non si "sprecano" merker per operazioni di questo tipo.

Le variabili locali sono comodissime anche per questo.

Riguardo la ritenzione, solo tu conosci l'impianto. Se dici che è corretto azzerare i parametri, non trovo nulla da obiettare.

Prima di questa modifica però mi pare di aver capito che i supervisori scrivevano il guadagno direttamente nel DB di istanza di FB41. Il dato quindi era ritentivo.

Di solito comunque si utilizzano lo stesso variabili di DB e si inizializzano i dati in OB100.

Tieni presente che far ripartire un PID con guadagno zero può essere pericoloso, perché alla ripartenza succede quanto segue:

- la parte proporzionale (LMN_P) è zero.

- la parte integrale (LMN_I) rimane congelata al valore che aveva al momento dello spegnimento. Con guadagno zero infatti, non viene più modificata.

- l'uscita del PID (LMN) rimane quindi congelata al valore attuale raggiunto dall'integrale (LMN_I)

Se segui quindi la strada della ripartenza con guadagno azzerato, non dimenticarti di effettuare anche altri controlli sul PID e sulla sua uscita.

[batta]

Altro modo per invertire il segno del guadagno.

Se hai modificato la variabile dove vanno a scrivere i supervisori, significa che hai libero accesso anche alla loro programmazione.

Una soluzione poteva essere quella di effettuare l'inversione direttamente nei supervisori, tramite scalatura.

In questo modo, l'operatore vede un guadagno positivo, ma il supervisore scrive nel DB il corrispondente valore negativo.

[Mauro_lab]

In effetti ho fatto cosi, ho preso la variabile di inserimento guadagno e uso una var_tamp poco prima della funzione di PID

Pertanto il supervisore mette un guadagno positivo e poi viene invertito prima di darlo al PID sembra quasi facile

Il fatto dell'azzeramento oltre ad azzerare la variabile di guadagno azzera anche i limiti di uscita LMN_HLM e LMN_LLM pertanto le uscite sono nulle e costringo il supervisore a verificare i parametri prima di inserire il PID

Sprecare Maker, è sempre un delitto anche se avanzano.....

Volendo fare accademina ci sono molti altri modi per invertire un valore, mi basta uno che funziona