Page History

...

messi in bypass su DBFile del DEVIL628 gli elementi DHSTB002, QUATB003 e QUATB004. 

...

...

Data: 21/01/2021 
Oggetto: Data errata su dante003 (ntp spento) 
ID: 20210121.1 
Autore: P.C. 
Problema: La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987)

...

Impostata data a mano e riavviato di nuovo il servizio ntp da utente root

...

 
Soluzione: Il client ntp era spento. Lanciato di nuovo da utente root con il comando /usr/lib/inet/xntpd 
Descrizione:  

Un operatore ha aperto il ticket http://www.lnf.infn.it/acceleratori/public/trouble/updateList.php?id=5730 descrivendo un problema di data errata durante il salvataggio di un dataset. 

 A.S. ha trovato in effetti la data errata sulla macchina dante003 e l’ha reimpostata manualmente da utente root con il comando date mmddHHMMyyyy (dove mm è il mese a due digit, dd il giorno a due digit, HH è l'ora in formato 24 ore a due digit, MM i minuti a due digit e yyyy l’anno a quattro digit).

...

Lanciando il comando ps -fe | grep ntp

...

si nota però che sulla macchina dante003 il client ntp non sta girando

...

(lanciando il comando ntpq -c peers si nota che sulle altre force l’output è una lista di server ntp mentre sulla dante003 viene stampato un messaggio di errore)

...

, mentre sulle altre force si. 

Si provvede quindi a rilanciare il client ntp

...

sulla dante003 da utente root con il comando /usr/lib/inet/xntpd e si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

...

Si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Con il comando date si

...

controlla che la data sia corretta e con il

...

comando ntpq -c peers

...

 l’output è correttamente una lista di server ntp. 

...

Data: 2115/01/2021 

Oggetto: Data errata su dante003 (ntp spentoValori del vuoto e rawData vuoti o a zero (0) 

ID: 2021012120210115.1 

Autore: P.C. 

Problema: La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987) Dati del vuoto assenti o uguali a zero. Idem per la pagina rawData 

Soluzione: fermare in ordine devil 205, 203, 202; Chiudere devil 203; Riaprire devil 203 con “Manual Management” da sysreset; far partire in ordine devil 202, 203 e 205.Soluzione: Il client ntp era spento. Lanciato di nuovo da utente root con il comando /usr/lib/inet/xntpd 

Descrizione:  Un operatore ha aperto il ticket

Sandro De Biase segnala che i valori del vuoto dalla sala controllo si vedono, mentre dalla pagina web di dafne http://wwwdafne.lnf.infn.it/acceleratori/public/trouble/updateList.php?id=5730 descrivendo un problema di data errata durante il salvataggio di un dataset. 

A.S. ha trovato in effetti la data errata sulla macchina dante003 e l’ha reimpostata manualmente da utente root con il comando date 012016322021 

Lanciando il comando ps -fe | grep ntp si nota però che sulla macchina dante003 il client ntp non sta girando (lanciando il comando ntpq -c peers si nota che sulle altre force l’output è una lista di server ntp mentre sulla dante003 viene stampato un messaggio di errore), mentre sulle altre force si. 

Si provvede quindi a rilanciare il client ntp sulla dante003 da utente root con il comando /usr/lib/inet/xntpd e si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Con il comando date si controlla che la data sia corretta e con il comando ntpq -c peers l’output è correttamente una lista di server ntp. 

Data: 15/01/2021 

Oggetto: Valori del vuoto e rawData vuoti o a zero (0) 

cgi-bin/vs.csh no (restano tutti a zero). Ho notato che quel grafico del vuoto viene generato dallo script /space/daq/status/dafnePlots.csh che a sua volta lancia più generateJPEG con diversi parametri. Visto che gli UDPServer su dafne girano senza problemi ed il problema sembra nella parte che genera i dati, ho fatto le seguenti operazioni:  

• Ho provato a far riavviare il devil202 ma non ha sortito effetto; 

• Sono entrato in VNC sulla console in sala controllo ed ho notato che stoppando il devil203 e riavviandolo apparivano dei warning nel campo log del devil (segnalando una discrepanza di tempo). Allora l’ho chiuso e riaperto col tool “Manual Management” della SysReset ed ho fermato in ordine il devil205, 203 e 202. Ho aspettato 10 secondi ed ho fatto ripartire prima il devil202, poi il 203 (stavolta non sono apparsi warning) ed infine il 205. 

Rilanciando a mano il comando /space/daq/status/dafnePlots.csh ho notato che le immagini finalmente contengono i dati, di conseguenza il problema è risolto. 

Data: 23/11/2020 

Oggetto: Font di LabVIEW in sala controllo più grandi (su solaris) dopo riavvio sunray server 

ID: 20201123ID: 20210115.1 

Autore: P.C. Problema: Dati del vuoto assenti o uguali a zero. Idem per la pagina rawData 

Soluzione: fermare in ordine devil 205, 203, 202; Chiudere devil 203; Riaprire devil 203 con “Manual Management” da sysreset; far partire in ordine devil 202, 203 e 205. 

Descrizione:  

Sandro De Biase segnala che i valori del vuoto dalla sala controllo si vedono, mentre dalla pagina web di dafne http://dafne.lnf.infn.it/cgi-bin/vs.csh no (restano tutti a zero). Ho notato che quel grafico del vuoto viene generato dallo script /space/daq/status/dafnePlots.csh che a sua volta lancia più generateJPEG con diversi parametri. Visto che gli UDPServer su dafne girano senza problemi ed il problema sembra nella parte che genera i dati, ho fatto le seguenti operazioni:  

• Ho provato a far riavviare il devil202 ma non ha sortito effetto; 

• Sono entrato in VNC sulla console in sala controllo ed ho notato che stoppando il devil203 e riavviandolo apparivano dei warning nel campo log del devil (segnalando una discrepanza di tempo). Allora l’ho chiuso e riaperto col tool “Manual Management” della SysReset ed ho fermato in ordine il devil205, 203 e 202. Ho aspettato 10 secondi ed ho fatto ripartire prima il devil202, poi il 203 (stavolta non sono apparsi warning) ed infine il 205. 

Dopo un riavvio del sunray server (per consumo eccessivo di ram), le barre dante in sala controllo avevano i font “sballati” (più grandi del solito, con conseguente disallineamento delle righe degli elementi nei mag terminal e nei menù delle applicazioni LabVIEW). Per risolvere la problematica, ho dovuto modificare la dimensione dei font (Application Font, System Font, Etc) dalle opzioni di labview (Tools -> Options… -> Fonts) che era diventata 10 invece di essere 9. Dopo averla reimpostata correttamente, ho chiuso labview, fatto logout dalla sunray e riloggato. I font ora sono corretti e tutto funziona senza problemi (unica nota: il menu’ dell’applicazione con il disegno di dafne è diventato in grassetto, ma si vede bene). 

NOTA: probabilmente, il file di configurazione delle preferenze di labview in qualche modo si è corrotto. La prossima volta che dovesse ricapitare una cosa simile, provare prima a ripristinare il file delle pref al path /u1/dafne/.labviewrc con il suo backup presente in /u1/dafne/.labviewrc.20201123.saveRilanciando a mano il comando /space/daq/status/dafnePlots.csh ho notato che le immagini finalmente contengono i dati, di conseguenza il problema è risolto. 

Data: 2328/1110/2020 

Oggetto: Font di LabVIEW in sala controllo più grandi (su solaris) dopo riavvio sunray serverPlot dei rawData su dafne.lnf.infn.it non visibile con errre 

ID: 2020112320201028.1 

Autore: P.C. 

Descrizione:  

Dopo un riavvio del sunray server (per consumo eccessivo di ram), le barre dante in sala controllo avevano i font “sballati” (più grandi del solito, con conseguente disallineamento delle righe degli elementi nei mag terminal e nei menù delle applicazioni LabVIEW). Per risolvere la problematica, ho dovuto modificare la dimensione dei font (Application Font, System Font, Etc) dalle opzioni di labview (Tools -> Options… -> Fonts) che era diventata 10 invece di essere 9. Dopo averla reimpostata correttamente, ho chiuso labview, fatto logout dalla sunray e riloggato. I font ora sono corretti e tutto funziona senza problemi (unica nota: il menu’ dell’applicazione con il disegno di dafne è diventato in grassetto, ma si vede bene). 

NOTA: probabilmente, il file di configurazione delle preferenze di labview in qualche modo si è corrotto. La prossima volta che dovesse ricapitare una cosa simile, provare prima a ripristinare il file delle pref al path /u1/dafne/.labviewrc con il suo backup presente in /u1/dafne/.labviewrc.20201123.save 

Data: 28/10/2020 

Oggetto: Plot dei rawData su dafne.lnf.infn.it non visibile con errre 

ID: 20201028.1 

Autore: P.C. 

Descrizione:  

Dal vuoto si segnala che alla url http://dafne.lnf.infn.it/cgi-bin/rawData quando si prova a “plottare” un elemento appare un errore. 

Dal vuoto si segnala che alla url http://dafne.lnf.infn.it/cgi-bin/rawData quando si prova a “plottare” un elemento appare un errore. 

Dopo diagnosi, si è scoperto che la cartella /space/Dopo diagnosi, si è scoperto che la cartella /space/daq/www/scratch era dell’utente daq e del gruppo dcs, mentre il web server gira come nobody:nobody. Di conseguenza, la pagina web che chiamava lo script /space/daq/www/cgi-bin/generateJPEG dava errore perché questo script provava a salvare l’immagine generata nella cartella scratch ma non ne aveva i permessi. 

La cartella è stata reimpostata a nobody:nobody con permessi in rwx per tutti gli utenti e la pagina non ha più avuto problemi.  

Data: 30/06/2020 

Oggetto: modifica a IPTable.DBFile 

...

Inserito DEVIL671 nel file IPTable.DBFile per test alimentatori BTF2. Documentazione su Confluence aggiornata.  

Data: 05/05/2020 

Oggetto: http://dafne.lnf.infn.it/cgi-bin/rawData modificato per visualizzare dati di vecchi elementi non in linea 

...

ATTENZIONE: Se non si utilizza la pagina ma si modifica a mano la URL per avere dati più velocemente, ricordarsi che la patch permette di cercare i nomi nuovi per date antecedenti alla modifica del nome, ma se si cerca con il nome vecchio per date successive al cambio del nome, lo script non fa nulla e di conseguenza non si otterranno dati.  

Data: 05/05/2020 

Oggetto: dante002 riavviata 

...

 
ATTENZIONE: inaspettatamente, insieme alla dante002  si riavvia anche la dante004 (da investigare se c'è un errore di configurazione di ponticelli o di qualche parametro in vram che causano il riavvio su sysreset. Da notare che le altre Force NON si sono riavviate).  

Data: 02/05/2020 

Oggetto: modificato DEVIL205 (per utilizzo con il nuovo DCT Agilent Ethernet) 

...

NOTA: il VI readCurrent_mc.vi viene inizializzato due volte: nella InitHWICM e nel frame di init della DDDCtrl. Questo non crea alcun problema perchè la modalità "init" del VI non fa altro che recuperare il mcConnectionID dalla globale e quindi non interferisce con le altre istanze del VI che eventualmente stanno già girando in modalità "run".  

Data: 25/04/2020 

Oggetto: modificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

...

Nel file serverConfigFile.conf, gli elementi DCTEL001 e DCTPS001 sono stati cambiati con DCTEL002 e DCTPS002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla i nuovi DCT Ethernet Agilent dei monitor di corrente degli anelli.  

Data: 26/02/2020 

Oggetto: modificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

...

Nel file serverConfigFile.conf, l'elemento RDS42001 è stato cambiato in RDS42002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla il generatore di frequenza. 

Data: 21/01/2020 

Oggetto: Cambio permessi su shares NFS 

...

Monitorare come va il sistema di controllo.  

Data: 20/01/2020 

Oggetto: Sostituzione dafneswitch con moxa in sala strumentazione per seriali target solaris 

...

NOTE Hardware: Sono stati realizzati dei cavetti da RJ45 a RS-232 con RX e TX invertiti (per parlare con le force). Sono connessi sulle porte 3-7 del moxa in questione ed hanno sopra di loro una scritta con pennarello ROSSO. Solo uno di questi connettori, connesso alla porta 2, ha una scritta di colore BLU (Moxa RS232): questo non inverte i segnali di RX e TX (è dritto). Difatti è connesso con un secondo cavetto che converte una DB9 ad una DB25 ed inverte RX e TX, ed è connesso alla dante002.  

Data: 09/10/2019 

Oggetto: Connettore seriale su DHRTT001 sembra inaffidabile 

...

Viene segnalato che il connettore seriale del cavo che arriva al DHRTT001 (Sala Modulatori) è lento e provoca falsi contatti. Valutare se da sostituire o comunque da tenere d’occhio. 

Data: 27/09/2019 

Oggetto: VNC display del DEVIL675 nero e DEVIL dead 

...

$ ps -fe | grep Xvnc il processo XVnc :75 e DEVIL675 compare! 

Data: 17/07/2019 

Oggetto: Modifica script per avvio/reset VNC per devil serie 7 

...

NOTA: Ci sono altri controlli sul numero del devil: ad oggi vengono accettati devil della serie 6 e 7! Nel caso si volessero aggiungere altre serie di devil, riaprire lo script /u2/dcs/script_linux/devil_mngr.sh ed aggiungere le nuove serie nei controlli sul numero del devil;  

Data: 03/04/2019 

Oggetto: configurazione porte switches vLAN Apple 

...

SWMOD1 Porte 7-10 

SWBTF Porte 9-10  

Data: 03/04/2019 

Oggetto: Problema riavvio CPU force e DAFNE dovute a server NFS krunc spento 

...

Data: 03/04/2019 

Oggetto: Lextel 23 spenta 

...

In uno dei crate VME di livello 2, è presente la Lextel 23 spenta. Questa era utilizzata dall'ex devil Apple 361 che gestiva le flags. Adesso le Flags sono gestite dal DEVIL661 che gira su VMIC. La Lextel è una ottica "pura" e quindi non da problemi di rumore se la compagna a livello 3 è spenta e non manda il carrier. Si può togliere.  

Data: 26/03/2019 

Oggetto: QUATM002, QUATM003 intervento definitivo per ripetuti problemi di fuori comunicazione 

...

Si testa muovendo i connettori mentre si osserva sul posto il driver di comunicazione: connessione stabile.  

Data: 19/03/2019 

Oggetto: Modifiche DBFile per ripartenza marzo 2019 

ID: 20190319.1 

Autore: A.S. 

  DEVIL 646 

rimossi quadrupoli skew QSKPL107, QSKPS100 e sostituiti con canali DUMMY011, DUMMY012 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

  DEVIL 640 

rimossi quadrupoli skew QSKES100, QSKEL107 e sostituiti con canali DUMMY010, DUMMY013 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

  Create le directories 

AAA_OLD_DEVIL640_20190311 

...

e copiatici dentro i DBFiles di prima della modifica 

  Rimossi da 

/u2/dcs/space/uniDatabase/elementaryAreas/MRe/MRe_quadrupoles_skew.cnf 

...

/u2/dcs/space/uniDatabase/functionalAreas/MRe/MRe_quadrupoles_skew.cnf 

QSKES100 

QSKEL107 

/u2/dcs/space/uniDatabase/elementaryAreas/MRp/MRp_quadrupoles_skew.cnf 

...

/u2/dcs/space/uniDatabase/functionalAreas/MRp/MRp_quadrupoles_skew.cnf 

QSKPL107 

QSKPS100 

Nuovi correttori MRs 

Rimossi DEVILs 

636 

637 

643 

645 

Rimpiazzati Rimpiazzati da 664 e 665   

Rimosse le seguenti Main Units 

...

SIMEL101, SIMES101, SIMES102, SIMPL201, SIMPS101, SIMEL201, SIMPL202, SIMPS201 

DEVIL602   

Create directory 

AAA_OLD_DEVIL602_20190318 

e copiatici dentro i DBFiles di prima della modifica   

Modificati files DBSta e DBDyn: rimessi in linea QUAI1023 (Add 00) e QUAI1014 (Add 07). 

...

/u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_quadrupoles.cnf   

DEVIL619 

MRe 

MRe_correctors_C_Lamb 

...

e copiatici dentro i DBFiles dei DEVIL 619 di prima della modifica. 

  /u2/dcs/space/uniDatabase/elementaryAreas/ MRp/MRp_correctors_C_Lamb.cnf 

...

CHHEI102 

CHHEI202 

CHHEI101  

Data: 07/02/2019 

Oggetto: Nuova versione finestra Odoscopio.vi (da 1.94 a 1.95) 

...

Resta da verificare la corretta calibrazione della finestra (calcolata su di una macchina a 500 MeV mentre ora è ben al di sopra per PADME) che si farà in seguito con Foggetta e Di Giulio.  

Data: 22/01/2019 

Oggetto: Installazione VIPM e modulo MODBUS su VMs del controllo 

...

LabVIEW 2015: vldantedev701 (192.168.198.210) - vldantedev702 (192.168.198.211)  

Data: 09/11/2018 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

...

Si ri-confermana quindi la precarietà del "monchino" o del connettore del cavo seriale lato MOXA (falsi contatti o crimpatura difettosa). CONTROLLARE connettore e SOSTITUIRE monchino.  

Data: 04/12/2017 

Oggetto: file fast.stat generato dal DUMPER malformato 

...

smb://nasda.lnf.infn.it/control/docs/2_purgatory/Dumper/dumper\ ConfigFile\ analisi.docx  

Data: 25/05/2017 

Oggetto: situazione installazione versione newOCEM_x.x alla data attuale 

...

Dopo due riavvii ha funzionato tutto correttamente… restano i dubbi sul perché si sia comportato così, visto che sulla stessa macchina c’era in run un altro devil che andava sullo stesso MOXA e funzionava correttamente, sia prima che dopo i riavvii. 

Data: 25/05/2017 

Oggetto: situazione installazione versione newOCEM_x.x alla data attuale 

...

Data: 16/05/2017 

Oggetto: fermata di maggio - fase 2 lavori cablaggio alimentatori OCEM 

...

Data: 16/05/2017 

Oggetto: fermata di maggio - calendario 

...

Data: 14/04/2017 

Oggetto: Connessione difettosa alimentatore OCEM 

...

Modalità seriale: native 

Data: 10/04/2017 

Oggetto: connessione difettosa alimentatore OCEM 

...

Il cavo difettoso è quello del nuovo cablaggio singolo alimentatore. 

Data: 10/04/2017 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

...

Si confermano quindi i dubbi sul "monchino" o sul connettore del cavo seriale lato MOXA (falsi contatti o crimpatura difettosa). SOSTITUIRE connettore e monchino. 

Data: 21/03/2017 

Oggetto: Nuovo cablaggio alimentatori in sala modulatori 

...

Creato script eseguibile “switch_chaos_dafne.sh” dentro /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/ che cambia le configurazioni tra chaos e dafne (sia come DBFile che come IPTable)  

Data: 12/01/2017 

Oggetto: sostituzione DEVIL361 con DEVIL661 

...

Prossimo step (dopo collaudo e uso senza problemi del nuovo sistema FATTO ): rimozione DEVIL Apple, lextel da livello 3 e 2, riconfigurazione del sysreset-VMICReset per funzionare come unico processore sul bus.  

Data: 07/12/2016 

Oggetto:  

...

E' stato rimpiazzato da due MOXA 8 porte (192.168.192.33 per QSK elettroni e 192.168.192.34 per QSK positroni). Aggiornato file di configurazione nella macchina virtuale  e documentazione Excel.  

Data: 05/12/2016 

Oggetto: Rottura moxa 16 porte ( 192.168.190.46) corretori skew e+ e- 

...

Devil 651 e 657 bloccati, entrati in sala Dafne, trovato moxa 16p spento 192.168.190.46 e non recuperabile, abbiamo sostituito HW con un moxa 16p 192.168.190.45 e rimpiazzata l’entry nel driver moxa.  

Data: 10/11/2016 

Oggetto:  

...

Dato che gli errori si verificano su tutti, il problema sembra essere sul MOXA o sul cavo o sullo SWITCH 

Data: 24/10/2016 

Oggetto:  

...

currRead,0.004273,0.0,0.0,280.0,0.5 (era 0.1),1.0 (era 0.5) 

Data: 24/10/2016 

Oggetto: Controllo magneti OCEM lento - DEVIL625 

...

La situazione è migliorata apprezzabilmente anche se ,nel caso più comandi arrivino sullo stesso DEVIL, i contextual checks causano sempre un rallentamento della control.  

Data: 14/09/2016 

Oggetto: Problema con SCHES101_INT - non riesce ad andare in OPER 

...

1. Problema gia verificato in data 04/11/2014.

Data: 13/09/2016 

Oggetto: Corruzione firmware NI-cDAQ-918X 

...

# NOTA: Non è mai stato eseguito hard-reset del cDAQ che in parte può spiegare il comportamento inusuale del device sulla rete 

Data: 12/09/2016 

Oggetto: Bug di Caronte 

...

Soluzione temporanea: riavviare Caronte con il VI di inizializzazione aperto e con breakpoint; Alla chiamata del VI di init, quando entra il breakpoint, fare RUN, togliere a mano l'errore in uscita e sganciare. Attenzione: il VI di init viene chiamato due volte e l'operazione deve essere fatta entrambe le volte. Poi rimuovere il breakpoint e richiudere tutto. 

Da fissare! 

Data: 06/09/2016 

Oggetto: problema su migrazione VMs fra hosts con HW/performances diversi 

...

Facendo prove di migrazione di VM da host più performanti tipo M620 verso M610, i devil time critical, ovvero quelli che usano drivers per la comunicazione con gli alimentatori, mostrano problemi di timeout sulla comunicazione con gli alimentatori stessi. La migrazione inversa (VM da M610 -> M620) non evidenza lo stesso problema. Di fatto il problema può essere associato a come la VM calcola il proprio tempo al primo bootstrap, ereditando variabile di sistema dall’host fisico. Host diversi impongo alle VM variabili di sistema diversi quindi tempi macchina diversi che possono influenzare il timeout imposti al devil. La possibile soluzione su cluster XEN non omogenei è avere l’emulazione del VCPU conforme con tutte le CPU oppure imporre al KERNEL della VM il ricalcolo del tempo a seguito di una migrazione.  

Data: 31/08/2016 

Oggetto: modifica DBFiles DEVILs 647 e 650 

...

Al momento quindi, i links NON DEVONO essere rediretti sui DBFiles ".CHAOS".  

Data: 12/08/2016 

Oggetto:  

...

Documentazione dettagliata su nasda nel file /control/docs/3_hell/DEVIL_eth program/changelog DEVIL  

Data: 12/08/2016 

Oggetto:  

...

Documentazione dettagliata su nasda nei files control/docs/0_classes/XXX/changelog XXX  

Data: 29/06/2016 

Oggetto: Sostituita vmic dante074 con dante055 (devil 622, kicker positroni) 

...

Il DEVIL622 viene segnalato come morto. Si riavvia la VMIC dante074 con il tappo da 50ohm in sala strumentazione ma non sortisce alcun effetto. Si entra in sala e la VMIC non da segni di vita se non nel led verde del POWER ON. Si sostituisce con la dante055 (batteria cambiata e BIOS riconfigurato) e si prepara sul server beatrix il file system della VMIC nuova per lanciare i devil al suo avvio. Modificato anche l’IPtable.DBFile per associare il DEVIL622 alla vmic dante055.  

Data: 20/06/2016 

Oggetto: problema GPIB-ENET/1000 kickers lato elettroni 

...

Riavvio della vm 192.168.198.131: tutto ok, GPIB Explorer ok.  

Data: 15/06/2016 

Oggetto: problema GPIB-ENET/1000 kickers lato elettroni 

...

AGGIORNAMENTO: nell'ipotesi che  il GPIB-ENET/1000 sia colpito da radiazione proveniente dalla TL e-, è stato spostato sopra il rack. 

Data: 14/03/2016 

Oggetto: Sostituzione GPIB-ENET/1000 kickers lato elettroni 

...

Il DEVIL690 risultava bloccato sull’initHW. E’ stato riavviato più volte ma la situazione non cambiava. E’ stata riavviata anche la macchina virtuale ma continuava a non funzionare. Si è deciso di andare a vedere i 4 GPIB controllati da quel devil ed è stato trovato quello in posizione kickers elettroni con l’errore 11 (firmware danneggiato). E’ stato quindi sostituito ed è stata avviata la pratica per l’invio in riparazione di quello rimosso. E’ già la seconda volta che un oggetto di questo tipo si rompe, sempre in quella posizione (se dovesse ripresentarsi lo stesso problema conviene anche sostituire l’alimentatore del GPIB-ENET e studiarne una nuova posizione nei limiti consentiti dal cavo GPIB).  

Data: 09/11/2015 

Oggetto: errore "local error" sul crate delle LEXTEL dell'orbita 

...

Si fa un riavvio di livello 2: ok. 

Test dell'orbita: ok.  

Data: 19/11/2015 

Oggetto: down del SunRay server 

...

ATTENZIONE: Etichettatura, relativa alla vecchia linea seriale dipolo BTF, insufficiente (potrebbe indurre in errore). 

Data: 17/03/2015 

Oggetto: Ripetute perdite di connessione con sistemi CompactDAQ della RF

ID:20150317

Autore: A.S., R.G.

Our setup (see fig. 1) consists of three CompactDAQ crates connected to a dedicated VLan and controlled by a LabVIEW 2012 program running on a Windows computer, which is connected to the same VLan.

Image Added

Fig. 1 - CompactDAQ crates connection layout

With this setup, we are suffering frequent connection drops between the Windows computer and the CompactDAQ modules (random disconnections of one or more modules installed into one or more crates). When this happens, we have to:

• stop the LabVIEW program
• recover the lost connection/s with MAX start the LabVIEW program again 

At first, we deeply checked the network health and performance and it turned out to be ok.
Then — looking at our Nagios monitoring system — we looked for any correlation between the disconnection events and the Windows machine parameters logged by Nagios and we found a strict and repetitive concurrence between the connection drops and the Windows system time synchronisation events.

Image Added

Fig. 2 - Plot of the Windows System Time Offset (respect to our ntp server) from the Nagios monitoring system 

Looking at the Nagios “system time offset” plot (see fig. 2), three different regimes can be identified:

1. Until the 5th day of week 09

   The synchronisation period is set to 24 hours.

   The System Time drifts of few seconds per day (respect to the ntp server ) and then it re-synchronises. We didn’t experience connection drops in this condition;

2. From the 5th day of week 09 up to the mid 6th day of week 11

   The synchronisation period is set to 1 week.

   The System Time drifts of about 30 s per week and then it re-syncs. We had two connection drops in correspondence of the two big re-syncs;

3. From the mid 6th day of week 11 onwards

   The synchronisation period is set to 1 hour.

   The System Time doesn’t significantly drift. We didn’t experience connection drops in this condition.

We guess that something happens about the CompactDAQ connection management when contiguous TCP/IP packets have their timestamps mixed up due to the sharp time reset. 

Data: 27/01/2015 

Oggetto: Finestra dell’orbita in OVERSAMPLING senza nessun dato e DEVIL366 fuori comunicazione 

...