Jump to content
PLC Forum


GioUnoNoveOttoOtto

Differenza tra programmazione ad oggetti e non

Recommended Posts

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

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
_angelo_

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

Edited by _angelo_

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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? 

Share this post


Link to post
Share on other sites
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) 
 

Edited by Marco Mondin

Share this post


Link to post
Share on other sites
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? 

Share this post


Link to post
Share on other sites
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.



 

Edited by Marco Mondin

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...