WebDAQ

Perché da un browser

Come è fatto

Due processi sulla macchina DAQ, un'interfaccia web e un server Python, e nessun passaggio di rete sul percorso dei dati: le schede vengono lette, decodificate e scritte su disco da una libreria C++ dentro il server stesso.

Cosa fa

• Schede

  Cerca i digitizzatori collegati (USB, fibra ottica, A4818, VME), li aggiunge e conserva l'intera configurazione dei registri di ogni scheda in un file. Da quel momento quel file è la configurazione della scheda, e ogni run ne porta con sé una copia.

• Acquisizione

  Un solo file .caendat per run per tutte le schede insieme, avviate in sincronia dal loro stesso meccanismo di partenza.

• Regolazione in linea

  Cambia soglie, finestre e filtro trapezoidale mentre il run è in corso, e osserva come cambiano la traccia e lo spettro: un fit in tempo reale dello spettro raccolto dall'ultima modifica dà la risoluzione di ogni impostazione. Alla scheda arriva solo ciò che si può toccare durante l'acquisizione, e in un run di produzione solo dopo una tua conferma; il resto aspetta il run successivo.

• Monitoraggio

  Spettri, forme d'onda e grafici di forma dell'impulso per ogni canale; rate di eventi, pile-up, persi e saturati canale per canale; corrente del fascio e carica accumulata.

• Spettri e regioni di interesse

  Regioni di interesse con nome e conteggi in tempo reale, definite una volta sola sul server: lo stesso cruscotto su ogni schermo, ripristinato dopo un riavvio e scritto in ogni run come roi.json.

• Slow control

  La corrente del fascio da un TetrAMM, da un RBD 9103 o da un valore che l'acceleratore già pubblica, e qualunque altro valore monitorato, registrati nel file stats.csv di ogni run con nome e unità di misura.

• Documentazione dei run

  I metadati del run scritti accanto ai dati, un registro di tutti i run con ricerca, valutazione e note, l'ELOG della collaborazione e le regole di allarme di Grafana legate al run.

• Sorveglianza

  Contatori di lettura per ogni scheda, allarmi su Telegram o Zulip e uno storico di ciò che è successo, con accanto le azioni per rimediare.

Un turno, in sei passi

In breve, dal capitolo «una sessione completa» della documentazione di WebDAQ. La visita guidata della demo percorre gli stessi passi.

1. 1

   1. Apri l'esperimento.

   Avvia WebDAQ e scegli la cartella di lavoro della campagna. Il server parte lì e crea ciò che gli serve: configurazione, calibrazioni, dati e database dei run. La cartella è l'esperimento.

2. 2

   2. Controlla l'hardware.

   Le schede compaiono con modello, firmware e collegamento, in verde quando il server le ha aperte. Il picoamperometro segna quasi zero a fascio spento, e si scelgono i valori da monitorare (tensione di terminale, rate), ognuno con nome e unità di misura.

3. 3

   3. Regola un canale.

   Nel tuner, con il salvataggio dei dati spento, imposta la soglia, poi il trapezio (o, per uno scintillatore, le finestre di carica) guardando l'impulso e lo spettro.

4. 4

   4. Avvia il run.

   Inserisci bersaglio, tensione di terminale e di sonda e tipo di run, e premi Start. WebDAQ copia nel run la configurazione di ogni scheda, avvia insieme le schede, la registrazione della corrente e le statistiche, e attiva le regole di allarme del run.

5. 5

   5. Tienilo d'occhio.

   Spettri, rate, corrente del fascio e carica, e i contatori delle schede, da dovunque si faccia il turno. Se una scheda si guasta, l'allarme arriva sul telefono e la pagina Troubleshoot propone il rimedio.

6. 6

   6. Ferma e scrivi.

   Lo Stop scrive la carica, i conteggi delle regioni di interesse e i metadati del run. La voce del logbook viene precompilata dalla documentazione del run; chi è di turno aggiunge il perché.

FAIR in pratica

I dati FAIR sono reperibili, accessibili, interoperabili e riutilizzabili (findable, accessible, interoperable, reusable). Per un esperimento tutto comincia dall'acquisizione: ciò che non viene annotato mentre il run è in corso è difficile da ricostruire dopo. WebDAQ è progettato perché ogni run lasci una documentazione predisposta per i principi FAIR, che ruota attorno al suo metadata.json. Ecco su cosa poggia oggi ciascuna lettera, nel codice, e quali sono i prossimi passi.

{
  "Schema Version": 1,
  "Run Number": 1276,
  "Start Time": "2025-11-14T21:03:12",
  "Stop Time": "2025-11-15T05:47:40",
  "Duration (s)": 31468.0,
  "Terminal Voltage": 380,
  "Run Type": "beam",
  "Target Name": "TiN #4",
  "Accumulated Charge": 2.71,
  "Flag": "good",
  "Acquisition": {
    "Synchronisation": "daisy-chain",
    "Software": { "webdaq": "…", "caendaq": "…", "acquisition_mode": "hardware" },
    "Boards": [ … ]
  },
  "Files": {
    "Data": ["run_1276_0000.caendat"],
    "Board Configuration": ["V1730_0.json"],
    "Current": ["current.txt"],
    "Statistics": ["stats.csv"],
    "Manifest": [ { "Name": "run_1276_0000.caendat", "Role": "raw-data", "Bytes": 1843200000 } ]
  }
}

Prova la demo

Link, licenza e citazione