Evviva SCL! Che ne dite?

[batta]

5 ore fa, Marco Mondin ha scritto:

Non so, ogni softwarista è diverso, ma noi il impieghiamo massimo il 10% del tempo a mettere assieme i pezzi.

Quando parlo di tempo per la stesura di un programma, mi riferisco al tempo che impiego per scrivere il programma. Se per mettere insieme le varie funzioni impieghi solo il 10% di questo tempo, significa che impieghi il 90% del tempo per scrivere le funzioni. Ma, in questo caso, significa che, ogni volta, le riscrivi per quella macchina, senza attingere dalle tue librerie standard.

 

5 ore fa, Marco Mondin ha scritto:

A grandi linee i nostri tempi si dividono così:
60% progettazione software;
10% realizzazione software di controllo mettendo assieme pezzi e implementando le parti mancanti;
20% realizzazione diagnostica (Uso massiccio di message manger e logger) e HMI;
10% debug;

Scusa, ma mi vorresti dire che per decidere come realizzare un programma impieghi 6 volte il tempo che ci metti a scriverlo?
Spiegami cosa intendi tu con "progettazione software" perché, per come la intendo io, proprio non ci siamo.

 

[batta]

7 ore fa, Livio Orsini ha scritto:

Questo è il "tessuto connettivo" che varia da progetto a progetto

Sì, ma è proprio questo che ti porta via tempo.
Esempio banale:
- devo comandare un motore sotto inverter
- ho già la mia funzione di libreria alla quale passo i comandi e che si occupa di gestire l'inverter

- devo però dire a questa funzione quando il motore deve partire, a che velocità deve andare, quando deve fermarsi

Tempo impiegato per il richiamo della funzione e il collegamento delle variabili: 60 secondi.

Tempo impiegato per creare il "tessuto connettivo": 30 minuti.

 

[Livio Orsini]

14 minuti fa, batta ha scritto:

Scusa, ma mi vorresti dire che per decidere come realizzare un programma impieghi 6 volte il tempo che ci metti a scriverlo?

 

Batta, in genere quando siprogetta software, il tempo maggiore lo si impiega per effttuare l'analisi dettagliata del progetto e la sua suddivisione; la codifica vera e propria, cioè la scrittura delle istruzioni è quasi una conseguenza automatica dell'analisi.

Se poi usi "mattoncini" standard prefabbricati e collaudati, il tempo di scrittura si riduce anor di più.

Il blocco standard lo scrivi e lo metti a punto una volta, poi non lo tocchi più.

 

Questo è indipendente dalla macchina, che sia un mainframe o un arduino l'approccio è il medesimo.

 

[Livio Orsini]

2 minuti fa, batta ha scritto:

Esempio banale:

 

Dipende come hai fatto la tua funzione, se è fatta bene ti liiti a richiamarla, quando necessario, passando i parametri.

 

Se, ad esempio, ho un avvolgitore in servo diametro chiamo la funzione e passo i parametri di tiro, diametro minimo e massimo e finisce li

[Marco Mondin]

1 ora fa, batta ha scritto:

Scusa, ma mi vorresti dire che per decidere come realizzare un programma impieghi 6 volte il tempo che ci metti a scriverlo?
Spiegami cosa intendi tu con "progettazione software" perché, per come la intendo io, proprio non ci siamo.

 

Il 10% è il tempo sul totale, in quello includo configurazione ambiente, importazione librerie, ed implementazione di quel 10% del codice specifico per la macchina.

6 Volte è non è per pensare a cosa scrivere, ma per progettare!
Pagine e pagine di diagrammi degli stati.
Pagine e pagine organizzative.
Progettazione delle strutture dati che permettano il corretto grado di privacy negli interscambi tra moduli di un programma.
Micro simulazioni di processo. (Sovente le facciamo in ambient C++ poi traduciamo la logica in ST e la inseriamo nelle cicliche di stato delle varie macchine a stati).

Scrivere il programma alla fine è una mera stupidaggine che richiede un minimo di formazione informatica, la parte complessa per creare un lavoro elegante, modulare, ordinato, organizzato, facilmente estendibile e modificabile per me consiste nella fase di progetto.

Nella fase di progetto scendiamo letteralmente da un linguaggio formale umano a step fino ad un insieme di algoritmi implementabili su sistemi programmabili seguendo un filone di paradigmi e regole in buona parte nate da decenni di esperienza di guru dello sviluppo software.

Posso fare la stessa cosa in decine, centinaia o infiniti modi diversi, ma ci sono modi per fare le cose che per alcuni sviluppatori portano a vantaggi a lungo termine.
Più è grande il framework di librerie e più livelli di astrazione concatenati si usano più si possono realizzare in tempi brevi applicativi molto complessi.
Sul lungo termine paga, in quanto tutto l'investimento fatto prima permette di implementare al volo nelle macchine funzioni che ad altri sprovvisti di tali librerie potrebbe portare a sforare tutti i budget.

Per fare un esempio se mi chiedessero di realizzare una macchina a controllo particolare ed io partissi totalmente sprovvisto di librerie dovrei chiedere (numero buttato lì solo per esempio) 500 ore per fare una cosa base base, simile a come la sviluppa la media di chi fa questo lavoro ed ottenendo lo stesso risultato, in quanto non sono migliore di nessuno.
Partendo con un buon framework in 200 ore potrei fare una macchina con un sacco di fronzoli in più (Oggi molto apprezzati) dando un deciso valore aggiunto rispetto al lavoro che avrei realizzato senza framework ed impiegando al contempo molte meno ore.

In quel tempo di 6 volte, pensiamo molto a come fare le cose, se il lavoro è fatto bene al primo avvio sovente la macchina inizia a funzionare (Non sempre ma in una buona percentuale dei casi è così) i bug si riducono vertiginosamente. Non pensiamo solo a come realizzare la macchina, ma anche a tutta una serie di punti al contorno.
Per esempio se osserviamo che dobbiamo implementare qualcosa di nuovo, valutiamo se è il caso di generalizzarlo e portare parte del lavoro nel framework anziché nel progetto, ed in questo caso si spendono molte ore per integrarlo in modo coerente.

Per poter fare al meglio ciò, siamo fortemente slegati da tutto ciò che sono HMI e SCADA commerciali, tutte le nostre applicazioni, ad eccezione di quelle veramente banali si appoggiano a PC industriali con fortissima integrazione PC/PLC, questo ci ha resi indipendenti da quegli abomini di gestori ricette, gestori allarmi etc preconfezionati.
Alla fine la logica di macchina è quasi sempre la cosa meno impegnativa, le parti difficili sono sempre altre. La matematica per esempio in alcuni processi particolari, il dare all'operatore un dettaglio altissimo delle problematiche che può avere una macchina con logger e gestore messaggi molto curati e dettagliati, il dare all'operatore un editor ricette che parli la sua lingua e non la nostra, sovente corredato di visualizzazioni in 3D (oggi la potenza di calcolo si spreca ed è banale portare grafica openGL con modelli STL per guidare l'utente con viste 3D), offrire spaccati di HMI per smartphone con connessione 4G protetta in SSL per monitorare le macchine ovunque ci si trovi ed in qualunque momento, etc...
Realizzare una macchina che oltre a funzionare in condizioni normali sappia ripartire da sola dal 95% delle situazioni anomale (Operatore che non si fa gli affari suoi e sposta a mano qualcosa)! Dopo uno stop per anomalia, l'operatore non deve fare null'altro che una singola operazione de deve farne di più le cose probabilmente potevano essere fatte meglio!
(Poi il mio socio ogni tanto vuole linciarmi perché sostiene che regalo troppe cose ai clienti.... Solo che a volte mi faccio prendere un po' la mano)

Tutto il tempo che non sprechiamo a riscrivere le stesse noiose cose a livello software (ed io se devo scrivere 2 volte la stessa cosa inizio subito ad annoiarmi) lo dedichiamo ai fronzoli in più ed all'evoluzione.

Ovviamente questo è solo il mio punto di vista, ma ragionando così oggi trovo banale integrare le macchine in un vero concetto di industria 4.0.
 

Modificato: 29 gennaio 2020 da Marco Mondin

[batta]

22 minuti fa, Livio Orsini ha scritto:

Batta, in genere quando siprogetta software, il tempo maggiore lo si impiega per effttuare l'analisi dettagliata del progetto e la sua suddivisione; la codifica vera e propria, cioè la scrittura delle istruzioni è quasi una conseguenza automatica dell'analisi.

 

Il tema della discussione non è tanto come si deve procedere per sviluppare software, ma su SCL e altri linguaggi.
L'analisi è a monte di questo. Al massimo, nell'analisi, posso far rientrare la scelta del linguaggio per i singoli compiti: 0.01% di tutto il tempo?
L'analisi non cambia se programmi in strutturato o in ladder.
Poi, l'analisi, come le nuove funzioni, incide molto quando ti dedichi a qualcosa di completamente nuovo. Se da una vita fai avvolgitori, non perdi ogni volta 200 ore in analisi se ti commissionano un nuovo avvolgitore. Devi sono analizzare le particolarità di quell'avvolgitore, riutilizzare i blocchi già collaudati, e scrivere il codice che serve proprio per quel particolare avvolgitore. Il tempo maggiore quindi, non è né quello per l'analisi, né quello per creare le funzioni, ma è quasi esclusivamente quello che passi con le dita sulla tastiera per scrivere quello che chiami "tessuto connettivo".
 

[Marco Mondin]

30 minuti fa, batta ha scritto:

 

Il tema della discussione non è tanto come si deve procedere per sviluppare software, ma su SCL e altri linguaggi.
L'analisi è a monte di questo. Al massimo, nell'analisi, posso far rientrare la scelta del linguaggio per i singoli compiti: 0.01% di tutto il tempo?
L'analisi non cambia se programmi in strutturato o in ladder.
Poi, l'analisi, come le nuove funzioni, incide molto quando ti dedichi a qualcosa di completamente nuovo. Se da una vita fai avvolgitori, non perdi ogni volta 200 ore in analisi se ti commissionano un nuovo avvolgitore. Devi sono analizzare le particolarità di quell'avvolgitore, riutilizzare i blocchi già collaudati, e scrivere il codice che serve proprio per quel particolare avvolgitore. Il tempo maggiore quindi, non è né quello per l'analisi, né quello per creare le funzioni, ma è quasi esclusivamente quello che passi con le dita sulla tastiera per scrivere quello che chiami "tessuto connettivo".
 

Per fare un esempio pratico in una macchina per pallettizzazione, quello che ci ha portato via più tempo non è stato mettere insieme i pezzi per la gestione della macchina (Per il 90% identici a quasi tutti quelli per la robotica generica che usiamo in un sacco di applicazioni). Le due cose più impegnative sono state il gestore ricette e la realizzazione di percorsi ibridi composti geometricamente da un mix di splines e beziers su cui poi abbiamo anche dovuto smazzarci il calcolo di tutta la dinamica per la costruzione delle camme di percorso in modo tale che la macchina da sola indipendentemente dalla sua configurazione accessori (Rulliere etc) fosse in grado di calcolarsi i percorsi più economici in termini di tempi ciclo.
Il gestore ricette per l'operatore si è ridotto a disegnare solo il bancale con un editor drag & drop 2D per i layout e un gestore 3D per i layers integrati sull'HMI.
Rendendo al contempo le ricette migrabili in macchine con configurazioni etrogenee senza la minima modifica.
Solo la progettazione di queste due parti ha portato via molto più tempo che la mera scrittura del codice. Una parte enorme del tempo che supera di gran lunga lo sviluppo codice è stata l'analisi delle anomalie, la sua categorizzazione per gravità, priorità etc e la compilazione di tutto il db del gestore allarmi (Nel caso specifico abbiamo codificato più di 400 messaggi).

Modificato: 29 gennaio 2020 da Marco Mondin

[batta]

6 minuti fa, Marco Mondin ha scritto:

6 Volte è non è per pensare a cosa scrivere, ma per progettare!
Pagine e pagine di diagrammi degli stati.
Pagine e pagine organizzative.
Progettazione delle strutture dati che permettano il corretto grado di privacy negli interscambi tra moduli di un programma.
Micro simulazioni di processo. (Sovente le facciamo in ambient C++ poi traduciamo la logica in ST e la inseriamo nelle cicliche di stato delle varie macchine a stati).

Insomma, mi stai dicendo che, ad ogni macchina, riparti da un foglio bianco, che non tieni valide tutte le considerazioni, le scelte, la progettazione, fatta per la precedente macchina? Anzi, proprio ti dimentichi cosa hai fatto e perché l'hai fatto sulla precedente macchina?

So benissimo che non è così, ma solo se riprogetti tutto da capo ogni volta mi puoi giustificare questa tua valutazione dei tempi. Oppure su progetti completamente nuovi, non certo su, come hai affermato in un precedente post, macchine costruite in piccole serie, o comunque sulla stessa tipologia di macchina.
Ma scusa, sostieni che si può riciclare una parte veramente alta del codice, e mi vorresti dire che recuperi poco o nulla di tutta la progettazione a monte? Mi dispiace, ma non ti posso certo credere. Anzi, io sostengo esattamente il contrario: sulla stessa tipologia di macchina sai già cosa serve, come va comandata, quali sono i punti critici, come vuoi suddividere le varie parti di macchina, come vuoi gestire le ricette, come affrontare il problema sicurezza di una connessione. Il software diventa quasi l'unica cosa alla quale devi mettere mano.

Inoltre, il tema di partenza non era su cosa ci sia dietro la realizzazione di un programma, ma se sia vantaggioso o meno sviluppare un programma per plc esclusivamente in strutturato. Sarai d'accordo con me che tutte le disquisizioni su (cito): " Matrici, quaternioni, trasformate dirette ed inverse, calcolatori di camme nello spazio editor gCode, tool grafici di visualizzazione etc... ", o su (cito nuovamente):

- Suddivisione in sottomacchine;
- Diagrammi degli stati delle singole sottomacchine e diagramma degli stati della macchina a stati principale;
- Algoritmi cartacei di tutte le transizioni di stato e ricerca di possibili situazioni di dead lock;
- Diagramma delle classi quando usiamo OOP;
- Matematica tutta testata su matlab o la sua controparte free octave;
- Simulazione di processo di piccole parti critiche con svariati tool più o meno specializzati a seconda dei casi;
- Lista più completa possibile di possibili anomalie;
- Schizzi cartacei sulle disposizioni HMI;

- Divisione dei compiti su chi realizza cosa;

 

nulla c'entrano col programmare tutto in strutturato o usare più linguaggi.

 

 

[Marco Mondin]

4 minuti fa, batta ha scritto:

Inoltre, il tema di partenza non era su cosa ci sia dietro la realizzazione di un programma, ma se sia vantaggioso o meno sviluppare un programma per plc esclusivamente in strutturato.

D'accordissimo!
Abbiamo divagato troppo, il succo è che in ST(SCL) per me è più semplice fare crescere le librerie.
È più semplice gestire le macchine a stati.
È più semplice usare una logica prevalentemente sequenziale e non puramente combinatoria.
Poi ognuno è diverso e si trova meglio con metodi diversi.
Io ed il mio socio preferiamo la logica sequenziale in cui sono le parti di codice necessarie girano, altri preferiscono quella puramente combinatoria che si sposa meglio con il ladder.
Ci sono pro e contro in tutti i linguaggi. Certo che se sviluppo il ST seguando la filosofia ladderista combinatoria faccio una schifezza.
Se scrivo in ladder con logica sequenziale faccio esplodere il codice.
Paradigmi diversi, gusti diversi. Per me il ladder (lo ho usato anche molto) non porta alcun vantaggio al mio stile e lo considero morto!
 

(Con piccole serie intendo facciamo il prim sw, poi ci chiamano solo per le messe in servizio e per aggiungere eventuali moduli extra, per il resto ogni nostro lavoro è diverso da altri, nonostante questo il codice, a parte parti come matematica dedicata tendiamo a portarlo quasi sempre in libreria)
 

[acquaman]

1 ora fa, Marco Mondin ha scritto:

altri preferiscono quella puramente combinatoria che si sposa meglio con il ladder.

Con il ladder crei benissimo logiche sequenziali come con SCL, e comunque per le logiche sequenziali il linguaggio migliore è il Graph che è nato apposta. 

[Marco Mondin]

3 minuti fa, acquaman ha scritto:

Con il ladder crei benissimo logiche sequenziali come con SCL, e comunque per le logiche sequenziali il linguaggio migliore è il Graph che è nato apposta. 

Potrebbe darsi per alcuni, ma mi limiterei in modo impressionante nella migrazione da un sistema all'altro!
Facendo tutto in ST, sono più volte passato da OMRON a CODESYS a B&R a SIEMENS con semplici copia ed incolla, ad eccezione dell'ultimo che è un po' diverso di suo.
In LADDER  etc mi tocca rifare ogni volta le stesse cose! È una noia mostruosa!

[batta]

2 ore fa, Marco Mondin ha scritto:

Solo la progettazione di queste due parti ha portato via molto più tempo che la mera scrittura del codice. Una parte enorme del tempo che supera di gran lunga lo sviluppo codice è stata l'analisi delle anomalie, la sua categorizzazione per gravità, priorità etc e la compilazione di tutto il db del gestore allarmi (Nel caso specifico abbiamo codificato più di 400 messaggi).

Forse confondiamo le cose. Forse per te scrivere codice significa solo il lavoro di battitura. Per me, scrivere codice, significa ragionare su come ottenere il risultato desiderato, e tradurre le idee in un qualcosa che possa essere capito, nel mio caso (e nel caso cui si riferisce questa discussione), da un plc.
Decidere come organizzare i dati, fa già parte della scrittura del codice. Decidere come e quali parametri scambiare, fa già parte della scrittura del codice. Dimensionare un array, creare una struttura, anche solo decidere che nome assegnare ad una variabile, fa parte della scrittura del codice. Anche creare un diagramma di flusso fa parte della scrittura del codice, perché è una cosa che mi serve per poter scrivere il codice. Se scrivere codice fosse solo inserire qualche costrutto con un qualche editor, allora per scrivere software non servirebbe un programmatore, ma un dattilografo.

 

[batta]

2 ore fa, Marco Mondin ha scritto:

Se scrivo in ladder con logica sequenziale faccio esplodere il codice.

No, assolutamente. E se lo dico io non non sono certo un amante del ladder...

 

2 ore fa, Marco Mondin ha scritto:

Per me il ladder (lo ho usato anche molto) non porta alcun vantaggio al mio stile e lo considero morto!

La stessa Siemens sta dando sempre meno spazio ad AWL e continua invece a migliorare il ladder. Eppure, man mano che passa il tempo, chi programma plc viene sempre meno dal mondo elettrico, e sempre più dal mondo informatico (con molti vantaggi, ma anche con parecchi svantaggi. L'ideale sarebbe un ibrido). Dunque, Siemens, in una realtà sempre più in mano agli informatici, perde tempo a migliorare il ladder. Un motivo, forse, c'è.

[marco1278]

10 ore fa, Marco Mondin ha scritto:

Prima di mettere giù la prima riga di codice dobbiamo avere chiari:

 

Wow 

Ottimo sistema! 

 

[Marco Mondin]

10 minuti fa, batta ha scritto:

La stessa Siemens sta dando sempre meno spazio ad AWL e continua invece a migliorare il ladder. Eppure, man mano che passa il tempo, chi programma plc viene sempre meno dal mondo elettrico, e sempre più dal mondo informatico (con molti vantaggi, ma anche con parecchi svantaggi. L'ideale sarebbe un ibrido). Dunque, Siemens, in una realtà sempre più in mano agli informatici, perde tempo a migliorare il ladder. Un motivo, forse, c'è.

Filosofia che sembra segua anche OMRON. Mentre agli antipodi abbiamo B&R, Beckhoff e Codesys che spingono dal lato opposto ed hanno un ambiente molto più user friendly per chi proviene dalla formazione informatica.

[ifachsoftware]

Il 28/1/2020 alle 16:46 , acquaman ha scritto:

Continuate a considerare il software come il prodotto finito, cambiate mentalità, il prodotto è la macchina, questa deve essere manutenuta, può essere modificata, implementata con muove produzioni, impianti che nascono con uno scopo possono essere nell'arco della vita riadattare e riutilizzate, se compro un impianto per fare vino e dopo 2 anni decido di fare birra devo essere libero e nelle condizioni di farlo.

Queste errate considerazioni portano poi il cliente finale a imporre dei paletti (tipo imporre il ladder) perchè si è trovato in difficoltà con software troppo complessi e magari ha avuti un fermo produzione per un software troppo complesso dove il manutentore non è riuscito a trovare un guasto.

 

 Se in ladder infili quei concetti hai sbagliato ad usare il ladder per quella parte di programma dovevi usare l'SCL.

I Concetti di Polimorfismo ecc non sono legati al linguaggio con cui vengono implementati

 

Il fatto di strutturare per bene del codice indipendentemente dal linguaggio lo si capisce a fronte di continue modifiche al software stesso.

Un programma scritto per bene si adatta facilmente , un software scritto male dopo poche modifiche richiede spesso minori tempi a riscriverlo che a farci manutenzione.

 

[Marco Mondin]

38 minuti fa, ifachsoftware ha scritto:

Il fatto di strutturare per bene del codice indipendentemente dal linguaggio lo si capisce a fronte di continue modifiche al software stesso.

Un programma scritto per bene si adatta facilmente , un software scritto male dopo poche modifiche richiede spesso minori tempi a riscriverlo che a farci manutenzione.

Stiamo tornando off topic, ma concordo pienamente. Solo che sovente i paradigmi che si usano per scrivere bene in tale senso vanno a cozzare con la mentalità di chi ragiona in puro stile elettromeccanico e si limita a pensare che il software sia solo un insieme di costrutti a logica booleana ignorando il 90% della teoria che sta alla base dello sviluppo software.