Problemi di interferenze esterne e dati sbagliati su byte e/o word

[BRUNO_regg]

Salve a tutti,

seguo spesso il forum in quanto c'è sempre qualcosa di nuovo da imparare;

Volevo chiedere a chi frequenta la chat, se vi è mai successo di avere dei problemi con un programma che si comporta in modo strano e

che non sia imputabile obbligatoriamente al programma stesso ma a eventuali interferenze, disturbi o problemi legati ad una eventuale difettosità della CPU.

 

A livello hardware il sistema è composto da una CPU314 PN/DP + 5 batterie di valvole in Profibus + pannello TP700 Comfort in ethernet,

il tutto programmato con Tia V13 sp1 upd6.

 

Cerco di spiegare quello che succede:

Il programma è super-testato in quanto installato su più macchine da più anni. Per la precisione, la base di programma viene mantenuta, poi aggiunti o tolti blocchi a seconda della tipologia di macchina.

 

Nella parte "base" ho un sistema di conteggio utilizzando 2 byte (tramite un sensore di "passo" incremento i valori dei 2 byte fino ad un valore "X" (es.39); raggiunto 39,

resetto il valore (carico "0") e ricomincio il conteggio (0..39).

 

Ho anche un sensore di "reset giro" che ad ogni "x" (39)  impulsi del sensori di fase mi ripristina i dati e mi ricarica i valori di off set sui 2 byte (che chiaramente saranno uguali ai valori incrementati

dal sensore di passo)..

 

Il programma è scritto in AWL e utilizzo il "fronte di salita FP" del sensore.

I conteggi dei 2 byte, sfasati tra di loro tramite off set, (es. valore del primo byte   13,14,15,16.... secondo 38,39,0,1....) vengono utilizzati per creare un indice e "puntare" tramite il loro valore dei bit settandoli e resettandoli con una determinata sequenza. Per il puntatore utilizzo l'istruzione LAR 1. Tramite i bit comando delle elettrovalvole della macchina.

 

Quello che ci tengo a precisare, è che questa parte di programma (come detto precedentemente) è rimasta tale da almeno 7..8 anni senza avermi mai dato dei problemi (quindi direi che non ci sono errori di programmazione).

Arriviamo al dunque, cosa succede:

In maniera random, ogni tanto, mi trovo dei valori diversi rispetto a quelli che mi dovrei trovare all'interno dei byte. Me ne accorgo in quanto vedo che le elettrovalvole non vengono più comandate in fase rispetto al ciclo della macchina.

Poi, avendo anche il sensore di "reset giro", al giro successivo si rimette a posto.

Sono stato dal cliente 3 giorni (Algeria), e succede proprio quando meno te lo aspetti e in modo quasi del tutto casuale; es su 8 ore di produzione, il problema si è manifestato ogni 2 ore per 3 volte, dopodiché' nel giro di un'ora si è riproposto ben 2..3 volte.

 

Quello che però ho notato (chiaramente il 3' giorno, in quanto gli altri 2 li ho passati a verificare tutto quello che si poteva controllare, dal programma all'hardware, alle connessioni, ecc... )

è che i momenti in cui il problema si manifestava maggiormente (2..3 volte nell'arco di un'ora) era ad inizio produzione, pranzo e fine produzione che più o meno può coincidere con l'avvio e l'arresto delle attività produttive!!!! (es, fabbriche).

 

A livello di programma ho ricontrollato tutto, verificato che non ci fossero delle aree che si sovrapponevano, sostituito MB con DBB, tolto eventuali aree TEMP nei blocchi, niente da fare.

A livello Hardware, ho verificato il funzionamento dei sensori tramite dei debug a livello di programma, connessioni, ecc. Niente di niente.

Il cliente è convinto che il problema sia legato ad una difettosità del Firmware PLC (e subito lo pensavo anch'io) anche se sono stato smentito da Siemens (il cliente nel frattempo ha richiesto un PLC nuovo in garanzia ma dobbiamo ancora avere un FB).

A questo punto penserei ad eventuali interferenze che mi arrivano dall'esterno.......anche se dico, mi vanno a fare del casino solo nei conteggi???????

 

A qualcuno è successo di avere delle problematiche strane come quello che sto riscontrando?

 

Grazie a che mi vorrà rispondere e/o dare un qualche consiglio

Bruno 

 

 

 

 

 

 

 

 

 

[Nicola Carlotto]

Prova levare la messa a terra dalla cpu.

Se ci sono delle scariche elettrostatiche sulla macchina  potrebbero farti scherzi di questo genere.

Ciao

 

[batta]

Io escluderei che disturbi di natura elettrica possano causare questo tipo di anomalia.

E, anche se fosse possibile, mi sembra alquanto improbabile che il problema si manifesti sempre e solo su questi byte.

[lucios]

Condivido il batta-pensiero e aggiungo che il plc secondo me c'entra poco.

Ma di che tipo di sensori si tratta?

[Livio Orsini]

Per conto mio, derivando il parere da esperienza diretta, è probabile che i guai derivino da disturbi di conteggio dei sensori.

Per evitare, o minimizzare a livelli trascurabili, la possibilità di conteggi impropri è necessario prevedere un filtraggio sw degli im pulsi di conteggio.

[BRUNO_regg]

Grazie a tutti per l'interessamento,

guarderò di rispondere ai vari interventi:

 

per il discorso della "massa" ho già provato a toglierla ma non cambia in quanto il problema si è manifestato ugualmente.

Anche a me sembra strano il fatto che eventuali disturbi vadano ad impattare solo su queste 2 aree.

 

Per quanto riguarda i sensori sono dei comuni diam.18 induttivi di marca conosciuta con i quali non ho mai avuto problemi.

 

Per quanto riguarda l'eventuale filtraggio degli ingressi, (non l'ho specificato nel post precedente) avevo effettuato una prova ulteriore:

nella macchina ci sono installati 2 sensori di passo che lavorano sfasati tra di loro; Per testare il funzionamento del sensore "incriminato", ho creato 2 conteggi paralleli (incrementati uno da un sensore e uno dall'altro) senza però notare nessuna differenza di conteggio anche nel momento in cui la macchina sbaglia.

 

Proprio ora, in seguito alla precisazione di Livio, ho controllato il tempo di filtro inserito a livello di CNF HW (ritardo di ingresso) e ho notato che il byte dove sono collegati i 3 sensori hanno un tempo di ritardo impostato di 0,1 ms contro i 3 ms. di default in quanto nello stesso banco ho collegato anche altri 2 sensori che utilizzano i fronti salita discesa e chiamata del relativo OB di interrupt, mentre la funzione che manifesta il problema non utilizza interrupt e relativi OB.

 

Tengo anche a precisare che questa CNF HW l'ho già utilizzata per altre macchine, però a questo punto Livio mi mette un dubbio.....

Ci sarà un legame tra l'impostazione HW e il problema? 

 

Ritornando sulla prova effettuata con i 2 conteggi, mi sarei aspettato di trovarmi su una delle 2 aree utilizzate  per la prova (nel momento in cui la macchina sbaglia) dei conteggi diversi......

 

Un dato che non ho specificato precedentemente, ma per far capire che l'applicazione (a livello di velocità) non è critica il PLC "gira" in 5..6 ms, e il sensore di "passo" e quello di "reset giro macchina" rimangono in lettura per circa 22..28 ms. (testato).

 

Quale altro suggerimento?

Grazie

Bruno

[EsseCi60]

Cavi di potenza cablati vicini a quelli dei sensori...?

[Livio Orsini]

Con 6ms di ciclo e 22 ms di permanenza puoi leggere almeno 2 volte e confermare la transizione se, e solo se, il livello è rimasto costante.

Cerco di chiarire con un esempio.

Rivelo il fronte di salita e memorizzo la transizione senza aggiornare il conteggio. Per i 2 cicli successivi di programma verifico che lo stato sia sempre alto; solo se si verificano queste condizioni aggiorno il conteggio.

Se quste condizioni non si verificano significa che la transizione era una spuria.

Se poi aggiungi qualche cosa di simile per il fronte di discesa incrementi la sicurezza.

[lucios]

E tra un impulso e il successivo quanto tempo passa? Perchè forse  si potrebbe pensare anche a fare una sorta di filtro tacitando gli ingressi per un tempo fissato.

Però si tratta sempre di palliativi perchè se, come affermi, prima andava e nessuno ha toccato nulla, propenderei per un problema hardware.

Sei proprio sicuro che il cliente non abbia fatto qualche intervento a tua insaputa vero? Perchè a me è capitato anche questo.

[BRUNO_regg]

Buongiorno a tutti,

cavi di potenza si, ci possono essere, anche se bisognerebbe verificare l'impianto (macchina finita già in produzione), ma mi sento già di dire con certezza che senz'altro un qualche cavo c'è.

Nel frattempo (oltre al PLC in garanzia) abbiamo mandato anche 2 cavi schermati nuovi da collegare direttamente PLC e sensori.

 

Per quanto riguarda il consiglio di Livio, potrebbe essere una strada da seguire. Il problema è che la macchina è già installata dal cliente, al momento non abbiamo interventi da fare sul posto e per fortuna il cliente ha capito che siamo impegnati a risolvere il malfunzionamento e non ha preteso un nostro intervento immediato sul posto ma solo alcuni pezzi in garanzia giusto per capire se c'è qualcosa a livello di HW (in tutti i modi il problema è da risolvere, quindi prima o poi un intervento sarà da fare).

Comunque terrò in considerazione il consiglio.

Nel frattempo, oltre a PLC e cavi schermati abbiamo inviato al cliente una MMC con il programma modificato da testare (modifica che mi era venuta in mente l'ultimo giorno di permanenza);

Praticamente ho inserito nel blocco dei conteggi (dove si manifesta il problema) un salvataggio del conteggio precedente effettuato sul fronte di discesa addizionato di 1 poi confrontato con il fronte di salita successivo. In questo modo, se l'errore di conteggio avviene durante la lettura del sensore (dopo il fronte di salita ma prima del fronte di discesa), confrontando i dati dovrei avere la certezza di trovare sempre il dato corretto.

Es. Rilevo fronte di salita; incremento conteggio da 3 a 4, rilevo il fronte di discesa salvo il dato incrementato (4) e lo addiziono di 1 =5.

Sul fronte di salita successivo l'incremento dovrà essere da 4 a 5, confronto il dato incrementato, nel caso non fosse 5 lo scarto e trasferisco il dato salvato precedentemente.

Con questa modifica dovrei riuscire a risolvere il problema durante la lettura del sensore.

 

Rispondo a Lucios...Tra un impulso e l'altro c'è un tempo superiore, non l'ho verificato ma sarà almeno di 200ms. Il cliente non ha toccato nulla.

Una precisazione: la base di programma che manifesta il difetto è super collaudata, ma il problema su questa macchina l'ho avuto fin da subito.

anche se durante il collaudo in azienda non era stato riscontrato anche se magari era già presente (i problemi li vedi con le macchine in produzione).

 

 

 

Grazie a tutti,

se qualcuno ha un qualche altro consiglio da dare.....

 

bruno

 

 

 

 

 

[Livio Orsini]

Quote

cavi di potenza si, ci possono essere,

 

Se si seguissero le prescrizioni delle nrmative EMC, questo tipo di cablaggio, e questo tipo di problema, non dovrebbe esserci. Purtroppo troppo spesso queste prescrizioni vengono ignorate perchè ritenute, a torto, spese inutili.

 

E' evidente che il problema è legato a disturbi.

I disturbi son sempre presenti. Si applcicano le direttive EMC per "non tirarseli in casa". Inoltre si mettono in atto accorgimenti Sw per abbaterne le eventuali conseguenze.

Se queste precauzioni si prendono in sede di progetto hanno un costo minimo, se si deve rincorrere l'apparecchiatura i costi salgono e poi son sempre pezze.

[lucios]

Ma la modifica che hai fatto funziona solo se l'errore non è dovuto a trillamenti degli ingressi, altrimenti avrai sempre dei fronti di salita e discesa, anche se irregolari. O ho capito male io?

[BRUNO_regg]

Buongiorno a tutti,

rispondo a Lucios: Si, la modifica che ho preparato (e non ancora testata dal cliente) funziona solo se hai dei "trivellamenti" sugli ingressi. è una prova da fare....

 

Per quanto riguarda i consigli di Livio, sono sempre ben accetti. Il più delle volte non consideri il fatto di avere cavi di potenza vicino a cavi di comando, anche perché (anche se non sempre è così) molte volte hai dei passaggi obbligati oppure (come sta succedendo a me) non è mai successo.

 

Proveremo a spostare i cavi di comando (posando i nuovi cavi schermati inviati al cliente) e vediamo.

 

Un filtro in ingresso sulla "trifase" potrebbe essere utile?

 

Grazie a tutti

Bruno

 

[EsseCi60]

Se hai passaggi obbligati o ci metti lo schermo oppure rendi edotto il cliente sulle problematiche che questo comporta.
Così sei spalle al muro su questi problemi = costi supplementari.

I "filtri" , a mio modesto parere, servono a niente.

I disturbi sono dati dai campi elettromagnetici che si formano al passaggio della corrente (ovvero nel normale funzionamento) che influenzano i segnali dei sensori

[Livio Orsini]

Filtro sulla trifase non ti assicura contro questi falsi conteggi.

Potrebbe addirittura, per cause differenti, farti apparire il problema come risolto, inizialmente, ma poi il problema ritorna.

Questi problemi si risolvono radicalmente usando contempoiraneamente 2 procedure.

1. Cercare di evitare di portarsi "in casa" i disturbi, agendo sui cablaggi, schermi e masse.
2. Filtrando in modo software in modo da impedire conteggi impropri.

Hai la fortuna di avere impulsi abbastanza larghi e con tempi di ripetizione lunghi. Fai un filtro come ti ho descritto, addirittura se hai contezza dell'ordine di grandazza del tempo di zero puoi anche imporre che non consideri un fronte di salita se l'impulso non è rimasto a zero per un tempo minimo.

 

Ti complichi, ma nemmeno tanto, il software ma ha un'elevatissima sicurezza di contare solo gli impulsi veri.

[JumpMan]

negli ob di interrupt hai qualche variabile condivisa con il programma incriminato che può influire sul conteggio? Ho avuto problemi simili con s7 200 e c'erano delle note sull'aiuto in linea, ma non credo che anche il 300 ne sia afflitto. Se il problema e hardware, cosa avevano di diverso a livello HW le macchine funzionanti dei 7 anni precedenti?

[Livio Orsini]

Basta un percorso cavi un poco differente sul cavo del sensore si accoppiano disturbi.

[BRUNO_regg]

Buongiorno nuovamente,

a livello di interrupt non ho nessuna variabile potenzialmente condivisa....

 

Per quanto riguarda i cavi,

abbiamo già detto al cliente di posare quelli nuovi in percorsi differenti;

 

Attendiamo il riscontro da parte del cliente.

 

Grazie  a tutti

[pigroplc]

Non ho trovato alcuna indicazione sulla posizione dei sensori: sono nel rack centrale oppure decentrati?

Se sono decentrati io verificherei eventuali disturbi di Profibus (proprio settimana scorsa diagnosticato in teleassistenza impianto in Arabia una simile anomalia dovuta ad un bridge Parker che dava problemi).

Se invece si tratta di rack centrale io proverei a cambiare l'alimentatore a 24V oppure a verificare se nel circuito del 24V ci sono dei mini-corti circuiti che fanno sedere l'alimentatore e creano questi problemi.

 

[batta]

Quote

Se sono decentrati io verificherei eventuali disturbi di Profibus (proprio settimana scorsa diagnosticato in teleassistenza impianto in Arabia una simile anomalia dovuta ad un bridge Parker che dava problemi).

Se invece si tratta di rack centrale io proverei a cambiare l'alimentatore a 24V oppure a verificare se nel circuito del 24V ci sono dei mini-corti circuiti che fanno sedere l'alimentatore e creano questi problemi.

 

Tutte cose che è corretto verificare, ma io ritengo altamente improbabile che simili eventuali problemi causino anomalie sempre e solo sugli stessi due byte.

[Livio Orsini]

Quote

ma io ritengo altamente improbabile che simili eventuali problemi causino anomalie sempre e solo sugli stessi due byte.