Semaforo Linguaggio Ladder

[ton-io92]

Salve a tutti,

sono un giovane ragazzo da poco diplomato, e mi sono sempre appassionato alla programmazione dei plc della siemens con lo step7 (in KOP). In pratica con programmi del tipo avviamento diretto di un m.a.t, ,teleinversione, o cancello automatico non ho mai avuto problemi, ora però sto cercando di programmare i semafori, e sto avendo una certa difficoltà . In pratica è un incrocio con quattro semafori che funzionano due alla volta ed inoltre ci sono anche i semafori pedonali . Il problema è che con i temporizzatori viene troppo dispersivo ed è un caos poi ho provato ad utilizzare la funzione ADD con le rispettive comparazioni ma ho problemi nell' accendere e spegnere ed inoltre mi hanno detto di utilizzare prima delle comparazioni la funzione MOVE però non ho capito a cosa serve . Come devo muovermi ???? mi date qualche suggerimento !!!!grazie a tutti in anticipo

[Livio Orsini]

C'è una recente discussione sui linguaggi di programmazione dove un utente ha usato le reti di petri per definire le sequenze di un semaforo. Nella discussione son riportati due esempi con diagrammi di flusso e spiegazione. ti consiglio vivamente di leggere quella discussione. Spendi un po' di tempo per la sua ricerca, così ti vedi anche un po' del forum , che è sempre utile.

Poi ti consiglio caldamente una visita alla sezione didattica del forum dove puoi vuisionare una gran quantità di materiale didattico, compresi i nuovi bellissimi video corsi di GianMario Pedrani sullo step7

Modificato: 1 maggio 2012 da Livio Orsini

[Manuel Larsen]

Ok, bella sfida, provo a utilizzare il solito metodo per creare quest'incrocio.

Prima di tutto si crea l'incrocio base, coi quattro semafori e le due fasi che si alternano:

Dobbiamo ora aggiungere i pedonali, che vengono chiamati da una delle due fasi indistintamente in maniera asincrona premendo il pulsante, ma che mettono l'intero incrocio in rosso (se volessimo ad esempio dei pedonali incrociati basterebbe togliere qualche arco...). Le cose cominciano a complicarsi:

Una volta finite le fasi pedonali si ritorna nella fase 1, che terremo come fase principale. Ogni semaforo è composto da RGV, da implementare in questo modo (con a fianco il modello con il prolungamento del verde da detector):

Ora non ci resta che unire il tutto:

Ora bisogna considerare le prenotazioni: se A prenota mentre viene servito B, A non viene servito (in realtà ora come ora non viene servito praticamente MAI). Bosogna introdurre le prenotazioni con memoria e anche il concetto di gestione FIFO (First In First Out). Per quanto riguarda la prenotazione basta aggiungere un posto, ma per la gestione FIFO abbiamo per forza bisogno di una matrice di posti:

Inserendo anche quest'ultima parte nella rete grossa prima che vengano ESEGUITE le fasi pedonali ottieniamo la rete finale.

Ora utilizzando il documento linkato da Livio possiamo convertire la rete in LD.

Alcune considerazioni:

- Tutte le transizioni (o quasi) sono temporizzate. Bisogna fare molta attenzione ai tempi da assegnare ad ognuna di esse o si rischia di creare dei casini.

- Ogni aggiunta di un nuovo gruppo semaforico aumenta esponenzialmente la complessità della rete.

- Andando avanti nello studio delle reti di Petri ho notato come le reti di Petri Colorate aiutano parecchio a semplificare gli schemi (come la coda FIFO).

- Il PLC NON può essere usato come regolatore semaforico in incroci stradali. Per fare ciò c'è bisogno per forza di un regolatore semaforico particolare e dedicato. Se si vuole regolare un semaforo interno a una ditta però va ancora bene.

- Programmare un incrocio anche di medie dimensioni con un PLC è un lavoraccio...

Manuel.

Modificato: 3 maggio 2012 da Manuel Larsen

[Livio Orsini]

Non per polemica o critica personale, ma solo per contruibire alla comprensione dei problemi di programmazione dei PLC (che non sono differenti dai normali problemi di proigramamzione).

Più che una sfida sembra una "spaghettata" (Così eran chiamati i programmi Fortran e Basic [spagetti like programming] proprio per le linee tracciate per seguire i jumps).

Se invece dell'uso delle reti di PETRI avessi approcciato il problema scivendo le specifiche in modalità "top down" o, detto in italiano, con metodo deduttivo, avresi risolto il tutto con, al massimo, una pagina molto chiara e comoprensibile a tutti. Da queste specifiche la codifica, indipendentemente dal linguaggio usato, è praticamente immediata. Anzi si possono scrivere adottando le regole sintattiche di un liguaggio strutturato. Ai bei tempi dell amia gioventù si sarebbero scritte con un simil PL11 (dialetto del CERN del PL1).

Modificato: 3 maggio 2012 da Livio Orsini

[Manuel Larsen]

Non sono nuovo al termine "spaghetti code", alla fin fine sono un programmatore java! Comunque l'approccio top-down credo proprio che sia stato seguito nel buttar giù le specifiche, anzi, se così non fosse non si capirebbe proprio nulla di quel che ho fatto, immagina se mi presentassi direttamente con la rete più grossa dicendo "Ecco qui!". In effetti è un po' confusionario come post, ho praticamente sviluppato il programma mentre scrivevo il post stesso, si potrebbe migliorare in un milione di modi (la seconda rete di petri è DAVVERO inguardabile, ciò non toglie che sia, forse, giusta)... Ma più che alle migliorie di "bellezza estetica", che sinceramente ritengo secondarie (ma MAI inutili, sia chiaro), volevo qualche consiglio/osservazione sulla programmazione vera e propria, sui metodi per creare aspetti particolari dei DES con la rete di Petri, oppure approcci con metodi differenti che possono svelare mancanze o incongruenze del mio metodo...

[Livio Orsini]

Il PLC NON può essere usato come regolatore semaforico in incroci stradali.

Partiamo da qui.

Forse se tu avessi usato un altro approccio, in luogo delle reti di PETRI, non avresti azzardato un'affermazione tanto categorica, quanto sbagliata.

Non solo il PLC può essere usato per controllare un regolatore a semaforo, ma addirittura può essere usato per costruire un semaforo intelligente che si autoadatta, entro certi limiti, alle condizioni del traffico, basto dotare il sistema di opportuni sensori di presenza e passaggio dei veicoli. Permette di inserire facilmente anche la chiamata pedonale.

Sarà un caso, ma uno degli esercizi previsti dai corsi di base della aziende produttrici di PLC, è proprio la regolazione di un incrocio stradale per mezzo di un semaforo controllato da PLC.

Non solo, ma oltre venti anni fa si applicavono già sistemi PLC di medie dimensioni per controllare isole di traffico nelle grandi città, con poi un sistema di supervisione e coordinamento delle varie isole gestito da calcolatore.

Ma su questo tipo di applicazioni potrei scrivere decine di pagine. basti pensare che buona parte degli automatimsmi di una macchina industriale hanno logiche simili al controllo di un incrocio stradale.

La mia critica all'uso delle reti di PETRI non è estetica, ma funzionale.

Personalmente non ho mai trovato un problema di automazione dove lìimpiego delle reti di PETRI ovvia qaulche significativo vantaggio sulle altre metodologie di analisi, anzi per mio conto vedo solo svantaggi.

Penso a chi debba intervenire a manutenere il programma e si trova di fronte, come documentazione, l'analisi con rete di PETRI. Mi par sintire le bestemmie e le maledizioni inviate all'autore.

volevo qualche consiglio/osservazione sulla programmazione vera e propria, sui metodi per creare aspetti particolari dei DES con la rete di Petri, oppure approcci con metodi differenti che possono svelare mancanze o incongruenze del mio metodo...

Non si tratta di evidenziare mancanze o incongruenze del metodo, perchè... è, appunto, un metodo. I metodi non possono prescidere dalla mentalità di chi li usa. Personalmente considero questa metodologia di analisi come un UCAS; forse sono in numerosa compagnia vista la scarsissima diffusione di questo metodo, se si esclude la'mbito didattico-accademico.

Poi non si deve confondere l'analisi con la programamzione. L'analisi del problema prescinde, almeno in buona parte, dalla macchina che i andrà ad usare.

Tanto per stare sull'esempio del semaforo.

Se tu esegui un'analisi corretta del problema la puoi applicare ad un micro PLC come il LOGO, ad un PLC mini come lo S7-2xx, o grnade come S7-300 o S7-400. Non solo è sempre valida anche se usi PLC A&B, GE, Panasonic o Mitsubishi. Cambieranno solo i dattagli legati alla specificità dello Hw.

Non solo se esegui il programma in ladder diagram, usando solo le istruzioni previste dallo standard IEEE, il programma potrà essere portato su qaulsiasi macchina il cui set di istruzioni sia un sovrassiome del set previsto dallo standard IEEE.

[Manuel Larsen]

Il mio "non può essere usato in un incrocio semaforico" non era a caso. Non so come ci si regolava 20 anni fa ma ora posso assicurare che è ILLEGALE utilizzare un PLC come LOGO! per regolarizzare un incrocio stradale civile, tant'è che tutte le ditte che si occupano di regolazione semaforica hanno un proprio regolatore che è ben diverso da un "semplice" PLC. Che poi si possa effettivamente fare è un altro paio di maniche, come dimostrato più e più volte dai tanti esempi accademici. Anche io ho provato, con il mio post, a regolare un incrocio con un PLC. Se pensassi che è impossibile farlo sarei quantomeno stupido a provarci, no?

Per quanto riguarda le reti di Petri nello specifico, essendo un linguaggio, non possono essere a discapito dell'autore. Non le ho inventate io e sicuramente sbaglierò in qualche punto nel loro utilizzo. Quel che dicevo era che magari si potrebbero confrontare i metodi (anche SFC è un linguaggio, non tanto differente dalle reti di Petri, e di certo si può dire se il metodo che si sta utilizzando con quel linguaggio è giusto o sbagliato o se è migliorabile) e le tecniche di progettazione per valutare se e quando un metodo è meglio di un altro. Se mi dovessi trovare davanti un progetto complesso in rete di Petri o in SFC (o ancora in LD) sinceramente non so per quale dei tre bestemmierei peggio Solitamente per me è sempre ostico riuscire a capire la programmazione di qualcun altro, indipendentemente dal linguaggio o metodo o formalismo utilizzato. Certo è che se ognuno si inventa un formalismo proprio diventa impossibile decifrare alcunchè. Ho notato che le reti di Petri non ti (le?) piacciono affatto, ma i metodi che impone di utilizzare non differiscono poi più di tanto da qualsiasi altro linguaggio di programmazione, tant'è che programmo con reti di Petri seguendo la logica che seguo in java (o quasi).

Modificato: 3 maggio 2012 da Manuel Larsen

[Manuel Larsen]

Utimo appunto: concordo pienamente nel dire che la rete di Petri normale non può essere usata come modello di programmazione avanzato, ma la rete di Petri Colorata è attualmente utilizzata nelle più disparate applicazioni, compresa la gestione del traffico urbano in Brasile.

Chiedo scusa per il doppio post!

[Livio Orsini]

ora posso assicurare che è ILLEGALE utilizzare un PLC come LOGO!

Questo è ben differente. Illegale ed impossibile sono due cose assolutamente differenti.

LOGO potrebbe diventare legale se ci fosse qaulcuno interessato a farlo omologare. Se fosse impossibile automatizzare un semaforo con LOGO anche omologandolo non si potrebbe usare.

La lingua italiana è una lingua precisa, ben differente dall'inglese, lingua rozza ed imprecisa, quindi il termine impossibile ha un significato completamente differente da illegale, se volevi dire illegale dovevi scrivere "illegale" e non "impossibile".

Ciusa la parentesi semantica passiamo all'argomento reti di PETRI.

ma la rete di Petri Colorata è attualmente utilizzata nelle più disparate applicazioni, compresa la gestione del traffico urbano in Brasile.

In Brasile fan tutto molto colorato, quindi è possiible che usino le reti di PETRI colorate Comunque il controllo del traffico urbano in Brasile non è ancora assunto a standard di qualità del software. Se avessi portato come esempio lavori della NASA o dell'agenzia spaziale europea avrebbe avuto ben altro peso.

Per prima cosa io le considero un metodo e non un linguaggio, come considero anche SFC un metodo e non un linguaggio. AWL è un linguaggio, KOP è un linguaggio, JAVA è un linguaggio, "C" è un liguaggio. Ladder Diagram è un linguaggio con specifiche riconosciute da IEEE.

Se mi dovessi trovare davanti un progetto complesso in rete di Petri o in SFC (o ancora in LD) sinceramente non so per quale dei tre bestemmierei peggio

Se ti trovassi a dover capire un progetto software complesso ben documentato, non avresti alcuna ragione per tirar moccoli indipendentemente dal linguaggio usato. Questo è uno dei motivi per cui contesto l'uso di metodo come le reti di PETRI o di SFC, perchè sono erroneamente spacciati come "autodocumentanti".

Come ho denunciato nell'altra discussione c'è l'errata tendenza a saltare la fase di analisi. Questa omissione, oltre a ridurre drasticamente qualità ed affidabilità del lavoro, elimina anche una seria documentazione. Da cui i moccoli quando si dovrà manutenere il programma.

[Manuel Larsen]

Siamo due bei testoni. Già immagino come prosegue la discussione:

Livio: "Impossibile è diverso da illegale."

Io: "Ho detto che non si può, non che è impossibile, che è leggermente diverso. Vuoi la possibilità di programmare l'incrocio sotto casa tua? Non ce l'hai. Perchè? È illegale, ergo, non puoi."

Livio: "Tu dici che programmare è illegale, ed è sbagliato. È l'installazione ad essere illegale, io devo poter avere la possibilità di programmare quel che voglio."

Io: "Mi riferisco ed è scritto alla programmazione dell'incrocio, che prevede quindi anche l'installazione dello strumento di controllo."

Livio: "Siamo su PLCforum.it, quando ci si riferisce al verbo 'programmare' il complemento oggetto sottinteso è ovviamente il PLC."

Eccetera, eccetera.

Io considero le reti di Petri un linguaggio per creare dei modelli, come ad esempio uso Petri per creare il modello della coda FIFO. Così come qualsiasi altro linguaggio modellizza un problema, diverso dal concetto di approccio del programmatore al problema.

Le reti di Petri Colorate inoltre hanno le seguenti applicazioni:

Protocols and Networks:

Intelligent Networks at Deutsche Telekom

IEEE 802.6 Configuration Control at Telstra Research Labs

Allocation Policies in the Fieldbus Protocol in Japan

ISDN Services at Telstra Research Laboratories

Protocol for an Audio/Video System at Bang & Olufsen

TCP Protocols at Hewlett-Packard

Local Area Network at University of Las Palmas

UPC Algorithms in ATM Networks at University of Aarhus

BRI Protocol in ISDN Networks

Network Management System at RC International A/S

Interprocess Communication in Pool IDA at King's College

Software

Mobile Phones at Nokia

Bank Transactions & Interconnect Fabric at Hewlett-Packard

Mutual Exclusion Algorithm at University of Aarhus

Distributed Program Execution at University of Aarhus

Internet Cache at the Hungarian Academy of Science

Electronic Funds Transfer in the US

Document Storage System at Bull AG

ADA Program at Draper Laboratories

Hardware

Superscalar Processor Architectures at Univ. of Newcastle

VLSI Chip in the US

Arbiter Cascade at Meta Software Corp.

Control of Systems

Security and Access Control Systems at Dalcotech A/S

Mechatronic Systems in Cars at Peugeot-Citroën in France

European Train Control System in Germany

Flowmeter System at Danfoss

Traffic Signals in Brazil

Chemical Production in Germany

Model Train System at University of Kiel

Military Systems

Military Communications Gateway in Australia

Influence Nets for the US Air Force

Missile Simulator in Australia

Naval Command and Control System in Canada

Ho citato solo il traffico in Brasile perchè pertinente. Fonte: http://www.cs.sfu.ca/~sja25/personal/resources/presentations/CPN.ppt

Comunque sia propongo di seppellire l'ascia di guerra e rimanere con l'idea di ballerine brasiliane che si lanciano coriandoli come se fossero token di una rete di Petri Colorata, che è molto allietante come immagine

[Livio Orsini]

Comunque sia propongo di seppellire l'ascia di guerra e rimanere con l'idea di ballerine brasiliane che si lanciano coriandoli come se fossero token di una rete di Petri Colorata, che è molto allietante come immagine

Non c'è nessuna ascia di guerra da seppellire perchè, almeno per parte mia, non c'è nessuna guerra in atto.

Non mi è mai piaciuto considerare le divergenze di opinioni come "guerre", come mi piacciono ancora meno le guerre ideologiche. Purtroppo è un male tutto italiano che prolifera senza soluzione di continuità da più di 2000 anni. Ma qui si entrerebbe in un'altro tipo di discussione.

Comunque concordo sull'immagine veramente gaia delle ballerine brasiliane che lanciono coriandoli, immagine gioiosa sia che le guardi dal lato A o dal lato B.

Sperando che ora non intervenga qualche utente femminasta a dar addosso a tutti e due.

Venendo a cose un poco più serie, ma molto meno gioiose.

In un precedente messaggio avevi chiesto di esprimere eventuali critiche al tuo metodo di approccio ed io le ho espresse.

Potremo discutere per mesi e anni, ed ognuno di noi porterebbe nuovi aqrgomenti pro o contro la sua teoria. Rimane il fatto che a me le reti di PETRI come metodo di anlisi piacciono poco o nulla, mentre a te sembrano piacere assai.

Anche nella lista di referenze che hai inserito le applicazioni, sebbene i nomi sono di un certo peso, si nota che sono applicazioni un poco marginali rispetto al "peso" degli enti citati.

Forse siamo tutti ciechi. Forse solo pochi eletti hanno visto la luce.

Comunque viviamo in una società dove è ancora possibile la libertà di pensiero e di dissenso quindi pssiameo pensarla in modo diametralmente opposto.

Differente è l'ambiente di lavoro. Li per forza di cose non ci può essere libertà di scelta. Ci deve essere chi decide la filosofia aziendale e chi lavora si deve attenere a quella filosofia per evidenti ragioni di omogeneità. Se nell'ambiente di lavoro dove operi è stato deciso di accettare le reti di PETRI sei "a posto".

Io considero le reti di Petri un linguaggio per creare dei modelli, come ad esempio uso Petri per creare il modello della coda FIFO.

Concordo su questa definizione. Però usare le reti di PETRI per modellare un FiFo mi sembra da masochisti. Ma è solo il,mio parere.

[Manuel Larsen]

Forse siamo tutti ciechi. Forse solo pochi eletti hanno visto la luce.

Dopo questa direi che siamo a posto così.

[batta]

Le reti di Petri saranno anche utilizzate per un sacco di applicazioni, ma sicuramente il loro uso non è adatto alla programmazione di PLC.

Basta vedere cosa ne è sorto per un semplice semaforo.

Non oso immaginare cosa accadrebbe con un problema più complesso.

Tornando al tema principale, ovvero al semaforo, un sistema semplice e molto flessibile potrebbe essere il seguente:

- incremento del tempo di ciclo del semaforo

- accensioni e spegnimenti regolati con delle semplici comparazioni in base al tempo trascorso.

I tempi impostati per le accensioni potrebbero anche essere espressi in percentuale del tempo di ciclo anziché in valore assoluto, in modo da adattare automaticamente tutte le fasi anche cambiando il tempo totale del ciclo.

Solo la durata del giallo dovrebbe rimanere fissa.

In questo modo risulterebbe semplicissimo anche gestire i tempi in cui il semaforo deve rimanere rosso in tutte le direzioni.

Si potrebbero gestire, altrettanto semplicemente, anche eventuali chiamate pedonali, con accelerazione del tempo fino alla fase del verde.

Il metodo va bene anche per incroci più complessi.

Invece che perdersi tra reti di Petri, SFC, fasi, autoritenute, reset, memorie, basta un banalissimo sequenziatore ciclico.

[Manuel Larsen]

Credo di non aver capito, purtroppo non sono un esperto in PLC

In pratica ho un "ciclo fisso" del semaforo (R-G-V) comandato da un temporizzatore in base al quale accendo le uscite corrispondenti facendo una comparazione costante del tempo trascorso. Se voglio gestire un ingresso asincrono come una chiamata pedonale devo accelerare il ciclo fino al rosso e farne partire un altro per il pedone. Come torno poi al ciclo sincrono? Devo resettare il temporizzatore? Come gestisco le uscite? Ho un temporizzatore per uscita (le 3 luci) o uno solo per tutti?

Giuro non voglio essere polemico, voglio solo imparare

Comunque tutto dipende da quanto complesso dev'essere l'incrocio. Se deve mantenere le prenotazioni, se deve fare l'incremento del verde, se il ciclo è attuato, semi-attuato o fisso... Il semaforo di per se non è complicato, ma un incrocio rischia di essere una bella gatta da pelare. Ad esempio mi han portato una descrizione di un incrocio fatta in questo modo: 3 strade a T, 2 principali (il viale) che devono rimanere in giallo lampeggiante. Quando ricevo il segnale da uno dei detector delle due strade deve passare da giallo lampeggio a giallo fisso e poi rosso, servire la strada che ha prenotato, tornare a rosso di sgombero e servire la strada incidente, rosso di sgombero ancora e poi giallo lampeggiante. Ovviamente da qualsiasi punto del ciclo deve mantenere le prenotazioni in memoria... Come se non bastasse c'è un pedonale a complicare il tutto!

Se invece si tratta di un senso unico alternato... Beh, quello è tutto un altro discorso!

[batta]

Ho un temporizzatore per uscita (le 3 luci) o uno solo per tutti?

Io intendevo un solo tempo per tutto il ciclo, in modo da gestire il tutto come se fosse un programmatore ciclico a camme.

Insomma, la trasposizione su logica programmabile del vecchio "programmatore per lavatrice".

Per esempio:

- incremento ogni 100 ms del valore corrente del tempo di ciclo (possibilità quindi di impostare tempi con risoluzione del decimo di secondo)

- la luce 1 deve rimanere accesa dal tempo x1 al tempo x2

- la luce 2 deve rimanere accesa dal tempo y1 al tempo y2

- la luce 3 deve rimanere accesa dal tempo z1 al tempo z2

- la luce 4 ...........

Per ogni semaforo basta gestire due luci: verde e giallo (o rosso e giallo, a piacere). Il rosso, a semaforo attivo, è sempre opposto al verde.

Mano a mano che l'incrocio diventa più complesso, per aggiungere semafori basta aggiungere comparazioni.

Nel caso di chiamata pedonale potrei, per esempio, incrementare il conteggio del tempo più velocemente (magari con incremento ogni 50ms o con incremento sempre ogni 100ms ma di due unità) in modo da arrivare più rapidamente all'accensione del verde.

Questo vale, ovviamente, per il ciclo normale del semaforo.

Le fasi con semaforo lampeggiante, giallo fisso prima dell'inizio del ciclo o altro, dovranno essere gestite a parte.

Se ti fai un semplice diagramma temporale, vedrai che tutto risulta più chiaro.

[Manuel Larsen]

Credo di aver capito, grazie! In pratica è un unico ciclo per tutte le fasi:

Pensando di avere l'incrocio con Nord (N), Sud (S), Est (E), Ovest (O), Pedonale 1(P1) e Pedonale 2 (P2) sarebbe:

t0_t1__t2_______t3__t4____t5____t6___t7

-----|N/S|-------------|E/O|---------|P1/P2|-------

Dove ---- significa tutto rosso e | xx | significa VERDE per xx (con il giallo subito dopo). Una volta arrivato a t7 azzera il contatore e ricomincia il ciclo.

Quel che non ho ben capito è come faccio il controllo sul tempo. Uso un temporizzatore o un "contatore" che si incrementa da solo ogni X secondi? Se uso un temporizzatore, come faccio in LD a controllare continuamente a che tempo del ciclo sono? Inoltre, l'incrocio da te ipotizzato è un ciclo fisso, cioè ho una e una sola fase che ripeto all'infinito, se volessi regolare un semi-attuato (una fase che gira all'infinito e delle fasi che possono subentrare quando vogliono) o un attuato (tutto l'incrocio rimane in attesa di prenotazioni, non ci sono fasi che girano sempre)? Quale modellizzazione utilizzeresti? Sempre un diagramma temporale? Attualmente qui da me si usano proprio diagrammi temporali, ma rischiano di non essere proprio esaustivi... Sembra che descrivano sempre un ciclo fisso, bisogna differenziare le fasi secondo me...

EDIT:

Mi è venuta un'altra domanda: se ho un ciclo fisso e due "fasi" pedonali distinte (prima P1 e poi P2, non insieme) e viene prenotata P2, con l'accelerazione del ciclo servo comunque P1 ma gli do metà del tempo di verde perchè devo arrivare a P2 ?

Modificato: 4 maggio 2012 da Manuel Larsen

[batta]

Se utilizzi un timer per sapere a che punto del ciclo ti trovi devi interrogare il tempo corrente del timer.

A seconda del plc e del tipo di timer, potresti trovarti con il tempo che si incrementa da zero fino al valore di preset, oppure con il tempo che conta indietro dal preset a zero.

Io ritengo sia molto più comodo usare una semplicissima variabile (inutile usare un contatore) da incrementare a intervalli fissi di tempo. Arrivati al valore finale, si azzera e si riparte da capo.

Per il tipo di applicazione in esame, io ritengo che la base tempo per l'incremento più adatta sia il decimo di secondo.

Per il funzionamento del semaforo, io ho solo buttato lì l'idea di base, poi si dovranno implementare tutte le varianti.

Per quanto riguarda gli altri cicli del semaforo, a seconda del caso potrebbe essere conveniente una gestione completamente svincolata dal ciclo, oppure una gestione interna al ciclo.

Potresti avere la condizione di semaforo lampeggiante (per esempio di notte), o con il verde fisso da una parte e il rosso dall'altra, in attesa che arrivino macchine sulla via secondaria.

Nel caso di semaforo lampeggiante, ritengo sia conveniente un controllo separato: il ciclo principale è OFF, lampeggiano tutte le luci gialle e, alla ripartenza, dal lato dove si dovrà accendere il rosso, per qualche secondo accendi la luce gialla fissa.

Terminato questo breve ciclo di preparazione, fai ripartire il ciclo principale avendo l'accortezza di gestire la ripartenza dal giusto valore di tempo trascorso.

A secondo di come è stato programmato il ciclo, non è scontato che si debba sempre ripartire da zero, ma potrebbe essere conveniente partire da un istante diverso.

Niente di più facile: allo start imposti il valore corrente desiderato ed hai risolto il problema.

Nel caso di verde da una parte e rosso dall'altra, potrebbe risultare più semplice congelare il tempo ad un certo istante e far ripartire il tempo solo se è stata rilevata la presenza di veicoli sulla via secondaria.

Per quanto riguarda le fasi pedonali P1 e P2, basta accettare la prenotazione della chiamata (con conseguente incremento più rapido del tempo) solo se è acceso il rosso dal lato da cui effettuo la prenotazione.

In questo modo modifico l'incremento del tempo solo per la fase interessata.

Per quanto riguarda invece la gestione diversa dei segnali pedonali (per esempio, la luce verde comincia a lampeggiare prima che si accenda il giallo, perché un pedone ha bisogno di più tempo per sgomberare l'incrocio), non devi pensare alle accensioni e spegnimenti di tutte le lampade come tante fasi di uno stesso ciclo, ma conviene considerare cicli separati per ogni lampada. Tutti i cicli avranno, ovviamente, il tempo corrente in comune.

In questo modo sarai libero di accendere e spegnere qualsiasi lampada come e quando vuoi.

Per non creare pasticci )accensioni incongruenti) si dovrà, ovviamente, porre una certa attenzione all'impostazione dei tempi.

Per esempio:

via N/S:

- G	000000000110000000000000

- V	111111111110000000000000

- R	000000000001111111111111

- P	1111111LLLL0000000000000

via E/O:

- G	000000000000000000000110

- V	000000000000111111111110

- R	111111111111000000000001

- P	0000000000001111111LLLL0

Dove:

G = Giallo; V = Verde; R = Rosso; P = Pedonale

0 = Spenta; 1 = Accesa; L = Lampeggiante

Queste però sono solo semplici considerazioni che faccio così, al volo, senza pensare troppo a tutti i dettagli del funzionamento di un semaforo.

Non escludo quindi di poter aver scritto cose non esatte, ma rimango convinto che l'idea di base sia valida e sia la più semplice da mettere in atto.

[Manuel Larsen]

Eccomi! Ho avuto qualche problema a loggarmi da un altro posto che non è a lavoro (mi loggo con Facebook, mi sa che c'è qualche problema al sito!). Tonando a noi, il fatto di usare un unico contatore per tutti non mi convince molto, se voglio cambiare il tempo di verde di un solo semaforo dovrò cambiare tutti i tempi di tutti i semafori: se voglio che il tempo di verde del primo semaforo del ciclo sia aumentato di 2 secondi ad esempio, dovrò cambiare tutti i controlli degli altri semafori aumentandoli di due secondi, cosa semplice se i semafori sono due, più difficile se ho 5 semafori e 2 cicli diversi... Per quello io ho preferito utilizzare una gestione dei tempi separata per ogni semaforo (o gruppo semaforico), in questo modo cambiando un tempo non intacco le tempistiche degli altri semafori perchè abilito un semaforo solo se il tempo di verde del semaforo precedente nel ciclo è terminato, non con un tempo prefissato (partenza asincrona vs. partenza sincrona).

Per il codice della strada, inoltre, non è possibile "accelerare" il tempo di verde o di rosso di un semaforo, questo per evitare che la vecchietta con la panda si ritrovi al centro dell'incrocio che il suo tempo di attraversamento è già finito, permettendo ai pedoni di passare e facendo una bella frittata. Bisogna per forza mantenere i tempi fissi e al massimo cambiarli a incrocio "vuoto". Un altro metodo è quello di cambiare il tempo di verde in base al traffico entrante, ma comunque bisogna mantenere un minimo imprescindibile (il verde viene al massimo allungato, non accorciato). Questo metodo è usato per rimuovere i tempi morti dall'incrocio, cosa che con la tua strategia non viene fatta purtroppo.

Per programmare un incrocio come si deve bisogna infine tenere conto di tutte le combinazioni possibili in tutte le fasi. È una matrice di incidenza [Fasi X Ingressi] che deve essere gestita nella sua totalità. Cosa faccio a fronte di quest'ingresso in questa fase (semaforo A in rosso, B verde, C e D giallo lampeggio) ? La risposta deve essere determinata e univoca in ogni istante del ciclo. Il sistema diventa quindi un automa a stati finiti DETERMINISTICO, con l'aggiunta della possibilità di avere più "eventi" coincidenti nella stessa fase... Che non sono altro che token di una rete di Petri. La rete di Petri infatti ha una potenza computazionale leggermente maggiore di un semplice automa a stati finiti, ed ecco il perchè della mia scelta.

Programmare un incrocio semaforico purtroppo non è una cosa cosi semplice come usare un sequenziatore ciclico, questa è l'unica cosa che ho imparato qui a lavoro Ho iniziato poco tempo fa e la prima cosa che ho pensato è stata "E che ci vuole a fare un semaforo? Sono tre luci che si accendono una dopo l'altra!"... Grosso errore! Più vado avanti e più mi rendo conto che ci sono variabili e condizioni che non ti verrebbero mai in mente. Io sto cercando di capire e imparare sempre di più, il PLC mi sembra il punto di partenza ottimale, tant'è che è proprio programmando incroci semplici che sto arrivando alle conclusioni di cui sopra.

[Manuel Larsen]

Ho trovato un documento molto carino! So di essere rompiscatole con ste reti di Petri, ma secondo me la soluzione è nei ditorni...

Il documento si chiama: Modeling and Analysis of Urban Traffic Lights Control Systems Using Timed CP-nets

[batta]

Tonando a noi, il fatto di usare un unico contatore per tutti non mi convince molto, se voglio cambiare il tempo di verde di un solo semaforo dovrò cambiare tutti i tempi di tutti i semafori: se voglio che il tempo di verde del primo semaforo del ciclo sia aumentato di 2 secondi ad esempio, dovrò cambiare tutti i controlli degli altri semafori aumentandoli di due secondi

No.

Basta, molto semplicemente, collegare tra loro i tempi impostati.

Se l'istante impostato per l'accensione del rosso da una parte è vincolato all'istante impostato per l'accensione del verde dall'altra, se modifichi un tempo automaticamente si aggiusta anche l'altro.

Inoltre, a scelta, puoi decidere di impostare il tempo totale del ciclo (praticamente indispensabile se vuoi sincronizzare tra loro più incroci), oppure se impostare i tempi delle varie fasi, con tempo totale pari alla somma dei singoli tempi.

Per il codice della strada, inoltre, non è possibile "accelerare" il tempo di verde o di rosso di un semaforo, questo per evitare che la vecchietta con la panda si ritrovi al centro dell'incrocio che il suo tempo di attraversamento è già finito

E allora, a cosa serve il pulsante di chiamata?

Premesso che sono convinto che il più delle volte non sia nemmeno collegato, lo scopo dovrebbe essere quello di ridurre l'attesa del pedone che intende attraversare.

Questo, ovviamente, non vuol dire far durare di meno il giallo o il tempo di attraversamento di un altro pedone.

Che i tempi di sgombero non debbano assolutamente essere modificati mi pare ovvio, ma se voglio ridurre l'attesa del pedone, non vedo in quale altro modo potrei farlo se non anticipando il rosso (preceduto dal giallo di durata fissa) dall'altra parte.

Cosa faccio a fronte di quest'ingresso in questa fase (semaforo A in rosso, B verde, C e D giallo lampeggio) ? La risposta deve essere determinata e univoca in ogni istante del ciclo.

Beh, direi che con il sistema del timer, istante per istante definisci in maniera assolutamente univoca lo stato globale delle lanterne.

Il sistema poi può facilmente diventare a prova di errore implementando semplicissimi controlli.

Ho iniziato poco tempo fa e la prima cosa che ho pensato è stata "E che ci vuole a fare un semaforo? Sono tre luci che si accendono una dopo l'altra!"

Io ho iniziato a programmare PLC 25 anni fa, e non ho mai pensato che gestire un impianto semaforico fosse cosa banale.

Comunque, io ho solo proposto (non certo imposto) un metodo.

Ovvio che tu sei libero di utilizzare il metodo che tu stesso consideri migliore.

Può anche essere che il sistema col timer non sia ottimale per esigenze particolari, ma il quesito iniziale parlava di un comunissimo incrocio senza strane varianti.

Se sei innamorato delle reti di Petri, puoi utilizzarle anche per un marcia/arresto, nessuno te lo vieta.

Ma il masochismo non fa parte della mia filosofia di vita: io preferisco le cose semplici

[Roberto Gioachin]

Devo fare diversi appunti, si tratta di mie opinioni, spero possono essere costruttive.

Messaggio 3:

- Programmare un incrocio anche di medie dimensioni con un PLC è un lavoraccio...

Dipende molto dal metodo di lavoro del programmatore, personalmente ritengo che non sia per nulla così, in realtà si tratta di sequenze ben definibili.

Per uno che fa il nostro lavoro, questi problemi si affrontano ogni giorno.

Infatti per buttare giù una sequenza con le reti di Petri non credo ci hai impegnato molto tempo.

messaggio 7

un PLC come LOGO! per regolarizzare un incrocio stradale civile

Se si deve parlare di plc, non tiriamo in ballo uno dei più "leggeri", prendiamo in considerazione quelli che adottano i linguaggi previsti dalle IEC 61131, mi sembra logico che da un logo non si possa pretendere molto, di sicuro non è nato per applicazioni complesse, quindi parliamo di plc veri.

e ancora

Se mi dovessi trovare davanti un progetto complesso in rete di Petri o in SFC (o ancora in LD) sinceramente non so per quale dei tre bestemmierei peggio

Daccordissimo, anzi credo che mi preoccuperei meno se mi trovassi proprio le reti di Petri

messaggio 9

Per prima cosa io le considero un metodo e non un linguaggio, come considero anche SFC un metodo e non un linguaggio

Io credo che oramai si potrebbe prendere atto che anche le IEC 61131 chiamano l' SFC un linguaggio. Che lo si possa ritenere un metodo può anche andare bene, ma su questo si può discutere per ore senza arrivare ad una conclusione. Quindi io direi di prenderlo come un linguaggio (almeno per convenzione), tanto tutti sanno di che cosa si tratta.

Tiriamo un po' di somme:

Personalmente credo che l'utilizzo delle reti di Petri in un plc sia quantomeno scomodo, abbiamo capito che parlare di reti di Petri e SFC è più o meno la stessa cosa, quindi per quale motivo si deve creare un diagramma come quello del messaggio 3 per poi convertirlo in LD, quando è possibile digitare direttamente la sequenza in SFC e metterci all'interno le varie istruzioni?

Il linguaggio SFC permette di discriminare molto bene passi e transizioni, permette di inserire commenti e sopratutto di monitorare la sequenza in esecuzione in modo molto agevole.

Stiamo parlando di un linguaggio (o metodo se si preferisce) grafico, sappiamo tutti che la grafica ha portato molti benefici sui metodi di programmazione, ad iniziare con il passaggio da DOS a Windows.

Oltretutto per esperienza posso affermare che con SFC o metodi molto simili, si possono agevolmente controllare semafori di qualsiasi complessità, anche decine con una sola CPU.

Che poi ci siano delle normative che non lo permettano, questo è tutto un altro paio di maniche (io non conosco le norme specifiche).

messaggio 17

si tratta sicuramente di un buon approccio al problema, ma come dice Manuel

il fatto di usare un unico contatore per tutti non mi convince molto, se voglio cambiare il tempo di verde di un solo semaforo dovrò cambiare tutti i tempi di tutti i semafori

Il rischio che si corre quando si modifica un programma già fatto è quello di perdere il controllo dei tempi.

Proprio per questo io concordo con Manuel sul fatto che tutti i tempi delle varie fasi debbono essere indipendenti, io farei proprio così.

E che ci vuole a fare un semaforo? Sono tre luci che si accendono una dopo l'altra!"... Grosso errore!

Credo che questo discorso sia una costante per tutti i problemi di automazione, il problema è che sopratutto chi commissiona i lavori la pensa in quel modo, prova a farglielo capire.

Scusate se mi sono dilungato, ma quello che ho scritto è per il gusto di condividere opinioni, non certo per critica.

Roberto

[batta]

Il rischio che si corre quando si modifica un programma già fatto è quello di perdere il controllo dei tempi.

Proprio per questo io concordo con Manuel sul fatto che tutti i tempi delle varie fasi debbono essere indipendenti, io farei proprio così.

Forse non hai letto cosa avevo risposto in proposito: basta, molto semplicemente, collegare tra loro i tempi impostati.

Se anticipo il verde da una parte, in modo completamente automatico si anticipa il rosso dall'altra.

Poi, a seconda di come procedo, se modifico l'istante di accensione del verde posso decidere di mantenere fissa la durata del verde, oppure di tenere fisso l'istante di spegnimento.

Il tutto con delle banalissime somme aritmetiche.

Ma provate a riguardare cosa ne è saltato fuori, con le reti di Petri, per gestire un comunissimo semaforo: un diagramma da perderci la testa.

Casomai, mi sta bene risolverlo con l'SFC che, in realtà, non è altro che un diagramma di flusso (e anch'io sono più propenso a considerarlo un metodo piuttosto che un linguaggio), con una rappresentazione infinitamente più chiara delle reti di Petri.

A mio avviso le reti di Petri sono un ottimo esercizio mentale.

Quando faccio un programma però non penso ad allenare la mente (per questo c'è anche il sudoku), ma cerco di fare una cosa che funzioni, e che sia possibilmente facile da capire e da modificare.

[Livio Orsini]

A mio avviso le reti di Petri sono un ottimo esercizio mentale.

Concordo! Non per niente hanno la loro maggior applicazione negli ambienti didattici. Le ho usate, per obbligo, nelle esercitazioni di informatica ai tempi dell'università, poi le ho lasciate "riposare".

Una buona analisi, ben descritta, è lo strumento ideale per definire la strategia del sistema di automazione ed un'ottima documentazione del programma a futura memoria; ovviamente integrando il programma con i commenti necessari e sufficiente.

Poi il tipo di linguaggio usato dipende dal problema, dalla macchina, dalle attrezzature disponibili e dalle conoscenze-preferenze personali.

Personalmente preferirei usare solo linguaggi strutturati tipo "C" ma anche il vecchio "PL" sarebbe ottimo. Purtroppo per motivi commerciali quasi nessuno dei grandi costruttori prevede la possiiblità di programamre in "C".

[Manuel Larsen]

Batta:

Basta, molto semplicemente, collegare tra loro i tempi impostati.

Se l'istante impostato per l'accensione del rosso da una parte è vincolato all'istante impostato per l'accensione del verde dall'altra, se modifichi un tempo automaticamente si aggiusta anche l'altro.

Inoltre, a scelta, puoi decidere di impostare il tempo totale del ciclo (praticamente indispensabile se vuoi sincronizzare tra loro più incroci), oppure se impostare i tempi delle varie fasi, con tempo totale pari alla somma dei singoli tempi.

E se volessi far si che tre semafori vadano uno dopo l'altro (stile onda verde) ma volessi cambiare il tempo di verde del primo semaforo? Devo creare dei vincoli tra semaforo e semaforo? Sarebbero 3 x 2 = 6 vincoli e 6 tempi, mentre a me basterebbe impostare solo 4 tempi, i 3 verdi e un rosso globale e 3 vincoli (qando finisce il verde di uno fai partire l'altro). Nel caso di cambio del verde devo cambiare solo un verde e non tutti e sei i vincoli (nel caso peggiore).

E allora, a cosa serve il pulsante di chiamata?

Premesso che sono convinto che il più delle volte non sia nemmeno collegato, lo scopo dovrebbe essere quello di ridurre l'attesa del pedone che intende attraversare.

Questo, ovviamente, non vuol dire far durare di meno il giallo o il tempo di attraversamento di un altro pedone.

Che i tempi di sgombero non debbano assolutamente essere modificati mi pare ovvio, ma se voglio ridurre l'attesa del pedone, non vedo in quale altro modo potrei farlo se non anticipando il rosso (preceduto dal giallo di durata fissa) dall'altra parte.

Il pulsante serve a chiamare la fase. Ogni fase è distinta per ogni gruppo semaforico (anche se ci possono essere più di due gruppi in una fase). Così è come è adesso, nella realtà. Il semaforo sotto casa è fatto esattamente così. Nessun tipo di accelerazione del tempo, nessun ciclo fisso se ci sono radar o pulsanti pedonali. I cicli fissi si usavano 40 anni fa. Ora si fanno solo cicli attuati o semi-attuati (a parte rari casi) ed è forse questo punto che non sono riuscito a spiegare bene. Bisogna ragionare un po' come la programmazione ad oggeti in C++, ho un oggetto chiamato "fase X" che io invoco tramite chiamata asincrona utilizzando l'evento "pulsante premuto". La chiamata al metodo però non può avvenire se sono già all'interno di un'altra fase o se sto già servendo quella chiamata. La chiamata però deve rimanere in memoria e può essere servita soltanto in una fase dove è permessa (come ad esempio una fase di lampeggio o di rosso rest). Le fasi però sono COMPLETAMENTE INDIPENDENTI, niente cicli unici o cose simili. Al massimo una fase può chiamare un'altra fase, dando l'idea di essere un ciclo, ma se dopo la fase A io voglio che venga servito il pedone (SE E SOLO SE è stata effettuata una prenotazione) devo farlo.

A prescindere quindi da Petri o non Petri (che tra l'altro, nessuno si è dato la briga di leggersi le reti di Petri Colorate? Quelle si che hanno un sacco di applicazioni, altro che didattica) la gestione dell'incrocio dev'essere deterministica. Sono d'accordo che aumentonado i controlli sul timer istante per istante definisci lo stato globale delle lanterne, è proprio questo quel che si vuole fare, ma non è più semplice operare SOLO a fronte di determinati eventi? Fare cioè una gestione ASINCRONA dell'incrocio? Il numero di controllo che deve effettuare il processore diminuiscono drasticamente e anche quelli che deve fare il programmatore! Se instante per istante devo definire cosa deve fare, quando ho (nel caso peggiore) un ciclo da 2 o 3 minuti, cosa faccio? Ogni decimo di secondo effettuo controlli sul timer?

[batta]

Sono d'accordo che aumentonado i controlli sul timer istante per istante definisci lo stato globale delle lanterne, è proprio questo quel che si vuole fare, ma non è più semplice operare SOLO a fronte di determinati eventi?

Forse sì e forse no.

Dipende da quanti eventi e da quante varianti devi gestire.

Il quesito iniziale parlava di un semaforo semplice, non con 150 lanterne, diciotto strade e novantasei controlli sul traffico.

Io comunque intendevo solo buttare lì un'idea, un modo diverso di affrontare il problema.

Non ho mai fatto e, probabilmente, non farò mai la gestione di un semaforo.

Però poter determinare con delle banali comparazioni se una lanterna, in un determinato istante, deve essere accesa o spenta, non mi pare né complicato da gestire, né difficile da sviluppare.

E questa idea per la gestione di un semaforo mi è venuta nonostante, per lavoro, io sia abituato ad affrontare praticamente tutti i giorni macchine che compiono cicli più o meno complicati, che vanno da tre-quattro fasi fino a varie decine (nel qual caso cerco però di suddividere il ciclo, mettendo insieme più cicli possibilmente semplici).

Il numero di controllo che deve effettuare il processore diminuiscono drasticamente e anche quelli che deve fare il programmatore!

Vero solo in parte. Dipende infatti dal tipo di PLC e dal linguaggio usati.

Può essere che le fasi non attive vengano saltate, oppure può essere che le istruzioni vengano ugualmente lette tutte ma solo in un punto di programma ci sarà quella che darà un TRUE come esito.

Per quanto riguarda lo sviluppo poi, se devi gestire eventi che attiveranno varie ramificazioni, la semplicità non è scontata.

Se instante per istante devo definire cosa deve fare, quando ho (nel caso peggiore) un ciclo da 2 o 3 minuti, cosa faccio? Ogni decimo di secondo effettuo controlli sul timer?

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.