Page History

...

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

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. 

...

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 

...

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 

...

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

...

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 

...

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 

...

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

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

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) 

!!! 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 - E642Probus 

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

...

seguente: 

Caso nativeVISA 

#SER15002#SER68001 

@HCI(S)[DI32,(DBL),A32SHU32,DU32,DU32,A32SHU32,DU32,DU32,(DBL):61] 

10,SER15002SER68001,E02FE000E02FF000,1024,40100,E02FE800E02FF800,1024,40,QUATE001:QUATE002:QUATP001:QUATP002:QUATP003:QUATP004100,QSKEL106 

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

10,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2SerCh001,E3FF4000,640,0C5 (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 VISAnative 

#SER68001 

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

0,SER68001,E02FF000,1024,10050,E02FF800,1024,10050,QSKEL106QSKPS101 

@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] 

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

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

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 

...