Questa è la cronca di una infelice applicazione di un PLC Wago. Spero possa servire a qualcuno, se dovesse trovarsi in condizioni analoghe. Prendete queste cronache per quel che sono.
Ho fatto parecchi lavori usando i PLC della Wago. Nello specifico ho usato quelli della serie PFC100 e quelli della serie superiore PFC200. Per noi è stata una scelta imposta dal cliente, in quanto solitamente preferiamo andare su prodotti più consolidati, tipo i PLC della Siemens, sui quali abbiamo decenni di esperienza. Da qualche tempo invece un certo cliente ha preferito andare sui prodotti Wago, probabilmente per una questione di prezzo.
I PLC della Wago hanno il loro ambiente di sviluppo, che si chiama e!COCKPIT ed è basato a sua volta sull’ambiente di sviluppo CODESYS che aderisce allo standard industriale IEC 61131-3
Si può programmare nei soliti linguaggi PLC (cito dal wiki inglese:
- Ladder diagram (LD), graphical
- Function block diagram (FBD), graphical
- Structured text (ST), textual
- Instruction list (IL), textual (deprecated in 3rd edition of the standard[1])
- Sequential function chart (SFC), has elements to organize programs for sequential and parallel control processing, graphical.
La mia preferenza va al linguaggio ST, che nel mondo Siemens si chiama SCL, un linguaggio testuale basato sul Pascal.
Quel che mi piace di più dell’ambiente Wago è che il PLC integra nel suo software un server WEB e la possiblità di disegnare abbastanza facilmente delle semplici interfacce utente che sarà poi possibile visualizzare su un qualsiasi client WEB.
In questo modo non è necessario fare ricorso a pannelli operatore specializzati. Wago mette a disposizione un pannello HMI ad hoc che altro non è che un pannello con integrato un browser WEB. Basta configurare l’indirizzo IP del PLC che si vuole monitorare. Ma, volendo, si può utilizzare un qualsiasi PC, tablet o dispositivo mobile (smartphone) dalla rete locale oppure (tramite VPN) da remoto.
In’altra caratteristica simpatica del Wago è la possibilità di segmentare facilmente il programma in vari task, ognuno con la sua priorità e con il suo ciclo di esecuzione. Caratteristica comuque non certo esclusiva del Wago. Tanto per dire, con i PLC Siemens si possono usare gli OB da 30 a 38.
Tutto bene dunque? Mica tanto.
Abbiamo fatto parecchi lavori con questo PLC, cose abbastanza semplici per il controllo di impianti industriali: aria condizionata, riscaldamento, gestione pompe di calore, interfaccie Modbus.
Ma i dolori sono iniziati quando ci è stato chiesto di integrare una rete di luci DALI (5 controllori DALI 753-0647 e 5 bus DALI separati) e di interruttori e sensori Konnex connessi ad controllore KNX 753-0646 via bus KNX.
Bisogna comunque specificare il fatto che questo lavoro è stato fatto “a cuore aperto”, in una situazione in cui l’impianto era già in funzione, il cliente mal digeriva interruzioni del servizio e la deadline della inaugurazione era imminente. Non c’è stato tempo per fare le prove a banco con la necessaria calma. Il tutto complicato dal fatto che le specifiche praticamente non esistevano, che gli architetti del cliente aggiungevano e toglievano in continuazione i punti luce DALI, le utenze elettriche, i punti KNX. Un incubo.
Wago ha a catalogo i moduli adatti per la gestione delle due realtà. Sul fronte DALI fornisce anche un utile strumento software, il Wago Dali Configurator che permette di configurare e controllare in modo abbastanza intuitivo la rete di illuminazione.
I dolori per quanto mi riguarda sono arrivati sul fronte KNX. Per noi era la prima volta che usavamo l’accoppiata WAGO-KNX, quindi c’era una mancanza di know-how specifico. E poi, forse per mia incapacità nel reperire le informazioni. è stato un delirio capire come configurare la parte KNX lato PLC. Sarà colpa mia, ma non sono riuscito a trovare un manuale con informazioni ed esempi esaustivi per tutte le possibili casistiche. Il service di Wago mi ha mandato i riferimenti di alcune application notes datate e assolutamente non sufficienti ad avviare un progetto KNX in totale autonomia. Vicino alla disperazione sono stato indirizzato ad un sistem integrator che, commosso dalle mie difficoltà, mi ha dato alcune dritte telefoniche che mi hanno finalmente permesso di uscire parzialmente dal pantano, almeno fino al punto di poter tenere la testa fuori dall’acqua. Non voglio qui entrare nel dettaglio dell’applicazione che comunque mi è solo parzialmente chiara. Posso solo anticipare che l’applicazione prevede la definizione della rete lato PLC, l’esportazione dal PLC di un file XML che viene passato al software ufficale ETS5 della Konnex con il quale si fa la configurazione della rete KNX fisica.
Nel caso DALI, il software WagoDaliConfigurator genera dei pacchetti di configurazione che transitano attraverso la CPU del PLC, arrivano al modulo Wago Dali Master (nel mio caso il 753-0647) e da li vengono inoltrati tramite bus DALI ai vari Driver Dali disseminati lungo la rete. In questo modo la configurazione della rete viene fatta tutta utilizzando il cavo Ethernet connesso alla CPU, lo stesso cavo utilizzato per la programmazione ed il debug del programma PLC.
In questo modo non è necessario utilizzare hardware ad hoc per la configurazione della rete DALI. Si può utilizzare lo stesso PC utilizzato per la programmazione del PLC, lo stesso cavo ethernet per connettere il PC al PLC e il flusso di configurazione passa quindi dal Wago Dali Configurator ai devices DALI passando attraverso il PC, la CPU del PLC ed il modulo DALI controller 753-0647.
Anche se le attività di programmazione del PLC e di configurazione del DALI possono passare attraverso lo stesso canale ethernet, occorre evitare assolutamente la sovrapposizione delle due attività. Quando il sw Wago Dali Configurator è online sul bus DALI non è possibile contemporaneamente andare online sulla CPU. Se si dimentica questo limite ci si ritrova inspiegabilmente a non riuscire ad andare online sul PLC. RIcordare quindi:
- quando si va online sul PLC non si può andare online sul bus DALI
- quando si va online sul bus DALI non si può andare online sul PLC
Nel caso KNX invece la cosa è più complessa. Come dicevo prima, la configurazione viene fatta nel sw PLC, da qui si esporta un file XML che viene passato al software KNX ETS5 sul quale viene fatta la configurazione della rete fisica DALI. Ma il sw ETS5 non può collegarsi alla rete KNX tramite la CPU Wago e il modulo KNX/EIB/TP1 Interface 753-0646. Occorre invece un gateway, tipicamente una chiavetta USB da inserire nel PC dove viene eseguito l’ETS5, che dall’altro lato si collega alla rete KNX e che permette quindi la configurazione fisica dei singoli punti KNX. Occorre quindi una interfaccia ad hoc, che viene utilizzata solo per la configurazione.
Il PC utilizzato per la configurazione della rete fisica KNX può essere lo stesso usato per configurare il PLC o uno diverso. Deve però essere chiaro che, diversamente da quanto avviene nel caso DALI, il flusso di configurazione non può passare attraverso la CPU del PLC e il modulo 753-0646 per arrivare ai devices KNX. Il flusso di configurazione deve raggiungere i devices KNX attraverso il bus KNX, passando per un gateway apposito, sia esso USB o ethernet.
Se troverò il tempo cercherò di scrivere un piccolo tutorial dedicato a questa operazione non proprio banale.
Una volta capito come fare, ed eseguite queste operazioni, sono riuscito a mettere in piedi tutta la rete DALI + KNX. Quando l’utente preme un pulsante KNX il PLC riceve l’informazione e accente o spegne o regola uno o più punti luminosi DALI relativi a quel pulsante.
Tutto a posto? Neanche per idea. Dopo qualche giorno di funzionamento regolare il cliente mi chiama inferocito per dirmi che il sistema si è bloccato e che non funziona più niente. Si è proprio bloccato tutto, il PLC non reagisce più, come se fosse morto. Mi reco sul posto, spengo e riaccendo il PLC. Niente, non va in RUN. Ha il led di RUN che lampeggia, rosso. Guardo sul manuale e mi dice che l’errore segnalato corrisponde alla situazione di “programma assente”. Provo a ricaricare il programma, ma non c’è verso, il PLC non accetta il programma. Eseguo il PING all’indirizzo IP della CPU e questa risponde. Ma di andare online e scaricare il programma non se ne parla. Il panico inizia a serpeggiare, ed il cliente è sempre più nervoso. Mi gioco la carta del reset di fabbrica. Il PLC torna come nuovo, e posso ricaricare tutto, il sistema riparte. C’è da dire per altro che con il Wago non c’è verso di caricare tutta la configurazione dal progetto. Alcune caratteristiche del PLC vanno necessariamente configurate tramite l’interfaccia web WBM (Web Based Management). Comunque me ne vado risollevato ma perplesso. Come mai è successa questa cosa?
Ovvio che, a distanza di qualche giorno e ad intervalli assolutamente irregolari l’evento si ripete. Con l’aggravante che, siccome il PLC gestisce anche le pompe di rilancio in fogna delle acque di cucina, quando il PLC si blocca le acque tracimano e finiscono sul pavimento. E vi garantisco che le acque di cucina di un ristorante sono davvero fetide. Immaginate cosa succede quando odori fetidi invadono la cucina e le sale di un ristorante di lusso. Il cliente è furioso. E Wago, interpellata, avanza le ipotesi più improbabili: forse la memoria non è sufficiente, forse la CPU non è abbastanza potente…. Controlliamo l’occupazione di memoria della CPU e i tempi di esecuzione del programma, e onestamente non sembra che siamo vicini al limite.
Ma tant’è, all’ennesimo blocco della CPU cerchiamo di capire quando è iniziato il dramma, e puntiamo il dito sul momento in cui abbiamo attivato la rete KNX. Decidiamo quindi di disattivare tutti i blocchi sw relativi al KNX, ed il problema scompare. Chiaro quindi che abbiamo qualche problema con il konnex.
Wago, interpellata, è sempre più perplessa. Ci consigliano di passare alla CPU di taglia superiore, una PCF200 8212. Ce la consegnano in tempi rapidi, vado a sostituire la CPU e poi riattivo il KNX. Tutto sta in piedi regolarmente. Bene, finalmente.
Proviamo a spegnere e riaccendere, per vedere se il software riparte regolarmente: morto. Ma come “morto”? Che significa? C’è il solito LED rosso lampeggiante di RUN. Come dire “non ho più il programma da eseguire”. Ricarico il programma e il sistema riparte. Ripetiamo l’operazione più volte, ed il risultato è sempre lo stesso: dopo uno spegnimento e successiva riaccensione del PLC il programma sparisce e va ricaricato. Come dire che se va via la luce il PLC non riparte. Grandioso! Mettiamo un UPS, tanto per proteggerci da piccoli black-out inferiori ai 20′, che Dio ce la mandi buona!
I tecnici di Wago ci dicono comunque che il nostro software è scritto male (grazie!), che usiamo troppe variabili ritentive e che abbiamo tutto il sw in un unico task, mentre lo dovremmo segmentare in diversi task con tempi di esecuzione differenziata. Il vero problema è che:
- non c’è modo di sapere con certezza quanta memoria ritentiva stiamo utilizzando. Ci dicono, genericamente “ne utilizzate troppa”. Si, ma troppa quanto? L’unico riferimento è il data-sheet dell’8212 che dice che l’8212 ha 128kB di memoria ritentiva di cui 104kB utilizzabili per le variabili ritentive. E va bene. Ma come faccio a sapere quanta ne sto utilizzando? Non si sa.
- non c’è modo di sapere in base a quale criterio dovrei segmentare il programma in task a cadenza temporale differenziata. Dove lo trovo il criterio?
Decidiamo di soprassedere, anche perché il cliente è già furioso e non vede di buon occhio i nostri interventi, in quanto ogni volta che si ricarica il programma nella sua completezza il sistema si blocca per il tempo necessario al download completo con conseguente arresto delle utenze e indesiderati spegnimenti delle luci.
Passano le settimane e il sistema sta in piedi senza problemi. Alleluya! Si, d’accordo, non possiamo spegnere il PLC, ma speriamo nell’UPS.
Finchè un giorno, dopo 6 settimane, il sistema si blocca di nuovo. Bestemmie. Grazie al cielo adesso abbiamo una VPN e possiamo collegarci da remoto. Il PLC sembra online, il server WEB funziona, e riesco a collegarmi. Quindi non è morto come in precedenza… Si, certo, il server WEB funziona, ma tutta la logica sottostante è morta. Non aggiorna neanche l’orologio sulla pagina web. Beh, provo a mettere il PLC in stop e poi di nuovo in run. Niente, non riparte. Nella diagnostica trovo un messaggio illuminante che dice che “un processo ha generato un’eccezione”. Quale processo? Che eccezione? Mistero. E io dove vado a cercare?
Insomma, ricarico il programma da zero, e il sistema riparte. Si, certo, ma viviamo con il fiato sospeso. E infatti dopo qualche giorno il sistema si blocca di nuovo. E poi di nuovo.
Quelli di Wago ci dicono “colpa vostra che non avete ancora ridotto le variabili ritentive e segmentato il programma”. Si, certo, colpa nostra, come no.
Per farla breve, installiamo una versione del programma rimaneggiata secondo le indicazioni di Wago. Variabili ritentive ridotte all’osso e programma segmentato. Prima indicazione: il programma riparte anche dopo lo spegnimento, alleluya. Per lo meno adesso non dobbiamo aver paura dei black-out. Si verificherà di nuovo il problema del blocco? E chi lo sa? Per adesso sono due giorni che funziona. Incrociamo le dita.
Una cosa è certa: problemi simili con PLC di altre marche (Siemens, Rockwell, Schneider) non ne abbiamo MAI avuti. Mai. Un PLC per definizione non si dovrebbe mai bloccare. Può guastarsi, oppure può andare in errore. Ma in quei casi ci sono tutte le indicazioni sul perché il PLC è andato in errore. E non può certo andare in una situazione che non si possa risolvere con un classico ciclo di power-off. E non può certo “perdere il programma” quando si spegne.
Insomma, non posso certo dire di essere soddisfatto.
Per ora il sistema sta in piedi, ma fino a quando? L’esperienza precedente ci dice che neanche due mesi di funzionamento ci garantiscono di aver risolto il problema.