Programmazione PLC: logica a passi o combinatoria

[smsmsms]

Buonasera a tutti e auguri!

 

negli ultimi mesi mi è capitato di dover realizzare dei brevi programmi PLC; usualmente utilizzo una logica a passi ma, sempre più spesso. mi sento dire che una logica combinatoria sarebbe più snella ed efficace. Credo di "capire" cosa si intenda per combinatoria ma, la mia mente un po' avanti con l'età ... fa fatica ad afferrare appieno il concetto. Avete per gentilezza qualche suggerimento o link o libro o post o altro da consigliarmi per poter visionare informazioni in merito a questa logica di programmazione?

 

 

Grazie in anticipo a tutti; saluti

[Roberto Gioachin]

Per rispondere bisogna prima capire per quali applicazioni usi la logica a passi e per quali applicazioni ti viene suggerito di usare la logica combinatoria.

La logica combinatoria è il classico metodo che utilizza la combinazione di porte logiche AND, OR, NOT, la stessa quindi è utilizzabile in modo sovrapponibile con contatti in Ladder oppure in ST (testo strutturato), non mi pare quindi nulla di nuovo.

La logica a passi, detta anche Logica Stati oppure Logica a Stati Finiti o ancora SFC è un metodo che viene usato per realizzare sequenze di qualsiasi tipo.

I due metodi secondo me vanno usati in situazioni diverse, quale è il tuo caso?

 

Vedi:

Logica combinatoria e sequenziale

 

[leleviola]

Combinatoria? non penso sia il termine giusto, semmai sequenziale, combinatoria è una logica fissa derivante da una logica booleiana ben definita, un esempio classico per farti capire è il comando di un display sette segmenti di cifra numerica esadecimale secondo la combinazione di 4 ingressi digitali, una logica sequenziale è quella che invece segue la storia passata del sistema e quindi tiene conto delle stato attuale del sistema. Post che possono farti capire qualcosa? Beh non saprei al limite cerca SFC per plc tipo Omron o Mitssubishi altrimenti Graph per Siemens

[smsmsms]

9 minuti fa, Roberto Gioachin ha scritto:

Per rispondere bisogna prima capire per quali applicazioni usi la logica a passi e per quali applicazioni ti viene suggerito di usare la logica combinatoria.

La logica combinatoria è il classico metodo che utilizza la combinazione di porte logiche AND, OR, NOT, la stessa quindi è utilizzabile in modo sovrapponibile con contatti in Ladder oppure in ST (testo strutturato), non mi pare quindi nulla di nuovo.

La logica a passi, detta anche Logica Stati oppure Logica a Stati Finiti o ancora SFC è un metodo che viene usato per realizzare sequenze di qualsiasi tipo.

I due metodi secondo me vanno usati in situazioni diverse, quale è il tuo caso?

 

Vedi:

Logica combinatoria e sequenziale

 

 

Buongiorno e grazie per la risposta.

 

Devo realizzare il programma di una macchina con 4 o 5 stazioni; l'avanzamento a "passo" del nastro principale (o meglio, il fine avanzamento e cioè il fine passo) fornisce il consenso al lavoro delle 4 o 5 stazioni. Le stazioni compiono movimenti per lo più semplici di movimentazione o pick e place di pezzi mediante ventose e vuoto tramite venturi (diciamo dai 2 movimenti nella stazione più semplice fino ai 10/12 movimenti nella stazione più complessa). Il problema è che se l'operatore passa da automatico a manuale, e compie una movimentazione anche corretta, con una sequenza a passi "rigida" dovrei scartare tutti i pezzi. Invece, come accennato nella prima mail, mi consigliano di guardare lo stato della stazione dopo il movimento manuale e riprendere quindi il ciclo automatico da li considerando la "combinazione" degli stati (reed, px, ev attivate ecc...).

[Livio Orsini]

Qui non si tratta di tipo di logica usata, si tratta di fare "la cosa giusta".

In pratica è quasi impossibile che in un'automazione si usino solo combinazioni o solo stati/passi.

In genere il problema si risolve con una giusta combinazioen dei due metodi.

Non sempre è possibile passare da uno stato al successivo senza valutare se è stata ripetta un somma di condizioni.

Modificato: 28 dicembre 2020 da Livio Orsini

[Roberto Gioachin]

Quindi il tuo programma sarà prevalentemente sequenziale.

Ognuno dei due metodi ha vantaggi e svantaggi, io personalmente utilizzerei senza il minimo dubbio la logica sequenziale, ed in particolare il linguaggio SFC, ma questo poi dipende da che PLC andrai ad utilizzare.

Se ben costruita la logica sequenziale può facilmente tener conto di eventuali movimenti fatti in manuale, ne uscirà un programma un po' più voluminoso ma estremamente affidabile.

Con la logica combinatoria ti potresti ritrovare facilmente con dei comportamenti imprevisti nel caso il movimento fatto in manuale non sia coerente con ciò che deve fare la macchina in automatico. Io personalmente programmi per sequenze ma fatte in logica combinatoria, non li faccio da tantissimi anni che quasi mi vergogno a dire quanti 😂

[Livio Orsini]

32 minuti fa, Roberto Gioachin ha scritto:

Io personalmente programmi per sequenze ma fatte in logica combinatoria, non li faccio da tantissimi anni che quasi mi vergogno a dire quanti 😂

 

Se è una sequenza è logico che si usi una logica sequenziale.

Si verifica se ci sono le condizioni per il passo successivo e la sequenza avanza.

[Roberto Gioachin]

32 minuti fa, Livio Orsini ha scritto:

Se è una sequenza è logico che si usi una logica sequenziale.

Anche per me è logico, ma suppongo tu abbia visto le sequenze che alcuni facevano 20 - 30 anni orsono senza usare il concetto di "stati", ma implementando network e network in logica combinatoria dove il movimento di ogni pistone o motore dipendeva esclusivamente dalla logica combinatoria di alcuni sensori o comandi vari, beh.. quel modo di lavorare io l'ho visto anche di recente da parte di qualche improvvisato programmatore.

Suppongo che a smsmsms abbiano consigliato proprio questo. 

 

 

[Marco Mondin]

Diciamo che sequenziale e macchine a stati finiti non è esattamente la stessa cosa.
Possiamo avere:
1 - Logica combinatoria
Viene valutata in continuo, è meno soggetta a dead lock, è più leggibile da un elettromeccanico ed è la più avara di risorse computazionali;

 

2 - Logica sequenziale
Si usano sequenziatori per evitare che tutta la logica o buona parte di essa giri in continuo, rende il codice di difficile lettura per un elettromeccanico, il debug è più semplice con l'ausilio dei break point (DI difficile utilizzo in LADDER), cosa che tuttavia comporta rischi. Permette di sviluppare codice più pulito e più facile da debuggare per chi ha formazione informatica, se sviluppato male e senza adeguata progettazione il rischio di cadere in deadlock è elevato, tanto che ad alcuni impiegati pasticcioni di alcune aziende ne viene proibito l'uso. Permette di risparmiare risorse computazionali.

 

3 - Logica a macchine a stati finiti
Non sono solo sequenziatori, c'è più teoria dietro. Sovente sono abbinate a vari sequenziatori, ma una macchina a stati finiti si basa di solito su due variabili a visibilità estesa COMMAND e STATUS. Lo status non indica solo una semplice sequenza, ma una condizione più estesa della macchina.
Poi ogni stato può avere un suo sequenziatore, una sua logica combinatoria o un ibrido a seconda dei casi. La cosa più importante nel caso di macchine a stati sono le transizioni di stato che vengono di solito eseguite in funzione delle sequenze di un comando.
L'abbinamento di 3 a 1 e 2 per implementare i singoli stati e le transizioni di stato, nonché i comandi permette un mostruoso risparmio di risorse.
Di contro è molto complessa la fase progettuale su carta, diagramma degli stati etc... Un comportamento progettuale superficiale è garanzia di casini e deadlock!

Queste 3 sono tutte facilmente utilizzabili con gli strumenti messi a disposizione dallo standard IEC 61131-3 e si possono usare tutte sia in paradigma procedurale che in paradigma strutturato che in paradigma object oriented.

In questo screeshoot, si possono notare i vantaggi computazionali dell'abbinamento di 3 a 2 e 1.
Si tratta di un tornio a 5 assi con molta componentistica al contorno. La ciclica da 1ms, inizializzazione a parte (Dove li supera) non raggiunge MAI i 100us di impiego del suo tempo e non li raggiunge neppure quella da 10ms, tanto che avrebbe tranquillamente girare tutto a 1ms, ma sono divise in quanto non avrebbe senso far girare la parte di PLC bordo macchina a 1ms è uno spreco inutile di risorse.

Non esiste la logica migliore di un'altra, come suggerito da Livio, dipende dal caso e quasi sempre si mischiano.

Il nuovo standard IEC 61499 che, purtroppo, sta incontrando un muro nell'essere implementato dai costruttori, aggiunge:

4 - Logica Event Driven
Tale logica si sposa con la filosofia OOP (Paradigma object oriented), del quale ne esalta i pregi.
Si tratta di una logica non ciclica (Solo una minima parte dei compiti vengono eseguiti in modo ciclico legati al'evento E-CYCLE).
I metodi interfaccia dei vari oggetti vengono attivati dall'emissione di segnali con il classico sistema della callback utilizzato nei software dei PC.
Esempio 1 se ho un socket TCP in ascolto, non controllo ad ogni ciclo se ci sono nuovi dati con il classico FB, aspetto semplicemente che sia lui a chiamare il mio metodo esposto quando si accorgerà per i fatti suoi che ci sono dati.
Esempio 2 se ho un input di start non lo controllo ad ogni ciclo, ma aspetto che sia lui a chiamare il mio metodo esposto quando cambia di stato.
Rimangono sotto E-CYCLE solo ed esclusivamente quelle poche parti che necessitano di determinismo.
Si tratta della logica più economica a livello di risorse, tuttavia richiede una buona formazione in campo informatico avanzato.
Il debug senza break points è impossibile.
Si sposa con il mutithreadig.
Abbinata a protocolli con supporto degli eventi, per esempio l'inutile OPC-UA che reinventa per l'ennesima volta l'acqua calda, li supporta e permette la distribuzione di processo su più controllori.
Un giorno motiverò la mia convinzione dell'inutilità di OPC-UA! Anticipo che è legata al fatto che esistono da molti anni standard per l'IoT che fanno le stesse cose a cui i buoni softwaristi che sviluppano MES ed ERP sono abituati. Mentre con OPC-UA sovente devono scomodare un terzo incomodo pagato a peso d'oro per fare da gateway verso tali standard, quando tutti i produttori di PLC avrebbero potuto appoggiarsi agli standard già esistenti nel campo IoT.

Modificato: 28 dicembre 2020 da Marco Mondin

[Livio Orsini]

39 minuti fa, Roberto Gioachin ha scritto:

quel modo di lavorare io l'ho visto anche di recente da parte di qualche improvvisato programmatore.

 

A mio giudizio tutto dipende dal fatto che non si usa fare prima l'analisi dettagliata della macchina/impianto.

Se si fa una corretta analisi dettagliata la codifica è praticamente automatica, qualsiasi sia il linguaggio usato.

Se invece si comincia a scrivere codice senza aver fatto il lavoro di anlisi, spesso ne risulta un programma che sta assieme come un castello di carte sostenuto da puntelli vari.

 

Se si fa una buona analisi, si suddivide ilproblema generale in tanti problemi sempre meno complessi (metodo topo down o deduttivo) ci si ritrova con una serie di funzioni elementari; a questo punto si può effettuare il processo inverso (metodo bottom up o induttivo) per assiemare l'intero programma. Si parte con l'implementare tutte le funzioni elementari, molte delle quali sono presenti o nelle libreria di sistema o nella libreria del programmatore. Completate le funzioni elementari si passa al livello superiore unendo i vari blocchi elementari, salendo di volta in volta di livello sino ad ottenere il programma completo.

Questa tecnica riducce notevolmente la possiiblità di errori perchè si può fare largo uso di blocchi collaudati. Il debug è facilitato dalla modularità del programma e dalla possibilità di collaudo parziale di singole funzioni.

 

Nei miei lavori ho sempre usato questa metodologia che può apparire inizialmente più dispendiosa in termini di tempo. Però, a lavoro terminato, il tempo impiegato e di gran lunga inferiore al tempo impiegato se, con l'ottica di risparmiare, tempo si iniza a codificare "ad libitum".

Ho visto persino casi aziendali dove il programma della macchina lo sviluppavano durante la messa in marcia della stessa con peze continue sino a che la macchina aveva un funzionamento accettabile.

[Marco Mondin]

7 minuti fa, Livio Orsini ha scritto:

 

A mio giudizio tutto dipende dal fatto che non si usa fare prima l'analisi dettagliata della macchina/impianto.

....

Ho visto persino casi aziendali dove il programma della macchina lo sviluppavano durante la messa in marcia della stessa con peze continue sino a che la macchina aveva un funzionamento accettabile.

Sacrosanto! Anche se sovente si viene criticati!
Sono molti convinti che per far funzionare una macchina bastino pochi giorni proprio per colpa di chi usa tale metodologia.

Mi è capitato molte volte di vede scrivere applicativi in campo. Di vedere applicativi che se fossero il mosaico di una chiesa appeso a un muro sarebbero anche belli, ma non sono un mosaico murale.

L'esempio delle puntelle calza a pennello.
Quando dico che io passo l'80% del tempo su carta e solo il 20% a scrivere codice e debuggare mi prendono per scemo.

Oggi in epoca IoT poi le cose si complicano, spiegare ad un cliente finale che il software scritto alla bene meglio non predisposto per una seria integrazione non può fare cosa si aspetta è disarmante. Un software per essere integrato deve nascere per potersi integrare, altrimenti se anche qualcuno riesce ad integrarlo, oltre alla mostruosità di tempo perso inutilmente, ottiene un risultato mediocre e molto al di sotto delle aspettative di ciò che si aspetterebbe il committente come integrazione MES/ERP/IoT.
Un cliente deluso, sovente è un cliente perso... Molti non considerano questo aspetto.

[Livio Orsini]

3 minuti fa, Marco Mondin ha scritto:

Un software per essere integrato deve nascere per potersi integrare,

 

E uno dei tanti concetti lapalissiani, ma che sembra incomprensibile ai più. Poi magari si lamentono per i continui disservizi.

[batta]

2 ore fa, smsmsms ha scritto:

Il problema è che se l'operatore passa da automatico a manuale, e compie una movimentazione anche corretta, con una sequenza a passi "rigida" dovrei scartare tutti i pezzi. Invece, come accennato nella prima mail, mi consigliano di guardare lo stato della stazione dopo il movimento manuale e riprendere quindi il ciclo automatico da li considerando la "combinazione" degli stati (reed, px, ev attivate ecc...)

Personalmente ti consiglio di usare una logica sequenziale, con la possibilità di far partire la sequenza non solo dal primo passo, ma anche da alcuni passi intermedi, a seconda delle condizioni in cui si trova la macchina.

 

[batta]

24 minuti fa, Marco Mondin ha scritto:

Mi è capitato molte volte di vede scrivere applicativi in campo.

È capitato anche a me, ma non per mia volontà. Anzi, credo sia capitato a tutti.
Troppo spesso, il cliente fornisce solo delle informazioni molto ridotte sul funzionamento della macchina/impianto. Spesso nemmeno lui conosce tale funzionamento. Ed ecco che ti trovi a scoprire come deve funzionare la macchina solo quando sei davanti alla macchina.
Certo, è sbagliato, ma non sempre la colpa è del programmatore.
Oppure capita che ti hanno dato una settimana per sviluppare un software che richiede un mese, e il cliente vuole vedere la macchina che si muove. A nulla serve spiegargli che un giorno in ufficio, a scrivere software con un certo criterio, vale come tre giorni passati lì con mille elementi di disturbo.

[Marco Mondin]

9 minuti fa, batta ha scritto:

... A nulla serve spiegargli che un giorno in ufficio, a scrivere software con un certo criterio, vale come tre giorni passati lì con mille elementi di disturbo.

Tristissima verità!

Poi aggiungiamo che siamo il capro espiatorio di tutti i ritardi elettrici, meccanici, di consegne materiale, progettuali etc...

Essendo gli ultimi a mettere le mani su un progetto, sembriamo gli unici colpevoli a volte.
Vi è mai capitato di trovare committenti arrabbiati ancora prima di iniziare?

Modificato: 28 dicembre 2020 da Marco Mondin

[batta]

27 minuti fa, Marco Mondin ha scritto:

Essendo gli ultimi a mettere le mani su un progetto, sembriamo gli unici colpevoli a volte.

Altra tristissima verità.

[marco1278]

19 ore fa, smsmsms ha scritto:

usualmente utilizzo una logica a passi ma, sempre più spesso. mi sento dire che una logica combinatoria sarebbe più snella ed efficace.

Secondo me sono due modi diversi che vanno usati insieme. Per la tua macchina userei una logica sequenziale e poi in certe condizioni userei la logica combinatoria es: prima di passare al passo successivo o dopo un fermo operatore. 

 

9 ore fa, Roberto Gioachin ha scritto:

. quel modo di lavorare io l'ho visto anche di recente da parte di qualche improvvisato programmatore.

Purtroppo anch'io ho visto macchine del 2020 con programmi osceni. Il problema è che sono fatti da programmatori un po' troppo vissuti che continuano a riciclare codice inutile scritto 30 anni fa. 

Ho il mal di pancia ogni volta che ci devo mettere mano. 

[Mattia Spoldi]

1 ora fa, marco1278 ha scritto:

Purtroppo anch'io ho visto macchine del 2020 con programmi osceni. Il problema è che sono fatti da programmatori un po' troppo vissuti che continuano a riciclare codice inutile scritto 30 anni fa. 

Le ho viste anche io, ma secondo me il problema non sono i programmatori vissuti, ho visto programmatori anziani scrivere "arte" sotto forma di codice, ed ho visto giovani scrivere boiate.
Il problema è la mentalità di certa gente, hanno imparato a lavorare con un metodo sbagliato e non c'è modo di fargli cambiare idea.
Esempio recente, il mio ex capo, circa 38/40 anni, software monolitici, utilizzo di variabili globali come se piovesse, ecc ecc(più altri obbrobri tutti documentati su wikipedia qui). Durante l'ultimo avviamento che abbiamo fatto insieme su un suo sw, mi ci sono voluti solo 45 minuti per capire perchè una lampada di richiesta accesso si accendesse.

[Livio Orsini]

11 ore fa, marco1278 ha scritto:

. Il problema è che sono fatti da programmatori un po' troppo vissuti che continuano a riciclare codice inutile scritto 30 anni fa. 

 

Se un programma è scritto bene è scritto bene anche dopo 30 anni; se  osceno non è per l'età, ma perchè è stato mal progettato.

Un programma ben progettato è facilmente manutenibile ed aggiornabile., introducendo le varianti una alla volta e collaudandole.

Un buon analista programmatore aggiorna le sue librerie in modo da avere le sue funzioni sempre allo stato dell'arte. Se riusa una funzione scritta bene 30 anni fa, quella funzione sarà ancora attuale e avrà il vantaggio di essere super collaudata.

 

11 ore fa, marco1278 ha scritto:

Secondo me sono due modi diversi che vanno usati insieme.

 

23 ore fa, Livio Orsini ha scritto:

non si tratta di tipo di logica usata, si tratta di fare "la cosa giusta".

 

[marco1278]

11 ore fa, Livio Orsini ha scritto:

Un buon analista programmatore aggiorna le sue librerie in modo da avere le sue funzioni sempre allo stato dell'arte.

 

Ho avuto macchine consegnate nel 2020 dove la pressione di un tasto a pannello hmi tira in ballo contatori, confronti, word e altre cose solo per eseguire il set e il reset di un bit. Ci ho messo 20 minuti per capirlo 🙈🙈🙈

 

Colleghi mi dicevano che si faceva così sui primi S5. Adesso è il pannello che ha già la funzione per eseguire il set del bit. Perché non usarlo 🤷‍♂️

 

 

[leleviola]

23 ore fa, marco1278 ha scritto:

Secondo me sono due modi diversi che vanno usati insieme. Per la tua macchina userei una logica sequenziale e poi in certe condizioni userei la logica combinatoria es: prima di passare al passo successivo o dopo un fermo operatore.

scusami ma non capisco, una logica a passi è una logica che tiene conto dello stato del sistema o meglio ancora della storia passata del sistema, quindi non può essere una logica combinatoria, una logica combinatoria è quella logica che attua le proprie funzioni secondo una logica booleiana ben definita senza tenere conto dello stato di un sistema. In una logica sequenziale si è vero ci sono i passi che definiscono banalmente lo stato del sistema ma non posso definire una logica combinatoria quella logica in cui le transizioni tra un passo e un altro fanno passare lo stato del sistema tra un passo e una altro anche perchè tali transizioni non sono altro che le attuazioni di una logica sequenziale non combinatoria

[marco1278]

UNa logica a passi è tipo quella di un pick&place. Ci sono i vari stati che sono le posizioni del braccio e per passare da uno stato all'altro deve arrivare la condizione.

 

Per generare la condizione si può usare una logica booleana. Ad esempio la presenza corretta del pezzo da movimentate. 

Modificato: 29 dicembre 2020 da marco1278

[leleviola]

Infatti è una logica sequenziale che tiene conto dello stato attuale macchina, la logica che interviene per cambiare lo stato macchina è ovviamente una logica booleiana ma non può essere assimilata a una logica combinatoria perchè una logica combinatoria è legata esclusivamente a una esperessione booleinana che non tiene conto dello stato macchina, esempio banale come dicevo sopra è il comando di un decoder comando display 7 segmenti, tale comando è sempre lo stesso ed è dato da una combinazione di quatro ingressi binari, tramite una serie di combinazioni combinatorie si ha l'accensione di ogni singolo segmento secondo una logica prestabilita che non tiene assolutamente conto dello stato macchina, altro esempio banale può essere il comando di un asse avanti indietro con le combinazioni avanti indietro manuale e le condizioni avanti indietro automatico. Vero è che spesso logica combinatoria e sequenziale si mescolano tra di loro ma vero è che se un sistema fa parte di una logica  generale sequenziale non può essere assimilato a una logica combinatoria

[Livio Orsini]

11 ore fa, marco1278 ha scritto:

 

Ho avuto macchine consegnate nel 2020 dove la pressione di un tasto a pannello hmi tira in ballo contatori, confronti, word e altre cose solo per eseguire il set e il reset di un bit. Ci ho messo 20 minuti per capirlo

 

Che si impieghi 20" o 20 ore per capire può dipendere anche dalle conoscenze di chi sta cercando di capire.

Poi molto dipende da cosa deve fare quel bit. La condizione di un flag può essere alta o bassa in funzione della combinmazione anche di 100 variabili, non esiste una regola.

Poi, ripeto, se il programma è mal fatto può capitare che per dare la marcia di un monomotore si usino 50 righe di programma.

Non questione di età del programmatore, è solo questione della professionalità specifica di chi programma.

 

[batta]

3 ore fa, Livio Orsini ha scritto:

Non questione di età del programmatore, è solo questione della professionalità specifica di chi programma.

Vista la mia, di età, devo per forza dire che l'età non c'entra 😉
Scherzi a parte, sono anch'io del parere che non sia una questione di età.
È anche vero però che il modo di programmare di oggi è ben diverso dal modo di programmare di 20 o più anni fa.
Questo è dovuto sia al fatto che i PLC si sono evoluti (un tempo già era un'impresa fare un calcolo in virgola mobile, mentre oggi si gestiscono array a più dimensioni come per gioco), sia al fatto che è profondamente cambiato il compito del PLC (un tempo sostituiva un cablaggio elettromeccanico e poco più, oggi la pura gestione degli I/O è solo uno dei compiti, e non certo il più difficile). Tra i programmatori "avanti con gli anni" (categoria alla quale, indubbiamente, appartengo) ci sono quelli che si sono evoluti (ho la presunzione di essere uno di questi), e ci sono quelli che sono rimasti legati al modo di programmare imparato ad inizio carriera.
Pur rimanendo costanti i concetti base di come si deve sviluppare un programma, il mio modo di programmare è profondamente mutato nel tempo.