Richiamo Db Istanza Per Pid

[martino69]

Buongiorno a tutti!

Devo gestire 16 zone di controllo della temperatura tramite un sistema multiplexer, dove vado ad interrogare una zona ogni 2 secondi.

Per il controllo della temperatura pensavo di richiamare un unico PID all’interno di un FC e di utilizzare come DB di istanza una variabile di INPUT del FC stesso, ma non riesco a trovare il formato corretto, ho sempre l’errore che potete vedere nello screenshot cliccando il seguente link:

Qualcuno ha un idea di come potrei fare senza dover scrivere 16 PID?

[walterword]

se usi un unico pid rischi di fare un pasticcio colossale

in teoria dovresti salvare e ricaricare tutte le variabili , i parametri , le uscite , i setpoin ect , di ogni processo ogni votla che devi eseguire l'algoritmo .Potresti provare con SCL o puntatori e salvare i dati da e su tabella pero ricorda che i dati sono mantenuti statici dai db di istanza e non da db globali .

PEr avere un unico DB devi richiamare tante volte FB del pid quante ti serve e all'interno di un FB e creare il db di istanza che contiene tutte le istanze degli FB dei vari pid .

E' meglio richiamare un blocco PID per ogni processo che avere un blocco solo per tanti processi , il tempo a caricare e salvare tutti i dati alla fine ti costa in termini di tempo di piu che eseguire tanti blocchi pid

Io ultimamente ne ho richiamati 13 in un blocco FC , ogni pid col suo db di istanza visualizzabile esternamente .Se devi fare modifiche o ricreare l'istanza di un pid lo fai solo per uno e non per tutti , quando l'impianto e' in moto e' molto rischioso azzerare i dati e i parametri di processo per ricreare tuttu i db

[martino69]

Infatti, non era mia intenzione utilizzare un unico DB di istanza.

Volevo creare un FC unico in cui, oltre al FB del PID, inserire anche altri segmenti con vari controlli (sovratemperatura, sottotemperatura, correzione sonda ecc.), e nell'interfaccia del blocco mettere una variabile di input (es. NR_DB).

In questo modo quando andrò a richiamare il mio FC potrò inserire un DB di istanza diverso per ogni zona, il problema è che non riesco a trovare una variabile adatta.

[walterword]

il pid per funzionare bene lo devi inserire in OB35 a tempo , e presettare il tempo di interrupt nel hardware

Il tempo di campionamento passato come parametro ai pid deve coincidere col tempo di richiamo del OB35 .

L'algoritmo pid , proporzionale , integrale , derivativo deve lavorare su richiamo costante perche il tempo tra una chiamata e l'altra e' in realtà la base dei rettangoli la cui area sommata ti da l'integrale

La componente derivativa non e' proprio la derivata nel senso del termine analitico in quanto non si puo' far tendere il tempo di campionamento a zero , infatti e' settato uguale al tempo di richiamo dell'interrupt , per cui e' un calcolo derivativo inteso come rapporto incrementale tra la variazione della grandezza da controllare (errore) rispetto al tempo , che e' il tempo di richiamo .

La regolazione nei sistemi digitali come il plc non e' tempo continuo , bensi' a tempo discreto

Giusto , cosi , per farti capire 2 cose molto importanti sulla teoria che se non vengono rispettate rischi di mettere in piedi un pid che diventa una ciofeca ....

Ricorda , il pid lo devi sempre richiamare da un OB a interruzione , per questo scopo ci sono gli OB35 e il tempo e' di solito 100mS se devi regolare temperature

Per quanto riguarda i parametri devi vedere bene come sono normalizzati rispetto alla variabile di processo da controllare e da come risponde il sistema da controllare

Per evitare di appesantire lo stack delle chiamate puoi fare cosi , io faccio cosi di solito , preparo un OB35 a 100mS e poi dentro richiamo gli FB41 con relativi DB di istanza "separati " ....

I controlli , le copie e i salvataggi nonche le correzioni dei parametri falli fuori , in un FC richiamato ad ogni ciclo

Lascia nel OB35 solo quello che deve essere processato rigorosamente nel tempo prestabilito , le altre logiche le fai in un FC di gestione della macchina o del pezzo di macchina che gestisce il tal controllo

Modificato: 18 marzo 2015 da walterword

[Lucky67]

Concordo con il modus operandi di walterworld. In fase di debugging poi, avere un solo blocco che gestisce tutto n volte rischia veramente di essere una roba da mal di testa colossale!!!

[martino69]

Capisco e concordo con il tuo ragionamento..

Però come hardware ho solo 1 ingresso per termocoppie e tramite relè richiamati a tempo vado a scansionare una termocoppia alla volta.

Questo sistema lo utilizzo già su S7 300, ovviamente i tempi di campionamento si aggirano sui 16-20 secondi (1 sec x 16 zone), ma utilizzando solo le componenti P e I del PID e avendo processi molto lenti e poco influenzati da fattori esterni, riesco ad ottenere buoni risultati.

[walterword]

ti conviene fare un multiplexer sull'ingresso ed avere n PID quanti sono i processi .Pero bisogna vedere i tempi di risposta al transitorio , cioe quanto tempo ci vuole prima che il segnale sia buono da mandare al pid , copairlo , processarlo nel pid e poi selezionarne un altro

Che lavori che ti fanno fare.....con i rele non so come possa venire .....

[martino69]

Infatti, non è il massimo ma il cliente è contento così.

Grazie per i tuoi consigli..

[Giuseppe Signorella]

Il cliente sarà anche contento, (anche se credo che non abbia ben capito cosa stia facendo) ma fare un lavoro del genere è alquanto poco professionale.

Inoltre se prendi in considerazione l'elevato numero di inserzioni che faranno i relè,

(1 sec x 16 zone)

ti rendi conto che sarà una macchina e/o applicazione che richiederà una assidua manutenzione con una elevata casistica di guasto.

Modificato: 19 marzo 2015 da Giuseppe Signorella

[walterword]

questo progetto rientra nell'insieme dei progetti che funzionano cosi :

- Il cliente e' folle che non sa quello che dice e quello che vuole , convinto di fare la scoperta del secolo e di ricavare ingenti guadagni , sicuramente sperperando risorse su altre parti della macchina

- Il progettista o esecutore della parte automazione e' abbagliato dalla solita storia che se la macchina funziona poi ce ne sono altre milioni gia pronte da fare , per cui non bada a quello che sta facendo

- Il progetto sarà un fallimento

- Si tenterà di aggiungere un ingresso o due o comunque di apportare modifiche inutili

- Il committente non pagherà

- Chi esegue l'automazione subirà perdite

- Il costo del progetto supererà il costo effettivo di una "normale" automazione

- La macchina non sarà manutenuta perchè non funzionerà mai

Bisogna essere in grado di gestire i progetti ed in questi casi di lasciarli perdere perche sono solo fallimenti

Un po come quelli che volevano realizzare macchine di riscaldamento e raffreddamento degli stampi delle presse a iniezione mettendo una sola termocoppia sul tubo di mandata del riscaldamento .....solo problemi , ignoranza , arroganza e perdita di soldi -tempo

Lascia perdere finche sei in tempo

Modificato: 19 marzo 2015 da walterword

[martino69]

@ giuseppe

Quote

Inoltre se prendi in considerazione l'elevato numero di inserzioni che faranno i relè,
(1 sec x 16 zone)
ti rendi conto che sarà una macchina e/o applicazione che richiederà una assidua manutenzione con una elevata casistica di guasto.

Un rele che lavora per 1 secondo ogni 16 secondi significa che si chiude 3.75 volte/minuto = 225 volte/ora = 5.400 volte/giorno = 1.890.000 manovre anno se rimane acceso 24 ore su 24 e 365 gg/anno!

Quindi nella peggiore delle ipotesi si dovrebbero cambiare 16 rele ogni 2 anni, non mi sembra assolutamente una manutenzione eccessiva.

@ waltterword

Può darsi vada come dici tu, ma il cliente utilizza questo sistema nei suoi impianti dal 1994, e ti assicuro che ne ha venduti, e ne vende tuttora, centinaia in tutto il mondo.

[walterword]

probabilmente usava multiplexer C-MOS e non rele' comunque chiedi al cliente di farti vedere un impianto che funziona con queste specifiche perche per la mia poca esperienza nel settore mi sembra una cosa fuori da ogni logica .

Se fa queste macchine dal 1994 avrà sicuramente i disegni del progetto elettromeccanico , il software , i video , gli apprezzamenti dei clienti ect ect ect . Tutte informazioni utili per il tuo sviluppo , non credi?

I rele' soffrono del difetto di impastarsi spesso soprattutto se sollecitati con frequenze elevate e la tua applicazione implica frequenze elevate di lavoro per un rele' .Un rele' ha dei tempi di latenza , per cui anche se dal plc butti fuori un treno di impulsi per attivarlo , i suoi limiti meccanici sono quelli che sono .Un rele' implica disturbi sul segnale .Nel sw devi filtrare la lettura di ogni sensore in modo tale da essere sicuro che la stai prendendo a regime e non in transitorio ....poi fai la copia nel blocco pid dopo aver salvato i dati su cui il pid stava lavorando , poi chiudi un altro rele ed apri il penultimo e via cosi ....io dico può darsi con una elevata percentuale statistica di fallimento .Ovviamente nulla di personale .

ricordo che tempo fa in arabia i cinesi usavano un sistema multiplxer per gestire ingressi ed uscite e dopo pochi giorni erano a piedi .Qualcun altro ho visto fare che multiplexava gli ingressi analogici di alcuni sensori di posizione per una calandra , durato poco anche lui ....ah di questi due esempi poi ho rifatto tutto come dicevo io anzi come dicono le regole , l'esperienza e la normalità , sia chiaro

[Giuseppe Signorella]

Quindi nella peggiore delle ipotesi si dovrebbero cambiare 16 rele ogni 2 anni, non mi sembra assolutamente una manutenzione eccessiva.

Questo dipende da quante macchine metti in circolazione. Se sono molte, avrai guasti e/o fermi impianti quasi quotidianamente (ovviamente su macchine differenti).

Forse abbiamo due modi differenti di valutare la cosa.

* In genere le aziende quando constatano che vi sono anomalie ricorrenti (che si ripetono su tutte le macchine in modo sistematico) adottano delle azioni correttive per prevenire che accada ciò. Non le creano a priori.

* Un buon software, tiene in considerazione anche della perdita del sensore, (nel tuo caso della termocoppia), inserendo nella diagnostica e/o nel buffer degli allarmi. Nel tuo caso non riesco proprio a capire come si possa gestire ciò in quanto in 16 secondi la scolleghi altrettante volte.

* Infine analizzando la cosa sotto l'aspetto economico non ne vedo un grande vantaggio. Per gestire un sistema del genere ti servono altre 16 uscite sul PLC, 16 relè con relativo zoccolo, maggiore spazio nel quadro, un alimentatore più grande, maggiore tempo di cablaggio. (quindi manodopera) che è la cosa che incide maggiormente.

Non prenderla come una critica, sono solo punti di vista.

Modificato: 20 marzo 2015 da Giuseppe Signorella

[acquaman]

Senza usare dei relè, esistono anche dei multiplexer per ingressi analogici, a me è capitato di usarli, con un solo ingresso analogico e 3 ingressi digitali acquisivo 6-8 valori.

[batta]

Multiplexare gli ingressi analogici non piace nemmeno a me ma, per favore, non arriviamo a dire che per un relè è un problema commutare una volta ogni 16 secondi.

Questa non è assolutamente una frequenza elevata.

Casomai, quello che un po' mi lascia perplesso, è il far passare i segnali di una termocoppia dai contatti di un relè.

Per quanto riguarda i costi, sono d'accordo con Giuseppe: qualcosa forse si risparmia, ma non così tanto come potrebbe sembrare.

E il risparmio va a scapito della funzionalità: maggior ingombro nel quadro e più cablaggi, software più complesso, tempi di lettura lenti e, probabilmente, errori nella misura per il passaggio dai contatti dei relè.

Forse poteva essere conveniente nel 1994, quando il costo degli ingressi analogici era importante.

Ma non è detto che quello che era valido nel 1994 sia valido ancora oggi.

Modificato: 21 marzo 2015 da batta

[Giuseppe Signorella]

per favore, non arriviamo a dire che per un relè è un problema commutare una volta ogni 16 secondi.

Questa non è assolutamente una frequenza elevata.

Batta, Infatti non è un problema.

I relè sono in grado di supportare commutazioni con una frequenza anche decisamente superiore. (Tipo una commutazione ogni secondo o anche meno senza alcun problema ed anche per lunghi periodi)

Si faceva riferimento ad una ipotetica e probabile casistica di guasti proiettata in un arco di tempo.

E' insindacabile che la vita di un organo meccanico di questa tipologia (relè, pulsanti, interruttori ecc) si misura sul numero di inserzioni (medie) che sono in grado di sopportare. Maggiore è il loro numero di inserzioni in un arco temporale X, e prima raggiungono il limite.

Poi tutto come detto in precedenza dipende dai punti di vista.

C'è chi pensa che se una macchina raggiunge i due anni di vita (periodo di copertura della garanzia) senza alcun problema, ha raggiunto un traguardo, e chi pensa che tale traguardo si raggiunga dopo i 5 anni o addirittura dopo 10.

Modificato: 21 marzo 2015 da Giuseppe Signorella

[walterword]

Devo gestire 16 zone di controllo della temperatura tramite un sistema multiplexer, dove vado ad interrogare una zona ogni 2 secondi.

quindi secondo voi e' normale fare una regolazione PID con lettura di ogni parametro ogni 16 sec.

bo magari si tratta di regolare la temperatura di grosse vasche dove si puoo' richiamare il pid di ogni processo ogni 16 sec e comunque ci sono i multiplexer C-MOS per fare questi lavori

Con 4 uscite selezioni uno tra i 16 canali , 2^4=16 e sono ancora meno di 16 uscite una per ogni canale