Fiera 27-29/10: demo TMF con calibro, attività e camera TC bench (misure, PM, DXF compare su Sider) #72

New Issue

2026-10-12T13:00:57Z

Adriano commented

2026-10-12 13:00:57 +00:00

ESITO: richiesta
RIF: gitea:Adriano/TieMeasureFlow (V3.0.0 82ad885); fiera con Ricerca e Misure (Menoncin) 27-29/10/2026
COSA: contenuto della demo in fiera deciso da Adriano il 12/10/2026.

HARDWARE DISPONIBILE: TC CORE BENCH 036 di Opto Engineering (camera integrata); una telecentrica con stativo.
SI ESPONE: TieMeasureFlow con

calibro USB (emulatore di tastiera, già provato in TMF il 15/09; il calibro è di Menoncin, restituito il 15/09);
gestione per attività (ricetta → task → misura guidata → esito OK/warning/fail → statistica);
camera del TC bench collegata a TMF per: misure, pattern matching, DXF compare.
CAMPIONI: profili Sider Engineering (5 disegni DWG+PDF in Shared/5_SIDER ENG/1_Materiale utile/).

STATO VERIFICATO:

TMF esegue qualunque ricetta VisionSuite v2 nel worker vision (#46 chiusa): misure, MatchPattern, CompareDxf, overlay salvato.
CompareDxf anchor="align" prende la posa dal localizzatore (visionsuite origin/main c84bfd4, packages/vs-tools/src/visionsuite/tools/dxf.py:15,136): PM + DXF compare componibili.
L'immagine entra in TMF solo da UPLOAD. La camera via agente di stazione (#3) NON esiste ed è attesa:cliente (decisioni Tràfilo).

MANCA PER LA FIERA (ordine di rischio):

Acquisizione dalla camera del TC bench dentro il flusso operatore. Proposta minima, staccata da #3: processo locale sul PC demo (vs-camera, nativo, fuori Docker per la GigE) con GET /grab; nella schermata operatore un tasto «Acquisisci» lo chiama e passa il fotogramma alla stessa API dell'upload (/api/vision/execute). Niente station_devices, niente WebSocket. Da decidere: questa via o anticipare #3.
Modello e SDK della camera del TC CORE BENCH 036 (Itala GenTL? OECS?) e prova di acquisizione con vs-camera.
Calibrazione mm/px del bench (target o ingrandimento nominale della telecentrica) da mettere nella ricetta.
Sider: DWG → DXF (5 profili), ricette MatchPattern (con rotazione: i profili arrivano orientati a caso) + CompareDxf + 2-3 quote; verificare risoluzione contro ±0,05 mm.
PC della demo: installazione TMF offline (docker-compose.dev, Nginx HTTP, SESSION_COOKIE_SECURE=false), monitor touch, rete isolata.
Ruolo della telecentrica con stativo: seconda postazione? (domanda ad Adriano)
Bug gitea:Adriano/TieMeasureFlow#71 (migrazione 015): irrilevante su DB nuovo, rilevante se si clona un DB esistente.

APERTE: nome e sede della fiera; dove sta l'hardware e quando arriva a Tielogic; chi porta PC e monitor; data della prova generale (proposta: entro 22/10).
CRITERIO DI FATTO: sul PC della fiera, un pezzo Sider appoggiato sul bench → «Acquisisci» → esito PM + DXF compare + quote con tolleranze, salvato in statistica; un task col calibro nella stessa ricetta.

AGGIORNAMENTO 15/10/2026: fiera = A&T Vicenza (Automation & Testing), Fiera di Vicenza, 27-29/10. Perimetro esteso: assistente di ricetta LLM in vs-gui (gitea:Adriano/visionsuite#282) + test DXF compare su Sider. Dettaglio nel commento 13787.

ESITO: richiesta RIF: gitea:Adriano/TieMeasureFlow (V3.0.0 82ad885); fiera con Ricerca e Misure (Menoncin) 27-29/10/2026 COSA: contenuto della demo in fiera deciso da Adriano il 12/10/2026. HARDWARE DISPONIBILE: TC CORE BENCH 036 di Opto Engineering (camera integrata); una telecentrica con stativo. SI ESPONE: TieMeasureFlow con 1. calibro USB (emulatore di tastiera, già provato in TMF il 15/09; il calibro è di Menoncin, restituito il 15/09); 2. gestione per attività (ricetta → task → misura guidata → esito OK/warning/fail → statistica); 3. camera del TC bench collegata a TMF per: misure, pattern matching, DXF compare. CAMPIONI: profili Sider Engineering (5 disegni DWG+PDF in Shared/5_SIDER ENG/1_Materiale utile/). STATO VERIFICATO: - TMF esegue qualunque ricetta VisionSuite v2 nel worker `vision` (#46 chiusa): misure, MatchPattern, CompareDxf, overlay salvato. - CompareDxf `anchor="align"` prende la posa dal localizzatore (visionsuite origin/main c84bfd4, packages/vs-tools/src/visionsuite/tools/dxf.py:15,136): PM + DXF compare componibili. - L'immagine entra in TMF solo da UPLOAD. La camera via agente di stazione (#3) NON esiste ed è attesa:cliente (decisioni Tràfilo). MANCA PER LA FIERA (ordine di rischio): 1. Acquisizione dalla camera del TC bench dentro il flusso operatore. Proposta minima, staccata da #3: processo locale sul PC demo (vs-camera, nativo, fuori Docker per la GigE) con `GET /grab`; nella schermata operatore un tasto «Acquisisci» lo chiama e passa il fotogramma alla stessa API dell'upload (`/api/vision/execute`). Niente station_devices, niente WebSocket. Da decidere: questa via o anticipare #3. 2. Modello e SDK della camera del TC CORE BENCH 036 (Itala GenTL? OECS?) e prova di acquisizione con vs-camera. 3. Calibrazione mm/px del bench (target o ingrandimento nominale della telecentrica) da mettere nella ricetta. 4. Sider: DWG → DXF (5 profili), ricette MatchPattern (con rotazione: i profili arrivano orientati a caso) + CompareDxf + 2-3 quote; verificare risoluzione contro ±0,05 mm. 5. PC della demo: installazione TMF offline (docker-compose.dev, Nginx HTTP, SESSION_COOKIE_SECURE=false), monitor touch, rete isolata. 6. Ruolo della telecentrica con stativo: seconda postazione? (domanda ad Adriano) 7. Bug gitea:Adriano/TieMeasureFlow#71 (migrazione 015): irrilevante su DB nuovo, rilevante se si clona un DB esistente. APERTE: nome e sede della fiera; dove sta l'hardware e quando arriva a Tielogic; chi porta PC e monitor; data della prova generale (proposta: entro 22/10). CRITERIO DI FATTO: sul PC della fiera, un pezzo Sider appoggiato sul bench → «Acquisisci» → esito PM + DXF compare + quote con tolleranze, salvato in statistica; un task col calibro nella stessa ricetta. AGGIORNAMENTO 15/10/2026: fiera = A&T Vicenza (Automation & Testing), Fiera di Vicenza, 27-29/10. Perimetro esteso: assistente di ricetta LLM in vs-gui (gitea:Adriano/visionsuite#282) + test DXF compare su Sider. Dettaglio nel commento 13787.

Adriano added the sviluppo label 2026-10-12 13:00:57 +00:00

Adriano commented

2026-10-15 07:44:43 +00:00

ANALISI (passo 1, claude-opus-5-5) — acquisizione dalla camera, parte 1 di #72
RIF: gitea:Adriano/TieMeasureFlow#72, base V3.0.0 5bf374a
DECISIONI DI ADRIANO (15/10/2026): processo locale, non #3; bench TC CORE BENCH 036 sta da Menoncin; telecentrica con stativo = seconda postazione; PC e monitor della demo li porta Menoncin.

ARCHITETTURA: niente servizio nuovo. Sul PC della demo gira vs-gui (VisionSuite) nativo, che ha già POST /camera/grab {source, trigger, timeout_ms} → PNG (vendor/visionsuite/packages/vs-gui/src/visionsuite/gui/server.py:355), con GenTL Itala/Opto via harvesters e la sorgente finta camera:folder per provare senza ferro. Ogni stazione TMF dichiara URL del servizio e nome della sorgente. Il Flask fa da proxy (niente CORS, niente X-API-Key nel browser) e il fotogramma entra in acquire(blob) di vision_execute.js:27, cioè nella stessa API dell'upload.

CONTRATTO (identico per A e B):

stations.camera_url VARCHAR(500) NULL — stesso validatore di vision_worker_url (vuoto→None, http(s)://, senza / finale).
stations.camera_source VARCHAR(200) NULL — strip, vuoto→None. Es. camera:<seriale>, camera:folder.
StationCreate/StationUpdate/StationResponse portano i due campi.
NUOVO GET /api/stations/by-code/{code} → StationResponse; 404 se il codice non esiste; auth come GET /api/stations/{station_id}.
Flask POST /measure/api/vision/grab (login_required, role MeasurementTec), senza corpo: stazione = _current_station(); legge la stazione da /api/stations/by-code/{code}; senza camera_url o camera_source → 409 JSON {"error": "..."}; altrimenti POST {camera_url}/camera/grab json {"source": camera_source, "trigger": "continuo", "timeout_ms": 5000}, timeout 15 s; 200 → PNG così com'è (image/png); 404/503/504 del servizio → 502 JSON con il dettaglio; servizio irraggiungibile → 502 JSON.

PIANO A — backend (agente A, ramo lavoro/jeeg-tmf72-backend):
FILE: src/backend/migrations/versions/020_station_camera.py (nuova, down_revision 019_station_vision_worker, batch_alter_table, downgrade toglie le due colonne); src/backend/models/orm/station.py; src/backend/models/api/station.py; src/backend/services/station_service.py (create e update); src/backend/api/routers/stations.py (by-code, PRIMA di /{station_id} per l'ordine delle route).
TEST: test_migrations.py (020 su e giù, schema come 019); test_stations_api.py (crea/aggiorna/leggi i due campi, validazione URL, by-code 200 e 404).
NON TOCCARE: frontend, vision_service, migrazioni 000-019.

PIANO B — frontend (agente B, ramo lavoro/jeeg-tmf72-frontend):
FILE: src/frontend/flask_app/services/api_client.py (get_station_by_code); blueprints/measure.py (route grab; flag camera_enabled passato al template di task_execute, calcolato dalla stazione corrente, falso se la chiamata fallisce); templates/measure/task_execute.html (pulsante «Acquisisci dalla camera» accanto all'input file, solo con camera_enabled; grabUrl in window.__visionCfg); static/js/vision_execute.js (metodo grab(): fetch POST con X-CSRFToken → blob → this.acquire(blob); errore mostrato come oggi gli errori di execute; stato busy); templates/admin/stations.html (due campi, nei cinque punti JS dove compare vision_worker_url); translations it/en (+ compilazione .mo se il repo la versiona); docker-compose.dev.yml (client: extra_hosts "host.docker.internal:host-gateway", così da container si raggiunge vs-gui sull'host Linux).
TEST: src/frontend/flask_app/tests — route grab con api_client e requests finti: 409 senza camera, 200 PNG passato, 502 su 503 del servizio, 502 su ConnectionError; ruolo richiesto; admin stazioni con i campi nuovi.
NON TOCCARE: backend, vendor/visionsuite, vision_execute.acquire().

DOPO (Opus): merge dei due rami, suite intera, prova d'insieme in docker-compose.dev con vs-gui su jeeg e camera:folder sui BMP Sider.
PARTI SUCCESSIVE (non in questo giro): ricette Sider (servono i DXF: nessun convertitore DWG su jeeg), calibrazione mm/px per stazione, guida d'installazione sul PC di Menoncin.

ANALISI (passo 1, claude-opus-5-5) — acquisizione dalla camera, parte 1 di #72 RIF: gitea:Adriano/TieMeasureFlow#72, base V3.0.0 5bf374a DECISIONI DI ADRIANO (15/10/2026): processo locale, non #3; bench TC CORE BENCH 036 sta da Menoncin; telecentrica con stativo = seconda postazione; PC e monitor della demo li porta Menoncin. ARCHITETTURA: niente servizio nuovo. Sul PC della demo gira vs-gui (VisionSuite) nativo, che ha già `POST /camera/grab` {source, trigger, timeout_ms} → PNG (vendor/visionsuite/packages/vs-gui/src/visionsuite/gui/server.py:355), con GenTL Itala/Opto via harvesters e la sorgente finta `camera:folder` per provare senza ferro. Ogni stazione TMF dichiara URL del servizio e nome della sorgente. Il Flask fa da proxy (niente CORS, niente X-API-Key nel browser) e il fotogramma entra in `acquire(blob)` di vision_execute.js:27, cioè nella stessa API dell'upload. CONTRATTO (identico per A e B): - stations.camera_url VARCHAR(500) NULL — stesso validatore di vision_worker_url (vuoto→None, http(s)://, senza / finale). - stations.camera_source VARCHAR(200) NULL — strip, vuoto→None. Es. `camera:<seriale>`, `camera:folder`. - StationCreate/StationUpdate/StationResponse portano i due campi. - NUOVO `GET /api/stations/by-code/{code}` → StationResponse; 404 se il codice non esiste; auth come `GET /api/stations/{station_id}`. - Flask `POST /measure/api/vision/grab` (login_required, role MeasurementTec), senza corpo: stazione = `_current_station()`; legge la stazione da `/api/stations/by-code/{code}`; senza camera_url o camera_source → 409 JSON {"error": "..."}; altrimenti POST `{camera_url}/camera/grab` json {"source": camera_source, "trigger": "continuo", "timeout_ms": 5000}, timeout 15 s; 200 → PNG così com'è (image/png); 404/503/504 del servizio → 502 JSON con il dettaglio; servizio irraggiungibile → 502 JSON. PIANO A — backend (agente A, ramo lavoro/jeeg-tmf72-backend): FILE: src/backend/migrations/versions/020_station_camera.py (nuova, down_revision 019_station_vision_worker, batch_alter_table, downgrade toglie le due colonne); src/backend/models/orm/station.py; src/backend/models/api/station.py; src/backend/services/station_service.py (create e update); src/backend/api/routers/stations.py (by-code, PRIMA di `/{station_id}` per l'ordine delle route). TEST: test_migrations.py (020 su e giù, schema come 019); test_stations_api.py (crea/aggiorna/leggi i due campi, validazione URL, by-code 200 e 404). NON TOCCARE: frontend, vision_service, migrazioni 000-019. PIANO B — frontend (agente B, ramo lavoro/jeeg-tmf72-frontend): FILE: src/frontend/flask_app/services/api_client.py (get_station_by_code); blueprints/measure.py (route grab; flag `camera_enabled` passato al template di task_execute, calcolato dalla stazione corrente, falso se la chiamata fallisce); templates/measure/task_execute.html (pulsante «Acquisisci dalla camera» accanto all'input file, solo con camera_enabled; `grabUrl` in window.__visionCfg); static/js/vision_execute.js (metodo grab(): fetch POST con X-CSRFToken → blob → this.acquire(blob); errore mostrato come oggi gli errori di execute; stato busy); templates/admin/stations.html (due campi, nei cinque punti JS dove compare vision_worker_url); translations it/en (+ compilazione .mo se il repo la versiona); docker-compose.dev.yml (client: extra_hosts "host.docker.internal:host-gateway", così da container si raggiunge vs-gui sull'host Linux). TEST: src/frontend/flask_app/tests — route grab con api_client e requests finti: 409 senza camera, 200 PNG passato, 502 su 503 del servizio, 502 su ConnectionError; ruolo richiesto; admin stazioni con i campi nuovi. NON TOCCARE: backend, vendor/visionsuite, vision_execute.acquire(). DOPO (Opus): merge dei due rami, suite intera, prova d'insieme in docker-compose.dev con vs-gui su jeeg e `camera:folder` sui BMP Sider. PARTI SUCCESSIVE (non in questo giro): ricette Sider (servono i DXF: nessun convertitore DWG su jeeg), calibrazione mm/px per stazione, guida d'installazione sul PC di Menoncin.

Adriano added the assegnata:jeeg label 2026-10-15 07:44:45 +00:00

Adriano commented

2026-10-15 07:44:46 +00:00

⚡ jeeg — preso in carico 2026-10-15T07:44:46Z
ramo: lavoro/jeeg · capacità: docker, gpu, systemd

⚡ jeeg — **preso in carico** 2026-10-15T07:44:46Z ramo: `lavoro/jeeg` · capacità: docker, gpu, systemd

Adriano commented

2026-10-15 08:00:40 +00:00

ANALISI 2 (passo 1, claude-opus-5-5) — servizio camera minimo, parte 1b di #72
RIF: gitea:Adriano/TieMeasureFlow#72, ramo lavoro/jeeg-tmf72 (merge di backend 1453b31 e frontend 192d4b5; suite 545 + 342 passed)
PROBLEMA VERIFICATO: vs-gui ascolta solo su 127.0.0.1 per scelta (vendor/visionsuite/packages/vs-gui/src/visionsuite/gui/__main__.py, niente --host, niente auth). Dal container client il loopback dell'host non si raggiunge.
PROVA: vs-gui su jeeg, POST 127.0.0.1:8760/camera/grab {"source":"camera:folder"} → 200 PNG 2464x2056 (BMP Sider); dal container tmflow-client connect 172.17.0.1:8760 → ECONNREFUSED.
DECISIONE: vs-gui non si tocca. Si aggiunge a TMF un servizio camera minimo, solo grab, con lo stesso contratto HTTP di vs-gui, e host configurabile.

FILE: scripts/camera_service.py (nuovo). Avvio: vendor/visionsuite/.venv/bin/python scripts/camera_service.py [--host 127.0.0.1] [--port 8765] [--folder <cartella immagini>] (il venv di VisionSuite ha vs-camera, fastapi, uvicorn; uv sync --all-packages in vendor/visionsuite).

GET /camera/sources → {"sources":[{name,kind,label}]} da visionsuite.camera.sources.list_sources(None, cameras=True, config=cfg).
POST /camera/grab json {source, trigger="continuo", timeout_ms=5000} → PNG (cv2.imencode). Sorgenti aperte una volta e tenute in un dict con lock per nome (come vs-gui server.py:355-390). Errori: 400 source mancante; 404 SourceNotFound; 503 CameraError/CameraGrabError; 504 timeout.
--folder → config {"folder": {"folder": X, "loop": True}} così camera:folder gira in loop sulle immagini.
Default host 127.0.0.1; header del file: cosa fa, uso, dipendenze, ⚠️ nessuna autenticazione: --host diverso da loopback solo su rete isolata. Linux: --host 172.17.0.1 (gateway di docker0, raggiunto via host.docker.internal:host-gateway del compose dev). Windows Docker Desktop: PRESUNTO che host.docker.internal raggiunga 127.0.0.1, da provare sul PC di Menoncin.
Porta 8765, coerente col placeholder host:8765 della schermata Stazioni.
TEST: src/backend/tests? no — test in scripts non esistono; aggiungere src/frontend/flask_app/tests/? no. Test con il venv di VisionSuite: scripts/tests/test_camera_service.py con FastAPI TestClient su una cartella di 2 PNG generati: sources contiene camera:folder; grab → 200 image/png e dimensioni giuste; source mancante → 400; sorgente inesistente → 404.
DOC: README.md, sezione breve «Camera di stazione (demo fiera, #72)»: avvio del servizio, campi camera_url (http://host.docker.internal:8765) e camera_source (camera:<seriale> o camera:folder) nella schermata Stazioni, STATION_SWITCH_ENABLED per due postazioni sullo stesso PC.
NON TOCCARE: vendor/visionsuite, src/backend, src/frontend.

ANALISI 2 (passo 1, claude-opus-5-5) — servizio camera minimo, parte 1b di #72 RIF: gitea:Adriano/TieMeasureFlow#72, ramo lavoro/jeeg-tmf72 (merge di backend 1453b31 e frontend 192d4b5; suite 545 + 342 passed) PROBLEMA VERIFICATO: vs-gui ascolta solo su 127.0.0.1 per scelta (vendor/visionsuite/packages/vs-gui/src/visionsuite/gui/__main__.py, niente --host, niente auth). Dal container client il loopback dell'host non si raggiunge. PROVA: vs-gui su jeeg, `POST 127.0.0.1:8760/camera/grab {"source":"camera:folder"}` → 200 PNG 2464x2056 (BMP Sider); dal container tmflow-client `connect 172.17.0.1:8760` → ECONNREFUSED. DECISIONE: vs-gui non si tocca. Si aggiunge a TMF un servizio camera minimo, solo grab, con lo stesso contratto HTTP di vs-gui, e host configurabile. FILE: scripts/camera_service.py (nuovo). Avvio: `vendor/visionsuite/.venv/bin/python scripts/camera_service.py [--host 127.0.0.1] [--port 8765] [--folder <cartella immagini>]` (il venv di VisionSuite ha vs-camera, fastapi, uvicorn; `uv sync --all-packages` in vendor/visionsuite). - `GET /camera/sources` → {"sources":[{name,kind,label}]} da `visionsuite.camera.sources.list_sources(None, cameras=True, config=cfg)`. - `POST /camera/grab` json {source, trigger="continuo", timeout_ms=5000} → PNG (cv2.imencode). Sorgenti aperte una volta e tenute in un dict con lock per nome (come vs-gui server.py:355-390). Errori: 400 source mancante; 404 SourceNotFound; 503 CameraError/CameraGrabError; 504 timeout. - `--folder` → config {"folder": {"folder": X, "loop": True}} così `camera:folder` gira in loop sulle immagini. - Default host 127.0.0.1; header del file: cosa fa, uso, dipendenze, ⚠️ nessuna autenticazione: --host diverso da loopback solo su rete isolata. Linux: `--host 172.17.0.1` (gateway di docker0, raggiunto via host.docker.internal:host-gateway del compose dev). Windows Docker Desktop: PRESUNTO che host.docker.internal raggiunga 127.0.0.1, da provare sul PC di Menoncin. - Porta 8765, coerente col placeholder `host:8765` della schermata Stazioni. TEST: src/backend/tests? no — test in scripts non esistono; aggiungere `src/frontend/flask_app/tests/`? no. Test con il venv di VisionSuite: `scripts/tests/test_camera_service.py` con FastAPI TestClient su una cartella di 2 PNG generati: sources contiene camera:folder; grab → 200 image/png e dimensioni giuste; source mancante → 400; sorgente inesistente → 404. DOC: README.md, sezione breve «Camera di stazione (demo fiera, #72)»: avvio del servizio, campi camera_url (`http://host.docker.internal:8765`) e camera_source (`camera:<seriale>` o `camera:folder`) nella schermata Stazioni, STATION_SWITCH_ENABLED per due postazioni sullo stesso PC. NON TOCCARE: vendor/visionsuite, src/backend, src/frontend.