Cpu 319F-3Pn/dp In Stop !

[bluetooth]

Buongiorno a tutti,

è da un pò che non scrivo ma in questo tempo ho continuato sempre a frequentare questo fantastico sito.

Vi descrivo la mia applicazione con relativo problema:

Ho una CPU SAFETY 319F-3PN/DP collegata in profinet con diversi slave( IM 151-3PN) e con due cpu, una IM 151-8 PN/DP ed una IM151-8F PN/DP.

La CPU 319 attraverso i-device scambia dati con queste due cpu.

Capita che in maniera random la cpu 319 va in stop, 1 volta al giorno, a volte 3 a volte 5, non esite una periodicità. Basta fare poi uno stop/run ed il tutto si risolve.

L'errore che si presenta ha a che fare con la comunicazione tra cpu 319 e cpu IM151-8F. Utilizzo per lo scambio l'FB225 - F_Send S7 Connection - (F_SENDS7) e l' FB226 - F_Receive S7 Connection - (F_RCVS7)

Allego le FB, non è la prima volta che l'utilizzo !!! ed il tipo di errore che si presenta quando la cpu va in stop.

Ho fatto diverse prove sotto la supervisione di Siemens ma non riesco a venirne fuori !!!!

Ringrazio tutti anticipatamente.

Saluti,

Luca

[pigroplc]

Hai provato ad allungare a dismisura il parametro di time out?

pigroplc

[bluetooth]

Si si questa prova l'ho fatta !!!! Ma 2 sec sono più che giusti perchè ho un tempo di ciclo di 50ms.

[pigroplc]

io farei la prova di controllare la rete con un programma gratuito come PingoInfoView collegato ad un PC che pinga entrambi I PLC con la frequenza di 1 ping ogni secondo.

Potrei verosimilmente avere le seguenti condizioni:

a) errore di ping per entrambi I PLC in corrispondenza dello stop del PLC: mi viene da pensare che la rete ha problemi

bi) errore di ping per un PLC e stop l'altro no: mi viene da controllare il PLC che si è scollegato oppure il ramo di rete che fa capo al quell PLC

c) nessun errore di rete e PLC che va in stop: proverei a cambiare la CPU e a ridurre il tempo di intervallo di ping.

pigroplc

Modificato: 19 gennaio 2015 da pigroplc

[pkk]

Scambi dati safe?

Tieni presente che non è assolutamente possibile cambiare lo stato delle memorie esterne tipo merker o db safe , dall'entrata all'uscita del fc safety.

Cioè se un bit è a uno quando sei entrato nel fc safe deve rimanere tale per tutta l'esecuzione di questo fc. Altrimenti si dice che i dati safe sono corrotti... Infatti lo vedo nella tua diagnostica.

Inviato dall'app. Mobile di PLC Forum da iPhone5,2

[pkk]

Scaricati il manuale safety siemens, che è spiegaro bene.

Inviato dall'app. Mobile di PLC Forum da iPhone5,2

[bluetooth]

Grazie per le risposte, domani sarò sull'impianto per la prova di pingare entrambi i plc e controllo anche il discorso delle memorie rilevato da pkk.

[pigroplc]

Mi sa che pkk ha ragione, io proverei a inibire eventuali cambi di stato dei bit da spedire con il negato del flag DB511.DBX20.1.

Io non ho mai usato quei blocchi ma mi sembra chiaro.

[pnet]

Mi associo al problema di coerenza, io tempo fa dovevo gestire una uscita e non avendone di libere "normali" ho dovuto gestire una lampada di un pulsante con uscita FAIL SAFE.

Il famoso MB di clock della CPU letto dal programma safety può generare questo tipo di problema dato che l'esecuzione viene fatta per 2 volte, capitava random che tra la prima e la seconda esecuzione un bit cambiasse di stato, con conseguente incoerenza dati e immediato stop cpu simile al tuo caso. La soluzione è stata copiare il MBxx in MByy prima dell'esecuzione del CALL_F e richiamare dappertutto solo il MByy.

Ovviamente il tuo può essere un caso completamente diverso, ma ciò riportato sopra può facilmente indurre in errori grossolani come il mio... ;-)

Una curiosità, hai PN coupler tra le 2 cpu? al tempo che ho usato io la 319 era necessario, so che poi hanno fatto aggiornamenti firmware delle cpu ed è diventato non necessario.

[bluetooth]

Ok grazie, non ho PN coupler tra le due CPU, ho un semplice collegamento Profinet.