Programmazione AWL Siemens

[Nicola Scanavacca]

Salve a tutti ,

 l'azienda dove lavoro ricercano una figura che si occupa sia della parte meccanica e anche la parte softwere (per l'installazione di macchinari) , ho deciso di ricominciare a studiare la programmazione.

Premetto ho il diploma di perito meccanico , ma durante il periodo scolastico (terminato un paio di anni fa) mi sono interessato alla programmazione di plc , in particolare avevo fatto un corso extrascolastico con Plc Omron. Utilizzavo il linguaggio di programmazione ladder diagram .

Dove lavoro la parte softwere viene gestita da Plc Siemens , step 7 , ed il linguaggio utilizzato è awl misto al kop (ma principalmente awl). 

In questo periodo non mi trovo in italia perchè sto effettuando una installazione all'estero , ho ricercato in internet del materiale per cominciare a studiare awl dato che ho conoscenza del solo linguaggio kop , ho comprato anche un paio di e-book ma niente da fare . Stesso discorso per quanto riguarda i videocorsi su youtube ed i manuali siemens . 

Cosa mi consigliate di fare? 

[Ctec]

Condivido.

Tra l'altro, i PLC Step-7 (S7-300) sono oramai fuori produzione da anni.

[batta]

Il problema è che, se deve mettere le mani su programmi esistenti scritti in awl, dovrà imparare awl.
Anche per poter convertire i programmi in strutturato, dovrà comprendere l'awl.
Senza tralasciare che parlare di conversione non è nemmeno corretto, perché se si cerca di tradurre pari pari da awl a strutturato (ma anche da ladder a strutturato o viceversa), ne esce solo una grande porcata. Per ottenere un buon risultato, si deve comprendere il programma, e riscriverlo adattandolo al nuovo linguaggio.
Solo che non saprei cosa suggerire per imparare. Non so se esistono veri e propri manuali di programmazione in awl. Io non ne ho mai visto uno.
Il linguaggio in sé è molto semplice, con poche istruzioni, tutte documentate nella guida in linea.
Per i calcoli, si deve capire come si lavora con gli accumulatori, ma non è difficile.
Molto importante è la gestione dei salti.

Poi, prendendo un programma scritto da altri (mi auguro con i commenti), si interpretano le istruzioni una per una, e si cerca di capire a quale risultato portino.

 

A me, personalmente, dispiace un po' che stia per essere accantonato. Non è quel mostro che molti dipingono. Attualmente io stesso mi impongo di non usarlo, ma ci sono ancora alcune cose che in awl verrebbero molto bene.
 

[batta]

18 minuti fa, Yiogo ha scritto:

per quanto riguarda i salti, diciamo anche che erano necesari ai primordi quando avevi a disposizione un unico blocco

Non è solo quello. Per esempio, una semplice operazione matematica, in AWL, viene sempre eseguita, non è legata al risultato logico precedente. L'unico modo per non eseguirla, è saltarla. O, se preferisci, quando la vuoi eseguire, devi non saltarla.

Nei vecchi plc poi, saltare intere parti di programma quando non serviva elaborarle (non mi riferisco solo a S5, ma anche alle cpu meno performanti S7-300/400), aiutava molto a ridurre i tempi di scansione. Ora le prestazioni sono molto migliorate, e questa esigenza quasi non si sente più ma, in passato, talvolta era fondamentale.

 

Su AWL poi, io farei un appunto: mentre è corretto chiamare, rispettivamente, LD, FBD e ST ciò che Siemens chiama KOP, FUP e SCL, non è corretto identificare AWL con IL.

Sì, è una lista di istruzioni, ma con regole e sintassi ben diverse da quello che è il normale linguaggio IL.

[leleviola]

1 ora fa, batta ha scritto:

Nei vecchi plc poi, saltare intere parti di programma quando non serviva elaborarle (non mi riferisco solo a S5, ma anche alle cpu meno performanti S7-300/400), aiutava molto a ridurre i tempi di scansione. Ora le prestazioni sono molto migliorate, e questa esigenza quasi non si sente più ma, in passato, talvolta era fondamentale.

Verissimo passato da 70-100ms di scansione a 5ms di scansione con i salti di parti di programma non necessarie

e passare a tali scansioni può voler dire far girare un vecchio telaio telaio Karl Meyer a 300 battute il minuto e far sbuzzare gli occhi al commissionante il lavoro

al non fare il lavoro.

Oggi giorno con le prestazioni che c'è quasi non ce n'è bisogno,

di contro i programmi occupano sempre più spazio

[Nicola Scanavacca]

Il 30/3/2020 alle 15:59 , batta ha scritto:

Il problema è che, se deve mettere le mani su programmi esistenti scritti in awl, dovrà imparare awl.
Anche per poter convertire i programmi in strutturato, dovrà comprendere l'awl.
Senza tralasciare che parlare di conversione non è nemmeno corretto, perché se si cerca di tradurre pari pari da awl a strutturato (ma anche da ladder a strutturato o viceversa), ne esce solo una grande porcata. Per ottenere un buon risultato, si deve comprendere il programma, e riscriverlo adattandolo al nuovo linguaggio.
Solo che non saprei cosa suggerire per imparare. Non so se esistono veri e propri manuali di programmazione in awl. Io non ne ho mai visto uno.
Il linguaggio in sé è molto semplice, con poche istruzioni, tutte documentate nella guida in linea.
Per i calcoli, si deve capire come si lavora con gli accumulatori, ma non è difficile.
Molto importante è la gestione dei salti.

Poi, prendendo un programma scritto da altri (mi auguro con i commenti), si interpretano le istruzioni una per una, e si cerca di capire a quale risultato portino.

 

A me, personalmente, dispiace un po' che stia per essere accantonato. Non è quel mostro che molti dipingono. Attualmente io stesso mi impongo di non usarlo, ma ci sono ancora alcune cose che in awl verrebbero molto bene.
 

Ho trovato un programma che si chiama codesys , può essere un buon inizio per cominciare a studiare ?

[batta]

Non quotare l'intero messaggio, crea solo confusione.

 

1 ora fa, Nicola Scanavacca ha scritto:

Ho trovato un programma che si chiama codesys , può essere un buon inizio per cominciare a studiare ?

Per il testo strutturato (e non solo), sicuramente sì.
Per AWL, non ti serve assolutamente a nulla, perché IL del Codesys è lontanissimo da AWL Siemens.

[rguaresc]

Qualche documento per AWL

 

ListaIstruzioni

GenericoSTEP7

manualeAWL_spagnolo

 

[lucios]

Quote

sto prorio in questo periodo lavorando su un vecchio S7 tutto in AWL,   non mi esprimo che è meglio, mi sembra di essere tornato indietro di 30 anni fa .....

Eh, AWL è per uomini duri, che non devono chiedere mai...😂😂

[batta]

7 ore fa, Yiogo ha scritto:

non mi esprimo che è meglio, mi sembra di essere tornato indietro di 30 anni fa .....

Sai che io, invece, con awl mi trovo a mio agio, anche se ho smesso di utilizzarlo per nuovi programmi.
Poi, bisogna vedere come è stato scritto il programma, e se ci sono commenti.

Anche un programma in strutturato, se non commentato, potrebbe essere di interpretazione non immediata.
In un certo senso, è il linguaggio più semplice di tutti: si interpretano le istruzioni riga per riga.
Certo che se trovi segmenti ricchi di parentesi, l'interpretazione diventa sicuramente difficile, ma la colpa, in questo caso, non è del linguaggio, ma di chi ha utilizzato il linguaggio in modo improprio.

Modificato: 1 aprile 2020 da batta

[Ctec]

Stavolta quoto Batta. Lo AWL può essere paragonato a un linguaggio assembler per i processori, vedi l'uso dell'accumulatore. Mentre gli altri (no lo IL, per me sempre simile all'assembler), mentre gli altri (ladder, ST, SFC) sono paragonabili a linguaggi di livello più elevato (basic, C, pascal, ecc).

Ma come spesso mi accade, per operazioni critiche, a volte è necessario poter scrivere routine in assembler in programmi in C (oppure chi non ricorda righe di POKE in basic...).

Chiaramente, avendo invece oggi strumenti migliori, difficilmente scriveremo un intero software in assembler (o AWL).

Poi è verissimo, commentare sempre i programmi e più approfonditamente possibile. Non vi capita mai di dover rimettere mano a un VOSTRO software scritto 10 o 20 anni fa e senza commenti ci mettereste una vita a capire cosa avevate fatto allora?

[batta]

1 ora fa, Ctec ha scritto:

Non vi capita mai di dover rimettere mano a un VOSTRO software scritto 10 o 20 anni fa e senza commenti ci mettereste una vita a capire cosa avevate fatto allora?

Proprio così, ma anche senza risalire così indietro nel tempo.
Nei miei programmi, in AWL (che ora mi impongo di non usare più, se non strettamente necessario) o in strutturato, non è raro che i commenti siano più del codice.
Se ci sono operazioni non immediatamente comprensibili, commento ampiamente anche i segmenti in ladder.
Ma mica per altruismo, sia chiaro, ma per capire cosa ho fatto quando ci rimetto le mani dopo un po' di tempo.

[leleviola]

55 minuti fa, batta ha scritto:

Se ci sono operazioni non immediatamente comprensibili, commento ampiamente anche i segmenti in ladder.
Ma mica per altruismo, sia chiaro, ma per capire cosa ho fatto quando ci rimetto le mani dopo un po' di tempo.

In pratica solletichi la sinapsi nel cervello e tutto in un attimo ritorna a mente portandoti a capire cosa avevi fatto

[batta]

9 minuti fa, leleviola ha scritto:

In pratica solletichi la sinapsi nel cervello e tutto in un attimo ritorna a mente portandoti a capire cosa avevi fatto

Sì, a volte basta poco per far riaffiorare dai ricordi i motivi di una scelta.
Inoltre, scrivere mi aiuta anche a fissare nella mente ciò che devo fare. In pratica, scrivo in parole cosa intendo fare, e poi lo traduco in codice.
Molto spesso poi non descrivo solo quello che dovrebbe fare il codice, ma anche il perché.
Esempio banale, solo per chiarire: se in un certo punto del codice, supponiamo, azzero una variabile, non mi limito a commentare: "Azzero la variabile" (sarebbe un commento piuttosto insulso), ma scrivo: "Azzero la variabile in questo punto del programma, per questi motivi...).
Altro esempio: a volte un ciclo si può fare con un FOR o con un WHILE. Il FOR è molto più usato ma, in alcuni casi, mi è capitato di preferire il WHILE.
Nei commenti, scrivo le motivazioni che mi hanno portato a preferire il WHILE al FOR.

Inutile dire che, nella programmazione, è fondamentale l'ordine in cui le istruzioni vengono eseguite. In alcuni casi l'ordine corretto non è immediatamente comprensibile.
In questi casi, scrivo qualcosa del genere: "ATTENZIONE!!! Questa operazione deve assolutamente essere eseguita dopo quella tal operazione, per questi motivi...".

Quando mi trovo a mettere le mani su programmi poco o per nulla commentati, mi si risveglia la colite 😉

[Livio Orsini]

20 minuti fa, batta ha scritto:

Molto spesso poi non descrivo solo quello che dovrebbe fare il codice, ma anche il perché.

 

Questa è un'ottima cosa perchè spesso, riguardando un lavoro fatto qualche hanno addietro, ci si chiede: "Ma perchè ho fatto così?" Se nei commenti si è messo un appunto sulle motivazioni della scelta, torna alla mente tutta la strategia pensata per risolvere quel problema.

Io uso mettere dei paragrafi di commento, esplicativi della strategia, sia in testa alle funzioni, sia in punti strategici del "main".

Modificato: 2 aprile 2020 da Livio Orsini