PLC in STOP e INVERTER RUN = disastro

[gianco]

salve,

configurazione:  cpu 319pn  e   24 inverter  gc120c  collegati in profinet

guasto: a fronte di una micro interruzione del sitop dovuta ad un  overlaoad dell'alimentatore la cpu e' andata in stop  , ma gli inveter hanno continuato ad eseguire l'ultimo comando.

non vi dico il disastro....

E' gia' successo a qualcuno di voi ?

grazie.

 

[lelos]

ciao 

per me mai dare comandi start attraverso una rete , un relè se non alimentato si diseccita (caso molto molto  raro rimane incollato visto le bassisime correnti)

mi è successo non con profinet

[Giuseppe Signorella]

In genere quando vi sono inverter o azionamenti comandati in rete, è indispensabile adottare opportuni accorgimenti onde evitare questi tipi di problematiche. 

Ad esempio interporre un teleruttore a monte o a valle dell'inverter comandato dal plc che lo gestisce.

Se poi quest'ultimo prevede a bordo uno o più ingressi  con funzioni Safety, e quindi dotato di una certificazione come dispositivo di sicurezza, si comandano direttamente questi ingressi, in uno ad un altro dispositivo ridondante come ad esempio un preventa o similare. 

Modificato: 15 ottobre 2015 da Giuseppe Signorella

[bleny]

Ciao Gianco,
oltre a quello che ha giustamente detto Giuseppe, io per evitare questo problema con dei Micromaster controllati in profibus attivo il tempo dopo il quale viene generato un errore se non c'è comunicazione tra drive e cpu, così da far spegnere tutto.

Con il Micromaster il parametro è il p2040, immagino che ci sia qualcosa di simile anche per il G120 in profinet.

Ciao.

Massimo

[busanela]

Acrocchi software non danno mai la certezza di uno stop di emergenza e non sono sicuramente in linea con la normativa macchine: un bel teleruttore a valle dell'inverter, pilotato da una semplice autoritenuta, o meglio, da una centralina ridondante, nel caso in esame avrebbe garantito l'istantaneo distacco del motore dal pilotaggio di potenza.

[Livio Orsini]

Ricordo che o l'inverter ha uscita di sicurezza certificata o è obbligatorio avere un organo elettromeccanico di sezionamento.

In entrambi i casi direi che la mancanza rete o lo stop CPU devono causare un arresto di emergenza e solo l'intervento volontario dell'operatore può riportare la macchina/impianto in marcia.

Questo è previsto dalle norme di sicurezza.

[pigroplc]

Non entro nel merito del ciruito di sicurezza nè della gestione combinata del comando di OFF1-OFF2 misto fra comandi del PLC-Safety ecc.

Settimana prossima devo andare da un cliente per provare una applicazione simile. Proverò quindi a mandare il PLC in stop e vedro lo stato dei comandi.

Su Simotion c'è il valore di sostituzione, cioè il valore che viene scritto in caso di stop della CPU, ho provato a cercare un omologo a livello di PLC senza trovarlo.

Farò delle prove poi relazionerò.

Modificato: 16 ottobre 2015 da pigroplc

[Livio Orsini]

Non entro nel merito del ciruito di sicurezza nè della gestione ......

 Dovresti tenerlo presente perchè, salvo pochi casi particolari, non è ammessa la ripartenza automatica dopo un'interruzione delenergia elettrica.

Devi fare l'analisi dei rischi e prendere la decisione appropriata.

[acquaman]

Dipende dai tipi di impianti, impianti non pericolosi per l'operatore possono non esserci circuiti di sicurezza, es.impianti trattamento acqua.

[pigroplc]

Dovresti tenerlo presente perchè, salvo pochi casi particolari, non è ammessa la ripartenza automatica dopo un'interruzione delenergia elettrica.

Si Livio che ne tengo presente nei progetti, è logico pensarlo ed è criminale non considerarlo in una certificazione di un equipaggiamento. La realtà è che in caso di equipaggiamenti semplici I costruttori di macchine tendono a "dimenticare" certi accorgimenti, il più delle volte anche in buona fede.

Gianco ha iniziato questa discussione mettendo in risalto NON la pressione di un fungo di emergenza (quindi l'intervento del circuito di sicurezza); NON lo spegnimento dell'impianto, tant'é che gli inverter hanno continuato ad azionare I motori, BENSI' LA COMMUTAZIONE START-STOP del PLC!

Da quello che IO CAPISCO si tratta di un arco di tempo anche considerevole (ipotizziamo 30 secondi) all'interno del quale l'impianto ha girato senza controllo delle condizioni di contorno. Siccome io metto pure un comando di uscita del PLC sull'OFF2 in modo da arrestare in caso di PLC STOP voglio provare a vedere se temporaneamente eliminando questa combinazione l'inverter gira comunque.

Poi forse Gianco mi smonta la mia interpretazione inserendo altri dettagli dell'accaduto.

 

 

Modificato: 16 ottobre 2015 da pigroplc

[pcontini]

A parte il discorso sicurezza, che è fondamentale ma va valutato nel caso specifico, anche io adotto il sistema citato da bleny e cioè parametrizzo gli inverter in modo da arrestare l'uscita in caso di mancanza di comunicazione. Questo è comunque importante in quanto potrei trovarmi, anche senza avere la cpu spenta, una mancata comunicazione semplicemente per cavo interrotto o difettoso. Un eventuale arresto di emergenza non interverrebbe.

 

[rimonta]

A me è successo spesso che cadesse la rete e l'inverter va subito in errore , mi sembra strano che i tuoi non abbiano riscontrato l'anomalia.

Non è che sia stato modificato il valore del P 2040?

[Livio Orsini]

A me è successo spesso che cadesse la rete e l'inverter va subito in errore..

Se si è trattato di una microinterruzione il PLC va in stop e l'inverter se è predisposto per ignorare le microinterruzioni non fa una piega.

Si considera microinterruzione, se ricordo correttamente, l'assenza di tensione per un tempo pari a 2 periodi. Nel caso di reti a 50 Hz sono 40 ms che per l'inverter è un tempo insignificante, al massimo il DC bus rippla un poco di più, mentre per il PLC è un tempo enorme pari a parecchi cicli di programma. Il tutto poi dimende in maniera fondamentale dall'alimentatore del PLC, come è stato previsto. In molti dispositivi l'assenza di un solo periodo di rete innesca in automatico il salvataggio dati nelle aree di memoria non volatile.

Potrebbe anche trattarsi di uninterruzione dell'alimentatore del PLC non per mancanza rete ma per sovraccarico istantaneo.

Gianco ha iniziato questa discussione mettendo in risalto NON la pressione di un fungo di emergenza ..

 

Di fatti io non ho fatto alcun riferimento ad emergenze, ma proprio al PLC che per una qualsiasi ragione perde il controllo.

Nei vecchi sistemi di controllo si usava l'uscita CCZ (Computer CraZy == Controlore impazzito), per tagliare consensi e alimentazioni agli attuatori.

Si trattava di un'uscita che veniva alzata ad ogni ciclo di programma e cadeva entro un tempo ben preciso.

Quando si controlla un impianto tramite bus di campo bisogna prevedere analoghe sicurezze anche se la macchina è semplice e non da luogo a stati pericolosi per il personale.

Anche un impianto di pompaggio può essere pericoloso. ma anche se non c'è pericolosità una pompa che lavora inutilemte alla massima portata per un guasto di pilotaggio causa senza alcun dubbio un danno economico.

[busanela]

Nei vecchi sistemi di controllo si usava l'uscita CCZ (Computer CraZy == Controlore impazzito), per tagliare consensi e alimentazioni agli attuatori.

Si trattava di un'uscita che veniva alzata ad ogni ciclo di programma e cadeva entro un tempo ben preciso.

Livio, è l'analogo del più recente Watchdog? 

[pigroplc]

Il valore di default del parametro P2040 è 100ms ed è quello che ho lasciato nella parametrizzazione degli impianti. Inutile dire che in caso di commutazione STOP del PLC il tempo di ripartenza è nell'ordine dei secondi-decine di secondi e NON millisecondi. Allo scadere di questo tempo di ritardo l'inverter di sicuro va in errore.

[Livio Orsini]

Livio, è l'analogo del più recente Watchdog? 

 

No è tutto Hw. In pratica è una capacità che viene mantenuta carica da un impulso che la rinfresca ad ogni termine di programma. Il tempo è stabilito dalla costante di scarica e non può essere mutato. L'inervento di questa sicurezza è previsto in caso di guasto "catastofico".

Il WD è invece un limite software che può essere variato entro una certa gamma, ma in caso di guasto catastrofico potrebbe non intervenire; poi dipende da come è stato realizzato,

Concettualmente sono due cose differenti.

Il valore di default del parametro P2040 è 100ms ed è quello che ho lasciato nella parametrizzazione degli impianti.

 

In altri termini se l'inverter non riceve indicazioni dal bus di campo per oltre 100ms va in allarme.

Questo sicuramente protegge da blocchi di comunicazione.

[busanela]

Non esiste un unico tasso di rischio o un’unica categoria di rischio per una macchina: ogni rischio deve essere considerato e valutato singolarmente. 100 ms. possono essere pochi od anche tanti, dipende dall'accellerazione, dalla velocità della macchina e dalla massa della parte in movimento: in 0,1 secondi lo spazio percorso può essere anche di decine di centimetri o addirittura metri e se il sensore di rallentamento o di stop non viene interpretato in tempo a causa della comunicazione interrotta, devono essere messe in atto le più corrette misure cautelative per eventuali danni a cose e persone. Mi viene in mente il caso di una rotativa di stampa. 

[gianco]

Innanzi tutto vorrei ringraziare tutti  per l'interesse e le utili info che mi avete dato.

In particolare riguardo al parametro 2040 che credo spieghi buona parte del problema.

La mia interpretazione e' questa:

Il sitop  ha abbassato la 24 per un sovraccarico.( e ci sta perchè  e' sottodimensionato)

la cpu ha rilevato una sotto tensione ed e'  andata in "reset"  

i circuiti  di sicurezza (PILZ)  evidentemente hanno una soglia piu bassa e quindi sono rimasti vivi .

gli inverter sono rimasti vivi

l'alimentatore  , scaricato dai carichi pilotati direttamente da uscite  plc si e' subito ripreso   ed e' tornato ad erogare la tensione giusta

A questo punto la cpu ha iniziato la procedure di ripartenza (circa 30 secondi)

FORSE il tempo di buco della rete profinet e' durato  meno di 100ms e gli inverter non hanno rilevato la caduta del profinet percio hanno continuato con l'ultimo comando ricevuto

o piu probabilmentre il processore di comunicazione del plc ha continuato  ad inviare il buffer "ante-plc-mortem".

Che ne pensate della mia interpretazione ?

COMUNQUE  PER IL MOMENTO HO PROVVEDUTO A METTERE UN WD COME SI FACEVA SECOLI FA  (quando ci si faceva in casa le schede con cpu 8085 e z80... che bei tempi).

 

  

 

 

 

 

[pigroplc]

Gianco io non ho capito come si possa mettere un WD. Io ritengo ancora valida la mia soluzione dell'uscita del plc collegata con un OFF1 del motore. Se il PLC va in stop le uscite vanno a zero e gli inverter si fermano.

Quanto alla ripartenza del PLC io mi immagino che uno stop-start vada ad inizializzare la comunicazione Profinet con I partecipanti, mi sembra quantomeno improbabile che gli inverter manco se ne siano accorti.

Quanto al Sitop sottodimensionato è qualcosa che mi è capitato in precedenza, dovuto alla inesperienza della progettazione elettrica e la necessaria contemporaneità dell'alimentazione di una miriade di elettrovalvole. Altra condizione accadutami: totale mancanza di protezioni intermedie e alimentatore seduto a causa di un corto circuito in catena porta cavi nel bordo macchina.

[Livio Orsini]

Non è per niente bello usare il medesimo alimentatore per alimentare PLC e attuatori sul campo, anche perchè in questo modo è inutile avere la separazione galvanica degli I/O, oltre ad essere pericoloso per gli inconvenienti sopra elencati.

Concordo con pigroplc che la mancanza di alimentazione del PLC dovrebbe tagliare tutte le uscite, uscite che verranno rimesse operative dal PLC dopo l'avvenuta inizializzazione.

[Giuseppe Signorella]

In genere un'uscita del PLC dovrebbe comandare direttamente il preventa,(in serie con tutte le altre sicurezze) in questo caso il preventa verrebbe abilitato solo se la CPU è in run, e se a livello software vi siano tutte le condizioni di sicurezza soddisfatte.

Quando la CPU va in stop, causa la disabilitazione del preventa e di conseguenza la caduta dei teleruttori a monte/valle degli inverter.(Ho protezione similare, come la mancata alimentazione sul morsetto configurato come Safety in alcuni azionamenti ), 

Modificato: 17 ottobre 2015 da Giuseppe Signorella

[batta]

FORSE il tempo di buco della rete profinet e' durato  meno di 100ms e gli inverter non hanno rilevato la caduta del profinet percio hanno continuato con l'ultimo comando ricevuto

Non riesco a capire.

Se l'inverter non riceve telegrammi si ferma.

Se la CPU va in stop non invia telegrammi.

Quindi già questo dovrebbe garantire l'arresto degli inverter.

[gianco]

per WD intendo un monostabile "retriggerato" da un segnale pulsante che se non viene rinfrescato entro un tempo definito scade e attiva le azioni di reset or salvaguardia meccanica .

comunque concordo con prigroplc  e Giuseppe che una uscita statica  del plc che va su off1 o in serie al pilz offra un buon livello di protezione . Il WD e' un eccesso di zelo

concordo con LIvio che il fatto che sparare le alimentazioni "intelligenti" dalle alimentazioni delle attuazioni sia casa saggia e giusta.

ma cio' non toglie che un plc in fase si restart  che consente agli inverter g120c (su rete profinet)    di continuare a lavorare sia cosa alquanto pericolosa.

Ho dimenticato di dire che il plc ha generato un ob83 ( io fault 2)  ma non ha generato un ob82 (io fault 1)  dove 1 = profinet e 2=profibus.

a conferma di cio'  ho visto che i dispositivi gestiti da profibus si sono fermati mentre i g120c che sono sulla rete profinet  continuavano a fare danni.

P.S. siemens dice che ho sbagliato io perchè ho esteso l'intefaccia di processo da 512 a 1024 e in questo modo gli inverter che di default vengono messi oltre al 512  ci sono finiti dentro..... .

Se ha ragione c'e da avere paura di tutto anche di una semplice   et200  su profinet  .

 

 

 

[claudioram]

Ricordo una ventina di anni fa con la serie C200 H di Omron, un problema analogo in una rete controller link, però senza inverter.

Esistevano  circa sei sette rack dislocati nei vari piani di un molino di macinazione di grano duro e tutti sotto rete Contoller link di Omron.

Succedeva raramente durante i temporali che mancando la tensione per frazioni di secondo, gli ausiliari generali non sganciavano. Le uscite anzichè spegnersi molte continuavano a rimanere in stato di on. Dipendeva dalle circostanze di contemporaneità di lavoro del plc.

La cosa l' abbiamo risolta mettendo un UPS con alimentazione 220 V comune a tutte le CPU. (praticamente abbiamo creato un alimentazione comune separata per tutte le cpu)

Questo per dire che quando si lavora con qualsiasi tipo di rete, di qualsiasi azienda, possono esserci sempre aspetti, che nessuno neppure i progettisti delle multinazionali citate,  lontanamente avrebbero pensato!!

 

Come diceva Livio secondo mè la cosa migliore è creare un alimentazione plc protetta da fusibili esclusivamente per la CPU.

Per gli ingressi un alimentazione separata.

Per le uscite un  alimentazione separata.

Se tutto è a 24 V tre alimentatori .

Se la CPU è a 220V due alimentatori da 24V .

Sicuramente i guasti citati da voi vengono molto ma molto ridotti.!!

Dimenticavo una cosa: se si lavora all'interno del programma con aree di memoria a rimanenza,

questo problema viene amplificato in caso di black out elettrici.

Saluti a tutti.

 

[gianco]

Pienamente d'accordo con la separazione delle alimentazioni e accorgimenti vari  per ridurre le probabilità di creare l'evento disastroso. (cosa che ovviamente  ho fatto subito )

Ma alle leggi di murphy non si sfugge !!!  e  se puo' succedere prima o poi lo fara' e nel momento meno opportuno.(Scusate per la nota di pessimismo ma e' stata una brutta esperienza )

Quindi secondo voi si puo dire che  : un dispositivo remoto controllato  tramite  profinet  potenzialmente puo' rimanere in "RUN" senza impostare configurazioni di default   anche se il master non e'  in "RUN".   ?

Io spero che ci sia una altra spiegazione (magari un bug nel G120C) , non posso pensare di essere ritornato ai tempi in cui si collaudava la stabilita e l'affidabilita di una linea seriale facendo scintillare un carico induttivo vicino al cavo e alla cpu