Avvio: aprire le camere subito, il primo scatto dopo l'avvio dura ~25 s #108

Closed
opened 2026-10-25 17:15:27 +00:00 by Adriano · 3 comments
Owner

Dopo ogni avvio del TMF il primo grab apre la camera GenTL e dura ~25 s (misurato 25/10/2026 su daitarn, Itala camera:601020: 24,76 s); l'operatore pensa che la camera non parta (Adriano 25/10 18:14, pagina misura task 8). Cosa: packaging/windows/avvio.py, dopo avvia_server, un thread che aspetta la porta camera e fa un grab a vuoto per ogni camera configurata (stazioni e acquisizione dei task). Criterio: dopo l'avvio, il primo «Acquisisci» dell'operatore risponde in meno di 1 s.

Dopo ogni avvio del TMF il primo grab apre la camera GenTL e dura ~25 s (misurato 25/10/2026 su daitarn, Itala camera:601020: 24,76 s); l'operatore pensa che la camera non parta (Adriano 25/10 18:14, pagina misura task 8). Cosa: packaging/windows/avvio.py, dopo avvia_server, un thread che aspetta la porta camera e fa un grab a vuoto per ogni camera configurata (stazioni e acquisizione dei task). Criterio: dopo l'avvio, il primo «Acquisisci» dell'operatore risponde in meno di 1 s.
Adriano added the sviluppo label 2026-10-25 17:15:27 +00:00
Author
Owner

ESITO: richiesta
RIF: gitea:Adriano/TieMeasureFlow#108
COSA: all'avvio del TMF, packaging/windows/avvio.py apre le camere configurate con un grab a vuoto, in un thread daemon, così il primo «Acquisisci» dell'operatore non aspetta ~25 s.

BASE: ramo lavoro/daitarn-tmf-108 da 249999f, worktree C:/Users/Adriano/lavoro/TieMeasureFlow-108.

VERIFICATO (daitarn 25/10/2026):

  • primo POST /camera/grab dopo l'avvio → 24,76 s; i successivi → 0,06 s;
  • packaging/windows/sviluppo.ps1:52 lancia avvio.py, che è lo stesso launcher dell'installato;
  • db %PROGRAMDATA%\Tielogic\TieMeasureFlow\tmf.db: tabella stations (camera_url, camera_source), oggi (1, ST-DEFAULT, http://127.0.0.1:8765, camera:601020); tabella recipe_tasks.acquisition_json (JSON con camera_url e camera_source, #97), oggi tutte NULL.

MODIFICHE (solo packaging/windows/avvio.py)

  1. camere_da_scaldare(db: Path) -> list[tuple[str, str]]: legge in sola lettura (sqlite3, file:...?mode=ro, come _nessun_utente):
    • da stations: le coppie (camera_url, camera_source) entrambe non vuote;
    • da recipe_tasks.acquisition_json: le coppie con camera_url e camera_source non vuoti (json.loads; JSON non valido → si salta);
    • deduplicate, nell'ordine di lettura; qualsiasi errore sqlite → lista vuota.
      Solo le sorgenti che iniziano con "camera:" e non sono "camera:folder" (le altre non aprono hardware).
  2. scalda_camere(db: Path) -> None:
    • aspetta che PORTA_CAMERA sia aperta (stesso ciclo di _apri_browser_quando_pronto, max ~60 s); se non si apre, log.warning ed esce;
    • per ogni coppia: POST {camera_url.rstrip('/')}/camera/grab con JSON {"source": src, "trigger": "continuo", "timeout_ms": 5000}, timeout 90 s, con urllib.request (niente dipendenze nuove; avvio.py usa già urllib);
    • log.info con sorgente, esito HTTP e durata in secondi; ogni eccezione → log.warning, si passa alla successiva; mai un'eccezione fuori dal thread.
  3. In main, subito dopo thread = avvia_server(args.host, dati): threading.Thread(target=scalda_camere, args=(dati / "tmf.db",), daemon=True).start(), con o senza browser.
  4. Commento «#108» breve su ogni aggiunta; docstring brevi in italiano come il resto del file.

TEST

  • packaging/windows/tests/test_avvio.py (seguire lo schema esistente):
    • camere_da_scaldare su un db sqlite temporaneo con le due tabelle minime: stazione con camera, stazione senza, task con acquisition_json valido, JSON rotto, una sorgente camera:folder, un duplicato → lista attesa;
    • db inesistente → [];
    • scalda_camere con _porta_aperta patchata a True e urlopen patchato: una chiamata per coppia, URL e body corretti; un'eccezione di urlopen non esce dalla funzione.
  • Comando: vedere come i test di packaging/windows/tests sono lanciati (README o build.ps1); se non è chiaro, C:/Users/Adriano/lavoro/TieMeasureFlow-dxfcal/build/venv313/Scripts/python.exe -m pytest packaging/windows/tests -q -p no:cacheprovider dal worktree (se quel venv manca, usare quello indicato in build.ps1). Tutti i test esistenti di test_avvio.py devono restare verdi.

NON TOCCARE: src/** , vendor/**, sviluppo.ps1, build.ps1, TieMeasureFlow.iss, il resto di main().

PROVA (Opus): merge, riavvio del TMF, nel log scalda della camera:601020 con ~25 s; subito dopo, POST /maker/api/stations/1/camera/grab < 1 s.

ESITO: richiesta RIF: gitea:Adriano/TieMeasureFlow#108 COSA: all'avvio del TMF, packaging/windows/avvio.py apre le camere configurate con un grab a vuoto, in un thread daemon, così il primo «Acquisisci» dell'operatore non aspetta ~25 s. BASE: ramo lavoro/daitarn-tmf-108 da 249999f, worktree C:/Users/Adriano/lavoro/TieMeasureFlow-108. VERIFICATO (daitarn 25/10/2026): - primo POST /camera/grab dopo l'avvio → 24,76 s; i successivi → 0,06 s; - packaging/windows/sviluppo.ps1:52 lancia avvio.py, che è lo stesso launcher dell'installato; - db %PROGRAMDATA%\Tielogic\TieMeasureFlow\tmf.db: tabella `stations` (camera_url, camera_source), oggi (1, ST-DEFAULT, http://127.0.0.1:8765, camera:601020); tabella `recipe_tasks.acquisition_json` (JSON con camera_url e camera_source, #97), oggi tutte NULL. MODIFICHE (solo packaging/windows/avvio.py) 1. `camere_da_scaldare(db: Path) -> list[tuple[str, str]]`: legge in sola lettura (sqlite3, `file:...?mode=ro`, come `_nessun_utente`): - da `stations`: le coppie (camera_url, camera_source) entrambe non vuote; - da `recipe_tasks.acquisition_json`: le coppie con camera_url e camera_source non vuoti (json.loads; JSON non valido → si salta); - deduplicate, nell'ordine di lettura; qualsiasi errore sqlite → lista vuota. Solo le sorgenti che iniziano con "camera:" e non sono "camera:folder" (le altre non aprono hardware). 2. `scalda_camere(db: Path) -> None`: - aspetta che PORTA_CAMERA sia aperta (stesso ciclo di `_apri_browser_quando_pronto`, max ~60 s); se non si apre, log.warning ed esce; - per ogni coppia: POST `{camera_url.rstrip('/')}/camera/grab` con JSON {"source": src, "trigger": "continuo", "timeout_ms": 5000}, timeout 90 s, con urllib.request (niente dipendenze nuove; avvio.py usa già urllib); - log.info con sorgente, esito HTTP e durata in secondi; ogni eccezione → log.warning, si passa alla successiva; mai un'eccezione fuori dal thread. 3. In `main`, subito dopo `thread = avvia_server(args.host, dati)`: `threading.Thread(target=scalda_camere, args=(dati / "tmf.db",), daemon=True).start()`, con o senza browser. 4. Commento «#108» breve su ogni aggiunta; docstring brevi in italiano come il resto del file. TEST - packaging/windows/tests/test_avvio.py (seguire lo schema esistente): - camere_da_scaldare su un db sqlite temporaneo con le due tabelle minime: stazione con camera, stazione senza, task con acquisition_json valido, JSON rotto, una sorgente camera:folder, un duplicato → lista attesa; - db inesistente → []; - scalda_camere con `_porta_aperta` patchata a True e urlopen patchato: una chiamata per coppia, URL e body corretti; un'eccezione di urlopen non esce dalla funzione. - Comando: vedere come i test di packaging/windows/tests sono lanciati (README o build.ps1); se non è chiaro, `C:/Users/Adriano/lavoro/TieMeasureFlow-dxfcal/build/venv313/Scripts/python.exe -m pytest packaging/windows/tests -q -p no:cacheprovider` dal worktree (se quel venv manca, usare quello indicato in build.ps1). Tutti i test esistenti di test_avvio.py devono restare verdi. NON TOCCARE: src/** , vendor/**, sviluppo.ps1, build.ps1, TieMeasureFlow.iss, il resto di main(). PROVA (Opus): merge, riavvio del TMF, nel log `scalda` della camera:601020 con ~25 s; subito dopo, POST /maker/api/stations/1/camera/grab < 1 s.
Adriano added the assegnata:daitarn label 2026-10-25 17:15:53 +00:00
Author
Owner

🔵 daitarn — preso in carico 2026-10-25T17:15:49Z
ramo: lavoro/daitarn · capacità: build-windows, gpu

🔵 daitarn — **preso in carico** 2026-10-25T17:15:49Z ramo: `lavoro/daitarn` · capacità: build-windows, gpu
Author
Owner

Soluzione

ESITO: fatto
RIF: gitea:Adriano/TieMeasureFlow#108
COSA: all'avvio avvio.py apre le camere configurate con un grab a vuoto in un thread daemon; il primo «Acquisisci» dell'operatore non aspetta più l'apertura GenTL.
FILE:

  • packaging/windows/avvio.py — camere_da_scaldare(db): coppie (camera_url, camera_source) da stations e recipe_tasks.acquisition_json, solo camera:* esclusa camera:folder, deduplicate; scalda_camere(db): attende la porta 8765, POST /camera/grab timeout 90 s, log di esito e durata; thread avviato in main dopo avvia_server
  • packaging/windows/tests/test_avvio.py — 4 test nuovi
    Commit cab419b e b2e3867 (Sonnet, claude-sonnet-5-5), ramo lavoro/daitarn-tmf-dxfcal pushato.
    PROVA:
  • pytest packaging/windows/tests → 26 passed
  • daitarn 25/10/2026, TMF riavviato: log «tmf.avvio: scalda camera camera:601020: HTTP 200 in 32.3 s»; subito dopo POST /maker/api/stations/1/camera/grab → 200 in 0,07 s (prima del fix: 24,76 s)
    MANCA: nulla. Sul PC fiera vale dall'installazione della build nuova.
**Soluzione** ESITO: fatto RIF: gitea:Adriano/TieMeasureFlow#108 COSA: all'avvio avvio.py apre le camere configurate con un grab a vuoto in un thread daemon; il primo «Acquisisci» dell'operatore non aspetta più l'apertura GenTL. FILE: - packaging/windows/avvio.py — camere_da_scaldare(db): coppie (camera_url, camera_source) da stations e recipe_tasks.acquisition_json, solo camera:* esclusa camera:folder, deduplicate; scalda_camere(db): attende la porta 8765, POST /camera/grab timeout 90 s, log di esito e durata; thread avviato in main dopo avvia_server - packaging/windows/tests/test_avvio.py — 4 test nuovi Commit cab419b e b2e3867 (Sonnet, claude-sonnet-5-5), ramo lavoro/daitarn-tmf-dxfcal pushato. PROVA: - pytest packaging/windows/tests → 26 passed - daitarn 25/10/2026, TMF riavviato: log «tmf.avvio: scalda camera camera:601020: HTTP 200 in 32.3 s»; subito dopo POST /maker/api/stations/1/camera/grab → 200 in 0,07 s (prima del fix: 24,76 s) MANCA: nulla. Sul PC fiera vale dall'installazione della build nuova.
Adriano removed the assegnata:daitarn label 2026-10-25 17:18:02 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Adriano/TieMeasureFlow#108