Approccio A Plc Siemens

[sartorig]

Salve a tutti,

sono nuovo del forum e mi sono avvicinato da poco ai PLC.

Sono quindi un principiate e spero mi perdonerete se cadro' in errore ponendo questioni tipiche da principianti e magari già affrontate in altre discussioni in passato

Mi sono trovato di colpo sul campo con un PLC Siemens s7-300 e mi sento abbastanza spiazzato sebbene non sia nuovo alla programmazione in C e in assembler e alla filosofia del software real-time.

Diciamo che dopo una settimana comuncio a "capire" il KOP e l'AWL ma mi mancano i seguenti punti:

1) Non riesco a inquadrare il siemens nella logica dettata da IEC-1131.

Dovrei avere l'IL e il LD come linguaggi di basso livello, poi linguaggi di alto livello come l'ST, FDB e SFC.

Mi sembra che in realtà nel KOP (che vorrebbe essere l'LD) e nell'AWL (che vorrebbe essere l'IL) siano state "inglobate" anche istruzioni di alto livello (che dovrebbero essere prerogativa di ST) andando in una direzione molto diversa da quella indicata dalla norma, nonostante il manuale dica esplicitamente che il sistema è 1131 compliant.

2) Vorrei sapere dove trovare una descrizione chiara ed esauriente delle memorie non solo dal punto di vista logico (merker, db , ecc.) ma anche dal punto di vista fisico (ram, ram tamponata, fash ecc.) sempre che ci sia un qualche tipo di relazione tra di essi.

3) Qualche forma di debug che vada oltre l'uso delle VAT: che ne so è possibile tracciare l'andamento temporale di una memoria? o capire se il programma passa per un dato punto anche solo per un breve istante?

4) e concludo, vedo che il programma è strutturato in FC chiamate spesso senza parametri e vedo che si fa invece un largo uso di variabili globali modificate in piu' punti del programma. Ora in informatica si sconsiglia l'uso pesante di variabili globali perchè complicano la leggibilità del software, ma puo' essere che le risorse limitate di un PLC non consentano di fare altrimenti. In altre parole la domanda potrbbe essere: qual'e' il miglior modo di strutturare il programma tenendo conto che oltre ad FC esistono anche FB e OB?

Mi rendo conto che il post è venuto lungo, non pretendo che mi rispondiate esaurientemente mi basta anche qualche indicazione e suggerimento.

Grazie a tutti,

Gabriele.

[Gabriele Corrieri]

Ciao omonimo !

1) Non riesco a inquadrare il siemens nella logica dettata da IEC-1131.

Dovrei avere l'IL e il LD come linguaggi di basso livello, poi linguaggi di alto livello come l'ST, FDB e SFC.

Mi sembra che in realtà nel KOP (che vorrebbe essere l'LD) e nell'AWL (che vorrebbe essere l'IL) siano state "inglobate" anche istruzioni di alto livello (che dovrebbero essere prerogativa di ST) andando in una direzione molto diversa da quella indicata dalla norma, nonostante il manuale dica esplicitamente che il sistema è 1131 compliant.

.... take that ... ossia Siemens può per la potenza che è (nel caso presente nel settore automazione industriale, ma non solo) dettare legge, e dire che i suoi linguaggi sono xxxx compliant ... vuoi metterti contro a un colosso del genere?

Mio consiglio: non focalizzarti su una base standard che magari hai già: prendi la tua filosofia di ragionamento che hai e stendila sul plc ... secondo me impieghi meno tempo ed è menu frustrante di cercare di far funzionare una cosa come si vorrebbe quando fisicamente non può farlo.

2) Vorrei sapere dove trovare una descrizione chiara ed esauriente delle memorie non solo dal punto di vista logico (merker, db , ecc.) ma anche dal punto di vista fisico (ram, ram tamponata, fash ecc.) sempre che ci sia un qualche tipo di relazione tra di essi.

Qualche spunto ... poi dovrai spulciarti tonnellate di PDF in rete.

Merker e DB sono fisicamente la stessa cosa: porzioni di RAM, che nelle nuove CPU viene trasferita su MMC (una flash card formattata in modo particolare), al boot-up quasi* tutta la flash è caricata in RAM e parte il software applicativo, per cui è come avere una RAM tamponata ...

Poi è possibile definire delle aree a ritenzione, ossia delle aree di Merker, temporizzatori e counters ritentivi. con le nuove CPU i DB sono sempre ritentivi.

*ho scritto che "quasi tutta la flash è caricata in RAM " perchè vi sono anche i DB unlinked, DB che non sono caricati fisicamente in RAM, ma risiedono in flash, generalmente per contenere la RAM della CPU.

3) Qualche forma di debug che vada oltre l'uso delle VAT: che ne so è possibile tracciare l'andamento temporale di una memoria? o capire se il programma passa per un dato punto anche solo per un breve istante?

... by a hand in pratica (io uso fare così) nel gruppo di istuzioni incriminato che desidero sapere se ci passo dentro o no ci piazzo un bel S Mx.x (in pratica setto un merker di test) se il merker è alto allora ci son passato dentro, altrimenti no .. Ovvio poi devi ricordarti di resettarlo ... R Mx.x

Se hai PLCSim allora hai anche un debug a livello di STEPbySTEP o di singolo ciclo di scansione, altrimenti puoi guardarti il codice ONLINE mentre gira ... ma ci vuole molto colpo d'occhio per capire ciò che sta accadendo ... un po' di esperienza e anche la visione dei blocchi ONLINE è un ottimo debug

4) e concludo, vedo che il programma è strutturato in FC chiamate spesso senza parametri e vedo che si fa invece un largo uso di variabili globali modificate in piu' punti del programma. Ora in informatica si sconsiglia l'uso pesante di variabili globali perchè complicano la leggibilità del software, ma puo' essere che le risorse limitate di un PLC non consentano di fare altrimenti. In altre parole la domanda potrbbe essere: qual'e' il miglior modo di strutturare il programma tenendo conto che oltre ad FC esistono anche FB e OB?

Qui sarebbe come trasferire il mio Know-How a te ... non che sia geloso, ma ognuno ha un modo di operare meglio adatto al proprio stile di ragionamento e risoluzione problemi.

Concordo che tante sono le variabili globali ... modificate in più punti del programma (inteso come assegnazione) non concordo ... se assegno ad una variabile un valore (anche logico) in più punti non saprò mai chi l'ha assegnata nel corso dell'elaborazione: si interroga anche infinite volte una variabile ma la si assegna UNA e UNA SOLA VOLTA ... poi c'è chi fa anche diversamente: ad ognuno cercarsi le proprie rogne ...

Sperando di aver almeno dato l'input per partire poi posso sempre (o altri che ne sanno molto più di me) allargare o rispondere a quesiti più specifici.

Ciao

[sartorig]

Grazie 1000 per le dritte.

Pensavo avrei ricevuto un rimprovero per la mie domande niubbe invece ho ottenuto una rapida ed esauriente risposta :-)

Ciao,

Gabriele.

[Livio Orsini]

Mi sembra che in realtà nel KOP (che vorrebbe essere l'LD) e nell'AWL (che vorrebbe essere l'IL) siano state "inglobate" anche istruzioni di alto livello

Se leggi bene il manuale, ma anche l'help in linea, ti accorgerai che esistono due elenchi di istruzioni: quello "full compliant" e quello esteso. Ovviamente in quello esteso sono incluse anche le istruzioni ad alto livello. Sembra un sosfisma, ma questo modo di agire permette di sia rispettare le specifiche IEC, sia di avere istruzioni più "potenti"

[sartorig]

Attualmente mi fanno lavorare con Simatic Manager Step 7 versione 5.4.

Sfogliando l'. in linea non ho trovato quello che mi dici, ma puo' essere che effettivamente da qualche parte ci sia. Diciamo che quando parlo di 1131 compliant intendo anche la presenza di linguaggi di alto livello quali ST e linguaggi grafici come SFC. Ora pero' ho appreso che esiste un pacchetto opzionale denominato "Engineering" dove ci sono tutte le opzioni descritte in 1131 e anche di piu'! (addirittura c'e' un compilatore C).

A lato pratico pero' mi rendo conto che, almeno dove lavoro ora, il PLC si programma in KOP o in AWL, punto e basta! :-)

Diciamo che linguaggi di piu' alto livello possono aiutare nella modellazione del problema di automazione, ma anche con linguaggi a basso livello quali KOP e AWL si fa tutto ugualmente: serve senz'altro darsi un metodo poichè i linguaggi di basso livello non te lo impongono come invece fanno quelli di alto livello e il rischio di perdersi e fare programmi illeggibili e immodificabili è alto.

Priorpio ora mi sto' scontrando con problemi di questo genere ma è il prezzo che si deve pagare avendo seguito la peggior strada per imparare: essere buttati sul campo senza nozione alcuna.

Saluti,

Gabriele.

[Federico Milan]

Ciao,

credo che un PLC debba essere programmato con linguaggi da PLC, compilatori vari aiutano che viene da un mondo diverso ...

Secondo me i punti per adottare linguaggi di alto livello sono vntggiosi quando:

* eterogeneità dei componenti, PLC di varie marche

* processi sequenziali, statistiche con moli di dati eterogenee ma con tempistiche blande

per il resto non vi sono grossi vantaggi a livello produttivo su macchine speciali o prototipi. L'AWL di S7 è estremamente completo, e permette programmazioni dinamiche molto potenti ... a scapito di doverlo studiare e utilizzare a pieno, quindi un costo iniziale non del tutto trascurabile.

I linguaggi di alto livello sono necessari quando il PLC si trasforma in un PAC (notazione presa da National ...) e lì secondo me, solo in questo preciso campo, diventa conveniente una programmazione evoluta con linguaggi e strutture dati ottimizzate per i processi che si vanno a controllare.

ovviamente sono oppinioni, e spesso derivanti dal background proffesionale e soggettivo, quindi non verità assolute.

ciao

[sartorig]

ST e SFC sono linguaggi da PLC!!

La differenza è che sono di alto livello.

ST e SFC stanno ad IL o LD come l'ANSI C stà all'assembler per intenderci.

In ambito informatico si è sentita presto l'esigenza di liguaggi di alto livello per svincolarsi dai dettagli della macchina e concentrasi di piu' sul problema vero e proprio, pertanto è naturale che questo avvenga anche per il mondo dei PLC. E in effetti lo standard IEC 1131 nasce proprio con questo intento.

E' anche vero che nel caso di Siemens (non so per altri PLC) sia AWL che KOP sono molto potenti e dispongono di istruzioni di piu' alto livello, ma rimane il fatto che non obbligano il programmatore a seguire un metodo preciso. Cosi leggere programmi scritti da altri a volte è veramente molto difficile soprattutto se il programmatore è molto "creativo" :-) cosi come fare modifiche o aggiungere funzionalità: tutte cose già note da anni in l'informatica e che hanno portato verso linguaggi di piu' alto livello.

Ora non voglio fare l'esperto quale non sono, mi chiedevo soltanto se questi linguaggi cominciassero ad essere usati anche se credo di aver già capito che non è cosi e per molti anni continuerà ad non essere cosi.

Con questo non voglio sminuire AWL e KOP, anzi! sto' dicendo che le cose sarebbero piu' facili se si adottassero linguaggi di piu' alto livello.

Purtroppo sono molto abbattuto dalla mia scarsa capacità di seguire il funzionamento di un programma complesso e comincio a nutrire forti dubbi sulle mie capacità che prima d'ora non ha mai ritenuto notevoli ma nemmeno scarse :-(

Ho scarsa memoria e questo mi pare essere semplicemente devastante per seguire un programma PLC che risulta essere enormemente frammentato in tante FC e le variabili sono utilizzate un po' ovunque.

Forse è questione di tempo ma ormai è un mese che ci sto' lavorando sopra e sono ancora molto insicuro e mi pianto su cose banali. Non ho ancora idea di come si faccia a fare un ciclo fatto bene e di come si scelgono le memorie per transizioni da uno stato all'altro. In teoria ci si dovrebbe aiutare con un diagramma a stati ma io sto' lavorando su un tavolino da campeggio presso un cliente e il tempo stringe.

Isomma una tristezza :-(

Ciao e grazie,

Gabriele.