Utilizzo Dell'ingresso "e" Nella Bobina Di Uscita

[Ecup]

per fabmatt:

Ognuno è libero di fare il programma come vuole, non siamo tutti uguali e quindi rispettare il modo di lavorare degli altri.

Verissimo, ma ciò non toglie che si siano dei modi "corretti" e dei modi "meno corretti". Quando ti trovi su un impianto con 1500 variabili tra ingressi e uscite (magari su un programma fatto a più mani), ti voglio vedere a capire che quell'ingresso particolare che stai cercando di capire perché non funziona non è realmente l'ingresso ma è l'ingresso negato o filtrato o spippolato in vario modo (fermo restando che personalmente on uso mai direttamente gli ingressi nel programma)

per Livio:

Anche nel caso di sensori, selettori che possono essere montati NO o NC, socondo una pessima abitudine degli elettrecisti ("tanto lo giri a software, per te è un attimo" )

Giusto... questa cosa mi fa ancora più imbestialire quando si parla di sicurezza: un contatto di sicurezza "deve" essere NC, perché se fosse NO, in caso di rottura filo io non potrei rilevare l'allarme

ciao

[elettricem]

Verissimo, ma ciò non toglie che si siano dei modi "corretti" e dei modi "meno corretti". Quando ti trovi su un impianto con 1500 variabili tra ingressi e uscite (magari su un programma fatto a più mani)

daccordo ma fino ad un certo punto e cioè

come fai a sapere le motivazioni dei modi corretti o meno che ci sono a monte?

sei sicuro che una persona che programmi in quel modo sia scorretto?

Non voglio giustificare nessuno, ma a volte ci sono situazioni e motivazioni a cui "noi"..non ne siamo a conoscenza.

a buon intenditor.....dagli un buon vino.

[ricki]

Ecup, anche a me fanno imbestialire quelli che per risparmiare 2 min di lavoro per girare un contatto , mi chiedono di farlo fare a me.... a quel punto prendo nella mano sx un cacciavite e nella dx un bastone ......

Livio pienamente d'accordo, il programma DEVE avere una logica ben precisa.... , altrimenti lo chiamerebbero porcaio..... e il fabmatt di turno ne paga le conseguenze..

... per il buon vino ci penserò nei prossimi giorni

Buon Natale

Ricki

[ifachsoftware]

il programma DEVE avere una logica ben precisa.... , altrimenti lo chiamerebbero porcaio.....

^^^^^

[Ecup]

come fai a sapere le motivazioni dei modi corretti o meno che ci sono a monte?

Se le motivazioni sono quelle discusse in questo thread, si può risolvere appoggiando gli ingressi a dei merker e facendo un lavoro più "pulito" senza il minimo rischio di inconveniente/incomprensione

sei sicuro che una persona che programmi in quel modo sia scorretto?

Si, ritengo che quel modo di programmare (ovvero invertire NO/NC e mettere filtri sovrascrivendo direttamente gli ingressi) sia scorretto... scrivere gli ingressi per la simulazione va benissimo, ma sull'impianto in funzione non lo trovo minimamente corretto; inoltre ti abitua ad una pratica che cambiando PLC non potrai più fare...

Chi non lo considera scorretto può continuare ad usarlo se lo ritiene opportuno (non è certo un problema mio), ma io non ci vedo alcun vantaggio

ciao

[dott.cicala]

A questo punto ci vorrebbe un sondaggio x verificare quanti sono pro e quanti contro la scrittura degli ingressi.

Io sono contro, come ho già detto.

Al limite se c'è solo la cpu sul banco e si vogliono far delle prove...e non si ha a disposizione PLCSIM...ma x quello che costa quest'ultimo, vale la pena investire.

[elettricem]

Chi non lo considera scorretto può continuare ad usarlo se lo ritiene opportuno (non è certo un problema mio), ma io non ci vedo alcun vantaggio

Sono daccordo con te, pure io non uso questa tecnica che trovo sconveniente, solo che non me la sento di accusare chi l'ha fatto anche perchè non conosco il motivo che l'ha indotto a farlo...naturalmente se è per pura pigrizia o inettitudine...

Buon Natale

[rddiego]

secondo me la discussione ha preso la piega sbagliata, nel senso che non si sta ragionando sul quesito iniziale ma su una cosa che per forza volete generalizzare.

Il quesito iniziale era quello di sapere il significato di certe istruzioni.... avete voluto interpretare subito queste istruzioni scorrette, inadeguate, e quant'altro ma in realtà non sappiamo niente dell'impianto a cui sono state applicate. Ecco perchè dico che ci sono molteplici modo di progrmmare e tutti plausibili e funzionali, perchè ogni impianto ha le sue problematiche.. L'istruzione presa così a sè stante può "irritare" alcuni ma bisogna comprendere da cosa nasce. Io "asetticamente" la vedo come un istruzione possibile e giustificabile se spiegata come dagli esempi di simone70. NON mi sembra giustificabile una tale discussione in quanto la si è estremizzata a tal punto che si sta "condannando" chi voglia sovrascrivere gli ingressi fisici di qualsivoglia impianto quando in realtà gli è conveniente. Ciascun programmatore sa bene quel che fa anche se talvolta con metodi poco ortodossi. Ribdisco ancora una volta che la discussione nasce da un dubbio riguardo alcune istruzioni diciamo inconsuete. A queste è stato ben risposto e nessuno può dire che sono risposte azzardate o scorrette. Si è voluto allargare il discorso a qualsiasi programma, a qualsiasi applicazione senza motivo. Come se ci fossero programmatori (l'anonimo da cui è scaturita la discussione) che scrvono gli ingressi senza motivazione alcuna o senza badare a difficoltà nel debug o quant'altro. La discussione dovrebbere vertere solo sulle istruzioni fornite senza indebitamente sfociare in inutili divagazioni su programmazioni corrette o meno. Altrimenti io e ciascuno di voi avrebbe da dire sulla maggior parte delle discussioni già affrontate fin ora nel forum. Io dico atteniamoci alla specifica discussione presentata, che risulta in ultima analisi più utile a tutti. Le istruzioni in discussione non sono sbagliate e l'utilizzo migliore che tutti noi possiamo consigliare a chiunque sono quelle date da OB1 e Simone70. Secondo me è quanto basta. Il resto mi vien da dire è discussione per il popolo che forse è di piccole vedute riguardo la programmazione e che ritiene che esistano regole imprescindibili come se esistessero dei codici di "programmazione". Il risultato è quello che conta. Tuttavia si può discutere sul raggiungimento di questo risultato proponendo eventualmente soluzioni più performanti, ma qui vedo solo grandi "NO" come se lo scopo da ottenere non fosse raggiunto. Molti (tra cui io stesso) propongono la copiatura su altre memorie degli ingressi fisici, ma non aggiungono nulla se non la comodità di gestire memorie diverse dalle immagini degli ingressi.

[Livio Orsini]

A questo punto ci vorrebbe un sondaggio x verificare quanti sono pro e quanti contro la scrittura degli ingressi.

Io sono contro, come ho già detto.

Qui non è una questione dove "la maggioranza governa"! La scienza non è democratica, e non è neanche un'opinione!

Esiste uno ed un solo modo corretto per programmare, gli altri sono sbagliati.

Dopo di chè uno può continuare a lavorare in modo approssimativo; di programmi che sono stati costruiti usando la mazzetta del muratore ne circolano, ahimè, troppi. Programmi che se devi fare anche una minima modifica all'impianto crollano come un castello di carte mal fatto.

Se ad un certo punto del programma modifico via software lo stato di un ingresso, eseguo una parte del programma secondo lo stato fisico ed un'altra parte con lo stato modificato. Già questa è una grave scorrettezza dal punto di vista formale. Notare che tutti i PLC di qualità almeno decente prevedono di leggere tutti gli ingressi e copiarne lo stato nel registro immagine. Questo perchè, independentemente dalla durata del programma e dalla posizione dell'utilizzo, si usi sempre il medesimo valore per ciascun ingresso. Se, e solo se, si vuole usare lo stato istantaneo di un ingresso si esegue una lettura dello stato fisico.

Apportando modifiche ad un programma che prevede l'amenità della modifica software di un ingresso fisico, si corre il rischio di avere sequenze falsate. Ad esempio nella terza rountine modifico lo stato fiscico di un finecorsa. In seguito si aggiunge un'altra routine che è condizionata dallo stato fisico di quel finecorsa, routine che viene lanciata dopo la modifica del valore fisico dell'ingresso. Ci sono alte probabilità che se l'aggiunta viene eseguita da un altro programmatore, lo stato sia considerato al contrario. ma anche se esguita dal medesimo programmatore, in epoca successiva alla prima stesura, le probabilità di errore sono comunque elevate.

Fare operazioni di questo tipo significa compromettere la qualità del software.

In software house molto professionali, dove esiste un controllo di qualità del software (ma ne esistono ancora di aziende simili? ), questa procedura verrebbe bocciata e l'estensore appeso per i pollici ad un pennone come esempio per i giovani programmatori

Modificato: 20 dicembre 2006 da Livio Orsini

[Simone70]

secondo me la discussione ha preso la piega sbagliata, nel senso che non si sta ragionando sul quesito iniziale ma su una cosa che per forza volete generalizzare.

Il quesito iniziale era quello di sapere il significato di certe istruzioni.... avete voluto interpretare subito queste istruzioni scorrette, inadeguate, e quant'altro ma in realtà non sappiamo niente dell'impianto a cui sono state applicate. Ecco perchè dico che ci sono molteplici modo di progrmmare e tutti plausibili e funzionali, perchè ogni impianto ha le sue problematiche.. L'istruzione presa così a sè stante può "irritare" alcuni ma bisogna comprendere da cosa nasce. Io "asetticamente" la vedo come un istruzione possibile e giustificabile se spiegata come dagli esempi di simone70. NON mi sembra giustificabile una tale discussione in quanto la si è estremizzata a tal punto che si sta "condannando" chi voglia sovrascrivere gli ingressi fisici di qualsivoglia impianto quando in realtà gli è conveniente. Ciascun programmatore sa bene quel che fa anche se talvolta con metodi poco ortodossi. Ribdisco ancora una volta che la discussione nasce da un dubbio riguardo alcune istruzioni diciamo inconsuete. A queste è stato ben risposto e nessuno può dire che sono risposte azzardate o scorrette. Si è voluto allargare il discorso a qualsiasi programma, a qualsiasi applicazione senza motivo. Come se ci fossero programmatori (l'anonimo da cui è scaturita la discussione) che scrvono gli ingressi senza motivazione alcuna o senza badare a difficoltà nel debug o quant'altro. La discussione dovrebbere vertere solo sulle istruzioni fornite senza indebitamente sfociare in inutili divagazioni su programmazioni corrette o meno. Altrimenti io e ciascuno di voi avrebbe da dire sulla maggior parte delle discussioni già affrontate fin ora nel forum. Io dico atteniamoci alla specifica discussione presentata, che risulta in ultima analisi più utile a tutti. Le istruzioni in discussione non sono sbagliate e l'utilizzo migliore che tutti noi possiamo consigliare a chiunque sono quelle date da OB1 e Simone70. Secondo me è quanto basta. Il resto mi vien da dire è discussione per il popolo che forse è di piccole vedute riguardo la programmazione e che ritiene che esistano regole imprescindibili come se esistessero dei codici di "programmazione". Il risultato è quello che conta. Tuttavia si può discutere sul raggiungimento di questo risultato proponendo eventualmente soluzioni più performanti, ma qui vedo solo grandi "NO" come se lo scopo da ottenere non fosse raggiunto. Molti (tra cui io stesso) propongono la copiatura su altre memorie degli ingressi fisici, ma non aggiungono nulla se non la comodità di gestire memorie diverse dalle immagini degli ingressi

[elettricem]

Livio non me ne volere ma sono anch'io daccordo in toto con rddiego.

[Livio Orsini]

Elettricem, non te ne voglio: non sei ne un mio collaboratore ne un mio fornitore. Pensala come vuoi però il tuo non è un buon modo programmare.

Io da un mio collaboratore non lo avrei accettato e tantomeno lo accetterei da un fornitore.

Poi ripeto di programmi malfatti ce ne sono in circolazione tanti, anzi troppi.

Qui non si condanna chi sovrascrive gli ingressi, si condanna chi programma male. E' OT? Non direi. L'argomento iniziale della discussione era proprio una richiesta di spiegazione sulle ragioni di sovrascrittura di un ingresso.

Tra l'altro, escludendo il momento relativo al debugging del software, la sovrascrittura di un ingresso non ha alcuna ragione d'essere.

Anche il filtro anti rimbalzo, ad esmepio, lo implementa più efficacemente senza sovrascrittura dell'ingresso.

Modificato: 20 dicembre 2006 da Livio Orsini

[ricki]

Caro rddiego , non te la prendere , io penso con un forum sia fatto per discutere , criticare , migliorare tanti aspetti rigurdandanti , in questo caso , l'automazione. Anche se la questione iniziale era "A" e il discorso si è modificato in "A+1" ,cosa importa , ognuno ha espresso la propria opinione e altri che leggono hanno modo di riflettere sul fatto o sul da farsi. Come dice Livio non siamo OT e ha pienamente ragione a spingere in una data direzione . Probabilmente anche lui come me , e tanti altri, hanno trovato delle difficoltà nel sistemare delle tegolate che gli sono capitate sulla scrivania (a volte provocate da programmatori con meno esperienza). Questo non significa che il software del collega non è "bello" o non "piace", ma perchè non è stato sviluppato pensando a chi poi dovrà metterci mano....

Comunque Livio 100% ragione e secondo me , questa discussione torna utilissima per i giovani programmatori con poca esperienza sul campo.

Ciao a tutti e buon Natale

Ricki

[dott.cicala]

Credo anche io nel forum quale possibilità di confronto, scambio di idee, opportunità di crescita.

E' bello anche, a volte, poter essere d'aiuto. Purtroppo, caro Livio, il fine giustifica i mezzi, anche se sono pienamente d'accordo con te.

Proponevo il sondaggio non per stabilire democraticamente quale metodo sia ritenuto corretto dalla maggioranza, ma al fine di conoscere quanti sono soliti usare questo metodo improprio. Non è utile? Pazienza.

Mi trovo spesso, nel mio ambito lavorativo, a dovermi scontrare con chi agisce impropriamente che si barrica dietro un "però funziona".

Ritengo inoltre che lo scopo della discussione non si debba esaurire in "fai così, fai cosà" altrimenti si perderebbe l'occasione di approfondire.

Buon Natale a tutti

[batta]

Sono anch'io fondamentalmente d'accordo con Livio, anche se non così drastico.

Come già detto, io utilizzo la scrittura degli ingressi in fase di debug, per simulare segnali di feedback dal campo quando il campo non c'è. Poi rimuovo tutto.

Farlo per abitudine lo considero sbagliato.

Se dovessi però trovare scritture di ingressi utilizzate non solo per il debug, magari correttamente messe all'inizio del programma per evitare di leggere stati diversi durante la medesima scansione e, soprattutto, con descritte le motivazioni di tale scelta, bè, ci vuole ben altro perché mi metta ad urlare "allo scandalo".

Insomma, non condivido la scelta se usata come metodo, ma sono altre le cose che trasformano un buon programma in un porcaio.

[ricki]

Ok Batta, ma il porcaio indica il programma del caro Fabmatt il quale afferma : "Questa è una delle tante righe che trovo nel programma, cosa significa? ".

Un'altra mia domanda è : ma su impianti mediamente complessi ( 200 i/o) quanto sarà mai la % di programma che puoi debuggare in ufficio o solo davanti al quadro elettrico ? 5-10% , solo l'interfaccia HMI verso il PLC, concludendo la mia opinione è che tempo sprecato debuggare un programma plc che contiene una ciclica di attuatori .... a voi la vostra.

Per Livio , se sono OT aprirò un'altro Topic.

Ciao

Ricki

[Ecup]

A questo punto ci vorrebbe un sondaggio x verificare quanti sono pro e quanti contro la scrittura degli ingressi

non ne vedo l'utilità... il sondaggio potrà avere qualsiasi risvolto, ma per me rimane una tecnica di programmazione errata e non la userò mai...

per rddiego:

secondo me la discussione ha preso la piega sbagliata, nel senso che non si sta ragionando sul quesito iniziale ma su una cosa che per forza volete generalizzare.

siamo su un forum: la discussione "evolve"... è normale... il questito iniziale ha comunque trovato immediate risposte, e la discussione è pertinente all'argomento

Il quesito iniziale era quello di sapere il significato di certe istruzioni.... avete voluto interpretare subito queste istruzioni scorrette, inadeguate, e quant'altro ma in realtà non sappiamo niente dell'impianto a cui sono state applicate. Ecco perchè dico che ci sono molteplici modo di progrmmare e tutti plausibili e funzionali, perchè ogni impianto ha le sue problematiche

Qualunque sia l'impianto e le relative problematiche, questo modo di programmare (IMHO) è errato... sarà ugualmente funzionale, sarà più veloce, sarà tutto quello che vuoi, ma non è corretto, anche se magari chi l'ha scritto è un mezzo genio che in pochi giorni ti programma impianti da 1000 I/O...

Le motivazioni che possono portare a scrivere istruzioni di quel tipo le abbiamo già elencate, ed è evidente a tutti che si può ottenere lo stesso risultato (filtri, NO<->NC) appoggiando gli ingressi a dei merker; i merker possono avere qualsiasi significato gli si voglia attribuire, ma la stessa cosa non dovrebbe valere per gli ingressi, che per l'appunto dovrebbero rappresentare lo stato fisico degli ingressi (guardacaso non è possibile fare la stessa cosa su altri PLC).

Va benissimo scrivere gli ingressi in una simulazione a banco (lo faccio anch'io, anche se lo faccio con i merker ai quali ho appoggiato gli ingressi), ma non è concepibile trovare simili istruzioni in una macchina o un impianto in funzione.

[Simone70]

Dico la mia poi chiudo il discorso: secondo me generalizzare troppo non fa bene alla discussione, bisogna sempre analizzare le singole applicazioni. Sono d'accordo con Livio quando dice che cambiare lo stato dell'ingresso durante il ciclo del programma non è corretto. Tuttavia mi è capitato di fare qualche filto di un ingresso creando un blocco chiamato "Modifica immagine di processo" ed elaborato all'inizio del programma in modo che lo stato dell'ingresso rimaneva lo stesso per tutto il ciclo. Devo dire che non sarà il massimo della bellezza ma non lo trovo poi una cosa così abominevole.

Ho sentito parlare di sicurezze che vengono invertite SW; bhe secondo me se si è in grado di fare una cosa del genere, c'è una carenza sulla progettazione, visto che la sicurezza prima che SW deve sempre essere a livello superiore.

[batta]

Posso rispondere con un esempio pratico, descrivendo uno degli ultimi impianti avviati.

- CPU S7-315 2DP: 272 DI/DO, 16 AI, 2 AO, scambio dati globali con cpu 314C e scambio dati con altro impianto tramite accoppiatore DP/DP, scada con quasi mille variabili scambiate col plc. Dimensione programma circa 70k.

Aggiungendo un blocco che simulava la risposta dei finecorsa delle valvole, i segnali dai teleruttori e le risposte degli inverter, è stato possibile testare il funzionamento del programma direi oltre il 90%.

In fase di avviamento sono rimaste da fare regolazioni dei PID (temperature e pressioni), alcune modifiche per eliminare colpi d'ariete che si verificavano in alcune fasi, e non molte altre cose.

Passando al funzionamento sull'impianto si è cancellato il richiamo al blocco si simulazione, ed ora non viene effettuata nessuna scrittura dello stato degli ingressi. Per il debug in ufficio è stato non di semplice aiuto, ma fondamentale.

[Ecup]

Batta, siamo tutti d'accordo che questa cosa va benissimo per simulare... ma solo per simulare

per simone70:

mi è capitato di fare qualche filto di un ingresso creando un blocco chiamato "Modifica immagine di processo" ed elaborato all'inizio del programma in modo che lo stato dell'ingresso rimaneva lo stesso per tutto il ciclo

Il problema non è (solo) che rimanga uguale per tutto il ciclo, ma che una persona che si trova ad esaminare una parte di programma dove è richiamato l'ingresso, non sa qual'è l'effettivo stato dell'ingresso (neanche se si mettesse ad utilizzare la tabella delle variabili).

Non ottenevi lo stesso risultato (più corretto) se invece di fare un blocco "Modifica immagine di processo", facevi un blocco "Mappatura Ingressi su Merker"?

[Simone70]

Non ottenevi lo stesso risultato (più corretto) se invece di fare un blocco "Modifica immagine di processo", facevi un blocco "Mappatura Ingressi su Merker"?

No perchè avrei dovuto sostituire su tutto il programma l'ingresso con il merker.

[Ecup]

No perchè avrei dovuto sostituire su tutto il programma l'ingresso con il merker.

Rigirandoti la frittata potrei dirti che se avevi un altro PLC avresti comunque dovuto fare questo lavoro...

Ma vorrei puntualizzare che ho parlato di "risultato", non di lavoro in più da fare, e che l'argomento della discussione è la correttezza di programmazione, non la via più corta per fare una certa cosa

In ogni caso non avresti avuto alcun lavoro extra se iniziavi a scrivere il programma pensando a questa eventualità, e questo è un'altro dei motivi che mi portano a fare sempre una mappatura su merker di ingressi e uscite; lavoro in più? Forse... ma sicuramente più "pulito" e più facilmente "riciclabile" (quindi più breve la volta succesiva)

Anche mettere tutti i tempi macchina fissi (o parametri di funzionamento) accorcia i tempi di lavoro rispetto a metterli personalizzabili in una pagina del pannello operatore (o supervisore, o SCADA che sia), ma quale delle due cose ti sembra un lavoro fatto meglio?

Anche l'elettricista se ha cablato un contatto al contrario ci mette meno a dirti di girare il contatto piuttosto che mettersi lui a girarlo; ma se per un lavoro fatto bene serve che il contatto sia in un certo modo (sicurezze), è giusto che sia lui a fare il lavoro...

[Livio Orsini]

Proponevo il sondaggio non per stabilire democraticamente quale metodo sia ritenuto corretto dalla maggioranza, ma al fine di conoscere quanti sono soliti usare questo metodo improprio.

Scusa dott.cicala avevo mal interpretata la tua proposta. Comunque, indirettamente, i patecipanti a questa descrizione hanno risposto a questo sondaggio.

Vorrei fare una specie di riassunto e chiarire il mio concetto base.

Si individuano tre linee di comportamento:

1 - Chi, come me, è drastico: il metodo di modificare via software lo stato fisico di un ingresso non deve essere fatto mai; se è per fini di test può essere impiegato ma non deve essere operativo nel modo normale

2 - Chi ammette la modifica dello stato fisico ma solo se fatto all'inizio di programma e solo se chiaramente documentato

3 - Chi invece modifca tranquillamente lo stato fisico secondo il bosogno del momento.

Io ho un comportamento pragmatico, specie per i problemi di lavoro. Come ebbe ad affermare un noto statista cinese "non importa se un gatto è bianco o nero, l'importante è che acchiappi i topi!". Però ci sono situazioni dove non si può essere pragmatici ma ci si deve attenere a principii fondamentali, essere quasi manichei.

Ad esempio un individuo è onesto solo se agisce sempre onestamente, non perchè non è stato ancora scoperto!

Io sono convinto che la progettazione va affrontata con pragmatismo nella tattica, ma è indispensabile che la strategia sia improntata di assolutismo. In altri termini esiste uno ed un solo metodo corretto di progettazione.

Venendo al quesito iniziale della discussione.

fabmatt chiedeva:

U E5.0

U T1

= E5.0

Questa è una delle tante righe che trovo nel programma, cosa significa? Come fa ad utilizzare un ingresso come uscita?

Dalla domanda si deduce che:

1 - l'istruzione in criminata è usata più volte

2 - che lìistruzione incriminata non è commentata (altrimenti non avrebbe chiesto lumi)

Inoltre si arguisce che fabmatt non ha molta esperienza-conoscenza di programmazione (almeno per Step7) altrimenti non avrebbe necessità di chiedere lumi.

Io ritengo che oltre a dare una risposta che spieghi la funzione sia anche corretto descrivere le controindicazioni, se ce ne sono. Inoltre trattandosi di problematiche di programmazione è utile dare delle linee guida generali.Che poi si discuta più su queste linee guida che sul quesito in se stesso è abbastanza logico. La risposta promaria si può dare in 4 righe. Ben altre però sono le implicazioni di buona programmazione.

Io forse sarò donchisciottesco, ma è da quando ho iniziato a programmare professionalemte che mi batto per migliorare il mio e l'altrui modo di programmare.

Forse sarà stato per costrizione (ho imparato su una P101 primo computer personale, anni '60-'70, produttore Olivetti) ma la struttura del programma l'ho sempre ritenuta fondamentale per la comprensibilità, la portabilità e la manutenibilità del programma; in altri termini per la sua qualità.

Purtroppo, nonostante tutte le aziende vantino certificazioni ISO 9xxx, la qaulità dei prodotti di automazione sembra peggiorare ed il software ancora di più.

Le scuse del tipo: la pagnotta da portare a casa, il tempo che manca et similia non reggono. A mio parere c'è troppo pressapochismo, improvvisazione e mancanza di cultura di base. Troppi si improvvisano programmatori senza conoscere bene quello che stanno facendo. I risultati sono software eseguitti come certi cablaggi: provi ad aprire la canalina ed i cavi ti schizzano in faccia come un "misirizzi" d'altri tempi.

Forse sarà perchè ci spero, ma ho l'impressione che un quest'ultimo tirmenstre, almeno nella mia zona, la derivata si stia invertendo. Stanno sparendo certe quadristi e le aziende committenti sembra non sonsiderino più solo prezzo e tempo di consegna, ma anche qualità ed affidabilità. Che sia arrivato il vento di una nuova primavera?

[Simone70]

Rigirandoti la frittata potrei dirti che se avevi un altro PLC avresti comunque dovuto fare questo lavoro...

Io lavoro solo con Siemens quindi il problema non sussiste. Rigirandoti la frittata ancora ti dico che il tuo metodo non mi piace proprio, ma ripeto, è un parere personalissimo. e non penso assolutamente che devi cambiarlo. Per me è molto meno leggibile andare a leggere un programma dove invece di trovare Ingressi trovo solo memorie. Immagina se per qualche motivo (capita spessismo) non si ha a disposizione la documentazione che indica la mappatura.

[ricki]

Sarà la primavera , ma secondo me, la gente ha capito che "chi meno spende , piu spende". Poi se spendi ora x ore in piu in progettazione e collaudo in sede, risparmi 3x dal cliente ...

Ciao

Ricki