Una dashboard reale per osservare un processo virtuale
Una HMI industriale deve aiutare l’operatore a distinguere una misura valida, un comando in attesa e un allarme che richiede intervento. SLX ReelSync applica questo principio a una linea di svolgimento, trascinamento e riavvolgimento: una dashboard Raspberry Pi comunica via Wi-Fi con un simulatore 3D e presenta velocità, tensione del materiale, diametri delle bobine e posizione del ballerino.
Il pannello è un dispositivo embedded; la linea e i sensori sono interamente simulati sul PC. La Raspberry esegue l’applicazione operatore e il servizio di comunicazione, mentre il modello fisico e il controllore restano nel simulatore. Questa separazione permette di studiare interazione, diagnostica e comportamento della rete senza richiedere una macchina reale.
L’approfondimento Controllo tensione del nastro: simulazione guasti con SLX ReelSync sviluppa i calcoli del processo, gli errori dei sensori e i criteri di prova.
Interfaccia touch: processo, riferimenti e stato del collegamento
La GUI nativa usa LVGL 9.5 e un layout progettato per 1024 × 600 pixel. La panoramica raccoglie le grandezze principali e un sinottico animato del percorso del materiale. Il movimento dei rulli e i riferimenti visivi sul nastro rendono percepibili marcia, arresto e trasferimento tra le bobine.
Regolazione, grafici, eventi e connessione hanno funzioni distinte. L’inserimento di un valore impiega tastierino e tastiera a schermo; le finestre possono essere chiuse e gli esiti operativi non devono trasformarsi in una successione di notifiche invasive. Stato del Wi-Fi, collegamento al simulatore e autorità di comando sono informazioni separate.
Il profilo Operatore mantiene in primo piano supervisione e comandi ordinari. Le funzioni di iniezione delle anomalie appartengono al laboratorio di prova. Il confine rende il pannello più vicino all’impiego di una HMI di macchina, pur conservando la possibilità di eseguire dimostrazioni e diagnosi.
Il PC calcola, il pannello presenta e richiede
Processo e controllo
Il core C++ del PC integra il modello e applica limiti, stati e comandi ammessi. La scena 3D, i grafici e l’HMI leggono lo stesso stato.
Trasporto applicativo
Il servizio gestisce identità, sessioni, telemetria, richieste e risultati. Sulla Raspberry dialoga con la GUI attraverso un socket Unix privato.
HMI nativa
LVGL presenta i dati e invia richieste. La dashboard non esegue una seconda copia indipendente del modello fisico.
Osservabilità
Identificativo della prova, sequenze, eventi e qualità dei sensori collegano un’azione all’effetto osservato.
Il disaccoppiamento evita che una ricerca Wi-Fi o un’attesa di rete blocchino il rendering. Il servizio raccoglie e valida i messaggi; la GUI aggiorna i propri oggetti nel contesto dell’interfaccia. La progettazione riguarda quindi sia il disegno delle pagine sia la gestione di tempi, code e transizioni.
Linux embedded su una piattaforma da 512 MB
La piattaforma di riferimento è Raspberry Pi 3 Model A+, con processore Cortex-A53 e 512 MB di RAM. Il collegamento del banco utilizza il Wi-Fi integrato. Buildroot assembla kernel, filesystem e servizi del sistema embedded; l’interfaccia non richiede un browser o un desktop generalista.
Il sistema separa filesystem di base e dati persistenti. Rete, identità e configurazioni devono sopravvivere al riavvio senza trasformare il supporto di avvio in un’area di lavoro indistinta. Le credenziali Wi-Fi possono essere inserite dal touch oppure importate attraverso il file di configurazione previsto sulla SD; dopo un’importazione riuscita il file compilato viene rimosso.
Dimensionamento dei buffer grafici, aggiornamento selettivo degli oggetti e operazioni di rete asincrone sono scelte rilevanti su questa classe di hardware. Il dimostratore non attribuisce al pannello garanzie di tempo reale duro né funzioni di sicurezza della macchina.
Wi-Fi, associazione e autorità di comando
La rete locale trasporta WebSocket su TLS 1.3. L’associazione confronta l’impronta dell’identità del PC e usa un codice temporaneo, con conferma del dispositivo dal simulatore. Le identità sono generate per l’installazione: l’immagine non contiene chiavi private condivise da tutti i pannelli.
Una connessione autenticata nasce in sola lettura. Il pannello richiede il controllo e il PC lo assegna a una connessione; un intervento locale può revocarlo. Un comando include il contesto della prova e un identificativo, riceve un esito correlato e non viene semplicemente considerato eseguito perché è stato trasmesso.
Con dati non aggiornati i comandi remoti vengono sospesi. La riconnessione risincronizza lo stato e riparte in sola lettura, senza reinviare automaticamente richieste precedenti. Questo comportamento riguarda la coerenza della supervisione: il canale Wi-Fi non rappresenta una funzione di arresto di emergenza certificata.
Il ciclo di vita di un comando
| Passaggio | Verifica applicativa | Effetto sulla HMI |
|---|---|---|
| Associazione | Identità, impronta e codice temporaneo | Il dispositivo viene riconosciuto; la sola lettura resta distinta dal controllo |
| Richiesta di controllo | Consenso del PC e autorità assegnata a una connessione | I comandi diventano disponibili nello stato ammesso |
| Invio | Contesto della prova, identificativo e freschezza del trasporto | La richiesta attende un risultato correlato |
| Applicazione | Limiti, stato e validazione del core | Il pannello mostra il riferimento e lo stato restituiti dal processo |
| Riconnessione | Nuovo snapshot e nuova autorità | Nessun reinvio automatico delle operazioni precedenti |
La scansione delle reti e l’autenticazione Wi-Fi appartengono al sistema operativo; la connessione TLS identifica invece il partner applicativo. L’IPC locale fra servizio e HMI usa un socket Unix con accesso ristretto. Il contratto di rete è specifico del banco ReelSync e non viene presentato come un protocollo universale di campo.
Allarmi contestuali e ripristino consapevole
Gli allarmi distinguono condizione attiva, memoria di una condizione rientrata e causa introdotta per la prova. Colore, simbolo e testo accompagnano la segnalazione sia sul pannello sia nel simulatore. La scena 3D evidenzia il componente interessato: encoder, cella di carico, ballerino, azionamenti o percorso del materiale.
La conferma di un allarme non elimina una causa ancora attiva. Il ripristino richiede le condizioni ammesse dal core; una rottura del materiale richiede una nuova prova. Il conto alla rovescia permette di predisporre un’anomalia, tornare alla panoramica e osservarne l’evoluzione sui due dispositivi.
Bobine, tensione e sei profili di materiale
La linea virtuale comprende due zone elastiche, bobine a raggio variabile, traino e ballerino. Il catalogo offre PET, PE-LD, BOPP, PA6 condizionato e due profili elastici. Proprietà e dimensioni della ricetta cambiano la risposta: la tensione in newton non descrive da sola la sollecitazione del materiale, che dipende anche dalla sua sezione.
Le prove includono perdita o scala errata dell’encoder, bias o blocco della cella, attrito, riduzione della coppia disponibile, perdita di forza dell’attuatore, ritardo dei sensori e rottura. Una causa introdotta può generare più conseguenze; non coincide automaticamente con un allarme già diagnosticato.
Prove ripetibili e distribuzione disponibile
Le verifiche software riguardano modello, conservazione del materiale, scenari, replay, validazione dei comandi, trasporto TLS e binari ARM. La ricompilazione del pacchetto pubblico è verificata senza sorgenti del core. Le prove software e in emulazione non sostituiscono il collaudo della specifica combinazione di scheda, display, touch e rete.
Il pacchetto Windows 1.5.0 contiene l’EXE e il materiale consentito per la valutazione. La dashboard embedded è un componente distinto; l’immagine SD non fa parte del download Windows. La linea è un modello dimostrativo, non calibrato su un impianto reale.
Dalla dashboard dimostrativa alla HMI di prodotto
Il progetto rende concrete competenze di sviluppo firmware, Linux embedded, dashboard industriali e integrazione tra applicazione operatore e servizi di controllo. Su un impianto reale il lavoro parte da I/O, azionamenti, protocollo disponibile, frequenze di aggiornamento e condizioni di accettazione.
Integrazioni con PLC, adattatori OPC UA o Modbus TCP, diagnostica specifica, acquisizione di misure reali e strategie di controllo su misura sono sviluppi su progetto. Non sono presentati come funzioni già implementate nel collegamento ReelSync.
Una HMI industriale deve rendere verificabile il processo
Per valutare una dashboard embedded o un banco di simulazione, una richiesta tecnica a Silicon LogiX può indicare hardware, segnali, protocolli e anomalie da riprodurre. Questi dati permettono di definire un percorso di sviluppo e collaudo aderente al prodotto.
Domande tecniche sul progetto
Serve una linea industriale reale per provare ReelSync?
No. Bobine, materiale, azionamenti e sensori sono simulati sul PC. La dashboard embedded comunica con quel processo virtuale e consente di studiare interfaccia, comandi e diagnostica.
La Raspberry esegue il controllo del processo?
In ReelSync il modello e il controllore sono sul PC. Sulla Raspberry sono eseguiti HMI e servizio di collegamento. L’eventuale trasferimento di logiche su un controllore dedicato richiede un’architettura e verifiche specifiche.
Il collegamento usa Modbus TCP oppure OPC UA?
La versione descritta usa WebSocket su TLS e un contratto applicativo ReelSync. Adattatori Modbus TCP, OPC UA o verso PLC possono rientrare in uno sviluppo su misura, ma non sono inclusi nel collegamento dimostrativo.
