Evviva SCL! Che ne dite?

[Livio Orsini]

35 minuti fa, acquaman ha scritto:

ma la gran parte del codice di una macchina e customizzato per quella macchina,

 

Forse abbiamo esperienze differenti, ma ti garantisco che quando lavoravo con i PLC avevo ricreato la metodologia che usavo con i micro calcolatori: piccole funzioni parametrizzabili con le quali potevo affrontare buona parte delle macchine / impianti da automatizzare.

La sostanziale differenza era costituita dal fatto che, mentre per i micro usavo prevaletemente "C", quindi senza vincoli di macchina, per i PLC al tempo disponevo solo del ladder e di quello che siemens chiama awl e che altri definiscono in modi differenti, quindi i blocchi bisognava riscriverli per ogni macchina, anche se era solo una riscrittura formale.

[acquaman]

19 minuti fa, Livio Orsini ha scritto:

Forse abbiamo esperienze differenti,

Sicuramente, non lavorando su macchine di serie, ma su impianti di assemblaggio o di processo sempre differenti, negli anni mi sono creato una buona libreria di funzione che riutilizzo, ma non c'è modo di standardizzare qualcosa sempre differente.

[Livio Orsini]

16 minuti fa, acquaman ha scritto:

Sicuramente, non lavorando su macchine di serie, ma su impianti di assemblaggio o di processo sempre differenti, negli anni mi sono creato una buona libreria di funzione che riutilizzo, ma non c'è modo di standardizzare qualcosa sempre differente

 

Non sono d'accordo, cambia solo "il tessuto connettivo" e qualche sequenza particolare, ma almno il 60% del programma lo èpuoi ricavare da blocchi standard, se li hai progettati bene. Io ho avuto esperienza su macchine di quasi tutti i tipi di produzioni: gomma, carta, plastica, lamiera, fili metallici, tessile (filati e tessitura), siderurgia, alimentari.... e altro. E per mia esperienza, facendo le cose bene, si piò standardizzare molto.

Tra l'altro io non ho quasi mai usato le librerire standard dei produttori di PLC.

[acquaman]

2 minuti fa, Livio Orsini ha scritto:

ma almno il 60% del programma lo èpuoi ricavare da blocchi standard

Assolutamente, ma io considero la parte del ciclo, la sequenza il cuore del programma e li che si vede la differenza tra un bravo programmatore plc e uno meno bravo, come si muove la la macchina, non se il programma è scritto in ladder o in SCL, quello lo può apprezzare un altro programmatore che legge il programma.

Del resto ribadisco, programmiamo macchine non facciamo programmi quello lo fanno gli informatici ed è la differenza che ci separa.

[Marco Mondin]

45 minuti fa, acquaman ha scritto:

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

Per quale motivo di grazia???

Chi ha detto che il polimorfismo e l'ereditarietà si sposano male con il ladder???

In realtà evitano una quantità abnorme di codice inutilmente ridondato.

Se ho N componenti aggiuntivi di tipo diverso, ma che condividono alcune piccole parti e tali parti sono uguali in tutti creo un oggetto astratto con la parte comune, poi lo specializzo in quelli che verranno poi istanziati.

Avere istanze di oggetti ed il codice comune in un oggetto astratto mi evita di avere lo stesso codice riportato in più punti di un applicativo. Questo è comodo anche in LADDER, mica solo in altri linguaggi!

Esempio:
Primo livello di astrazione:
Componente astratto per macchina.

Secondo livello di astrazione:
Torretta utensili generica ESTENDE Componente astratto per macchina.
Contropunta generica ESTENDE  Componente astratto per macchina.
.......
.......

Terzo livello di astrazione:
Torretta pneumatica ESTENDE Torretta utensili generica.
Torretta servocontrollata ESTENDE Torretta utensili generica.
......
Contropunta a finecorsa ESTENDE Contropunta generica.
Contropunta a riga analogica ESTENDE Contropunta generica.
Contropunta servocontrollata ESTENDE Contropunta generica.
......

Oggetto Gestore parti ausiliarie macchina a controllo:
Istanzia una torretta;
Istanzia una contropunta;
Istanzia ............

L'oggetto Gestore parti ausiliarie è libero di comunicare con le parti ausiliarie senza necessità di conoscerne i dettagli implementativi.
Questo, sia esso fatto in LADDER, sia esso fato in ST o qualunque altro linguaggio o con un mix di linguaggi è sempre comodo.

[Marco Mondin]

9 minuti fa, Livio Orsini ha scritto:

 

Non sono d'accordo, cambia solo "il tessuto connettivo" e qualche sequenza particolare, ma almno il 60% del programma lo èpuoi ricavare da blocchi standard, se li hai progettati bene. Io ho avuto esperienza su macchine di quasi tutti i tipi di produzioni: gomma, carta, plastica, lamiera, fili metallici, tessile (filati e tessitura), siderurgia, alimentari.... e altro. E per mia esperienza, facendo le cose bene, si piò standardizzare molto.

Tra l'altro io non ho quasi mai usato le librerire standard dei produttori di PLC.

Sono della stessa idea. SI può riciclare una percentuale veramente alta del codice.
Anche io ed il mio socio ci scriviamo le librerie e usiamo con parsimonia quelle messe a disposizione dai produttori. Questo ci permette di non essere vincolati ad un produttore.

[acquaman]

Il manutentore elettromeccanico deve poterci mettere mano per la manutenzione, ricerca guasti, implementazioni, ecc. Uno dei parametri che mi fa scegliere un linguaggio da un'altro è anche il livello di manutenzione che c'è e che dovrà gestire per anni, anche dopo che tu non ci sarai.

Se in manutenzione elettromeccanico (e ricordati non sotto valuarlo mai) non c'è un ingeniere informatico devi scrivere il software in modo che lo capisca.

Sembro un disco rotto, ma tu programmi, non programmi macchine, perdi di vista l'obbiettivo, che non sei tu ma la macchina, l'operatore, il manutentore, il ciclo di lavorazione, la qualità, la produttività,..............................................................

 

Modificato: 28 gennaio 2020 da acquaman

[dcautomation]

2 ore fa, Marco Mondin ha scritto:

Se un programma è scritto bene in Ladder si legge bene, se scritto bene in ST e/o C/C++ non ci trovo differenze ed il debug mi porta via lo stesso tempo. Se scritto male in Ladder da qualche cinghiale comunque ci si raccapezza, se scritto male in ST etc... è da suicidio fare debug.

Mi sembra di capire, da quel che scrivi, che usi decisamente molto di più i linguaggi di alto livello, quando e su quali prodotti usi di più ST e/o C/C++? Per quanto riguarda il C#, è usato al giorno d'oggi? 

[pilota60]

Che un manutentore non debba avere la possibilità di mettere le mani sulla logica è un discorso decisamente presuntuoso.
Al di là del fatto che qualcuno mi deve dimostrare che andando a fare un commissioning / start-up la logica funzioni alla prima.
In 20 anni di trasferte, pur lavorando con ingegnerie validissime, c'era sempre da metterci le mani, una volta dal cliente.
Ma poi, se il cliente ti chiede di fare una modifica e si sta in Malesia, cosa succede : che il mitico creatore di software, che non muove il cu*o dalla sedia nemmeno per prendere il caffè alla macchinetta, prepara la valigia e parte?
Qui ancora vedo gente che non ha capito che il lavoro deve essere di squadra, altrimenti ci andasse l'ingegnere a farsi 150-200 giorni di trasferte l'anno in giro per il mondo, con i suoi trucchetti ed elaborazioni private sui software.

[Marco Mondin]

21 minuti fa, pilota60 ha scritto:

Qui ancora vedo gente che non ha capito che il lavoro deve essere di squadra, altrimenti ci andasse l'ingegnere a farsi 150-200 giorni di trasferte l'anno in giro per il mondo, con i suoi trucchetti ed elaborazioni private sui software.

Io le trasferte le faccio molto volentieri, in quanto pagano molto bene! Per gli affinamenti ci sono precollaudo, FACT, zero production, solitamente diamo anche assistenza ai SAT ma non si deve toccare il sw pena fallimento del SAT!!! Le modifiche di solito si fanno da remoto tramite VPN, in rarissime occasioni è necessario muoversi.
Se compero una lavatrice ed ha un malfunzionamento contatto la casa che lo risolva! Mica chiedo il firmware e ci metto le mani io!!!
Io potrei dire che è presuntuoso il contrario! Nel software dobbiamo anche imparare a far valere la proprietà intellettuale!

[acquaman]

25 minuti fa, pilota60 ha scritto:

che non muove il cu*o dalla sedia

Non sono tutti cosi fortunati, che sappia io, la maggior parte sviluppa, mette in servizio e installa

[pilota60]

Peccato che chi fa software e chi fa trasferte facciano due lavori diversi.
Se tu dovessi fare trasferte non riusciresti a fare software, visto che saresti fuori per mesi.
E non è che se ne fai 1-2 l'anno hai risolto tutti i bug che escono sistematicamente fuori quando si vanno a fare gli start-up.
Ma forse nella tua ditta siete in 1-2 persone , in quel caso sei obbligato a fare tutto tu.
Ma ti assicuro che da altre parti funziona in modo diverso.
E le teleassistenze le puoi fare per bischerate, non certo per bug che necessitano di ore , se non giorni per arrivare alla soluzione.
Senza considerare che necessitano di personale sul posto che non sempre un cliente, che ha pagato caro un progetto e che vede non funzionare, ti mette a disposizione.

Modificato: 28 gennaio 2020 da pilota60

[acquaman]

La normativa macchine dice che il cliente finale ha diritto di avere e poter mettere mano a tutto, cosi come DEVE avere i disegni meccanici e gli schemi elettrici deve anche avere il software.

Se muori, o se la tua azienda fallisce i tuoi clienti cosa fanno se non hanno più il tuo supporto buttano via  l'impianto?

[Marco Mondin]

37 minuti fa, dcautomation ha scritto:

Mi sembra di capire, da quel che scrivi, che usi decisamente molto di più i linguaggi di alto livello, quando e su quali prodotti usi di più ST e/o C/C++? Per quanto riguarda il C#, è usato al giorno d'oggi? 

Si, anche se quando si usano C è C++ il livello è variabile da alto a basso a seconda del paradigma che si usa. C in particolare può scendere quasi al livello di un assembly.
C# lo usiamo nella parte PC quando necessario per esempio ci è capitato di dover offrire un servizio WCF per la tracciabilità nell'ambito del tabacco.
Dì solito usiamo ST(anche per imposizione il c e c++ sono poco accettati) se sviluppiamo su controlli/plc. Ladder all'occorrenza e su piccole parti se obbligati.
Su PC sviluppiamo prevalentemente in C++ appoggiandoci ad un framework molto completo e multi piattaforma, il quale ci permette di ricompilare lo stesso codice su svariati OS (Windows, Linux, MacOS, Android, VxWorks e QNX) denza grosse variazioni al sorgente (Giusto una manciata di #IFDEF qua e la per piccole differenze).
Su tale ambiente abbiamo decine di librerie che continuiamo ad evolvere per interfacciarci ad ogni genere di PLC/Controllo e gestionale. Ormai abbiamo una enorme libreria di oggetti per la gestione della matematica nello spazio e della dinamica (Matrici, quaternioni, trasformate dirette ed inverse, calcolatori di camme nello spazio editor gCode, tool grafici di visualizzazione etc...)
Usiamo Java su android per sviluppare HMI su TAB e SmartPhone.

 

Modificato: 28 gennaio 2020 da Marco Mondin

[acquaman]

10 minuti fa, Marco Mondin ha scritto:

Nel software dobbiamo anche imparare a far valere la proprietà intellettuale!

Comunque nessuno compra il tuo software compra le tue macchine.

[Marco Mondin]

9 minuti fa, acquaman ha scritto:

La normativa macchine dice che il cliente finale ha diritto di avere e poter mettere mano a tutto, cosi come DEVE avere i disegni meccanici e gli schemi elettrici deve anche avere il software.

Se muori, o se la tua azienda fallisce i tuoi clienti cosa fanno se non hanno più il tuo supporto buttano via  l'impianto?

Spero di non morire a breve, comunque se la macchina funziona ed ha un backup dei binari facilmente reinstallabile non ci sono grossi problemi di solito.
In alcuni casi abbiamo rilasciato pezzi di sorgente, ma teniamo rigorosamente chiuse alcune librerie. Alla fine la parte che possono toccare in quei rari casi è l'unica che gli serve per piccole personalizzazioni.
Se il cliente a contratto non ha la cessione del sorgente non ha diritto a nulla!
Se vuole comperare il sorgente ci deve pagare le migliaia di ore impiegate nello sviluppo di tutto il nostro framework! (Messa così sovente desistono)

4 minuti fa, acquaman ha scritto:

La normativa macchine dice che il cliente finale ha diritto di avere e poter mettere mano a tutto, cosi come DEVE avere i disegni meccanici e gli schemi elettrici deve anche avere il software.

Se muori, o se la tua azienda fallisce i tuoi clienti cosa fanno se non hanno più il tuo supporto buttano via  l'impianto?

Spero di non morire a breve, comunque se la macchina funziona ed ha un backup dei binari facilmente reinstallabile non ci sono grossi problemi di solito.
In alcuni casi abbiamo rilasciato pezzi di sorgente, ma teniamo rigorosamente chiuse alcune librerie. Alla fine la parte che possono toccare in quei rari casi è l'unica che gli serve per piccole personalizzazioni.
Se il cliente a contratto non ha la cessione del sorgente non ha diritto a nulla!
Se vuole comperare il sorgente ci deve pagare le migliaia di ore impiegate nello sviluppo di tutto il nostro framework! (Messa così sovente desistono)

[acquaman]

In questo momento, Marco Mondin ha scritto:

Se il cliente a contratto non ha la cessione del sorgente non ha diritto a nulla!

Non è il cliente che lo dice, ma la normativa macchine, la legge.

Non so di cosa ti occupi ma da quello che hai scritto mi sa che ti occupi più gestione dati tracciabilità e simili che impianti, e sono due cose differenti.

[Marco Mondin]

11 minuti fa, acquaman ha scritto:

Non è il cliente che lo dice, ma la normativa macchine, la legge.

Non so di cosa ti occupi ma da quello che hai scritto mi sa che ti occupi più gestione dati tracciabilità e simili che impianti, e sono due cose differenti.

Comunque nessuno compra il tuo software compra le tue macchine.

Facciamo anche quello, poi sviluppiamo software per macchine di collaudo, movimentazione etc con cinematiche particolari o configurazioni particolari.
Per esempio di recente abbiamo realizzato una macchina ibrida con una parte di assi elettrici interpolati ad assi idraulici.
Per quello che riguarda la normativa macchine, uno dei nostri clienti più grossi ci ha proibito di lasciare il SW ai clienti finali (Comunque non era a contratto e non lo avremmo fatto) e tali clienti sono multinazionali del tabacco. Questo è uno dei casi in cui a contratto il nostro cliente ha voluto la proprietà di una piccola parte del codice, firmando a contratto davanti a due avvocati che le librerie sarebbero rimaste nostre e consegnate solo in forma binaria.

Sempre sulla normativa macchine! Se il software è sigillato sono responsabile io e mi assumo le mie responsabilità per quello che può succedere. Se qualcuno ci mette le mani dimostrare in tribunale che non sono stato io sarebbe molto difficile. Con un software chiuso io firmo per una cosa consegnata ed essendo responsabile di quella cosa esigo che non venga modificata senza mia autorizzazione e/o supervisione. Non mi piace quando un altro gioca con la mia fedina penale!

Qualcuno compera anche il software, o meglio le librerie che sviluppiamo. Ovviamente solo i binari.

Modificato: 28 gennaio 2020 da Marco Mondin

[batta]

5 ore fa, Marco Mondin ha scritto:

Per altro se gli applicativi diventano molto grossi (più di 50000 linee di codice) il ladder diventa troppo dispersivo e ci andrebbe lo spazio di una enciclopedia per contenerlo.
Per non parlare del tempo! Se in ST ci metto 1600-2000 ore uomo per un progetto medio grande non immagino nemmeno quanto ci metterei in LADDER, ma certamente il committente non lo accetterebbe mai!

Io ho lavorato anche su programmi da 10-15 mila pagine, non righe, di codice. E, se ho fatto un misto ladder, strutturato e awl, è stato proprio perché per ogni compito utilizzavo il linguaggio più adatto, anche per risparmiare tempo. Non mi puoi dire che, in ogni occasione, scrivendo in strutturato risparmi tempo. Ci sono cose che si fanno meglio e più velocemente in strutturato, e cose che si fanno meglio e più velocemente in ladder.

 

5 ore fa, Marco Mondin ha scritto:

l'elettromeccanico medio non può più metterci mano in quanto è piuttosto difficile fagli capire cosa siano polimorfismo ereditarietà ed interfacce implementabili.

Non sono queste le cose sulle quali deve agire il manutentore, ma non puoi impedirgli di accedere, magari solo in lettura, a sequenze del ciclo o a parti di programma che possono essere indispensabili per risalire all'origine di un guasto.

Sappiamo tutti benissimo che il software non si guasta. Salvo la presenza di bachi, i problemi sono sempre il sensore regolato male, la fotocellula che si è spostata, un filo scollegato, un gioco meccanico od un attrito anomalo, il giunto di un encoder, una connessione di rete ballerina, e molto altro. Ma, per risalire al guasto, anche in presenza di un'ottima diagnostica, a volte entrare nel programma è indispensabile. Quindi, o tu, quando il cliente ti chiama, sei operativo in mezz'ora, a qualsiasi ora del giorno o della notte, o dai la possibilità di intervenire ai manutentori.

 

 

2 ore fa, Marco Mondin ha scritto:

Se compero una lavatrice ed ha un malfunzionamento contatto la casa che lo risolva! Mica chiedo il firmware e ci metto le mani io!!!

Non stai vendendo una lavatrice, che se si rompe puoi portare gli indumenti in lavanderia. Stai vendendo un oggetto che, se si ferma, potrebbe causare perdite per mancata produzione astronomiche. Fornire o non fornire il software fa sempre parte degli accordi. Personalmente, non acquisterei mai una macchina sulla quale non posso mettere le mani.
 

 

4 ore fa, Livio Orsini ha scritto:

Non sono d'accordo, cambia solo "il tessuto connettivo" e qualche sequenza particolare, ma almno il 60% del programma lo èpuoi ricavare da blocchi standard, se li hai progettati bene.

Non condivido. Puoi aver creato una vasta libreria di "mattoncini Lego" (penso che, chi più, chi meno, tutti noi lo facciamo), ma poi questi mattoncini Lego bisogna metterli assieme. 

Perché una macchina funzioni bene, c'è bisogno sia di mattoncini Lego costruiti bene, sia unire bene questi mattoncini tra loro. E, su come si devono mettere insieme, ogni macchina ha la sua storia. I mattoncini, una volta realizzati e testati, hai finito di perderci tempo (salvo piccole modifiche migliorative). Per metterli insieme, ci devi perdere tempo ad ogni nuovo programma. E' questo che ti porta via il 90% del tempo per lo sviluppo del programma.

 

 

[Livio Orsini]

9 ore fa, batta ha scritto:

ma poi questi mattoncini Lego bisogna metterli assieme. 

 

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

 

9 ore fa, batta ha scritto:

E' questo che ti porta via il 90% del tempo per lo sviluppo del programma.

 

ma se tu non avessi fatto le tue funzioni, impiegheresti 150% del tempo impiegato.

[Marco Mondin]

11 ore fa, batta ha scritto:

Non condivido. Puoi aver creato una vasta libreria di "mattoncini Lego" (penso che, chi più, chi meno, tutti noi lo facciamo), ma poi questi mattoncini Lego bisogna metterli assieme. 

Perché una macchina funzioni bene, c'è bisogno sia di mattoncini Lego costruiti bene, sia unire bene questi mattoncini tra loro. E, su come si devono mettere insieme, ogni macchina ha la sua storia. I mattoncini, una volta realizzati e testati, hai finito di perderci tempo (salvo piccole modifiche migliorative). Per metterli insieme, ci devi perdere tempo ad ogni nuovo programma. E' questo che ti porta via il 90% del tempo per lo sviluppo del programma.

 

 

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

 

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;

Prima di mettere giù la prima riga di codice dobbiamo avere chiari:
- 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;

Solo dopo tutto questo scriviamo codice, che poi alla fine è solo più tradurre in un qualunque linguaggio di programmazione tutto ciò che abbiamo progettato.

 

Tutto questo ha un costo, o il cliente lo accetta o si trova un altro softwarista.

Modificato: 29 gennaio 2020 da Marco Mondin

[Livio Orsini]

1 ora fa, Marco Mondin ha scritto:

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

.......

 

 

Concordo in tutto; questo è il lavoro di analisi e progettazione, senza di questo, anche se alla fine la macchina gira, è sempre una cosa mal fatta.

Senza contare che l'uso di funzioni e sottofunzioni standard riduce al minimo lo possibilità di errori di software, quindi maggior affidabilità e minor tempo di debug ed avviamento.

[dcautomation]

8 minuti fa, Livio Orsini ha scritto:

 

 

Concordo in tutto; questo è il lavoro di analisi e progettazione, senza di questo, anche se alla fine la macchina gira, è sempre una cosa mal fatta.

Dove si acquisiscono queste competenze per quanto riguarda la struttura del codice? Cosa bisogna studiare per avere una buona base? 

[Livio Orsini]

6 minuti fa, dcautomation ha scritto:

Dove si acquisiscono queste competenze per quanto riguarda la struttura del codice? Cosa bisogna studiare per avere una buona base? 

 

Conoscenza di base di informatica, più tanta esperienza professionale maturata in aziende dove si sa lavorare.

Sembra banale, ma è la realtà.

Poi su tutto questo bisogna mettere molto di se stessi, le competenze non ti cascano addosso, ma devi ricecarle, oserei dire stanarle.

Modificato: 29 gennaio 2020 da Livio Orsini

[Marco Mondin]

41 minuti fa, dcautomation ha scritto:

Dove si acquisiscono queste competenze per quanto riguarda la struttura del codice? Cosa bisogna studiare per avere una buona base? 

Lo studio aiuta in modo mostruoso, nel senso che le maggiori linee guida sulla metodologia di progettazione software conducono quasi sempre agli stessi concetti.
Per altro non si finisce mai di studiare! Il progresso è frutto di continuo impegno ed evoluzione, un traguardo non può esistere, esistono solo tappe intermedie.
L'esperienza nello sviluppo software è indispensabile.
Il tempo è la risorsa più imprescindibile in quanto solo con il tempo ci si costruiscono grossi framework di librerie e tools.