- Questo topic ha 9 risposte, 4 partecipanti ed è stato aggiornato l'ultima volta 4 anni, 5 mesi fa da
.
-
Post
-
Su un PLC SlimLine in funzione da un paio di mesi ha cominciato ad andare ripetutamente in stop. Avevo un altro PLC in casa e ho provveduto alla sostituzione, il nuovo PLC non ha avuto più problemi. Ma lo strano che anche lo SlimLine che ho sostituito lasciandolo acceso nel mio studio non ha dato problemi da giorni. Ho rilevato il log dallo SlimLine che andava in blocco, eccone un estratto.
[E] SFR050 [28/08/2014 01:40:18] 1020, Exception:1 At:0x00060510
[E] SFR050 [28/08/2014 15:26:18] 1020, Exception:1 At:0x00060510
[L] SFW184 [28/08/2014 15:26:18] 6040, Restart:1, ApplID:0x61E0353BNon ho trovato documentazione per risalire al significato di questa exception 1 At:0x00060510, mi verrebbe da pensare ad un errore di accesso alla memoria.
Nelle ultime versioni del sistema operativo abbiamo sostituito il numero di eccezione con un acronimo di riferimento, ecco un elenco delle eccezioni di programma.
Except: UNDEF, Exception 0: Eccezione non definita
Except: DAT_ABORT, Exception 1: Indirizzo memoria errato (Il programma ha fatto accesso ad una area dati errata)
Except: PREFETCH, Exception 2: Istruzione errata (Il programma contiene una istruzione errata)
Except: IDISABLE, Exception 3: Disabilitazione interrupt
Except: IENABLE, Exception 4: Abilitazione interrupt
Except: WDOG, Exception 5: Watch dog (Il programma ha un tempo di esecuzione superiore al tempo di controllo)
Except: IVECTOR, Exception 6: Corruzione vettori interrupt (Si è sovrascitta l’area di memoria dedicata ai vettori)
Except: REBOOT, Exception 7: Reboot sistema (Il sistema è stato riavviato)
Except: SYSTIME, Exception 8: Counter system time (Si è sovrascitta l’area di memoria dedicata ai counters di sistema)Nel tuo caso il codice di eccezione 1 indica è un Data abort exception, questo significa che il programma ha fatto un accesso ad un’area di memoria non consentita. Questo capita solitamente quando si utilizzano puntatori che erroneamente (Perchè sporcati dal programma) vanno a puntare zone di memoria non accessibili. Può succedere anche nel caso di array il cui indice è fuori range.
Il fatto che per un pò ha funzionato ed ora funzioni, può essere legato ad un limite posto in memoria tampone che si è sporcato e/o ad una parte di programma che si attiva solo su certe condizioni logiche e che non si era mai verificata prima e non si stà più verificando ora (Tantomeno nel tuo laboratorio dove tieni il solo sistema acceso senza agire sugli I/O).
Per meglio comprendere quanto ho espresso nel post precedente riporto lo screenshot di un programma in ST che dimostra come sia facile generare eccezioni di programma a seguito di facili sviste.
Per aiutare a capire dove il problema si è manifestato è possibile risalire dall’indirizzo di programma indicato con l’eccezione, se prendiamo ad esempio il mio programma mandandolo in esecuzione lo SlimLine si arresta. Con Toolly è possibile connettersi in Telnet e con il comando Syslog ci verrà indicata l’eccezione (Screenshot). Come si vede si è manifestata all’indirizzo 0x000600C4.
In LogicLab dal menù Project -> Options si accede alle opzioni di progetto e nel tab Build output è possibile abilitare il tick di inclusione codice sorgente (Screenshot). Compilando il progetto nella cartella si troverà un file NomeProgetto.lst, editando questo file al suo interno si trovano i riferimenti tra l’indirizzo di programma ed il codice sorgente. Ecco cosa si vede nel mio programma
#17 ST @Ptr {L:7}
(*) USINT
000600BC E59FC120 ldr r12, [pc, #+288] ; 0x400054B0
000600C0 E59C3000 ldr r3, [r12]
000600C4 E5C30000 strb r0, [r3]Come si vede all’indirizzo 000600C4 si trova la parte di codice relativa alla compilazione del programma alla linea 7 {L:7}.
Analogamente a quanto descritto sto avendo dei problemi su uno Slimline con il target 12.0. Ho seguito le indicazioni riportate nel post precente e nel file di log trovo quanto segue:
…
[L] SFW184 [21/01/2016 18:17:23] 6000, Run ApplID:0x86BAD4BB[E] SFR050 [22/01/2016 08:47:30] 1020, Except: DAT_ABORT At:0x000055E0[L] SFR050 [22/01/2016 08:47:30] 1000, System power on[L] SFW184 [22/01/2016 08:47:30] 6040, Restart:1, ApplID:0x86BAD4BB[L] SFW184 [22/01/2016 08:47:34] 6000, Run ApplID:0x86BAD4BB[E] SFR050 [22/01/2016 08:59:53] 1020, Except: DAT_ABORT At:0x000052C4…
Esaminando il file .lst però non riesco ad identificare l’area di origine del problema, in quanto il programma mi pare essere allocato oltre l’indirizzo 60000. Potete aiutarmi ?L’eccezione DAT_ABORT (Data abort) si ha quando si tenta di accedere ad un indirizzo di memoria non esistente.
Giustamente come fai notare tu il programma sviluppato dall’utente è allocato dopo l’indirizzo 0x60000, agli indirizzi riportati nel file di log corrispondono funzioni del sistema operativo. Se hai la versione SFW184B000 ad indirizzo 0x000052C4 è allocata la funzione memcpy che è richiamata dalla funzione Sysmemmove, mentre ad indirizzo 0x000055E0 è allocata la funzione memset che è richiamata dalla funzione Sysmemset.
Queste funzioni operano con dei puntatori, in generale attenzione quando si usano puntatori se l’indirizzo caricato nel puntatore è sabagliato si può incorrere in questo tipo di eccezione.
Aggiungo inoltre che magari tu non stai usando direttamente queste funzioni ma utilizzi una funzione e/o un blocco funzione che a sua volta utilizza queste funzioni.
Il mio SlimLine si è appena arrestato per una eccezione:
[E] SFR050 [14/11/2019 16:04:05] 1020, Except: WDOG At:0x004B9FDC
C’è modo di capire a cosa può esser dovuto?
Gli unici cicli FOR sono da 0 a 3, da o a 4 e da 0 a 0.
Non uso puntatori “epliciti” nel senso che la funzione ADR la uso per le funzioni di scrittura in stringa ADR(stringa).
Un’altra cosa che vorrei capire: in warning precedenti la stringa era [W] SFR055: cosa identificano SFR050 e SFR055?
L’eccezione di WDOG capita se l’esecuzione del ciclo di programma richiede un tempo superiore al tempo di watch dog. Ma Lo SlimLine con questa eccezione in accordo alla normativa esegue un reboot. Se al successivo reboot il programma non genera più eccezioni tutto funziona normalmente.
Se si ripetono eccezioni, dopo 10 consecutive il programma và in stop. Se hai LogicLab collegato al sistema il programma và in stop già alla prima eccezione.
Non capisco il ciclo FOR da 0 a 0, tieni presente che il contenuto del ciclo viene eseguito 1 volta, Nel programma di esempio che posto dopo il ciclo FOR i vale 1. Quindi se nel ciclo hai qualcosa che non vuoi venga eseguito ricordati che il programma lo esegue.
i:=0;
FOR a:=0 TO 0 DO i:=i+1; END_FOR;Le warnings non sono significative, i codici SFR050, SFR055, ecc sono i codici delle varie librerie utilizzate dal sistema operativo ed hanno un significato solo per noi.
Se l’eccezione capita sporadicamente è difficile trovare quale parte del programma la genera, se invece capita sistematicamente, basterà sezionare il programma per capire dove si genera il problema.
Il sistema è in esecuzione da un paio di mesi e s’è bloccato oggi per la prima volta. Me ne sono accorto perché in avvio mi manda una email di avviso.
Il ciclo FOR da 0 a 0 è perché cicla su un array, che al momento è composto solo da un elemento: posso mettere una variabile e vedere se ricapita (l’array mi serviva per definire dei “time trap”, orari in cui il PLC mi deve mandare dei report).
No, non ho il sistema collegato a LogicLab sempre, e come dice Lei se succede una volta ogni tanto è difficile trovare chi causa il problema.
Domani ricontrollo tutto il programma.
Le chiedo un suggerimento: ho visto che altri utenti del forum quando postano loro pezzi di codice utilizzano di frequente i cast TO_INT, TO_UDINT e via dicendo (ho visto in SysVarsnprintf usarlo per tutti i parametri della funzione). E’ necessario? Oppure se definisco le variabili del tipo corretto è superfluo? Potrebbe essere causa di eccezione?
Gli operatori TO_INT, TO UDINT, ecc sono operatori di cast, servono ad informare il compilatore che si stà trasferendo una variabile di un certo tipo in una variabile di altro tipo.
Mi spiego meglio ammettiamo di avere una variabile di tipo USINT e la passiamo ad una funzione o FB che accetta un parametro UINT o la trasferiamo in una variabile UINT, in questo caso siccome l’USINT è a 8 bit mentre l’UINT è a 16 bit non ci sono problemi ed il compilatore non dà messaggi di warning.
Ma facciamo l’ipotesi contraria, ho nel programma una variabile UINT (Che io programmatore sò di certo non assumerà mai valori superiori a 255) e la passiamo ad una funzione o FB che accetta un parametro USINT o la trasferiamo in una variabile USINT. Il nostro programma è corretto ma il compilatore ci avverte con una warning che potrebbe esserci un problema usando il cast TO_USINT informiamo il compilatore che và tutto bene siamo sicuri di quello che stiamo facendo.
Quindi se come dici le variabili che usi sono del tipo giusto non serve il cast.
Aggiungo per la valutazione della eccezione, se invii alla nostra mail di supporto il file Logs.txt presente nella cartella System, e scrivi il codice del sistema e la versione del software (Li puoi ricavare connettendoti in Telnet alla porta 23) possiamo fare una indagine e magari dare informazioni maggiori.
- Devi essere connesso per rispondere a questo topic.