Come Ragionare Quando Si Programma? - Come si passa dalla descrizione linguistica alla programmazione ladder

[avafab]

Ciao a tutti, volevo fare una domanda ai più esperti:

come ragionate quando vi approcciate a passare dalla descrizione linguistica di un compito di automazione alla effettiva programmazione?

usate diagrammi di flusso, macchine a stati, reti di petri?

quale sequenza di operazioni e ragionamenti fate per passare dalla descrizione di funzionamento alla schematizzazione delle singole operazioni e successivamente alla realizzazione in ladder?

apro questo topic solo per confrontarci e condividere il modo in cui si ragiona. scrivete la vostra esperienza, penso che gioverà a tutti.

grazie.

[Livio Orsini]

Io da sempre uso il metodo dell'analisi "top down" con descrizione e specifiche dettagliate.

Si parte con la scrittura delle specifiche generali; si anilizzano inseguito le varie parti descivendo sempre piùi dettagli sino a che si giunge alla descrizione della singola funzione elementare. A questo punto la codifica è praticamente automatica ed indipendente dal linguaggio che si userà.

Cerco di chiarire meglio. A livello di funzione elementare, se descritta nel dettaglio, la descrizione è valida sia se si scrive in assembler per una scheda dedicata, sia che si usi AWL per un plc Siemens.

[avafab]

Grazie Livio, con il classico "divide et impera", non si sbaglia mai. Anche io sono abituato così, ma vorrei sapere più nel dettaglio sulla programmazione plc, c'è qualcuno che utilizza diagrammi di flusso, automi o reti di petri? forza condividiamo, magari arriviamo ad uno standard (se non esiste già) di "buona programmazione" del plc con linguaggio a contatti.

[Roberto Gioachin]

Gran bella domanda!!

Rispondere però non è così facile.

Le applicazioni sono sempre molto diverse una dall'altra, in base al tipo di lavoro che si deve eseguuire.

Ci possono essere applicazioni che richiedono molti calcoli matematici, altre che invece richiedono si realizzino sequenze con pochi calcoli e così via.

Il metodo descritto da Livio dovrebbe sempre essere utilizzato come base, ma la tua domanda vorrebbe entrare un pò più sul dettaglio.

Per rispondere alla tua domanda, io utilizzo sicuramete "automi".

Al posto delle reti di petri utilizzo "SFC", nato proprio per i plc.

I diagrammi di flusso, molto utili per chi programma in linguaggi ad alto livello sono, credo, non indispensabili per chi programma PLC, anche se non nego che ogni tanto utilizzo questo strumento.

Questi strumenti comunque non sono sufficenti per fare un lavoro ben fatto.

Io per esempio abino ad ogni progetto un file di Word, sul quale riporto tabelle, immagini, appunti e informazioni varie.

Un metodo che dovrebbe essere nella mentalità di ogni programmatore, è sicuramente quello di: prendere un problema complesso e dividerlo in molti pezzi elementari (senza esagerare a dividere), realizzare il programma per il problema elementare e provarlo in tutte le situazioni, anche quelle più strane ed improbabili.

Solamente una volta testato, questo può essere utilizzato senza creare problemi al progetto finale.

Ciao

Roberto

[avafab]

ciao roberto, grazie, quindi tu i plc li programmi sempre con l'SFC? per me che sono uno studente di ingegneria dell'automazione industriale l'sfc e gli automi sono decisamente più comprensibili ma ho fatto questa domanda perché da subito mi è stato detto di usare tassativamente il ladder (in particolare KOP).

sto cercando di farmi un idea sulle varie tecniche pratiche che si usano per passare dalla decrizione del problema alla programmazione in ladder, perché senza fare un passaggio intermedio (fatto di automi, schemi, diagrammi o reti di petri) ho come l'impressione di trovarmi davanti ad un rompicapo.

se uno programma direttamente in ladder, e non è particolarmente esperto, pensa che tutto va bene e invece poi sta le ore a fare debug con conseguenti perdite di tempo che, credo, si possono evitare utilizzando un passaggio, intermedio.

comunque continuiamo a confrontarci, grazie a chi vorrà scrivere la sua e partecipare.

[batta]

Io non vedo SFC (o grafcet), reti di petri ed altro come veri e propri linguaggi, ma come metodi di programmazione.

Con qualsiasi linguaggio si possono stabilire le condizioni per passare da una tappa ad una o più tappe successive.

Nulla vieta, quindi, di prendere i concetti del grafcet e scrivere il programma in KOP

Anzi, devo dire che questo è il metodo che uso più frequentemente, ma utilizzando AWL.

La cosa che mi pare un po' strana è l'obbligo tassativo, per uno studente di ingegneria dell'automazione, di usare il ladder.

Voglio dire, non può esistere un ingegnere dell'automazione che non conosce il ladder. Sarebbe come un medico che non conosce l'acido acetilsalicilico.

Il ladder è un linguaggio largamente utilizzato in automazione e, anche se non lo amo in modo particolare, ha indubbiamente i suoi pregi.

Allo stesso modo, ritengo non possa esistere un ingegnere dell'automazione che conosce solo il ladder. Sarebbe come un medico che conosce solo l'aspirina.

Ma forse dipende solo dall'attuale fase di studio. Una volta imparato bene ad utilizzare il ladder, si passerà ad altri linguaggi. Almeno spero sia così.

[avafab]

grazie batta, il mio non è stato un "obbligo tassativo", sono arrivato in azienda con persone competenti che mi hanno detto, qui si usa il kop.

e quindi sto cercando una strada per partire dalle mie basi (automi e reti di petri) ed approdare, in maniera naturale e comoda, allo schema a contatti.

ho trovato anche diversi articoli specializzati che fanno degli esempi su come passare dalla schematizzazione con reti di petri al linguaggio ladder utilizzando un "mapping" uno a uno. cioè che singole operazioni sulla rete si traducono, naturalmente in prestabiliti schemi a contatti.

vabbè non voglio annoiarvi, voglio solo trovare un modo che sia più sistematico possibile per approcciarmi alla programmazione evitando inutili ritardo e ore e ore di debug, ogni consiglio proveniente da persone esperte è ben gradito.

[Livio Orsini]

...qui si usa il kop.

KOP, in tedesco, "ladder diagram" in anglo americano, "programmazione a contatti" in italiano son tutti modi per indicare un linguaggio di programmazione che serve a risolvere problemi di logica binaria. Infatti il contatto può essere solo o aperto o chiuso, quindi si possono applicare tutte le regole previste dall'algebra di Bool.

Il nocciolo della faccenda non è il linguaggio usato che, in definitiva, è solo uno strumento, bensì è individuare quello che la macchina deve fare e realizzaro nel modo migliore.

Io ho iniziato a programmare più di 40 anni fa. Usavo Fortran perchè era l'unico linguaggio adatto e disponibile per calcoli scientifici (non è che, a quel tempo, ceran tanti linguaggi per prograggamare gli elaboratori ). Ovviamente seguivo i dettami dei libri di testo: diagramma di flusso e codifica. Il programma poi era un bel groviglio, dopo qualche mese era difficile da capire anche dall'estensore. Non per niente gli americani avevano rinominato il Fortran e linguaggi consimili "spagetti like programming"; questo perchè le linee sui listing, tracciate per seguire i vari "go to", alla fine assomigliavano ad un bel groviglio di spagetti.

Poi, con l'avvento dei micro procesori (primi anni 70) ho iniziato l'approccio ai problemi di automazione industriale ed ho realizzato che la metodologia doveva essere necesariamente differente, più rigorosa. Perchè non bastava che il programma bene o male girasse. Il prgramma deve girare bene, deve essere manutenibile e, soprattutto, affidabile.

A questo punto che si programmi in ladder, in "C" o in altro linguaggio, poco importa.

Usando KOP o simili molti pseudo programmatori, buttan giù sequenze "ad orecchio", tanto son contatti. Purtroppo la fase di macro analisi e, soprattutto, di analisi dettagliata tende ad essere saltata. Pechè? Perchè è reputata un'inutile perdita di tempo. Anzi spesso si va sull'impianto senza quasi aver sviluppato il programma. Si inizia a scirvere e a buttar giù righe di contatti, si vede se la macchina fa quello che dovrebbe, altrimenti si mettono pezze su pezze. Alla fine a forza di mazzate la macchina riesce a fare quello che dovrebbe.

Risultato. Il programma apparentemente "gira". Se dovrai fare una modifica rischi di dover buttar tutto per aria e, passato qualche mese, se qualcuno deve metterci mano son dolori.

Se si fosse lavorato in modo corretto, con macroanalisi ed analisi dettagliata per iscritto, Con un dizionario delle variabili, con tutti i simboli al loro posto, etc., il tempo impiegato sarebbe stato inferiore o comunque non superiore, il programma sarebbe documentato e qualsiasi modifica e/o aggiunta non comporterebbe equilibrismi di alta acrobazia.

Ci sono cose banalissime ma che ti fanno risparmiare un sacco di tempo poi, quando andrai a far manutenzione al programma.

Ti faccio un esempio terra terra. Io, da decenni, indipendentemente dal linguaggio usato, nomino connomi inizianti per "flg_" tutte le variabili booleane che servono da indicatori per scelte. Se leggo un mio listato di 30 anni fa quando incontro un'istruzione che pone a "1" o a "0" una variabile flg_pippo so già da qualche parte quella variabile servirà ad operare una scelta.

Non solo assieme al listato troverò uno o più files di testo che discrivono quello che fa il programma e come lo fa.

[avafab]

grazie livio, sono giovane e sono d'accordo con te. bisogna documentare e commentare. Infatti al mio primo approccio l'ingegnere mi ha dato il suo programma e mi ha detto: "ecco, hai visto come funziona la macchina, questo è il programma che ho fatto, studiatelo e capisci un po' come funziona". Il problema è che non c'era nessun commento, e per capire il programma ci ho messo una vita.. mi sono fissato per giorni e giorni su cose che poi ho scoperto essere delle stupidate.. immagino se un giorno mi capiterà di fare manutenzione..

mi riprometto di seguire i tuoi consigli. grazie.

continuiamone a parlare, scrivete il vostro approccio con la programmazione, il modo in cui schematizzate prima di procedere alla stesura del programma.

[Roberto Gioachin]

Quoto in toto quello che ha scritto Livio, più o meno è come faccio anch'io.

quindi tu i plc li programmi sempre con l'SFC?

I non ho detto questo, sarebbe impossibile scrivere un programma esclusivamente in SFC.

Io, come molti, prediligo il ladder, un linguaggio che rappresenta il lavoro in maniera grafica, con vantaggi indubbi durante il debug.

Altri preferiranno "IL", ma questo dipende da diverse attitudini o diversa formazione, di fatto non esiste una grande differenza fra i due.

Sicuramente quando realizzo sequenze, uso abondantemente SFC.

In questo modo posso rappresentare prima graficamente le operazioni da eseguire, solo sucessivamente riempio passi e transizioni con le istruzioni adeguate.

Purtroppo ho visto molto spesso usare questo linguaggio (così è definito dalle IEC61131), in modo errato con risultati scadenti o limitati.

Altra cosa imprtante:

A mano a mano che si scrive codice, prendere appunti su alcuni aspetti che saltano agli occhi se non si è in gradi di analizzarli subito, per evitare di dimenticarli e trascurare quindi cose che potrebbero essere inportanti.

[Manuel Larsen]

Spero di non essere accusato di necro-post, ma volevo apportare la mia esperienza di programmazione. Lavoro in una ditta di impianti semaforici e si è pensato di regolare l'entrata e uscita garage con un semaforo a due luci controllato da PLC (come fanno del resto tutti...). Premetto che non ho mai utilizzato un PLC anche se il Ladder Diagram l'avevo già visto a lezione (sono ingegnere informatico). Girovagando per il web mi sono imbattuto in questo bellissimo documento, che cerca di automatizzare la traduzione di una rete di Petri direttamente in LD.

Ho provato a programmare il semaforo di cui sopra e devo dire che son riuscito a ottenere un ottimo risultato.

Il semaforo funziona in questo modo:

- Attesa sul rosso da entrambe le parti.

- Prenotazione dell'incrocio da uno dei due lati.

- Se l'incrocio è libero ed è passato un tempo minimo di rosso, servo con il verde chi ha prenotato.

- Passati 10 sec torno in rosso e passati 3 sec (di sgombero) libero l'incrocio.

La rete di Petri da me creata è la seguente (BTW il programma usato per farla è TINA):

Tv1 = transizione temporizzata tempo di verde 1

Tv2 = transizione temporizzata tempo di verde 2

Tr1 = transizione temporizzata tempo di rosso minimo 1

Tr2 = transizione temporizzata tempo di rosso minimo 2

Una volta creata la rete di Petri ho usato l'equazione (4) del documento trovato nel web e voilà! La rete è stata tradotta automaticamente in LD.

Il programma è stato testato e funziona alla grande. Trovo che le reti di Petri sono ottime per la modellizzazione (forse si adattano molto al campo in cui lavoro in realtà), permettono di apportare modifiche senza stravolgere tutto quanto, una volta fatto il modello di cui sopra ad esempio aggiungere il giallo è velocissimo

Cosa ne pensate? Ribadisco se sono neofita del PLC, per ora è ciò che di meglio ho trovato, ma sono aperto a nuove sfide!

Modificato: 27 aprile 2012 da Manuel Larsen

[Roberto Gioachin]

Mi sembra ottimo lo spunto che dai con queste informazioni.

Sicuramente hai fatto un buon lavoro, utile a molti.

Vorrei farti notare una cosa; se guardi nel documento del quale hai fornito il link, si nota come i diagrammi fatti con le reti di petri siano molto simili al SFC delle IEC61131.

Detto questo ci si può immaginare come uno derivi dall'altro.

Ma allora, per quale motivo si deve rinunciare alla rappresentazione grafica del diagramma inserito dentro il programma stesso?

Io credo che se ti guardi bene il linguaggio SFC ti accorgi che per ottenere lo stesso risultato hai anche minori passaggi da fare.

Tieni presente che proprio i programmi per i semafori sono il piatto forte per insegnare a scuola (ITI o IPSIA) il linguaggio SFC, essendo quasi solo composti da sequenze.

Altra cosa importante, in genere i compilatori degli ambienti di sviluppo per plc, tendono a convertire il programma in IL utilizzando salti di programma (Jump - Label),

In questo modo, anche le sequenze complesse non appesantiscono il processore, in quanto tutte le fasi non attive non vengono elaborate.

Complimenti per il risultato

Roberto

[Manuel Larsen]

In realtà appena mi è arrivato LOGO! SoftComfort sul PC ho iniziato a programmare con il mooolto intuitivo linguaggio FBD di LOGO!. Il problema fondamentale è che andavo veramente "a caso" nella programmazione, facevo tentativi su tentativi finchè non arrivavo a una soluzione soddisfacente per il problema che avevo trovato. Poi si manifestava un nuovo problema... e da capo. Questa soluzione ovviamente è controproducente e anche per fare la cosa più semplice (un senso unico alternato) avrei perso un sacco di tempo. È qui che ho avuto un'illuminazione: mi sono ricordato del corso di Automazione Industriale del PoliMi, che tra l'altro mi era molto piaciuto, nel quale si parlava delle reti di Petri. Ho subito pensato che le reti di petri sarebbero state la soluzione. Così mi son riguardato le lezioni e mi sono imbattuto in questo. Ho tentato di applicare il tutto al mio caso ma mi sono trovato il leggera difficoltà nella traduzione rete Petri -> SFC, inoltre passare da Petri a SFC e infine a LD mi pareva laborioso, così ho cecato di eliminare un passaggio e sono arrivato al documento del mio post precedente.

In conclusione: sono logorroico anche nello scrivere; mi trovo molto meglio a progettare in rete di Petri e programmare in LD.

Grazie infinite per le considerazioni!

[Livio Orsini]

Interessante, anche se le reti di Petri è una metodologia che, personalmente, non gradisco.

[Manuel Larsen]

Mi son divertito a fare anche un bel senso unico alternato utilizzando la stessa procedura. Ecco la rete:

Tv1 = blocco ad accensione ritardata a 10s con ingresso V1

Tv2 = blocco ad accensione ritardata a 10s con ingresso V2

Tr = blocco ad accensione ritardata a 3s con ingresso ¬R1 * ¬R2

Funzioni delle uscite: ¬ = NOT, + = OR, * = AND

A = A * (¬V2 + ¬Tv2) + ¬A * ¬R1 * Tr

B = (B + V1 * Tv1) * (¬B + ¬Tr + R2)

V1 = (V1 + ¬A * Tr * ¬R1) * (¬Tv1 + R1)

V2 = (V2 + B * Tr * ¬R2) * (¬Tv2 + R2)

R1 = R1 * (¬V1 + ¬Tv1) + ¬R1 * Tr * ¬A

R2 = R2 * (¬V2 + ¬Tv2) + ¬R2 * Tr * B

Buttando dentro queste formulette nel LD il programma è fatto.

Aggiungo che per "accendere" le luci R1 e R2 dovremo usare le uscite negate, essendo i posti R1 e R2 inizialmente marcati nella rete.

Girovagando nel forum ho visto molta gente chiedere come si fa un "ciclo infinito", questo programmino fa esattamente quello, quindi lo lascio qui per tutti i ricercatori.

Sto andando troppo off-topic...

Modificato: 27 aprile 2012 da Manuel Larsen

[ZENOMA]

Amici del Forum.

Anche io o sempre avuto questo dubbio di che metodo usare per programmare i PLC senza usare il metodo "TRy and Test" cioe programmare seguendo una logica cronometrica, provare e poi riprogrammare quello que non va...e cosi via.

Vorrei sapere di piu del metodo usato da Livio....lui parla di un "Analisi Top-Down" mi potete spiegare come si fa???

Grazie a tutti.

Zeno.

[Manuel Larsen]

L'analisi Top-Down (o almeno quella che han insegnato a me, non so se Livio intende qualcosa d'altro) è semplicemente un approccio al problema. Consiste nel considerare il problema nella sua interezza in primo luogo, valutando variabili e situazioni generali, e poi passare ad una suddivisione dello stesso valutando variabili e situazioni sempre più particolari. Si contrappone al metodo Bottom-Up che consiste esattamente nell'inverso: si parte da tanti problemi singoli e si va via via aggregandoli in problemi "più grandi" che risulteranno poi nel problema completo. Solitamente nelle grandi aziende viene utilizzato il metodo Bottom-Up: ad ogni gruppo di lavoro dell'azienda viene assegnato un preciso problema, una volta che tutti i gruppi hanno finito si uniscono tutti i risultati ad ottenere la soluzione finale (si pensi allo sviluppo di un gioco per PC ad esempio. C'è il gruppo che crea la storia, quello che crea la grafica, quello che crea il core esecutivo e alla fine si mette tutto insieme... Non per forza chi crea la storia deve sapere come deve essere la grafica e viceversa, ovvio che comunque un minimo di indicazioni generali ci devono essere).

Esempio: devo scrivere un tema per il compito di italiano.

Top-Down:

- Scrivo gli argomenti principali che devo affrontare nel tema e l'ordine che voglio seguire.

- Per ogni argomento sviluppo un paragrafo che segue il filo logico deciso precedentemente.

Bottom-Up:

- Scrivo tutto quel che mi viene in mente suddividendo in "paragrafetti".

- Unisco tutti i paragrafetti in un unico tema aggiungendo il senso logico che li deve unire.

[Livio Orsini]

Solitamente nelle grandi aziende viene utilizzato il metodo Bottom-Up:

No!

Si fa esattamente il contrario, almeno dove si lavora bene.

Si deve sempre iniziare con l'analisi del problema nella sua complessità.

Si considera il problema nella sua interezza e si scende nel dettaglio sino al livello minimo. Questo significa applicare il metodo deduttivo o si si preferisce di "top down".

Poi si valuta quante di queste funzioni elementari possono essere ricavate da precedenti già consolidati e di cui si riconosce l'affidabilità.

Le parti mancanti ed il "tessuto connettivo" vengono scritte ex novo.

A questo punto si può iniziare a parlare di "bottom up" o metodo induttivo.

Allora si si può affidare a singoli gruppi, anche fisicamente distanti, lo sviluppo delle funzioni elementari che saranno poi integrate in sottogruppi, gruppi, supergruppi e sistemi. I nomi possono variare secondo abitudine e tradizione, ma non muta la filosofia.

Ma questa è solo la strategia di realizzazione, non di analisi.

Purtroppo noto che si confonde, o si ignora, la fase di analisi con la fase di realizzazione. Tutto a scapito dell'affidabilità del software.

Come ho scritto in precedenza c'è sempre chi pensa di risparmiare saltando l'analisi.

Bottom-Up:

- Scrivo tutto quel che mi viene in mente suddividendo in "paragrafetti".

- Unisco tutti i paragrafetti in un unico tema aggiungendo il senso logico che li deve unire.

Questo è il paradigma di come non si deve lavorare!

[Manuel Larsen]

Top down

La programmazione top-down è uno stile di programmazione in cui la progettazione inizia specificando parti complesse e suddividendole successivamente in parti più piccole (divide et impera). Eventualmente, i componenti sono specificati quanto basta per la codifica ed il programma viene anche scritto. Questo è l'esatto opposto della programmazione bottom-up.

Il nome top down significa dall'alto verso il basso: in "alto" viene posto il problema e in "basso" i sottoproblemi che lo compongono. Il nome ricorda anche una raffigurazione a forma di piramide, in cui l'obiettivo finale è composto dalla cima della piramide e i sottoproblemi che lo compongono formano la base.

Il top down parte dall'obiettivo e da esso fa scaturire la strategia direttamente adatta a determinare l'obiettivo stesso, quindi valorizza il perché e da esso fa dipendere il come, ovvero la strategia; individua, quindi, le risorse necessarie, precisa quelle disponibili e identifica quelle mancanti, propone successivamente ogni risorsa mancante come sub-obiettivo ovvero come sotto-problema in cui ciascun sub-obiettivo richiede una sub-strategia ad esso correlata.

Bottom up

Il bottom up richiama invece un'immagine raffigurante una freccia in cui la coda è il bottom (la parte bassa) mentre up è la punta: dal punto di vista dinamico si parte dal bottom e si procede verso up.

Il bottom up prende corpo dal punto di partenza (bottom) ovvero dalla situazione iniziale; considera l'obiettivo finale, induce a costruire un percorso sequenziale organizzato in passaggi successivi in cui l'ancoraggio tra traguardi intermedi e obiettivo finale è generalmente ricercato in modo intuitivo (euristico).

-Copincollato da wikipedia

Il collegamento tra fasi del bottom-up è intuitivo, non induttivo... Si definisce, infatti, procedimento euristico, un metodo di approccio alla soluzione dei problemi che non segue un chiaro percorso, ma che si affida all'intuito e allo stato temporaneo delle circostanze, al fine di generare nuova conoscenza. È opposto al procedimento algoritmico (sempre mamma wiki).

Questa volta ho precisato che quello a cui si riferiva Livio poteva differire da ciò che intendo io!

Si considera il problema nella sua interezza e si scende nel dettaglio sino al livello minimo. Questo significa applicare il metodo deduttivo o si si preferisce di "top down".

Poi si valuta quante di queste funzioni elementari possono essere ricavate da precedenti già consolidati e di cui si riconosce l'affidabilità.

Le parti mancanti ed il "tessuto connettivo" vengono scritte ex novo.

A questo punto si può iniziare a parlare di "bottom up" o metodo induttivo.

Non ho capito questo passaggio, prima utilizzi il Top-Down e poi il Bottom-Up? Quando scendi nel dettaglio non stai già "scrivendo" il tessuto connettivo? Nel mio esempio i "paragrafetti" sono i precedenti già consolidati e di cui si riconosce l'affidabilità dopodichè scrivi il tessuto connetivo. Ovvio che ci deve essere una base, non puoi scrivere paragrafetti sul duomo di Milano quando il tema è sul sistema solare. Però puoi scrivere un paragrafo sulla luna, uno su marte e poi unirli...

EDIT: concordo sul fatto dell'azienda, in effetti quello è il procedimento di implementazione, non di analisi. Solitamente per l'analisi è meglio usare un metodo Top-Down, per ricerca e sviluppo un Bottom-Up.

Modificato: 9 maggio 2012 da Manuel Larsen

[batta]

Concordo pienamente con Livio.

Fare un tema scrivendo tutto quello che viene in mente e riordinando i paragrafi alla fine darà un risultato, nel migliore dei casi, scarso.

Quando a scuola nelle canoniche due ore dovevo fare un tema, solitamente rimanevo per un'ora e mezza a pensare, senza scrivere nulla.

Nell'ultima mezzora, col le idee ben chiare, scrivevo tutto seguendo un filo logico.

Quando programmo devo conoscere tutto del problema che dovrò risolvere.

Anche avendo chiaro il traguardo da raggiungere, capita ugualmente di dover ritornare sui propri passi perché ci si accorge di aver preso la strada sbagliata.

Se il traguardo finale nemmeno si conosce, la strada sbagliata sarà la regola e non l'eccezione.

Nel caso il problema si debba affrontare col metodo Bottom-Up, se si vuole sperare di arrivare al risultato finale ci dovrà essere qualcuno che conosce globalmente il problema ed in grado di distribuire i compiti ai singoli gruppi di lavoro, seguendo quindi un metodo top-down.

Ogni gruppo di lavoro poi, per poter risolvere il singolo problema, lo dovrà conoscere in modo dettagliato. All'interno del singolo gruppo si ritorna, quindi, al top-down.

[Livio Orsini]

Premesso che wikipedia va citata con molta cautela perchè spesso, specialmente in ambito tecnico, non è molto precisa (eufemismo). Non si possono citare singole asserzioni avulse dal loro concetto.

Il collegamento tra fasi del bottom-up è intuitivo, non induttivo...

Come ho scritto in precedenza, la lingua italiana è molto precisa, al contrario della lingua inglese.

Un progettista non può basare il proprio lavoro sulla sola intuizione, questa può solo essere un aiuto. Il lavoro di un progettista deve essere rigoroso e esclusivamente basato su fatti e leggi.

Dal vocabolario della lingua italiana intuire "Vedere prontamente con l'intelletto deducendo da indizi vaghe e generici." oppure "Comprendere attraverso una percezione immediata senza l'aiuto della ragione".

Dal vocabolario della lingua italiana induzione: "Procedimento logico che consente di ricavare da osservazioni di particolari, leggi generali......."

Galileo Galilei osservando le oscillazioni di un lampadario del duomo di Pisa per induzione ricavò le leggi dell'oscillatore armonico; sir Isaac Newton, svegliato di soprassalto dalla caduta di una mela sulla sua testa, fu indotto a speculare sul fatto giungendo a formulare le leggi di gravitazione.

Di esempi che testimoniano come speculando intellettualmente su piccoli particolari si possa giungere a formulare leggi universali ne potrei citare molte altre, mi mi limito a questi due esempi eclatanti.

L'analisi denominata "bottom up" tende proprio a risalire all'applicazione generale partendo da funzioni elementari e /o particolari.

Il metodo deduttivo opera esattamente al contrario.

Sempre dal vocabolario della lingua italiana deduzione: "Pervenire mediante una inferenza da un principio generale a una soluzione particolare".

Però, in questa imperante sottocultura delle tre "S" (Sciocchezza, Stupità e Servilismo culturale) che fa pronunciare "gianior, sinior e steisg in luogo di junior, senior e stasg (perhè stage è un termine francese e non inglese), usare appropriati italianissimi termini sembra poco elegante e cosi si sproloquia di "top down" e "bottom up", rozzi termini Yankee che approssimano deduzione ed induzione.

Conoscendo le leggi che regolano l'oscillatore armonico (leggi che ai miei tempi si studiavano nelle fasi iniziali del corso di meccanica razionale), si può dedurre il modello che rappresenta il moto oscillante del lampadario del duomo di Pisa. Oppure conosscendo le leggi di gravitazione universale si può dedurre il modello che rappresenta la caduta dellla mela sulla testa di chi si è addormantato sotto l'albero di mele.

Questa deduzione effettua un'analisi "top down" per costruire il modello della caduta della mela. Poi da questo modello potrai codificare le istruzioni, che ti permettono di simulare il moto della mela dal ramo al terreno, su di un elaboratore elettronico.

Tra la modellizzazione e la codifica è necessaria un'altra operazione di anlisi.

Come tradurre le equazioni del modello in istruzioni macchina?

Questo lavoro è specifico dell'analista software. Per effettuare questo lavoro l'analista deve considerare i mezzi "meccanici" disponibili (hardware) ed i mezzi di programamzione disponibili: sistema operativo, linguaggio di programmazione, ambiente di sviluppo, interazione del prodotto finito con l'utente (interfaccia HMI). In base a queste specifiche effetterurà un'analisi deduttiva o, se preferisci, top down, per definire le varie funzioni necessarie, le gerarchie, le interconnessioni, le priorità, etc.

Terminato questo lavoro la codifica è praticamente automatica. Può essere svolta in parallelo da più programamtori, oppure da un programmatore che realizza le varie funzioni in ordine sparso o, se è rigoroso, partendo dalle più esterne risalire sino al programma principale, con metodo induttivo o di "bottom up".

Non ho capito questo passaggio, prima utilizzi il Top-Down e poi il Bottom-Up? Quando scendi nel dettaglio non stai già "scrivendo" il tessuto connettivo?

Se non hai capito il passaggio significa che non sai cosa sia la progettazione di un sistema!

Come ho scritto in precedenza tu confondi l'analisi con la codifica.

Modificato: 9 maggio 2012 da Livio Orsini

[Livio Orsini]

Quando programmo devo conoscere tutto del problema che dovrò risolvere.

Anche avendo chiaro il traguardo da raggiungere, capita ugualmente di dover ritornare sui propri passi perché ci si accorge di aver preso la strada sbagliata.

Se il traguardo finale nemmeno si conosce, la strada sbagliata sarà la regola e non l'eccezione.

Questo è il modo di lavoro di un buon prgettista, esperto, che lavora con metodo.

L'accenno al dover rivedere la propria strategia iniziale denota una consolidata esperienza lavorativa, su problemi reali e pratici.

Io, come filosofia di vita, ho molti dubbi e poche certezze. Son sempre pronto a rivedere le mie convinzioni alla luce di nuovi elementi.

In pochissime cose ho un atteggiamento manicheo.

Una di queste è sulla metodologia di lavoro.

Da mezzo secolo sono convinto che esistono solo due modi di lavorare: quello corretto e quello errato.

[Matteo L]

Salve a tutti,

nella ditta per cui lavoro abbiamo utilizzato per molto tempo il Logo! della Siemens e la facilità di programmazione e connessione con l'impianto è ciò che secodo me lo rende davvero utile, ma se si vuole fare "qualcosa di più audace" i limiti vengono fuori. A seguito di ciò abbiamo deciso di passare ad ABB e la programmazione del controllore avviene col Codesys, che permette la programmazione con i 5 linguaggi IEC più il CFC, davvero uno strumento fenomenale. Qualcuno di voi utilizza tale linguaggio? Mi piacerebbe avere scambi di opinione con altri utilizzatori se possibile!

[urci56]

Salve a tutti; vorrei dare il mio contributo a questa interessante discussione.

Per quanto riguarda i linguaggi da usare, sono daccordo con chi afferma che ormai è quasi un fatto di scelta soggettiva, essi consentono tutti di documentare bene il lavoro da fare; personalmente preferisco il ladder.

Per quanto invece riguarda il metodo di approccio io cerco di riportare la specifica in flow chart, cominciando da macro funzioni proseguendo poi nelle subroutine più dettagliate.

Facendo così ci hanno due vantaggi: 1) la stesura del flow chart aiuta il ragionamento di analisi del problema 2) il flow chart stesso, se ben fatto, è il miglior documento storico del programma in questione.

Lasciatemi dire però che alla fine queste scelte sono fatti soggettivi e che difficilmente possono essere riportate all'interno di una regola comune.

Saluti.