Primo scatto dalla camera dopo l'avvio: «Servizio camera non raggiungibile» (timeout 15 s) #106

Closed
opened 2026-10-25 16:51:36 +00:00 by Adriano · 3 comments
Owner

src/frontend/flask_app/blueprints/maker.py:611 e src/frontend/flask_app/blueprints/measure.py:1120: il proxy POST <camera_url>/camera/grab ha timeout=15. Dopo ogni avvio del TMF il primo grab apre la camera GenTL (Itala ITA32-GM-10C, camera:601020) e impiega più di 15 s: Flask risponde 502 «Servizio camera non raggiungibile: Read timed out»; l'acquisitore non registra la richiesta (client già disconnesso). I grab successivi durano 0,04 s. Riprodotto da Adriano su daitarn il 25/10/2026 alle ~17:49 nel wizard «Crea ricetta da DXF». Anche admin.py:185 (GET /camera/sources, timeout=5) è vicino al limite: la prima enumerazione ha impiegato 3,7 s.

src/frontend/flask_app/blueprints/maker.py:611 e src/frontend/flask_app/blueprints/measure.py:1120: il proxy POST <camera_url>/camera/grab ha timeout=15. Dopo ogni avvio del TMF il primo grab apre la camera GenTL (Itala ITA32-GM-10C, camera:601020) e impiega più di 15 s: Flask risponde 502 «Servizio camera non raggiungibile: Read timed out»; l'acquisitore non registra la richiesta (client già disconnesso). I grab successivi durano 0,04 s. Riprodotto da Adriano su daitarn il 25/10/2026 alle ~17:49 nel wizard «Crea ricetta da DXF». Anche admin.py:185 (GET /camera/sources, timeout=5) è vicino al limite: la prima enumerazione ha impiegato 3,7 s.
Adriano added the bug label 2026-10-25 16:51:36 +00:00
Author
Owner

ESITO: richiesta
RIF: gitea:Adriano/TieMeasureFlow#106
COSA: alzare i timeout dei proxy Flask verso l'acquisitore, così il primo grab dopo l'avvio (apertura GenTL lenta) non fallisce.

BASE: ramo lavoro/daitarn-tmf-106 da 08616aa, worktree C:/Users/Adriano/lavoro/TieMeasureFlow-106.

VERIFICATO (daitarn 25/10/2026):

  • curl POST 127.0.0.1:8765/camera/grab a camera già aperta → 200 in 0,04 s;
  • nel log dell'acquisitore non c'è il grab di Adriano delle 17:49: uvicorn non registra una richiesta il cui client si è già disconnesso.
    PRESUNTO: la prima apertura GenTL dura più di 15 s (già osservato prima in questa sessione, durata esatta non misurata).

MODIFICHE

  1. src/frontend/flask_app/blueprints/maker.py, api_station_camera_grab (~riga 611): timeout=15 → timeout=60.
  2. src/frontend/flask_app/blueprints/measure.py, api_vision_grab (~riga 1120): timeout=15 → timeout=60.
  3. src/frontend/flask_app/blueprints/admin.py, api_camera_sources (~riga 185): timeout=5 → timeout=15.
  4. Il valore 60 va in una costante di modulo per ciascun file, CAMERA_GRAB_TIMEOUT_S = 60, con commento «#106: la prima apertura GenTL dopo l'avvio supera 15 s». Non serve un modulo condiviso. Il timeout_ms=5000 del payload resta com'è.
  5. Commento «#106» su ogni riga cambiata.

TEST

  • tests/test_measure_camera_grab.py:71 → 60; tests/test_maker_acquisition.py:60 → 60; tests/test_admin_stations.py:281 → 15.
  • Suite da src/frontend/flask_app: C:/Users/Adriano/lavoro/TieMeasureFlow-dxfcal-frontend/.venv/Scripts/python.exe -m pytest tests -q -p no:cacheprovider. Base del ramo dxfcal: 13 failed (9 noti + 4 lingua/.mo). Nessun fallimento nuovo.

NON TOCCARE: maker.py:578 (sources, già 15), vendor/, src/backend/, src/vision*/**, il JS.

ESITO: richiesta RIF: gitea:Adriano/TieMeasureFlow#106 COSA: alzare i timeout dei proxy Flask verso l'acquisitore, così il primo grab dopo l'avvio (apertura GenTL lenta) non fallisce. BASE: ramo lavoro/daitarn-tmf-106 da 08616aa, worktree C:/Users/Adriano/lavoro/TieMeasureFlow-106. VERIFICATO (daitarn 25/10/2026): - curl POST 127.0.0.1:8765/camera/grab a camera già aperta → 200 in 0,04 s; - nel log dell'acquisitore non c'è il grab di Adriano delle 17:49: uvicorn non registra una richiesta il cui client si è già disconnesso. PRESUNTO: la prima apertura GenTL dura più di 15 s (già osservato prima in questa sessione, durata esatta non misurata). MODIFICHE 1. src/frontend/flask_app/blueprints/maker.py, api_station_camera_grab (~riga 611): timeout=15 → timeout=60. 2. src/frontend/flask_app/blueprints/measure.py, api_vision_grab (~riga 1120): timeout=15 → timeout=60. 3. src/frontend/flask_app/blueprints/admin.py, api_camera_sources (~riga 185): timeout=5 → timeout=15. 4. Il valore 60 va in una costante di modulo per ciascun file, `CAMERA_GRAB_TIMEOUT_S = 60`, con commento «#106: la prima apertura GenTL dopo l'avvio supera 15 s». Non serve un modulo condiviso. Il timeout_ms=5000 del payload resta com'è. 5. Commento «#106» su ogni riga cambiata. TEST - tests/test_measure_camera_grab.py:71 → 60; tests/test_maker_acquisition.py:60 → 60; tests/test_admin_stations.py:281 → 15. - Suite da src/frontend/flask_app: `C:/Users/Adriano/lavoro/TieMeasureFlow-dxfcal-frontend/.venv/Scripts/python.exe -m pytest tests -q -p no:cacheprovider`. Base del ramo dxfcal: 13 failed (9 noti + 4 lingua/.mo). Nessun fallimento nuovo. NON TOCCARE: maker.py:578 (sources, già 15), vendor/**, src/backend/**, src/vision*/**, il JS.
Adriano added the assegnata:daitarn label 2026-10-25 16:51:59 +00:00
Author
Owner

🔵 daitarn — preso in carico 2026-10-25T16:51:55Z
ramo: lavoro/daitarn · capacità: build-windows, gpu

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

Soluzione

ESITO: fatto
RIF: gitea:Adriano/TieMeasureFlow#106
COSA: timeout dei proxy Flask verso l'acquisitore alzati; il primo grab dopo l'avvio non cade più.
FILE:

  • src/frontend/flask_app/blueprints/maker.py — CAMERA_GRAB_TIMEOUT_S = 60, usata in api_station_camera_grab (era 15)
  • src/frontend/flask_app/blueprints/measure.py — CAMERA_GRAB_TIMEOUT_S = 60, usata in api_vision_grab (era 15)
  • src/frontend/flask_app/blueprints/admin.py:185 — GET /camera/sources timeout 5 → 15
  • test: test_measure_camera_grab.py, test_admin_stations.py, test_dxf_recipe_routes.py (nuova assert timeout 60 sul grab maker)
    Commit 7cb877b (Sonnet, claude-sonnet-5-5) + 5737655 (revisione Opus), ramo lavoro/daitarn-tmf-dxfcal pushato.
    PROVA:
  • pytest tests (flask_app) → 9 failed noti, 410 passed, 2 skipped; file toccati → 90 passed
  • daitarn, TMF riavviato 25/10/2026: primo POST /maker/api/stations/1/camera/grab a freddo → 200 in 24,76 s (prima cadeva a 15 s); secondo → 200 in 0,06 s
    MANCA: nulla. Valutare sul PC fiera la durata della prima apertura con le sue camere.
**Soluzione** ESITO: fatto RIF: gitea:Adriano/TieMeasureFlow#106 COSA: timeout dei proxy Flask verso l'acquisitore alzati; il primo grab dopo l'avvio non cade più. FILE: - src/frontend/flask_app/blueprints/maker.py — CAMERA_GRAB_TIMEOUT_S = 60, usata in api_station_camera_grab (era 15) - src/frontend/flask_app/blueprints/measure.py — CAMERA_GRAB_TIMEOUT_S = 60, usata in api_vision_grab (era 15) - src/frontend/flask_app/blueprints/admin.py:185 — GET /camera/sources timeout 5 → 15 - test: test_measure_camera_grab.py, test_admin_stations.py, test_dxf_recipe_routes.py (nuova assert timeout 60 sul grab maker) Commit 7cb877b (Sonnet, claude-sonnet-5-5) + 5737655 (revisione Opus), ramo lavoro/daitarn-tmf-dxfcal pushato. PROVA: - pytest tests (flask_app) → 9 failed noti, 410 passed, 2 skipped; file toccati → 90 passed - daitarn, TMF riavviato 25/10/2026: primo POST /maker/api/stations/1/camera/grab a freddo → 200 in 24,76 s (prima cadeva a 15 s); secondo → 200 in 0,06 s MANCA: nulla. Valutare sul PC fiera la durata della prima apertura con le sue camere.
Adriano removed the assegnata:daitarn label 2026-10-25 16:58:55 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Adriano/TieMeasureFlow#106