Semaforo Linguaggio Ladder

[Roberto Gioachin]

Forse non hai letto cosa avevo risposto in proposito:

Mi scuso, ma stavo rispondendo al messaggio nello stesso momento e non avevo ancora visto l'ultima risposta.

[Manuel Larsen]

Da questa affermazione mi viene da pensare che tu non conosca molto i plc e la programmazione di plc.

Un plc non si ferma ad attendere un evento, ma continua a ripetere il ciclo all'infinito.

Niente di più vero! Come ho detto il PLC non l'ho mai programmato... Aggiungici che l'unico che ho visto finora è il LOGO! che a quanto ho capito è il PLC più basilare che esista (corretto?), è come non aver visto nulla

Comunque la mia frase in realtà voleva dire esattamente quel che hai detto tu: il PLC non si ferma in attesa di un evento, ma esegue un controllo ogni X unità di tempo per verificare se l'evento è GIA' accaduto, ovvero controlla ad esempio se un'uscita è diventata alta a seguito della pressione di un pulstante. L'evento associato è proprio la pressione del pulsante, ma la pressione da sola non impone al PLC di fare il controllo. Tutto questo però considerando il problema in questione ed utilizzando la tattica del controllo sul timer. Facendo così si effettuano X controlli al secondo dove X = 1 s / l'unità di tempo scelta, quindi usando 0.1s in un ciclo di 3 minuti dovrò effettuare (3*60) / 0.1 = 1800 controlli... (NB: non parlo di "controlli diversi", saranno eseguiti sempre dallo stesso blocco logico, ma aumentano notevolmente il carico che deve affrontare la CPU del PLC). Appena un controllo restituisce il valore "pulsante pedonale premuto" agisco di conseguenza. Quel che dicevo io era fare il contrario, ovvero premere il pulsante agisce direttamente sul controllo. Il controllo lo eseguo solo quando premo il pulsante, se sono in un tempo di ciclo che non mi permette di gestire l'ingresso lo salvo in memoria, attendo la fine del ciclo proibitivo e dopo servo la richiesta. Per farlo però ho bisogno di timer separati, se usassi un timer unico dovrei controllare a che punto del ciclo sono e sarei punto e a capo. In parole povere è questa la differenza di cui continuo a parlare tra ingresso sincrono e asincrono. Tu vuoi gestire in maniera sincrona un ingresso asincrono, mentre sarebbe più semplice a mio avviso trattarlo per quello che è (anche se il salvataggio in memoria dell'ingresso altro non è che la trasformazione dell'ingresso da asincrono a sincrono).

Il modello sarebbe quindi:

- Ciclo con timer diversi i semafori N/S e E/O (che posso considerare come facenti parte dello stesso gruppo semaforico a due a due). Vengono considerate due fasi distinte per il ciclo.

- Alla fine di ognuna delle due fasi ho una fase di "tutto rosso" che deve durare almeno 3 secondi. Finita QUESTA fase posso gestire le chiamate.

- Quando mi arriva una prenotazione (e solo quando mi arriva) controllo se ho finito la fase di tutto rosso. Se non è così memorizzo la prenotazione.

- Alla fine della fase di tutto rosso controllo se ho prenotazioni, se è così servo chi di conseguenza.

In questo modo preservo la lunghezza di tutte le fasi, ovvero mantengo i tempi di verde/rosso sempre uguali per qualsiasi fase. Allungo semplicemente dinamicamente il "ciclo" totale aggiungendogli le fasi pedonali quando serve. I controlli sono ridotti al minimo, devo farli solo quando rilevo un input e alla fine della fase di tutto rosso. Durante le altre fasi me ne frego altamente. Questo modello sono riuscito a crearlo abbastanza bene (a mio avviso ovviamente ) con le reti di Petri, dove i controlli vengono effettuati dalle transizioni. Se una transizione non ha un controllo semplicemente è perchè non serve (sono nella zona "me ne frego").

Modificato: 9 maggio 2012 da Manuel Larsen

[batta]

Mi scuso, ma stavo rispondendo al messaggio nello stesso momento e non avevo ancora visto l'ultima risposta.

Non ti preoccupare, non hai proprio nulla di cui doverti scusare.

Tutto questo però considerando il problema in questione ed utilizzando la tattica del controllo sul timer. Facendo così si effettuano X controlli al secondo dove X = 1 s / l'unità di tempo scelta, quindi usando 0.1s in un ciclo di 3 minuti dovrò effettuare (3*60) / 0.1 = 1800 controlli... (NB: non parlo di "controlli diversi", saranno eseguiti sempre dallo stesso blocco logico, ma aumentano notevolmente il carico che deve affrontare la CPU del PLC).

No, non è così.

In base al carico la cpu potrà avere un tempo di scansione di 1 ms, oppure di 30-40 ms.

Supponiamo che il tempo di scansione medio sia di 10 ms, non conta assolutamente nulla quale sarà la base tempi del mio timer. La cpu effettuerà tutti i controlli che deve fare ogni 10 ms.

Se invece di una comparazione attende la pressione di un pulsante o lo scadere di un timer, non cambia assolutamente nulla: la cpu continuerà a testare tutte le condizioni, ed agirà secondo programma quando troverà una condizione vera o falsa.

Del resto, la comparazione che ti dice che è scaduto il tempo del verde, cosa è se non un evento?

Diciamo che si potrebbe saltare il controllo di tutte le fasi non attive. Cosa cambierebbe? Cambierebbe che, se la cpu ha meno istruzioni da controllare, anziché girare nei 10 ms di cui sopra scenderà a tempi di scansione più brevi.

Questo vuol dire che la cpu continuerà sempre a sostenere lo stesso carico di lavoro, ma effettuerà più cicli nell'unità di tempo.

Il beneficio quindi potrebbe essere quello di una risposta del sistema in 5 ms piuttosto che in 10 ms. Vale a dire, nessun beneficio pratico (non per un semaforo, almeno).

Considera poi che, se devi tener sotto controllo tutta la situazione, non potrai mai rimanere in attesa di un singolo evento, ma dovrai sempre sorvegliare i segnali provenienti dal campo per eventuali memorizzazioni.

Quindi...

In questo modo preservo la lunghezza di tutte le fasi, ovvero mantengo i tempi di verde/rosso sempre uguali per qualsiasi fase. Allungo semplicemente dinamicamente il "ciclo" totale aggiungendogli le fasi pedonali quando serve. I controlli sono ridotti al minimo, devo farli solo quando rilevo un input e alla fine della fase di tutto rosso. Durante le altre fasi me ne frego altamente.

Come già detto qualche post indietro, se vuoi preservare la durata delle singole fasi, lo puoi fare tranquillamente anche col timer unico.

Vuol solo dire che, anziché impostare il tempo totale del ciclo, questo tempo verrà calcolato sommando i vari tempi.

Se il semaforo però deve essere sincronizzato con altri semafori, tenere il tempo totale costante sarebbe un vantaggio.

Per quanto riguarda invece il discorso dei "controlli ridotti al minimo", vale quanto detto sopra.

Inoltre, avrai meno controlli da fare ma più azioni da intraprendere.

Nel tuo modo dovrai gestire una sequenza tipo:

- evento 1 --> accendi verde

- evento 2 --> accendi giallo

- evento 3 --> spegni verde e giallo, accendi rosso

- evento 4 --> spegni rosso, accendi verde

...

...

Con l'altro sistema invece avrai:

- la lanterna verde deve essere accesa o spenta? Comparazione --> Stato

- la lanterna gialla deve essere accesa o spenta? Comparazione --> Stato

- la lanterna rossa deve essere accesa o spenta? Comparazione --> Stato

Anche il debug risulta più facile nel secondo modo: perché il verde è acceso? Cerco l'uscita, controllo i valori della comparazione, vedo al volo dov'è l'eventuale errore.

Con l'altro metodo invece: perché il verde è acceso? Dunque, qui ho fatto il set, ma qui dovrei aver fatto il reset. Come mai non l'ho fatto? Oppure è stato l'atro set che ha acceso la lampada?

Mi pare di capire che sei più abituato a sviluppare software per PC: apro un form e aspetto che qualcuno prema un pulsante. Se nessuno preme un pulsante, me ne sto qui buono buono a non fare nulla (semplificando molto, ovviamente).

Sviluppare un programma di plc con un approccio simile porterebbe a disastri incontrollabili.

Modificato: 9 maggio 2012 da batta

[Manuel Larsen]

Allora: ho un ciclo per tutti i semafori, ogni punto del ciclo corrisponde a un colore dei semafori, per gestire le fasi salto in questo ciclo da una parte all'altra settando la variabile che si incrementa da sola a seconda di chi e cosa devo servire.

Per fare ciò devo:

1) controllare ogni istante in che punto del ciclo sono

2) controllare ogni istante se ho una prenotazione

La prima cosa che mi viene in mente è un comparatore seguito da un contatto normalmente aperto:

----|CMP TIMER==20s|--------| I1 |----------(SET TIMER=40s)

La funzione sarebbe IF((TIMER==20s) AND (I2)) TIMER=40s supponendo che 20s corrisponde al momento in cui posso accettare la prenotazione e 40s corrisponde al verde pedonale (di 8s ad esempio).

Essendoci un clock di 10 ms come giustamente mi fai notare, il tempo perchè questo piolo sia true è appunto 10ms. O sto sbagliando qualcosa io...

Nel tuo modo dovrai gestire una sequenza tipo:

- evento 1 --> accendi verde

- evento 2 --> accendi giallo

- evento 3 --> spegni verde e giallo, accendi rosso

- evento 4 --> spegni rosso, accendi verde

...

...

Con l'altro sistema invece avrai:

- la lanterna verde deve essere accesa o spenta? Comparazione --> Stato

- la lanterna gialla deve essere accesa o spenta? Comparazione --> Stato

- la lanterna rossa deve essere accesa o spenta? Comparazione --> Stato

Quindi per ogni lampada abbiamo:

Verde: ----|CMP 0s <TIMER<Tv |-------(V) Se il timer è compreso tra 0s e Tv accendi la lampada verde.

Giallo: ----|CMP Tg <TIMER<Tr |-------(G) Se il timer è compreso tra Tg e Tr accendi la lampada gialla.

Rosso:----|CMP Tr <TIMER<Ft |-------® Se il timer è compreso tra Tr e Ft accendi la lampada rossa.

(PS: esiste il blocco CMP come questo?)

Con Ft = FINE TIMER = Tv + Tg + Tr e Tv = TEMPO VERDE, Tg = TEMPO GIALLO, Tr = TEMPO ROSSO.

Questo per una sola lampada. Se ne ho 4 devo fare la stessa cosa 4 volte (o al minimo 2, in base ai gruppi semaforici). Se ho una fase pedonale la devo inserire nel ciclo, ma non devo eseguirla se non è avvenuta prima una prenotazione. Per servirla devo fare come sopra. Devo definire per tutto il ciclo dove e quando si accende ogni luce e ogni ciclo per ogni lampada comprende tutte le fasi. Cosa cambia da utilizzare timer separati e utilizzare il "fine timer" corrispondente per accendere la luce? Cambia che posso gestire le prenotazioni e il prolungamento del verde, e se devo far accendere una luce più volte posso riutilizzare il pezzo di codice già scritto. Il metodo utilizzato da te mi rendo conto sempre di più che assomiglia al mio: entrambi usiamo delle variabili per definire quanto deve durare l'accensione di ogni lampada, io uso una concezione di ciclo dinamico che cambia a seconda dello stato attuale e delle prenotazioni e quindi per forza devo usare timer differenti, tu usi un ciclo rigido e non modificabile (hard coded dice l'informatico dentro di me ). Quello che ancora non ho capito è come gestisci le prenotazioni. Ora capisco anche perchè vuoi utilizzare un diagramma temporale per far vedere l'incrocio, essendo il ciclo sempre quello non c'è molto altro da mostrare. Io invece volevo riuscire a far capire il ciclo dinamico e mi sembrava che le reti di Petri fossero un buon metodo (e continuo ad esserne parzialmente certo) per far capire il funzionamento dell'incrocio, ma mi sa che non è adatto ai non addetti ai lavori .

[batta]

Se ho una fase pedonale la devo inserire nel ciclo, ma non devo eseguirla se non è avvenuta prima una prenotazione

Questo accade, per esempio, in Australia (e sicuramente in molti altri paesi).

Qui in Italia, di semafori che se non prenoti saltano la fase pedonale io non ne ho mai visti.

io uso una concezione di ciclo dinamico che cambia a seconda dello stato attuale e delle prenotazioni e quindi per forza devo usare timer differenti, tu usi un ciclo rigido e non modificabile (hard coded dice l'informatico dentro di me )

Ne sei proprio sicuro?

Le prenotazioni le puoi gestire sempre e comunque e, se vuoi fare salti, basta semplicemente caricare un valore in una variabile.

Se devo aggiungere accensioni aggiungo un paio di comparazioni ed ho finito.

Non mi pare sia così "hard coded".

Ora capisco anche perchè vuoi utilizzare un diagramma temporale per far vedere l'incrocio, essendo il ciclo sempre quello non c'è molto altro da mostrare. Io invece volevo riuscire a far capire il ciclo dinamico e mi sembrava che le reti di Petri fossero un buon metodo (e continuo ad esserne parzialmente certo) per far capire il funzionamento dell'incrocio, ma mi sa che non è adatto ai non addetti ai lavori .

Dunque, il quesito iniziale, come già fatto notare, parlava di un semaforo molto semplice.

Affrontare il problema con una soluzione semplice quindi mi pareva (e mi pare ancora) una buona idea.

Se vuoi fare un programma in grado di gestire anche l'incrocio più complicato per poi usarlo per un incrocio base mi sta bene, ma non mi pare la scelta migliore.

In ogni caso anche il ciclo con timer può essere reso dinamico in modo molto semplice.

Per quanto riguarda gli "addetti ai lavori", devo dire che non ho capito chi siano, secondo te, gli addetti e chi i non addetti

Modificato: 9 maggio 2012 da batta

[Manuel Larsen]

La maggior parte dei semafori con chiamata pedonale non effettuano la chiamata pedonale se non è stata prenotata. Lavoro in una ditta di regolazione semaforica e di incroci ne progettiamo tutti i giorni, fidati che è così. Per quanto riguarda i non addetti ai lavori mi riferivo al tipico geometra del comune, che potrebbe chiederti il funzionamento dell'incrocio e se gli presenti una rete di Petri ti guarda male e non ne capisce granchè. Per hard coded infine intendevo che il ciclo non può essere modificato a runtime.

Le prenotazioni le puoi gestire sempre e comunque e, se vuoi fare salti, basta semplicemente caricare un valore in una variabile.

Cosa intendi per caricare un valore in una variabile?

[batta]

Per hard coded infine intendevo che il ciclo non può essere modificato a runtime.

Da dove nasce questa tua (sbagliata) convinzione?

Lavoro in una ditta di regolazione semaforica e di incroci ne progettiamo tutti i giorni, fidati che è così.

Io i semafori non li programmo ma li vedo funzionare da "utilizzatore".

Funzionano così in una piccolissima percentuale.

Ho visto, nell'altra discussione, il link alle reti di Petri e la trasposizione in ladder.

Devo dire che il risultato non mi ha per nulla entusiasmato.

Inoltre risulta evidente che le reti di Petri non si possono definire un linguaggio, ma solo un metodo.

[Livio Orsini]

Lavoro in una ditta di regolazione semaforica e di incroci ne progettiamo tutti i giorni, fidati che è così.

E' forse quell'azienda che ha progettato i famosi semafori truccati per incrementare gli introiti comunali?

Ho visto, nell'altra discussione, il link alle reti di Petri e la trasposizione in ladder.

Devo dire che il risultato non mi ha per nulla entusiasmato.

Io le considero metodo di analisi didattico abbastanza utile per la formazione generale.

Un po' come il PASCAL nella versione originale di Wirth; poco pratico ma molto utile per formare la mentalità all'approccio rigoroso alla programamzione.

Può anche essere che le reti di PETRI siano uno strumento particolarmente efficace per l'analisi di particolari problematiche. Non avendo esperienza diretta nella progettazione di sistemi semaforici, non esprimo giudizi. Però se devo basarmi su quello che ho letto su queste due discussioni confermo il mio giudizio di UCAS .

Modificato: 9 maggio 2012 da Livio Orsini

[Roberto Gioachin]

Fino ad ora avete parlato solo di ladder e di reti di Petri, ma nessuno di voi ha preso in seria considerazione il linguaggio SFC che, diversamente dalle reti di Petri, è presente negli ambienti di sviluppo per plc.

Mi sembra di capire che nessuno di voi lo usa per realizzare programmi professionali.

Molto spesso ho notato confusione su questo argomento, sminuendo un metodo (se così lo vogliamo definire), per il solo motivo che nessuno lo spiega in maniera decente.

Io realizzo programmi con un numero di STEP da qualche decina a diverse centinaia, il vantaggio di questo metodo sta nel fatto che, se ben utilizzato, non si perde mai il controllo delle varie sequenze.

Inoltre qualsiasi modifica sulle sequenze è talmente semplice da non dover quasi aver bisogno di rifare da capo il ragionamento dell'insieme.

Naturalmente bisogna dare a Cesare quello che è di Cesare, quindi è inutile voler fare con SFC cose non adatte a questo linguaggio.

In pratica la parte SFC deve servire solamente come un direttore d'orchestra, quindi impartire degli ordini, ma la singola esecuzione viene demandata a FB, FC, o PB adeguati allo scopo.

Io non faccio programmi per semafori a livello professionale, ma da quello che avete scritto fino ad ora rimango sempre più convinto che SFC sia il linguaggio più adatto per questo scopo.

In realtà l'approccio con SFC a questo problema, non è molto diverso da quello descritto da Batta, ma il metodo di lavoro è completamente diverso e, secondo me, molto ma molto più semplice.

Naturalmente la mia opinione deriva anche dalla grande esperienza che ho con questo metodo, ma vi assicuro che non potrei rinunciarvi per tornare ai vari metodi tradizionali basati solo sul ladder (oppure ST che molto non cambia).

Roberto

[Livio Orsini]

Naturalmente la mia opinione deriva anche dalla grande esperienza che ho con questo metodo, ma vi assicuro che non potrei rinunciarvi per tornare ai vari metodi tradizionali basati solo sul ladder (oppure ST che molto non cambia).

Molto dipende sia dalla personale esperienza sia dalla personale preferenza.

SFC è molto simile al Grafcet francese, molto in voga negli anni 70-80 sui PLC francesi come Renault e particolarmente adattato alle problematiche dell'industria che ha fatto nascere i PLC: l'industria automobilistica.

Il vero problema di fondo, come si è discusso nell'altra discussione è la metodologia con cui si affronta l'analisi prima e la programmazione dopo.

[Roberto Gioachin]

Naturalmente Livio concordo sulla metodologia e su quanto hai scritto nell'alta discussione.

Un progetto lo si analizza sempre partendo dall'alto scendendo sempre più nei particolari, poi si spezza il tutto in parti semplici senza esagerare e si realizzano le singole parti da assemblare alla fine per raggiungere l'obiettivo iniziale.

Di tutti questi passaggi e non solo, si deve realizzare una completa documentazione, anche esterna all'ambiente di sviluppo se serve con anche informazioni che al momento potrebbero sembrare banali ed inutili.

Su questo sono concorde, ma io in questa discussione intendevo offrire la mia esperienza per dimostrare che non esiste solo il ladder per realizzare sequenze, visto che si parla di un semaforo.

Anzi, visto che SFC ha lo stesso spirito delle flow chart bene si adatta a questi scopi, ed ancora di più impone un metodo di lavoro del tipo top-down.

Con SFC si deve lavorare in questo modo: Per prima cosa si crea una sequenza ragionata con passi e transizioni vuoti, ma aggiungendo i commenti.

Successivamente si riempiono Passi e Transizioni con i segnali di input ed i comandi semplici, alla fine si realizzano Blocchi Programma che eseguano le operazioni in base ai comandi semplici provenienti dai Passi.

Il motivo per cui molti non usano questo metodo è che credono si debba programmare tutto solo con SFC, ma questo sì sarebbe il modo sbagliato di lavorare.

Roberto

[Livio Orsini]

Il motivo per cui molti non usano questo metodo è che credono si debba programmare tutto solo con SFC, ma questo sì sarebbe il modo sbagliato di lavorare.

Forse il vero problema di fondo è che molti programmano i PLC senza saper programmare!

L'uso dei linguaggi LD ha favorito la convinzione che programamre i PLC non è......programmazione.

Concordo con te che, secondo il tipo di problematiche che si affronta, bisogna usare il metodo ed il linguaggio più adatto alla soluzione, secondo le proprie conoscenze e preferenze. SFC, come Graphcet, in alcune situazioni è molto comodo e facilita molto.

Modificato: 12 maggio 2012 da Livio Orsini

[batta]

Fino ad ora avete parlato solo di ladder e di reti di Petri, ma nessuno di voi ha preso in seria considerazione il linguaggio SFC che, diversamente dalle reti di Petri, è presente negli ambienti di sviluppo per plc.

Mi sembra di capire che nessuno di voi lo usa per realizzare programmi professionali.

Io non uso quasi mai SFC perché mi pare, in alcuni casi, limitato.

Quando devo gestire un ciclo però, pur usando un misto di awl (90%) e kop (10%), in realtà non faccio altro che ricreare tappe e transizioni.

Non utilizzo quindo l'SFC come linguaggio, ma come metodo.

Tornando alle reti di Petri, probabilmente sarà solo perché non ho mai studiato a fondo l'argomento, ma la mia impressione è che non siano molto di più di un diagramma di flusso.

In ogni caso, non si possono considerare un linguaggio (non per il plc, almeno). Prova ne è il fatto che si debba tradurre la rete in ladder (o altro linguaggio da plc).

Il problema vero quindi, non è la rete di Petri in quanto tale, ma il fatto che poi, in fase di debug o quando mi trovo a dover apportare modifiche, in un plc io non vedo la rete di Petri, ma solo la "traduzione" in linguaggio da plc.

Capire quindi la causa di un'eventuale anomalia, visto che la traduzione in ladder risulta essere tutt'altro che intuitiva, non mi pare essere la scelta ottimale per un plc.

Solo per fare un esempio, in Step7 puoi programmare usando il linguaggio strutturato (SCL) che, per certe problematiche, risulta essere un ottimo linguaggio.

Quello che però scrivo il linguaggio strutturato viene convertito dal compilatore in awl e inviato alla cpu.

Se perdo il sorgente riesco a vedere solo il blocco convertito in awl. Chi ha provato, sa che il risultato è qualcosa di incomprensibile.

Lavorare con le reti di Petri per programmare un plc, visto che non esiste come linguaggio di programmazione per i plc e non è quindi possibile effettuare un debug "guardando" la rete, è come scrivere un programma in scl e cancellare i sorgenti.

[Nino1001]

Annoitato amorte da questa estate caldissima ho risolto il problema di un semaforo a quattro cicli:

Ciclo A - Direttrice NORD-SUD ( e Sud NORD ovviamnete)

Ciclo B: Direttrice EST-OVEST ( e OVEST -EST)

Ciclo C : da NORD verso EST e da SUD verso OVEST

Ciclo D : Da OVEST verso NORD e da EST verso sud.

Adottando come soluzioni:

1) Soluzione meccanica : Motorino elettrico sul cui albero sono montate delle camme. La SignalWerke AG, Berna li produceva ancora nel 1980.

2) Soluzione elettrotecnica: con relè temporizzati usando il programma di disegno e simulazione CAD_SIMU (vedi in rete)

3) Soluzione elettronica: con circuiti digitali classici. Ho perso la pazienza e l'ho abbandonato

4) Soluzione con PIC: l'ho poi testata con Real PIC Simulator.

5) In LADDER ma alla fin fine si è rilevata la brutta o la bella copia del ciruito elettrotecnica con relè temporizzati. l'ho testato a pezzetti...

[Mauro Dalseno]

5) In LADDER ma alla fin fine si è rilevata la brutta o la bella copia del ciruito elettrotecnica con relè temporizzati. l'ho testato a pezzetti...

e' un classico, da vecchio elettricista l' avrei fatto cosi'...

[spatula]

Riprendo la discussione che ho trovato finora molto istruttiva. Premetto di non essere un programmatore PLC, quindi se dirò delle cose per voi assurde tenete conto che vorrei soprattutto verificare le mie assunzioni, e poi capire se in questo caso particolare si può raccomandare (come farei io) un approccio basato su un diagramma a stati.

Sarò lungo quindi chiedo scusa e ringrazio anticipatamente chi mi leggerà fino in fondo.

Assunzione 1: anche se tecnicamente fattibile, non è né obbligatorio né raccomandabile usare il PLC per controllare lo stato delle singole lampade. Se l'incrocio è tra due strade e ciascuna ha quattro semafori per il traffico veicolare, nel PLC mi limiterò a impostare lo stato di un generico semaforo per ciascuna strada. La traduzione di questo output in accensione e spegnimento di luci è un problema che può essere demandato a un altro dispositivo. Nel PLC mi limiterò a gestire 6 output (2 semafori * 3 luci).

Assunzione 2: un sistema completo prevederà un'interfaccia di amministrazione per impostare le temporizzazioni e porre il sistema nello stato inattivo (tutti gialli) o di emergenza (tutti rossi). Assumo che qualsiasi PLC possa gestire input che interrompono immediatamente la normale sequenza del programma e portano all'esecuzione di routine particolari. Posso quindi programmare il normale funzionamento del sistema senza preoccuparmi di gestire queste interruzioni (ci penserà un altro programma). Il ritorno allo stato normale implica il riavvio del sistema e non ho bisogno di memorizzare lo stato precedente.

Assunzione 3: il calcolo delle temporizzazioni esula dagli scopi del programma.

Caso semplice

Lo stato di un singolo semaforo può essere V, G, R. Il numero di stati di un sistema con due semafori non è, fortunatamente, pari al numero di combinazioni di 3 stati per 2 semafori (che sarebbe 9). Molte combinazioni (es. VV) sono proibite. In questo caso il numero è 4, in generale è 2 * N. Posso descrivere un sistema a due semafori così:

| NS EO

---------------------------

S1. | V R

S2. | G R

S3. | R V

S4. | R G

Un diagramma a stati propriamente detto rappresenterebbe gli stati della tabella (Sx) come nodi, e le possibili transizioni con archi e frecce (eventualmente con un identificativo). Ma in questo caso le transizioni ammesse sono intuitive e ci possiamo risparmiare il diagramma.

Domanda chiave: Ma non è che da qui potrei già passare a un programma ladder? Ogni stato diventerebbe un rung, e ogni rung si limiterebbe a impostare gli output (luci) e a far partire un timer, con una durata specificata da qualche registro di configurazione. Manca qualcosa di essenziale?

Aggiungendo i semafori pedonali gli stati possibili diventano 3 * N. Nel caso specifico:

| NS-V NS-P EO-V EO-P

----------------------------------------------

S1. | V V R R

S2. | V G R R

S3. | G G R R

S4. | R R V V

S5. | R R V G

S6. | R R G G

(NS-V, EO-V: semaforo Veicolare, NS-P, EO-P: semaforo Pedonale)

Non vedo differenze di rilievo rispetto al caso precedente, quindi dovrebbe essere possibile anche qui passare direttamente alla programmazione in ladder.

Chiamata pedonale

Con la chiamata pedonale devo poter gestire due input (attraversamento NS e attraversamento EO - anche qui non mi interessa il numero effettivo di pulsanti), che possono teoricamente dare 4 combinazioni. Qui vado un po' di fantasia perché non so se lo scopo della chiamata sia quello di abbreviare i tempi di attesa o prolungare i tempi di attraversamento, cose che possono anche andare in conflitto. Adotterei comunque alcune regole:

1. La chiamata non può ridurre la durata dello stato G di qualunque semaforo.

2. Le chiamate successive alla prima (all'interno di uno stesso ciclo) sono ignorate.

3. La chiamata viene ignorata se lo stato del corrispondente semaforo non è R (questo per non generare nel pedone l'aspettativa di avere un tempo più lungo per l'attraversamento, quando magari la chiamata è già stata fatta da altri).

Da queste regole deriva che il programma non deve gestire contemporaneamente chiamate pedonali nelle due direzioni, e (soprattutto) che una chiamata produrrà effetti solo quando il sistema si trova negli stati S1 e S4.

Questo è il punto in cui interviene un minimo di complessità che sembra richiedere un lavoro di programmazione: dovrei ispezionare il valore corrente del timer e modificarlo evitando ovviamente che assuma valori negativi, ed evitando anche che la durata del verde scenda sotto un certo valore. Non è una cosa complicata, però personalmente mi sono dato come principio di non modificare mai lo stato di un timer - o lo si azzera o si aspetta che abbia finito. Quindi ricorrerei a un paio di timer aggiuntivi. Il primo è un timer di prolungamento (TP), attivato in cascata rispetto al timer normale (TN): in caso di chiamata pedonale gli si assegna un valore e il tempo totale sarà quindi TN+TP. Il secondo è un timer di accorciamento dei tempi di attesa (TA), in parallelo a TN: il primo dei due che arriva a zero fa scattare la transizione (e azzera l'altro). Il tempo di attesa effettivo diventa quindi il minimo tra tempo residuo di TN e TA.

Per risolvere eventuali conflitti farò in modo che TA sia attivato solo se TP non è stato attivato.

A questo punto credo di poter modificare e completare il programma ladder aggiungendo due rung, interposti tra le transizioni S1->S2 e S4->S5. Prendo quello tra S1 e S2 (verde in direzione NS):

- se in uno degli stati S4, S5 o S6 (semaforo rosso) del ciclo precedente è stato premuto il pulsante di chiamata, allora assegno al timer di prolungamento un valore non zero. NB lo stato della chiamata è un input il cui valore non cambia mentre mi trovo nella transizione S1->S2.

- se viene premuto il pulsante di chiamata nell'altra direzione, e TP non è attivo, faccio partire TA. NB lo stato della chiamata in questo caso può modificarsi (da OFF a ON) nel corso della fase di transizione. L'assunzione è che il programma possa essere immediatamente notificato della pressione del pulsante, ma forse questo non è neppure necessario perché niente mi impedisce (credo) di attivare il secondo timer in un dispositivo a parte e di metterlo in OR con il timer normale del PLC, e di condizionare la transizione al risultato (chiedo troppo?).

Al termine della transizione (si entra in S2) l'input corrispondente al pulsante di chiamata viene resettato.

Conclusioni

In un caso come questo un diagramma a stati è espressivo, e porta molto rapidamente al corrispondente programma ladder. Una volta risolta la mia incertezza sulla gestione degli interrupt credo che riuscirei anch'io a scriverne uno .

Le regole che non sono espresse nella tabella degli stati sono essenzialmente quelle relative alla gestione dei pulsanti di chiamata. Non mi pare un limite perché si tratta di input che 1) potrebbero non esserci, 2) non sono significativi per decidere lo stato successivo del sistema, 3) hanno effetti ben localizzati all'interno del ciclo. Il fatto che lo stato della chiamata non sia rappresentato come uno stato del sistema mi permette di cambiare le regole di gestione, priorità in caso di conflitto, temporizzazione, senza alterare la struttura del programma. Infine in un contesto del genere il numero di stati rimane limitato (3N) anche se si aumenta (ragionevolmente) il numero di vie da regolare.

Grazie ancora a chi vorrà spenderci un po' del suo tempo.