Tecniche Di Programmazione

[Livio Orsini]

Caro Alessandro2151, quello che io trovo strano di te è il tuo modo di saltare alle conclusioni.

Prendi quello che segue solo come puntualizzazione e spiegazione senza intenti polemici

A parte la storia del PLC non completamente esatta ed incompleta fai delle ipotesi che non hanno fondamento.

Vidiamo di precisare*chiarire qualche punto.

IL PLC (programmable logic controller) nasce intorno agli anni 70....

Alla fine degli anni 60 General Motors indice una gara per la fornitura di apparati industriali programmabili atti ad autoamtizzare le linee di produzione.

Rispondono A&B e Modicon. In pratica entrambi propongono un calcolatore di processo (bisogna fare riferimento alla potenza di calcolo di quegli anni), dotato di I/O industriali e di "programma applicativo" che crea un'interfaccia grafica semplificata per il manutentore-programmatore. Questa interfaccia traduce la logica booleana in "ladder diagrams" simili ad una pagina di disegno. Piccolo particolare non trascurabile: noi europei sviluppiamo i disegni da sinistra a destra ponendo l'alimentazine in alto e le bobine in basso; gli americani sviluppano dall'alto in basso ponendo le bobine a sinistra e l'alimentazione a destra, questa è il motivo per cui, ancora oggi, i ladder diagrams hanno questa configurazione.

Questo tipo di approccio comincia ad avere molto successo. Molti costruttori di elettronica ed elettromeccanica, con l'avvento dei primi microprocessori, iniziano a sviluppare sistemini PLC con alcune decine di I/O.

Con l'incremento della potenza di calcolo aumentano sia le prestazioni che la capacità (in termini di I/O) dei PLC; la configurazione basata su calcolatore di prcesso resiste fino ai primi anni 80.

Personalmente ho visto applicazioni E. MArelli - Westinghose, per controllo di laminatoi, basati su calcolatori simili a PDP11, con fino ad un migliaio di I/O circa. Nel medesimo periodo, quando l'applicazione richiedeva un centinaio di I/O, si usavano PLC simili agli attuali.

..ma il PLC è inquadrabile più come informatica o eletromeccanica intelligente ? ? ?..

Prima dovresti porti la domanda fondamentale: Cosa è l'informatica?

A mio parere, la risposta è insita nel termine: informazione automatica.

Mentre si tende a confondere l'informatica con la cibernetica, che è la scienza dei comandi e dei governi.

Sempre a mio parere oggi i PLC sono distanti anni luce dai PLC anni 80 e sono apparati che appartengono contemporaneamente alla cibernetica ed all'informatica. Questo perchè in contemporanea possono sia governare le macchine, sia per trasmettere le informazioni.

.....Dato quanto sopra citato una persona come te come riesce ad avere un felice approccio con i PLC visto con quale scuola di programmazione sei nato e cresciuto ???...

Primo punto. Tu cosa ne sai a quale scuola di programmazione mi sono formato? Puoi fare solo supposizioni non suffragate da dati. In effetti io ho iniziato a programmare con linguaggio ad alto livello: il FORTRAN (FORmula TRANslate), solo con l'uso dei micro processori sono arrivato al linguaggio macchina (più basso livello dell'assembler, praticamente puro binario).

Secondo punto. E' ancora da dimostrare che il mio approccio ai PLC sia felice . Potrebbe essere solo un modo per guadagnare il corrispettivo del pane e della benzina.

Terzo punto, il più importante. Io mi vanto di avere una grande elasticità mentale per cui mi è indifferente lo strumento usato. Rifletti bene sui tecnici della mia generazione.

Condizioni iniziali: matita e regolo per i calcoli e disegni, valvole e relè come strumenti di lavoro. Condizioni attuali (non dico finali perchè intendo campare ancora molti anni ): PC per calcoli e disegni + calcolatrice tascabile che è potente quasi come un PDP8 (oer alcune cose lo è di più), microprocessori, PC, PLC che hanno la potenza di dieci PDP11 (anche di più) come strumenti di lavoro, oltre agli insostituibili relè, più convertitori in cc e ac in luogo degli ampli magnetici e Ward Leonard.

E tu credi che una persona come me, che ha attraversato indenne 4 (quattro) rivoluzioni tecnologiche, si ponga dei problemi per passare da un linguaggio tipo lader diagram a d un assembler? Ma via...

..Nel senso che il PLC dovrebbe essere un salto all’indietro , o no ?...

Perchè? Con questa logica si dovrebbe affermare che anche il PC è un salto all'indietro. Infatti anche chi, come mio cognato, non conosce proprio niente di onformatica e cibernetica riesce a compiere operazioni e calcoli in modo automatico, senza neanche immaginare quello che sta succedendo nella macchina. Digita alcuni dati, preme un tasto e si presenta un ble diagramma che esemplifica come sono didtribuiti i vari eventi...

No, asoutamente no! Un salto all'indietro sarebbe, p.e., tornare al regolo ed alla macchina da scrivere o, additittura al pennino più calamaio

..E preferisci il Siemens perché si avvicina all’assembler grazie all?AWL ?...

Questa illazione, destituita di fondamento, potevi risparmiartela semplicemente leggendo con più atenzione il mio post.

Io affermo: "Una delle poche cose buone di Siemens è...." Questo non mi sembra proprio esprimere una preferenza nei confronti di Siemens, anzi è proprio il contrario

Chiudo questo post quasi OT con una domanda rivolta a te: mi spiegeresti cosa ti prefiggevi con il tuo post? sinceramente non l'ho capito. Sicuramente la spiegazione della non comprensione è dovuta alla mia data di nascita (triste perchè vorrei una ventina di anni in meno)

Modificato: 17 febbraio 2005 da Livio Orsini

[FranSys]

Ogni volta che vedo un programma scritto in ladder devo fare contorsioni mentali per capirne la logica. In pratica devo trasformare i contatti in serie in AND e quelli in parallelo in OR; per le altre operazioni è anche peggio.

Livio, io credo che si debba modulare il proprio modo di pensare a seconda dell'ambiente in cui ci si trova, senza fossilizzarsi su determinate convenzioni.

E' un po' come quando si tenta d'imparare una lingua straniera: fin tanto che si parla pensando in italiano e traducendo nella lingua straniera si fatica a farsi comprendere. Nel momento in cui la nuova lingua entra in testa e ci si esprime senza effettuare "conversioni intermedie" il gioco è fatto.

Per quanto mi concerne - e non sono certo il solo a farlo - passo con discreta facilità da un linguaggio di programmazione ad un altro... dipende da cosa ho davanti: con un PC uso il Basic o quel poco di C che conosco, con un microcontrollore preferisco l'assembler perché "non fa perdere la sensazione delle cose", con un PLC trovo confortevole il Ladder. In realtà, molto spesso è necessario utilizzare il meglio dei linguaggi che ho citato utilizzandoli discrezionalmente nelle varie sezioni dell'applicazione (compilatore permettendo).

ma il PLC è inquadrabile più come informatica o eletromeccanica intelligente ? ? ?

Alessandro, lascia perdere gli inquadramenti e le definizioni scolastiche e pensa a come è fatto l'hardware. Nel PLC, infine, c'è un microprocessore... il resto sono solo convenzioni. Forse il timer della lavatrice è "elettromeccanica intelligente"!

Ciao.

Modificato: 17 febbraio 2005 da FranSys

[FranSys]

E tu credi che una persona come me, che ha attraversato indenne 4 (quattro) rivoluzioni tecnologiche, si ponga dei problemi per passare da un linguaggio tipo lader diagram a d un assembler? Ma via...

Meno male Livio, cominciavo a preoccuparmi!

Ciao.

[Alessandro2151]

Caro Alessandro2151, quello che io trovo strano di te è il tuo modo di saltare alle conclusioni

Mi sembra che quello che salta alle conclusioni sei tu , non sono io . Infatti ti ho riportato un documento sottolineando " correggimi se sbaglio " proprio prechè ho capito che hai visto sicuramente e hai vissuto in prima persona 4 rivoluzioni tecnologiche , la mia + che una conclusione era una domanda per capire , tutto qui .

Non giudico nessuno quando non la pensa come me , anzi , le pongo dei quesiti perchè magari ho davanti qualcuno che vede qualcosa che io non riesco ancora a capire .

Non ho sicuramente la tua esperienza chiaramente e quindi il confronto è del tutto costruttivo come ho già ribadito alcuni giorni fa .

Primo punto. Tu cosa ne sai a quale scuola di programmazione mi sono formato?

Be lo affermi tu con quale scuola sei nato , o no ?

Secondo punto. E' ancora da dimostrare che il mio approccio ai PLC sia felice  . Potrebbe essere solo un modo per guadagnare il corrispettivo del pane e della benzina.

Sicuramente non escludo neanche questo , ed infatti ti ho chiesto come possa essere felice il tuo approccio con essi non ho detto che lo è .

Terzo punto, il più importante. Io mi vanto di avere una grande elasticità mentale per cui mi è indifferente lo strumento usato.Condizioni attuali (non dico finali perchè intendo campare ancora molti anni  ): PC per calcoli e disegni + calcolatrice tascabile che è potente quasi come un PDP8 (oer alcune cose lo è di più), microprocessori, PC, PLC che hanno la potenza di dieci PDP11 (anche di più) come strumenti di lavoro, oltre agli insostituibili relè, più convertitori in cc e ac in luogo degli ampli magnetici e Ward Leonard.

Questo è scontato altrimenti non saresti soppravissuto all'evoluzione tecnologica di tutti questi anni

E tu credi che una persona come me, che ha attraversato indenne 4 (quattro) rivoluzioni tecnologiche, si ponga dei problemi per passare da un linguaggio tipo lader diagram a d un assembler? Ma via....

Assolutamente no .

Non ho detto che ti poni dei problemi ho solo ripreso il fatto " devo fare contorsioni mentali quando mi trovo davanti ad un ladder " parole tue !

Perchè? Con questa logica si dovrebbe affermare che anche il PC è un salto all'indietro. Infatti anche chi, come mio cognato, non conosce proprio niente di onformatica e cibernetica riesce a compiere operazioni e calcoli in modo automatico, senza neanche immaginare quello che sta succedendo nella macchina. Digita alcuni dati, preme un tasto e si presenta un ble diagramma che esemplifica come sono didtribuiti i vari eventi...

Be questo è quello che fa la maggior parte delle persone che usa un PC si per lavoro , ma magari usa solo word ed excel per fare il ragioniere o altro , e che deve ringraziare o forse no (questa è un'altra discussione ) il Signore della Microsoft , perchè senza di lui oggi sarebbe li ancora con carta e penna .

Chiudo questo post quasi OT con una domanda rivolta a te: mi spiegeresti cosa ti prefiggevi con il tuo post? sinceramente non l'ho capito. Sicuramente la spiegazione della non comprensione è dovuta alla mia data di nascita  (triste perchè vorrei una ventina di anni in meno)

Ma se pensavi che mi prefiggevo qualcosa ti sbagli , perchè ti ho solo chiesto alcune cose alle quali hai gentilmente risposto , non è morto nessuno no ?

Io dovrei per esempio sforzarmi di più con un AWL su un plc che con un ladder , nonostante per i PC uso Visual Basic che è un conpilatore con molte + istruzioni possibili di quante ne abbia un AWL , ho incominciato a studiare il Pascal agli inizi ma poi per necessità ed obblighi lavorativi ho dovuto implementare il Visual basic ( ma non per mia scelta ) , e tu magari allo stesso tempo ai implementato il PLC nei tuoi strumenti di lavoro per varie esigenze , nulla da dire !

Le mie erano solo curiosità , che mi sembra hai soddisfatto bene. Se ti sono sembrato provocatorio o con qualche scopo da raggiungere non era mia intenzione credimi , non giro in questo forum per provocare qualcuno tutt'altro !

Quello che mi sembra di vedere alcune volte , è che le curiosità esposte in questi post ( non solo da me ) molte volte vengono interpretate da molti ( non mi riferisco a te in particolare ) come mine per discordia invece che come semplice e puro apprendimento .

Per quanto riguarda la tua età , tu vorresti avere 20 anni meno ...........qualcuno ne vorrebbe avere 20 di più con la conseguente esperienzia che ne porterebbe ci hai mai pensato ?

[Alessandro2151]

FranSys  Alessandro, lascia perdere gli inquadramenti e le definizioni scolastiche e pensa a come è fatto l'hardware. Nel PLC, infine, c'è un microprocessore... il resto sono solo convenzioni. Forse il timer della lavatrice è "elettromeccanica intelligente"!

Effettivamente hai ragione , sono d'accordo con te ,quello che la differenza è solo lo strumento che usi che ti permette di usarlo di + o meno al meglio delle sue possibilità .

[STEU]

Ragazzi secondo me il povero DM27 se legge tutti i post da grande vorra' andare a lavorare in banca..

Comunque devo dire bisogna sempre vedere cosa si fa e come si fa a programmare.

Sicuramente scrivere in awl e molto piu' veloce che in ladder poi la capibilità dipende da come uno è abituato senz'altro in ladder si è obbligati ad utilizzare molta piu' memoria e risorse del plc (ma con i plc di oggi non credo sia un problema).

Fare dei cicli con dei passi di set rest con le transizioni penso che sia la stessa cosa, probabilmente se ce qualche segmento con tanti bit in and or con molti livelli di parentesi è possibile che in ladder sia un po' piu' facile.

Lo so che con il ladder (step 7 compreso) è possibile fare tutti i calcoli che si vuole , spedire tutte le e-mail , cominicare con il mondo intero, e solo un approccio mentale devo dire comunque che per esperienza personale

alcune cose (ammetto meno comprensibiole al primo impatto , ma con un po di attenzione capibilissimo) come i loop per la ricerca all'interno di un data base sono scritti con molto meno codice.

Un'ultima cosa che non capisco perchè la maggior parte dei plc ,escluso Siemens, non fanno è quando in stato con il computer si osserva un contatto quasi tutti i PLC visualizzano lo stato del contatto a 1 o a 0 che è a fine programma e non come è in quel momento.

Mi spego meglio:

Immaginiamo di resettare un bit ad inizio programma , a meta' programma lo vado ad interrogare in una catena ladder , a fine programma lo setto a 1 la scansione sucessiva resetto di nuovo e cosi via all'infinito.

Quando vado in stato con il computer a meta' programma il bit in quella posizione è a 0 ma io lo vedo a 1 perche' a fine programma e' settato in questa maniera si vedono dei bit che dovrebbero essere a 1 quando sono a 0 e viceversa.Questo secondo me e' un errore sacrosanto.

Spero di essere stato chiaro nell'esempio finale.

[FranSys]

Sicuramente scrivere in awl e molto piu' veloce che in ladder poi la capibilità dipende da come uno è abituato senz'altro in ladder si è obbligati ad utilizzare molta piu' memoria e risorse del plc (ma con i plc di oggi non credo sia un problema).

Steu, se il compilatore dell'ambiente di programamzione è ben fatto, non è detto che un certo linguaggio utilizzi più memoria dell'altro... in teoria il risultato dovrebbe essere assolutamente lo stesso, a prescindere dalla convenzione utilizzata per scrivere il codice. In ogni caso concordo sul fatto che questo non avviene per tutti i PLC.

Un'ultima cosa che non capisco perchè la maggior parte dei plc ,escluso Siemens, non fanno è quando in stato con il computer si osserva un contatto quasi tutti i PLC visualizzano lo stato del contatto a 1 o a 0 che è a fine programma e non come è in quel momento.

Questa è una lancia spezzata a favore dello Step7. Anche se, con altri PLC, è possibile inserire nel programma dei break-point per controllare lo stato dell'elaborazione in un certo momento.

Ciao.

[Alessandro2151]

Immaginiamo di resettare un bit ad inizio programma , a meta' programma lo vado ad interrogare in una catena ladder , a fine programma lo setto a 1 la scansione sucessiva resetto di nuovo e cosi via all'infinito.

STEU puoi risoiegare l'esempio che hai fatto perchè non penso di avere capito . Scusami magari sono io che non afferro il senso del tuo discorso , Ciao Grazie Alessandro2151

[Alessandro2151]

Anche se, con altri PLC, è possibile inserire nel programma dei break-point per controllare lo stato dell'elaborazione in un certo momento.

Hai perfettamente ragione , i PLC che uso io hanno la possibilità di interrogare in qualsiasi momento e punto di stesura del programma lo stato di qualsiasi cosa , senza contare uno strumento utile come la funzione di MONITOR in tempo reale precisa al millisecondo (premetto che non è un Siemens)

[STEU]

Per alessandro2151

Intendo dire che un bit puo' essere a 1 in una parte di programma a zero in un'altra poi di nuovo a uno piu' avanti nella scansione e così via per infinite volte.

Quindi vuol dire che il bit nella stessa scansione puo' cambiare di stato tante volte ed in segmenti diversi puo' avere valori diversi.

Quando sei in stao (o monitor per altri PLC) il software step7 ti visualizza il bit a 1 o a 0 proprio come è in quel punto del programma , mentre molti PLC visualizzano lo stato del bit come è a fine scansione , anche se in quel punto del programma il bit puo' avere un valore diverso.

Devo dire che ho visto da voi che esistono dei Break point, potreste spiegarmi che cosa sono , ne ignoravo l'esistenza servono solo per la visualizzazione oppure sono istruzioni che aggiornano la periferia immediatamente?

Modificato: 18 febbraio 2005 da STEU

[FranSys]

Un break-point (punto di interruzione) è un'istruzione che congela il program counter comportando l'arresto del programma in un punto predefinito. In questo modo è possibile effettuare con tutta calma il controllo dell'area di memoria ovvero dello stato delle variabili. Tramite l'ambiente di sviluppo è generalmente possibile riprendere l'esecuzione del programma al termine dell'analisi.

E' appena il caso di dire che ci sono diversi modi per "fare in casa" un break-point... per esempio facendo "loopare" il programma su una subroutine vuota la cui uscita sia condizionata ad un bit forzabile dall'editor.

Un altro utensile molto potente, presente in alcuni editor e spesso trascurato, è il data trace. Tramite questa funzione è possibile analizzare l'andamento di una o più variabili (in ordinata) nel tempo (in ascissa, normalmente in millisecondi o frazioni).

Le istruzioni di I/O refresh consentono infine di scattare un'istantanea delle variabili discrete (DI, DO, ecc., normalmente aggiornate all'inizio od alla fine del ciclo) prima di lanciare un break-point (a volte anche prima d'eseguire un determinato codice).

In altre parole sto dicendo che per me è assoutamente normale creare un apposito task di debug che mi consenta di verificare a fondo i task che costituiscono la mia applicazione. Al termine del lavoro cancello la sezione di debug oppure la lascio dentro al PLC "a futura memoria". Ovviamente mi prendo questo mal di pancia quando il programma è veramente complesso e, specialmente, quando devo gestire situazioni asincrone rispetto al ciclo macchina.

Aggiungo che è importante non fidarsi troppo delle funzioni di monitoraggio poiché generalmente sono invalidate dalle latenze di comunicazione fra PLC ed editor.

Ho l'impressione di essere leggermente OT...

Ciao.

[Alessandro2151]

Devo dire che ho visto da voi che esistono dei Break point, potreste spiegarmi che cosa sono , ne ignoravo l'esistenza servono solo per la visualizzazione oppure sono istruzioni che aggiornano la periferia immediatamente?

Io nei GEFanuc ho una funzione chiamata DO_IO che mi può controllare , quando voglio in qualsiasi punto del programma , input solo , input e output, output solo, WORD e DWORD o sino a 5 moduli interi . non so cosa abbia il Siemens di diverso magari ha qualcosa in più è possibilissimo, ma ti posso garantire che io non ho problemi di attesa di una scansione per controllare cicli o avvenimenti molto rapidi ! Oltre a questo premetto che presto molta attenzione nella stesura del programma e nella configurazione hardware che mi permette di ottenere tempi di scansione della CPU molto buoni ! Lo so che è relativo alla dimensione del programma , ma anche con diversi moduli intelligenti e programmi molto lunghi ho sempre avuto dei buoni risultati e mai un problema di scansione ! Un esempio che ti posso fare ? Ho avuto un collega che in passato che si è preso la briga di remotare in Profibus una scheda 4 assi che da sola ciucciava alla CPU 40 ms senza un righa di ladder o IL scritto al suo interno !!! Allucinante ! ! ! Risultato ??? scablare la scheda e metterla vicino alla CPU........un'altra musica credimi ! ! !

Non so cosa usi come PLC ma sicuramente avrai qualcosa di simile anche nei tuoi

E comunque penso sia una cosa da analizzare macchina x macchina ,credo sia abbastanza impossibile generalizzare o almeno io non lo faccio mai , come già detto da Livio e altri chi parte bene finisce sempre bene ! ! !

Ciao alessandro2151

[Livio Orsini]

Per quanto riguarda la tua età , tu vorresti avere 20 anni meno ...........qualcuno ne vorrebbe avere 20 di più con la conseguente esperienzia che ne porterebbe ci hai mai pensato ?

Caro Alessandro2151, come disse, mi parema non sono certo, Bertrand Russel la gioventù è una malattia da cui purtroppo si guarisce. Quindi che vorrebbe essere più vecchio e più esperto deve solo avere un po' di pazienza... Io invece indietro non posso tornare.

La cosa che più mi preoccupa è che, nonostante l'uso di numerose faccine sorridenti, hai inteso il mio post molto seriamente. Mentre io ce l'ho messa tutta per tenermi sul faceto-scherzoso. Si vede che sto diventando pedante e professorale, che tristezza.

Piuttosto, scrivendo seriamente, credo di non essermi spiegato a sufficienza quando dico di dover fare contorsioni mentali per il ladder diagram.

In effetti la definizione "contorsioni mentali " è leggermente esagerata, volutamente, per significare il mio disagio nel leggere i contatti. Cerco di spiegarmi meglio.

Io, come tutti del resto, ho un mio metodo per approcciare le cose. Per esempio non uso i "flow chart", ma preferisco descrivere il flusso delle informazioni e gli stati della macchina attraverso descirzioni dettagliate.

Se vedo due contatti in parallelo non mi viene naturale pensare ad un "OR", rimangono due contatti in parallelo; non parliamo poi di quelle lunghe e belle catene di contatti in serie e parallelo.

Per me è molto più naturale descrivere il funzionamento scrivendo: "Se A e B sono veri o C è falso allora D è vero" che tradotto in ladder sarebbe "contatto NA A in serie al contatto NA B, il tutto parallelato dal contatto NC C, comanda la bobina D". Dalla descrizione alla lista istruzioni il passo è molto breve e molto indolore.

Io, quasi mai, mi metto alla tastiera ad introdurre istruzioni. Orima di immettere le istruzioni studio il problema e scrivo la traccia di come deve lavorare il programma. Ma questa è la penultima delle operazioni. In precedenza c'è stato tutto il lavoro di analisi e di suddivisione delle funzioni. Poi scrivo solo quelle funzioni che non ho in libreria e quel poco di software di connesseione. A qualcuno può sembrare una perdita di tempo, ma alla fine, quando si tirano le somme di tutte ore lavorate dall'acquisizione fino all'accettazione, ci si rende conto che è il metodo più veloce; senza contare la facilità di manutenzione.

C'è un'altra cosa che mi lascia perplesso. Qualcuno ha portato come esempio un bit che cambia di stato più volte durante il programma.

Non è una bella cosa. Anzi è una cosa che non deve accadere. Lo stato di una variabile deve essere univoco. Sarà il risultato della somma delle condizioni che ne determinano lo stato. Se si effettua un'analisi corretta, ed una corretta suddivisione delle funzioni, questo, variare lo stato più volte nel corso del programma, non avviene.

Forse, il fatto di programmare in ladder, facilita questo malaware (brutto neologismo).

Somo le classiche cose che creano problemi durante il debugger o, molto peggio, che in particolari condiziononi causano dei malfunzionamenti.

[STEU]

Caro Livio

che un bit non debba cambiare di stato piu' volte nel programma mi trova abbastanza daccordo con te, ma a volte esistono anche errori di battitura (M11.3 M13.1 quante volte errori simili!!!) e a questo punto non sai piu' cosa puo' succere al bit , e quando vedi un bit a 0 quando in realta' in quel punto del programma è a 1 trovare l'errore con una monitorizzazione errata dello stato della variabile diventa una cosa.... ardua.

[FranSys]

Forse, il fatto di programmare in ladder, facilita questo malaware (brutto neologismo).

No, invece è bellissimo e me lo sono segnato (mentalmente)!

Le alee all'interno del software non sono mai belle cose. Ma occorre distingure. Se il bit "flickerante" (questa è molto peggio di "malaware") è una variabile d'uscita o di stato è assolutamente sbagliato. Se è un flag (ad esempio "azione macchina eseguita, passa oltre") può andare bene.

Può anche essere impiegato più volte lo stesso bit all'interno del programma per funzioni diverse, a condizione che si abbia il controllo della situazione. Ad esempio, io utilizzo molte variabili temporanee per registrare lo stato del programma (o di un'istruzione) provvisoriamente. Se si tratta di un dato che dopo lo step successivo alla sua assegnazione non ha più alcun valore, non vedo per quale motivo dovrei "battezzarlo" come variabile dedicata e univoca... anche in Ladder. Questo è il tipico caso di tecniche mutuate da linguaggi di programmazione superiori.

che un bit non debba cambiare di stato piu' volte nel programma mi trova abbastanza daccordo con te, ma a volte esistono anche errori di battitura (M11.3 M13.1 quante volte errori simili!!!)

Steu, bisogna lavorare con i mnemonici e non con gli indirizzi assoluti! E limiti molto questo genere di errori. Oggi disponiamo di editor che accettano nomi di variabili molto lunghi e con minuscole e maiuscole (mi riferisco ai nomi veri e propri, oltre ovviamente ai commenti). Da tempo non etichetto più "FED_RUN" ma "FeederRunning" oppure "AlimentatoreInServizio"... e spesso mi risparmio anche il commento alla variabile.

Ciao.

[Livio Orsini]

...Ad esempio, io utilizzo molte variabili temporanee per registrare lo stato del programma ..

..Steu, bisogna lavorare con i mnemonici e non con gli indirizzi assoluti!..

Ho riunito le due citazioni perchè ritengo debbano essere collegate.

Usare varaibili temporanee in più funzioni è assolutamente corretto, purchè si rispettino alcune condizioni.

La prima è l'uso di un simbolo mnemonico, p.e.: temp_01, temp_02, etc. (che fantasia che ho), secondo che il volare che la variabile assume nella funzione venga usato nella funzione stessa, usciti dalla funzione il valore non deve avere più senso. In questo modo si emulano le variabili dinamiche o locali dei linguaggi ad alto livello. Nei PLC però io a questo scopo preferisco, quando è possibile, usare i registri come gli accumulatori.

Per i flags io sono di parere opposto. Io uso i flags esclusivamente come variabili statiche. Sono quasi trentanni che tutti i miei flags iniziano come Flg_xx, in questo modo si notano a prima vista. Sono esclusivamente booleani, anche quando il linguaggio (come il "C") non supporta l'uso di bit. Qundo il compilatore lo permette definisco anche VERO e FALSO per assegnare lo stato dei flags.

Nella mia filosofia i flags hanno un ruolo molto importante. Praticamente lavorano quasi come dei semafori per incanalare l'informazione sul sentiero voluto. Tanto è vero che dallo stato dei flags posso risalire al percorso dello stato della macchina.

[FranSys]

Per i flags io sono di parere opposto. Io uso i flags esclusivamente come variabili statiche.

Nella mia filosofia i flags hanno un ruolo molto importante. Praticamente lavorano quasi come dei semafori per incanalare l'informazione sul sentiero voluto. Tanto è vero che dallo stato dei flags posso risalire al percorso dello stato della macchina.

Siamo in sintonia. Solo che per questo tipo di gestione preferisco utilizzare i registri. Generalmente creo uno stack dove scrivo nella prima word il numero del processo corrente. Man mano che i vari processi si evolvono, faccio un word shift spingendo ("pushando" mi faceva schifo!) nello stack il numero del nuovo processo. In questo modo ho anch'io possibilità di risalire allo stato "storico" della macchina.

Insomma, come sempre possono esserci diversi approcci che conducono al medesimo risultato. Visto che siamo nel forum "PLC & Didattica", vorrei consigliare ai neofiti di utilizzare sempre lo stesso tipo di filosofia a prescindere dal tipo di macchina che si sta programmando. Questo facilita la portabilità - più crudamente il riciclaggio - del codice.

La mia ultima considerazione ne sottintende un'altra: se si abusa di funzioni particolari disponibili solo su certi tipi di macchine potrebbe essere difficile migrare il software su altre piattaforme. Un codice scritto utilizzando funzioni elementari quali MOVE, COPY, SHIFT, COMPARE e via discorrendo, potrà essere implementato su qualunque PLC o microprocessore con grande risparmio di tempo. Solo se l'applicazione è molto particolare e si prevede che non debba essere replicata è meglio ragionare in modo opposto, cercando di ridurre al massimo i tempi di sviluppo e usufruendo di tutte le facilitazioni che l'ambiente di programmazione mette a disposizione.

Ciao.

[STEU]

Steu, bisogna lavorare con i mnemonici e non con gli indirizzi assoluti

Ok potrei scrivere Step_01 anzichè Step_10

[Alessandro2151]

La cosa che più mi preoccupa è che, nonostante l'uso di numerose faccine sorridenti, hai inteso il mio post molto seriamente. Mentre io ce l'ho messa tutta per tenermi sul faceto-scherzoso. Si vede che sto diventando pedante e professorale, che tristezza.

No Livio ci mancherebbe altro ! L'unica cosa che ho preso seriamente è che magari ho detto qualcosa in un modo che ti è sembrato poco cortese , tutto qui .

Ma ora vedo che non è così , sai capita a volte di dire delle cose che potrebbero urtare involontariamente la persona con cui discuti , può succedere o almeno a me in passato è successo, a chi non è mai successo ?

Se me la prendessi non avrebbe + senso il mio girare su questo forum , anzi spero di avere ancora modo di scambiare opinioni e pareri con te .......c'è sempre sempre da imparare nella vita , sopprattutto in un lavoro come questo !

Ciao Alessendro2151

[wnc]

Ok potrei scrivere Step_01 anzichè Step_10

Ecco un buon esempio di scrittura mnemonica del tutto inutile.

[STEU]

Ecco un buon esempio di scrittura mnemonica del tutto inutile.

Caro wnc

evidentemente ti devo scrivere tutto

"stazione_1".step[01]

così va meglio e chiaramente nel commento c'è scritto cosa fa lo step_01.

Utilizzo le db e ci costruiamo dell udt magari con degli array anche per i passi di programma , i merker li abbiamo abbandonati da tempo.

Comunque un buon tecnico (prima ancora che programmatore) non giudica il lavoro degli altri sopratutto senza avere la piu' pallida idea di quali macchine si tratta e come sono programmate e senza sapere se i clienti sono contenti di come sono fatti i programmi.

La mia è solo una constatazione , non voglio entrare in polemica con te , spero che questo ti serva nella vita piu' che nel lavoro.

Ciao

[FranSys]

Steu, Wnc, non mettevi le dita negli occhi per così poco!

Ciao.

[Livio Orsini]

Comunque un buon tecnico (prima ancora che programmatore) non giudica il lavoro degli altri sopratutto senza avere la piu' pallida idea di quali macchine si tratta e come sono programmate e...

Io direi che è una regola indipendente dal lavoro, riguarda i rapporti interpersonali per tutte le occasioni e per ogni tipo di realzione.

Saltare alle conclusioni senza conoscere tutti i termini del problema è sempre errato. Ancor peggio se si giudica il lavoro altrui su dati molto parziali.

... senza sapere se i clienti sono contenti di come sono fatti i programmi.

Qui non sono in disaccordo. I cliento posono anche essere contentissimi, ma ciò non toglie che un lavoro mal fatto rimanga comunque e sempre mal fatto.

[wnc]

Il mio intento era solo quello di sottilineare che usare cosi il simbolismo, ossia non assegnare una descrizione significativa, non è il metodo da utilizzare.

"stazione_1".step[01]

Anche questa rischia di essere una descrizione non dettagliata, per uno che a posteriori deve riprendere il programma.

Non era certo mia intenzione dire che lavori male in quanto, primo non mi interessa, secondo non ti conosco nemmeno.

Utilizzo le db e ci costruiamo dell udt magari con degli array anche per i passi di programma , i merker li abbiamo abbandonati da tempo

peccato! I merker invece li ritengo utilissimi. A parer mio nei programmi spesso si cerca di rendere complicate le cose che in realta non lo necessitano. Tipica filosofia Siemens! Ah. Mi riferisco certo a te Steu se no te la prendi.

[wnc]

Mi riferisco certo a te Steu se no te la prendi

Correggere con

Non mi riferisco certo a te Steu, se no te la prendi. Errore di battitura!