Programmare Bene, Programmare Male - Messaggi spsostt da:"Flusso In Ladder ... Ma Dai!"

[walterword]

talvolta implica una percentuale di probabilità abbastanza bassa , o comunque inferiore al 50%

, diversamente diventa un "purtroppo" .

Il fatto e' che comunque chi costruisce macchine spesso non sa nulla di automazione , ma nonostante cio' si permette di scegliere questo pannello piuttosto che quello , questo plc piuttosto che l'altro

e quantifica tempi di sviluppo e messa in servizio bassi , spesso insufficienti .

In questo caso non si dovrebbe fare altro che dire:" ok fattelo tu visto che sei cosi bravo e che sai tutto "

e questa soluzione talvolta e' piu interessante che magari iniziare un'avventura e poi rimetterci i soldi o

stare in ballo 2 anni per prendere 4 miseri euro ed averci gia pagato le tasse magari

Modificato: 6 ottobre 2006 da walterword

[mynameisrex]

Rispetto alle "bobine" iniziali vedo che la discussione ha preso un bell'indirizzo... noto (purtroppo con dispiacere) che "l'automazione secondo me" è un qualcosa che (ripeto - purtroppo) sta prendendo molto piede...

[TravelMen]

Caro walterword la mia era solo una provocazione, concordo con te in tutti i punti da te esposti, guarda caso sono 5 anni (sicuramente pochi) che vado in giro x il mondo a mettere apposto/messa in servizio, di programmi scritti da altri, x cui mi trovo sempre a dover decifrare cosa volesse fare il programmatore di turno, x capire dove e come agire. (Che vita di m )

Come si può intuire ne ho viste di cotte e di crude, una di queste l'ho riportata

In questi anni ho imparato una cosa fondamentale, anzi due, la prima che non si finisce mai di imparare, ottimo xchè vuole dire crescere proffessionalmete, la seconda,

alcuni programmatori mi vien voglia di prenderli a calci in cu*o

aggiungerei, specialmente quelli che sviluppano un prog. PLC da dietro una scrivania, sensa essere mai aver fatto una messa in servizio, e predendono, anzi sono convinti, che se qualcosa non va sia colpa nostra che abbiamo modificato il codice.

Se qualcuno vuole vedere altro bel codice me lo dica che glelo posto subito

Modificato: 6 ottobre 2006 da TravelMen

[walter.r]

Stabilito che ....è sempre meglio non fare definizioni multiple di segnali, siano bobine d'uscita o merker d'appoggio.......

Mi pare di capire che esistano, secondo la discussione in corso, tre tipi di programmatori :

1) Programmatore da scrivania, cioè colui che, manuali alla mano, "fa" il programma della macchina senza averla vista, sulla base di un progetto.

2) Programmatore da officina, cioè colui che, non avendo mai visto il progetto ( magari perchè non c'è.... ), "fa" il programma della macchina e in genere non ha bisogno dei manuali, dato che improvvisa.

3) Programmatore da installazione, cioè colui che va dal cliente finale a mettere a posto i danni fatti dai primi due, e in genere deve capire cosa avevano in mente.......

Vogliamo fare un sondaggio su questo, per vedere in quale categoria ci mettiamo ???

[AndreaC]

Io sono 1) + 3).

Credo come tanti partecipanti al forum. Purtroppo una minoranza... la voce grossa nel campo ho l'impressione che sia dalla categoria 2)

[TravelMen]

Aggiungerei:

4) Programmatore che va a fare la manuntenzione.

Vorrei fare una piccola precisazione, non è mia intenzione puntare il dito contro nessuno, anzi rispetto il lavoro fatto da tutti, ma ci sono delle volte che ti scontri con tipi troppo convinti di se stessi, la loro è la cosa giusta.

Sono concorde con walterword quando dice

Io non mi ritengo ancora bravo , pero ce la metto tutta

Secondo me è quello che dobbiamo fare noi programmatori, indipendentemente dal numero scritto da walter.r e da me.

Per rispondere al sondaggio io faccio parte di tutti e 4 i punti

Modificato: 6 ottobre 2006 da TravelMen

[Luca Bab]

Aggiungo

5) colui che fa' il progetto elettrico ( schema , tabelle e materiale ) , il programma dalla scrivania , testa la macchina in officina e la installa e collauda dal cliente.

PS e' molto facile criticare un SW fatto da altri , ed e' molto facile anche corregerlo

il discorso cambia quando hai un foglio bianco da riempire ( e per giunta in poco tempo )

Saluti

Luca

[batta]

PS e' molto facile criticare un SW fatto da altri , ed e' molto facile anche corregerlo

D'accordo in parte sulla prima considerazione. E' vero che criticare è facile, ma è altrettanto vero che ci sono software fatti.. non dico con che parte del corpo, ma sicuramente non usando il cervello. Quello che mi fa più rabbia è la scarsa documentazione. Non faccio colpe (nel senso che un'eventuale scarsa capacità di strutturare un programma è un limite, non una colpa) al programmatore che sviluppa un software contorto. Non documentare invece è una colpa e basta. Anche un software contorto può essere capito se ben documentato. Se a lunghi giri per arrivare ad una soluzione aggiungiamo la completa mancanza di documentazione, quel software diventa una schifezza.

Non sono per niente d'accordo invece sulla facilità di correzione. Un programma iniziato male al quale continui ad aggiungere correzioni (io direi rattoppi) rimarrà sempre un programma fatto male.

il discorso cambia quando hai un foglio bianco da riempire ( e per giunta in poco tempo )

Questa è la soluzione che per certi versi preferisco. Se sei di fronte ad un foglio bianco e non hai idee è dura, ma se sai già dove vuoi arrivare e che strada seguire allora significa non dover sottostare alle scelte, non sempre corrette, fatte da altri.

[walter.r]

Bene, ringrazio LucaBab per l'indicazione N° 5, che forse è quella in cui mi riconosco anch'io.

Però mi è capitato spesso di entrare nei panni del N° 3, e in questo non posso che approvare Batta quando dice che spesso è molto meglio un foglio bianco.

Mi è successo di dover gestire impianti fatti da altri apportando modifiche e aggiunte, e ogni volta che con il cliente abbiamo concordato di non "rifare" ma di "aggiustare", me ne sono pentito. Sempre.

E, attenzione, non mi sento di dire che io programmo "meglio" di un altro: il fatto è che la programmazione è un po' un'arte. Picasso e Monet erano bravi entrambi, anche se con risultati estremamente diversi per stile.

Ognuno di noi ha un suo "stile", ed è normale che un'altro non ci si ritrovi troppo.......

Però quando trovo un PLC multitasking programmato in rigoroso stile "sequenziale", un po' mi inc***o !!

[Water]

mi associo alla categoria 5,

dove il PLC è uno dei tanti componente di un sistema da noi fornito

purtroppo o per fortuna, il tutto DEVE essere gestito dall'interno,

questo per evitare lungaggini bibliche o il solito scarica barile,

quindi l'impianto (o la macchina) viene fornito chiavi in mano

ovviamente fino a che non si raggiungano complessità elevate ...

categoria 5

ciao a tutti e grazie per i preziosi spunti che emergono tra le righe

Giuseppe

[Livio Orsini]

Un programma iniziato male al quale continui ad aggiungere correzioni (io direi rattoppi) rimarrà sempre un programma fatto male.

Sottoscrivo interamente, anzi aggiungo che un programma iniziato male può solo peggiorare.

Purtroppo sembra che lo stile di programmazione dominante, almeno nel campo PLC, sia far funzionare i programmi a martellate (metaforiche), al pari di come si usa chiudere le canline dei quadri: sempre a martellate (reali).

Ogni programma dovrebbe iniziare da zero, cioè dal foglio bianco. Una volta stabilita la strategia di soluzione dei problemi della macchina/impianto si può anche usare "il copia e incolla", ma sempre e solo dopo che si è progettato il sistema.

Picasso e Monet erano bravi entrambi,.....

Paragone un poco esagerato, non credi?

Scrivere programmi è un lavoro da bravi artigiani, come un buon ebanista per esempio.

Modificato: 7 ottobre 2006 da Livio Orsini

[lucios]

Ogni programma dovrebbe iniziare da zero, cioè dal foglio bianco. Una volta stabilita la strategia di soluzione dei problemi della macchina/impianto si può anche usare "il copia e incolla", ma sempre e solo dopo che si è progettato il sistema.

Giustissimo!!!

Però il problema, almeno nel mio caso, è che spesso i clienti non hanno la cultura di fornire specifiche (non dico dettagliate, ma almeno decenti) del prodotto da realizzare.

Ciò crea in primis un problema a livello di offerta (non si sa cosa vuole!), poi si parte e cominciano i guai:

modifiche in corso d'opera, funzionalità non previste (con battaglie per gli adeguamenti dell'offerta ), ecc.

In questo modo diventa difficile fare un software che, alla fine, sia lineare e ben strutturato. A volte ci riesco e a volte no. Quello che voglio dire è che non è sempre (o tutta) colpa del povero progettista .

Ciao

[Livio Orsini]

Ciò crea in primis un problema a livello di offerta (non si sa cosa vuole!), poi si parte e cominciano i guai:.....

Niente di nuovo sotto il sole. Ero giovane, alcuni decenni addietro , e già litigavo con i commerciali per questi problemi.

La progettazione di un sistema di automazione inizia dalla fase di offerta economica a meno che si tratti di un componente standard messo a magazzino.

Solo che, in genere, i commerciali non vogliono i progettisti tra i piedi. Loro dicono "perchè la trattativa con il cliente è un momento squisitamente commerciale". In realtà perchè, altrimenti, c'è il rischio concreto che vengano scoperti gli inghippi e le fandonie da subito .

Però qui siamo abbondantemente OT dall'argomento iniziale.

Se l'argomento (come si deve progettare e scrivere il programma) interessa possiamo separare i post in una nuova discussione.

Modificato: 7 ottobre 2006 da Livio Orsini

[batta]

Paragone un poco esagerato, non credi? smile.gif

Scrivere programmi è un lavoro da bravi artigiani, come un buon ebanista per esempio.

Il paragone è sicuramente esagerato, nel senso che di Picasso e Monet ce ne sono (ce n'erano) pochi, mentre programmatori di plc ce ne sono a milioni. Mi trovo però d'accordo col concetto di base: programmare è un'arte. O almeno, programmare bene è un'arte. Chiaro che una mostra di programmi di plc non avrebbe senso. Considerare la programmazione un'arte nel senso stretto della parola è certamente una forzatura, ma io non riesco a vedere, com è invece idea di molti, la programmazione come una fredda scrittura di righe di codice. Per programmare, oltre alla tecnica, ci vuole molta inventiva e fantasia. L'unico problema è che per capire lo stile del programmatore si deve saper interpretare il linguaggio. Un quadro invece lo possono guardare tutti, bastano gli occhi. Poi, se vogliamo dirla tutta, io sinceramente (sarà per la mia totale ignoranza nel settore) in certi quadri di Picasso non ci vedo molta arte.

Sono andato un pò OT? Scusate

Concordo con l'idea di separare la discussione.

[walter.r]

Sul paragone Picasso - Monet , chiaro che era esagerato, non volevo certo paragonare......una tela ad un PLC.

Era il concetto di " diverso gusto " che mi interessava esprimere.

E su certi quadri di Picasso.......la penso come Batta !

Per programmare, oltre alla tecnica, ci vuole molta inventiva e fantasia.

Certo, il succo del discorso sta proprio qui.

Nell'immaginare la macchina, idearne i comportamenti, ipotizzare come potrà agire chi la userà......mica tanto facile farlo bene, soprattutto se, come dice bene Lucios, in fase di progetto le idee non sono molto chiare.

Va benissimo anche per me l'idea di separare le discussioni

[Luca Bab]

programmatori di plc ce ne sono a milioni

che capiscono l'automazione , molto meno

ciao

Luca

[Livio Orsini]

Riunisco qui i messaggi che riguardano l'argomento della programmazione più o meno ben fatta ed i relativi stili.

[Livio Orsini]

....programmare è un'arte.

Bisogna definire l'accezzione di arte. Un fatto artistico, secondo l'accezzione comune, è qualche cosa che trascende il razionale, è qualche cosa che procura emozioni allo spettatore od al aprtecipante all'evento.

Se l'accezzione è quella comune odierna, programmare non deve e non può essere un fatto artistico.

Non esistono stili di programmazione ad libitum del programmatore. Esiste solo un programma ben progettato e ben scritto o un programma mal fatto.

Si possono usare linguaggi diversi e piattaforme diverse. Programmatori differenti si differenziano solo per sfumature insignificanti. Un programma ben fatto, oltre a funzionare bene, deve essere facilmente leggibile e facilmente manutenibile. Se risponde a questi due presupposti non ha spazio per le invenzioni "artistiche" del programmatore.

E' vero che un programma non è solo un'algida sequenza di righe di istruzione. Un programma è, prima di tutto, una soluzione di un problema.

L'abilità dell'analista (distinguo analista, non programmatore) sta nell'individuare la soluzione ottima al problema. Forse, in questa fase, c'è spazio per un quantum di artistico. Poi, individuata la soluzione, ne consegue una serie di algoritmi e/o sequenze dove non c'è spazio per la fantasia. Si deve applicare esclusivamente una logica rigorosa.

Diffido sempre dei programmatori "artisti". O sono personaggi che, per costituzione, rifiutano disciplina e rigore, oppure saltano bellamente la fase di analisi, o rifiutano che ci sia qualcun altro che la esegua.

Nel primo caso sono persone che dovrebbero fare un altro lavoro. Nelle loro soluzioni ci saranno sempre problemi; problemi che sono molto spesso ben occultati da cortine fumogene così da renderli ancor più pericolosi e di difficile individuazione.

Nel secondo caso i lavori saranno confusi, raffazzonati, inaffidabili e impossibili da manutenere.

Quando si discute di programmazione bisogna sempre tenere presente se si sta esaminando un giochino amatoriale od un serio lavoro professionale.

Se scartiamo i lavori amatoriali, e rivolgiamo l'attenzione al solo settore professionale, il rigore e la disciplina sono il primo fattore della buona riouscita di qaulsiasi progetto.

Purtroppo è un limite nazionale il rifiuto di queste caratteristiche. Ognuno di noi si sente un artista, avere dei confini precostituiti sembra un attentato ai diritti inalienabili dell'uomo. Invece è la base del vivere e lavorare in modo civile.

Ci sono lavori che possono essere inventati al momento. Se di professione fai lo stilista puoi fare secondo ispirazione. Se fai l'ingegnere lo puoi fare un po meno.

Quando, circa quarant'anni addietro, iniziai a lavorare in un laboratorio di ricerca e sviluppo di grandissima azienda elettronica, di cui oggi esiste solo il marchio commerciale, ero convinto di poter dar sfogo alla mia fantasia. Poi, giorno dopo giorno, capii che la progettazione è sopra a tutto rigore e disciplina.

Se così non fosse sarebbe impossibile costruire programmi enormi come, ad esempio, un Sistema Operativo tipo Windows o una suite di sviluppo come Visual.Net. Su questi progetti lavorano contemporaneamente decine di analisti e più di un centinaio di programmatori. Se alcuni di loro volessero lavorare da "artisti", od avere un proprio "stile" di programamzione, questi prodotti non funzionerebbero mai.

Una seria azienda di programmazione dispone perfino di un dizionario che regola l'assegazione dei nomi delle variabili. Pedanteria teutonica? No! Semplicemente si vuole facilitare la comprensibilità del codice. Qualsiasi programmatore, anche se arrivato in azienda da pochi giorni, che legga delc odice scritto da altri anni addietro, comprende automaticamente dai nomi tipo e funzione della variabile.

Modificato: 7 ottobre 2006 da Livio Orsini

[walter.r]

Caro Livio,

Esiste solo un programma ben progettato e ben scritto o un programma mal fatto.

...comprendo ma non concordo.

Quello che dici circa la comprensibilità, la leggibilità di un codice è condivisibile, ma io mi riferivo al "tipo" di programmazione che viene adottata per risolvere uno specifico tema.

Facciamo un esempio: una macchina sequenziale, con una sequenza nota di 12 passi.

Mi vengono in mente al momento, senza studiarci troppo, almeno 4 o 5 possibilità per gestire lo "scorrimento" dei passi. Tutte funzionanti.

Il decidere quale utilizzare, in casi come questi, è cura del programmatore; non sarà "arte" nel senso letterale del termine, ma creatività sì.

Se io uso una soluzione "non convenzionale" per risolvere uno specifico problema, la spiego e la commento, essa è comunque leggibile e comprensibile.

E allora non è comunque buona programmazione ??

Dobbiamo per forza sentirci "pecoroni" ?? Della serie: se il problema è questo, la soluzione può essere soltanto questa....... Mica vero !!!!

E poi, con il passare del tempo la tecnica mette a disposizione strumenti e caratteristiche sempre diversi e aggiornati: continuiamo a programmare come abbiamo imparato 20 anni fa, sugli strumenti di 20 anni fa ???

[batta]

Dal vocabolario della lingua italiana Zingarelli:

arte

1) attività umana regolata da accorgimenti tecnici e fondata sullo studio e sull'esperienza

2) l'attività, individuale o collettiva, da cui nascono prodotti culturali che sono oggetto di giudizi di valore, reazioni di gusto...

3) complesso delle opere artistiche, spec. di arte figurativa, di un dato paese o epoca

4) abilità, accorgimento

5) dall'antichità alla Rivoluzione francese, organizzazione di artigiani, mercanti e lavoratori in genere, per tutelare i propri interessi

Mi pare che la programmazione possa rientrare in più di una di queste voci. Poi, ripeto, non voglio certo paragonare un programma alla Giconda, ma ritengo comunque che programmare richieda creatività. Certo, quando si deve lavorare in squadra si devono imporre delle regole per poter assemblare insieme i vari pezzi di programma e per far in modo che anche chi non conosce quel programma sia in grado di capirlo il più rapidamente possibile. Imporre queste regole è un obbligo che toglie comunque libertà e lascia meno spazio alla creatività.

Anche con regole imposte si nota comuque uno stile di programmazione. E' impossibile che due programmatori risolvano lo stesso problema nello stesso identico modo. Rimane sempre spazio per scelte personali, anche imponendo regole ferree. Se per sviluppare un programma bastasse seguire una logica rigorosa saremmo già invasi da plc autoprogrammanti. Il lavoro umano mi pare sia invece ancora indispensabile.

Quante volte capita che non si riesce a risolvere un problema. Ci si pensa di giorno, di notte, quando si mangia, quando si fa all'a... (bè, allora no, dai ). Poi, all'improvviso, ci si illumina.

Certo, si può considerare questo fatto come semplice raggiungimento della soluzione del problema. Ma allora, giusto per provocare, anche la Gioconda potrebbe essere considerata un semplice ritratto. Alla fine cos'è: una tela sulla quale qualcuno ha lasciato dei semplici tratti con dei pennelli. Sai, allora non avevano le macchine fotografiche...

[Livio Orsini]

Walter.r

Dobbiamo per forza sentirci "pecoroni" ?? Della serie: se il problema è questo, la soluzione può essere soltanto questa....... Mica vero !!!!

No! Se il problema ammette più di una soluzione ci sarà senz'altro una soluzione migliore delle altre. Migliore non significa che sia la più elegante o la meno convenzionale. La soluzione migliore è quella che, dopo avere analizzato pragmaticamente tutte le esigenze, adotta il miglior compromesso tra di esse. La soluzione perfetta non esiste.

Sceglere la soluzione più adatta non significa dover per forza essere anticonformisti, l'anticonformismo fine a se stesso è solo inutile narcisismo.

Poi devi sempre pensare che non sei solo. Da quello che scrivi arguisco che tutto non abbia mai lavorato in un gruppo. Un progettista non vive nella propria monade ma deve interagire con tutto l'universo che lo circonda. Se lavori in un gruppo ci deve essere una filosofia comune che guida il progetto. E qui si totna al concetto di rigore e disciplina.

Dovrebbe essere obbligatorio per tutti i programamtori un periodo di lavoro in cui si è costretti a lavorare solo con il compilatore Pascal originale di Niklaus Wirth. Sarà noioso, anzi palloso, ma ti insegna cosa si deve fare per programmare in modo corretto.

Rigore e discilplina non significa essere pecore in gregge, significa essere uomini nel senso più alto dell'accezzione.

Modificato: 8 ottobre 2006 da Livio Orsini

[Livio Orsini]

A Batta.

Leggendo l'incipit del mio mesaggio #18 si può notare che ipotizzo una definizione di arte e dichiaro che essa non si attaglia al programmare. Nel mesaggio precedente definisco il programmare un lavoro di buon artigianato, definizione a cui si adatta la definizione di arte nel senso ad essa dato dalle corporazioni, come riportato all definizione n.o 5 tratta dallo Zingarelli. Credo che fino a qui le nostre due idee siano simili.

Differiscono sulla creatività. la divergenza nasce dal fatto che io separo l'analisi dalla programmazione. Se le sequenze di progettazione sono state eseguite correttamente, prima di codificare si deve analizzare il problema. Dopo l'analisi di dettaglio la codifica è praticamente automatica.

Tu dici che se così fosse ci sarebbero PLC che si autoprogrammano. Se ci ragioni un poco più approfonditamente ti accorgerai che è praticamente quasi così. Non lo è se programmi in AWL o in ladder. Però se usi strumenti come "Graphcet" praticamente la programmazione è automatica. Analizzi il problema in dettaglio usando il linguaggio ad alto livello, il compilatore farà poi il resto.

Se stai al livello di elaboratori ci sono linguaggi, specialmente per le intelligenze artificiali, in cui il livello è spostato ancora più in alto. Il "lisp" era stato definito come l'assembler per "AI", ed oggi ci sono linguaggi a più alto livello del lisp.

Più si procede con la potenza degli elaboratori più si alza la soglia della creatività e non solo nel campo della programamzione.

Quando ero giovane progettare un buon amplificatore i continua richiedeava notevoli conoscenze e capacità progettuali. Oggi chiunque, senza quasi nessuna conoscenza di elettronica, piazza il primo operazionale che conosce ottenedo risultati irraggiungibili da qualsiasi progettista di 40 anni fa. E' il progresso tecnologico.

Ci si pensa di giorno, di notte, quando si mangia, quando si fa all'a... (bè, allora no, dai ). Poi, all'improvviso, ci si illumina.

Questo non dovrebbe appartenere alla programmazione, bensì all'analisi. Mi rendo conto che, come sempre, alla base di tutto c'è un problema di semantica. probabilmente non sei abituato a dividere le due fasi, o lo fai in modo automatico.

Anch'io, per problemi abbastanza noti, fondo le due fasi; in pradica codifico quasi in contemporanea al lavoro di analisi. Però so eseguo due fasi in qausi contemporaneità. Diciamo che il cervello umano è dotato di un RTOS talmente potente che può tranquillamente gestire questi due task in contemporanea.

...anche la Gioconda potrebbe essere considerata un semplice ritratto.

In effetti lo è. Ma qui mi rifaccio alla mia prima definizione di arte. Cosa distingue la gioconda da un qualsiasi ritratto di maniera? La perfezione dei tratti? La rispondenza all'riginale? No. L'elemento distintivo è l'emozione che suscita in chi la osserva. E' questo che distingue la natura morta del Caravaggio da una qualsiasi crosta che puoi acquistare al mercato rionale.

In effetti anche un ritratto fotografico eseguito da un artista suscita emozioni che invece non sono suscitate dalla normale foto del figlioletto di un qaulsiasi padre o madre dotati di fotocamera.

PS

...quando si fa all'a... (bè, allora no, dai ).

Ti dirò, spesso non durante ma dopo, mi sono venute ottime idee e soluzioni.

Probilmente è per questa ragione che invecchiando si è meno creativi..

Modificato: 8 ottobre 2006 da Livio Orsini

[Paolo Cattani]

Rigore e discilplina non significa essere pecore in gregge, significa essere uomini nel senso più alto dell'accezzione.

... sembra di leggere una pagina dal Bushido...

Modificato: 8 ottobre 2006 da Paolo Cattani

[Livio Orsini]

... sembra di leggere una pagina dal Bushido...

Tutte le grandi filosofie e religioni si fondano sul rigore e la disciplina. Rigore e disciplina sono tratti caretteristici dell'uomo.

Gli animali si riuniscono in gregge, gli uomini si riuniscono in comunità

[walterword]

siamo partiti dal mal programmare due volte la stessa bobina

con diversi concetti stretti e ben definiti e

siamo arrivati ad un discorso filosofico

INCREDIBILE !!!