DCS_log

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) 
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: 15/01/2021 

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

ID: 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. 

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: 20201123.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. 

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 

ID: 20200630.1 

Autore: A.S. 

Descrizione:  

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 

ID: 20200505.2 

Autore: P.C. 

Descrizione:  

La pagina http://dafne.lnf.infn.it/cgi-bin/rawData (user: dafne, pass: 1033lumi) permette di interrogare i dati raw del sistema di controllo di dafne. Il problema è che se un elemento ha cambiato nome durante la sua vita e lo si cerca con il nome nuovo, i vecchi dati non si visualizzano più. E’ stata realizzata una patch per permettere di vedere anche i vecchi dati dei tre elementi che hanno cambiato nome: 
 

• DCTEL001 rinominato in DCTEL002 dal 25/04/2020 (ticket ID: 20200425.1); 
• DCTPS001 rinominato in DCTPS002 dal 25/04/2020 (ticket ID: 20200425.1);
• RDS42001 rinominato in RDS42002 dal 26/02/2020 (ticket ID: 20200226.1); 

 
Di conseguenza, se si cerca uno di questi elementi nuovi per una data antecedente al loro essere rinominati, la pagina si occupa di cercare il vecchio nome al posto del nuovo. 
 

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 

ID: 20200505.1 

Autore: P.C. 

Descrizione:  

La console Force dante002 non risponde più sulla seriale anche se risponde in ssh. 
Si tenta un reboot da ssh ma la macchina non risale (probabilmente è caduta a prompt ok). 
Si fa un reset fisico sulla Force (fatto da Giampiero) che riparte. La seriale torna a funzionare. 

 
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) 

ID: 20200502.1 

Autore: A.S. 

Descrizione:  

Modificato DEVIL205 (DDDCtrl, InitHWICM, ICMCtrl) come segue: 

I VIs .../DCT/console/readCurrent e readCurrentFast (identici fra loro) che leggono il DCT con voltmetro HP (VME) 

sono stati sostituiti dal VI .../DCT/console/memcached/readCurrent_mc.vi che legge il volmetro Agilent (ETH). 

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 

ID: 20200425.1 

Autore: A.S. 

Descrizione:  

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 

ID: 20200226.1 

Autore: A.S. 

Descrizione:  

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 

ID: 20200121.1 

Autore: P.C. 

Descrizione: 

Sono stati cambiati i permessi sulle shares NFS da gruppo wheel a gruppo dcs (presente su tutti gli host: target solaris, vmic, macchine virtuali, sun ray server e server con servizi). 

Monitorare come va il sistema di controllo. 

Data: 20/01/2020 

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

ID: 20200120.1 

Autore: P.C. 

Descrizione: 

Visto che ogni volta c’era un problema di accesso al dafneswitch via rete, si è deciso di sostituire il CMS con un moxa da 8 porte in sala strumentazione. Il moxa è stato configurato sul NUC in sala controllo (dove gira caronte) ed è stata creata la pagina wiki per illustrare come connettersi alle force: 

http://wiki.infn.it/strutture/lnf/da/dafne/sistema_di_controllo/sviluppatori/forceconsole 

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 

ID: 20191009.1 

Autore: P.C. 

Descrizione:  

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 

ID: 20190927.1 

Autore: A.S. 

Descrizione: 

DEVIL 675 - Virtual machine 032 - VNC display 75 

• kill -9 <PID dell'XVnc del DEVIL675> 
• restart del DEVIL675 

Si riportano a seguito i comandi utili per una diagnosi (da eseguire sulla vm interessata): 

$ more /home/dafne/.vnc/vldantedev032:75.log 

$ ls -l /tmp/.X11-unix il display X75 non compare 

$ vncserver -list il display :75 non compare 

$ ps -fe | grep labview il LabVIEW con -display vldantedev032:75 non compare 

$ 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 

ID: 20190717.1 

Autore: P.C. 

Descrizione: 

Per abilitare l’utilizzo dei devil serie 7, si è resa necessaria la modifica degli script per il calcolo del display VNC. Sono stati modificati i seguenti files: 

• /u2/dcs/script_linux/devil_mngr.sh per aggiungere il parametro -name DEVIL$devil_number all'avvio del display VNC; Così facendo, la finestra VNC mostra il nome del devil e lanciando il comando ps -fe | grep Xvnc si possono vedere quali devil girano su quali display; 
• /var/www/html/devil_manager/index.php su danteweb per calcolare il display VNC come resto della divisione intera per 100 del numero del devil (così funziona anche per i devil della serie 7, 8, etc.) 

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 

ID: 20190403.3 

Autore: A.S. 

Descrizione: 

Le porte degli switches dove sono connessi tutti i devils Apple non avevano più la configurazione per: 10 Mbps, no autonegotiation, half-duplex. Pensiamo che questo possa essere la causa del problema di perdita di connessione dei devils Apple e di Caron (AKA Console100) dal server Bible che stiamo sperimentando ultimamente (forse da quando Spigone ha riconfigurato gli switches del controllo). 

Richiesta riconfigurazione delle porte degli switches che sono configurati per avere dei devil connessi su di loro: 

SWDAFNE4B Porte 11-16 

SWDAFNE2C Porta 48 

SWDAFNE1 Porta 44 

SWALIMDAFNE Porte 7-12 

SWMACC Porte 7-10 

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 

ID: 20190403.2 

Autore: P.C. 

Descrizione: 

Dopo un blackout, le FORCE non ripartivano. Rimanevano bloccate con il messaggio di errore: 

Setting default IPv4 interface for multicast:add net 224.0/4: gateway dante00[2-7] 

Il problema era dovuto al fatto che nel file /etc/vfstab dei vari target veniva montato il seguente path via NFS: 

krunc:/runcond/slow/global /u2/kloe 

ed il server krunc non è più raggiungibile (KLOE Spento). Di conseguenza la sequenza di boot si fermava in attesa della risorsa NFS. 

Commentando quella riga, le force sono ripartite senza problemi. 

Per sicurezza, anche sul server DAFNE le righe relative ai mount dei folder da kloe sono state commentate ed è stato effettuato un umount delle stesse: 

krunc:/runcond/slow/global /kloe 

krunc:/runcond/slow/curr/stat /kloenano 

krunc:/runcond/slow/trg /kloelumi 

NOTA: Mentre si debuggava l’errore del boot, abbiamo notato un messaggio di errore nella configurazione della porta ethernet dei target. Si è provveduto a modificare i files di configurazione dei target come riportato nella tabella seguente (nel file della prima scheda era presente solo il nome del target, mentre ci doveva essere l’IP seguito dalla netmask). Ora i target si avviano senza messaggi di  errore per quanto riguarda la parte ethernet. 

Data: 03/04/2019 

Oggetto: Lextel 23 spenta 

ID: 20190403.1 

Autore: A.S. 

Descrizione: 

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 

ID: 20190326.1 

Autore: A.S. 

Descrizione: 

Riguardo la problematica del 10/04/2017 e del 12/11/2015 descritta nel ticket ID: 20151112.1 

Si sostituisce il monchino+DB9 sulla porta 5 dl MOXA .40 

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 

AAA_OLD_DEVIL646_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/saveAreas/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/saveAreas/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 da 664 e 665 

Rimosse le seguenti Main Units 

(nella finestra MRCorrectorsMainUnit, rimangono solo le due SIM che pilotano le back-legs) 

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). 

Aggiunti QUAI1023 e QUAI1014 in 

/u2/dcs/space/uniDatabase/elementaryAreas/IR/IR_quadrupoles.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/IR/IR_quadrupoles.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_quadrupoles.cnf 

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

DEVIL619 

MRe 

MRe_correctors_C_Lamb 

Creata directory: 

AAA_OLD_DEVIL619_20190319 

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

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

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

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

CDVPS101 

CDVPS201 

CDVPL101 

CDVPL201 

CDHPS101 

CDHPS201 

CDHPL101 

CDHPL201 

CVVPI201 

CVVPI102 

CVVPI202 

CVVPI101 

CHHPI201 

CHHPI102 

CHHPI202 

CHHPI101 

DEVIL618 

MRe 

MRe_correctors_C_Lamb 

Creata directory: 

AAA_OLD_DEVIL618_20190319 

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

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

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

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_correctors_C_Lamb.cnf 

CDVES101 

CDVES201 

CDVEL101 

CDVEL201 

CDHES101 

CDHES201 

CDHEL101 

CDHEL201 

CVVEI201 

CVVEI102 

CVVEI202 

CVVEI101 

CHHEI201 

CHHEI102 

CHHEI202 

CHHEI101 

Data: 07/02/2019 

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

ID: 20190207.1 

Autore: P.C. 

Descrizione: 

A seguito di più ticket aperti dalla sala controllo si interviene per valutare il malfunzionamento della finestra. 

Dopo attenta analisi, si è notato che la finestra - a fronte di un comando di set partendo dai MeV - inviava i comandi relativi ai due elementi sempre e solo al devil identificato dall’element index relativo all’elemento selezionato invece di discriminare in base all’elemento da controllare (con un devil che gestiva tutti e due gli elementi il problema non si poteva notare facilmente; da quando ci sono i due devil 682 e 683 però la finestra ha smesso di funzionare correttamente). Si è provveduto a sanare il bug ed a certificare il corretto funzionamento della nuova versione. In concomitanza di questo intervento, sono state richieste altre due modifiche: una con la sostituzione del selettore 100pC - 800pc inserendo un campo di testo libero (inserita con criterio insieme a Foggetta); una cambiando i calcoli fatti sui primi ed ultimi 4 “beam index” in quanto veniva divisa la carica sia dal devil che dalla finestra ed il grafico risultante non era corretto. 

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 

ID: 20190122.1 

Autore: P.C. 

Descrizione: 

Si installa sulle seguenti VM il software VIPM ed il modulo MODBUS (tutte queste sono LabVIEW 2102 SP1) con i seguenti dettagli da segnalare: 

Labview non partiva. Il reboot della VM si è bloccato con un kernel panic dovuto ad alcuni moduli labview; Dopo un Power Off e Power On della VM dall’interfaccia oVirt, tutto è tornato funzionante: 

vldantedev023 (192.168.198.123) - vldantedev029 (192.168.198.129) 

Labview non partiva. Dopo un reboot della VM tutto è tornato funzionante: 

vldantedev027 (192.168.198.127) - vldantedev028 (192.168.198.128) - vldantedev032 (192.168.198.132) 
 

Nessun Problema: 

vldantedev015 (192.168.198.115) - vldantedev020 (192.168.198.120) - vldantedev021 (192.168.198.121) 

vldantedev022 (192.168.198.122) - vldantedev024 (192.168.198.124) - vldantedev025 (192.168.198.125) 

vldantedev026 (192.168.198.126) - vldantedev030 (192.168.198.130) - vldantedev031 (192.168.198.131) 

vldantedev033 (192.168.198.133) - vldantedev034 (192.168.198.134) - vldantedev035 (192.168.198.135) 

vldantedev036 (192.168.198.136) - vldantedev038 (192.168.198.138) 

Su alcune macchine, aprendo labview 2012 SP1 da VIPM (utente root) appare un popup di errore, ma come utente dante non è successo. Restano le seguenti macchine senza VIPM: 

LabVIEW 2010: vldantedev001 (192.168.198.101) - vldantedev014 (192.168.198.114) 

LabVIEW 2012: vldantedev101 (192.168.198.150) 

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

Data: 09/11/2018 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

ID: 20181109.1 

Autore: A.S. 

Descrizione: 

Si ripete la problematica del 10/04/2017 e del 12/11/2015 descritta nel ticket ID: 20151112.1 

Si risolve sempre smanettando il monchino+DB9 sulla porta 5 dl MOXA .40 

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 

ID: 20171204.1 

Autore: A.S. 

Descrizione: 

Il file fast.stat risultava malformato per errore nel descrittore di formato scritto nel file: 

/u2/dcs/prefs/DMP/serverConfigFile.conf 

Si veda rapporto completo su: 

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 

ID: 20170525.2 

Autore: A.S., P.C. 

Descrizione: 

problema con seriali DEVIL642 su vldantedev032 

Il devil gira velocissimo. Guardando sul MOXA si vede che le porte vengono prese dall'IP giusto ma non c'è traffico (neanche in trasmissione). 

1. si riavvia il DEVIL: Nessun miglioramento 

1. si riavvia il MOXA: Nessun miglioramento 

1. si riavvia la vm: Nessun miglioramento 

1. si passa da VISA a native: Nessun miglioramento 

1. si mette in run il DEVIL su un'altra vm (che ha lo stesso MOXA configurato): Nessun miglioramento 

1. si riavvia NUOVAMENTE la vm: OK 

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 

ID: 20170525.1 

Autore: A.S. 

Descrizione: 

La versione _newOCEM_3.2 richiede le seguenti configurazioni: 

DEVIL6XX.DBSta: 

timeouts = 10, 10, 400 

serialType = 1 (native) 

DEVIL6XX.pref:  

idleTime = 100 

Con il simbolo SW si indicano gli alimentatori che commutano durante lo switch di macchina. 

Con il simbolo [!C] si indicano i DEVILs potenzialmente sostituibili con CU !CHAOS e DEVIL7XX 

Data: 16/05/2017 

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

ID: 20170516.2 

Autore: A.S. 

Descrizione:  

Data: 16/05/2017 

Oggetto: fermata di maggio - calendario 

ID: 20170516.1 

Autore: A.S. 

Descrizione:  

Data: 14/04/2017 

Oggetto: Connessione difettosa alimentatore OCEM 

ID: 20170414.1 

Autore: A.S. 

Descrizione:  

Messo cavo temporaneo per dipolo DVRTT001. Lasciato monchino precedente. 

Il cavo difettoso è quello del nuovo cablaggio singolo alimentatore. 

Messi VI _newOCEM in DEVIL697. Nessun errore di comunicazione/protocollo nel periodo osservato (~ 30'). 

Modalità seriale: native 

Data: 10/04/2017 

Oggetto: connessione difettosa alimentatore OCEM 

ID: 20170410.2 

Autore: A.S. 

Descrizione:  

Messo cavo temporaneo (due spezzoni in serie) su porta 5 del MOXA 192.30 per dipolo DVRTT002. 

Il cavo difettoso è quello del nuovo cablaggio singolo alimentatore. 

Data: 10/04/2017 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

ID: 20170410.1 

Autore: A.S. 

Descrizione: 

Si ripete la problematica descritta nel ticket ID: 20151112.1 

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 

ID: 20170321.1 

Autore: A.S., P.C. 

Descrizione:  

Gli alimentatori da cablare a stella sono: 

Compiti da svolgere: 

Cartella contenente i nuovi DBFiles: 

/u2/dcs/db/DBFiles_3/CPU_LINUX_eth/NewChaosDafne 

preCabling/DEVIL[6UV].DB[Dyn/Sta] -> DBFiles pre cablaggio (22/03/2017) 

postCabling/DEVIL[6UV/6WX].DB[Dyn/Sta] -> DBFiles per uso DAFNE post cablaggio 

postCabling/DEVIL[7YZ].DB[Dyn/Sta] -> DBFiles per uso CHAOS post cablaggio 

Modifica seriali per devil: 

DEVIL650 (vldantedev022) 

OLD: SER15004 (QUATM009:QUATT007:QUATB001) 

NEW: SER15004 (QUATT007:QUATB001) (ASRL12::INSTR - /dev/ttyr0b) nport1601 (192.40) porta 12 

DEVIL691 (vldantedev035) 

NEW: SER15007 (QUATM009) (ASRL1::INSTR - /dev/ttyr00) nport801 (192.30) porta 1 

DEVIL658 (vldantedev015) 

OLD: SER15005 (QUATM005:QUATT011:QUATM007:QUATM008) 

NEW: SER15005 (QUATT011) (ASRL18::INSTR - /dev/ttyr11) nport403 (192.22) porta 2 

DEVIL692 (vldantedev035) 

NEW: SER15008 (QUATM005) (ASRL2::INSTR - /dev/ttyr01) nport801 (192.30) porta 2 

DEVIL693 (vldantedev035) 

NEW: SER15009 (QUATM007) (ASRL3::INSTR - /dev/ttyr02) nport801 (192.30) porta 3 

DEVIL694 (vldantedev035) 

NEW: SER15010 (QUATM008) (ASRL4::INSTR - /dev/ttyr03) nport801 (192.30) porta 4 

DEVIL653 (vldantedev034) 

OLD: SER23011 (DHRTP001:DHRTP002:DHRTE001:DVRTT002) 

NEW: SER23011 (DHRTP001:DHRTP002:DHRTE001) (ASRL2::INSTR - /dev/ttyr01) nport1601 (192.40) porta 2 

DEVIL695 (vldantedev036) 

NEW: SER23017 (DVRTT002) (ASRL5::INSTR - /dev/ttyr04) nport801 (192.30) porta 5 

DEVIL655 (vldantedev021) 

OLD: SER23015 (DHSTB001:DHSTT001:DHPTT002) 

NEW: SER23015 (DHSTB001:DHSTT001) (ASRL10::INSTR - /dev/ttyr09) nport1601 (192.40) porta 10 

DEVIL696 (vldantedev036) 

NEW: SER23018 (DHPTT002) (ASRL6::INSTR - /dev/ttyr05) nport801 (192.30) porta 6 

DEVIL656 (vldantedev021) 

OLD: SER23016 (DVRTT001:DVRTE002:DVRTE001) 

NEW: SER23016 (DVRTE002:DVRTE001)  (ASRL11::INSTR - /dev/ttyr0a) nport1601 (192.40) porta 11 

DEVIL697 (vldantedev036) 

NEW: SER23019 (DVRTT001) (ASRL7::INSTR - /dev/ttyr06) nport801 (192.30) porta 7 

DEVIL652 (vldantedev021) 

OLD: SER23010 (DHPTS001:DHSTS001:DHRTT001) 

NEW: SER23010 (DHRTT001) (ASRL1::INSTR - /dev/ttyr00) nport1601 (192.40) porta 1 

DEVIL682 (vldantedev021) 

NEW: SER23008 (DHSTS001) (ASRL9::INSTR - /dev/ttyr08) nport1601 (192.40) porta 9 

DEVIL683 (vldantedev036) 

NEW: SER23009 (DHPTS001) (ASRL8::INSTR - /dev/ttyr07) nport801 (192.30) porta 8 

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 

ID: 20170112.1 

Autore: A.S., F.G. 

Descrizione: 

Sostituzione DEVIL361 Apple/VME - Lextel 23 - Flags & GWO - Sala controllo BTF (vetrina) con VMIC dante063, DEVIL661, display 192.168.192.107:61 

In caso di un eventuale roll-back, ripercorrere le azioni della seguente lista (ovviamente, facendo l'azione opposta): 

• decommentato (come utente root) nel file /etc/rc.local della dante063 il rigo per il lancio del DEVIL661; 
• disarmati DBFiles e mappe Apple del DEVIL361, spostandoli in /DBFiles_3/disarmed/; 
• esposti DBFiles Linux in /DBFiles_3/CPU_LINUX_eth/; 
• DEVIL361disconnesso dalla rete Ethernet 10-base2 ma lasciato sul bus; 
• DEVIL361 commentato in /DBFiles_2/WorldMap.DBFile; 

• DEVIL661 de-commentato in /DBFiles_2/IPTable.DBFile; 
• nuova finestra delle Flags "combo" salvata come "Flags.vi" (quella Apple-VME è stata salvata come "Flags_1.0.vi"; 
• modificato typeDef "FL1HCIDyn" alterando l'ordine degli elementi dentro il cluster: nella finestra per Apple/VME l'ordine deve essere "sbagliato" come nella figura seguente. 
   
  Il TypeDef è stato modificato per la finestra "combo" ripristinando un ordine progressivo dall'alto vesro il basso); 
• finestra GWOMUX.vi rimossa da /pref/menu/itemsCtrl.tbl (file precedente salvato come itemsCtrl.tbl_20170111); 
• aggiornata tabella html in "dafne/space/daq/www/home/info/" (come utente daq), commentando la table-row del vecchio DEVIL361 in modo che non compaia più nella tabella che si visualizza dal link "riavvio_livello_3.htm". 

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:  

ID: 20161207.1 

Autore: A.S. 

Descrizione: Sostituzione MOXA 16 porte corretori skew e+ e- con 2 MOXA 8 porte. 

Il Moxa 16 porte (montato come detto nel ticket 20161205.1), era quello rimosso recentemente per numerosi errori di comunicazione contemporanei su tutte le linee RS232 (come detto nel ticket 20161110.1). 

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- 

ID: 20161205.1 

Autore: Olimpio Giacinti, Andrea Michelotti 

Descrizione: 

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:  

ID: 20161110.1 

Autore: A.S. 

Descrizione: errori su QSK seriali RS232 (serialTimeout e invalidProtocol) 

DEVIL651 seriali VISA 

errori prodotti: serialTimeout 

QSKEL 

QSKES 

DEVIL657 seriali native tty 

errori prodotti: invalidProtocol (Catia dice che sui positroni ci sono più errori) 

QSKPL 

QSKPS 

Classe: MG1 

Protocollo: Probus 

MOXA 192.168.190.46 

16 porte RS232 (tutte usate per i QSK) 

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:  

ID: 20161024.2 

Autore: A.S. 

Descrizione: tune-up pref e DBFiles DEVIL618, DEVIL655, DEVIL652 

DEVIL618 

idleTime abbassato da 100 a 10 

DEVIL652 alzate soglie di read sensitivity ed error per DHSTS001 

currRead,0.009918,0.0,0.0,650.0,0.5 (era 0.1),1.0 (era 0.5) 

DEVIL655 alzate soglie di read sensitivity ed error per DHPTT002 

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 

ID: 20161024.1 

Autore: A.S. 

Descrizione: 

Si lamenta una lentezza del controllo per quanto riguarda gli alimentatori OCEM. 

La lentezza è reale ed è riconducibile alla nuova modalità di "contextual check" introdotta sulla MG1Ctrl ad agosto. 

Per testare una soluzione si è agito sperimentalmente sul DEVIL625. 

Dopo opportuno test, le modifiche andranno propagate a tutti i DEVILs MG1-OCEM 

Modifiche fatte: 

1. MG1Ctrl_multi_3.3 (sostituita a mano nella control625) 
   Modificata la richiesta esplicita di SL e COR ogni 10 giri (funzione denominata "slow poll"). La richiesta esplicita viene ora fatta: 

1.  al primo giro di control per poter avere le informazioni necessarie ad aggiornare i readouts di stato logico, allarmi, polarità. La struttura originale che cadenzava l'evento di slow poll è stata modificata; 

1. ogni N giri di control per un solo elemento alla volta, con indice dell'elemento che ruota circolarmente 

1. idleTime=10 (era già così) 

1. DBFile prima 
   #SER18112 
   @HCI(S)[DI32,(DBL),A32S,DU32,DU32,A32S,DU32,DU32,(DBL):6] 
   0,SER18112,E02FF000,1024,100,E02FF800,1024,100,QUATT006:QUATT005:QUATT004:QUATT003:QUATT002:QUATT001 
   @GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),A16M,HU32,HU32] 
   1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2,E3FF4000,64,2 
    
   DBFile dopo 
   #SER18112 
   @HCI(S)[DI32,(DBL),A32S,DU32,DU32,A32S,DU32,DU32,(DBL):6] 
   0,SER18112,E02FF000,1024,50,E02FF800,1024,50,QUATT006:QUATT005:QUATT004:QUATT003:QUATT002:QUATT001 
   @GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),A16M,HU32,HU32] 
   1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2,E3FF4000,32,2 

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 

ID: 20160914.1 

Autore: F.G. 

Descrizione:  

L’ asse dello scraper SCHES101_INT (1 solo asse) non riesce ad andare in OPER: 

Il cassetto in oggetto e’ situato nel rack 084 in sala dafne, ed è configurato con 1 solo asse. 

Si risolve collegandosi localmente con il drive Technosoft (mediante porta seriale); in questo caso  

1. e’ stato necessario fare un “Reset to Drive/Motor” per ripristinare l’errore riportato dalla flag “Invalid setup data” e successivamente...  

1. impostando una movimentazione locale, si e’ ripristinata la modalita’ “Axis On”, che si traduce in “Oper” a primo livello, altrimenti non risolta dalla procedura descritta al punto (1). 

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

Data: 13/09/2016 

Oggetto: Corruzione firmware NI-cDAQ-918X 

ID: 20160913.1 

Autore: R.G. 

Descrizione:  

I device NI-cDAQ-918X possono essere soggetti a corruzione del firmware. I sintomi evidenziati in questo caso sono: rispondeva al ping, non era raggiungibile da NI-MAX, self-test falliva, riavviando il led di status Yellow “blinca” per tre volte. Da manuale si evince firmware corrotto.  

La procedura prevede di scaricare NI Network cDAQ Recovery Utility 1.4.0 - Windows 7 connettere il device direttamente ad un computer impostando la scheda di rete in DCHP, fa partire il programma e vedere se riconosce il dispositivo. Di fatto il device viene visto ma lanciando il tasto update il software si bloccava. Il work-around è stato impostare  la scheda di rete del PC nello stesso network in cui è/era il cDAQ e impostare il gateway con l’ip associato al PC. Il Recovery Utility rivedere il cDAQ, funziona anche il PING verso il device e si riesce a concludere l’update del firmware di default ovvero 1.4. Da NI-MAX ora il device si vede e si può aggiornare con firmware più recente.  

# 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 

ID: 20160912.1 

Autore: A:S. 

Al momento dell'avvio di Caronten, nel caso di un DEVIL 3XX in Bus Error, quel DEVIL e tutti i successivi risultano in condizione di "dead" e non ne escono più. 

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 

ID: 20160906.1 

Autore: R.G. 

Descrizione: 

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 

ID: 20160831.1 

Autore: AS 

Descrizione: 

Avendo spezzato oggi le linee seriali dei DEVILs in oggetto (da 2 iniziali adesso sono 4), si sono conseguentemente frammentati i DBFiles relativi, introducendo due nuovi DEVILs: il 658 ed il 659. 

Il 647 si frammenta in 647 e 658 

Il 650 si frammenta in 650 e 659 

I DBFiles originali dei 647 e 650 sono stati copiati in folder AAA_OLD_...... 

Attenzione: dato che i DEVILs 647 e 650 sono interessati dai cambi di configurazione per test in BTF con !CHAOS, i loro DBFiles sono in realtà dei links a files che si diversificano secondo la configurazione DAFNE oppure !CHAOS. 

DEVIL647.DBDyn -> /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/DafneChaos/DEVIL647.DBDyn.DAFNE (o .CHAOS) 

DEVIL647.DBSta -> /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/DafneChaos/DEVIL647.DBSta.DAFNE (o .CHAOS) 

DEVIL650.DBDyn -> /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/DafneChaos/DEVIL650.DBDyn.DAFNE (o .CHAOS) 

DEVIL650.DBSta -> /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/DafneChaos/DEVIL650.DBSta.DAFNE (o .CHAOS) 

Dopo questa frammentazione, bisognerà rivedere i DBFiles ".CHAOS", essendo possibile che gli elementi interessati da quella configurazione siano adesso sotto i nuovi DEVILs 658 e 659. In ogni caso, le linee seriali sono state sdoppiate e quindi vanno rifatti. 

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

Data: 12/08/2016 

Oggetto:  

ID: 20160812.2 

Autore:  

Descrizione: Modificato il DEVIL_eth.vi 

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

Data: 12/08/2016 

Oggetto:  

ID: 20160812.1 

Autore:  

Descrizione: Modificate classi MG1, SER, SIP, VUG 

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) 

ID: 20160629.1 

Autore: PC, RG 

Descrizione: 

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 

ID: 20160620.1 

Autore: AM 

Descrizione:  

Ancora problema sul GPIB-ENET/1000 collegato al ritardo dei kicker elettroni (DEVIL690). 

Ping ok, DEVIL in run ma comandi non eseguiti. 

GPIB Explorer NON testato. 

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

Data: 15/06/2016 

Oggetto: problema GPIB-ENET/1000 kickers lato elettroni 

ID: 20160615.1 

Autore: AS, AM 

Descrizione: 

Identico problema sul GPIB-ENET/1000 collegato al ritardo dei kicker elettroni (DEVIL690) descritto al ticket ID: 20160314.1 . 

IP dei 4 GPIB-ENET/1000: 

  * 192.168.191.31 (Kickers elettroni - sala DAFNE) 

  * 192.168.191.33 (Kickers positroni - sala DAFNE) 

  * 192.168.191.34 (sala Modulatori) 

  * 192.168.191.35 (Kickers accumulatore - sala alimentatori accumulatore) 

Questa volta il dispositivo192.168.191.31 faceva con il led rosso 2 lampeggi lunghi e 8 brevi, quindi ERROR = 28 (the interface lost power). 

Soluzione: spento e riacceso, led verdi, gpibexplorer = ok, devil = ok 

WARNING: lo stesso malfunzionamento era avvenuto in aprile ma non è stato riportato nei tickets e quindi non sappiamo quale era il codice di errore segnalato. 

WARNING 2: in questa posizione si sono già rotti 2 GPIB-ENET e l'ultimo sostituito ha avuto problemi 2 volte !!! 

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 

ID: 20160314.1 

Autore: P.C. / F.G. 

Descrizione:  

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 

ID: 20151109.1 

Autore: A.S. 

Descrizione: 

Durante un ordinario riavvio di livello 2 per crash dell'orbita, esce la paginetta rossa di errore sulle 4 LEXTEL dei 4 DEVILs dell'orbita. 

Si fanno vari tentativi di reset ma il risultato è sempre negativo. Si controllano tensioni etc. sui crates di livello 3 e 2 ma risultano a posto. 

Si fa un riavvio delle FORCEs e si nota che danno un errore durante il boot (per spazio disco insufficiente). 

Si vede che il file /var/adm/wtmpx (contenente il log delle login degli utenti) aveva riempito il file system dove c'è la /export/home (condivisa fra le FORCEs). Si svuota il file e si riavviano le FORCEs: ok. 

Si fa un riavvio di livello 2: ok. 

Test dell'orbita: ok. 

Data: 19/11/2015 

Oggetto: down del SunRay server 

ID: 20151119.1 

Autore: A.S. 

Descrizione: 

Alle 15:07 tutte le consoles perdono la connessione con il SunRay server (schermata grigia e finestra ORACLE di login con clessidra di connessione non funzionante). Mentre si analizza il problema (dopo 5 minuti circa), le sessioni tornano da sole, con tutte le finestre aperte e funzionanti come al momento della loro scomparsa. 

Si analizza con Spigone la situazione e lo storico degli switches e delle porte interessate: 

• la vlan 192.168.193.x è collegata all'interfaccia del server em2 -> swlat2 - porta 25 
• la vlan 192.168.194.x è collegata all'interfaccia del server p1p2 -> swlat2 - porta 26 
• l'uplink 10G di swlat2 -> swlat - modulo 2 - porta SFP #18 

Risulta che non c'è stato alcun problema di rete/switches/porte. 

Nei logs del SunRay Server si vede — dalle 15:07 alle 15:10 — un lungo elenco di richieste DHCP delle SunRays al server. 

Pare quindi si sia trattato di un problema occorso al servizio stesso (risoltosi spontaneamente). 

ATTENZIONE: manca sul Wiki la documentazione per riavvio del servizio da terminale. Creata una nuova pagina: 

http://wiki.infn.it/strutture/lnf/da/dafne/sistema_di_controllo/sviluppatori/sunray_server 

con informazioni di accesso al server e all'amministrazione web del servizio SunRay. Da completare. 

ATTENZIONE 2: provando ad andare sulla pagina di amministrazione web del SunRay server con Chrome, si ottiene l'errore: 

"Server has a weak ephemeral Diffie-Hellman public key" or ERR_SSL_WEAK_EPHEMERAL_DH_KEY 

If you see this error, it means that a secure connection can't be established because of outdated security code on the website. Chrome protects your privacy by preventing you from connecting to these sites. You won't be able to visit this page using Chrome. 

If you're a website administrator, we recommend you update your server to support ECDHE and disable DHE. If ECDHE is unavailable, you can instead disable all DHE cipher suites and rely on plain RSA. 

Vedere se si può fare quanto indicato... 

Data: 12/11/2015 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

ID: 20151112.1 

Autore: A.S. 

Descrizione: 

I due quadrupoli Danfysik SYS8800, QUATM002, QUATM003, controllati dal DEVIL649 sono in bad status. 

Controllando il driver che fa la query, si vede che non rispondono. 

Il DEVIL649 gira sulla vldantedev022 

La linea seriale interessata è: SER15003, ASRL5::INSTR, MOXA .40 - porta 5 

La linea è: porta 5 del MOXA -> QUATM002 -> QUATM003 -> DHRTB001 (in bypass e non usato) -> TERM 

Riavvio della vldantedev022: il problema persiste. 

Si controllano le connessioni (Stefano Martelli) della linea seriale: si stacca-riattacca il connettore RJ45 dal MOXA: ok, connessione ristabilita. Si lascia così ma attenzione, forse il "monchino" ha dei falsi contatti o la crimpatura difettosa. Appena possibile, provare a muoverlo per vedere se si ri-verifica il problema di comunicazione. 

Data: 09/11/2015 

Oggetto: procedura di sconfigurazione/riconfigurazione correttori CHV della BTF 

ID: 20151105.1 

Autore: A.S. 

Descrizione: 

come si disattiva/riattiva il controllo della Main unit: CITTB001 e dei suoi canali della BTF CHHTB001, CVVTB001, CHHTB002, CVVTB002 (gli altri 4 canali della Main Unit — CHHTE001, CVVTE001, CHHTE002, CVVTE002 — non sono più utilizzati). 

Procedura di attivazione/disattivazione 

Si può procede tramite script o manualmente, come descritto a seguito. 

Con Script 

Si usa la procedura: 

/u2/dcs/script_linux/manageCHVTB.sh 

La procedura deve essere eseguita come utente dante da una macchina che veda le directories: 

/u2/dcs/space/uniDatabase/ 

/u2/dcs/db/DBFiles_3/CPU_LINUX_eth/ 

come per esempio una dante00X. 

ATTENZIONE: la procedura deve essere eseguita dalla shell bash 

La procedura presenta il seguente menù: 

1) Disable TB correctors    (Ovvero toglie i CHVTB dal controllo DANTE) 

2) Enable TB correctors      (Ovvero mette i CHVTB sotto il controllo DANTE) 

3) Quit 

Please enter your choice: 

• Imettere l'opzione desiderata. 
• A procedura conclusa, fare stop-run del DEVIL631, dei processi di servizio (Caron, ....etc...) sulla console di servizio e di tutte le consoles di lavoro. 

Manualmente 

Volendo operare manualmente, eseguire tutti i seguenti passi. 

A livello 1 

Bisogna predisporre il MagTerminal in modo da vedere/non vedere i suddetti correttori. Questo si fa modificando i files di configurazione  .cnf  presenti nella directory: /u2/dcs/space/uniDatabase/ 

I files di configurazione interessati sono nelle sub-directories: elementaryAreas, functionalAreas, customAreas.  

Per mettersi nella condizione voluta, bisogna copiare il files relativi (già pronti) dalle sub-directories disarmed a quelle effettive, rimuovendo l'estensione .[with | without]CHVTB, in modo da sovrascrivere quelli al momento in esercizio. 

ATTENZIONE: in un caso, la condizione "CHVs disabilitati" si risolve semplicemente con l'assenza del file .cnf ). 

A livello 3 

La Main unit ed i suoi canali, sono controllati da: 

DEVIL631 

vldantedev025 

SER40010 

MOXA 192.168.192.40, port 16 

subID2 = 0f 

L'abilitazione/disabilitazione dei CHV si ottiene mettendo in esercizio i files DEVIL631.DBSta e DEVIL631.DBDyn adatti alla condizione voluta (CHVs disabilitati/abilitati) nella directory: 

u2/dcs/db/DBFiles_3/CPU_LINUX_eth/ 

I files già pronti per le due condizioni sono nella sub-directory 

.../CPU_LINUX_eth/AAA_OLD_DEVIL631_20151013/ 

Bisogna quindi copiare i files voluti da .../CPU_LINUX_eth/AAA_OLD_DEVIL631_20151013/ a .../CPU_LINUX_eth/, rimuovendo l'estensione [.with | .without]CHVTB.twoSerialLines, in modo da sovrascrivere quelli attualmente in esercizio. 

A livello di sistema 

Fare stop-run del DEVIL631, dei processi di servizio (Caron, ....etc...) sulla console di servizio e di tutte le consoles di lavoro. 

Data: 05/10/2015 

Oggetto:  Problema su MOXA 192.168.190.44 

ID: 20151005.1 

Autore: A.S. 

Descrizione:  

Il problema si ripete. Si fa controllare da Spigone la porta dello switch alla quale è collegato il MOXA e risulta che non compare neache il MAC address: il dispositivo è quindi rotto. 

Si sostituisce. OK. 

Data: 04/10/2015 

Oggetto: Problema su MOXA 192.168.190.44 

ID: 20151004.1 

Autore: A.S. 

Descrizione:  

Da remoto si verifica che i due DEVILs 651 e 657, entrambi sulla macchina virtuale vldantedev028, girano lentissimi e quindi sono in condizione di "DEAD" con sporadici momenti di "ALIVE". 

Il MOXA che gestisce le 16 linee serali RS232 utilizzate da questi due DEVILs è il 192.168.190.44 (situato in sala DAFNE - rack 068). 

L'interfaccia WEB del MOXA non risponde e facendo ping, questo risponde con un roundtrip ~ 30 sec. . 

Si fa resettare il MOXA (togliendo e rimettendo la spina e il tempo di ping torna regolare. 

Si riavviano i DEVILs e il loop torna regolare. 

Test di inoltro comandi e riletture = OK. 

Data: 01/10/2015 

Oggetto: Installazione VMIC dante068 in tower VME Sala Strumentazione (42) 

ID: 20151001.1 

Autore: P.C. 

Descrizione: Posizionato un tower VME in sala strumentazione (42) vicino al crate VME del luminometro ed installata e resa operativa la vmic dante068 (192.168.192.68) per sviluppo da parte di Antonio De Santis (da supervisionare per farlo sviluppare come utente dafne nella cartella /u2/dcs/source_testing). 

Data: 30/09/2015 

Oggetto: sviluppo drivers seriali “multi” ( VISA & native ) 

ID: 20150930.1 

Autore: A. D’Uffizi, A.S. 

(1) vedi paragrafo "Particolarità del DBFile nel caso MG1 - E642". 

(2) BUG 01 - 22/10/2015: la serialConfigure, dopo i primi due elementi (subID2 = 8 e 9) rilascia tutti handlers uguali a 0. Il risultato è che da console, i comandi su un elemento viene eseguito anche su molti altri. 
Forse è un caso ma subito dopo 8 e 9 cominciano gli hex A, B, E, F, C, D... 
INOLTRE: dopo un po di debugging e un paio di stop/start, il DEVIL è crashato (come era successo durante lo sviluppo). BUG SOLVED 
 

Note sui timeouts 

Le nuove routines seriali "....._multi.vi" utilizzano 2 input di timeout: 

• uno è quello che esisteva anche sulle routine VISA e che riguarda il timeout sull'operazione di lettura (serve ad assorbire eventuali frammentazioni della risposta proveniente dal dispositivo) 
• l'altro (waitBeforeFirstRead [ms]) è un ritardo che la funzione di read osserva prima di accedere al buffer di input (serve ad assorbire eventuali latenze iniziali della risposta proveniente dal dispositivo) 

Il valore assegnato al nuovo timeout waitBeforeFirstRead viene messo nel DBSta nel campo subID1 (prima inutilizzato). 

!!! WARNING !!! il campo subID1 è interpretato come HEX e quindi il valore di timeout in millisecondi che viene scritto nel DBFile deve essere scritto come HEX. 

Particolarità del DBFile nel caso MG1 - E642 

Nel caso di un DBFile di classe MG1 - protocollo E642 (ovvero alimentatori OCEM), il file viene come nell'esempio seguente: 

• i due timeout convenzionali (read e write), nel record HCI, sono 40 ms  (tarati per OCEM) sia per VISA che per native; 
• il campo genericSerialBoardType (0 = VISA, 1 = native), evidenziato in rosso nell'esempio; 
• waitBeforeFirstRead, messo nella posizione di subID1 = 0x64 = 100 ms  (tarato per OCEM) 
  WARNING (vedi ticket 20160906.1): waitBeforeFirstRead dovrebbe essere di 40 ms ma viene tenuto a 100 perchè se si migra a caldo una vm fra due hosts con diverse prestazioni, la durata dei tickcounts non è più reale (la taratura viene fatta a boot della vm (vedi p.es. il file /proc/cpuinfo). Questo è un problema di carattere generale e vale anche per altri parametri (p.es. cache, bogomips, etc...). 

Caso native 

#SER15002 

@HCI(S)[DI32,(DBL),A32S,DU32,DU32,A32S,DU32,DU32,(DBL):6] 

1,SER15002,E02FE000,1024,40,E02FE800,1024,40,QUATE001:QUATE002:QUATP001:QUATP002:QUATP003:QUATP004 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),A16M,HU32,HU32] 

1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2,E3FF4000,64,0C (subID1 indifferente nel caso VISA) 

Particolarità del DBFile nel caso MG1 - Probus 

Nel caso di un DBFile di classe MG1 - protocollo Probus (ovvero alimentatori per QSK), il file viene come nell'esempio seguente: 

Caso VISA 

#SER68001 

@HCI(S)[DI32,(DBL),HU32,DU32,DU32,HU32,DU32,DU32,(DBL):1] 

0,SER68001,E02FF000,1024,100,E02FF800,1024,100,QSKEL106 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32] 

0,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerCh001,E3FF4000,0,5 (subID1 indifferente nel caso VISA) 

Caso native 

#SER68001 

@HCI(S)[DI32,(DBL),HU32,DU32,DU32,HU32,DU32,DU32,(DBL):1] 

0,SER68001,E02FF000,1024,50,E02FF800,1024,50,QSKPS101 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32] 

1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerCh001,E3FF4000,50,5 (subID1 = 50 nel caso native) 

Data: 18/05/2015 

Oggetto: messa in produzione la switchDAFNE_COMBO.vi ver 3.3 

ID: 20150518.1 

Autore: A.S. & P.C. 

Descrizione:  

Dopo un week-end di utilizzo senza problemi, è stata messa in produzione la versione 3.3, build 20150511-1540 del programma switchDAFNE_COMBO.vi. 

La versione che è stata in run sino ad oggi è la 3.22, build 20141201-1433 

Data: 23/03/2015 

Oggetto: Ripristino linea seriale BTF (post Test CHAOS) 

ID:20150323 

Autore: F.G., P.C. 

Descrizione: Ripristinata linea seriale BTF (Test CHAOS -> Dafne); trovati connettori seriali con torrette lente (girano a vuoto le femmine) e non tutte le viti prendono nel modo corretto, determinando un’inaffidabilita’ e stabilita’ del connettore stesso (suggerisco di fare spezzoni di adattamento con viti lunghe per corretto serraggio e affidabilita’ della connessione). 

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.

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.

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 

ID: 20150127.1 

Autore: P.C., F.G., G.B. 

Descrizione: Segue il post ID: 20150126.1 

L’orbit monitor non visualizza nessun dato e risulta sempre in oversampling, mentre il DEVIL366 risulta di nuovo fuori comunicazione. Si effettua una rapida per accedere e si trova il DEVIL366 senza comunicazione di rete, mentre la porta 48 dello switch SWDAFNE2B risulta ok. Si stacca e si riattacca il cavo di rete, si riavvia il devil e riparte correttamente. Effettuato quindi il riavvio di secondo livello, la finestra dell’orbita resta in oversampling senza visualizzare alcun dato. Si prova a diagnosticare il DEVIL204 e si nota un errore del tipo “invalid0” nella finestra readOrbit1.5.vi (c’e’ una cin chiamata readOrbit1.5.c). 

Alla fine risulta un problema di collegamento seriale del devil366 (il cavo era lento, spingendolo e riavviando il sistema dell’orbita tutto e’ tornato a funzionare). 

Data: 26/01/2015 

Oggetto: DEVIL366 fuori comunicazione 

ID: 20150126.1 

Autore: P.C., O.G. 

Descrizione: Segue il post ID: 20150116.1 

A seguito di un riavvio dell’orbita, ci si accorge che il DEVIL366 e’ fuori comunicazione. Dopo diagnosi con Spigone si trova la porta 48 dello switch SWDAFNE2B in error disabled con una failure di tipo “hardware” e non di protocollo. Di conseguenza si sostituisce l’allied telesis connesso al DEVIL366 con l’ex allied del DEVIL351 e riavviando l’orbita tutto sembra partire correttamente (finestre dell’orbita non aperte). 

Il convertitore rimosso è stato etichettato e lasciato sul tavolo della SunRay in sala LAT. 

Continua con il post  ID: 20150127.1 

Data: 18/01/2015 

Oggetto: VNC del DEVIL603 

ID: 20150118.1 

Autore: A.S. 

Descrizione:  

A seguito del riavvio del DEVIL603 (vedi ticket precedente), sul suo VNC compare una dialog box che allego in figura: 

Data: 16/01/2015 

Oggetto:  

ID: 20150116.2 

Autore: A.S. 

Descrizione: 

In serata di venerdi, si notano numerosi problemi con i drivers seriali di molte macchine virtuali. Si nota un notevole incremento della frequenza di accesso ai Serial Servers MOXA e continui "hang" dei drivers che li effettuano. Questo potrebbe essere imputato alle mutate condizioni stabilitesi con il nuovo link a 10 Gbps. Seguendo questa ipotesi, si fanno le stesse modifiche fatte in precedenza sui CHN-COR Caenels, ovvero si introducono dei ritardi (1 ms) nei loops delle routines CTRL delle classi CHN e COR e si allunga l'idleTime (10 ms -> 100 ms) dei main loops dei DEVIL 641 e 619. Si riavviano le vldantedev008, 009, 012, 013. 

AGGIORNAMENTO 18/01/2015 

Stesso problema sui DEVILs 628 e 649 

si allunga l'idleTime (10 ms -> 100 ms) dei DEVILs 628 e 649 

e si riavvia la vldantedev022 

Stesso problema sul DEVIL602 

si allunga l'idleTime (10 ms -> 100 ms) dei  DEVILs 602, 603,604, 605, 606, 607,608, 649 

e si riavvia la vldantedev010 

Data: 16/01/2015 

Oggetto: DEVIL366 (orbita) 

ID: 20150116.1 

Autore: A.S., G.B. 

Descrizione: Segue il post ID: 20141130.1 

Essendosi ripetuto l'evento di perdita del collegamento Ethernet del DEVIL366 (vedi tickets precedenti), si procede al rimpiazzo del collegamento ETH (con lungo cavo 10-base2 dal DEVIL366 al cestello Allied posizionato sul rack 064) con un collegamento corto e un modulino Allied dedicato, collegandosi direttamente a swdafne2B (nel rack 069 adiacente al DEVIL366). 

Continua con il post ID: 20150126.1 

Data: 18/12/2014 

Oggetto: DEVIL680 "error on sending command" 

ID: 20141218.1 

Autore: A.S. 

Descrizione:  

A seguire ticket precedente 20141212.2: si ripete il problema dell'andamento "a singhiozzo" e della saturazione della CPU. Inserisco delle wait da 1 ms nei FOR loops dei VIs: 

• CORCtrl_CAEN.vi 
• dbCoverter_CAEN.vi 
• faulConverter(CHN)_CAEN.vi 
• faulConverter(COR)_CAEN.vi 

• FetchDB_CAEN.vi 
• forceSetting_CAEN.vi 
• SY3634_FillStatusRegister.vi 

Documentazione modifiche fatte su: 

smb://nasda/control/docs/Classes/CHN-COR/Modifiche Ctrl CAEN_LV12_18-12-14 

Il run è ovviamente più lento ma il carico della CPU è tornato normale (CPU<50% con picchi saltuari ed isolati). 

CONCLUSIONI: Monitorare il comportamento del 680, controllando che il system load e la CPU si mantengano su valori regolari. 

Data: 12/12/2014 

Oggetto: DEVIL680 "error on sending command" 

ID:  20141212.2 

Autore: A.S. 

Descrizione:  

PREMESSA: ieri Catia aveva riportato un ripetuto problema di "Error on sending command" sui correttori Skew degli anelli (Caenels). 

ANALISI:  Il DEVIL è il 680, sulla vldantedev015 con LabVIEW 2012-sp1-f5. A seguito di un controllo fatto ieri si evidenziava: 

- frequenza di run del DEVIL680 eccessiva (~100 Hz); 

- loop di run "a singhiozzo" (100Hz, pausa con clessidra, 100Hz, pausa con clessidra, ...) con un periodo di circa 1 secondo. Dalle risorse di sistema si vedeva lo stesso andamento sul traffico di rete e sull'impiego della CPU (nei picchi arrivava al 100%). Il system load era ~ 1.6 ! 

In queste condizioni è presumibile che l'invio di un comando in concomitanta di una fase "clessidra" & CPU al 100% & picco di rete potesse tradursi in un errore di invio del comando. 

INTERVENTO: dopo il problema di rete, sfrutto l'occasione per analizzare il problema ma il DEVIL680 si comporta diversamente da ieri: la frequenza è sempre eccessiva (~100Hz) ma il loop non è più "a singhiozzo". Cambio "idleTime" nel file DEVIL680.pref, portandolo da 10 a 100 ms. Lancio il DEVIL e verifico: loop costante, freq. ~ 10 Hz, carico della CPU stabile al 50%, system load è ~ 0.2. 

Faccio (per allineamento) lo stesso cambiamento anche sul file DEVIL680.pref dell'area di LabVIEW 2010. 

Controllo la reattività da MagTerminal in questa nuova configurazione: è ok. 

CONCLUSIONI: vedi ticket successivo 20141218.1 

Data: 12/12/2014 

Oggetto: problema generale di rete ethernet dei LNF  

ID: 20141212.1 

Autore: A.S., R.G. 

Descrizione:  

Nuovamente problema su uno di 2 core switches del Centro di Calcolo (CPU ~100%, anche il secondo core switch "si incasina" come l'altra volta). 

Il problema si riperquote anche sulla nostra rete, con le seguenti conseguenze: 

- DEVIL601 della RF perde la comunicazione con i CompactDAQ: ripristinata tramite Max. 

- trovato sullo storage un errore di "connessione con il cluster persa": fatto acknowledge. Non risultano errori attivi via web. Il led ambra di errore sul pannello frontale è spento. 

- tutti i DEVILs Apple avevano perso la comunicazione con Bible: riavviati. 

- Force dante005 trovata a "prompt ok": mi collego tramite switch seriale e faccio "boot". 

- file di preferences di LabVIEW 2010 (nelle home condivisa di dante delle vldantedevxxx) trovato resettato al default: ripristinato. Per il futuro, faccio due copie (LV10 e LV12) dei file di preferences. 

Data: 04/12/2014 

Oggetto: modifica serialWrite 

ID: 20141204.1 

Autore: A.S. 

Descrizione:  

Modificato e salvato il VI serialWrite, cambiando la modalità del driver VISA all'interno da asynchronous a synchronous. Fatta la stessa modifica su LV12 e LV12-sp1-f5. 

Data: 30/11/2014 

Oggetto: DEVIL631, modifica DBFiles 

ID: 20141130.2 

Autore: A.S. 

Descrizione:  

Sostituito su DBSta e DBDyn del DEVIL631 il canale correttore CHHTB004 con l'originale CHHTM004. 

Modificati coerentemente i files di configurazione delle: 

• elementaryAreas/TB 
• functionalAreas/TB 

RIMANE da rimettere l'elemento anche in tutti gli altri files di configurazione dei MagTerminal. Non l'ho fatto per paura di invalidare il salvataggio e la riapplicazione dei datasets di lavoro. CONTROLLARE... 

Data: 30/11/2014 

Oggetto: DEVIL366 (orbita) 

ID: 20141130.1 

Autore: A.S. 

Descrizione: Segue il post ID: 20141122.1 

Si manifesta nuovamente il problema del ticket sul DEVIL366. 

Interviene Giampiero Di Pirro: spegne e riaccende il crate dei 4 Allied in sala DAFNE. 

A questo punto sembra evidente che il problema sia dovuto o all'interfaccia di rete Ethernet del DEVIL o al cavo coassiale RG223 che collega il DEVIL all'Allied. 

Rimane quindi da sostituire il DEVIL e spostare l'Allied 

INOLTRE: controllare che il cavo ETH non sia in catenella con altri devils oramai dismessi (eventualmente controllare se ci sono T intermedie e/o tappi. 

DA FARE APPENA POSSIBILE: configurare una porta dello switch vicino al 366 come statica sulla 196 e collegarci direttamente il DEVIL con un Allied. 

Continua con il post ID: 20150116.1 

Data: 28/11/2014 

Oggetto: “Error sending command [...] a primo livello” 

ID: 20141128.1 

Autore: F.G., A.S. 

Descrizione:  

L’errore si presenta quando si tenta di inviare comandi ad elementi controllati da devil i cui servlet sono cresciuti a dismisura. Questo dovrebbe essere causato da un programma di primo livello che va individuato (probabile e’ il nuovo programma di correzione dell’orbita, visto che i devil coinvolti comandano solo correttori - da controllare). 

I devil che hanno evidenziato il problema in oggetto sono: 

636, 637, 643 

NOTA: aggiornare il presente ticket dopo l’individuazione esatta del problema! 

UPDATE 01/12/2014 by A.S. 

Problema individuato. 

PREMESSA: le connessioni TCP-DCS si chiudono quando si chiude il VI che le ha aperte. Se però un VI che apre una connessione TCP-DCS viene usato come Sub-VI, allora la connessione viene tenuta aperta dal main, anche quando il Sub-VI termina la sua esecuzione. Questo era un fatto noto e la chiusura esplicita veniva fatta chiamando il ConnectionManager con un empty array (di nomi di elementi) in ingresso. 

BACO: la versione 2.1 del ConnectionManager ha un funzionamento diverso e la chiusura viene ottenuta mettento a TRUE il controllo "forceReopen". Per un errore, sia nel programma switchDHPTT001_combo_1.4 sia in quello che commuta la macchina (quadratini colorati), sia nel pretune, questo input non era cablato. 

Testato prima della modifica: si conferma l'aumento del numero di servlet. 

Testato dopo modifica: si verifica la soluzione del problema. 

CONCLUSIONE: forse c'è ancora qualche Sub-VI che non chiude ma sicuramente, con questo intervento, si è risolto il 90% delle cause dell'aumento dei servlet. Sopratutto, questo dovrebbe aver risolto l'annoso problema del pulsato DHPTT001 che ogni tanto smetteva di commutare e guardacaso, bisognava chiudere e riaprire il VI di switch per farlo rifunzionare. 

Allo shutdown di dicembre bisogna fare un controllo a tappeto. 

Data: 22/11/2014 

Oggetto: aggiornamento barra dante 

ID: 20141122.2 

Autore: A.S. 

Descrizione:  

Aggiornata la barra dante alla versione 6.0 che recupera da coda i comandi da loggare su MySQL. Il meccanismo precedente (che recupera tramite evento globale) è ancora in esercizio ma il suo impiego è deprecato. 

Modificata la routine di switch (finestra con i quadratini colorati) in modo da utilizzare la coda dei comandi e non piu l'evento globale di log. Al momento, tutte le altre finestre utilizzano ancora l'evento di log. 

Data: 22/11/2014 

Oggetto: DEVIL366 (orbita) 

ID: 20141122.1 

Autore: A.S. 

Descrizione:  

sabato mattina: la sala controllo riporta stesso problema di qualche giorno fa sul DEVIL366: BusError, non esegue il bootstrap. 

Da casa: faccio fare la manovra di distacco del cavo di rete fra il convertitore ETH Allied e lo switch. Non funziona. 

Intervengo sul posto: boot da disco, controllo la rete e ho la conferma che il DEVIL non vede la rete. 

Sostituisco il convertitore Allied con uno trovato in sala LAT. Tutto ok. 

Il convertitore rimosso è stato etichettato e lasciato sul tavolo della SunRay in sala LAT. 

Continua con il post ID: 20141130.1. Il convertitore rimosso non era la causa. 

Data: 14/11/2014 

Oggetto: istruzioni programma standalone dell’orbita Accumulatore 

ID: 20141114.1 

Autore: A.S. 

Descrizione: 

VMIC: dante067 (nella saletta a vetri in BTF) 

VNC: 192.168.192.107:5967 

Per collegarsi al display VNC dalle consoles in sala controllo, aprire un terminale e dare il comando: 

vncviewer 192.168.192.107:5967 & 

username (se richesto): dafne 

password: dafnevnc 

========================================================= 

SOLO NEL CASO SUL DISPLAY VNC NON CI FOSSE LabVIEW APERTO 

========================================================= 

da un terminale qualsiasi: 

> ssh dante@192.168.192.67 

... fare la login come utente dante ... 

> labview -display 192.168.192.107:67 & 

> exit 

... chiudere il terminale ... 

... connettersi al display VNC come descritto sopra ... 

========================================================= 

Directory di salvataggio dei files dell'orbita: /u2/dcs/space/datafiles/ORA/ 

Formato file: 3 righe di floating (riga 1: ascisse, riga 2: proiezione X, riga 3: proiezione Y). Attenzione: le ascisse non sono in ordine crescente. 

La versione utenti del programma è: 

/u2/dcs/source_linux/0_classes/ORA/console/Accumulator_Orbit_Manual_Controller.vi 

La corrispondente versione di sviluppo, è la più recente fra quelle con nome: Accumulator_Orbit_Manual_Controller_x.x.vi 

Quando si aggiorna la versione di sviluppo, si DEVE procedere così: 

1. si ri-salva la versione di sviluppo come una versione successiva (p. es. Accumulator_Orbit_Manual_Controller_1.1.vi) e si aggiorna coerentemente la stringa in alto a destra sul pannello frontale (p.es. ver 1.1, build 20141114-1650)
2. *
3. si fanno le modifiche su questa nuova versione
4. quando la release è pronta, si salva per gli utenti ANCHE con il nome "Accumulator_Orbit_Manual_Controller.vi" (sovrascrivendo il VI già esistente che — ovviamente — non deve essere aperto in quel momento).

Data: 04/11/2014 

Oggetto: problematiche dopo blackout 

ID: 20141104.1 

Autore: A.S., F.G. 

Descrizione: 

GPIB/ENET, MOXA, CompactDAQ 

Spegnere e riaccendere, reboot via WEB, riconfigurare con MAX 

Le consoles Force non eseguono il boot: 

i servizi sul cluster sono a posto ma le consoles non fanno il boot. Dopo vari tentativi, si riavvia lo switch Cisco Catalist al quale sono collegate (notare che lo switch è sotto UPS e in teoria non dovrebbe aver risentito del blackout). Le consoles partono immediatamente. 

Lo switch delle seriali CMS-16 (192.168.192.210) non è raggiungibile: 

In questo caso il problema era dovuto allo stesso motivo sopradescritto. Comunque, dopo uno spegnimento, il CMS-16 non è raggiungibile via rete. Bisogna collegare un terminale seriale alla System Setup Port nr. 1 e fare un “ping” su una qualsiasi macchina 192.168.192.xxx 

Le riletture di posizione (dei counters) degli scrapers sono tutte incoerenti: 

Si salvano le riletture degli encoders potenziometrici e poi si fa un homing su tutti gli assi. 

L’ asse dello scraper SCHES101_INT (1 solo asse) non riesce ad andare in OPER: 

Il cassetto in oggetto e’ situato nel rack 084 in sala dafne, ed è configurato con 1 solo asse. 

Si risolve collegandosi localmente con il drive Technosoft (mediante porta seriale); in questo caso  

1. e’ stato necessario fare un “Reset to Drive/Motor” per ripristinare l’errore riportato dalla flag “Invalid setup data” e successivamente...  

1. impostando una movimentazione locale, si e’ ripristinata la modalita’ “Axis On”, che si traduce in “Oper” a primo livello, altrimenti non risolta dalla procedura descritta al punto (1). 

Data: 18/08/2014 

Oggetto: ticket riservato al report dei crash di LabVIEW, come da ticket ID: 20140808.1 

ID: 20140818.1 

Autore: F.G. 

Descrizione: mettere tutti i reports sui crash/freeze delle sessioni LabVIEW sotto osservazione in questo ticket 

UPDATE 18/08/2014 (F.G.) 

Trovato Devil 680 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 25/08/2014 (A.S.) 

Trovato Devil 641 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 01/09/2014 (A.S.) 

Trovati Devil   e 640 DEAD; desktop VNC vuoti. 

Devil 640 non il lista test secondo ID: 20140808.1, Devil 623 in lista (prima occorrenza del test). 

NOTA: il DEVIL 623 controlla i nuovi Kickers tramite gli ICP-DAS. Da un controllo effettuato più avanti (13/09), si trova la comunicazione TCP/IP costantemente in errore. Questo potrebbe essere il motivo dell'eccezione. 

Resettati. 

UPDATE 02/09/2014 (A.S.) 

Trovato Devil 646 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 05/09/2014 (A.S.) 

Trovato il display VNC del Devil 623 con le finestre LabVIEW bianche e congelate ma il devil e’ ancora ALIVE. 

Devil 623 in lista (seconda occorrenza del test, sempre sullo stesso 623) 

Resettato. 

Da un controllo effettuato più avanti (13/09), si trova la comunicazione TCP/IP costantemente in errore. Questo potrebbe essere il motivo dell'eccezione. 

UPDATE 10/09/2014 (A.S.) 

Trovato del Devil 637 DEAD;  desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 13/09/2014 (A.S.) 

Trovato del Devil 635 DEAD;  desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 16/09/2014 (F.G.) 

Trovato Devil 680 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato (probabilmente da un operatore alle 9:00 c.a.). 

UPDATE 16/09/2014 (F.G.) 

Trovato Devil 623 DEAD; desktop VNC vuoto. 

Devil 623 in lista  test secondo ID: 20140808.1 

Resettato. 

(terza occorrenza del test, sempre sullo stesso 623 ????  

La natura del crash e’ differente: solo 2 volte aveva il VNC vuoto, come pure il 680 ha avuto 2 occorenze di VNC vuoto!) 

UPDATE 22/09/2014 (F.G.) 

Trovato Devil 690 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 25/09/2014 (F.G.) 

Trovato Devil 680 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato dal  gruppo magneti ore 8:45 c.a., ma rimane il VNC vuoto ed il DEVIL e’ ALIVE. 

UPDATE 30/09/2014 (F.G.) 

Trovato Devil 623 DEAD; desktop VNC vuoto. 

Devil 623 in lista  test secondo ID: 20140808.1 

Resettato 08/10/2014. 

(quarta occorrenza del test) 

UPDATE 08/10/2014 (A.S.) 

Trovato Devil 680 DEAD; desktop VNC vuoto e DEVIL ALIVE! 

Devil non il lista test secondo ID: 20140808.1 

Resettato FAST: rimane il VNC vuoto ed il DEVIL ritorna ALIVE. 

Resettato SLOW: tutto OK. 

(terza occorrenza del test) 

UPDATE 09/10/2014 (F.G.) 

Trovato Devil 617 DEAD; desktop VNC vuoto. 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 13/10/2014 (F.G. e P.C.) 

Trovato Devil 657 DEAD; VNC frizzato. Labview OK devil ALIVE!!!!! 

Devil non il lista test secondo ID: 20140808.1 

Resettato. 

UPDATE 17/10/2014 (P.C.) 

Trovato Devil 680 DEAD; desktop VNC vuoto e DEVIL morto! 

Devil non il lista test secondo ID: 20140808.1 

Resettato SLOW. 

UPDATE 17/10/2014 (A.S.) 

Trovato Devil 615 DEAD; desktop VNC vuoto e DEVIL morto! 

Devil non il lista test secondo ID: 20140808.1 

Resettato SLOW. 

UPDATE 28/10/2014 (P.C.) 

Trovato Devil 629 DEAD; desktop VNC vuoto e DEVIL morto! 

Devil non il lista test secondo ID: 20140808.1 

Resettato SLOW. 

UPDATE 10/11/2014 (P.C.) 

Trovato Devil 621 DEAD; VMIC kickers elettroni bloccata! 

Devil non il lista test secondo ID: 20140808.1 

Resettata VMIC con BNC in sala strumentazione. 

UPDATE 14/11/2014 (P.C.) 

Trovato Devil 642 DEAD; desktop VNC vuoto e DEVIL morto! 

Devil in lista test secondo ID: 20140808.1 

Resettato SLOW. 

UPDATE 21/11/2014 (P.C.) 

Trovato Devil 642 DEAD; desktop VNC vuoto e DEVIL morto! 

Devil in lista test secondo ID: 20140808.1 

Resettato SLOW. 

Data: 08/08/2014 

Oggetto: test display VNC su danteweb 

ID: 20140808.1 

Autore: P.C., A.S. 

Descrizione:  

Per verificare se il problema dei crash saltuari dei DEVILs è dovuto al VNC server, sono stati riavviati a mano alcuni DEVILs che girano su macchine virtuali, indirizzando il display NON sul server della relativa macchina virtuale ma sul server VNC 192.168.192.107 

La lista dei devils è: 

603, 608, 610, 612, 623, 628, 631, 633, 636, 642, 654 

I display VNC originali sono stati lasciati aperti per consentire il funzionamento dei bottoni “Reset Devil” sulla pagina WEB “Devil_Manager” che è temporaneamente stata rinominata come Devil_Manager_ 

Riportare ogni eventuale crash avvenuto su questi DEVILs nel prossimo ticket 20140818.1 

Data: 26/03/2014 

Oggetto: DEVIL 346 non carica DBFiles. 

ID:  20140326.1 

Autore: F.Galletti, P.Ciuffetti 

Descrizione: 

E’ la prima volta che si verifica un malfuzionamento relativo al caricamento dei DBFiles. Il sintomo che bisogna tenere in considerazione è che aprendo il Mag Terminal sul suddetto devil, si trovano tutti gli elementi controllati dal medesimo con tutte le flags contemporanemente accese (OFF-LINE, LOCAL, BAD COMUNICATION, ...) 

Diagnosi: mettendo “Suspend when Called” sul VI che effettua il caricamento e il relativo riempimento delle globali del devil in oggetto, si è’ notato che la “loader346” veniva bypassata, e procedeva ad una inizializzazione di elementi il cui DB era vuoto.  

Soluzione: la solita, reboot della CPU, ma direttamente da sistema operativo (NON dal tastino di riavvio)!!!!! 

Data: 25/03/2014 

Oggetto: Ritardi programmabili Stanford e tensioni kickers positroni fuori controllo 

ID:  20140325.1 

Autore: F.Galletti, G. Di Pirro 

Descrizione: 

Per il problema delle tensioni è bastato semplicemente resettare il DEVIL622 relativo al front-end kickers positroni sul cui bus è presente il DAC relativo che controlla le medesime. 

Per i ritardi, dopo una serie di dignostiche riguardanti l’ENET National (convertitore ETH-GPIB) con l’aiuto di G. Di Pirro si è’ fatto girare il MAX National (su macchina windows del devil RF : DEVIL601). Attraverso questo software (che attualmente è disponibile per sola piattaforma windows) si è riusciti a comandare lo Stanford e quindi si è ritenuto opportuno riavviare la macchina virtuale (vldantedev003) che gestisce la risorsa VISA in questione, che - per ragioni non ancora ben chiare - ha perso il controllo della risorsa stessa. 

Attenzione!!!! Il tool explorer, lanciato dalla vldantedev003, vedeva la risorsa VISA funzionare correttamente, mentre - utilizzando il devil - la command andava in errore! 

Data: 23/08/2013 

Oggetto: Test Lextel ex 48 (devil388) con sistema 3^livello emulato su tower 

ID:  20130823.2 

Autore: F.Galletti 

Descrizione:  

Questa lextel faceva ~20err su 10^6 accessi. Per mancanza di tempo non ho potuto completare il test di misura sul totale di accessi voluto (10^7), ma si ha una accettabile stima sul buon funzionamento della medesima che ha presentato 0 errori su 10^6 accessi. 

Quindi, da quanto dedotto da ID: 20130823.1, sembra che la CES #2 induce mal funzionamenti sulle lextel LL48 e LL49. Ora bisognerebbe valutare quanto e’ accettabile la situzione fotografata al ID: 20130821.1. 

Data: 23/08/2013 

Oggetto: Test Lextel ex 49 (devil387) con sistema 3^livello emulato su tower 

ID: 20130823.1 

Autore: F.Galletti 

Descrizione:  

Questa lextel, montata a secondo livello faceva 132 errori con 10^6 accessi. Utilizzando il sistema di test su tower (in coppia con lextel ottica LL11 montata a secondo livello) sembra funzionare bene : 0 errori con 10^7 accessi. 

Quindi il problema degli errori sul devil 387 sembrano essere dovuti o alla CES del cestello #2 (molto probabile) oppure a seguito di errori del 388 (poco probabile). Per escludere eventuali problemi della lextel ex LL48 (devil388) ed avere quindi la certezza di un mal funzionamento della CES sopracitata, si procede al test come per la ex LL49. 

Data: 22/08/2013 

Oggetto: Sostituzione LL48 (devil388) e LL49 (devil387) 

ID: 20130821.1 

Autore: A.Stecchi, F.Galletti 

Descrizione:  

A seguito dell’analisi fatta con il tool 3rd-SingleCPUHam_new.vi abbiamo individuato come critiche le lextel 49 e 48. 

Dopo l’intervento di sostituzione abbiamo girato l’Hammer (3rd-LevelHamGraphnoTO#3vi) con il seguente risultato: 

# Accessi Err. Err. Err. 

totali 386 387 388 

crate 6 2 2 

-------------------------------------------------------- 

3*10^6 0 1 10 

7*10^6 1 4 37 

1*10^7 1 10 63 

LL48 (devil388): situazione migliorata di un fattore 10 

LL49 (devil387): situazione peggiorata di un fattore ~3 

Necessita un test di qualita’ sulle lextel stoccate in magazzino per valutarne il loro effettivo impiego sul DCS. 

Data: 20/08/2013 

Oggetto: DEVIL385 

ID: 20130820.2 

Autore: F. Galletti 

Descrizione:  

Messa in linea del DEVIL in oggetto (rif.ID: 20130711.1). Sostituita batteria - (WorldmapMap.DBFile OK). 

Data: 20/08/2013 

Oggetto: DEVIL391 

ID: 20130820.1 

Autore: F. Galletti 

Descrizione:  

Spostato in prima posizione VME per funzionare da System Controller (con relativa riconfigurazione dei Jumper); aggiunta terminazione ethernet - Sostituita batteria -  (WorldmapMap.DBFile OK). 

Data: 19/8/2013 

Oggetto: DEVIL312 

ID: 20130819.1 

Autore: F. Galletti 

Descrizione:  

Disinstallato e ridotta catenella ethernet. (WorldmapMap.DBFile OK). 

Data: 11/07/2013 

Oggetto: DEVIL 386 e 391 in Bus Error 

ID: 20130711.1 

Autore: P. Ciuffetti, O. Giacinti 

Descrizione:  

Questa mattina i devil 386 e 391 erano in bus error. Dopo riavvio dei devil e riavvio del secondo livello rimanevano in bus error. A secondo livello, i devil 386 e 391 afferiscono ad un unico cestello VME in cui ci sono le lextel LL32 (devil391 e devil312 stellato), LL46 (devil386) e LL31 (devil385 stellato). La LL31 aveva i monchini attaccati ma a terzo livello il cestello VME del devil385 e’ disalimentato (e l’alimentatore VME e’ in blocco). Abbiamo quindi provveduto a staccare i monchini a secondo livello della suddetta lextel ed eseguito un riavvio del secondo livello. I devil hanno ripreso a comunicare correttamente. 

Ricordarsi che se il 385 deve essere rimesso on line, l’alimentatore va sostituito e la lextel va ricollegata. 

Data: 10/07/2013 

Oggetto: Sostituzione SFP su SWDAFNE1 

ID: 20130710.1 

Autore: P. Ciuffetti 

Descrizione: 

Schema connessioni SWDAFNE1: 

SFP1 ←→ SWLAT      SFP2 ←→ SWDAFNE2B      SFP3 ←→ SWDAFNE3B      SFP4 ←→ SWDAFNE4B 

Nella notte tra il 03 ed il 04 luglio 2013 il canale di comunicazione in fibra tra SWDAFNE1 ed SWDAFNE3B ha smesso di funzionare. E’ stato sfilato e reinserito l’SFP relativo a quel canale sullo switch SWDAFNE1; cosi’ facendo il canale ha ripreso a funzionare correttamente. 

Oggi, il canale ha di nuovo smesso di funzionare. E’ stata ripetuta la stessa procedura senza alcun successo. L’SFP sullo switch SWDAFNE3B emetteva luce, mentre quello su SWDAFNE1 no. E’ stato quindi sostituito l’SFP della porta 3 dello switch SWDAFNE1 e con quello nuovo il canale ha ripreso a funzionare correttamente. L’SFP che sembra rotto sara’ portato al centro di calcolo per una conferma del suo malfunzionamento. 

Data:  16/04/2013 

Oggetto:  DEVIL612 e DEVIL610 

ID: 20130416.2 

Autore: A.S. 

Descrizione:  

Causa rottura disco nasda, i files: 

- layoutETH_YYYYMMDD.xls 

  (con la configurazione degli switches ethernet e lista dei dispositivi connessi alle loro porte) 

- Corrispondenze pannelli in fibra ottica YYYYMMDD.xls 

  (con le connessioni dei pannelli di distribuzione delle fibre ottiche) 

Sono stati temporaneamente spostati su Alfresco 

Data: 16/04/2013 

Oggetto: DEVIL612 e DEVIL610 

ID: 20130416.1 

Autore: A.S. 

Descrizione: 

Configurato DEVIL612 su dante065 per controllo SIP DAFNE. Aggiunto MOXA 192.168.192.43. 

Configurati conseguentemente: mxaddsrv, MOXA web, Excel file, visaconf, file di cablaggio seriali 

ATTENZIONE: questa è una configurazione di prova per debugging del programma e delle finestre di primo livello: i DEVILs 610 e 612 andranno spostati dalla VMIC dante065 (in sala modulatori) su macchina virtuale. 

Data: 01/04/2013 

Oggetto: divisione linee seriali DEVIL634 (continuazione del ticket 20130301.1) 

ID: 20130304.1 

Autore: A.S. 

Descrizione: 

modificati DBFiles Sta & Dyn del DEVIL634 in modo da prevedere la divisione della linea seriale SER18112 (con 16 elementi) in SER18112 (6 elementi), SER18113 (5 elementi), SER18114 (5 elementi) 
Configurati conseguentemente: mxaddsrv, MOXA web, Excel file, visaconf, file di cablaggio seriali 

Data: 01/03/2013 

Oggetto: divisione linee seriali DEVIL632 e DEVIL633 

ID: 20130301.1 

Autore: A.S., O.G. 

Descrizione: 

Modificati DBFiles Sta & Dyn del DEVIL632 in modo da prevedere la divisione della linea seriale SER15001 (con 15 elementi) in SER15001 (8 elementi) e SER15004 (7 elementi) 
Configurati conseguentemente: mxaddsrv, MOXA web, Excel file, visaconf 

Modificati DBFiles Sta & Dyn del DEVIL633 in modo da prevedere la divisione della linea seriale SER18003 (con 7 elementi) in SER18003 (4 elementi) e SER18004 (3 elementi) 

Configurati conseguentemente: mxaddsrv, MOXA web, Excel file, visaconf 

Data: 21/01/2013 

Oggetto: Configurazione temporanea livello 2 per test Franco Iungo 

ID: 20130121.2 

Autore: Alessandro, Francesco 

Descrizione: 

Per consentire i lavori sugli alimentatori DANFYSIK, si è stellato tutto il WorldMap.DBFile tranne che per i DEVILs 342, 343, 345 (il 346 non funziona e manda in prot. il PS. È stato rimosso dal crate). 

Si sono tolti i monchini twin-ax entranti sui connettori RX degli adattatori elettro-ottici a livello 2 di tutte le Lextel con led del carrier in ricezione spento. 

Si sono etichettate tutte queste Lextel con nastro adesivo e numeri in rosso. Le altre Lextel con monchini staccati, devono restare così (erano già off-line per altri motivi). 

Segue lista delle Lextel disconnesse per questa configurazione temporanea: 

Rack 031 

Crate 1: 04, 49, 48 

Crate 2: 05, 14, 15 

Crate 3: 28, 27, 29, 26 

Rack 032 

Crate 1: nessuna 

Crate 2: 31 

Crate 3: nessuna 

Data: 21/01/2013 

Oggetto: Rimozione DEVIL346 

ID: 20130121.1 

Autore: Francesco, Paolo 

Descrizione: 

Il DEVIL 346 (sala Macchine 8bis, Lextel 17) manda in protezione l'alimentatore del crate VME. Probabilmente è in corto. È stato rimosso e consegnato a Gianfranco per esame/sostituzione. 

Data: 22/10/2012 

Oggetto: Riavvio MOXA nport408 (192.168.192.27) 

ID: 20121022.1 

Autore: Paolo 

Descrizione: 

A seguito di problematiche non meglio specificate sulla linea di comunicazione inerenti l’elemento DHPTT001 controllato dal Devil644 (dante073), si e’ provveduto a stoppare il devil, riavviare il moxa in oggetto e riavviare il devil. 

Con questa operazione, i problemi di comunicazione sono spariti. 

Data: 21/09/2012  

Oggetto: Acknowledge ticket vecchi 

ID: 20120921.2 

Autore: Paolo 

Descrizione: 

Dopo aver chiuso il ticket per questa notte (devil 690) ho provveduto a dare l’acknowledge a tutti i ticket vecchi rimasti aperti dal 2008 ad oggi. 

Data: 21/09/2012  

Oggetto: Riavvio devil 690 manualmente per 2 volte 

ID: 20120921.1 

Autore: Paolo 

Descrizione: 

Durante la notte del 20/09/2012 non e’ stato possibile utilizzare l’acceleratore (a parte fare conditioning) a causa del devil 690 (che gira sulla VMIC dante081 con disco) che era fermo. E’ stata riavviata la VMIC dagli operatori in turno ma - come purtroppo gia’ sappiamo - il devil su quella CPU non riparte in automatico. Questa mattina ho riavviato manualmente il devil ed e’ ripartito funzionando correttamente. Pianificare una risoluzione del problema del non riavvio automatico del devil al riavvio della CPU. 

Data: 20/09/2012 

Oggetto: Riavvio Moxa 4 porte (192.168.192.28) in saletta alimentatori accumulatore 

ID: 20120920.1 

Autore: Paolo, Olimpio 

Descrizione: 

Il Devil 639 (sulla VMIC dante051) si bloccava per piu’ minuti sull’elemento n. 3 della sua lista, facendosi vedere ‘morto’ dalle barre dante in sala controllo. Dopo vari tentativi di riavvio dello stesso senza risultati, si e’ provveduto a riavviare il moxa in oggetto da remoto. Appena ripartito il moxa, il devil ha ricominciato a funzionare correttamente. Pensare ad una soluzione alternativa per questo problema, anche perche’ non e’ la prima volta che quel moxa deve essere riavviato. 

RICHIESTA DA FRANCO IUNGO: il devil 639 - tra le varie cose - controlla degli elementi SOL che andrebbero messi in BYPASS ogni volta che il devil viene riavviato. Ad oggi fa esattamente il contrario. 

Data: 10/09/2012 

Oggetto: configurazione nuova SunRay in Sala Controllo 

ID: 20120910.1 

Autore: Alessandro 

Descrizione: 

Su richiesta di Piermarini, ho configurato la SunRay usata sino ad oggi per visualizzare i segnali del LINAC, come effettiva console di lavoro (sulla dante003): 

dante@dante100>>> more /u2/dcs/db/dante_controls/dante003_tasks   ← FILE DI CONFIGURAZIONE 

labview:/u2/dcs/source_solaris/1_paradise/mains/dante.vi:pseudo.0003ba2a4e70:dafne 

labview:/u2/dcs/source_solaris/1_paradise/mains/dante.vi:pseudo.0003ba8ba219:dafne 

labview:/u2/dcs/source_solaris/1_paradise/mains/dante.vi:pseudo.0003ba2a4e79:dafne  ← NUOVO RIGO 

La SunRay e’ quella con lo schermo sul ripiano in alto, sopra la console tipicamente utilizzata dagli operatori del LINAC. 

Data: 01/08/2012 

Oggetto: porting dei ritardi programmabili Sala Modulatori su DEVIL690 

ID: 20120108.1 

Autore: Alessandro/Paolo 

Descrizione: 

I tre ritardi programmabili Stanford DG535 presenti in Sala Modulatori sono stati trasferiti 

dal DEVIL390 - LEXTEL 50 (Address FC) 

al DEVIL690 - dante081 - GPIB-ENET/1000 IP 192.168.191.34 

- il DEVIL Apple e' stato stellato sul WorlMap.DBFile (fatta copia di backup con data di oggi) 

- i vecchi DBFiles e le mappe su Solaris, sono stati disarmati spostandoli nella cartella AAA_OLD_390 

- i DBFiles del nuovo DEVIL690 sono stati aggiornati, aggiungendovi gli elementi che stavano sotto il 390 

- la dante081 e' stata configurata con gpibexplorer e visaconf: GPIB3::13, GPIB3::14, GPIB3::15 

ATTENZIONE: il DEVIL va in errore durante l'initHW sull'elemento con address 15. Da controllare. 

Controllato: si tratta di una incongruenza dei settaggi contenuti nel file che si imposta con il controllo dettagliato DG535. Non e’ un errore HW ma una segnalazione dello stanford che dice di non poter eseguire il setup per incongruenza delle impostazioni. 

Data: 09/07/2012 

Oggetto: timeout su tutta la catenella seriale SER15001 

ID: 20120709.1 

Autore: Alessandro 

Descrizione: 

a seguito di errore di comunicazione su tutti gli elementi connessi alla catenella seriale  MOXA 192.168.192.40 - porta 14 - SER15001 - devil 632 - dante075: 

- si e’ verificato, guardando il driver della control, quali elementi erano in timeout 

- si e’ consultato il file su TiCaCoDA (login: magneti, password: magneti) e si e’ visto che quegli elementi erano tutti e solo quelli sulla catenella SER15001. 

Tentativi di soluzione: