Da ladder con tia portal a solo ST con Beckhoff e Mitsubishi

[Danilo Cardace]

Ciao a tutti!

 

Ho delle considerazioni che mi frullano per la testa a cui so darmi delle risposte parziali e se possibile vorrei avere dei pareri da chi ha esperienza in programmazione.

 

Riassumo in breve a cosa sto andando in contro:

 

- Dopo 7/8 anni come tecnico nel settore industriale(installazioni, riparazioni, cablaggio quadri ecc...) ad agosto inizio la mia nuova carriera come programmatore plc, le mie conoscenze sono basilari e per lo piu riguardano prodotti Siemens ed ho programmato solo piccole automazioni. Mi sono sempre rifugiato nella programmazione ladder perche mi faceva stare "tranquillo" e soprattutto non ho mai avuto necessita di usare altri linguaggi dovuto dalla "semplicita" di alcune automazioni.

 

- Nella nuova azienda dove lavorero usano SOLO la programmazione ST  e raramente FBD solo se il cliente lo richiede. Io sono sempre stato interessato a imparare ST , lo trovo uno strumento potente ma non sono ancora in grado di usarlo con la stessa facilita che uso il ladder. Come posso fare questo "salto" il meno traumatico possibile? 

 

- Ho  fatto delle ricerche nei vecchi post del forum ed ho notato (chi piu e chi meno) che un mix dei linguaggi in base alle applicazioni dove saranno usate sembra essere la soluzione migliore.

Allora perche alcuni usano SOLO un linguaggio?

Quali sono vantaggi e svantaggi? 

 

- Ci tengo a precisare che mi sara dato il tempo di imparare, nell'azienda saro seguito e aiutato da colleghi esperti. Vivo e lavoro in Svezia. Lo specifico perche da quel che ho capito in altri post ci sono culture e modi diversi di approccio al lavoro.

 

Grazie.

 

PS: Chiedo scusa per gli accenti, la tastiera nordica non li concepisce.

 

[leleviola]

La concezione di usare il solo ST viene fondamentalmente dalla necessità di riciclare in breve tempo ciò che è stato fatto per macchine di diversi marchi, la prerogativa di usare un solo linguaggio può risultare utile per questi motivi, l'ho sentito dire da molti programmatori, per me, opinione personale, rimane più utile il liguaggio più adeguato al contesto, il ladder è innegabile che rimane più semplice e più facile da analizzare in fase di diagnostica di problematiche, ST è più utile nella realizzazione di calcoli dove il ladder rimarrebbe troppo farragginoso, SFC o Graph per Siemens rimane utile nella programmazione di cicli realizzati a passi o fasi ben distinte concatenati tra loro da condizioni di transizione. Che dire, ogni linguaggio evoluto ha le sue prerogative, basta saperlo usare per ciò che serve.

Modificato: 13 giugno 2020 da leleviola

[dcautomation]

Grazie @leleviola, per poter padroneggiare come si deve il linguaggio ST quanto tempo ci si impiega? (relativamente, immagino sia diverso da persona a persona )

[Colonial54]

Animo, in almeno il 99% di un sw si usano tuttalpiu' una dozzina di istruzioni, imparatele e vai tranquillo, col tempo e la pratica impararai a dominare anche le altre, ad es. in Siemens ci sono un sacco di istruzioni che in 35 anni non ho mai avuto la necessita' di utilizzare, nenche per sw di alto livello.

[ifachsoftware]

Allora perche alcuni usano SOLO un linguaggio?

Perchè basta un copia/incolla e porti il codice da una marca di plc all'altra  (anche se spesso devi riadattare certe parti).

 

Personalmente ritengo piu' corretto usare il giusto linguaggio per il compito che bisogna risolvere.

 

Usare ST per tutto non è corretto (un po' come un tempo che si usava solo l'AWL) , sono degli escamotage per risolvere certe situazioni.

 

Comunque come tutte le cose basta prenderci la mano

 

 

[batta]

Il 13/6/2020 alle 18:23 , Colonial54 ha scritto:

in almeno il 99% di un sw si usano tuttalpiu' una dozzina di istruzioni, imparatele e vai tranquillo

Questo giudizio mi sembra riduttivo e troppo ottimistico. È vero che le istruzioni da imparare sono poche (e che per quelle che non conosci c'è sempre la guida in linea), ma è come usarle e come combinarle insieme che fa la differenza. Come dire che la matematica è facile, perché ci sono solo poche operazioni.

[leleviola]

Le istruzioni ci sono per essere usate è che spesso possono non servire

[dcautomation]

3 ore fa, batta ha scritto:

È vero che le istruzioni da imparare sono poche ma è come usarle e come combinarle insieme che fa la differenza. 

Ho appunto provato diverse soluzioni per riprodurre lo stesso comando(classico start e stop, ecc..), 3 soluzioni diverse che svolgevano lo stesso comando correttamente (credo, usando il simulatore tutto funzionava). Ora, io che non ho appunto diversi anni alle spalle come programmatore, come faccio a intuire da solo quale sarebbe la più corretta? 

Non voglio e non sono interessato a programmare dispositivi e macchinari con il concetto "basta che funzioni". 

[batta]

2 ore fa, dcautomation ha scritto:

come faccio a intuire da solo quale sarebbe la più corretta? 

Non sempre c'è un modo "più corretto" di un altro. Sono cose che ti verranno insegnate (spero) dai tuoi colleghi esperti, e che apprenderai con la tua esperienza. E ci sonio anche scelte soggettive.
Faccio un banale esempio. Un marcia/arresto, in strutturato, si può scrivere in due modi (in realtà sono di più, ma prendiamo i due più usati come esempio).

// Metodo che corrisponde al SET/RESET del ladder
IF pb_Start THEN
	run := TRUE;
END_IF;
IF pb_Stop THEN
	run := FALSE;
END_IF;

// Metodo che corrisponde all'autoritenuta del ladder
run := (pb_Start OR run) AND NOT pb_Stop;

Personalmente preferisco il secondo modo (autoritenuta), ma saranno in molti invece che ti diranno che preferiscono il primo (set/reset).

Poi (ma è sempre questione anche di gusti personali), se devo fare un marcia/arresto con set/reset, preferisco fare così:

IF pb_Stop THEN
	run := FALSE;
ELSIF pb_Start THEN
	run := TRUE;
END_IF;

Come vedi, sono tre modi diversi per ottenere lo stesso risultato, e sono tutti e tre corretti.
 

Modificato: 15 giugno 2020 da batta

[Marco Mondin]

Ci sono una serie di motivi positivi:
1 - Come ti ha citato sopra leleviola, il motivo principale è appunto la riciclabilità del codice, ed oggi dove gli applicativi sovente non basta più che facciano funzionare una macchina bene al minimo del richiesto, ma sovente devono offrire molto valore aggiunto, banalizzando la macchina oggi la deve usare anche la signora Maria, non banalizzando ci sono tutta una serie di satelliti che ruotano attorno al funzionamento nudo e crudo di una macchina, se il software della macchina è scritto in un certo modo e con certi criteri e regole che esulano dal suo mero funzionamento, possono gravitare intorno all'intero mondo della macchina in modo naturale e si inseriscono senza difficoltà, in altri casi fanno perdere un sacco di tempo in più e sovente sacrificare funzionalità. Vige la regola del: "Più tempo risparmio prima, più ne perdo dopo, non è nemmeno detto che dopo riesca a fare tutto ciò che mi chiedono". Più volte in macchine di una certa complessità, ho visto riscrivere da zero il software dopo svariati tentativi di adattarlo alle richieste del cliente, software che funzionavano anche molto bene, ma scritti con uno stile che ne rendeva molto complessa la modifica radicale di alcune parti senza intaccarne altre.

2 - È più facile applicare paradigmi che traggono origine dai fondamenti dell'informatica. Anche se non sono indispensabili nell'automazione hanno il loro motivo per esistere e non basterebbe certo un messaggio su un forum per spiegarlo, in quanto ci sono interi libri di testo incentrati solo sui paradigmi. Paradigmi volti alla naturalizzazione dei concetti, alla riduzione degli errori umani tramite regole non campate all'aria, ma frutto di anni di ricerca e di ottimizzare la riciclabilità del codice, in modo che non si debbano riscrivere decine di volte le stesse cose.

3 - Se si è abituati ad applicare la teoria degli automi a stati finiti e si usano pesantemente logiche non puramente combinatorie, ma combinatorie/sequenziali trovo il codice in testo molto più leggibile. Con questo non intendo che chi usa pesantemente LADDER e logica quasi totalmente combinatoria sbagli!!! Tuttavia ci sono tecniche in questo caso che permettono una ottimizzazione delle risorse impressionanti. Per fare un esempio pratico, due machine fatte da persone diverse, ma con le stesse caratteristiche, una scritta in ladder in modo classico con stile combinatorio, una tutta in ST con automi a stati finiti e logiche sequenziali. La prima su una vecchia CPU occupava 6ms medi per ciclare, la seconda faceva più cose della prima e ciclava in una media di 0.7ms. Questo non è un invito a buttarsi su automi a stati finiti domani per chi non li ha mai usati, in quanto c'è tanta teoria da studiare, e se usati male fanno più danno che beneficio, ma offre una visione sull'ordine di grandezza dell'ottimizzazione ottenibile.

Come dice Batta non c'è un modo "più corretto" per fare le cose. Sì possono fare le cose bene o male con qualunque strumento si abbia a disposizione! Il tutto sta nel come si sa usare tale strumento.
Quello che trovo invece riduttivo è dire "in almeno il 99% di un sw si usano tuttalpiu' una dozzina di istruzioni, imparatele e vai tranquillo".

Mi sembra quantomeno offensivo per chi ha perso anni in ricerca sullo studio dei paradigmi ed ha scritto interi libri di teoria! È come la classica frase dei commerciali (Prima o poi mi porto un mattone nello zaino pronto a lancio)  "Tanto il software è solo una manciata di IF/THEN/ELSE" che corrisponde al dire tanto il tuo cervello è solo una manciata di neuroni che pesa poco meno di 2Kg. Peccato che se ti tolgono il cervello sei un mucchio di roba inutile. Peccato che il cervello sia una delle parti più complesse!

Non a caso alcune ditte aprono gli occhi e progettano al contrario!
Prima discutono l'HMI con il committente (Monitor, touch, pulsantiere, pagine, utenti) in modo che la mano che userà la macchina sappia usarla come oggi usa uno smartphone! Poi progettano il software intorno a quello ed infine tirano fuori le specifiche meccaniche ed elettriche che gravitano intorno al progetto software per garantire il funzionamento della macchina sulle reali richieste del cliente. Tuttavia siamo nuovamente difronte ad un problema! Tutto questo alza i costi e non tutti sono disposti a spendere di più! Anzi oggi molte volte nel software il tempo perso in progettazione è visto dal committente come tempo perso e vorrebbero che software, parte elettrica e meccanica partano in progettazione lo stesso giorno senza quasi interscambiarsi informazioni! Poi sappiamo tutti i limiti che ci troviamo in campo quando i committenti (tanti) ragionano in questo modo.

[batta]

4 ore fa, Marco Mondin ha scritto:

La prima su una vecchia CPU occupava 6ms medi per ciclare, la seconda faceva più cose della prima e ciclava in una media di 0.7ms.

Qua ci sarebbe da approfondire.
Prima di tutto, bisogna vedere di che PLC si sta parlando, e di come venga ottimizzata la compilazione nei diversi linguaggi.
Poi, al di là del diverso linguaggio usato, si deve valutare come sia stato sviluppato il programma.

 

4 ore fa, Marco Mondin ha scritto:

trovo il codice in testo molto più leggibile

Io sono sempre dell'idea che per manipolazione di dati sia quasi obbligatorio usare ST, ma se si parla di logica booleana (banali istruzioni tipo marcia/arresto, o la catena di condizioni per passare da uno stato al successivo) l'immediatezza del ladder non può essere messa in discussione.
Non crederò mai che ci sia qualcuno che capisce al volo cosa manca per soddisfare certe condizioni in un linguaggio testuale, e si trovi in difficoltà con il ladder.
Un ramo in ladder con logica booleana lo posso far vedere, online, alla signora Maria, e la signora Maria sarà in grado di capire cosa manca.
Non si può certo dire lo stesso per un linguaggio testuale.

 

Io stesso, quando scrivo codice, preferisco usare il testo strutturato per molte cose, ma se devo capire, online, cosa sta succedendo, devo ragionarci su. In ladder, vedi al volo la condizione che manca.

Poi, per carità, mi sono imbattuto anche in rami scritti in ladder di difficile comprensione, ma un ramo scritto male in ladder lo dobbiamo paragonare ad un ramo scritto male in strutturato.
Se in ladder, in qualche modo, si riesce a capire cosa succede, un codice scritto male in strutturato è assolutamente indecifrabile.
 

[leleviola]

Comunque sulla questione riciclabilità dei software in ST la vedo un po' diversamente, quando si intende riciclare del software già fatto per macchine simili o uguali si deve anche usare metodologie standard di programmazione degli assi come usare le librerie PLC Open, questo va si bene per usare il medesimo software su altri marchi ma non è detto che si sfrutti a fondo le peculiarità dei vari marchi, io invece preferisco utilizzare modularmente i vari FB o funzioni dedicate dei vari marchi e utilizzre quando serve ladder o ST e utilizzare le FB proprietarie dei vari marchi quando serve. Sarà forse perchè realizzo macchine piccole o forse perchè difficilmente ne realizzo di simili o quasi uguali, spesso sono anche prototipi. Questo diciamo è quello che mi si presenta ultimamente. Concordo con batta sulla maggiore semplicità di diagnostica del ladder, colpa della mia derivazione elettrotecnica purtoppo ma quello è e la sinapsi mi porta a ragionare in quel modo

Modificato: 16 giugno 2020 da leleviola

[Marco Mondin]

1 ora fa, leleviola ha scritto:

Concordo con batta sulla maggiore semplicità di diagnostica del ladder, colpa della mia derivazione elettrotecnica purtoppo ma quello è e la sinapsi mi porta a ragionare in quel modo

Infatti dipende dalla derivazione! È naturale che si è di derivazione elettromeccanica sia più semplice pensare in quel modo e non è assolutamente detto che sia sbagliato.
Chi arriva dalla formazione più informatica invece si trova più a suo agio a lavorare con logger, breakpoints e watch. È solo questioni di abitudine.

 

2 ore fa, batta ha scritto:

Qua ci sarebbe da approfondire.
Prima di tutto, bisogna vedere di che PLC si sta parlando, e di come venga ottimizzata la compilazione nei diversi linguaggi.
Poi, al di là del diverso linguaggio usato, si deve valutare come sia stato sviluppato il programma.

Stessa CPU. Mi è anche capitato di dimostrarlo sul campo ad altri riscrivendo il codice di macchine sulla stessa CPU. Un applicativo ben progettato con automi a stati ad ogni ciclo passa una manciata di righe di codice. Tutto il superfluo non gira. Non sempre ma il più delle volte in Ladder vedo applicativi scritti in cui tutti i rami vengono scansionati ad ogni ciclo.
Con gli automi uniti ad una logica sequenziale posso avere cicliche dome girano 20-100 linee di codice su magari 20000. Il rovescio della medaglia è che se non si progetta più che bene il dead lock è garantito, motivo per cui alcune ditte proibiscono di usare le macchine a stati in modo massiccio. 
 

1 ora fa, leleviola ha scritto:

Comunque sulla questione riciclabilità dei software in ST la vedo un po' diversamente, quando si intende riciclare del software già fatto per macchine simili o uguali si deve anche usare metodologie standard di programmazione degli assi come usare le librerie PLC Open, questo va si bene per usare il medesimo software su altri marchi ma non è detto che si sfrutti a fondo le peculiarità dei vari marchi, io invece preferisco utilizzare modularmente i vari FB o funzioni dedicate dei vari marchi e utilizzre quando serve ladder o ST e utilizzare le FB proprietarie dei vari marchi quando serve.

Infatti io evito FB proprietarie come la peste! Sono stato costretto per motivi di tempo ad usare il mapp B&R e lo odio! Preferiamo riscrivercele noi in ST proprio per migrarle da un sistema all'altro senza avere problemi. Tuttavia anche qua è una pura questione di gusti ed abitudini con pro e con contro di ogni soluzione. Per farti un idea su CODESYS non usiamo nulla del softmotion, ma facciamo motion ed usiamo il loro interprete gCode. La cosa triste è che per usare il solo interpolatore che fa parte della licenza CN ti fanno pagare anche quella softmotion anche se non la usi, in quanto secondo loro (Sede centrale, non CODESYS Italia che sa benissimo che noi lo facciamo) non si può fare! Per loro è assurdo che la gente si implementi da sola tutte le librerie per il motion. Per svincolarci da questo stiamo un pezzo alla volta scrivendo il nostro interprete ed il nostro interpolatore, in modo da soppiantare anche quello ed usare solo il codesys control puro senza CN e SoftMotion.
E non scherzo! Come puoi vedere nello screenshoot il pool softmotion è vuoto!!!

Ed io non è che non usi il ladder in nulla! A volte nei pezzetti di contorno più semplici lo suo, come in alcune parti di PLC intorno alla macchina:

[leleviola]

Marco Mondin è sempre un piacere leggere le tue opinioni, peccato ancora non faccia uso intensivo di Codesys

[batta]

32 minuti fa, Marco Mondin ha scritto:

Infatti dipende dalla derivazione! È naturale che si è di derivazione elettromeccanica sia più semplice pensare in quel modo e non è assolutamente detto che sia sbagliato.

No, di questo non riuscirai mai a convincermi.
Sia chiaro che mi riferisco sempre a segmenti con logica booleana, non algoritmi strani, calcoli, o altro, compiti per i quali reputo il ladder inadatto.
Ma, per quanto si possa essere di estrazione informatica, non mi puoi dire che una rappresentazione grafica, dove a colpo d'occhio chiunque capisce dove la sequenza logica viene interrotta, sia più difficile da interpretare di una logica scritta con un linguaggio testuale. Non è una questione di abitudine, in ladder è qualcosa che risulta evidente, a colpo d'occhio, senza bisogno di fare il benché minimo ragionamento.

 

40 minuti fa, Marco Mondin ha scritto:

Stessa CPU.

Sì, che era la stessa CPU era chiaro ma, da quanto mi risulta, alcune marche hanno compilatori che non sono ugualmente efficienti in tutti i linguaggi.
Poi, se mi vieni a dire che lavorando in strutturato elabori solo il codice che ti serve e salti tutto il resto (esattamente quello che si faceva normalmente soprattutto lavorando in AWL), mentre in ladder elabori sempre tutto, la colpa non è del ladder, ma di come viene sviluppato il programma. Che poi in strutturato lavorare con un "case" venga spontaneo, mentre la stessa cosa risulti poco naturale in ladder, è un altro discorso.
Mi pare inoltre un po' esagerata l'affermazione che "girano 20-100 righe di codice su 20000". Già 1000 su 20000 la vedo dura. Forse io e te lavoriamo su tipologia di macchine e/o impianti completamente diversi, ma mi risulta difficile immaginare un codice da 20 mila righe dove ne lavorano solo 100 alla volta.
Faccio un esempio banale. Devi comandare degli inverter con un qualche bus di campo. È prassi abbastanza comune creare una funzione, alla quale passi i comandi ed i parametri, che si occupa poi di dialogare con il drive. Al drive non invii solo i comandi (cosa che potresti fare lavorando sui fronti), ma devi anche leggere in continuo lo stato, la velocità, la corrente, ed altro. Come fai a saltare l'elaborazione di queste funzioni? Con un inverter devo scambiare dati anche quando è fermo!
In una macchina a stati, tutto quello che puoi saltare è l'elaborazione delle logiche degli stati non attivi. Per elaborare 100 righe su 20000 dovresti avere, come media, uno stato attivo su duecento. E senza considerare poi le parti di programma comuni, che non puoi saltare mai.
 

[batta]

1 ora fa, Marco Mondin ha scritto:

Per svincolarci da questo stiamo un pezzo alla volta scrivendo il nostro interprete ed il nostro interpolatore

Personalmente non condivido questa scelta.
Faccio un esempio: con le CPU S7-1500T con poche istruzioni metti in piedi un oggetto "cinematica" che gestisce 3 assi + rotazione. Ci sono già i modelli per portale, delta, roll picker, e molto altro. Sono gestiti i comuni sistemi di coordinate, e le zone di lavoro. E c'è anche la possibilità di inserire cinematiche personalizzate.
La prima volta che mi sono cimentato con questo oggetto "cinematica", partendo da zero e con l'unico aiuto della guida in linea, in poche ore ho fatto funzionare un portale 3D, con tanto di raccordi tra i vari segmenti.
Dunque, io, anche se lo volessi fare, non ho le capacità per sviluppare gli algoritmi necessari per gestire una cinematica complessa ma, anche se avessi queste capacità, non capisco perché dovrei perdere mesi per sviluppare qualcosa che già esiste e che funziona bene. Solo per risparmiare quattro soldi di licenze?

Oppure perché, dietro al vostro svincolarvi da parti di software proprietarie c'è la volontà di vincolare il cliente, fornendo sistemi che solo voi potrete modificare e manutenere?

Modificato: 16 giugno 2020 da batta

[Marco Mondin]

28 minuti fa, batta ha scritto:

Dunque, io, anche se lo volessi fare, non ho le capacità per sviluppare gli algoritmi necessari per gestire una cinematica complessa ma, anche se avessi queste capacità, non capisco perché dovrei perdere mesi per sviluppare qualcosa che già esiste e che funziona bene. Solo per risparmiare quattro soldi di licenze?

Oppure perché, dietro al vostro svincolarvi da parti di software proprietarie c'è la volontà di vincolare il cliente, fornendo sistemi che solo voi potrete modificare e manutenere?

Anche perché è divertente...

[batta]

1 ora fa, Marco Mondin ha scritto:

Anche perché è divertente...

Su questo non posso che darti ragione. Sicuramente sviluppare qualcosa di così complesso dà delle belle soddisfazioni.
Purtroppo, io, dopo oltre 20 anni di attività in proprio, e oltre 30 nel settore dell'automazione industriale, non ho mai trovato nessuno disposto a pagarmi per divertirmi.

[ETR]

Il 16/6/2020 alle 16:15 , Marco Mondin ha scritto:

usare il mapp B&R e lo odio

 

😉 Non è che ci si vede al SPS a Parma (sempre che lo facciano dopo l'estate) allo stand arancione, giusto per chiarire alcune cose con qualche austriaco ? 

 

Tornando alla domanda di Danilo, non gli sarebbe utile qualche testo scolastico di PASCAL ? Giusto per partire dall'ABC. Dopo di ché a questo punto sarebbe utile trovare dei testi più tecnici su tecniche di strutturazione del codice che semplice . del costruttore.

 

I vari libri di settore pubblicati ad uso e consumo della singola marca o singola serie di PLC non li mo mai degnati d'attenzione. Ho una sterminata cartella di PDF di testi in inglese sull'automazione, ma vorrei chiedere a Marco se potesse consigliare qualcosa di più teorico, invece che pratico.

 

Buona giornata, Ennio

[Marco Mondin]

21 ore fa, ETR ha scritto:

ma vorrei chiedere a Marco se potesse consigliare qualcosa di più teorico, invece che pratico.

 

Buona giornata, Ennio

Ognuno ha percorsi diversi.
Io iniziali il mio con la bibbia sul C di "Brian Kernighan" e "Dennis Ritchie" quando avevo 12 anni (prima pasticciavo solo in basic). Esula dal mondo dell'automazione, ma lo reputo uno dei migliori testi per una introduzione alla programmazione strutturata/procedurale.
Aiuta anche a capire molto bene l'utilità dell'uso di strutture dati, che ormai presenti in tutti gli ambienti di sviluppo moderni di automazione aiutano molto a mantenere tutto ordinato e pulito. Si possono anche comprendere concetti che di solito nell'automazione vengono nascosti un po'. Per esempio l'allineamento dei dati nelle strutture dai in funzione dell'architettura in uso. Questo aiuta se si devono mischiare applicativi in diversi linguaggi su apparecchiature eterogenee, se si devono scrivere protocolli custom, se si usano funzionalità come quelle di Beckhoff o Codesys per gestire la shared memory etc, etc, etc.
Nello stesso periodo studiai l'ASSEMBLY per i processori MC68xx0, ma questo è totalmente inutile aiuta solo a capire la mentalità che stava dietro a chi ha scritto IL e AWL. IL lo imparai nel manuale SquareD di un vetusto PLC che ho ancora in soffitta e mi regalò un agente che seguiva buonanima di mio padre (Era installatore industriale) quando vide che ero appassionato di informatica, avevo sempre 12 anni ai tempi, mi ricordo ancora che come prima applicazioni ci feci l'albero di natale con un po di giochi di luce, hahahah.
Studiai i fondamenti dell'Object Oriented sul "Fondamenti di programmazione in C++" McGraw-Hill, che mi permise di comprendere concetti come ereditarietà, polimorfismo, privacy etc... Leggere almeno la parte introduttiva di libri di testo di questo tipo, senza la necessità di addentrarsi in un linguaggio come il C++ che è tra i più complessi ed al tempo stesso più potenti mai concepiti, può aiutare a comprendere gli stessi concetti che oggi hanno portato nelle ultime revisioni del IEC 61131-3, dove hanno trasformato i FUB in vere e proprie classi con tanto di metodi, privacy, polimorfismo, ereditarietà, interfacce etc.
Io sono un dinosauro di epoche vecchie, quindi consiglio libri come questo, tuttavia oggi ci sono decine di altri libri che possono introdurre bene al paradigma object oriented.
Il pascal lo studiai alle superiori, e si!!! È molto comodo per capire la sintassi di ST, il quale deriva dal modula 2 che a sua volta deriva dal pascal. Alla fine la differenza più grossa è nella gestione dei blocchi di contesto. L'equivalente { e } del C/C++/Java/.... nel pascal diventa begin/end e in ST rimane solo la chiusura END_xxxx dove xxxx è l'istruzione che ha aperto il contesto, mentre l'apertura del contesto diventa implicita.
Invece per lo stile è difficile consigliare un libro, in quanto per me fu un docente del politecnico, che con la sua mania per la nomenclatura, la pulizia del codice e lo stile me la fece entrare forzatamente in testa. Successivamente ho capito bene la sua mentalità.
Se si usano le strutture organizzate bene, i nomi autoesplicativi ed anche lunghi, e il codice pulito, i commenti servono solo quando si scrivono parti particolarmente criptiche, altrimenti il codice diventa auto commentante.
Se lui vedeva una variabile che si chiamava "a" o "pippo", e l'applicativo funzionava perfettamente, non prendevi nemmeno 18!!! Eri segato! Per lui ogni nome di variabile doveva:
1 - Rappresentare al volo visivamente il significato che aveva come contenitore senza leggere altre righe di codice.
2 - Essere scritta con una regola tale da permetterne una semplicissima ricerca nel codice (In automazione sovente abbiamo i riferimenti incrociati, un tempo non era così).
Era maniaco degli spazi! Una singola riga vuota indicava un cambio di contesto, le identazioni non dovevano avere TAB, ma solo spazi e tutti identici e legati al livello di identazione, in tutte le assegnazioni dovevamo mettere uno spazio prima ed un dopo '=', idem per gli operatori matemetici, un singolo spazio dopo le "," e nessuno prima... L'elenco è lunghissimo e tedioso da scrivere...

Modificato: 20 giugno 2020 da Marco Mondin

[Livio Orsini]

1 ora fa, Marco Mondin ha scritto:

Per lui ogni nome di variabile doveva:
1 - Rappresentare al volo visivamente il significato che aveva come contenitore senza leggere altre righe di codice.
2 - Essere scritta con una regola tale da permetterne una semplicissima ricerca nel codice (In automazione sovente abbiamo i riferimenti incrociati, un tempo non era così).
Era maniaco degli spazi! Una singola riga vuota indicava un cambio di contesto, le identazioni non dovevano avere TAB, ma solo spazi e tutti identici e legati al livello di identazione, in tutte le assegnazioni dovevamo mettere uno spazio prima ed un dopo '=', idem per gli operatori matemetici, un singolo spazio dopo le "," e nessuno prima... L'elenco è lunghissimo e tedioso da scrivere...

 

Sei stato mnolto fortunato ad avere un simile docente.

Io queste cose le ho imparate sulla mia pelle da autodidatta.

[ETR]

Il 20/6/2020 alle 09:30 , Marco Mondin ha scritto:

Se lui vedeva una variabile che si chiamava "a" o "pippo

 

Perfetto, io ne avevo uno che invece attaccava sempre con "pippo" ! Una generazione rubata all'automazione !

 

Grazie per le informazioni. Adesso vado a vedere se la mia raccolta comprende quello che hai citato.

 

Buona giornata a tutti.

 

Ennio

[dcautomation]

Quanti spunti eccezionali. Qualcuno che ha avuto il piacere di leggere il seguente libro:

 

Il linguaggio C, fondamenti e tecniche di programmazione. Di Paul e Harvey Deitel (Pearson)

 

Ho 4 settimane di ferie, sarà una prima lettura entusiasmante. 

[Livio Orsini]

14 minuti fa, dcautomation ha scritto:

Ho 4 settimane di ferie, sarà una prima lettura entusiasmante.

 

De gustibus ....

Io quando lavoravo ,in ferie eseguivo il "memory clear" leggendo qualsiasi cosa purchè fosse lontanissima dagli argomenti inerenti il mio lavoro.

[dcautomation]

14 minuti fa, Livio Orsini ha scritto:

 

De gustibus ....

Io quando lavoravo ,in ferie eseguivo il "memory clear" leggendo qualsiasi cosa purchè fosse lontanissima dagli argomenti inerenti il mio lavoro.

In effetti ho sempre fatto il contrario anche io, ma dopo più di 10 anni di manutenzione, ricerca guasti, installazioni ecc.. Fra un mese inizio la "carriera" di programmatore e vorrei entrarci nel modo migliore. E anche il covid 19 ha fatto la sua parte e purtroppo non posso rientrare in Italia a salutare famiglia e amici, devo intrattenermi in qualche modo.