Manuali su testo strutturato ST

[Maximilian01]

Salve a tutti, per motivi di lavoro mi trovo a dover imparare a programmare utilizzando il testo strutturato, in particolare per la programmazione dei moduli Beckhoff.

 

Parto da zero, non conosco quasi nulla di programmazione. Mi è stato indicato, in azienda, di riferirmi al sito specifico Beckhoff per lo studio dello strutturato ma avrei bisogno di qualcosa di ancora più chiaro.

 

Potete indicarmi dispense o manuali per chi, come me, ha bisogno di partire dalle basi dell' ST?

 

Grazie per le eventuali risposte

[rr7788]

Qualcosa si trova sul sito siemens

[ETR]

Ciao Max, io starei lontano sa Siemens, in quanto ti legherebbe troppo a concetti propri del suo mondo (sia HW che SW), dato che dovresti poi programmare con qualcosa di differente.

 

Se vuoi rimanere nel generico, proverei prima con una ricerca pura :

 

PLC Open

UNI

 

Dopo, passerei alla documentazione specifica di Beckoff.

 

Comunque li contatterei per un webcorso o qualsiasi altra cosa che ti permetta di destreggiarti, perché il rischio è quello di un bagno di sangue in termini di ore.

 

Buona serata, Ennio

[Maximilian01]

4 ore fa, rr7788 ha scritto:

Qualcosa si trova sul sito siemens

Grazie per aver risposto e per l'informazione 

[valvolina]

ciao

si tratta di programmazione in Twincat 3?

se hai qualche problema specifico prova a postarlo

magari ti posso dare indicazioni.

una cosa che puoi fare è installarti il TC3-InfoSys.exe che trovi nella sezione downloads sul sito di Beckhoff

va installato a parte rispetto a Twincat 3 ed è come . in linea

 

un saluto

Valvolina

[Maximilian01]

4 ore fa, ETR ha scritto:

Ciao Max, io starei lontano sa Siemens, in quanto ti legherebbe troppo a concetti propri del suo mondo (sia HW che SW), dato che dovresti poi programmare con qualcosa di differente.

 

Se vuoi rimanere nel generico, proverei prima con una ricerca pura :

 

PLC Open

UNI

 

Dopo, passerei alla documentazione specifica di Beckoff.

 

Comunque li contatterei per un webcorso o qualsiasi altra cosa che ti permetta di destreggiarti, perché il rischio è quello di un bagno di sangue in termini di ore.

 

Buona serata, Ennio

Grazie Ennio. Il manuale che trovo al link "uni" secondo te può essere sufficiente per uno quasi a zero in programmazione st? 

[Maximilian01]

1 ora fa, valvolina ha scritto:

ciao

si tratta di programmazione in Twincat 3?

se hai qualche problema specifico prova a postarlo

magari ti posso dare indicazioni.

una cosa che puoi fare è installarti il TC3-InfoSys.exe che trovi nella sezione downloads sul sito di Beckhoff

va installato a parte rispetto a Twincat 3 ed è come . in linea

 

un saluto

Valvolina

Grazie per la risposta. Ho già il TC3. Il punto è che devo iniziare quasi da zero in programmazione ST. Sto cercando manuali o guide o dispense per chi, come me, deve iniziare. Sai dove posso trovarne? Grazie 

[valvolina]

ciao,

 

esiste ad esempio un libro

 

PLC Controls with Structured Text (ST): IEC 61131-3 and best practice ST programming

 

oppure puoi fare riferimento al sito info sys di Beckhoff, dove puoi trovare anche degli esempi

 

 

oppure trovi un manuale structured text tutorial in pdf su plcaccademy, che fa riferimento a Siemens come plc.

Poi devi contestualizzarlo in riferimento a Twincat 3

 

un saluto

Valvolina

 

 

[Maximilian01]

Ciao, come dicevo sopra, avevo necessità di qualcosa di più esplicativo rispetto a quello che avevo già letto sul sito di Beckhoff. 

 

Grazie per il primo suggerimento, faccio una ricerca.

[batta]

Il 27/3/2020 alle 17:30 , ETR ha scritto:

Ciao Max, io starei lontano sa Siemens, in quanto ti legherebbe troppo a concetti propri del suo mondo (sia HW che SW),

Tua personale opinione.
Per quanto riguarda il testo strutturato, non è assolutamente diverso dagli altri.
Per quanto riguarda l'hardware, ogni costruttore ha il proprio hardware.
Ci possono essere molti motivi, se uno vuole, per rimanere lontani dal mondo Siemens (come anche per rimanere lontani dal mondo Beckhoff, o B&R, o qualsiasi altro, del resto), ma non certo questi.

[Lucky67]

11 ore fa, batta ha scritto:

Per quanto riguarda il testo strutturato, non è assolutamente diverso dagli altri.

 

Pur essendo avverso a Siemens e dovendolo usare a malincuore ogni tanto (si deve purtroppo portare la pagnotta a casa) debbo  dire che siemens ha miliardi di difetti ma cercando anche in rete si trovano milioni di documenti sul linguaggio strutturato e quindi per imparare credo sia il più indicato. Poi che beckoff, come siemens e come tutti abbiano delle "inflessioni dialettali" è fisiologico ma tutto sommato ci sta.

 

[Maximilian01]

Chiaramente non ho (al momento) competenze per poter sviluppare una riflessione, pertanto mi fido di quanto dite avendo di sicuro molta più esperienza in materia di me. 

Grazie per i suggerimenti, dei quali terrò conto

 

[Marco Mondin]

Un po' tardi, ma arrivo anche io qua!
Premetto che si tratta di un consiglio personale frutto di esperienze vissute da me che potrebbero non corrispondere a quelle vissute da altri.

1 - Io consiglio sempre di partire da CODESYS puro se si tratta di un suo derivato come Twincat, vari prodotti Schneider, prodotti ABB etc...
I derivati CODESYS sono centinaia, praticamente una grossa fetta dei non big e stanno aumentando giorno dopo giorno.
Tale consiglio deriva dal fatto che programmando con quello che mette a disposizione il CODESYS puro si porta tutto senza grossa difficoltà da un sistema all'altro. Usando invece i fronzoli aggiunti da uno specifico produttore (Essendo disponibile un SDK CODESYS lo fanno in tanti) possono essere cavoli acidi e perdite di tempo.

2 - L'ST dei derivati CODESYS è molto più potente di quasi tutti gli altri ST, in quanto non pone limitazioni che impongono gli altri convinti che quasi tutti i softwaristi che lavorano in automazione siano caproni e sia meglio non esporre certi strumenti per evitare casini. Questo lo dico per certo perché collaboro direttamente con alcuni piccoli produttori e conosco personalmente responsabili tecnici di grossi produttori e tutti, dico tutti me lo hanno detto direttamente!

3 - Prima di tutto ti consiglio la parte introduttiva di un buon libro o dispensa dedicata al paradigma Object Oriented, in quanto i derivati CODESYS puntano molto su questo, mettendo a disposizione quasi tutto quello che serve per gestire ereditarietà e polimorfismo. Non ha la gestione dei template, ma poco male in automazione dove gli applicativi a livello logico di solito sono molto più semplici che su un PC. In CODESYS i Function Block, diventano vere e proprie classi e possono essere usati come tali. Questo fornisce strumenti per la portabilità che fino a poco tempo fa nel mondo dell'automazione sembravano un miraggio. (P.S. tale paradigma in CODESYS se uno vuole si applica anche al LADDER senza problemi).
Molti sostengono che ST CODESYS e ST dei big siano uguali! È come dire che C e C++ sono lo stesso linguaggio, quando C++ ingloba un C, ma non è C! È qualcosa di molto più grande! C è il pianeta terra, C++ il sistema solare fino alla fascia di Kuiper! La stessa cosa vale per ST IEC 61131-3 versione 3 di CODESY e ST IEC e non versioni < 3. Quando si analizza un linguaggio di programmazione non ci si deve fermare alla sintassi! Altrimenti potrei dire che JAVA è quasi un C senza puntatori e poche aggiunte quando sono cose radicalmente diverse come concezione di paradigma di applicazione.

4 - Poi ti consiglierei un buon libro di teoria sugli automi a stati finiti, in quanto soprattutto nel mondo dell'automazione e soprattutto in ST esprimono la loro potenzialità e permettono di rendere gli applicativi molto ben strutturati, separando ogni piccolo dettaglio e permettendo di rendere molto indipendenti i vari pezzi di un grosso applicativo, a patto di progettare bene.
Una buona progettazione di macchine a stati finiti per altro permette di ottimizzare in modo spaventoso gli applicativi, facendo girare l'impossibile su CPU microscopiche (Concetto che non va molto d'accordo con le politiche commerciali dei big, in questo modo ho esternato uno dei motivi per cui non apprezzo i big come SIEMENS etc... Non apprezzo chi mettendomi paletti mi impone l'acquisto di un ferrari quando con la 500 faccio lo stesso).

5 - Famigliarizzare molto bene con il concetto di privacy sulle proprietà, considerando come proprietà anche gli oggetti di campo. Questo permette una maggiore riciclabilità di ogni pezzo di codice. Per esempio se ho un oggetto contropunta che ha un sensore di contropunta avanti, da un oggetto mandrino è una idea molto malsana leggere direttamente il sensore della contropunta! È il classico esempio di violazione della privacy!!! Se io fossi la contropunta mi offenderei!!! Scherzi a parte, la contropunta deve possedere una proprietà esposta agli altri che indica lo stato di contropunta avanti! In questo modo se un giorno quella contropunta diventasse priva di sensori e avesse magari un trasduttore di posizione, non dovrei toccare il mandrino! Lui continuerebbe a chiedere alla contropunta "Di! Ma sei avanti???" e la contropunta continuerebbe a rispondere "Si si!!! Tranquillo sono avanti!".
Questo, a parte i vari termini scherzosi che ho usato, slega totalmente il mandrino dal dettaglio implementativo della contropunta. 

6 - Assodati i vari concetti partire con la pratica su ST accompagnati dalle guide beckhoff o codesys, che in parte si ricalcano e sono perfettamente identiche, in altri e meglio l'una ed in altri ancora l'altra. Per esempio ho imparato ad usare la shared memory di CODESYS sulla guida beckhoff.

Programmare in ST usando la mentalità classica, a meno che non si tratti solo di semplificare cose che in ladder sarebbero tediose (calcoli, formule, etc) sarebbe controproducente.
Renderesti il codice meno leggibile che in ladder senza trarne vantaggi.
Con mentalità "classica" è meglio continuare a mischiare i linguaggi, usando il LADDER dove conviene e ST per semplificare cose che in ladder sono tediose. 

Programmare in ST con un paradigma diverso da quello classico, a volte può portare a vantaggi indiscussi sul LADDER, una minore intuitività (per chi ragiona con mentalità elettromeccanica) del codice viene ripagata da una infinità di altri aspetti. 
Programmare in ST semplifica notevolmente il processo di creazione di standard, librerie e framework, dove alla fine per realizzare progetti si compone il 90% del software come un puzzle sfruttando un mare di roba già preparata e si aggiunge un 10% specifico per l'applicazione di campo in questione.
Con mentalità "informatica" si può usare per tutto ST, ma per trarne dei veri vantaggi è necessario un background che rende il linguaggio un semplice strumento per mettere in pratica tanta teoria, non è più il linguaggio la parte difficile, ma avere voglia di smazzarsi tutta la teoria che sta alla base del paradigma.

Una piccola nota personale. Il paradigma OOP tende a rappresentare nell'informatica il mondo reale più di qualunque altro paradigma. Questo lo rende talmente intuitivo quando si affronta la teoria che lascia un po' spiazzati quando si scopre poi sulla propria pelle che tutta quella bella teoria così intuitiva, da mettere in pratica bene non è una passeggiata.
Non ci si deve scoraggiare, è solo questione di esperienza.
 

[smartpatrol]

Il 28/5/2020 alle 09:24 , Marco Mondin ha scritto:

Un po' tardi, ma arrivo anche io qua!

 

 

arrivo tardi anch'io ma penso che non ci si dovrebbe 'spaventare' davanti alla programmazione ST anche perchè non è molto diverso ad altri linguaggi evoluti (C++, Pascal,C#, vb) per cui se si conoscono quei linguaggi (per me, se si fa automazione, almeno un paio di quei linguaggi andrebbero conosciuti) si è già a buonissimo punto. 

[Alice2024]

Grazie per il primo suggerimento, faccio una ricerca.