Esempi Progetti Ladder per Omron

[_gian]

Posso sbagliarmi ma a me pare che, contrariamente a quanto avviene nel settore maker ( Arduino, Raspberry. etc), in campo PLC non esiste una piattaforma open source dove scambiare idee, librerie e programmi reali pronti all'uso a customizzabili con facilità.  

 

Ed é appunto per questo motivo che mi piacerebbe condividere a solo scopo didattico e quindi gratuitamente e senza impegno, senza vincoli di alcun tipo e senza nessuna garanzia di buon funzionamento ( un poco come avviene per i progetti Open Source/ Creative Common)  programmi PLC/HMI implementati in impianti reali in ambito ingegneria di processo.

 

A scanso di equivoci ribadisco il fatto che si tratti esclusivamente di automazione di processo ( in continuo o batch) dove non ci sono parti in  movimento, bracci meccanici, nastri trasportatori od utensili che possano causare rischi per l'operatore in caso di errore del sistema di controllo.

 

Nel processo infatti si lavora tipicamente su sonde di livello flusso e temperatura, elettrovalvole di flusso e di dosaggio e pompe sommerse, agitatori a basso numero di giri  e poco altro ancora quindi niente di particolarmente rischioso per l'operatore che fra l'altro di solito opera da remoto. 

 

E' importante però che siano progetti realmente implementati od implementabili ( anche se obsoleti, incompleti e non ottimizzati): di esempi tratti da corsi o da tutorial c'è fin troppa abbondanza!   

 

Al momento dispongo di una mezza dozzina di programmi di questo tipo ma conto di aggiungerne e condividerne molti altri con la collaborazione degli utenti del forum se la cosa interessa e dovesse andare avanti.

 

Personalmente preferisco progetti su base CX Programmer e CX Designer quindi sorgenti .cxp .ipp ma anche altri vendor vanno bene. 

 

Cosa ne pensate?

Modificato: 9 dicembre 2021 da _gian

[Ctec]

Non credo sia facile. Tutti i costruttori di macchine e impianti hanno una forma di copyright su quanto prodotto, anche software. Anche io, che consegno copia di backup dei miei programmi al cliente finale per archivio (sarebbe dovuto, ma tantissimi non lo fanno), mi sono ritrovato con interi o parti di programma rubati e scopiazzati, spesso con i miei commenti originali...

Infatti si può constatare la cosa dalla mole di password installate a protezione, e non per evitare manomissioni, ma proprio per evitare che si rubi il know-how, che oramai risiede quasi completamente nella parte software.

Bisognerebbe che il software da divulgare fosse così generico o obsoleto da risultare praticamente inutile per chi lo riceve.

Sinceramente anche io proteggo parti "delicate" dei programmi, dove ho speso sangue e sudore per la messa a punto, in FB protette, in modo da risultare delle "scatole nere" a chi eventualmente copia il tutto. E col CX non si poteva fare se non nei PLC più grossi...

Boh, l'idea non mi dispiace, in generale, mi piace trasferire le mie (misere) conoscenze agli altri. Vediamo che ne pensano anche altri del forum.

 

PS: che gli impianti di processo non siano pericolosi, è una bufala. Prova a mandare con una pompa un fluido in una condotta erroneamente chiusa, e vedrai come scoppiano le giunture. O ad aprire inavvertitamente una valvola di scarico con un vapore o un prodotto ad alta temperatura con utenti nei pressi...

[Livio Orsini]

Di questi progetti se ne sono iniziati tanti sul questo forum, ma sono sempre abortiti perchè inizialmente molti si dichiarano interessati, ma alla rese dai conti sono interessati silo a godere i frutti, non anche a portare contribuiti significativi.

Almeno questo è quanto si deduce dalla storia.

Io sarei felicissimo se questa volta fossi smentito dai fatti.

[Ctec]

9 ore fa, Yiogo ha scritto:

la chiave di tutto sta nel sapere "cosa mettere insieme"

Questo è verissimo, infatti spesso sono dovuto intervenire sui miei programmi copiati (sennò come facevo ad accorgermi che li avevano copiati...) per sistemare malfunzionamenti.

Tieni però anche conto che spesso le decisioni di bloccare e proteggere il tutto non sono del singolo programmatore/integratore, ma delle politiche aziendali di dove lavorano.

Detto questo, riprendo la mia ultima frase del mio post precedente, nonché la finale di Livio. Vediamo come va avanti.

[_gian]

Scusate una doverosa precisazione che non ho fatto e che serviva invece ad evitare confusione: 

 

"Nel processo infatti si lavora tipicamente su sonde di livello flusso e temperatura, elettrovalvole di flusso e di dosaggio e pompe sommerse, agitatori a basso numero di giri  e poco altro ancora quindi niente di particolarmente rischioso per l'operatore che fra l'altro di solito opera da remoto. "

 

In realtà mi riferivo ad impianti di trattamento dell'acqua che lavorano tipicamente a pressione atmosferica, a temperatura ambiente, e con liquidi non pericolosi (acqua appunto). Un eventuale dosaggio di prodotti chimici corrosivi o nocivi per la salute e l'ambiente  (sodio ipoclorito, antiflocculante, etc) viene di solito gestito a parte con dispositivi dedicati.

 

Per quello che riguarda la mia proposta, anche limitatamente alla sola condivisione di metodi raccomandati o deprecati, mi pare capire che in linea di principio sia stata accettata dalla comunità del forum, vediamo dunque se c'è la volontà di sviluppare la cosa oppure no.

 

Secondo me si può fare benissimo anche in ambito C&A ciò che si fa normalmente in altri settori. Faccio l'esempio delle web agency che lavorano sulla personalizzazione di CMS open source tipo Wordpress, Drupal, Joomla oppure, sul front end, prendendo un CSS già ben impostato ed adattandolo alle esigenze specifiche del cliente: sono prodotti commerciali che fanno riferimento a licenze Open Source al loro interno.
Ma non finisce certo qui: quante applicazioni MS Excel si trovano in giro che si  possono adattare per fare un pò di tutto compreso calcolo strutturale e gestione di un file system o di un database relazionale mediante VBA o Power query?

 

 

Chi aveva detto che scambiandoci una moneta avremo indietro sempre una moneta, scambiandoci delle idee avremo indietro diverse  idee? Come detto, per chi è interessato a questo scambio di idee e di competenze, l'obiettivo dovrebbe essere inquadrato in un'ottica di miglioramento professionale reciproco e non di concorrenza commerciale, dopodiché ci saranno sempre leader e gregari più o meno opportunisti ma col tempo secondo me, tutti ne trarranno dei vantaggi. 

 

Mi si passi la divagazione, ma mille anni fa quando studiavo io (e il rettore era un magnifico Massone), i professori erano molto sospettosi gli uni con gli altri e non gradivano che prendessimo appunti col registratore da sbobinare ad uso di quelli che non potevano o non volevano frequentare: essi amavano avere l'aula sempre affollata (indice di popolarità e, per alcuni, di facile accesso alle allieve più carine) ma soprattutto avevano paura del giudizio dei loro colleghi visto che una baggianata registrata su cassetta diventava subito di dominio pubblico: ora per fortuna  non funziona più così e quei professori grigi e sospettosi sono ancora lì a spiegare le guide d'onda dei radar del 1950 a studenti supinamente compiacenti, mentre  in internet si possono scaricare  interi corsi STEM ( MIT Open Courseware su tutti ).

 

Detto questo, per tornare al concreto e dare un aspetto definito alla mia idea, ho elencato una lista del tutto non esaustiva delle subroutines applicabili al caso specifico di cui sopra: 

 

Main

       Inizializzazione

       Impostazioni di sistema

       Gestione I/O Analogici 

       Gestione allarmi

       Gestione timer/calendario

       Gestione trasduttori

       Gestione HMI

       Gestione Utenze e blocchi di Utenze

       Gestione MSG

       Gestione Processo ( Pompe, Agitatori, EV, Dosaggio, etc) 

       Gestione Input ed Output

       

Fine

 

In parallelo sarebbe bello condividere informazioni utili su implementazione controllo da remoto e sicurezza tramite VPN / VNC in ottica Industria (o come si chiama ora) 4.0. 

 

[batta]

2 ore fa, _gian ha scritto:

Per quello che riguarda la mia proposta, anche limitatamente alla sola condivisione di metodi raccomandati o deprecati, mi pare capire che in linea di principio sia stata accettata dalla comunità del forum, vediamo dunque se c'è la volontà di sviluppare la cosa oppure no.

La tua proposta è lodevole, e non c'è motivo per non accettarla.
Da vedere, piuttosto, la reale utilità.
Perché dico questo?
Perché tutti i clienti vogliono cose personalizzate, ed è veramente difficile (salvo produzione in serie o impianti standardizzati) che un programma si possa adattare ad un altro impianto, presso un altro cliente, senza apportare modifiche significative.
Più utile, piuttosto, cercare di standardizzare singole routines, tipo, per esempio, la gestione di una pompa con PID regolazione pressione, o con controllo di livello.
O single routines per comandare, con bus di campo diversi, un inverter Siemens, un Danfoss, un Omron, ecc.
Ma, anche in questo caso, per esperienza personale posso affermare che è veramente difficile trovare una soluzione univoca. Io stesso, da un lavoro all'altro, se si esclude la parte di scambio dati con l'inverter, mi trovo ogni volta ad adattare il mio "blocco di gestione inverter" alle esigenze del caso.
Per esempio: cambio la velocità passando esternamente il set point, oppure imposto delle velocità predefinite da commutare con un comando? E se imposto velocità predefinite, quante me ne servono? Le rampe sono gestite dall'inverter o dal PLC? E, se sono gestite dall'inverter, sono impostate direttamente nell'inverter o devono essere modificabili da PLC?
Devo fare un controllo in velocità, un controllo in coppia o un posizionamento?
Questo per dire che, solo per comandare un inverter, non basta una singola funzione, ma dieci funzioni diverse sarebbero ancora poche.

 

Inoltre, in base alla tipologia di macchina/impianto, può essere conveniente procedere come nel tuo esempio con inizializzazione, impostazioni, gestione I/O, gestione allarmi, ecc., oppure suddividere il programma in blocchi che gestiscono una parte di macchina/impianto che hanno in pancia tutte le funzioni elencate.
Salvo impianti molto piccoli, io propendo per il secondo metodo.
Solo per fare un esempio, recentemente ho realizzato un programma di gestione di un depuratore acque. A parte controlli generali comuni, poi mi trovo con un blocco per la gestione dei serbatoi di acqua omogeneizzata, uno per le vasche trattamento acqua, uno per i sili di decantazione, e così via. Ogni singolo blocco gestisce le sue impostazioni, i sui allarmi, la sua logica di funzionamento.
Ma, anche solo per la semplice gestione di un sertbatoio, ci sono molte varianti: ci sono livelli digitali o analogici? Se sono livelli digitali, quanti ce ne sono? Se sono livelli analogici, quante soglie devo prevedere? Un eventuale allarme di livello, cosa deve fare? Di quali consensi ho bisogno per poter riempire o svuotare il serbatoio? Quanti e quali segnali mi deve fornire la funzione del serbatoio da passare ad altre parti di programma?

Dubito fortemente che uno di questi blocchi possa essere utilizzato su altri impianti senza adattamenti rilevanti.
E questo per due motivi: il primo è che difficilmente si troverà un altro impianto dove, per esempio, la sedimentazione verrà trattata nello stesso identico modo; il secondo, che so già (perché sarei io il primo a farlo 😉 ) che se qualcuno dovesse partire dal mio blocco troverà sicuramente cose che avrebbe fatto in modo diverso, e ci metterà le mani.

 

Secondo me, la cosa più utile sarebbe la condivisione di piccole routine, da prendere più come esempio, come spunto per nuove idee, piuttosto che per un utilizzo reale.
Per dire, nel tempo mi sono creato (come più o meno tutti)  la mia libreria di funzioni. Ma anche questa libreria è in continua evoluzione, perché quello che ho fatto un anno fa oggi non mi piace più, e lo modifico.

Modificato: 11 dicembre 2021 da batta

[_gian]

[max.riservo]

@_gian

Quale sarebbe l'attinenza del titolo (progetti ladder per omron) con il P&Id  che hai allegato?

Comunque esistono diversi tipi di impianti di trattamento acque / reflui, sebbene ci possano essere diversi punti in comune non è possibile generalizzarli in toto.

 

PS - Anche volendo, non potrei essere di aiuto, in quanto pur conoscendo diverse tipologie di trattamento acque io utilizzo Schneider e meno che mai utilizzo il ladder (vabbè se proprio mi obbligano magari qualcosa in ladder lo scrivo).

[_gian]

Si tratta di un impianto di depurazione delle acque di lavaggio degli ortaggi che lavora a ciclo continuo. L' acqua da trattare è caratterizzata da elevata torbidità (solidi sospesi, sabbia e residui argillosi), dalla presenza di residui di fertilizzanti ( nitriti nitrati) e di pesticidi a da residui di lavorazione sfuggiti alle griglie a monte. Lo scopo dell'impianto e di ottenere acqua trattata da scaricare in un canale irriguo rispettando i limiti di legge. Una ulteriore sezione di depurazione e di accumulo mediante filtri a sabbia/carbone e disinfezione mediante biossido di Cloro permette il riutilizzo parziale dell' acqua per l'abbeveramento di mucche e dei vitelli e per la pulizia delle stalle. Ogni blocco funzionale può essere rappresentato da una SBR PLC ed è previsto inoltre la condivisione dei dati per l'assistenza mediante tecnologia VPN / VNC. I livelli dei serbatoi e delle vasche possono essere sia digitali sia analogici, l'impianto funziona a pressione atmosferica una volta che l'acqua grezza sia stata pompata dalla vasca bassa ai serbatoi alti. L'acqua da trattare passa da un serbatoio all'altro per sfioramento e i residui vengono rimossi da valvole ad azionamento pneumatico. Una tramoggia vagliatrice permette di rimuovere parte dei residui sabbiosi dal processo. Un serbatoio alto permette di dosare i prodotti chimici necessari alla sedimentazione dei fanghi all'interno di filtri defangatori. I fanghi concentrati vengono rimossi dai filtri per caduta mediante autobotte. I filtri sabbia carbone hanno un dispositivo temporizzato di rigenerazione gestito da valvole pneumatiche. Il generatore di biossido di cloro provvede al dosaggio dei reagenti in ingresso al reattore ed al dosaggio del biossido nel flusso di processo a valle dei filtri.   Il progetto è stato implementato su Omron CP1L-E per poter utilizzare in modo nativo la connettività di rete e quindi la teleassistenza ma potrebbe girare anche su CP1E se la connettività non interessa.

 

 

Modificato: 16 dicembre 2021 da _gian

[max.riservo]

15 minuti fa, _gian ha scritto:

Si tratta di un impianto di depurazione delle acque di lavaggio degli ortaggi che lavora a ciclo continuo ...

Ti ringrazio per la sommaria spiegazione di come funziona il tuo impianto, continuo a non vedere l'attinenza con Omron e neanche con Ladder ovvero il tuo impianto può essere realizzato con qualsiasi sistema di automazione che sia superiore a Zelio/Logo (io useri un M340 ma direi che anche un 1200 Siemens dovrebbe essere all'altezza).

Piuttosto sarebbe utile capire se hai implementato delle logiche che permettano il funzionamento dell'impianto fornendo adeguata diagnostica a chi dovrà agire localmente (e/o in remoto nel limite dell'operabile).

Hai previsto misure di portata (acqua sollevata, ricircolo fanghi, eventuale acqua industriale/potabile immessa, altre) per poi poter fare un bilancio idrico?

Hai previsto misure di pH/ redox / conducibilità / torbidità / solidi sospesi per gestire il processo di trattamento?

Hai previsto l'utilizzo di strumenti che possano fornirti indicazioni sull'affidabilità della misura? Esempio : utilizzi un trasmettitore di pH con tecnologia 'antica' ovvero con elettrodo analogico e l'elettrodo (in vetro) si rompe, ottieni la misura di pH circa 7 (che in genere è il valore di pH perfetto) come ti comporti?

Come ti cauteli che l'acqua che scarichi nel canale rispetti i limiti di legge? Misuri pH / redox / clororesiduo, altro ?

E come sei certo che l'acqua che vuoi/puoi destinare all'abbeveraggio sia ugualmente nei limiti di legge?

 

[leleviola]

2 ore fa, max.riservo ha scritto:

PS - Anche volendo, non potrei essere di aiuto, in quanto pur conoscendo diverse tipologie di trattamento acque io utilizzo Schneider e meno che mai utilizzo il ladder (vabbè se proprio mi obbligano magari qualcosa in ladder lo scrivo).

Vorrei proprio capire con cosa si programma oggi giorno un PLC? Il ladder un rimasuglio del passato?

Ne ho visti diversi di programmatori che facevano largo uso di tutt altro e quando poi dovevano fare debugging a quello che avevano loro stesso programmato si trovavano in difficoltà a risolvere inconvenienti all'impianto perchè non capivano cosa succedeva e erano in difficoltà a fare debugging. Il buon classico Ladder soprattutto in queste tipologie di impianto è molto più intuitivo e facile da leggere in caso di veloce necessità per verificare problematiche agli impianti. Precisiamo il testo strutturato è utile nell'utilizzo in fase di calcoli complessi, il Ladder facilita di non poco la fase di controllo processo, quindi è bene che anch esso sia imparato dai nuovi programmatori

[max.riservo]

8 minuti fa, leleviola ha scritto:

Vorrei proprio capire con cosa si programma oggi giorno un PLC? Il ladder un rimasuglio del passato?

Ne ho visti diversi di programmatori che facevano largo uso di tutt altro e quando poi dovevano fare debugging a quello che avevano loro stesso programmato si trovavano in difficoltà a risolvere inconvenienti all'impianto perchè non capivano cosa succedeva e erano in difficoltà a fare debugging. Il buon classico Ladder soprattutto in queste tipologie di impianto è molto più intuitivo e facile da leggere in caso di veloce necessità per verificare problematiche agli impianti. Precisiamo il testo strutturato è utile nell'utilizzo in fase di calcoli complessi, il Ladder facilita di non poco la fase di controllo processo, quindi è bene che anch esso sia imparato dai nuovi programmatori

Sinceramente non mi interessa aprire una polemica su quale sia il linguaggio da utilizzare per programmare i PLC, ognuno di noi è libero di utilizzare quello che ritiene più consono per realizzare l'applicazione, secondo le sue conoscenze, le sue preferenze e quello che mette a disposizione il PLC che deve/vuole/può utilizzare ...

[Livio Orsini]

10 ore fa, max.riservo ha scritto:

Sinceramente non mi interessa aprire una polemica su quale sia il linguaggio da utilizzare per programmare i PLC, ognuno di noi è libero di utilizzare quello che ritiene più consono per realizzare l'applicazione, secondo le sue conoscenze, le sue preferenze e quello che mette a disposizione il PLC che deve/vuole/può utilizzare ...

 

Sottoscrivo tutto!

[leleviola]

13 ore fa, max.riservo ha scritto:

Sinceramente non mi interessa aprire una polemica su quale sia il linguaggio da utilizzare per programmare i PLC, ognuno di noi è libero di utilizzare quello che ritiene più consono per realizzare l'applicazione, secondo le sue conoscenze, le sue preferenze e quello che mette a disposizione il PLC che deve/vuole/può utilizzare ...

Condivido anch'io quello che dici, ognuno ha le proprie abitudini, preferenze e ha le proprie inclinazioni dal settore dove ha studiato è cresciuto e ha fatto la propria esperienza e proprio per questo mi sento di dire di usare il linguaggio che si preferisce ma di non precludersi agli altri linguaggi magari scoprendo che hanno maggior utilità nella più veloce lettura e comprensibilità in fase di lettura, poi ognuno fa come vuole

2 ore fa, Yiogo ha scritto:

il software non deve essere "facile ed intuitivo" deve essere efficiente

Beh mi sembra sott inteso

 

Esprimo il mio pensiero affinche chi deve imparare non si precluda a vari tipi di linguaggi

[_gian]

Il sistema di controllo è implementato su di un CP1L_E e un HMI della serie NB Omron.

 

Abbiamo Nos. 27 DI, Nos. 17 DO

Abbiamo poi No. 01 AI ( sensore di livello acqua grezza) e non ci sono AO.

 

La struttura del programma è abbastanza standard e si presenta come sotto:

 

In questo tipo di impianto, normalmente non sono previste misure di portata e composizione chimica in continuo sia per motivi di costo sia perché l'impianto è dimensionato in funzione del flusso giornaliero medio e della composizione dell'acqua grezza in ingresso nonché ovviamente dalla capacità di accumulo: l'acqua trattata in eccesso viene scaricata nel rispetto delle norme vigenti.

Durante il primo avviamento dell'impianto e durante le manutenzioni ordinarie e straordinarie l'acqua viene campionata ed analizzata e se non rientra nei parametri si interviene sull'impianto.

A cura del conduttore dell'impianto, campioni di acqua trattata vengono inviati periodicamente ad un laboratorio di analisi Accredia che produce un certificato valido ai fini di legge.        

In ogni caso la qualità dell'acqua trattata viene garantita dalla tipologia e dal dimensionamento dell'impianto basato sull'esperienza in funzione della tipologia di inquinanti e della portata di acqua grezza.

 

Volevo però parlare dell'aspetto PLC che è quello che mi interessa di più. Nel caso specifico, nell'impianto di cui sopra, in funzione da un anno circa, si sono verificati dei malfunzionamenti che hanno provocato fermi di produzione. In particolare il PLC che gestiva l'impianto sembrava dare dei problemi. Dopo avere scaricato il programma, mi sono subito reso conto che era inutilmente ridondante, con funzioni duplicate fra PLC ed HMI. Anche l'implementazione della gestione da HMI, che era stata oggetto di critiche da parte del cliente, poteva essere ottimizzato in favore di una maggiore praticità di funzionamento. Alla fine poi il problema si è rivelato di altro tipo e una volta risolto  l'impianto è stato messo in funzione nuovamente quindi le modifiche al PLC/HMI sono passate, per il momento, in cavalleria,

 

Detto questo, io sto ancora lavorando a tempo perso su quel programma per tentare di toglier via tutto il superfluo o quello che si può rompere per poterlo eventualmente riutilizzare in futuro in impianti simili: vorrei però evitare di fare passi falsi e per questo motivo, prima di procedere, sarebbe bello se ci fosse qualcuno interessato a discutere la cosa ( contattandomi in PVT perché la mia è una copia di lavoro). Benvenuto anche chiunque altro con progetti similari da condividere in un'ottica di scambio sinergico. 

 

       

[leleviola]

2 ore fa, Yiogo ha scritto:

su questo sarei molto rigoroso

il plc o pac che sia deve controllare il processo, ingegnerizzare le variabili e fare le operazioni matematiche

gli hmi e mmi devono fare da interfaccie operatore e storicizzare

sembra banale ma se deroghi da questo nascono casini grandi 

Concordo far fare operazioni di processo all'HMI non mi sembra sia il suo compito