CPU 313C-2DP in Step7 - OB86 e OB82 non trovati dalla CPU

[DiegoNic]

Buongiorno a tutti,

ho una CPU 313C-2DP collegata via profibus a due schede di ingressi remotati, una con numero di nodo 4 e l'altra con 5.

L'impianto è in funzione da anni, ma da qualche settimana di tanto in tanto (e purtroppo devo davvero dire di tanto in tanto perché sembra essere un evento del tutto casuale) il bus va in fault (SF) e la CPU va in stop. In diagnostica vedo i messaggi allegati nelle immagini . La CPU richiede l'OB86 e l'OB82.

Ho controllato sulla documentazione e ho capito che si tratta di due OB di diagnostica di siemens e, se ho capito bene, posso aggiungerli anche vuoti al progetto.

Quello che non mi è chiaro è se si tratti di due OB necessari oppure no e quindi se la mancanza di questi OB è la causa del fault oppure la CPU, dopo il verificarsi del bus fault che si verifica a prescindere, va a cercare questi due OB e, non trovandoli, me lo segnala nel buffer di diagnostica.

Mi è venuto questo dubbio perché il SW (che non ho scritto io) in questa CPU non è mai cambiato... quindi non mi spiego come sia possibile che all'improvviso la CPU non trovi questi due OB, ammesso che ci siano sempre stati.

 

Grazie mille a chiunque abbia un po' di tempo da dedicarmi.

Buona giornata a tutti

 

Diego

 

[Mattia Spoldi]

i 2 OB che dici servono a prevenire che la CPU vada in STOP, il fatto che manchino non è la causa degli errori che hai.

per provare a risolvere i guasti senza un tester profibus, la cosa più veloce che ti consiglio di fare, è dare un'occhiata ad i cavi ed eventualmente prova a reintestare le spinette profibus.

[drn5]

Se carichi i due OB puoi fare un minimo di controllo su alcuni dei parametri che gli OB mettono a disposizione. Come dice @Mattia Spoldi eviteresti lo stop della cpu, ma non certo la causa. Quindi a parte i cavi e i connettori ti resano da valutare le alimentazioni delle schede remote, le stesse e la cpu.

[DiegoNic]

3 minuti fa, Mattia Spoldi ha scritto:

i 2 OB che dici servono a prevenire che la CPU vada in STOP, il fatto che manchino non è la causa degli errori che hai.

per provare a risolvere i guasti senza un tester profibus, la cosa più veloce che ti consiglio di fare, è dare un'occhiata ad i cavi ed eventualmente prova a reintestare le spinette profibus.

Ciao @Mattia Spoldi,

grazie mille per la risposta. Quindi se ho capito bene, puo essere che questi due OB in effetti non ci siano mai stati ma finché il bus ha funzionato correttamente nessuno se n'è accorto e l'impianto ha lavorato senza problemi. Ora c'è qualcosa che manda il bus in fault e la CPU, non trovando gli OB, va in stop?

Ma quindi se io li aggiungo senza ancora aver risolto la causa del fault, la CPU non andrà in stop? Oppure mi dovrò aspettare lo stesso che la CPU vada in stop e mi dia nel buffer di diagnostica un messaggio come nell'immagine allegata "Periferia decentrata: Guasto stazione" ecc con l'unica differenza che non ci sarà scritto "OB richiesto: OB ... ... (OB86)" ?

 

Grazie

[DiegoNic]

40 minuti fa, drn5 ha scritto:

Se carichi i due OB puoi fare un minimo di controllo su alcuni dei parametri che gli OB mettono a disposizione. Come dice @Mattia Spoldi eviteresti lo stop della cpu, ma non certo la causa. Quindi a parte i cavi e i connettori ti resano da valutare le alimentazioni delle schede remote, le stesse e la cpu.

Ciao @drn5,

grazie per la risposta. Ok, allora con i due OB la CPU non andrebbe in Stop. Ma in quel caso diventa fondamentale implementare un controllo di coerenza sui dati che le schede mi stanno comunicando, altrimenti come altro potrei accorgermi che c'è un problema sulla rete?

 

Grazie

 

[batta]

25 minuti fa, DiegoNic ha scritto:

grazie mille per la risposta. Quindi se ho capito bene, puo essere che questi due OB in effetti non ci siano mai stati ma finché il bus ha funzionato correttamente nessuno se n'è accorto e l'impianto ha lavorato senza problemi. Ora c'è qualcosa che manda il bus in fault e la CPU, non trovando gli OB, va in stop?

Proprio così.

 

[drn5]

Potresti semplicemente alzare un merker dentro gli OB da resettare a tempo nel OB1. Una spece di watchdog. Così facendo quando la cpu richiama gli OB di errore da fuori prendi le contromisure necessarie.

La coerenza dei dati non ricordo se puoi verificarla, perchè potrebbe essere che l'immagine dell'area di scambio resti inalterarta rispetto al ciclo precedentemente concluso con successo.. è da provare.

[DiegoNic]

35 minuti fa, batta ha scritto:

Proprio così.

 

Ciao @batta,

ok grazie mille.

[DiegoNic]

30 minuti fa, drn5 ha scritto:

Potresti semplicemente alzare un merker dentro gli OB da resettare a tempo nel OB1. Una spece di watchdog. Così facendo quando la cpu richiama gli OB di errore da fuori prendi le contromisure necessarie.

La coerenza dei dati non ricordo se puoi verificarla, perchè potrebbe essere che l'immagine dell'area di scambio resti inalterarta rispetto al ciclo precedentemente concluso con successo.. è da provare.

Ok, ottimo suggerimento, grazie. Intanto farò così, e nel frattempo faccio un controllo dei connettori e delle schede cercando di risalire alla causa del problema.

Grazie mille per il prezioso aiuto.

 

Ciao

[DiegoNic]

 

45 minuti fa, drn5 ha scritto:

Potresti semplicemente alzare un merker dentro gli OB da resettare a tempo nel OB1. Una spece di watchdog. Così facendo quando la cpu richiama gli OB di errore da fuori prendi le contromisure necessarie.

La coerenza dei dati non ricordo se puoi verificarla, perchè potrebbe essere che l'immagine dell'area di scambio resti inalterarta rispetto al ciclo precedentemente concluso con successo.. è da provare.

Ultima domanda che lascio postata qui insieme ad un'immagine che magari potrà essere utile ad altri "neo" programmatori come me... nel manuale ho trovato questa lista di OB nel capitolo Diagnostica.

Per quanto detto in questa discussione, sarebbe buona abitudine inserire sempre tutti questi OB nei progetti realizzati in Step7, magari inserendo in ognuo di essi una piccola routine di gestione oppure semplicemente un merker tipo watchdog come mi suggerisci tu. Giusto?

[batta]

57 minuti fa, DiegoNic ha scritto:

Per quanto detto in questa discussione, sarebbe buona abitudine inserire sempre tutti questi OB nei progetti realizzati in Step7

Quasi sempre io inserisco tutti gli OB necessari per evitare di mandare in stop la cpu, ma ci potrebbero anche essere dei casi nei qualii lo stop della cpu è voluto.
Si tratta di capire, nel caso specifico: cosa accade in caso di errore del Profibus se la cpu non va in stop?

 

 

Modificato: 15 gennaio 2024 da batta

[Mattia Spoldi]

io normalmente li metto più o meno tutti, escludo solo l'ob121, almeno se ho sbagliato qualche puntatore e cose simili, e qualcuno mi avvisa che ho sbagliato e correggo di conseguenza.

 

Più in generale metto quelli dei possibili guasti hardware/bus ed escludo quelli relativi al programma.

[acquaman]

Io li metto tutti a fine commisioning, durante preferisco che eventuali problemi escano.

[DiegoNic]

21 ore fa, batta ha scritto:

Quasi sempre io inserisco tutti gli OB necessari per evitare di mandare in stop la cpu, ma ci potrebbero anche essere dei casi nei qualii lo stop della cpu è voluto.
Si tratta di capire, nel caso specifico: cosa accade in caso di errore del Profibus se la cpu non va in stop?

 

 

Ciao @batta, sì in effetti sono d'accordo. Metterli tutti a prescindere solo per non far andare in stop la CPU potrebbe essere più pericoloso che lasciare che ci vada. Dipende dal caso specifico. Analizzerò tutti i casi possibili. Grazie mille

[DiegoNic]

20 ore fa, Mattia Spoldi ha scritto:

io normalmente li metto più o meno tutti, escludo solo l'ob121, almeno se ho sbagliato qualche puntatore e cose simili, e qualcuno mi avvisa che ho sbagliato e correggo di conseguenza.

 

Più in generale metto quelli dei possibili guasti hardware/bus ed escludo quelli relativi al programma.

Ciao @Mattia Spoldi,

sì credo che farò una cosa del genere, diciamo quelli per l'HW sicuramente, quelli SW li userò come un meccanismo di debug che mi deve segnalare se ho fatto un errore di concetto.

 

Grazie mille

[DiegoNic]

19 ore fa, acquaman ha scritto:

Io li metto tutti a fine commisioning, durante preferisco che eventuali problemi escano.

Ciao @acquaman,

grazie mille per la risposta. Sì è una strategia sicuramente valida per poter continuare lo sviluppo mentre, in un caso come il mio, viene messo a posto il problema sul bus.

Grazie