Blocco CPU da FB32775

[ETR]

Ciao a tutti, riporto esattamente il log di una CPU 1500 che è andata in STOP, apparentemente senza ragione, di notte, per poi rimanerci sino a quando non è stata manualmente posta in STOP e poi in RUN con il tasto fisico (dopo diversi spegnimenti che non hanno dato esito).

 

Da un controllo a posteriori del log, ho notato e purtroppo perso, una ulteriore trascrizione di una DIV 0 (istruzione fisica non esiste in nessuna parte del safety da me programmata), quindi presumo che sia riferita ad un blocco di sistema safety.

 

Cercando e leggendo, ho notato che alcune volte in maniera corretta, degli sforamenti di aree in scrittura, porterebbero al conseguente stop. Fin qua, mi sembra tutto chiaro e ovvio. La mia conoscenza con manovre non proprio consone con la memoria in B&R, mi ha permesso di fare una serie di queste esperienze. Nello specifico dei casi letti, si riconduce questa azione alla visualizzazione, specialmente con indirizzamento assoluto.

 

Questa applicazione è la medesima di un altro mio post, dove chiedevo lumi, circa la programmazione di un WinCC RT con classe IP xx che doveva puntare dietro un router una cpu con classe yy, senza dover commutare TUTTA la programmazione delle TAG, in assoluta.

 

Qualche giorno prima del blocco, a seguito di una impellente necessità, ho dovuto aggiungere alcuni bool ad un registro DB che hanno necessitato la ricompilazione. L'HMI locale è stato aggiornato proprio per questa necessità, mentre il WinCC RT, no.

 

Questa al momento sarebbe la mia spiegazione all'accaduto che si risolverebbe con l'aggiornamento del WinCC. Ma ci sono altri aspetti che dovrei tenere conto ?

 

Buon WE

 

Ennio

 

[ifachsoftware]

Non è che scrivi dei dati non safety nella parte safety in maniera non sincronizzata ?

[pigroplc]

Potrebbe essere qualche malfunzionamento hardware che causa questo problema? Sarebbe importante avere lo storico degli errori della CPU per capire se nella sequenza degli eventi si antepone una anomalia di qualcosa.

 

[Marco Fornaciari]

Mi consola (magramente) solo il fatto che capiti anche ad altri.

Con Siemens non mi è mai capitato.

 

Ma a fine anni '80 mi capitato su CPU 17 telemecanique con processore 80852, trovato causa e segnalato a produttore: risolto modificando firmware per allinearlo a processore.

 

Quindi 2016 su CPU Omron CJ2M- CPU15, successo due volte sempre in agosto (!), problema non capito, ma ripartita dopo stop/run via USB, vie Ethernet non c'è verso.

Poi sostituito CPU con CJ2M-CPU35, successo altre volte con errore che non nulla a che vedere (15 a menoria), anche qui ripartita con stop/run via USB.

Va da se che Omron nega, e problemi al SW non ci sono.

 

Ma attenzione con le CPU e i SW lavoranti in ambiente Visual Studio ho recente esperienza di problemi sulla porta Ethernet/profinet/ethenrt/ip, che oltre mandare in blocco la comunicazione, tra l'altro in modo casuale, danneggiano i data base degli I/O e del simbolico: a fine agosto ho riportato allo stato di fabbrica due CPU e poi riconfigurate e programmate.

Ma in questi due casi ho dubbi su gli aggiornamenti di Win10: 3 in 10 giorni in primavera e settembre, e chi ha messo mano hai programmi non se ne accorto (ovvero ha fatto danni lui a fine primavera).

 

[ETR]

Ciao a tutti, grazie per le risposte.

 

Dando riscontro a delle indicazioni di varie discussioni trovate in internet, ho controllato bene anche gli avvisi di compilazione. Nulla di ché, se non la FB38004 (blocco di comunicazione per due inverter G120) tutto inserito in automatico dal TIA, che sforava nell'area di memoria dedicata agli FB safety.

 

Ora, un medesimo impianto, presso lo stesso cliente funziona da due anni con una similare configurazione HW e nei prossimi giorni controllerò questo punto anche in quel programma. Nel mentre ho sistemato anche questa nota e al primo fermo, aggiornerò il software.

 

La versione di TIA in uso è la 18 con i firmware della CPU aggiornati. Purtroppo mi sono accorto tardi che ho un inverter con l'avviso di manutenzione che mi sta sporcando il log ogni minuto e quindi mi sembra di aver perso le informazioni salienti per un analisi approfondita.

 

Buona giornata

 

Ennio

[ETR]

Ciao a tutti, nella fortuna di aver risolto il problema dell'intasamento dei log per colpa di un G120C, l'altro ha pensato bene di ripiantarsi con lo stesso problema citato in questo post. 

 

Solo che questa volta, sono riuscito a tracciare e analizzare la causa :

 

21 of 512; Event ID: 16# 0D:75D6
Error: Safety program: Data corruption prior to sending to F-I/O
F-runtime group   1
Start address of the F-I/O:         55
Offset of the output:   0
 PLC_1 / PLC_1. 

 

Quindi ho una scrittura random del Q55.0 sulla rete (a quanto mi è dato capire). 

 

La mia ipotesi è questa : il PC e l'HMI locali li ho COMPLETAMENTE rivisti e non ho nessun riferimento incrociato sui questi elementi. Però, chi mi ha preceduto ha lasciato in giro per gli impianti versioni copia e incolla di versioni di RT che potrebbero ancora puntare a vecchie uscite del vecchio S7300 che era installato e che ho dovuto mantenere come indirizzamento IP (per compatibilità con sistemi di acquisizione dati superiori). 

 

La soluzione è iniziare una caccia alle streghe per tutti i reparti con controllo dei pacchetti sui vari router e/o tutte le versioni (se mai riuscirò a trovarle tutte) dei sorgenti dei vari RT oppure sradicare l'indirizzo del blocco che genera l'errore e spostarlo in un area completamente fuori da qualsiasi precedente utilizzo. Non è certamente la soluzione, ma è sempre meglio di un fermo linea.

 

Altre indicazioni o considerazioni che devo tenere presente ?

 

Buona giornata

 

Ennio

[ETR]

Ciao a tutti, chiedo conferma di una ulteriore indicazione ricevuta a fronte del ri presentarsi del problema dopo oltre 2 mesi continui di uso.

 

Il 05/10/2025 alle 06:25 , ifachsoftware ha scritto:

Non è che scrivi dei dati non safety nella parte safety in maniera non sincronizzata ?

 

Mi è stato segnalato che il solo BOOL proveniente dal HMI (appoggiato ad una DB ma comandato direttamente dal pannello), potrebbe essere il problema di tutto questo. Il BOOL in questione (Pb_Rst) dovrebbe comandare un ulteriore BOOL in una ciclica standard del PLC e poi SOLO quest'ultimo andare a lavorare nel FB Safety.

 

Non ci sono altre iterazioni tra l'HMI ed la parte Safety che è veramente ESIGUA (23 segmenti).

 

Chiedo se qualcuno abbia risolto eventuali similari problematiche con questa azione perché mi sono lasciato con il tecnico con l'indicazione di "tentativo". Quindi volevo capire quanto fosse la percentuale di esito positivo del "tentativo".

 

Buona serata

 

Ennio

 

[Mattia Spoldi]

56 minuti fa, ETR ha scritto:

Mi è stato segnalato che il solo BOOL proveniente dal HMI (appoggiato ad una DB ma comandato direttamente dal pannello), potrebbe essere il problema di tutto questo. Il BOOL in questione (Pb_Rst) dovrebbe comandare un ulteriore BOOL in una ciclica standard del PLC e poi SOLO quest'ultimo andare a lavorare nel FB Safety.

Questa situazione mi è capitata e quando capita manda in stop la CPU al 100%.

Quando devo passare qualche dato non safety alla parte safety, lo appoggio in un'area di memoria dedicata(tipicamente db, ma potrebbe essere anche area M), devi dichiarare un fc di presafety, ti fai tutti gli appoggi del caso e  poi usi gli appoggi nel safety.

 

 

[ETR]

Ciao @Mattia Spoldi, 

 

Solitamente tutti gli interscambi li eseguo sempre in aree dedicate (prassi mantenuta anche in altri ambiti), ma per questioni varie anche dettate dalla esiguità del programma, quel famoso BOOL dall'HMI era piazzato dritto.

 

Oggi ho modificato il segmento e terrò monitorata la questione. 

 

Per curiosità sono poi andato a controllare i programmi di altri impianti che non sono miei e che hanno in pancia Safety S7 300 e S7 1500. Sono esattamente quello che il manuale dice di non fare. Tutta una accozzaglia di logiche senza ritegno, ma che non hanno mai dato uno che sia uno blocco (100:150 segmenti).

 

Safety Guideline

 

Support

 

Buona serata

 

Ennio