Tecniche Di Programmazione

[dm27]

Salve,

desideravo avere informazioni su concetti di carattere generale.

Il nostro prof. ci ha insegnato che quando dobbiamo affrontare un

progetto la prima cosa che dobbiamo fare è costruire la macchina

di stato. Grazie alla quale sarà possibile individuare: stati,

ingressi, uscite e variabili temporanee.

Inoltre ci ha spiegato che la tecnica di programmazione che dobbiamo

usare per programmare in ladder,dopo aver costruito la macchina di

stato, è la seguente.

Ci sono tre fasi:

1)insieme di istruzioni ladder che indicano da quale stato partiamo e in quale

stato arriviamo.(settaggio degli stati)

2) in funzione dello stato in cui mi trovo resettare quello precedente

3) definire le azioni di ogni stato.

Ora volevo chiedervi se esistono altri approcci nella pratica.

Grazie

[STEU]

Modi di fare i programmi ce ne sono milioni,

quello che ti ha spiegato il tuo Prof è quello senz'altro piu' comune ed il piu' giusto (dal mio punto di vista) , in poche parole devi sapere da che condizione partire ,cosa fare e sapere la risposta all'azione intrapresa per poi continuare con la seguente , per poi trovarti a fine ciclo (nella maggior parte dei casi) di nuovo alle condizioni iniziali.

Il passaggio viene fatto con dei set e reset dei passi che devi efettuare.

Modificato: 11 febbraio 2005 da STEU

[dm27]

Grazie,

sei stato abbastanza chiaro.

[Livio Orsini]

L'approccio è concettualmente ineccepibile, anche se parziale: è l'ultima fase dell'analisi. Nella pratica le cose sono un poco diverse.

All'estremo opposto c'è chi parte a buttar giù istruzioni che poi verranno "martellate" fino a chè la machina ha un funzionamento quasi accettabile. Sembra una barzelletta ma, purtroppo, c'è un'infinità di macchine e impianti che sono composti da stratificazioni successive, pezze, aggiunte e quant'altro non andrebbe fatto. Puoi immaginare se devi fare una piccolissima modifica cosa può succedere.

L'approccio corretto è stabilire, come prima cosa, come deve lavorare la macchina-impianto; in altri termini stendere le specifiche di sistema. Sembra scontato ma spesso non avviene.

Stabilito cosa deve fare si analizza cosa serve per realizzare la macchina. In altri termini si definisce con quali dispositivi si andrà a realizzare la machina.

Superata anche questa fase si può iniziare a stendere le specifiche del software. In altri termini si desciverà quali funzioni di macchina dovrà realizzare il programma.

A questo punto, e solo a questo punto, si innesta la parte di analisi che hai descritto.

Il vero problema è che quasi mai, vuoi per motivi di tempo, vuoi per ingnoranza, si effettua tutta la procedura corretta. Oppure la si effettua in modo pittosto approssimato. Si crede di risparmiare tempo, ma lo si paga poi nell'attivazione della macchina.

Analizzare i preblemi prima, e risolverli, porta a risparmiare tempo sullo start up. Però quando si riesce a far pagare al cliente l'avviamento macchina, c'è anche che realizza il software direttamente in questa fase.

Modificato: 11 febbraio 2005 da Livio Orsini

[walterword]

l'impianto o la macchina o le macchine in rete , vanno analizzate

Va analizzato cosa fare , cosa si vuole ottenere e poi gestire come ottenere tutto questo

Si puo utilizzare la tecnica dei bit , settare e resettare per ottenere un flusso di programma

Io preferisco utilizzare una word di fase alla quale assegno dei valori e li leggo ed in base a quanto vale stabilisco le operazioni da eseguire (una sorta di switch-case nei linguaggi ad alto livello )

A seconda della complessita possono esserci piu di una word di fase ; per esempio c'e' un impianto con diverse macchine , quindi ci sara una word di fase che fa da regista , e altre word che

si occuperanno di gestire gli stati di ogni singola macchina o attivita

Ci sono poi delle routines per gestire gli allarmi , la comunicazione col mondo esterno , gli interblocchi

le aree di lavoro , la gestione encoders, gli azionamenti ect ect .

Insomma dipende da cosa si deve fare

L'errore di molta gente e' di iniziare a scrivere codice, a prescindere dal linguaggio, senza prima analizzare bene

le funzionalita o attivita da svolgere .

Poi viene fuori un putifero di porcherie , rattoppi , malizie pericolose

Si pericolose perche facendo porcherie magari potrebbe sembrare che tutto funzioni , ma in alcune situazioni potrebbero verificarsi anomalie insolite e dannose se non pericolose.

Si dovrebbe in teoria tendere a descrivere il tutto nella maniera piu astratta , definendo i blocchi logici ,

le funzionalita , e poi una volta concatenati questi iniziare a sviluppare l'architettura di ogni singola entita'.

Purtroppo pero , il mondo dell'automazione industriale , sta peggiorando , sempre poco tempo , male informazioni , specifiche mal fatte se non del tutto inesistenti e ci si ritrova a dover fare tutto o quasi sul cantiere

, con rumori vari , difficolta, mancanza di personale , quadri malfunzionanti , ma sopratutto il cliente finale che rompe le palle

ciao

walter

Modificato: 12 febbraio 2005 da walterword

[Roberto Gioachin]

Convinto come sono che discussioni come questa siano interessanti anche per programmatori già affermati, desidero apportare un sia pur piccolo contributo.

La risposta di Livio mette in luce come a volte non si abbia il tempo di realizzare il programma seguendo nel modo più completo la metodologia di programmazione, mentre un lavoro ben progettato permette la comprensione del programma, anche dopo anni.

Quindi, salvo per lavori definibili di scarsa complessità, ritengo indispensabile editare nel programma tutti i commenti e i testi che possono spiegere ogni piccola parte del programma.

Nel momento in cui si scrive il codice, tutto sembra logico e quindi il commento inutile, ma l'esperienza insegna che non è così.

Anche per quelli che scrivono la maggion parte del programma durante il collaudo, davanti alla macchina o impianto che sia, non possono pensare di lasciare quando editato, senza commenti; E' vero che ci si impiega meno tempo (non sempre), ma lo si sprecherà tutto alla prima modifica.

Oltre che commenti e testi vari, risultano inoltre utili, se non indispensabili, una serie di grafici, rappresentazioni a blocchi e tabelle, che permettono di fissare meglio, per esempio, un concetto astratto, ricordandolo più velocemente quando viene ripreso per modifiche.

Documentazione questa che dovrebbe essere allegata al programma, quindi meglio se in formato elettronico.

Roberto

[orsoblu]

Proprio vero che tra il dire e il fare.......

Come la mettiamo quando ti viene chiesto di programmare una macchina a 15 gg di ritardo dalla consegna con una codifica che non hai fatto tu, la macchina che la vedi per la prima volta, l'impianto elettrico con mancanza di dispositivi necessari per il controllo e progettata esclusivamente pensando al funzionamento ciclico automatico senza assolutamente pensare all'avvio, arresto e scarto pezzi.

PS Dimenticavo che se tu presumi di metterci una settimana al cliente è stao detto che sarebbe il tutto pronto per l'indomani.

[Livio Orsini]

PS Dimenticavo che se tu presumi di metterci una settimana al cliente è stao detto che sarebbe il tutto pronto per l'indomani.

Continuando in questo modo al cliente verrà assicurato che basta la visione del tecnico affinchè la macchina sia pronta a produrre! :ph34r:

La tragedia vera è che i clienti sono anche disposti a crederci (o fingono)

[Gianmario Pedrani]

Io di solito scompongo il problema in tanti piccoli sotto problemi cercando di costruirmi delle piccole funzioni indipendenti come tanti mattoncini, una volta creati e provati li lego insieme secondo la logica di funzionamento della macchina che devo andare a costruire, questo mi da il vantaggio di concentrarmi sulla logica principale perche a tutto il resto pensano delle piccole funzioni che si autocontrollano, e mi sto trovando bene..... comuncue di metodi ce ne sono a migliai come sopra detto non esiste una regola precisa, l'importante e mettere giu prima sulla carta quello che poi dovra fare il tuo programma ed analizzarlo solo cosi non ti troverai a dover martellare istruzioni per fare funzionare le cose

ciaooooooooooo

[OB1-Roby]

Quanto ti è stato detto da tutti coloro che sono intervenuti nella discussione è sacrosanto!

I metodi di programmazione sono moltissimi questo perchè secondo me la programmazione è un pò come un'arte: un pittore si sbizzarrisce con i colori, un architetto con le forme, uno scultore con martelo e scalpello, un programmatore con bit, byte, word, routine e quant'altro si possa mettere in un programma.

Ciò che è veramente importante però è sapere esattamente ciò che si vuole ottenre: una volta superate le fasi iniziali a cui Livio accennava, prima di scrivere qualsiasi riga di programma bisogna già avere nella testa la traccia primaria del funzionamento di quello che si va a realizzare. Nel momento in cui poi si arriva a scrivere codice è assolutamente fondamentale ed indispensabile farcire il tutto con i commenti, scritti in modo chiaro soprattutto se si fa utilizzo di cicli indicizzati e se si utilizzano i puntatori che sicuramente ottimizzano e "snelliscono" il programma ma che mettono in difficoltà nella fase di debug.

Per concludere vorri suggerirti, una volta che hai padronanza della programmazione in ladder, di passare all'AWL o addirittura all'SCL.

Per ora (con un pò di nostalgia) ti auguro un buono studio...

Ciao

[dm27]

Grazie a tutti per i consigli che mi avete dato.

Cercherò di capirne sempre di più perchè mi rendo conto che tra lo studio e la pratica c'è un abisso.

Ciao

[Savino]

Salve,

desideravo avere informazioni su concetti di carattere generale

Dunque,

In movimentazione se potrebbe dire .............

PLC: insieme di operazioni.

Operazione: insieme di sequenze.

Sequenza: insieme di passi.

Passo: insieme di movimenti

Movimento: insieme di attuatori, rilevatori, sensori,ecc.

Saluto.

[1234]

Concordo con l'analisi di Livio, la prima parte, in genere è molto approssimativa, prima di passare alla fase vera e propria della programmazione, bisogna stabilire cosa vogliamo realizzare, le condizioni logiche che s'intendono attuare, la possibilità di attuarle ecc., poichè oggi si vuole tutto e subito, ci accontentiamo di prodotti approssimati, sui quali interveniamo ripetutamente, con spreco di soldi ed energie.

[yupanqui]

Io programmo macchine uniche nel loro genere nel senso che sono prototipi e spesso l'ingegnere che le progetta meccanicamente deve apportare modifiche nel corso del montaggio macchina perchè si accorge che non puo' funzionare come era stata pensata.

Nel frattempo io ho gia' iniziato a scrivere il programma chiaramente.....

Non per questo il mio programma si incasina come diceva livio, Infatti se si segue uno schema a blocchi sfc credo che di modifiche se ne possono fare infinite.

Certo che a volte per modificare una cosa devi riscrivere qualche pezzo di programma ma alla fine se riesci a seguire la logica sulla carta, secondo me significa che il lavoro è fatto bene!

Silver.

[Alessandro2151]

OB1-Roby perchè consigli di passare all ' AWL dopo la pratica del LADDER ?

[Livio Orsini]

Non per questo il mio programma si incasina come diceva livio, Infatti se si segue uno schema a blocchi sfc credo che di modifiche se ne possono fare infinite.

I programmi non si incasinano (per usare la tua allocuzione) perchè si devono effettuare modifiche alle funzioni della macchina. I programmi si incasinano se sono mal pensati e peggio strutturati.

Se si progetta e si struttura bene il programma, anche le successive variazioni funzionali possono essere inserite senza problemi e senza che crolli tutto come un castello di carte.

Il fatto che una macchina sia un esemplare unico o il primo di una serie non cambia i termini del problema. Prima di buttar giù istruzioni è necessario avere ben chiaro cosa si deve fare e la relativa strategia per raggiungere lìobbiettivo. Poi strada facendo le specifiche di macchina cambiano? Nessun problema! Si modifica la funzione/funzioni relative al cambiamento. Le specifiche non possono essere le tavole della legge scolpite a fuoco nella pietra!

[Piero Azzoni]

OB1-Roby perchè consigli di passare all ' AWL dopo la pratica del LADDER ?

bella domanda, perche' ?

e' come dire :

dopo aver imparato bene ad usare excel ritorna ad usare il pallotoliere.

se proprio vogliamo fare della didattica (al limite, limite teorico) diciamo :

prima di usare il ladder (ladder e' universale per qualsiasi plc) comprendi il booleiano (termine universale, solo siemens lo chiama awl)

ma senconde me oggi, 2005, anche questa metodica e' superata da un po' di tempo

[STEU]

Caro Piero Azzoni

quando inizi ad usare parametri any ,puntatori, accessi a db come se fosse un data base devi fare tracking di codici ,e non solo muovere motori e cilindri vedrai che l' AWL è senz'altro indispensabile se usi Siemens.

[Piero Azzoni]

il mio e' un discorso generale.

per mia esperenza personale e' icuramente valido su tutti i plc meno uno

tieni conto che con "gli altri" in ladder si fa matematica avanzata, movimenti diretti ed a puntatore su array anche multidimensionali interfacciamenti a cpu secondarie speciali e quant'altro

siemens ............................... e' diverso da tutti (o quasi) gli altri

non dico peggiore ......... ma piu' contorto sicuramente

Modificato: 16 febbraio 2005 da Piero Azzoni

[FranSys]

Caro Piero Azzoni

quando inizi ad usare parametri any ,puntatori, accessi a db come se fosse un data base devi fare tracking di codici ,e non solo muovere motori e cilindri vedrai che l' AWL è senz'altro indispensabile se usi Siemens.

Hai detto bene: se usi Siemens. Evidentemente i crucchi non hanno voluto creare un ambiente di sviluppo universale in ladder. Fatti loro.

Piero ha la sacrosanta ragione: in Ladder si estraggono radici, si eseguono calcoli trigonometrici, si implementano funzioni matematiche complesse (anche non lineari), si scrive sulla seriale, si riceve un pacchetto TCP/IP dalla Ethernet, si calcola una CRC, si "fanno discorsi" in ASCII, si puntano aree dati direttamente ed indirettamente, ci si muove all'interno delle matrici, si fa il push nello stack, si invia la posta elettronica (sì, anche quella), si gestische l'hot standby, si cambia al volo la configurazione di una porta di comunicazione... devo andare avanti?!

Siemens non può fare questo... e c'è qualcuno che si ostina a dire che non c'è nulla meglio dell'AWL.

Svegliaaaaaa! I crucchi vi hanno traviati! I puristi dello Step7 aprano gli occhi, si guardino intorno!

L'altro giorno lavoravo in uno stabilimento con un assistente del cliente d'estrazione puramente elettrotecnica. Un uomo non più giovane ma molto in gamba. Stavo scrivendo una routinetta per parlare in seriale con uno strumento e, trattandosi di una logica recursiva (ben inteso, non ho detto che il Ladder è sempre comodo) stavo lavorando in Structured Text. L'assistente non mi seguiva. Allora mi sono chiesto per quale motivo dovessi complicare la vita a quelli che "poi l'impianto lo devono anche far andare". Ho cancellato tutto e ho riscritto la stessa cosa in Ladder per la felicità del mio assistente di campo che se n'è andato contento con la stampa del Ladder piegata in mezzo alla sua agenda. La morale mi sembra evidente.

Ciao.

[Alessandro2151]

Premetto che non ho nulla contro l'AWL,ognuno è libero di usare quello che vuole purchè una cosa sia fatta bene ,da parte mia però mi trovo già a dovere fare i conti con le istruzioni di un compilatore che è impegnativo già per conto suo (visto che non è a contatti richiede una maggiore concentrazione anche solo visiva ) ; quindi trovo + comodo un linguaggio a contatti almeno per il PLC , diciamo che è un modo come un 'altro per rilassare la vista e la mente.

Ho amici che usano l'AWL perchè così facendo riescono a scrivere in un minore spazio un maggior numero di istruzioni , può anche essere , dal momento però che il numero di istruzioni nei PLC odierni sono di gran lunga superiori di quelli del passato non la vedo come una scelta obbligatoria ma solo come un'alternativa .

[Claudio Monti]

Allora mi sono chiesto per quale motivo dovessi complicare la vita a quelli che "poi l'impianto lo devono anche far andare". Ho cancellato tutto e ho riscritto la stessa cosa in Ladder per la felicità del mio assistente di campo che se n'è andato contento con la stampa del Ladder piegata in mezzo alla sua agenda. La morale mi sembra evidente.

Questa e' la sacrosanta realta' del "campo"!

Anch'io, se so che qualche "elettrico" dovra' guardare il programma, realizzo in LADDER, ma appena posso o quando sono sicuro che a metterci le mani sono informatici/programmatori e non gli elettricisti, PROGRAMMO ESCLUSIVAMENTE IN ST (Structured Text).

Non mi sognerei minimamente di complicarmii la vita con il IL (Instruction List - AWL solo x Siemens)!!!

Non c'e' linguaggio meno comprensibile (a parte chi e' abituato a lavorarci).

Fate un programma ST e vedrete che anche un informatico puro riuscira' a leggerlo e capirlo facilmente, provate con IL e sentirete le bestemmie!

[OB1-Roby]

L'autore della discussione sta chiaramente utilizzando Siemens ed è per questo che consigliavo AWL piuttosto che LADDER per i motivi già proposti in questa discussione (con ladder di siemens non riesci a fare tutto quello che puoi fare con awl). In linea di massima consiglio awl (come era gia stao affrontato in questa discussione e come è anche già stato ribadito in questa) perchè il laddere è sicuramente più vicino a chi ha un'estrazione elettromeccanica piuttosto che informatica anche se ho poi aggiunto, ed è sicuramente ancora meglio per chi ha un'estrazione informatica, l'SCL.

Per Claudio

Non c'e' linguaggio meno comprensibile (a parte chi e' abituato a lavorarci).

Fate un programma ST e vedrete che anche un informatico puro riuscira' a leggerlo e capirlo facilmente, provate con IL e sentirete le bestemmie!

Mi spiace ma non mi sento di poterti dare completamente ragione! Secondo me dipende tutto da come si scrive il programma e soprattuto dalla bontà dei commenti anche dei singoli bit. Prova a scrivere un qualunque banale programma in qualsiasi linguaggio senza commenti chiari e senza un filo logico che le bestemmie arrivano comunque.

In fine aggiungo che in ogni caso la scelta del ladder, awl, scl, fup o quant'altro è sicuramente soggettiva, perchè in fin dei conti nel PLC finisce sempre la stessa cosa, quello che importa seriamente è che questo qualcosa faccia esattamente il "suo dovere"! Ma purtroppo talvolta, anzi troppo spesso, sappiamo bene come vanno le cose!

Ciao

[Livio Orsini]

....perchè il laddere è sicuramente più vicino a chi ha un'estrazione elettromeccanica piuttosto che informatica ...

Verità sacrosanta OB1; parlo per esperienza diretta. Io provengo dall'assembler dai microprocessori. Ogni volta che vedo un programma scritto in ladder devo fare contorsioni mentali per capirne la logica. In pratica devo trasformare i contatti in serie in AND e quelli in parallelo in OR; per le altre operazioni è anche peggio.

Una delle poche cose buone di Siemens è che puoi programmare in AWl, che assomiglia vagamente ad un assembler, e poi automaticamente puoi rivedere il programma in ladder e viceversa.

[Alessandro2151]

Verità sacrosanta OB1; parlo per esperienza diretta. Io provengo dall'assembler dai microprocessori. Ogni volta che vedo un programma scritto in ladder devo fare contorsioni mentali per capirne la logica. In pratica devo trasformare i contatti in serie in AND e quelli in parallelo in OR; per le altre operazioni è anche peggio.

Una delle poche cose buone di Siemens è che puoi programmare in AWl, che assomiglia vagamente ad un assembler, e poi automaticamente puoi rivedere il programma in ladder e viceversa.

Ho letto il tuo profilo Livio Orsini , e ho potuto constatare che sei nato nel 1944 , e fin qui nulla di strano !

Quello che trovo strano è questo :

IL PLC

IL PLC (programmable logic controller) nasce intorno agli anni 70

come sistema di controllo nelle fabbriche prodruttrici di materiali

pesanti, in sostituzione degli ingombranti, laboriosi e meno affidabili

sistemi elettromeccanici a rele'.

Oggigiorno il PLC ha in gran parte soppiantato i quadri elettrici a logica

cablata a rele',esso e' considerato il punto di intermediazione tra elettro

meccanica ed elettronica, grazie ovviamente al miglioramento delle

tecnologie che ne permettono l'uso nei campi dove prima erano richieste

solamente schede elettroniche dedicate.

IL PLC nel campo industriale ha portato notevoli vantaggi ,che vanno dalla

riduzione degli ingombri nei quadri elettrici al notevole risparmio di apparecchi

elettrici dedicati al cablaggio di comando e controllo.Nel PLC si possono creare

rele', contatti, temporizzatori, contatori ecc ecc. in grandi quantita'.

L'economicita' d'impiego dei componenti di automazione e' strettamente legata

alle capacita' professionali dei tecnici che ne assumono la gestione d'esercizio.

La migliore qualificazione del personale e' diventata nella realta' industriale

odierna, dove apparecchiature e sistemi raggiungono livelli sempre maggiori

di complessita' applicativa, un fattore determinante per l'impiego ottimale di

potenti strumenti di automazione come i tanto amati PLC.

Ora dato questo documento che può essere + o - preciso per date o quant'altro io vorrei capire una cosa .............

ma il PLC è inquadrabile più come informatica o eletromeccanica intelligente ? ? ?

Mi è venuto questo dubbio perchè sento parlare persone come te Livio che come dici tu , sei nato con l'assembler con i microprocessori quindi elettronica pura , correggimi se sbaglio , mentre il PLC si è avvicinato di più elettrotecnica industriale a sostituire quella miriade di rele ( che qualcuno ancora oggi sostiene che erano meglio ) e timer e quant’altro era in commercio .

A mio parere il PLC si accosta all’informatica ma non è informatica pura o sbaglio ?

Altra definizione :

Comprendere la funzione del linguaggio formale nella comunicazione uomo-macchina

L’utilizzo di un linguaggio formale consente di passare da un algoritmo al corrispondente programma.

Si dice programma una sequenza di istruzioni espresse in un linguaggio formale (linguaggio di programmazione) mediante le quali si può risolvere un problema.

L’esecuzione di un programma è un evento che trasforma dati in risultati.

Dal confronto tra la definizione di algoritmo data in precedenza e quella di programma, risulta evidente che la differenza sta nel modo in cui le istruzioni sono codificate.

Una prima distinzione può essere fatta tra:

1. linguaggi non evoluti o di basso livello (linguaggio macchina, linguaggi assemblativi);

2. linguaggi evoluti o di alto livello (algoritmici, speciali).

Ogni processore ha un proprio linguaggio, detto linguaggio macchina, che ad ogni stringa di bit fa corrispondere una operazione elementare. Questo tipo di linguaggio è molto lontano dal modo di ragionare dell'uomo. Inizialmente l’attività di codifica di algoritmi, lavoro lungo e difficile, era riservata solo a tecnici super specializzati. In seguito furono creati dei linguaggi intermedi con cui scrivere i programmi. Per l’utilizzo di un algoritmo codificato in questo modo è necessario un apposito programma traduttore che converte il programma originale (detto file sorgente) nelle corrispondenti istruzioni in linguaggio macchina (ottenendo così il file oggetto). Il primo di tali linguaggi fu il linguaggio Assembler, in cui al posto di ogni istruzione macchina viene usato un codice mnemonico ad esso associato. L'Assembler è ancora molto vicino alla logica del processore.

Successivamente sono stati ideati linguaggi non più orientati alla macchina, ma orientati alla soluzione di problemi. Con tali linguaggi, indipendenti dal processore e dalla particolare macchina, il lavoro del programmatore risulta semplificato. Le istruzioni e i dati da esse manipolati vengono rappresentati simbolicamente e viene delegato alla macchina il lavoro ripetitivo e deterministico della loro traduzione in codifiche binarie

Dato quanto sopra citato una persona come te come riesce ad avere un felice approccio con i PLC visto con quale scuola di programmazione sei nato e cresciuto ???

Nel senso che il PLC dovrebbe essere un salto all’indietro , o no ?

E preferisci il Siemens perché si avvicina all’assembler grazie all?AWL ?