Differenza tra programmazione ad oggetti e non

[GioUnoNoveOttoOtto]

Un saluto a tutti,

provengo dal mondo B&R che ha un approccio molto simile dal punto di vista del funzionamento a Beckhoff.

Nella nuova azienda dove ho incominciato, utilizzano Beckhoff ma.......... l'approccio alla stesura del SW è quello della programmazione ad oggetti.

Vorrei porvi una domanda.

Partiamo da un approccio di tipo "Programmazione ad Oggetti":

Creo il mio function block che chiamerò FB (che non sarà altro che la mia classe). All'interno del mio FB dichiaro 10 metodi.
Nel mio codice, quindi, instanziero la mia classe FB, creando dunque il mio oggetto.

VAR

     myFB : FB // In pratica, qua sto creando il mio oggetto myFB appartenente alla classe FB

END_VAR

se nel codice voglio utilizzare i metodi di FB, scriverò myFB.metodo1(), myFB.metodo2() e così via...

Ad un certo punto ho la necessità di creare una classe che abbia gli stessi metodi di FB, ma che avrà anche altri metodi.

Quindi creerò la mia nuova classe FB_2 che erediterà i metodi della classe FB...

Questa è la logica della programmazione ad oggetti. Ovvero cercare di scrivere il minor codice possibile. Ottimo.

Adesso illustro il modo che io ho sempre utilizzato e che non capisco cosa abbia di diverso da questa logica ad oggetti.

 

Creo la mia struttura myStruct_FB, all'interno della quale creerò dieci function block (FB1, FB2... e cosi via)

Se all'interno del codice voglio utilizzare un function block della myStructFB, scriverò myStruct_FB.FB1.parametro1, myStruct_FB.FB1.parametro2... E così via.

Ad un certo punto ho la necessità di creare un'altra struttura che abbia gli stessi FB di myStructFB più altri function block.

Bene, creerò la mia nuova struttura myStruct_FB2 che al suo interno avrà la strutturà myStruct_FB + i nuovi function block di cui necessito.

In questo secondo modo ho fatto esattamente quello che ho fatto nel primo modo.

 

Cosa cambia allora?!?!?!?

Che vantaggi mi da la programmazione ad oggetti?!

Spero che qualcuno possa aiutarmi.

Grazie a tutti

[pigroplc]

Io mi sono ingolosito alla cosa spinto dalle nuove funzionalità di Simotion.

Descrivere in due parole la differenza è sicuramente riduttivo e fuorviante. La principale caratteristica è data dal fatto che non è possibile modificare un oggetto al di fuori della dichiarazione dell'oggetto stesso. Se programmi in modo decente altre grosse differenze non ce ne sono a parer mio.

Io mi sono fatto una dispensa prelevando informazioni tratte dal sito www.html.it. Non lo allego per possibili implicazioni di copyright. 

 

[Gibbo]

Ma secondo voi la programmazione ad oggetti ha un futuro in automazione ? 

Sto approcciandomi a Beckhoff e sto valutando la programmazione OOP e ho un pò di dubbi.....

 

Intanto non tutti i produttori non la supportano, vedi Siemens con Tia per 1500 (il Simotion invece si...) e mi sembra anche Rockwell.

Mi sembra inoltre che il codice perda un pò di leggibilità e di immediatezza di intervento pur essendo abituato a programmare in ST. 

[del_user_97632]

Mah, non conosco bene il mondo dei plc, ma aggiungo un commento generale,  la programmazione ad oggetti era stata introdotta anche visto l'incremento di complessita' del sw e la difficile gestione di un programma molto grande. Con gli oggetti rendi piu comprensibile la struttura e piu semplice la manutenzione.

 

Detto questo, tra dichiarazioni di classi etc, per un programmino semplice scrivi generalmente piu codice. Per quel che ne so i programmi PLC mi sembrano in genere comprensibili per loro natura, per cui forse OOP diventa una funzionalita' inutile..

 

-------

Poi ci sono i fanatici degli oggetti, quelli che comprano il libro dei design pattern e vogliono implementare tutto ad oggetti sempre comunque. Non e' vietato, come sempre e' importante che un programma funzioni, ma se si lavora da soli anche meglio, cosi non si costringono gli altri ad utilizzare sempre gli oggetti, anche se talvolta e' inutile (si parla anche di "cargo cult programming", cioe la pratica di introdurre codice per ritualita', senza che ve ne sia uno scopo, o senza neanche il capirne a fondo il funzionamento) https://en.wikipedia.org/wiki/Cargo_cult_programming

Modificato: 19 giugno 2019 da _angelo_

[Mariuz]

19 minuti fa, _angelo_ scrisse:

Mah, non conosco bene il mondo dei plc, ma aggiungo un commento generale,  la programmazione ad oggetti era stata introdotta anche visto l'incremento di complessita' del sw e la difficile gestione di un programma molto grande. Con gli oggetti rendi piu comprensibile la struttura e piu semplice la manutenzione.

 

Detto questo, tra dichiarazioni di classi etc, per un programmino semplice scrivi generalmente piu codice. Per quel che ne so i programmi PLC mi sembrano in genere comprensibili per loro natura, per cui forse OOP diventa una funzionalita' inutile..

 

-------

Poi ci sono i fanatici degli oggetti, quelli che comprano il libro dei design pattern e vogliono implementare tutto ad oggetti sempre comunque. Non e' vietato, come sempre e' importante che un programma funzioni, ma se si lavora da soli anche meglio, cosi non si costringono gli altri ad utilizzare sempre gli oggetti, anche se talvolta e' inutile (si parla anche di "cargo cult programming", cioe la pratica di introdurre codice per ritualita', senza che ve ne sia uno scopo, o senza neanche il capirne a fondo il funzionamento) https://en.wikipedia.org/wiki/Cargo_cult_programming

 

Concordo, rischia di diventare una moda inutile rendendo i programmi poco comprensibili, inutilmente complicati e di difficile manutenzione...

A proposito di cargo cult programming...poi si genera il bloatware, ovvero programmi inutilmente lunghi e pesanti pieni di cose inutili.

La bravura del programmatore si vede dall'efficienza dell'algoritmo in relazione alla sua lunghezza...

[Marco Mondin]

Beh... Oddio... Ci sono pro e contro!
Se si sviluppano software piccoli e stupidi come la maggior parte dei software PLC è inutile probabilmente.
Se si sviluppano software molto complessi, che sono una minima parte è molto utile.
Io ed il mio socio usiamo in modo massiccio il paradigma object oriented in CODESYS, anche su software semplici, ma questo per poter rendere riciclabile la maggior parte del codice.
Se si conosce bene il paradigma, si sanno sfruttare l'ereditarietà ed il polimorfismo e si ha una buona padronanza di tali concetti, con una buona atomizzazione degli oggetti il software diventa più riciclabile della carta! Ovviamente diventa totalmente incomprensibile per chi non è un vero softwarista con conoscenze approfondite di informatica avanzata, teoriche e con molta esperienza applicativa. Tuttavia per un buon informatico è più semplice analizzare e modificare un buon progetto OOP che un progetto non OOP, in quanto il paradigma è nato per rendere ogni singolo oggetto indipendente dai dettagli implementativi degli altri oggetti. Di conseguenza il rischio di fare pasticci con le manutenzioni di singole parti si riduce ed è molto più semplice la manutenzione ad anni di distanza.
Tutto questo ha un prezzo salato!
-Primo il codice lievita in dimensioni, ma questo viene parzialmente compensato dalla riciclabilità (riciclando posso metterci meno a scrivere un progetto da 60.000-100.000 righe di codice ben strutturato che uno partendo da zero da un migliaio campate li in modo scombinato e poco riciclabile).
-Secondo è imprescindibile una profonda conoscenza dell'argomento, che non si limita alla teoria dei concetti che sono anche abbastanza intuibili, ma non certo così immediati nell'applicazione senza tantissima esperienza. Difficilmente un neolaureato (se non poche eccellenze) può diventare subito produttivo.
-Terzo Per le aziende i costi per softwaristi master potrebbero essere fuori portata, soprattutto nel mondo della manodopera usa e getta. Sono pochi ad oggi i committenti che accettano di pagare di più per avere qualcosa di realmente modulare che possa offrire un vero valore aggiunto alle macchine. Oggi la mentalità preponderante è ancora il basta che funzioni!

[dcautomation]

2 ore fa, Marco Mondin scrisse:

Beh... Oddio... Ci sono pro e contro!
Se si sviluppano software piccoli e stupidi come la maggior parte dei software PLC è inutile probabilmente.
Se si sviluppano software molto complessi, che sono una minima parte è molto utile.
 

Potresti indicare in quali settori e che tipo di macchinari un progetto OOP sarebbe più funzionale di uno a PLC?

E perché? Vantaggi e svantaggi? 

[Marco Mondin]

Ti faccio un paio di esempi!
Stiamo lavorando su un applicativo di un tornio a controllo numerico per una lavorazione molto particolare che di solito viene fatta a mano da operai specializzati!
Tale macchina ha da 1 a 5 gruppi da 2 assi, ogni gruppo può essere formato da 2 assi elettrici, 2 idraulici o due misti.

Siccome tale macchina lavora sia in gCode che in registrazione/riproduzione continua con 1 campione a 40 tracce ogni millisecondo l'uso del motion plcopen era un po' limitativo sotto alcuni sapetti della gestione degli assi.
Per avere lo stesso sorgente su macchine eterogenee abbiamo fatto massiccio uso del polimorfismo.
Per esempio esiste un oggetto virtuale (Oggetto interfaccia) che rappresenta un asse, ma essendo appunto virtuale è puramente astratto. Poi ci sono n implementazioni reali che ereditano l'asse astratto e lo estendono facendolo diventare reale e occupandosi dei dettagli implementativi.
L'oggetto CN viene configurato da un oggetto configuratore e gli vengono passate 2 reference ad assi astratti che puntano alle reali istanze degli assi reali.
Lui comunica con un'interfaccia virtuale e non ha idea del tipo di asse che sta compiendo il lavoro, come non ha nessuna idea o visibilità sul dettaglio implementativo di ogni asse, che può essere volendo stravolto in corsa senza toccare l'oggeto CN.

A sua volta un asse idraulico, può scegliere tra un ventaglio di PID in quanto non c'è un algoritmo PID che va bene per tutti gli assi idraulici in quanto possono comportarsi in modi molto diversi in dipendenza da troppe variabili esterne. Soluzione Oggetto PID virtuale e reference al PID reale passata come astratta all'asse, sempre fatta dall'oggetto configuratore che è l'unico a cambiare con il cambiare della macchina.

Potendo gli oggetti essere istanziati, e essendo la configurazione macchina come dicevo variabile da 1 a 5 gruppi assi grazie alla funzione __ISVALIDREF(...) che permette di verificare se l'istanza esiste in quanto appunto passata come reference dal configuratore si possono istanziare solo gli assi necessari alla macchina specifica, questo permette di scegliere l'hardware su cui installare il runtime adeguato alla macchina nello specifico. (Con 2 assi potrebbe bastare una CPU, con 10 ne potrebbe servire un'altra).

Siccome tale applicativo lavora in sinergia con una parte PC molto complessa, il runtime scambia dati tramite 4 shared memory distinte, una con dati di processo, una con dati di setup, una con il gestore eventi per tracciabilità e visualizzazione una per i programmi da registrare e/o eseguire. Tutte le shared fanno cose un po' diverse, ma un bel pezzo del codice fa le stesse cose, in questo caso abbiamo usato molto l'ereditarietà, un oggetto gestore della shared si smazza le parti comuni, le estensioni che lo ereditano fanno il resto senza prendersi il mal di pancia della gestione che sta sotto.

Sia il team CODESYS che quello BECKOFF(che è un codesys un po' personalizzato) fanno uso massiccio di polimorfismo ed ereditarietà! La reference che per esempio si passa per un asse al PLC open è un oggetto puramente virtuale, le sue estensioni diventano un asse reale a seconda di come viene istanziato. Una grossa parte delle librerie CODESYS e BECKHOFF sono in stile OOP.

Questo è solo un piccolo esempio, poi i meccanismi che stanno dietro sono più complessi, per esempio i metodi vengono chiamati dalla ciclica dell'oggetto chiamante e questo potrebbe creare problemi, per ovviare a tali problemi noi usiamo macchine a stati in pseudo stile OMAC per smistare eventi tramite i command di tali macchine.

Alla fine del tutto abbiamo un unico sorgente in cui cambiamo un singolo modulo con un POU che si trova nei devices invece che nei POUs e di conseguenza è legato alle varie configurazioni. Attivando una specifica application noi carichiamo il progetto su una specifica macchina. Una patch ad una parte comune si propaga con gli upgrade a tutto il parco macchine.

Una volta creati gli oggetti, può capitare poi che siano molto utili anche in progetti semplici, in quanto essendone i creatori ne abbiamo padronanza, quindi capita che ricicliamo oggetti creati per applicativi complessi anche in macchine semplici, e questo ci fa risparmiare molto tempo in quanto un buon OOP rende gli oggetti reciprocamente indipendenti dai dettagli implementativi degli altri, devono solo usarne l'interfaccia(metodi) senza avere minimamente idea di cosa ci sia nella blackbox(oggetto) 
 

Modificato: 14 luglio 2019 da Marco Mondin

[dcautomation]

Quali sono allora gli ostacoli che impediscono i programmatori Plc a fare l'upgrade e cominciare ad usare la programmazione OOP, se si può usare sia per progetti semplici e complicati? È solo una questioni di costi e competenze? Un softwarista ha le competenze tecniche anche per quanto riguarda installazione e ricerca di guasti dei componenti elettromeccanici? 

[Marco Mondin]

Beh! Prima di tutto il fatto che molti programmatori PLC ragionano a contatti usando il Ladder con una mentalità elettrica e non come un modo di visualizzare un IL a logica booleana.
Sono due modi differenti di vedere le cose, uno più semplice per chi è di pura estrazione elettrotecnica, l'altra per elettronici e informatici.
La prima mentalità purtroppo porta a maggiori difficoltà nel capire linguaggi più ad alto livello come ST in quanto è difficile vedere ST in ottica "elettrotecnica", per altro forzarlo a tale mentalità porta il codice ST a una totale illeggibilità e lo rende scomodissimo, perdendo tutti i vantaggi che tale linguaggio in realtà offre.
L'OOP fa un ulteriore salto della stessa grandezza, anche per un informatico puro abituato a una programmazione procedurale/strutturata, passare a una programmazione OOP è alquanto ostico. I concetti si imparano in fretta, ma l'applicazione non è altrettanto semplice.

Alla fine sui PLC/controlli, ad oggi si possono distinguere 3 grosse categorie, delle quali due sovrapponibili alle categorie degli informatici.

- Sviluppatori con mentalità "elettrotecnica" che ragionano più pensando ad una maglia elettrica che ad una sistema strutturato/procedurale e sequenziale.

- Sviluppatori con mentalità procedurale/strutturata.

- Sviluppatori con mentalità OOP. (Il motto degli sviluppatori OOP è: "Non sviluppare oop, ma pensa OOP!)

Il primo e l'ultimo metodo hanno entrambi vantaggi rispetto a quello centrale! Però l'ultimo prescinde da una buona conoscenza di quello centrale.

Nel caso "elettrotecnico" i programmi, se fatti da un buon softwarista (che non fa polpettoni mischiando cose a destra e manca), sono molto leggibili ed intuitivi, con tutti i limiti del caso, ma intuitivi il tempo necessario a riprendere in mano un progetto e modificarlo/personalizzarlo è tutto sommato breve i tempi di sviluppo sono i più corti.

Nel caso "strutturato/procedurale" i programmi se fatti bene sono leggibili, ma vedere software fatto bene è una chimera in questo caso. Fare modifiche a software di questo tipo a volte è un vero calvario! Soprattutto quando è pieno di modifiche fatte di fretta a destra e manca!

Nel caso "OOP" il software viene "PENSATO" con una rappresentazione reale del dominio della macchina! Si deve ragionare in un modo molto simile al modo con cui si osserva il mondo, ma per poter spiegare tale analogia è meglio leggere libri di teso specifici. Un buon software OOP è solitamente molto intuitivo, le sue parti sono talmente isolate che nella manutenzione il tutto anche se si lavora su software di grosse dimensioni è molto semplice, a patto di mantenere regole ferree di buona programmazione, ma questo vale per tutte e tre le categorie.

Per quello che riguarda la manutenzione elettrica! Beh! Parere personale, ma se un software è fatto come dio comanda non si usano i sorgenti online! Basta la diagnostica.
Per esempio noi abbiamo un software di pallettizzazione con 478 messaggi che vengono tracciati nel MessageManager su HMI e con uno storico temporale di 90 giorni, che raccontano vita morte e miracoli della macchina. Da una veloce analisi dei messaggi si può subito capire quale sia il componente guasto senza toccare il sorgente o monitorare online!
Ogni sensore ha messaggi di timeout, di mutua esclusione, ogni dispositivo ha messaggi che indicano il suo stato, ogni drive ha rimappata la principale serie di errori su cui un operatore può interventire, etc... Per altro uno dei lavori più noiosi e tediosi 😞 , ma necessari per togliersi tante grane nel futuro.
Purtroppo tutto questo non è sempre possibile, in quanto non sempre i commerciali sono in grado di convincere i committenti finali che un software può avere molto valore aggiunto...
In questo caso sta tutto alla bravura dei commerciali!

Detto questo, monitorare un buon progetto OOP non è difficile. Basta avere un ambiente di sviluppo che offra dei buoni watch, ma quelli derivati da codesys, di solito il loro lavoro lo fanno bene.



 

Modificato: 14 luglio 2019 da Marco Mondin

[walterword]

ciao Marco ......molti programmatori PLC ragionano a contatti usando il Ladder con una mentalità elettrica , è vero fino ad un certo punto. Per applicazioni serie e complesse si usa Ladder accoppiato ad altri linguaggi, awl per librerie a basso livello (encoder, azionamenti , comunicazioni etc ) . Per il 1200 visto che non c'e' awl hanno integrato molte funzionalità in scl per lavorare a basso livello e/o a livello di bit .

La mia opinione per quanto riguarda la OOP in automazione è la seguente.

Per oggetti io intendo modellare una tipologia di impianto e quindi macchine, suddiviso in macchine descritte dal loro FC e relativo DB magari in una cartella a se.

Questo ti permette di creare altri progetti copiando quello che hai gia fatto , estendere o tagliare etc. Il disaccoppiamento del codice è valido anche nei plc, per esempio il fatto di copiare gli ingressi digitali su aree di dati DB ed utilzizare questi ultimi nel sw invece di usare gli ingressi nudi e crudi fa gia parte del disaccoppiamento del codice, e cosi molte altre tecniche.

la programmazione OOP la uso quando scrivo in C#, python etc. In automazione i concetti di ereditarietà, polimorfismo ed incapsulamento non sono gestiti dal ambiente di sviluppo delle marche più comuni di plc. Per contro un controllore logico , per esempio basato su arduino , te lo programmo interamente in C++ con classi , classi derivate etc ma anche li il problema fondamentale è far funzionare l'applicazione senza troppi intoppi. Gia da anni , nei grandi impianti e soprattutto nei magazzini automatici esistono architetture di livello almeno 2.

Livello 0  --->  Motori, valvole, sensori , fotocellule

Livello 1 -----> Plc o reti di plc, HMI etc

Livello 2 ------> Sistema computerizzato scritti con linguaggi che supportano la OOP , con database ed algoritmi per la gestione ed il lancio delle missioni che il plc esegue, con i dovuti controlli, solo se riceve certi comandi . Per cui in questo caso potrei identificare una programmazione OOP in automazione ma composta da pc , plc etc. 

Con il solo plc credo che non abbia nessun senso programmare in OOP 

ciao 

[Marco Mondin]

il 19/9/2019 at 11:08 , walterword scrisse:

...

la programmazione OOP la uso quando scrivo in C#, python etc. In automazione i concetti di ereditarietà, polimorfismo ed incapsulamento non sono gestiti dal ambiente di sviluppo delle marche più comuni di plc....

Con il solo plc credo che non abbia nessun senso programmare in OOP 

ciao 

Che il solo PLC sia limitativo in molti lavori odierni è palese.
Le marche più comuni "PURTROPPO!!!" non hanno integrato completamente la IEC61131-3, che sarebbe uno standard de facto!
Solo Codesys è tutti i vari derivati dalla versione 3.x la implementano completamente. Alcuni di questi non sono nemmeno poi tanto piccoli, per esempio Beckhoff con il suo Twincat3 che è un Codesys un po' esteso.
In tale standard sono stati inseriti i concetti di polimorfismo, ereditarietà e classi ed il lavoro svolto è stato fatto molto bene! Hanno praticamente trasformato gli FB in vere e proprie classi. Hanno quasi tutto quello che serve nei linguaggi moderni, ma in ST IEC!
Nelle loro librerie li usano pesantemente e li espongono ai softwaristi!

Per fare un esempio, se si volesse usare il loro SMC_NCInterpreter non con i 3-4 modi implementati da loro ma in altri modi, (Programma GCode su shared memory piuttosto che su socket TCP piuttosto che ... etc) danno accesso ai loro tockenizer e tokenparser semplicemente reimplementando un ITextStream da una loro interfaccia puramente virtuale. Per altro è di una banalità impressionante.

Io lo trovo molto comodo, in quanto a fronte di un po' più di lavoro iniziale (Progettazione del diagramma delle classi) rende il codice riciclabile e riconfigurabile con uno sforzo ridicolo in seguito!
Lo adoro in quanto mi evita i copia incolla, creo una classe è la istanzio quante volte serve.

Che poi l'abbinamento con PC oggi sia quasi un obbligo, beh! I runtime moderni ormai girano sovente su PC è con un minimo di conoscenze sul sistema operativo, la gestione delle shared memory etc, si ottengono risultati ragguardevoli.
Ovviamente dipende sempre da cosa ci si deve fare. Se devo sviluppare una macchinetta microscopica e stupida il gioco sovente non vale la candela, se devo sviluppare un centro di lavoro fuori standard (Come uno dei lavori che stiamo seguendo ora) o un sistema fortemente integrato con il PC (Calcolo dinamico in realtime delle ricette con forte uso di algoritmi matematici, con gestione della logistica, calcolo di profili di camma compresi di ottimizzazione di dinamica in realtime) invece ne potrebbe valere seriamente la pena. Almeno per me ne vale la pena.
Poi il mondo è grande, il lavoro non manca certo nell'automazione quindi ci si può permettere di scegliere i lavori più divertenti e scartare quelli che si reputano più noiosi scelta per altro sempre molto soggettiva!