Riparare Una Scheda Uscite S5 6Es5441-8Ma11

[anto_next]

Hola

stamattina da un cliente ho sostituito l'ultima scheda uscite per S5 disponibile, siccome il guasto che ha avuto è la rottura di uno dei transistor di uscita ( il carico a cui era collegata è andato in corto ), vorrei sostituirlo, il problema è che non sono riuscito a capire che transistor sia, il codice è T426, mentre su quella che ho montato i transistor sono marcati T320 ( o T328 non sono riuscito a vedere bene )

Grazie a chi mi potrà aiutare

Anto

[busanela]

vorrei sostituirlo, il problema è che non sono riuscito a capire che transistor sia, il codice è T426

E' un FET a canale N: googla ST426S.

[batta]

Capisco che, al momento, la riparazione della scheda sia la strada più veloce ed economica, ma penso sia il caso di proporre al cliente la sostituzione di tutto il plc.

Sarà perché io detesto gli S5 (che considero tra i peggiori plc mai esistiti) ma, ogni volta che mi trovo ad operare su questo plc non perdo l'occasione di proporre un passaggio ad S7.

E questo non per interesse personale, ma perché gli S5 sono poco affidabili e perché i ricambi sono oramai difficili da reperire e, comunque, a caro prezzo.

Piuttosto che rischiare un lungo ed improvviso fermo macchina, penso sia conveniente (per il cliente) programmare il fermo macchina per passare ad un plc di due ordini di grandezza più affidabile e molto più facile da gestire.

[anto_next]

Grazie per le info, provo a sostituire il Mos Fet.

Siccome è una macchina molto semplice ( pressa con 8 In e 8 Out ) nel caso sostituirei il PLC con un S1200.

ciao

Anto

[busanela]

Non ci sono dubbi sul fatto che ormai la serie 5 ha fatto il suo tempo, che la tecnologia ha avuto enormi evoluzioni sia in termini di velocità di elaborazione che di miniaturizzazione e di versatilità, ma sono convinto che la soddisfazione di un cliente che vede ripartire la propria macchina, per quanto equipaggiata con dispositivi obsoleti, con un costo relativamente basso specie in un periodo di recessione come quella che stiamo industrialmente vivendo oggi, non può che portare, all'azienda che rappresentiamo, degli indubbi vantaggi sotto il profilo della professionalità, in un epoca in cui "buttare è meglio che riparare". Avere il servizio di un buon tecnico che leva le classiche castagne dal fuoco al cliente, gli permette sicuramente di dormire sonni tranquilli.

Piuttosto che programmare un intervento per sostituire il plc, sarebbe meglio consigliare tale intervento per modificare l'impianto elettrico e per interporre delle adeguate protezioni tra le uscite ed il carico che, in caso di corto come quello che ha causato la rottura dell'uscita, porterebbero comunque al fermo linea anche se avesse avuto un 400 a bordo.

Sarà perché io detesto gli S5 (che considero tra i peggiori plc mai esistiti) ma, ogni volta che mi trovo ad operare su questo plc non perdo l'occasione di proporre un passaggio ad S7.

Flavio, ma che ti hanno fatto gli S5? Ti hanno morso quando eri piccolo?

Avevano senz'altro dei grandi difetti, ma in termini di affidabilità, almeno per quei tempi, io invece sono convinto non avessero molti concorrenti. Posso concordare che l'ambiente di sviluppo del software e di debug non fosse il più intuitivo del mondo, ma del resto, in un periodo precedente a Windows pochi lo erano; se invece ci avessi lavorato sopra qualche tempo, come purtroppo o per fortuna è capitato a me, forse avresti apprezzato un pò di più anche questo aspetto, che alla fine non è proprio così brutto come lo si dipinge.

Modificato: 14 giugno 2012 da busanela

[Lucky67]

ma del resto, in un periodo precedente a Windows pochi lo erano

Mica vero...bastava vedere come si programmavano i texas instruments serie 300 e 400 per vedere come si poteva fare un buon prodotto anche pre windows (anzi forse windows ha peggiorato le cose)...

Io considero ancora adesso quelle serie di plc una delle più azzeccate di quegli anni...

[batta]

Piuttosto che programmare un intervento per sostituire il plc, sarebbe meglio consigliare tale intervento per modificare l'impianto elettrico e per interporre delle adeguate protezioni tra le uscite ed il carico che, in caso di corto come quello che ha causato la rottura dell'uscita, porterebbero comunque al fermo linea anche se avesse avuto un 400 a bordo.

Non sono d'accordo.

L'intervento di cui parli potrebbe anche essere più complicato del previsto (da valutare in primis se c'è spazio nel quadro), potrebbe costare non molto meno di una sostituzione completa, e ti rimane sempre un impianto con un vecchio osso pronto a lasciarti a piedi in qualsiasi momento.

Sono d'accordo con Lucky67.

Ho avuto modo di utilizzare e di conoscere a fondo i Texas serie 500-505 (gli attuali Simatic TI), e il confronto con gli S5, a mio avviso, non è nemmeno proponibile.

Chi ha lavorato con S5 sa che lasciare un PLC senza eprom significava, in modo matematico, prima o dopo dover intervenire per ricaricare un programma corrotto (non sto parlando di perdita di programma per batteria tampone scarica).

Gli zoccoli della serie 95 hanno dato dispiaceri a tutti.

E questo solo per fare due semplici esempi.

Tutti problemi che, all'epoca (lavoravo principalmente con Texas ma anche con Telemecanique, GE, Omron), per quanto riguarda la mia esperienza personale, erano completamente sconosciuti agli altri plc.

Tanto per dire, mi è capitato che, per errore di cablaggio, su due ingressi di un 115 arrivasse la tensione sbagliata (110Vac al posto di 24Vdc). Dopo qualche ora il modulo ha letteralmente preso fuoco, con fiamme di 20 cm.

Neanche a farlo apposta, lo stesso errore era stato fatto anche su un impianto con un Texas 505. Dopo un paio di giorni gli ingressi non funzionavano più. Ho sfilato il modulo dal rack, cambiato due resistenze e ripartito.

Tornando in tema, sono pienamente d'accordo sul fatto che riparare il modulo sia la soluzione migliore per ripartire rapidamente.

Ma lasciare un S5 su un impianto, a mio avviso, significa cercare grane. Ora si è guastata un'uscita. E domani???

Quindi, recessione o no, tenere un prodotto inaffidabile significa rischiare di rimanere improvvisamente fermi, magari proprio quando hai assoluto bisogno di produrre.

Che costo avrebbe un fermo macchina nel momento sbagliato?

Non è meglio programmare l'intervento e ripartire con un impianto affidabile?

[busanela]

Se il punto focale della discussione si concentra sull'esperienza di anto_next, mi sembra esagerato voler sostituire tutto un controllo perchè in seguito ad un corto circuito si è bruciata un'uscita: non si sta parlando di invecchiamento dei componenti, ma di un evento di guasto tra i più critici e che sottopone a stress elevato qualunque tipo di componente elettronico, oggi come 20 anni fa. Se il dubbio è

Ora si è guastata un'uscita. E domani???

per colpa di un corto, a me hanno insegnato che domani il corto non deve più guastare l'uscita, non upgradare il PLC!

Da quando è stato introdotto nel mercato circa trent’anni fa SIMATIC S5 è diventato uno standard internazionale nell’industria di processo e nell’automazione della produzione e può contare su una base installata estremamente ampia: da più di 30 anni i controllori programmabili Siemens SIMATIC S5 hanno trovato applicazione in tutto il mondo e nei più svariati settori, dalle piccole automazioni ai più sofisticati controlli di processo, tanto da essere diventato punto di riferimento per TUTTI i sistemi programmabili. Se alla fine fosse davvero così inaffidabile come si enuncia, non vedo il motivo del successo di Siemes od almeno della sua diffusione. personalmente ho visto sistemi S5 lavorare praticamente allagati da olio idraulico in vecchie presse Kolmag Colombo o Carozzauto, coperti da polverino di segatura di mdf o trucioli di alluminio senza aver il benchè minimo problema, così come ho visto vecchie serie Telemecanique essere più tempo fermi per la manutenzione che al lavoro, ma queste sono tutte eccezioni che confermano le regole e lasciano comunque il tempo che trovano.

Tornando al caso in esame, che è quello che ci interessa, mi sembra di voler cambiare tutte le gomme della propria macchina perchè a causa di un chiodo ne abbiamo forata una.

L'intervento di cui parli potrebbe anche essere più complicato del previsto (da valutare in primis se c'è spazio nel quadro), potrebbe costare non molto meno di una sostituzione completa, e ti rimane sempre un impianto con un vecchio osso pronto a lasciarti a piedi in qualsiasi momento.

Ma anche no.

Se l'impianto del quadro elettrico è fatto "a regola d'arte" e Siemens nei manuali dei suoi PLC mette anche delle chiare indicazioni a riguardo, così come vuole la mentalità teutonica, il PLC lavora SEMPRE, o quasi. L'inserimento di un magnetotermico a protezione dell'alimentazione dei moduli d'uscita o ancora più semplicemente, dei morsetti dotati di minifusibile (dimensionato adeguatamente, ovviamente), per esempio, interposti tra uscita e carico non occupano praticamente spazio e costano una sciocchezza, anche in termini di tempo necessario alla modifica. Ribadisco che comunque un impianto automatico non è comunque affidabile se monta un processore dell'ultima generazione ma ha un quadro elettrico fatto con i piedi.

Mica vero...bastava vedere come si programmavano i texas instruments serie 300 e 400 per vedere come si poteva fare un buon prodotto anche pre windows

Infatti io, pur non avendo lavorato con TI in quei tempi, ho scritto "pochi lo erano". Purtroppo, comunque, se si voleva lavorare con Siemens bisognava fare i conti con Step 5 ed oggi, col senno del poi, mi ritengo fortunato di far parte di questa "elite", al punto di essere un chiaro riferimento per quei "poveracci" ( a questo punto) che non hanno la possibilità di spendere quei 8-10.000 euro tra PLC e adattamento software per aggiornare magari la seminatrice automatica della floricultura od il forno a piani della falegnameria, magari anche con parte della forza lavoro in cassa!

[Livio Orsini]

Ribadisco che comunque un impianto automatico non è comunque affidabile se monta un processore dell'ultima generazione ma ha un quadro elettrico fatto con i piedi.

:thumb_yello:

[batta]

per colpa di un corto, a me hanno insegnato che domani il corto non deve più guastare l'uscita, non upgradare il PLC!

La questione non è il corto, ma il fatto che io considero gli S5 estremamente inaffidabili.

Sarà un caso, ma quando vengo chiamato per problemi hardware su plc, 9 volte su 10 si tratta di S5.

Inoltre credo sia inutile specificare che una eventuale sostituzione del plc non si limiterebbe al cambio dell'hardware, ma anche ad un aggiustamento generale di tutto il quadro.

Io credo sia doveroso far presente al cliente che, ora, si è trattato di un guasto banale risolvibile velocemente e con spesa irrisoria.

Se domani il guasto fosse di altra entità, c'è da mettere in conto la possibilità di un lungo fermo macchina per la difficile reperibilità dei ricambi.

Sarà poi il cliente a decidere se continuare a lavorare con una macchina a rischio, o se affrontare la spesa di un revamping serio per trovarsi con una macchina affidabile.

Tutto dipende dall'importanza di quella macchina per la produttività dell'azienda, e dal costo di un eventuale fermo macchina.

Anche nel caso specifico, non dimentichiamo che, se il modulo fosse stato da sostituire, i tempi di consegna per questo materiale sono... a discrezione di Siemens.

Un modulo analogo di un S7-300 lo trovi disponibile dal tuo rivenditore, o comunque reperibile in tempi brevi.

[Lucky67]

tanto da essere diventato punto di riferimento per TUTTI i sistemi programmabili

Tanto riferimento che per il suo S7 200 ha praticamente "requisito" il know how della texas acquistando il ramo d'azienda. A volte lo standard, purtroppo lo stabilisce non la qualità del prodotto bensì la potenza commerciale di chi c'è alle spalle. Questo naturalmente a mio modesto modo di vedere e senza voler a tutti i costi scatenare la solita guerra anti siemens...

[Livio Orsini]

Tanto riferimento che per il suo S7 200 ha praticamente "requisito" il know how della texas acquistando il ramo d'azienda.

La versione originale era praticamente T.I., compreso il software di sviluppo sotto DOS. Anche le prime versioni di microwin erano ancora molto pratiche e risentivano della pragmaticità dei prodotti TI.

Poi ian piano sono riusciti a peggiorarlo notevolmente inserendo continui UCAS.

Lo S7 300 lo hanno sviluppato partendo dal kow how acquisito da TI, però han cominciato da subito ad appesantire le cose, specialmente per la parte software.

Fortunatamente da qausi dieci anni dei PLC me ne occupo e preoccupo sempre meno.

Modificato: 16 giugno 2012 da Livio Orsini

[batta]

Lo S7 300 lo hanno sviluppato partendo dal kow how acquisito da TI, però han cominciato da subito ad appesantire le cose, specialmente per la parte software.

Di questo io non sono tanto sicuro.

Probabilmente c'è stata la mano TI, ma i punti di partenza, come concetti base di programmazione, sono rimasti quelli dell'S5.

E, per quanto io detesti gli S5, il fatto di programmare utilizzando OB, FC, FB e DB è senza dubbio una marcia in più rispetto alla concorrenza.

Col passaggio da Step5 a Step7 è stato fatto un gigantesco passo avanti.

E lo stesso gigantesco passo avanti è stato fatto anche, col passaggio da S5 a S7, sul fronte dell'affidabilità.

In oltre 15 anni che lavoro con S7, di guasti hardware io me ne ricordo solo due.

Dalla nascita di Step7 ad oggi poi (io uso Step7 dalla versione 2.1), io non vedo nessuna complicazione. Il software è sempre rimasto fedele a sé stesso (conservando, purtroppo, anche il difetto della pesantezza), e le evoluzioni hanno portato solo miglioramenti, e non complicazioni.

Se vogliamo parlare invece di un software di sviluppo che, almeno per ora, proprio non mi convince, dobbiamo tirare in ballo il TIA Portal che, ironia della sorte, è stato sviluppato da un team americano.

Il luogo "comune americani = cose semplici e funzionali --- tedeschi = cose complicate" è e rimane solo un luogo comune.

[Livio Orsini]

Probabilmente c'è stata la mano TI, ma i punti di partenza, come concetti base di programmazione, sono rimasti quelli dell'S5.

Lo Hw è di derivazione prettamente TI, mentre la parte software, purtroppo dico io, è l'evoluzione S5.

Ognuno ha i suoi gusti ed a nulla serve discuterne. Tu consideri OB, FC, FB e DB una marcia in più, per me è solo un'utile complicazione con uso di termini che nulla hanno a che vedere con la programamzione classica, infatti si trova qualche cosa di simile solo in alcuni PLC di scuola tedesca.

Il luogo "comune americani = cose semplici e funzionali --- tedeschi = cose complicate" è e rimane solo un luogo comune.

Su questo posso essere daccordo. Ho avuto esperienze con prodotti tedeschi pratici e funzionali, non Siemens ovviamente, e con prodotti americani farraginosi e complicati inutilmente (RS Logic per esempio a me non piace).

Siemes comunque è un'ottima dimostrazione di come si possano implementare UCAS ad ogni piè sospinto.

[busanela]

E, per quanto io detesti gli S5, il fatto di programmare utilizzando OB, FC, FB e DB è senza dubbio una marcia in più rispetto alla concorrenza

Tu consideri OB, FC, FB e DB una marcia in più, per me è solo un'utile complicazione con uso di termini che nulla hanno a che vedere con la programamzione classica, infatti si trova qualche cosa di simile solo in alcuni PLC di scuola tedesca

Alla fine l'utilizzo di sottoprogrammi logici di tipo organizzativo, i vari blocchi Siemens per esempio, non sono altro che l'applicazione dello schema mentale che guida la razionalizzazione tedesca, applicata alla programmazione di logiche programmabili: si possono amare od odiare, ma loro hanno proceduto così e procederanno sempre così, è nella loro indole.

Col passaggio da Step5 a Step7 è stato fatto un gigantesco passo avanti.

E lo stesso gigantesco passo avanti è stato fatto anche, col passaggio da S5 a S7, sul fronte dell'affidabilità.

Mi sembra che tempo fa se n'era già parlato: è la naturale evoluzione della tecnologia. Ho cominciato la programmazione con l'assembler dello Z80 (sicuramente sia tu che Livio lo ricorderete); poi si è passati al 6502 e non vi dico la differenza in velocità ed affidabilità; si è passati dal 6510, altro passo in avanti, per piombare nello Step 5, un'altro pianeta sia come comodità d'uso che versatilità e funzionalità, sino ad arrivare finalmente ai giorni nostri con Step 7 ed il futuro TIA.

Tutto questo per dire che è giusto che sia così, che si vada avanti senza fossilizzarci, ma che comunque non bisogna dimenticare come è successo, non "rinnegare" cioè i vari step (è il caso di dire) che ci hanno portati ad oggi: se fosse andato già bene all'epoca, non avrebbe avuto senso l'evoluzione che c'è stata.

le evoluzioni hanno portato solo miglioramenti, e non complicazioni.

Su questo non sono completamente d'accordo.

[Lucky67]

l'assembler dello Z80 (sicuramente sia tu che Livio lo ricorderete); poi si è passati al 6502 e non vi dico la differenza in velocità ed affidabilità

Non per fare sempre il rompi ma lo z80 è nato pochissimo dopo il 6502 ma a mio parere aveva un architettura e e una possibilità di programmazione che il 6502 se la sognava. Alcune volte rimpiango la potenza di quel processore con un set di istruzioni che ancora adesso a vederle fanno sorridere alcuni plc di modesta fattura che ci sono attualmente sul mercato...e non eravamo ancora negli anni 80!!! Senza parlare che poi uno Z80 abbinato a una z80 PIO era praticamente l'antesignano dei moderni plc...

Modificato: 20 giugno 2012 da Lucky67

[Livio Orsini]

Non per fare sempre il rompi ma lo z80 è nato pochissimo dopo il 6502 ma a mio parere aveva un architettura e e una possibilità di programmazione che il 6502 se la sognava.

Ho cominciato ancora prima, quando lo F8 era lo stato dell'arte.

Tra gli 8 bits di prima generazione, a mio parere, lo Z80 non ha mai avuto confronti. Oltre a tutte le istruzioni "ufficiali" ne ha altre "nascoste" che non sono state ufficializzate per non perdere la compatibilità con lo 8085, ma qui il discorso si falungo e soprattutto OT.

non sono altro che l'applicazione dello schema mentale che guida la razionalizzazione tedesca,

Appunto e questo non è certo un punto di forza (a mio parere). La rigidità mentale può gestire bene alcune cose ma prima o poi, spesso prima che poi, porta a disastri inerarrabili; basta leggere i giornali quotidiani.

[busanela]

Non per fare sempre il rompi ma lo z80 è nato pochissimo dopo il 6502 ma a mio parere aveva un architettura e e una possibilità di programmazione che il 6502 se la sognava.

Ma anche no!

Al di la che non si possono paragonare i 3,5 MHz dello Z80 con l' 1 MHz del 6502 altrimenti ricadremmo nel solito mito della frequenza di clock che attribuisce alla frequenza di funzionamento la variabile in assoluto più significativa da considerare in maniera erronea, 6502 è votato all'efficienza nell'esecuzione principalmente per l’accesso alla memoria, mentre lo Z80 poteva dare il meglio di sè nella compattezza del codice.

Gli estremi che rappresentano la situazione di cui sopra sono le istruzioni più lente e più veloci.

Il 6502 richiedeva 2 cicli di clock per il completamento dell’operazione più veloce, mentre solo 7 per quella più lenta. Lo Z80, invece, spendeva almeno 4 cicli di clock nel primo caso e ben 23 nel secondo:

Il fattore più importante che incideva su questi calcoli è il tempo per l’accesso alla memoria, vero tallone di Achille dello Z80. Nel 6502 era necessario un solo ciclo per la lettura o la scrittura di un byte, mentre per lo Z80 ne servivano almeno 3.

Per il 6502 ci sono altri tre elementi che giocavano a favore eriassumendo brevemente: l'impostazione del flag durante il caricamento di un dato dalla memoria (questo faceva risparmiare un'istruzione), la pipeline di esecuzione e l'ultima, l’elevato numero di modalità di indirizzamento, 13, che consentivano di accedere alla memoria in maniera molto efficiente e flessibile.

Lo Z80 aveva comunque altri vantaggi che però io non ho mai considerato tali: l’elevato numero di registri a disposizione: ben 16 a 8 bit ( ma di cui soltanto 8 alla volta utilizzabili nello stesso momento); fra tutti forse la ricca dotazione di istruzioni, 158 contro le 56 del 6502, ma che salivano a 152 contemplando le istruzioni "non ufficiali". Il mio parere è che la fortuna del Zilog era legata alla compatibilità con l'8080.

Questo comunque vuole chiudere l'OT, che mi fa tornare alle beghe tra Apple e Spectrum tra noi ventenni dei primi anni ottanta.

[Lucky67]

Apple e Spectrum

immagino volessi dire Spectrum e ZX80/81(sinclair) / Commodore 64 e Vic 20 (commodore)...:) Che tempiiii

[busanela]

immagino volessi dire Spectrum e ZX80/81(sinclair) / Commodore 64 e Vic 20 (commodore)... Che tempiiii

No, no: proprio Apple. Io avevo il glorioso Apple IIe e non ti dico le battaglie con chi aveva lo Spectrum od i Commodore. Gli ZX 80 ed 81 non venivano nemmeno contemplati!

Non so se i tempi erano belli per la loro semplicità o perchè noi eravamo più giovani!

[batta]

Appunto e questo non è certo un punto di forza (a mio parere). La rigidità mentale può gestire bene alcune cose ma prima o poi, spesso prima che poi, porta a disastri inerarrabili; basta leggere i giornali quotidiani.

OB, FB, FC, SFB, SFC... saranno teutonici ed un po' ostici come nomi, ma il loro utilizzo organizzato è sinonimo di flessibilità, e non di rigidità.

[Livio Orsini]

è sinonimo di flessibilità, e non di rigidità.

De gustibus...

Almeno si potrebbero usare le sigle standard dei linguaggi di porgrammazione secondo le regole IEEE.

[batta]

Almeno si potrebbero usare le sigle standard dei linguaggi di porgrammazione secondo le regole IEEE.

Su questo non posso che darti ragione, ma è un problema che si supera rapidamente e con poca fatica.

[Livio Orsini]

C'è un linguaggio che ha avuto molta fortuna: PASCAL.

Fu pensato e scritto da un professore di matematica del politecnico di Zurigo, uno svizzaro tedesco. Credo che per tradizione, cultura e formazione sia la quintessenza dell'ordine, della pianificazione e della rigidità; inoltre il liguaggio venne creato al solo scopo didattico, quindi doveva avere vincoli molto stretti.

In questo linguaggio persino l'ordine fisico delle finzioni e delle soubroutines non è lasciato alla libertà del progettista ma deve avere un ordine ben preciso nella collocazione fisica, non della memoria, ma nella compilazione. Prima devono essere compilate le routines di livello più basso, poi si sale di livello sino a giungere al main program.

Ebbene trovo che questo linguaggio sia molto più flessibile e logico dei linguaggi Siemens, escluso microwin.

Se l'organizzazione del programma è, a mio parere, un poco cervellotica si tocca il massimo nell'organizzazione dei dati.

Sarebbe così semplice e, soprattutto, usuale suddividere i dati nelle solite categorie: locali e globali (privati e pubblici) , statici e dinamici. Un bel blocco unico con le dichiarazioni tra binari (boolean), byte o char, interi, interi doppi (lunghi) e real. Tutto semplice, ordinato e comprensibile; troppo facile, quindi giu un bel po' di UCAS con i Db i DB d'istanza e via elencando.

Modificato: 22 giugno 2012 da Livio Orsini

[batta]

Io trovo che l'organizzazione dei dati in DB separati, con la possibilità di creare strutture complesse all'interno dei DB, sia non un solo gradino, ma due interi piani sopra alla "normale" gestione delle variabili fatta negli altri plc.