Programmazione A Oggetti Su Plc

[beasrl]

Che ne dite di creare un nuovo modello di programmazione PLC basata sugli oggetti ...

e parlo di oggetti con la "O" maiuscola non di istanze di FB o cose simili.

date un'occhiata qui http://www.enter-the-next-level.com/index....mainfeatures_en

[Federico Milan]

Credo che sia benedistinguere la programmazione ad oggetti da una programazione a basso livelo per PLC.

Credo sia indubbio il vantaggio di programmare con il paradigma adogetti, ma bisognaessere coscenti di csa comporta.

Credo che sia visibile chiunque che la programmzione occupa "parecchio" spazio in memoria (creazione dell'istanza, apoggi vari per l'ogetto), lentezza (utilizzo di più riferimenti e necessità di instanziare/referenziare l'oggetto), problemi di sicurezza (memori Lekage, ...), ...

Forse in dispostivi limitati conviene ancra la programmazione procedurale che permette non solo di scrivere ordinatamente il software e di debugare in modo "semplice" ma togli dall'impiccio di nuove prblematiche ...

[lucios]

C'è stato un pò di tempo fa un costruttore di cnc (di cui non faccio il nome per decenza) che ha implementato la parte plc con una struttura ad oggetti (con una versione realtime di Linux e programmato in Pithon). I risultati sono stati molto deludenti, sia a causa della particolare versione del sistema operativo, sia a causa della programmazione ad oggetti che, come fa notare giustamente Federico, mal si adatta al funzionamento tipico di un plc.

Ciao

[Savino]

Salve,

Dunque, i linguaggi PLC orientati agli oggetti ci sono gia' da un pezzo a questa parte.

SIMATIC APT e' senzaltro un PLC object-oriented language che offre una interfaccia editor di SW strutturato ad oggetti e posteriore emulazione sulle cpu della Siemens Ti505 family e parte della famiglia SIMATIC S5.

Esempio d'indirizzamento ad oggetti:

BLOCK
//{

PRAGMA("SF");
ARRAY (1 ..4 )OF REAL : REAL32_0 := 0.0; 

//}
BLOCK.ENABL := TRUE;   // abilito il blocco BLOCK to RUN

BLOCK.REAL32_0 [0] := 342,56;  // accesso al primo elemento del array appartenente all'oggetto.

Un oggetto viene identificato in memoria attraverso un indirizzo.Questo potrebbe essere costruito sulla base di una classe.

Ci sono gia'linguaggi PLC fondati su delle strutture di controllo tipo C++ e PASCAL che sfruttano a punto questa filosofia.

Modificato: 18 gennaio 2007 da Savino

[Federico Milan]

Scusa Savino,

ma per me un linguaggio ad oggetti non è una emulazione fatta con un linguaggio procedurale, e del resto non mi piace la definizione che per fare OO ci voglia dati e istruzioni insieme ... altrimenti un FB Siemens è un oggetto ... potremo esserci quasi, ma manca il concetto di eriditarietà e poliformismo, tra i quali poi vi è il concetto di interfaccia, di overloading, di overriding ...

Diciamoche secondo me, non basta instanziare in Ram una zona di memoria per definirla ogetto, in quanto la OO è un paradigma e non un vero metodo di allocare memoria .

Del resto, sono convinto che un linguaggio ad alto livello semplifichi la stesura del software, ma bsogna essere copscenti dei pro e dei contro.

[fabri]

Diciamoche secondo me, non basta instanziare in Ram una zona di memoria per definirla ogetto, in quanto la OO è un paradigma e non un vero metodo di allocare memoria

nel codesys, ma anche nell'esempio di savino non viene utilizzato il costruttore dell'oggetto, per cui l'oggetto viene allocato in memoria solo quando il programmatore scarica il programma

nel caso dei plc il paradigma di programmazione per oggetti viene tirato per i capelli, per cui parlerei magari di linguaggio strutturato "molto evoluto"

altrimenti il tuo programma dovrebbe contenere anche una specie di gestore della memoria (pensa se gli oggetti esauriscono tutta la memoria disponibile)

in ogni caso un plc che fa con la memoria quel che gli gira piuttosto che quello che decido io mi sembra un pericolo (errori di programmazione a parte)

Ciao, Fabrizio

[Savino]

Ciao Federico,

non è una emulazione fatta con un linguaggio procedurale

Ok!

Ma attenzione, in APT (che ha apross. 15 anni di vita o di piu') non succede esattamente cosi'... Il polymorphism ,mm behh bisognarebbe vedere se e' possibile ottenerlo in una struttura PLC , ma l'inheritance ci sarebbe...

Ad esempio APT fornisce una serie di oggetti, Devices( valves, motors,cylinders, etc) che potrebbero venire utilizzati da una applicazione PLC. Questi oggetti potrebbero essere considetrati come delle "base classes" dai quali e' possibile derivare le loro functionalities.

Per esempio le propieta' di un oggetto CSD ( cylinder single drive) viene ereditato (inherited) da due sottoelementi (subclasses) MyCyl1 e MyCly2.

Name : MyCyl1
Type : CSD
Energized state : E (when extend)
Extend/Retract command : Y_MyCyl1
Extended Limit Switch  : MyCyl1.ELS
Retracted Limit Switch : MyCyl1.RLS
Extend alarm time : 3.0 seconds.
Retract alarm time: 2.0 seconds.
...
..
etc.

Name : MyCyl2
Type : CSD
Energized state : E (when extend)
Extend/Retract command : Y_MyCyl2
Extended Limit Switch  : MyCyl2.ELS
Retracted Limit Switch : MyCyl2.RLS
Extend alarm time : 3.0 seconds.
Retract alarm time: 2.0 seconds.
...
..
etc.

Poi da qualche parte dal programma ..

..
NOT(MyCyl1.RLS)  // if is not retracted
..

Y_MyCyl2 := TRUE;  // extend cyl2

Come Java usa "the extends Keyword", APT usa "the dot extensions" metodo per impostare la relationship tra una child class e una parent class.

altrimenti un FB Siemens è un oggetto

Questo e' diverso agli FB di S7. Qui non si tratta di elaborare una function, dando dei valori in ingresso e ricavandone dei valori in uscita. Senon che un oggetto viene costruito ereditando le functionalities di una oggetto "base".

....

Comunque, sarebbe fattibile utilizzare OOP technologies per sviluppare PLC SW seguendo lo standardIEC-61131-3, come ad esempio con dei sistemi basati su strutture di controllo tipo C++, che e' un OOP senzaltro .

Saluti.

Modificato: 19 gennaio 2007 da Savino

[lucios]

La programmazione in linguaggi OOP con C++ è senz'altro affascinante, però ci sono 2 cose, secondo me, da tener conto:

1. Ne vale la pena? Dalla mia esperienza mi rendo conto che sono cosi variegate e "verticali" le applicazioni di automazione che, affrontandole con un rigoroso orientamento agli oggetti, il tutto diventa abbastanza macchinoso. In parole povere è difficile costruire oggetti ben fatti e riutilizzabili.

2. Il debug! Io faccio un pò di fatica ad immaginare un debug ben fatto in un ambiente basato su linguaggi di questo tipo in una macchina real-time. I break-point e compagnia bella diventano abbastanza problematici....

Comunque rimane il fatto che la tecnologia avanza (e i problemi per noi poveri mortali ), quindi prepariamoci a studiare.... .

Ciao

[Savino]

Link Vedi alla fine della pagina 89 "Conclusion"...." SIMATIC Applications Productivity Tool, APT " is an intuitive object - oriented tool for efficient software development.

Se lo dicono loro stessi, allora non ho sbagliato di tanto

[Federico Milan]

Ciao,

mi affascina la discussione ... Prima vorrei solo precisare una cosa, vidto che siamo nel forum Didattica, credo che bisogna essere "precisi" almeno fino che le capacità personali lo permettono , cioè se un linguaggio è OOP per definizione deve avere il poliformismo, l'eriditarietà, ... (e tutto ciò che ci va dietro). Quindi se un linguaggio non è polimorfico non è orientato agli oggetti anche se lo si publicizza così.

La discussione è nata sull'utilità di averre OOP su PLC. Secondo me, attualmente no! per i motivi prima descritti su i post precedenti.

Diciamo però che la realtà industriale è in continua evoluzione e fare gli struzzi o essere fermi sulle proprie idee non paga. Vi sono strumenti che possono essere rogrammati con linguaggi OOP.

Se come sembra, piano piano i PLC cominciano a crescere, probabilmente verrà il momento in cui la definizione netta tra PLC e Controllo evoluto non è più tale, e in quel preciso momento linguaggi ad alto livello e orientati agli oggetti saranno molto utili, non solo per velocizzare la scrittura software ma anche per riutilizzare e mantenere il software stesso.

Attualmente, il vincolo è: Spazio e prestazioni e "robustezza dell'aplicazione". Con i PLC attuali a mio avviso non siamo ancora pronti per l'utilizzo di OOP.

Il tema: è utili pensare ad un futuro OOP per i PLC? Probabilmente si, ma sotto stretti vincoli. Il prodotto deve essere specializzato (c'è qualcuno che ha "inventato" i PAC), cioè dove il manutentore di turno ha capacità/istruzione/... di grado molto superiore all'attuale (per ovvi motivi). Il prodotto deve essere specializzato (non "general purple"). Sotto questi aspetti e vincoli è possibile partire alla definizione del prodotto. Il linguaggio di programmazione può essere qulunque, certo che un C++ a mio avviso non lo vedo (sintassi potentissima, ma difficile da applicare, librerie standar troppo estese e complesse) - si dovrebbe costruire un sub set del c++, cosa poco furba -. Sicuramente, sarebbe utile un linguggio con una curva di apprendimento bassa, orientato allo scripting. Quindi non vedo ne java, ne c#, ...

quello che vedrei come linguaggio, è qualcosa di simile al phyton, rubby, ... linguaggi nati per scopi diversi ma che il loro essere script si adattano a scrivere paradigmi ad ogetti in formato script ... Ecco qui però si accende una discussione che potrebbe non finire più .. ma, per me molto interessante.

Tornando con i piendi sul pavimento ... io programm per PLC e supervisone da alcuni anni, e dalla mie esperienza non ho tratto benefici sensibili ad adottare paradigmi OOP su PLC, ma ho tratto benefici sull'utilizzo delle machine a stati (e teorie connesse). Ok, una macchina a stati è definibile elegantemente anche in OOP, però in procedurale è molto semplice spiegarla al manutentore di turno, occupa meno spazio, e si può estendere comunque con molta facilità ...

in fine, ora tocca a voi dire cosa pensate, e eventulmente se avete mai effttivamente tratto benefici su OOP (ma quella vera ) e soprattuto in quale specifica occasione ...

Modificato: 20 gennaio 2007 da Federico Milan

[Savino]

Ciao,

Dunque, in APT l'encapsulation e l'inheritance ci sarebbero. Quello che bisognerebbe sapere e' se il polymorphism sarebbe fattibile, cioe'la costruzione di classi parent (blocchi basi) che encapsuleno delle pure virtual functions che successivamente potrebbero venire eredate da distinti blocchi child che implementerebbero in "forme" diverse. Forse il limite appunto sarebbe nella ossoleta architettura dei PLC in questione( data types, memory management..)

Comunque, sarebbe interessante saperne di piu' da questo Codesys SW... appunto come gestirebbe il "polimorfismo".. e su quali CPU sarebbe applicato.

[lucios]

SIMATIC Applications Productivity Tool, APT " is an intuitive object - oriented tool

Ho dato un'occhiata veloce ma ti prometto che leggerò per bene il documentone sull'APT.

Ma, caro Savino ( il mio inglese è abbastanza scarso), se ho capito bene per fare gli oggetti "Tortellini" occorre programmare ad oggetti ? :lol: :lol:

Ciao

[mpazzi]

All' MC4 a Bologna ho visto effettivamente che altre aziende tedesche stanno introducendo linguaggi a testo strutturato con librerie dedicate con le quale implementare "Metodi". Ovviamente si poteva già fare in passato (M7 Siemens ad esempio) con il c++, ma bisognava scriversi buona parte delle classi da zero...ora invece molte sono già preconfezionate.

Personalmente ritengo che per applicazioni di digital I/O i linguaggi tradizionali siano ancora i piu versatili, soprattutto dal punto di vista del manutentore a caccia di guasti. Per applicazioni di motion e sincronizzazione forse un linguaggio strutturato magari ad oggetti può permetterti un ingegnerizzazione ed una manutenibilità del codice superiore.

Insomma è un po come per l'informatica gestionale, molti developer affermano che è bene conoscere diversi linguaggi, in modo da scegliere di volta in volta quello più consono al problema da risolvere. (come poi facciano ad imparare così tanti linguaggi ed essere subito produttivi questo è un altro problema

Cordialità

[TRUNC]

Comunque, sarebbe interessante saperne di piu' da questo Codesys SW... appunto come gestirebbe il "polimorfismo".. e su quali CPU sarebbe applicato.

Per saperne di più...

Su quali CPU è applicato...