Vivissimi ringraziamenti

[ETR]

Mi permetto di aggiungere una risposta, dato che si ricollega sempre al discorso della mia discussione e quindi l'interpretazione del software.

 

Perché un manutentore dovrebbe interpretare il mio software ? Cosa gli serve ? Se io fossi (uso il condizionale) bravo, avrei previsto le varie casistiche di errore e fornirei l'indispensabile per poter arrivare alla soluzione del problema (interfaccia HMI, informazioni POPUP, grafica ecc...). Se invece non lo fossi (cosa molto più probabile) o comunque qualcosa sfuggisse al mio controllo, uno straccio di connessione la si potrebbe magari avere  (anche qua condizionale perché MOLTE aziende, anche di GROSSA dimensione, non vogliono assolutamente accedere a questo servizio e continuano con l'idea che tutto vada gestito internamente) ?

 

Se il ladder lo intendiamo, come utilità di visualizzare un "powerflow", cioè il grassetto del disegno grafico dei contatti, posso anche concordare, per un logo. Ma nel momento che come per esempio B&R, ultimamente sta promuovendo librerie che praticamente dovrebbero (non le ho ancora usate) fare tutto loro, dando in pasto il contatto diretto, una volta che il contatto ce l'hai fisicamente sul modulo hardware plc, ce l'hai fisicamente sul tool web di controllo della logica e poi scompare praticamente nel blocco funzione, come manutentore, sei di nuovo in balia del programmatore.

 

Come il gatto che si morde la coda, siamo di nuovo ad uno dei capisaldi dell'opposizione PLC/Programmazione e cioè l'incapacità di agire e di essere in balia di qualcun altro (e quindi magari fermi con la produzione). Siccome è uno dei tanti aspetti che hanno generato la mia discussione con il cliente e quindi questo topic, le alternative si chiamerebbero :

- Contratti di assistenza

- Utilizzo della tele assistenza

- Ricambistica

- Programmazione della manutenzione

- Controllo della manutenzione ordinaria sugli impianti affidati

- e come ultimo - COMUNICAZIONE, intesa come scambio di informazioni... parlare

 

Siccome non ne ho molti di clienti di questo tipo, gli altri sono saccenti, tirchi, prepotenti, pretenziosi e cosi via ... per cui perché devo fare i salti mortali per rendere fruibile al manutentore del codice in 100 step, quando magari potrebbe essere snella in 10 ? Tutto torna a mio vantaggio, specialmente economico, se non ché il solito "cliente", il vantaggio economico lo vuole per se, poi la semplicità di lettura senza attingere assolutamente a quanto citato prima e magari la possibilità di copiarlo a piacimento.

 

Ritorniamo al discorso iniziale. Se pagassero TUTTO, non saremmo qua a discuterne.

 

Ciao, Ennio

[Livio Orsini]

Teoricamente il manutentore non dovrebbe interpretare alcunchè della programamzione.

Il software, per definizione, non si guasta.

Quindi se c'è un malfunzionamento della macchina o impianto o è un problema di Hw o è un errore di programma.

 

Se è un guasto Hw non ne è necessario, ne è di alcun aiuto, interpetare la programmazione.

Se è un errore di programma il manutentore non deve intervenire, ma è un problema che deve essere risolto dal fornitore. Inoltre non dico che è impossibile, ma è abbastanza difficle che l'errore possa essere individuato ed emendato dal manutentore.

 

Il vero motivo della richiesta di linguaggi di programmazione ladder diagram, da parte dei committenti, è la volontà di essere indipendenti in caso di modifiche. Indipendenza che è illusoria se non per modifiche banali come l'aggiunta di un contatto in serie o l'inversione di un contatto.

[barby]

Ciao ETR, ho fatto un corso B&R presso la filiale di Padova alcuni anni fa e me ne sono innamorato subito. Il C a quei tempi l'avevo scartato perchè non lo conoscevo, quindi mi sono concentrato sul testo strutturato. Poi purtroppo per vari motivi il progetto con B&R non è andato avanti però oramai mi ero sporcato le mani con il testo strutturato e ho iniziato ad usarlo su Omron e Siemens. Ora in pratica uso solo questo linguaggio anche se a detta di molti non è una buona pratica.

Ritorna regolarmente l'annosa questione dei manutentori che vogliono il ladder e ultimamente devo sottostare a capitolati dove è richiesto.

 

Quote

Perché un manutentore dovrebbe interpretare il mio software ? Cosa gli serve ? Se io fossi (uso il condizionale) bravo, avrei previsto le varie casistiche di errore e fornirei l'indispensabile per poter arrivare alla soluzione del problema

 

quoto 100% !

 

barby

 

 

[ETR]

Ciao barby,

 

Quote

Ora in pratica uso solo questo linguaggio anche se a detta di molti non è una buona pratica.

 

Senza sconfinare troppo dall'argomento iniziale, altrimenti, in questa discussione potremmo riassumere tutti i mali che affliggono la programmazione presso terzi, mi piacerebbe conoscere questi "molti". Considera che comunque l'AWL "potrebbe" essere ricondotto ad uno strutturato (solo perché scritto e non grafico e non istigo altre discussioni), poi io, nel mio personale, informatica l'ho cominciata con il PASCAL che ci azzecca in pieno ed alla fine stiamo programmando operazioni binarie ed il ladder, NESSUNO lo usa a livello informatico è solo una convenzione di "comodo" per l'ambito elettrico.

 

Chi nasce "informatico", quelle stanghette che si illuminano, gli sembrano un giochino anni 90, stile mario bros . Poi è ovvio, innegabile, che è di facile utilizzo e di facile lettura/comprensione, ma vogliamo ancora discutere, per chi ? In molti casi siamo legati, quasi zavorrati, da questo problema, che prima o poi dovrà essere risolto vista l'integrazione sempre più massiccia tra i vari mondi e dispositivi, dove non ci sarà più posto per il ladder come linguaggio di programmazione.

 

Come battuta, potremmo anche discutere degli altri stili di programmazione (tipo SCL o a blocchi grafici, stile Labview), ma ognuno ha comunque dei limiti e dei pregi, finalizzati al proprio ambito. Riassumendo ritengo il ladder, sempre più delegato e relegato, per funzioni basilari o logica di facile "fruizione" , ma che non dovrebbe essere preso come riferimento per uno sviluppo dell'automazione.

 

Ciao Ennio

[Livio Orsini]

 

Quote

Chi nasce "informatico", quelle stanghette che si illuminano,.....

 

Non bisogna dimenticare quando, come e perchè è nato il PLC.

 

Nei primi anni 70' del secolo scorso, la GM nella ricerca di rendere più facile e flessibile la progettazione-costruzione delle proprie linee di produzion,e lanciò una gara per un dispositivo programmabile che sostituisse gli armadi di logiche a relè.

Tra le specifiche di maggior peso c'era quella relativa alla programamzione.

Ai tempi erano già diffusi i calcolatori di processo che governavano i grossi impianti: leder era senz'altro digital con i suoi PDP8 e PDP11 (questo fu un vero e proprio mito). Poi i 2 grandi costruttori GE e Westinghose avevano i loro modelli.

Programamare e amnutenere un impianto controllato da un minicalcolatore era un vero e proprio lavoro da specialisti. Si programmava esclusivamente in assembler, l'interfaccia operatore era ancora costituita da teletype e nastro perforato e, in alcuni casi, era disponibile anche un rudimentale terminale video da 14" che dopo 2 ore di lavoro ti procurava una bella congiuntivite.

Bisognava conoscere il sistema operativo in real time della macchina e solo per effettuare il boot loader all'avvio era necessario effettuare una sequenza simele alla combinazione di una cassaforte da caveu di banca.

 

La condizione principale dei nuovi dispositivi programmali era che dovevano poter essere usati e programamti dai manutentori di fabbbrica.

Modicon e A&B presentarono 2 progetti, abbastanza simili. Si trattava di un vero minicalcolatore industriale, completo di I/O digitali, con un sistema operativo che veiva caricato in automatico ed era trasparente per l'operatore perchè, sempre in automatico, lanciava il Job PLC.

Il linguaggio di programamzione era costituito da simboli di contatti che potevano essere combinati in serie e parallelo per attivare o meno delle bobine di relè.

Essendo le aziende interessate tutte USA, si usò la simbologia USA, quindi contatto che assomiglia al simbolo di un  condensatore e bobina di relè stilizzata da "()" per richiamare alla mente il cerchietto che la rappresenta nei disegni.

 

Poi con l'avvento dei microporoccesori, pochi anni dopo, comparvero i fratelli minori di questi "mostri" che occupavano alcune ante di armadio. Erano dei grossi scatoloni che però mancavano dell'organo di programamzione. La programamzione si effettuava con una tastiera con tasti su cui eran riportati i simboli del linguaggio a contatti. Il risultato del programma  veniva scritto in una o più EPROM, dispositivi appena nati.

Ricordo che nel 1975 progettai un micro PLC (il mio primo PLC), basato su di un ICU motorola che esguiva operazioni booleane, con tastira di programamzione e display di 6 digit che mostrava in un'unica riga codice numerico dell'istruzione e lcoazione di memoria. In più era possibile far eseguire il programma sino ad una locazione bene precisa ed anche avanzare di un passo alla volta. tuto questo era lo stumento di debugging.

 

Da quel momento l'evoluzione è stata rapidissima, tanto che oggi un PLC classe S7-400 è molto più potente e performante dell'antenato che occupava 4 ante di armadio di cui una sola per CPU, memoria e alimentatori.

 

Però i manutentori si sono evoluti di poco, quindi il liguggio "ladder diagram" sopravviverà ancora per alcuni (parecchi) anni.

 

Non dimentichiamoci che anche i programmatori di PLC, mediamente, non sono poi molto evoluti. C'è ancora molta gente, troppa, che programma i PLC a "mazzate" con programmi che sono una collezione di "pezze" e che non sono mai stati progettati ma costruiti durante l'avviamento della macchina cercando di far fare alla macchina il necessario.

[dott.cicala]

Quote

Se io fossi (uso il condizionale) bravo, avrei previsto le varie casistiche di errore e fornirei l'indispensabile per poter arrivare alla soluzione del problema

 

Questo è possibile solo se l'impianto prevede un funzionamento molto semplice e con un numero di variabili estremamente limitato.

 

Altrimenti vorrebbe dire che la parte di software relativa all'autodiagnosi è più consistente di quanto serva all'impianto per svolgere i suoi compiti.

 

Se il funzionamento è sofisticato, allora, potranno esistere delle parti del programma che possono essere sviluppate in ladder e altre dove sono necessari calcoli complessi, dove il ladder non è applicabile, salvo essere masochisti.

 

Di conseguenza, se è possibile sviluppare tutto il programma in ladder, allora, il compito non è complesso e per tale ragione non sono richieste elevate competenze per la sua comprensione ma a questo punto, che sia scritto in un modo o in un altro, quello che potrà cambiare è il tempo necessario al manutentore per interpretarlo. Ma prima o poi ci arriverà.

 

C'è anche da tener presente che se un manutentore è addetto a quel determinato impianto, significa anche che avrà anche una buona conoscenza dell'impianto stesso e che, spesse volte i "nativi informatici" hanno conoscenze dell'hardware largamente inferiori a quelle di un manutentore di lunga esperienza e quindi....

 

Una cosa è cercare di tutelarsi contro la copia illegale del proprio software, un' altra è celare il funzionamento del programma.

 

 

U:= ((A AND NOT B)OR D) AND (C OR E);

 

U=((A&!B)|D)&(C|E);

 

 

In ogni caso, è possibile scrivere un pessimo programma in ladder che sia di difficile interpretazione anche per l'autore stesso....

 

 

ma è molto più facile raggiungere lo stesso obiettivo, cioè scrivere un pessimo programma difficilmente interpretabile, in ST, C , AWL codeSys ecc ecc.

 

Quando faccio qualcosa, penso a  scriverla nel modo più facilmente leggibile e non per il manutentore, ma per me stesso,  in modo tale che se, dopo molto tempo, mi dovessi ritrovare a dover svolgere un'assistenza, oltre alla fatica di comprendere la causa del problema non ci sia anche quella di dover capire il programma.

 

 

 

[ETR]

Ciao dott. cicala, quanto intendevo era riferito al fatto di utilizzare parti di codice strutturato in maniera standardizzata e tramite librerie.

 

Posso citare esempi di comando di centinaia di attuatori con feedback, scritti con "poche" righe di codice, perché gestiti tutti in strutturato, array e cicli for next. Ovvia una leggibilità a codice estremamente scarsa, ma con le debite accortezze di segnalazione grafica, qualsiasi anomalia viene segnalata. Ma la cosa l'ho vista fare, anche per assi CNC (sino a 16) con elaborate funzioni in C, che erano tutt'altro comprensibili, ma avevano tutti gli strumenti per l'analisi dei segnali di ingresso ed uscita, perché il core era stabile e quindi non interessava a me (in quel caso ero quasi io il manutentore) stabilire se fosse o meno funzionante.

 

Questa mia "semplificazione" non potrà essere applicata a qualsiasi sequenza, ma standardizzando il più possibile, si possono ottenere delle funzioni, stabili e complete.

 

Per quanto riguarda il manutentore, stabilita la logica, il suo interesse è sugli I/O. Lui deve essere il braccio armato del programmatore e non il risolutore con il cavallotto facile, anche perché se non dimostrato diversamente, il danno é sempre a carico di chi ha programmato (altrimenti liberiamo anche la parte safety e via !).

 

Comunque ho cominciato a programmare PLC a scuola, con il ladder su una tastiera Telemecanique di un TSX17 (per poi ricevere un esame di maturità richiedente Siemens e AWL ) e non lo rinnego, ma le lezioni di PASCAL ricevute, al momento, le ritengo molto più "educative" .

 

Ritengo che all'interno di un codice, se non strettamente necessario (vedi l'uso di un logo o di pochissime logiche binarie) non debba essere ritenuto come principale ed unico sistema di programmazione.

 

Grazie Livio per le lezioni di storia !

 

Ciao Ennio

 

 

[batta]

Personalmente considero la scelta di utilizzare un unico linguaggio simile all'autocastrazione.

Io non amo il ladder, pur essendo il linguaggio che ho imparato per primo.
Però non si può negare che, per quanto riguarda la logica booleana, è più semplice, più immediato e più efficiente sia dell'AWL che del testo strutturato.

Ma il bello dei PLC di oggi è che, quasi tutti, permettono di utilizzare più linguaggi.

Ecco che utilizzare il ladder per la logica booleana, inserendo pezzi in awl e richiamando routines in scl mi sembra la scelta che permette il miglior sfruttamento delle risorse a nostra disposizione. Io non riesco a capire il senso dell'eliminare a priori uno o più linguaggi.

Riguardo poi i "nativi informatici", per quanto riguarda la mia personale esperienza, non sono i migliori programmatori di PLC. Potranno diventarlo col tempo ma, per programmare bene un plc, la dimestichezza nell'uso del codice è solo uno dei molti aspetti.

[Nicola Carlotto]

Bravo Batta  concordo.

Nicola

[Livio Orsini]

Quote

Riguardo poi i "nativi informatici", per quanto riguarda la mia personale esperienza, non sono i migliori programmatori di PLC.

 

Non sono i migliori programmatori per tutto quanto concerne il mondo dell'automazione e del controllo.

Quelli bravi conoscono bene le filosofie dei linguaggi, le architetture degli S.O., ed altre finezze, ma son ben lontani da dal conoscere le problematiche che stanno alla base di un buon programma di controllo.

Quelli bravi hanno però un vantaggio rispetto ai non informatici di origine: dominano molto bene gli strumenti disponibili, quindi una volta che hanno acquisito anche le conoscienze necesario riescono a progettare delle ottime soluzioni.

 

Sono anch'io del parere che limitarsi ad un solo linguaggio è autocastrante. Si deve scegliere sempre, tra quelli disponibili, lo strumento più adatto allo scopo.

[batta]

Quote

Quelli bravi hanno però un vantaggio rispetto ai non informatici di origine

Su questo non c'è dubbio. Hanno un qualcosa in più che può permettere loro, col tempo, di diventare ottimi programmatori di PLC, e con l'ulteriore vantaggio di essere potenzialmente programmatori a 360 gradi.
Devono però abbandonare l'idea che la programmazione di PLC sia programmazione di serie B, e devono capire che ogni punto del processo deve essere controllato in continuo, e non solo su evento.

[Livio Orsini]

Quote

Devono però abbandonare l'idea che la programmazione di PLC sia programmazione di serie B ...

 

Questa è un'idea purtroppo molto diffusa che nasce assieme al PLC.

Quando entrai in E. Marelli (1978), questa era associata con Westinghose di cui usava anche computer industriali.

In Westinghose avevano sviluppato un applicativo che permetteva di programmare il computer in ladder diagram.

Ricordo che alla presentazione del "pacchetto" ai tecnici dei principali clienti (Italsider, Feralpi, Lucchini, etc.) l'esperto di software che aveva portato il pacchetto dagli USA definì la programamzione in ladder diagramcome : "...una "non programamzione" alla portata di qualsiasi elettricista che sapesse realizzare un po' di logiche combinatorie con i relè; in fin dei conti si tratta di realizzare uno schema elettrico con attrezzi differenti dalla carta e matita."

Questa convinzione che la programamzione di PLC sia una non programamzione è talmente radicata che ancora oggi è diffusissima. E' anche la maggior responsabili di certi programmi messi su a "mazzate", senza capo ne coda; però se osservi che il programma è fatto male, che è un castello di carte che alla prima modifica crolla, ti rispondono: "La macchina funziona e questo è tutto quello che deve fare il programma".

 

Per mia fortuna non mi occupo più di PLC.

[ETR]

Ciao a tutti, per la cronaca (e solo per quella) aggiorno la discussione con due considerazioni frutto di eventi, temporalmente distanti tra loro ma sempre collegati.

 

Ho postato, alcune settimane fa, una discussione sulla responsabilità penale del programmatore, frutto di un corso ecc... e giusto in questi giorni ho poi avuto un altro incontro con il "mio ex cliente" che invece ha innescato questa discussione.

 

Portando all'attenzione del cliente, l'argomento della responsabilità, non c'è stato verso di scardinare l'idea che comunque caschi il mondo, serva qualcuno che possa entrare a proprio piacimento nel PLC (intendendo non proprio il primo che passa, ma il primo programmatore che passa). Questo perché se il cliente chiama, si deve essere pronti a vigili, ovviamente senza extra costi.

 

E' inutile continuare, se non è possibile stabilire il medesimo punto di riferimento della discussione. Collaborazione e interscambio di informazioni, contro economicità e assoluta libertà di scelta. 

 

Ovviamente sono argomenti che sono alla base di qualsiasi lavoro, ma in questo caso, le sue argomentazioni, eliminano automaticamente le mie. 

 

Scusate se vi ho annoiato, ma penso di poter porre la parola fine a questa faccenda, per lo meno come l'ho fino ad ora gestita.

 

Ciao a tutti, Ennio