Tecnica Di Programmazione E Struttura Di Un Programma Per Plc

[AlfredoSA]

Salve. Innanzitutto un grazie a tutti coloro che mi daranno supporto.

Ho da poco iniziato a programmare in ladder/AWL. Vorrei sapere se esistono delle linee guida/tecniche particolari per strutturare un programma scritto in ladder o in AWL. Mi spiego. Dopo, ovviamente, aver battezzato tutti gli ingressi e le uscite, vorrei sapere se esistono delle tecniche di programmazione con le quali si possa descrivere il funzionamento della macchina/impianto automatico e definire la struttura di un programma PLC, evitando così di buttarsi a capofitto nella scrittura di rung su rung di codice senza avere una struttura in mente del programma che si sta sviluppando. In altre parole, vorrei sapere se ci sono parti di codice che devono essere scritte prima di altre o messe in delle posizioni particolari.

E' una richiesta un pò particolare ma spero di essere stato abbastanza chiaro nell'esporla.

Confido nel Vs aiuto. Grazie per l'attenzione.

Saluti.

[Iacopo 78]

La normale prassi prevede che tu ti costruisca delle routine precedentemte programmate per funzioni abbastanza comuni

.per poi con poche modifiche andrai di volta in volta ad adattare al programma....

Inoltre vale sempre la vecchia prassi di dividere il programma in varie FB e FC

Per una migliore e piu rapida esecuzione e chiarezza in fase di collaudo e debug....

E utile anche utilizzare molto i commenti di cio che stiamo facendo

In quanto potremmo nom essere soli a doverci lavorare oggi ma anche un domani..

[spatula]

Premetto che la mia conoscenza di AWL è praticamente nulla, ma mi pare che dato il tipo di linguaggio sia praticamente impossibile documentare nel codice il funzionamento del sistema nel suo insieme. Il minimo indispensabile, sia in fase di progettazione che di revisione del progetto, è la costruzione di un diagramma di flusso. La conversione di un blocco del diagramma in un blocco funzione dovrebbe col tempo diventare un processo (mentale) abbastanza fluido, soprattutto se riutilizzi routine già scritte.

Il funzionamento può anche essere descritto con un diagramma di stati, che se non erro è l'approccio seguito in alcuni tool di programmazione. Secondo me è importante padroneggiare entrambi i tipi di diagramma, poi uno usa quello che meglio si adatta al problema specifico e agli strumenti a disposizione. I diagrammi sono parte integrante del progetto, tanto quanto il codice, e vanno quindi aggiornati se si introducono anche piccoli cambiamenti.

E naturalmente il codice va commentato. Penso che i commenti servano soprattutto a chiarire lo scopo generale della routine e a motivare le decisioni meno intuitive (tipo "perché leggo prima I0.3 e poi I0.1"), che magari sono il risultato di ore di lavoro spese nel debug di errori sottili che non vogliamo ripetere.

[Nino1001]

E utile anche utilizzare molto i commenti di cio che stiamo facendo

In quanto potremmonon essere i solia doverci lavorare oggi ma anche un domani

Programmo solo per diletto ma in generale....beh dipende....potremmo voler essere i soli...dipende fondamentalmente dalla fiducia che abbiamo nel cliente: salderà il conto a lavoro ultimato e collaudato?

[Iacopo 78]

Non parlavo di quello ma mi riferivo a quando si lavora in team...

[spatula]

dipende fondamentalmente dalla fiducia che abbiamo nel cliente: salderà il conto a lavoro ultimato e collaudato?

Quindi, immagino, se poi il cliente paga riscrivi il programma già collaudato aggiungendoci i commenti .

[gpp1969]

Programmo solo per diletto ma in generale....beh dipende....potremmo voler essere i soli...dipende fondamentalmente dalla fiducia che abbiamo nel cliente: salderà il conto a lavoro ultimato e collaudato?

[claudio_p]

Ciao,

premetto che sono della vecchia scuola, pertanto il mio metodo potrà sembrare un pò obsoleto, però penso che per muovere i primi passi possa ancora andare bene.

- Diagramma di flusso di massima di funzionamento impianto/macchina

- Diagramma di flusso dettagliato suddiviso per avviamenti/movimentazioni

- Lista ingressi e uscite necessarie alla gestione (in continua evoluzione durante l'elaborazione della documentazione)

- Stesura programma suddiviso in FC per singoli avviamenti/movimentazioni, in pratica un blocco per ogni uscita da comandare o al massimo due nel caso di valvole o comunque uscite in qualche modo legate tra loro; questo per una semplice consultazione e controllo in fase di collaudo e visione in stato.

- Stesura blocchi FB per funzioni particolari, parametrizzati ecc.

- OB di gestione

Particolare attenzione alle sicurezze (pulsanti emergenza, trip inverter, scatto termico, switch sicurezze ecc..) e alle segnalazioni di funzionamento.

Ovviamente in corso di realizzazione dovrai spesso ritornare su ciò che hai già fatto per aggiungere e/o modificare qualcosa.

Inserisci quanti più commenti puoi; al momento ti sembra tutto chiaro ma a distanza di mesi potresti non ricordare tutti i ragionamenti che hai fatto per una certa operazione.

Spero di non aver dimenticato niente.

Buon divertimento

ciao

[Livio Orsini]

Anch'io sono vecchio di scuola e d'età. Il mio approccio è simile a quello di Claudio_P, con la differenza che non uso diagrammi di flusso, ma specifiche dettagliate con analisi di tipo "top down" o, in italiano corretto, di tipo deduttivo. I diagrammi di flusso solo per funzuioni particolari. Particolare attenzione alle tabelle descrittive degli ingressi e uscite, con evidenza dei casi particolari (interrupts, uscite veloci, etc.).

La predilezione per le specifiche è dovuta all'approccio strutturato alla programamzione; i diagammi di flusso permettono anche "porcherie" del tipo "spaghetti like programming".

Considero la progettazione software indispensabile per la buona qualità del software medesimo. La stesura di specifiche che partono dalle generali di sistema sino al dettaglio delle piccole funzioni, oltre ad essere un ottimo metodo di analisi, facilita il lavoro di gruppo, permettendo la facile suddivisione degli incarichi ed una facile azione di collaudo.

[Iacopo 78]

quoto Livio al 100%....anche noi in azienda usiamo il solito sistema senza diagrammi di flusso

[Frank681]

Concordo con Claudio_p e Livio , io poi ( non so se in modo corretto ) mappo gli ingressi su merker a inizio programma e alla fine mappo dei merker (diversi) sulle uscite .

In questo modo ho solo un riferimento all'ingresso e uno all'uscita , e internamente al programma lavoro solo con merker , logicamente suddivisione in FB e FC , e simbolico e commenti completi con anche data ultima modifica , per avere uno storico tra le varie richieste del cliente e le modifiche , poiche' a volte passano anni prima di volere una modifica .

I commenti e il simbolico a prescindere dal i l linguaggio utilizzato.

Scusate se sono stato prolisso

Saluti

[AlfredoSA]

Salve a tutte ed immense grazie per le risposte fornitemi. In realtà, quando ho postato la mia domanda nel forum, speravo di ottenere proprio qualche risposta che considerasse l'utilizzo di diagrammi di flusso affiancato poi a qualche metodo di traduzione più o meno diretto in linguaggio ladder. Tuttavia, ho letto in più di un punto (cfr. Livio) che anche scrivendo in maniera dettagliata tutte le specifiche del problema di automazione, si riescono ad ottenere ugualmente ottimi risultati. Io di fatto cerco un metodo, più o meno "procedurale", per partire dalla descrizione del funzionamento della macchina/impianto automatico alla stesura del programma. Non so se esiste.

Avreste degli esempi da presentarmi nei quali questo modus operandi è utilizzato?

Mi è ormai chiaro che fa parte di un buon metodo di programmazione l'utilizzo della tecnica top-down e che il funzionamento della macchina/impianto automatico va sviscerato in parti elementari. Tuttavia, la grossa difficoltà che sto incontrando è capire, una volta arrivato alla singola funzionalità elementare, come strutturare la singola funzione (sia essa un FC o un FB). Mi spiego. Presumiamo che io debba usare il linguaggio a contatti. Il software, all'interno di questa funzione, che struttura dovrà avere? Non mi sembra corretto inserire rung dopo rung a caso, senza seguire una struttura logica. Perciò, la domanda che vi pongo è: come si struttura il software all'interno di una singola funzione?

Se avete anche degli esempi pratici o delle letture da suggerirmi, mi farebbe molto piacere.

Grazie dell'attenzione. Saluti.

[claudio_p]

Ciao,

Tuttavia, la grossa difficoltà che sto incontrando è capire, una volta arrivato alla singola funzionalità elementare, come strutturare la singola funzione (sia essa un FC o un FB).

Ho l'impressione che tu debba partire dall'ABC.

Tanto per capire: come sei messo con algebra booleana e mappe di karnaugh o similari? sei pratico di operazioni and,or,not ed operazioni su bit,byte,word,dword?

Non mi sembra corretto inserire rung dopo rung a caso, senza seguire una struttura logica .

Diciamo che in ogni caso, visto che sei all'inizio, tanto per entrare nell'ottica di ragionamento, a mio giudizio dovresti usare più carta e penna (o pc creandotti tabelle e/o schema logico) e non il software di programmazione. Questo almeno per le prime operazioni, poi quando ti sei creato uno schema mentale ( molto soggettivo aggiungo) potresti evitare questo passaggio, almeno con le operazioni più semplici.

In linea di massima comunque, per creare un segmento di comando, devi stabilire quali sono le condizioni per cui una determinata uscita deve andare a "1"; quali condizioni devono invece portarla a "0" e (importantissimo) le condizioni che devono evitare che vada a "1".

In base alla complessità del ramo o se particolarmente lungo decidi se utilizzare bit di merker d'appoggio che vengono utilizzate per raccogliere un certo numero di condizioni (istruzioni) per poi richiamarle in un'altro segmento e comandare infine la tua uscita.

Altra caratteristica soggettiva è come comandare un'uscita, se con SET-RESET o con istruzioni tipo autoritenuta; io personalmente preferisco il secondo sistema (questione di praticità e gusto personale ).

Per il resto prova a dare un'occhiata ai tutorial ( o meglio ancora aspetta un consiglio di Livio O. )

Ciao e spero di non averti confuso ancora di più le idee.

PS: per la cronaca, anch'io dopo un pò ho abbandonato i flow-chart per schematizzazioni molto più pratiche e veloci, ma penso che in fase di apprendimendo i pall....simi diagrammi siano necessari per abituare la mente al ragionamento in attesa di sviluppare un metodo più personale ed efficiente.

[AlfredoSA]

Ciao Claudio_p, con l'informatica sto messo bene: sono un ingegnere e queste cose le ho ripetute fino alla nausea. Quindi non ho problemi da questo punto di vista.

Comunque, grazie per la risposta. Proverò a seguire il tuo consiglio, ma resto aperto anche ad altre soluzioni. Alla fine credo che, come hai bene detto, il metodo di progettazione sw sia soggettivo e che soltanto con la pratica si inizi a capire come procedere.

Grazie ancora.

Ciao.

[attiliovolpe]

Ciao, sono alle prime armi con la programmazione anch'io, con la differenza che ho delle discrete basi teoriche e dimestichezza nell'uso dei pacchetti software; dopo c'è che ho una know how da manutentore e riesco a districarmi facilmente tra le righe di programma, ma lo faccio comunque a "tentoni" in quanto sono quelle cose che ti capitano quasi mai.

Suggerisco a *****

Saluti

*****

Nota del moderatore.

Si ricorda che, a norma di regolamento, è assolutamente vietato usere il forum come vetrina per annunci commerciali.

Modificato: 30 marzo 2013 da Livio Orsini