Benvenuto (o bentornato se già conosci questo sito), in questa lezione parliamo di debug programmi PLC, oggi infatti ci occupiamo di linguaggio ladder, e vediamo come si effettua l’analisi di un programma in diretta, per cercare di risolvere le situazioni di blocco (depannage).
L’esempio di oggi è molto semplice, tuttavia ti permetterà di familiarizzare con queste operazioni, che molto spesso chi programma PLC si trova a dover affrontare, oggi simulando due situazioni di blocco diverse.
Se scrivere un programma PLC è qualcosa che richiede tempo e pratica, il debug (ricerca errori o situazioni di blocco dello stesso), è un’operazione in cui molte persone trovano difficoltà.
Risolvere situazioni di stallo, per esempio quando una linea produttiva è ferma per cause sconosciute, non è sempre semplice, soprattutto quando i fermi impianto si traducono in migliaia di euro all’ora e la tensione sale.
Oggi simuliamo per prima una situazione nella quale siamo stati chiamati a intervenire su un impianto, per capire perché un certo prodotto non viene inviato a un punto di utilizzo, e la pompa che dovrebbe farlo rimane ferma.
Nella seconda simulazione scopriremo perché l’invio di prodotto, questa volta funzionante, non si ferma e prosegue anche con il serbatoio di invio completamente vuoto.
Per l’esercitazione proposta supponiamo che non abbiamo scritto noi il programma, per cui non sappiamo esattamente come funziona; in questo caso dobbiamo adottare una tecnica di analisi che si chiama “From the end”.
Con questo metodo partiamo dalla fine delle catene di comando, e risaliamo fino a trovare dove il problema risiede.
Ecco nella prossima figura la prima parte di programma che analizzeremo:
Dato che non conosciamo il programma, ci affidiamo a ciò che l’operatore ci comunica, ovvero che la pompa che dovrebbe inviare il prodotto non è in funzione, quando secondo lui dovrebbe esserlo.
Per questa lezione tralasciamo l’analisi degli allarmi ed eventuali segnalazioni sul malfunzionamento degli apparecchi in campo, e ci concentriamo solo sul software.
La prima cosa che facciamo è cercare dove sono i comandi per le uscite del plc, in questo caso una bobina che attiva il comando della pompa M1: la troviamo in una routine chiamata “Gestione_uscite”, che il programmatore ha creato nell’ambiente di sviluppo (per il nostro esempio Codesys).
Notiamo subito che la bobina non è comandata perché manca il contatto “comando pompa”; a questo punto cerchiamo dove questo contatto viene generato, ovvero la sua bobina.
Per cercare il comando utilizziamo la funzione “riferimenti incrociati”, disponibile praticamente in tutti i sistemi di sviluppo software per PLC.
Nella cross reference individuiamo il punto nel programma in cui ciò che stiamo cercando è utilizzato con accesso “Scrivi”. Una volta identificato il punto, ci portiamo su questo, solitamente con un doppio click sulla riga corrispondente nella finestra dei risultati.
Ecco nella prossima immagine dove viene generata la bobina di nostro interesse.
Scopriamo che la bobina del comando pompa si attiva con un timer, sul cui ramo di abilitazione però ci sono tre contatti aperti in serie, quindi in AND; vediamo che manca il contatto che ci dice che la valvola V1 è aperta.
Nella routine “Gestione_Uscite” avevamo visto anche che c’erano attivati i comandi di due valvole, V1 e V2, quì il programma si aspetta di ricevere i feedbacks di apertura da entrambe.
Ecco che basterà verificare il funzionamento della valvola V1 e del suo micro di posizione aperta, per risolvere il problema. La verifica è di tipo elettrico, per cui un manutentore andrà a controllare i collegamenti della valvola, e se arriva l’ingresso sul modulo del PLC, solitamente un ingresso a 24V in corrente continua.
Una volta risolto il problema che non permetteva di inviare il prodotto, veniamo richiamati dallo stesso operatore, dopo alcuni minuti, il quale ci racconta che il serbatoio ormai è vuoto ma lo scarico del prodotto continua a funzionare; in questa situazione la pompa gira a vuoto e potrebbe danneggiarsi.
Riapriamo il programma del PLC, e verifichiamo che in effetti la pompa è ancora comandata.
A questo punto andiamo a vedere dove lo scarico si ferma, torniamo nella routine “Gestione_invio”; eccola di seguito.
Subito dopo il comando della pompa, troviamo un ramo ladder che controlla il livello del serbatoio, e quando questo scende sotto il 2%, attiva un timer di 10 secondi. Al termine del tempo, si attiva un bit chiamato “fine_invio”.
Che cos’è che non fa funzionare questo ramo? Prima del controllo del livello, c’è un contatto che arriva dal teleruttore della pompa; se questo non si attiva allora non ci accorgiamo che il prodotto è finito.
Per risolvere il problema si deve verificare il collegamento del contatto ausiliario del teleruttore del motore, e il segnale digitale di ingresso nel PLC.
In questo caso ci troviamo però di fronte a un programma che potrebbe essere migliorato; in effetti il controllo del livello non dovrebbe essere vincolato al motore in marcia.