Un protocollo per la generazione automatica di interfacce web per applicazioni LabVIEW tramite il Remote Interoperability Protocol

Sommario

Questo studio convalida la generazione automatica di interfacce utente Web basata su un protocollo di interoperabilità remota (RIP) con due sistemi LabVIEW distinti — un modello di ventola e un modello di controllo della posizione di un motore a corrente continua — e fornisce una procedura riproducibile per la costruzione, registrazione, distribuzione e verifica di entrambi gli esempi.

Abstract

Le piattaforme sperimentali remote consentono di accedere a modelli di simulazione locali o dispositivi fisici attraverso una rete, ma le tradizionali interfacce Web richiedono solitamente una pagina dedicata, un layout di controllo e una logica di comunicazione dati specifica per ciascun esperimento, aumentando così i costi di sviluppo. Questo lavoro convalida un flusso di lavoro consolidato per la generazione automatica di un'interfaccia utente Web (UI) a partire da strumenti virtuali LabVIEW (VIs) mediante il protocollo di interoperabilità remota (RIP) e fornisce un protocollo riproducibile per la sua implementazione. Il flusso di lavoro costruisce VIs LabVIEW che definiscono controlli di input e indicatori di output nel pannello frontale, registra ciascun VI nella configurazione del server RIP, legge i metadati delle variabili risultanti e genera i corrispondenti controlli Web e visualizzazioni di output. Caddy viene utilizzato come proxy inverso per unificare il percorso dei file statici del frontend e il percorso delle richieste all'interfaccia di programmazione applicativa (API) RIP. Il flusso di lavoro viene valutato su due sistemi distinti: un modello di velocità di un ventilatore e un modello di controllo di posizione con regolatore proporzionale-integrale-derivativo (PID) per un motore in corrente continua (DC). In entrambi i casi, la pagina Web identifica le variabili esposte, scrive gli input dell'utente nel backend LabVIEW, legge gli output del modello e genera l'interfaccia a partire dai metadati RIP. Questi risultati convalidano lo stesso processo di generazione automatica dell'interfaccia utente su due sistemi dinamici differenti e documentano i passaggi necessari per riprodurlo.

Introduzione

Con lo sviluppo di esperimenti a distanza, didattica online e tecnologie dell'Internet delle Cose, fornire accesso web a modelli di simulazione locali o dispositivi sperimentali è diventata una direzione importante nello sviluppo delle piattaforme sperimentali^1,2,3,4. Lavori recenti hanno ulteriormente integrato laboratori dotati di tecnologia IoT con metodologie di apprendimento basate su progetti e accesso locale o remoto, dimostrando il continuo sviluppo di piattaforme sperimentali flessibili e interconnesse nell'ambito della formazione ingegneristica⁵. Per gli esperimenti sui sistemi di controllo, gli utenti devono solitamente regolare i parametri di ingresso tramite un browser e osservare gli stati di uscita in tempo reale^6,7. I metodi convenzionali richiedono tipicamente una pagina web dedicata, logica di associazione del controllo e interfaccia di comunicazione dati per ciascun oggetto sperimentale^8,9. Quando le variabili nel modello di back-end cambiano, spesso è necessario modificare di conseguenza la pagina front-end, generando un notevole lavoro di sviluppo ripetitivo e limitando l'espansione rapida della piattaforma sperimentale.

Il protocollo di interoperabilità remota (RIP) fornisce un livello middleware tra modelli sperimentali back-end e interfacce Web front-end^10,11. Nell'approccio basato su RIP per la generazione automatica di interfacce utente descritto in lavori precedenti, il server RIP fornisce metadati per ogni esperimento, inclusi nomi delle variabili, attributi di input/output, tipi di dati, valori minimi, valori massimi, precisione, descrizioni e metodi di lettura/scrittura disponibili¹¹. Un client Web può quindi utilizzare questi metadati per creare gli elementi HTML corrispondenti, come etichette, campi di input numerici, cursori, controlli booleani e visualizzazioni di output, durante il caricamento o l'aggiornamento della pagina¹¹. Il presente protocollo non reimplementa né ridefinisce la specifica RIP. Al contrario, utilizza il servizio RIP open source esistente e la logica di generazione dell'interfaccia utente da metadati a HTML basata su RIP come fondamento per la comunicazione e la generazione dell'interfaccia, concentrandosi sulla costruzione, registrazione, distribuzione tramite proxy e verifica riproducibili di due esempi di VI LabVIEW.

Rispetto allo sviluppo tradizionale di interfacce web personalizzate, la generazione automatica di interfacce utente basata su RIP riduce la necessità di implementare layout di controllo, logica di associazione delle variabili e funzioni di comunicazione di base quando più esperimenti LabVIEW espongono variabili scalari di ingresso e uscita simili^8,9,10,11. Una volta che un nuovo VI viene registrato e le sue variabili sono disponibili per il server RIP, la stessa logica di lettura dei metadati e di generazione dei controlli può essere riutilizzata per costruire l'interfaccia web di base^10,11. Questa caratteristica è utile per il rapido deployment, le dimostrazioni didattiche e le piattaforme di laboratorio remoto che richiedono un accesso coerente a diversi esperimenti simili^3,8,9. Tuttavia, l'interfaccia generata automaticamente presenta anche alcune limitazioni. Non riesce a inferire completamente le relazioni fisiche tra le variabili, a determinare automaticamente le associazioni per i grafici o a progettare visualizzazioni e interazioni specifiche per il dominio in materia di sicurezza¹¹. Pertanto, lo sviluppo manuale dell'interfaccia web rimane preferibile quando un esperimento richiede grafiche altamente personalizzate, flussi di lavoro utente complessi, visualizzazioni avanzate, interblocchi hardware per la sicurezza o l'arbitraggio della scrittura tra più utenti.

Il flusso di lavoro complessivo del protocollo è riassunto in Figura 1. In questo flusso di lavoro, un VI LabVIEW definisce innanzitutto i controlli di input richiesti e gli indicatori di output nel pannello frontale. Il VI viene quindi registrato nella configurazione del server RIP specificando il nome dell'esperimento e il percorso del VI. Dopo la registrazione, il server RIP legge i metadati dell'esperimento selezionato e fornisce accesso in lettura e scrittura alle variabili disponibili. La pagina Web XHTML utilizza i metadati restituiti per generare automaticamente i controlli di input e le visualizzazioni di output corrispondenti, mentre Caddy fornisce un percorso di accesso unificato per la pagina Web statica e per le rotte di comunicazione RIP. I modelli di ventola e di motore a corrente continua sono utilizzati in questo studio come due implementazioni dello stesso flusso di lavoro. Per altri esperimenti LabVIEW che forniscono variabili compatibili di tipo scalare, numerico e booleano, gli sviluppatori possono seguire lo stesso flusso di lavoro di creazione-registrazione-distribuzione-verifica per creare un'interfaccia Web generata automaticamente, aggiungendo al contempo visualizzazioni specifiche per l'esperimento, logiche di sicurezza o gestione complessa dei dati quando necessario.

Questo articolo non propone una nuova architettura RIP né estende la gamma di tipi di dati già supportati da RIP. Piuttosto, utilizza RIP come meccanismo consolidato di comunicazione e di generazione dell'interfaccia utente basato su metadati, concentrandosi sulla validazione dello stesso processo con due diversi sistemi LabVIEW, documentando al contempo un protocollo di implementazione riproducibile. Lavori precedenti hanno presentato un metodo di base per la generazione automatica di interfacce web basata sui metadati RIP, utilizzando un esperimento online su un motore servo come caso di studio¹¹. Architetture di laboratori remoti abilitati al web, che combinano interfacce interattive con software ingegneristici e LabVIEW, sono state inoltre riportate in studi precedenti^9,12. Tuttavia, durante la riproduzione pratica, alcuni modelli LabVIEW del caso originale sono risultati influenzati dalla compatibilità tra versioni del software e moduli, rendendoli difficili da utilizzare direttamente in un ambiente più recente. Il presente lavoro, pertanto, ricostruisce due VI back-end compatibili — un modello di ventola e un modello di controllo di posizione proporzionale-integrale-derivativo (PID) per un motore in corrente continua (DC) — e applica lo stesso processo di generazione dell'interfaccia utente guidato dai metadati a entrambi. Il contributo consiste nella validazione incrociata del flusso di lavoro RIP consolidato e in un protocollo dettagliato per riprodurre il processo, piuttosto che in un'estensione della generalità di RIP.

Gli utenti previsti per questo protocollo sono ricercatori, insegnanti e sviluppatori di laboratorio che utilizzano già VI LabVIEW e necessitano di esporre modelli di simulazione o sistemi sperimentali a basso rischio attraverso un browser Web, senza dover implementare autonomamente un'interfaccia personalizzata completa per ciascun modello. Il protocollo è particolarmente adatto a esperimenti che utilizzano variabili numeriche e booleane standard, regolazione di parametri e monitoraggio in tempo reale dello stato^10,11. È meno adatto come soluzione autonoma per esperimenti che richiedono strutture dati complesse, visualizzazioni specializzate, interblocchi di sicurezza hardware rigorosi o arbitrato della scrittura multiutente¹¹. L'obiettivo di questo lavoro è validare la generazione automatica di interfacce utente Web basate su RIP con due diversi sistemi LabVIEW e fornire un protocollo completo e riproducibile, che va dalla costruzione del VI sul back-end all'interazione basata su browser. Il protocollo comprende la definizione delle variabili di ingresso e uscita, la registrazione dell'esperimento nel server RIP, la generazione dell'interfaccia utente basata su metadati, il deployment del proxy Caddy e la verifica remota di lettura/scrittura. L'applicazione dello stesso flusso di lavoro ai modelli del ventilatore e del motore in corrente continua dimostra che il processo stabilito può essere riprodotto senza dover riscrivere manualmente un'interfaccia Web completa per ogni esempio^9,10,11.

Protocollo

Completare i seguenti passaggi per creare, registrare, distribuire e verificare due esperimenti LabVIEW accessibili tramite RIP seguendo il flusso di lavoro riassunto in Figura 1. Tutti gli strumenti e le piattaforme utilizzati in questo studio sono elencati nella Tabella dei materiali.

1. Costruire e implementare l'esperimento con il modello di ventilatore

1. Costruire il VI del modello del ventilatore.
   1. Aprire LabVIEW, creare un nuovo VI e salvare il file come fengshan.vi. Salvare il VI in una qualsiasi directory accessibile dal processo RIP WebService. La cartella Private viene utilizzata solo come esempio di directory e non è codificata in modo fisso in RIP. Inserire il percorso effettivo del VI selezionato durante la registrazione dell'esperimento RIP.
   2. Sul Pannello Frontale, aggiungere i controlli di input per il modello del ventilatore. In questo esempio, denominare i controlli di input Enable, PWM, Load, Tau, KMaxRPM e Disturbance. Impostare Enable come controllo Booleano e impostare PWM, Load, Tau, KMaxRPM e Disturbance come controlli numerici a virgola mobile a doppia precisione (DBL). Vedere Tabella Supplementare 1 per il significato fisico e il ruolo nel modello delle variabili del ventilatore.
   3. Aggiungere gli indicatori di output per il modello del ventilatore. In questo esempio, denominare gli indicatori di output SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW. Impostare tutti gli indicatori di output come indicatori DBL.
      ​NOTA: Tabella 1 descrive il significato fisico e il ruolo nel modello di queste variabili di output. Il pannello frontale completo del ventilatore è mostrato in Figura 2. I nomi delle variabili, i range e gli incrementi mostrati in Tabella 1 descrivono i due esempi implementati in questo protocollo. Non si tratta di requisiti codificati in modo fisso in RIP. Per altri esperimenti LabVIEW, gli sviluppatori possono definire nomi di variabili e proprietà numeriche diversi per il Pannello Frontale. Il server RIP legge i nomi effettivi delle variabili, i tipi di dati, gli attributi di input/output e le proprietà numeriche disponibili dai metadati del VI, e la pagina Web genera i controlli e le visualizzazioni corrispondenti a partire dai metadati restituiti.
   4. Aggiungere un ciclo While nel Diagramma a Blocchi. Aggiungere due shift register per memorizzare speed_prev e time_prev e inizializzare entrambi i valori a 0.
   5. Aggiungere un nodo formula all'interno del ciclo While. Collegare Enable, PWM, Load, Tau, KMaxRPM, Disturbance, speed_prev e time_prev ai terminali di ingresso sinistri del nodo formula e impostare SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW e time_next come terminali di uscita destri.
   6. Costruire la logica di controllo di Enable all'esterno del nodo formula. Utilizzare Enable come segnale di selezione in modo che u = PWM quando Enable è True e u = 0 quando Enable è False.
   7. Inserire il codice del modello del ventilatore nel nodo formula. Utilizzare questo codice per calcolare la velocità a regime, la velocità effettiva, la velocità normalizzata, la corrente, la potenza e il tempo di esecuzione; vedere il File di Codice Supplementare 1 per il codice completo.
   8. Collegare l'uscita speed_next del nodo formula all'indicatore SpeedRPM e collegare speed_next nuovamente allo shift register destro per speed_prev. Collegare SteadyRPM all'indicatore SteadyRPM.
   9. Collegare time_next all'indicatore TimeS e collegare time_next nuovamente allo shift register destro per time_prev. Collegare SpeedNorm, CurrentA e PowerW ai rispettivi indicatori di output.
   10. Aggiungere una funzione Wait all'interno del ciclo While e impostare il tempo di attesa a 50 ms. Aggiungere un pulsante locale Stop e collegarlo al terminale condizionale del ciclo While.
   11. Salvare fengshan.vi. Il diagramma a blocchi completo del ventilatore è mostrato in Figura 3.
       PUNTO DI PAUSA: Dopo aver salvato il VI del ventilatore completato, il flusso di lavoro può essere interrotto. Riprendere successivamente riaprendo il VI salvato e verificando che tutti i controlli, gli indicatori del Pannello Frontale e i collegamenti del Diagramma a Blocchi siano ancora presenti.
2. Registrare l'esperimento del ventilatore nel server RIP.
   1. Aprire RIPWebService.lvproj nell'Esplora Progetti di LabVIEW.
      .
   2. Aprire Configuration.vi dall'albero del progetto e individuare la tabella di configurazione dell'esperimento.
   3. Aggiungere una nuova riga per l'esperimento. Impostare Nome su fan. Impostare il percorso completo del file fengshan.vi salvato. I campi di registrazione per l'esperimento del ventilatore sono mostrati in Figura 4.
   4. Compilare i restanti campi di configurazione. Impostare Autori sull'autore dell'esperimento, Parole Chiave su Fan, Descrizione su modello di velocità del ventilatore e Frequenza di Campionamento su 200.
   5. Nel menu di LabVIEW, selezionare Modifica > Rendi Valori Attuali Predefiniti. Salvare Configuration.vi.
   6. Riavviare RIP WebService e verificare che l'esperimento del ventilatore rimanga elencato nell'interfaccia di Configurazione dopo il riavvio.
      NOTA: Il nome dell'esperimento distingue tra maiuscole e minuscole. Il valore fan nella Configurazione RIP deve corrispondere esattamente all'ID dell'esperimento utilizzato nel file XHTML front-end. Per distribuire un altro VI LabVIEW con la stessa logica di generazione automatica dell'interfaccia utente, aggiungere una nuova voce di esperimento nella Configurazione RIP, impostare un nuovo valore Nome e impostare Percorso sul file VI corrispondente. Quindi utilizzare lo stesso valore Nome come ID dell'esperimento nel file XHTML. La pagina front-end non deve essere riscritta per ogni variabile.
      ​PUNTO DI PAUSA: Dopo aver salvato Configuration.vi e reso i valori attuali predefiniti, il flusso di lavoro può essere interrotto. Riprendere successivamente riavviando RIP WebService e verificando che l'esperimento del ventilatore sia ancora registrato.
3. Preparare la pagina front-end per l'esperimento del ventilatore.
   1. Posizionare Fan_Automatic_UI.xhtml nella directory Client utilizzata come directory radice front-end.
   2. Aprire Fan_Automatic_UI.xhtml con un editor di testo.
   3. Individuare la variabile ID esperimento nella sezione script e impostarla su fan.
      NOTA: Questo valore deve corrispondere esattamente al campo Nome dell'esperimento del ventilatore nella Configurazione RIP. Le impostazioni dell'ID esperimento e la logica condivisa di generazione dell'interfaccia utente basata sui metadati per i file XHTML front-end sono mostrate in Figura 5.
   4. Verificare che la pagina ottenga l'origine di accesso corrente tramite window.location.origin, richieda i metadati dell'esperimento tramite rip.info() e passi i metadati restituiti a autobuildUI().
      NOTA: La pagina non deve codificare manualmente i nomi delle variabili del ventilatore, i range o gli incrementi. Invece, le variabili scrivibili vengono generate da meta.writables.list, le variabili leggibili da meta.readables.list e gli attributi numerici come min, max e step vengono ottenuti dai metadati restituiti dal server RIP.
   5. Salvare Fan_Automatic_UI.xhtml.
      ​NOTA: Per utilizzare la stessa logica di generazione front-end per un altro VI LabVIEW, impostare un nuovo ID esperimento nel file XHTML e registrare il corrispondente Nome esperimento e Percorso VI nella Configurazione RIP. I controlli Web e le visualizzazioni di output vengono generati in base ai metadati restituiti dall'esperimento selezionato.
4. Configurare il percorso di accesso di Caddy per l'esperimento del ventilatore.
   1. Aprire il Caddyfile con un editor di testo.
   2. Impostare la directory radice front-end sulla directory Client che contiene Fan_Automatic_UI.xhtml.
   3. Selezionare una porta locale non utilizzata affinché Caddy fornisca l'accesso tramite browser alla pagina Web e ai percorsi RIP. In questo protocollo, la porta 8090 viene utilizzata come esempio di porta di accesso proxy.
      NOTA: La porta 8090 non è richiesta da RIP o Caddy. Se la porta 8090 è occupata, sostituirla con un'altra porta locale libera e utilizzare la stessa porta nell'indirizzo del browser.
   4. Aggiungere un percorso che riscriva /fan in Fan_Automatic_UI.xhtml.
   5. Individuare la porta del servizio RIP WebService configurata in LabVIEW. In questo protocollo, http://localhost:8001 viene utilizzato come indirizzo del servizio RIP WebService.
      NOTA: La porta 8001 è la porta back-end di LabVIEW/RIP WebService utilizzata nell'ambiente di test. Può essere modificata nella configurazione di LabVIEW/RIP WebService. Se viene utilizzata una porta diversa, sostituire http://localhost:8001 nel Caddyfile con l'indirizzo corrispondente del servizio RIP WebService.
   6. Aggiungere una regola di proxy inverso che invii le richieste /RIP/SSE* all'indirizzo del servizio RIP WebService, ad esempio http://localhost:8001.
   7. Aggiungere una regola di proxy inverso che invii le richieste /RIP* all'indirizzo del servizio RIP WebService, ad esempio http://localhost:8001. La configurazione del Caddyfile è mostrata in Figura 6.
   8. Aprire il Prompt dei comandi su Windows. Passare alla directory locale di download o installazione di Caddy inserendo il seguente comando:
      cd /d D:\caddy
      NOTA: In questo protocollo, D:\caddy è il percorso locale di download o installazione di Caddy utilizzato nell'ambiente di test. Se Caddy è memorizzato in un'altra directory, sostituire D:\caddy con il percorso locale corrispondente.
   9. Avviare Caddy con il Caddyfile specificato inserendo il seguente comando:
      caddy.exe run --config Caddyfile
   10. Verificare che Caddy si avvii senza segnalare errori di configurazione. Aprire http://localhost:8090/fan in un browser Web e verificare che l'interfaccia utente Web del ventilatore venga generata, come mostrato in Figura 7.
       ​NOTA: Se il browser restituisce un errore 502, verificare che RIP WebService sia in esecuzione, che la porta di RIP WebService in LabVIEW corrisponda all'indirizzo del proxy inverso nel Caddyfile e che la porta di accesso Caddy selezionata non sia occupata.
5. Verificare i risultati operativi dell'esperimento del ventilatore.
   1. Verificare che la pagina front-end generi automaticamente i controlli di input Enable, PWM, Load, Tau, KMaxRPM e Disturbance.
   2. Verificare che la pagina front-end visualizzi le variabili di output SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW.
   3. Regolare PWM e osservare se SpeedRPM aumenta all'aumentare di PWM e diminuisce al diminuire di PWM.
   4. Regolare il carico e osservare se SteadyRPM e SpeedRPM diminuiscono all'aumentare del carico.
   5. Regolare la perturbazione e osservare se SpeedRPM, CurrentA e PowerW cambiano in risposta all'ingresso di perturbazione.
   6. Verificare che TimeS continui ad aumentare, confermando che il VI del ventilatore back-end sia in esecuzione continua.

2. Costruire e implementare l'esperimento di controllo di posizione PID per motore in corrente continua

1. Costruire il modello VI di controllo di posizione PID del motore in corrente continua.
   1. Aprire LabVIEW, creare un nuovo VI e salvare il file come Motor.vi. Salvare il VI in una qualsiasi directory accessibile dal processo RIP WebService.
      NOTA: La cartella Private viene utilizzata solo come esempio di directory e non è codificata in modo fisso in RIP. Inserire il percorso effettivo del VI selezionato durante la registrazione dell'esperimento in RIP.
   2. Sul Pannello Frontale, aggiungere i controlli di input per il modello di controllo di posizione PID del motore in corrente continua. In questo esempio, denominare i controlli di input Setpoint, Kc, Ti, Td, Disturbance e Reset control. Impostare Setpoint, Kc, Ti, Td e Disturbance come controlli numerici DBL e impostare Reset control come controllo Booleano.
      NOTA: Tabella 1 descrive il significato fisico, il ruolo nel modello e l'intervallo raccomandato delle variabili utilizzate in questo esempio.
   3. Aggiungere gli indicatori di uscita per il modello di controllo di posizione PID del motore in corrente continua. In questo esempio, denominare gli indicatori di uscita Position, Voltage, Time e Measured angular velocity. Impostare tutti gli indicatori di uscita come indicatori DBL. Tabella 1 descrive il significato fisico e il ruolo nel modello di queste variabili di uscita. Il Pannello Frontale completato per il motore è mostrato in Figura 8.
      NOTA: I nomi e gli intervalli delle variabili elencati nella Tabella 1 descrivono i due esempi implementati in questo protocollo. Non si tratta di requisiti fissi per il flusso di lavoro di generazione automatica dell'interfaccia utente basato su RIP. Quando viene utilizzato un altro VI LabVIEW, RIP legge i nomi effettivi delle variabili, i tipi di dati, gli attributi di input/output e le proprietà numeriche disponibili dai metadati del VI. Pertanto, la logica di generazione del frontend non deve codificare in modo fisso i nomi delle variabili, i valori massimi, i valori minimi o gli incrementi per ogni esperimento.
   4. Aggiungere un ciclo While al Diagramma a Blocchi. Aggiungere sei registri di scorrimento (Shift Registers) per memorizzare theta, omega, im, e_prev, integ e time, e inizializzare tutti e sei i valori a 0.
   5. Aggiungere un Nodo Formula all'interno del ciclo While. Secondo lo schema del modello di controllo di posizione PID del motore in corrente continua mostrato in Figura 9, utilizzare questo Nodo Formula come modulo di calcolo principale per il calcolo dell'errore, il controllo PID, il limitatore di tensione, il modello elettrico, il modello meccanico e l'aggiornamento della posizione.
      NOTA: I parametri interni del motore utilizzati in questo modello, come R, L, J, b, Kt, Ke e Vmax, sono parametri normalizzati per scopi didattici e non parametri calibrati di un motore fisico specifico. Sono stati scelti per produrre una risposta simulata stabile e osservabile con il passo temporale e il limite di tensione selezionati, in modo che gli effetti di Setpoint, Kc, Ti, Td e Disturbance possano essere chiaramente dimostrati durante il funzionamento via Web.
   6. Impostare sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, disturbance, reset e dt come terminali di ingresso del Nodo Formula. Impostare theta_next, omega_next, im_next, e_next, integ_next e voltage come terminali di uscita del Nodo Formula.
   7. Collegare il controllo Setpoint al terminale di ingresso sp del Nodo Formula. Collegare Kc, Ti, Td e Disturbance rispettivamente ai terminali di ingresso Kc, Ti, Td e disturbance del Nodo Formula.
   8. Convertire il segnale Booleano del controllo Reset in un segnale numerico e collegarlo al terminale di ingresso reset del Nodo Formula. Eseguire il reset dello stato quando reset è diverso da 0 ed eseguire il controllo PID e l'aggiornamento dello stato del motore quando reset è uguale a 0.
   9. Aggiungere la costante numerica dt e impostarne il valore a 0,001 s. Collegare dt al terminale di ingresso dt del Nodo Formula e utilizzarla per l'aggiornamento del tempo.
   10. Impostare i parametri del modello interno del motore in corrente continua all'interno del Nodo Formula. Vedere Tabella Supplementare 2 per il significato fisico e il ruolo nel modello delle variabili del motore.
   11. Inserire il codice di controllo di posizione PID del motore in corrente continua nel Nodo Formula. Utilizzare questo codice per implementare la logica di reset, il calcolo dell'errore, il calcolo del termine integrale, il calcolo del termine derivativo, il controllo PID, il limitatore di tensione, l'aggiornamento della corrente, l'aggiornamento della velocità angolare e l'aggiornamento della posizione; vedere i file di codice supplementari per il codice completo.
   12. Collegare theta_next all'indicatore Position e collegare nuovamente theta_next al registro di scorrimento destro per theta. Collegare omega_next all'indicatore Measured angular velocity e collegare nuovamente omega_next al registro di scorrimento destro per omega.
   13. Collegare la tensione all'indicatore Voltage. Collegare im_next, e_next e integ_next nuovamente ai registri di scorrimento destri per im, e_prev e integ, rispettivamente.
   14. Utilizzare una funzione Add al di fuori del Nodo Formula per calcolare time_next = time + dt. Collegare time_next all'indicatore Time e collegare time_next nuovamente al registro di scorrimento destro per time.
   15. Aggiungere una funzione Wait all'interno del ciclo While e impostare il tempo di attesa a 1 ms. Aggiungere un pulsante Stop e collegarlo al terminale condizionale del ciclo While.
   16. Salvare Motor.vi. Il Diagramma a Blocchi del motore completato è mostrato in Figura 10.
       PUNTO DI PAUSA: Dopo aver salvato il VI del motore completato, il flusso di lavoro può essere interrotto. Riprendere successivamente riaprendo il VI salvato e verificando che tutti i controlli, gli indicatori del Pannello Frontale e i collegamenti del Diagramma a Blocchi siano ancora presenti.
2. Registrare l'esperimento del motore nel server RIP.
   1. Aprire RIPWebService.lvproj nell'Esplora Progetti di LabVIEW.
   2. Aprire Configuration.vi dall'albero del progetto e individuare la tabella di configurazione dell'esperimento.
   3. Aggiungere una nuova riga per l'esperimento. Impostare Name su Motor. Impostare Path sul percorso completo del file Motor.vi salvato. I campi di registrazione dell'esperimento del motore sono mostrati in Figura 11.
   4. Compilare i restanti campi di configurazione. Impostare Authors sull'autore dell'esperimento, Keywords su Motor, Description su DC motor position control model e Sampling Freq su 200.
   5. Nel menu di LabVIEW, selezionare Edit > Make Current Values Default. Salvare Configuration.vi.
   6. Riavviare RIP WebService e verificare che l'esperimento Motor rimanga elencato nell'interfaccia di configurazione dopo il riavvio.
      NOTA: Il nome dell'esperimento distingue tra maiuscole e minuscole. Il valore Motor in RIP Configuration deve corrispondere esattamente all'ID dell'esperimento utilizzato in Motor_Automatic_UI.xhtml. Per distribuire un altro VI LabVIEW con la stessa logica di generazione automatica dell'interfaccia utente, aggiungere una nuova voce di esperimento in RIP Configuration, impostare un nuovo valore Name e impostare Path sul file VI corrispondente. Quindi utilizzare lo stesso valore Name come ID dell'esperimento nel file XHTML. La pagina frontend non deve essere riscritta per ogni variabile.
      ​PUNTO DI PAUSA: Dopo aver salvato Configuration.vi e impostato i valori correnti come predefiniti, il flusso di lavoro può essere interrotto. Riprendere successivamente riavviando RIP WebService e verificando che l'esperimento Motor sia ancora registrato.
3. Preparare la pagina frontend per l'esperimento del motore.
   1. Posizionare Motor_Automatic_UI.xhtml nella directory Client utilizzata come directory radice del frontend.
   2. Aprire Motor_Automatic_UI.xhtml con un editor di testo.
   3. Individuare la variabile ID dell'esperimento nella sezione script e impostarla su Motor. Questo valore deve corrispondere esattamente al campo Name dell'esperimento del motore in RIP Configuration. La pagina frontend del motore utilizza la stessa logica di generazione dell'interfaccia utente basata sui metadati mostrata in Figura 5; solo l'ID dell'esperimento viene modificato per corrispondere alla voce Motor in RIP Configuration.
   4. Verificare che la pagina contenga la logica di lettura dei metadati RIP, la logica di generazione dei controlli HTML, la funzione di scrittura RIP e la funzione di aggiornamento dell'uscita.
      NOTA: La pagina non deve codificare manualmente in modo fisso i nomi, gli intervalli o gli incrementi delle variabili del motore. Queste proprietà sono ottenute dai metadati restituiti dal server RIP, seguendo il meccanismo di generazione da metadati a HTML basato su RIP descritto in precedenza¹¹.
   5. Salvare Motor_Automatic_UI.xhtml.
      ​NOTA: Per utilizzare la stessa logica di generazione del frontend con un altro VI LabVIEW, impostare un nuovo ID di esperimento nel file XHTML e registrare il corrispondente Name dell'esperimento e il percorso del VI in RIP Configuration. I controlli Web e le visualizzazioni di uscita vengono generati in base ai metadati restituiti dall'esperimento selezionato.
4. Configurare il percorso di accesso di Caddy per l'esperimento del motore.
   1. Aprire il file Caddy con un editor di testo.
   2. Impostare la directory radice del frontend sulla directory Client che contiene Motor_Automatic_UI.xhtml.
   3. Selezionare una porta locale non utilizzata affinché Caddy fornisca l'accesso tramite browser alla pagina Web e ai percorsi RIP. In questo protocollo, la porta 8090 viene utilizzata come esempio di porta di accesso proxy.
      NOTA: La porta 8090 non è richiesta da RIP o Caddy. Se la porta 8090 è occupata, sostituirla con un'altra porta locale libera e utilizzare la stessa porta nell'indirizzo del browser.
   4. Aggiungere un percorso che riscriva /motor in Motor_Automatic_UI.xhtml.
   5. Individuare la porta del RIP WebService configurata in LabVIEW. In questo protocollo, http://localhost:8001 viene utilizzato come indirizzo del RIP WebService.
      NOTA: La porta 8001 è la porta di backend di LabVIEW/RIP WebService utilizzata nell'ambiente di test. Può essere modificata nella configurazione di LabVIEW/RIP WebService. Se viene utilizzata una porta diversa, sostituire http://localhost:8001 nel file Caddy con l'indirizzo corrispondente del RIP WebService.
   6. Aggiungere una regola di proxy inverso che invii le richieste /RIP/SSE* all'indirizzo del RIP WebService, ad esempio http://localhost:8001.
   7. Aggiungere una regola di proxy inverso che invii le richieste /RIP* all'indirizzo del RIP WebService, ad esempio http://localhost:8001. La configurazione del file Caddy è mostrata in Figura 6.
   8. Aprire il Prompt dei comandi su Windows. Passare alla directory locale di download o installazione di Caddy inserendo il seguente comando:
      cd /d D:\caddy
      NOTA: In questo protocollo, D:\caddy è il percorso locale di download o installazione di Caddy utilizzato nell'ambiente di test. Se Caddy è memorizzato in un'altra directory, sostituire D:\caddy con il percorso locale corrispondente.
   9. Avviare Caddy con il file Caddy specificato inserendo il seguente comando:
      caddy.exe run --config Caddyfile
   10. Verificare che Caddy si avvii senza segnalare errori di configurazione. Aprire http://localhost:8090/motor in un browser Web e verificare che l'interfaccia utente Web del motore venga generata, come mostrato in Figura 12.
       ​NOTA: Se la pagina Web del motore si carica ma i valori di uscita non si aggiornano, verificare che RIP WebService sia in esecuzione, che il VI del motore sia in esecuzione, che la porta del RIP WebService in LabVIEW corrisponda all'indirizzo del proxy inverso nel file Caddy e che il percorso /RIP/SSE* sia correttamente prossimato.
5. Verificare i risultati operativi dell'esperimento del motore.
   1. Verificare che la pagina frontend generi automaticamente i controlli di input Setpoint, Kc, Ti, Td, Disturbance e Reset.
   2. Verificare che la pagina frontend visualizzi le variabili di uscita Position, Voltage, Time e Measured angular velocity.
   3. Regolare Setpoint e osservare se Position risponde al cambiamento della posizione desiderata.
   4. Regolare Kc, Ti e Td e osservare se Voltage, Position e Measured angular velocity cambiano.
   5. Regolare the disturbance e osservare se la posizione, la tensione di controllo o la velocità angolare misurata sono influenzate dall'input disturbance.
   6. Cliccare sul controllo Reset e osservare se Position, Voltage, Measured angular velocity e gli stati interni correlati tornano ai loro stati iniziali secondo la logica di reset.

Risultati

Dopo aver completato il flusso di lavoro descritto in precedenza, sia l'esperimento sul ventilatore sia l'esperimento sul controllo di posizione PID del motore in corrente continua possono essere accessibili tramite l'interfaccia web generata automaticamente. Un risultato positivo è indicato da tre osservazioni. In primo luogo, la pagina web genera automaticamente controlli di input e campi di visualizzazione dell'output in base ai metadati delle variabili restituiti dal server RIP. In secondo luogo, quando l'utente modifica una variabile di input sulla pagina web, il valore modificato viene scritto nel VI di back-end LabVIEW attraverso l'interfaccia RIP. In terzo luogo, le variabili di output calcolate dal VI di back-end vengono restituite tramite RIP e aggiornate sulla pagina web in tempo reale. Per l'esperimento sul ventilatore, dopo aver inserito http://localhost:8090/fan in un browser, la pagina genera automaticamente controlli di input e campi di output a partire dai metadati RIP, come mostrato in Figura 7. Il lato di input comprende Enable, PWM, Load, Tau, KMaxRPM e Disturbance, mentre il lato di output visualizza SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA e PowerW. Durante il funzionamento normale, TimeS aumenta continuamente, indicando che il VI di back-end fengshan.vi è in esecuzione. Quando PWM viene aumentato, SpeedRPM e SteadyRPM aumentano di conseguenza. Quando Load viene aumentato, la velocità del ventilatore diminuisce perché il carico riduce la velocità di funzionamento a regime. Quando Disturbance viene regolato, si possono osservare cambiamenti corrispondenti in SpeedRPM, CurrentA e PowerW. Queste osservazioni confermano che gli input dal lato web vengono trasmessi correttamente al back-end LabVIEW e che gli output calcolati vengono restituiti al front-end tramite RIP.

Per l'esperimento di controllo di posizione PID del motore in corrente continua, dopo aver inserito http://localhost:8090/motor in un browser, la pagina genera automaticamente i corrispondenti controlli e campi di output a partire dai metadati RIP, come mostrato in Figura 12. Le variabili di ingresso includono Punto di regolazione, Kc, Ti, Td, Disturbo, e Reimposta controllo, e le variabili di uscita includono Posizione, Tensione, Tempo, e Velocità angolare misuratay. Quando Valore di riferimento viene modificato, Posizione risponde al nuovo valore obiettivo. Quando i parametri PID Kc, Ti e Td vengono regolati, la risposta in uscita, il controllo tensione, e velocità angolare misurata modificare di conseguenza, indicando che i valori dei parametri inseriti nella pagina web vengono correttamente scritti nel modello LabVIEW sul backend e partecipano al calcolo di controllo. Quando il controllo di reset viene attivato, le variabili del modello tornano ai loro stati iniziali secondo la logica di reset.

Gli stati di errore e comunicazione lato browser sono mostrati in Figura 13, Figura 14, Figura 15. Figura 13 mostra un caso di accesso al browser non riuscito in cui Caddy non è in esecuzione. Il browser tenta di accedere a http://localhost:8090/motor ma visualizza un messaggio ERR_CONNECTION_REFUSED, indicando che il servizio proxy locale non è disponibile o non è in ascolto sulla porta di accesso selezionata. Figura 14 mostra un errore di comunicazione RIP POST dopo il caricamento della pagina. In questo caso, la console del browser segnala un errore 502 Bad Gateway per la richiesta RIP POST, indicando che il front-end ha raggiunto l'indirizzo del proxy ma la richiesta non può essere inoltrata correttamente al back-end del servizio Web RIP o elaborata da esso. Al contrario, Figura 15 mostra uno stato normale di comunicazione lato browser. Gli strumenti di sviluppo del browser mostrano un caricamento della pagina riuscito, richieste RIP POST e una richiesta SSE attiva con expId=fan, indicando che il front-end Web sta comunicando con il servizio Web RIP attraverso il proxy Caddy e riceve aggiornamenti in tempo reale tramite il canale SSE.

I risultati positivi relativi a ventola e motore, insieme ai risultati delle diagnosi lato browser, dimostrano che lo stesso flusso di lavoro basato sui metadati per la generazione automatica dell'interfaccia utente può essere riprodotto per due esperimenti LabVIEW diversi. Questi risultati forniscono inoltre criteri osservabili per distinguere una comunicazione riuscita dai tipici malfunzionamenti durante il deployment, mentre le corrispondenti procedure di risoluzione dei problemi sono discusse nella sezione Discussione.

Figura 1: Struttura complessiva del sistema sperimentale. Il sistema è composto dal VI di back-end LabVIEW, dal server RIP, dal proxy Caddy e dall'interfaccia web UI generata automaticamente. Il VI di LabVIEW fornisce le variabili del modello, il server RIP legge i metadati del VI e i valori delle variabili, Caddy unifica il percorso di accesso e risolve l'accesso cross-origin, mentre l'interfaccia web UI genera automaticamente i controlli. Il nome e il logo di Caddy sono mostrati esclusivamente per identificare il componente server/proxy web Caddy utilizzato nel flusso di lavoro. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 2: Pannello frontale del VI del ventilatore. Il pannello frontale contiene controlli di ingresso per Enable, PWM, Load, Tau, KMaxRPM e Disturbance e indicatori di uscita per SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA e PowerW. Questa schermata è stata acquisita dal pannello frontale di fengshan.vi in LabVIEW 2026 nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 3: Diagramma a blocchi del VI del ventilatore. Il modello del ventilatore è implementato mediante un ciclo While, registri a scorrimento, logica Enable, un nodo formula e indicatori di uscita. Questa schermata è stata acquisita dal diagramma a blocchi di fengshan.vi in LabVIEW 2026 nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 4: Pagina di configurazione di fan.vi. L'esperimento sul ventilatore è registrato nella Configurazione RIP con il nome dell'esperimento "fan", il percorso effettivo del VI, informazioni sulle parole chiave, una descrizione e la frequenza di campionamento. Questa schermata è stata acquisita dall'interfaccia di Configurazione RIP utilizzata con LabVIEW 2026 e RIP WebService nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 5: Impostazioni dell'ID dell'esperimento e logica di generazione dell'interfaccia utente basata sui metadati nei file front-end XHTML. Gli screenshot del codice XHTML sono stati acquisiti da Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml aperti in Visual Studio Code. Le pagine del ventilatore e del motore utilizzano la stessa logica di lettura dei metadati e di generazione dei controlli; soltanto l'ID dell'esperimento viene modificato per corrispondere al campo Nome nella configurazione RIP. Gli screenshot del codice XHTML sono stati acquisiti da Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml aperti in Visual Studio Code nell'ambiente di sviluppo locale degli autori. I file di codice sono stati preparati dagli autori per questo protocollo. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 6: Configurazione del Caddyfile. Il Caddyfile definisce la porta di accesso proxy locale, imposta la directory principale per l'interfaccia utente, riscrive i percorsi /fan e /motor nei corrispondenti file XHTML e inoltra tramite proxy inverso le richieste /RIP/SSE* e /RIP* alla porta del WebService LabVIEW/RIP. Lo screenshot della configurazione del Caddyfile è stato acquisito dal Caddyfile aperto in Visual Studio Code nell'ambiente di sviluppo locale degli autori. Il Caddyfile è stato predisposto dagli autori per configurare Caddy come server Web locale e proxy inverso. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 7: Pagina Web UI di fan.vi. Questa schermata dell'interfaccia Web è stata acquisita dalla pagina Web del ventilatore, distribuita localmente dagli autori, utilizzando Mozilla Firefox. La pagina front-end genera automaticamente controlli di input e visualizzazioni di output in base ai metadati delle variabili restituiti dal RIP Server. Questa schermata dell'interfaccia Web è stata acquisita dalla pagina Web del ventilatore, distribuita localmente dagli autori, utilizzando Mozilla Firefox. I controlli e i campi di output visualizzati sono stati generati dai metadati RIP nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 8: Pannello frontale del VI del motore. Il pannello frontale contiene i controlli per Setpoint, Kc, Ti, Td, Disturbo e Reset, e gli indicatori per Posizione, Tensione, Tempo e Velocità angolare misurata. Questa schermata è stata acquisita dal pannello frontale di Motor.vi in LabVIEW 2026 nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 9: Diagramma del modello di controllo di posizione PID per motore in corrente continua. Il diagramma mostra il percorso del segnale dall'errore del punto di riferimento, al controllo PID, al limite di tensione, alla sovrapposizione del disturbo, alla dinamica elettrica, alla dinamica meccanica e all'aggiornamento della posizione fino al feedback. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 10: Diagramma a blocchi del VI del motore. Il modello del motore è implementato mediante un ciclo While, registri a scorrimento, un nodo formula, logica temporale e indicatori di uscita. Questa schermata è stata acquisita dal diagramma a blocchi di Motor.vi in LabVIEW 2026 nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 11: Pagina di configurazione di Motor.vi. L'esperimento sul motore è registrato nella Configurazione RIP con il nome dell'esperimento (Motor), il percorso effettivo del VI, informazioni sulle parole chiave, descrizione e frequenza di campionamento. Questa schermata è stata acquisita dall'interfaccia di Configurazione RIP utilizzata con LabVIEW 2026 e RIP WebService nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 12: Pagina Web UI di Motor.vi. La pagina front-end genera automaticamente controlli di input e visualizzazioni di output per l'esperimento di controllo di posizione PID del motore in corrente continua. Questa schermata dell'interfaccia Web è stata acquisita dalla pagina Web del motore, distribuita localmente dagli autori, utilizzando Mozilla Firefox. I controlli e i campi di output visualizzati sono stati generati dai metadati RIP nell'ambiente sperimentale locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 13: Accesso al browser non riuscito quando Caddy non è in esecuzione. Quando Caddy non è avviato, l'indirizzo locale inoltrato http://localhost:8090/motor non è raggiungibile e il browser visualizza un messaggio ERR_CONNECTION_REFUSED. Questo sintomo di errore indica che il servizio proxy Caddy locale non è disponibile o non è in ascolto sulla porta di accesso selezionata. Questa schermata del browser è stata acquisita utilizzando Mozilla Firefox nell'ambiente di test locale degli autori e mostra lo stato di accesso non riuscito quando il proxy Caddy locale non era in esecuzione. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 14: Errore di comunicazione RIP POST dopo il caricamento della pagina. La console del browser mostra un errore 502 Bad Gateway per la richiesta RIP POST. Questo risultato indica che la pagina web ha raggiunto l'indirizzo del proxy Caddy, ma la richiesta non può essere inoltrata o elaborata correttamente dal backend del servizio web RIP. Questo screenshot della console del browser è stato acquisito utilizzando gli strumenti per sviluppatori di Mozilla Firefox nell'ambiente di distribuzione locale degli autori e mostra un errore di comunicazione RIP POST 502 Bad Gateway. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 15: Stato della comunicazione lato browser durante il funzionamento normale. Gli strumenti di sviluppo del browser mostrano un caricamento corretto della pagina, richieste POST RIP e una richiesta SSE attiva con expId=fan. Queste richieste indicano che l'interfaccia web front-end sta comunicando con il WebService RIP attraverso il proxy Caddy e sta ricevendo aggiornamenti in tempo reale tramite il canale SSE. Questa schermata degli strumenti di sviluppo del browser è stata catturata utilizzando Mozilla Firefox nell'ambiente di distribuzione locale degli autori e mostra una comunicazione POST RIP e SSE normale. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 16: Osservazione rappresentativa singola a livello di console del browser e delle risorse a livello di processo per l'esperimento con il ventilatore. Lo screenshot è stato registrato durante un test locale dell'esperimento con il ventilatore. La console mostra il tempo di richiesta/risposta dei metadati, il numero di variabili nei metadati, il tempo di generazione dell'interfaccia utente basata sui metadati, il tempo di apertura della connessione SSE e i dati SSE ricevuti. La vista del gestore attività mostra i valori di CPU e memoria a livello di processo per i processi del browser e di LabVIEW al momento dell'acquisizione. Questi valori sono osservazioni descrittive di questo singolo test e non rappresentano misurazioni di prestazioni replicate o un benchmark statistico. Lo screenshot è stato acquisito utilizzando gli strumenti per sviluppatori di Mozilla Firefox e il Task Manager di Windows nell'ambiente di test locale degli autori. Mozilla Firefox è stato utilizzato per registrare l'output della console del browser, mentre il Task Manager di Windows è stato utilizzato per osservare l'utilizzo di CPU e memoria da parte dei processi del browser e di LabVIEW. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Figura 17: Accesso simultaneo alla stessa pagina web basata su RIP da un browser desktop e da un browser mobile. La pagina dell'esperimento sul ventilatore viene aperta contemporaneamente su dispositivi PC e mobili, e entrambi i client mostrano i controlli e le variabili di uscita generati automaticamente. La pagina web desktop è stata accessibile tramite Mozilla Firefox, mentre la pagina web mobile è stata accessibile tramite un browser mobile nello stesso ambiente di rete locale. Gli screenshot sono stati catturati dall'ambiente di test locale degli autori. Non sono inclusi dati di utenti terzi né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Nome della variabile	Tipo di dato	Ingresso/Uscita	Significato fisico	Ruolo nel modello			Intervallo/Impostazione
Enable	Boolean	Ingresso	Interruttore di accensione del ventilatore	Controlla se il modello riceve l'ingresso PWM. Quando è True, u = PWM; quando è False, u = 0.			True / False
PWM	DBL	Ingresso	Ingresso di comando	Determina l'intensità di comando di base del ventilatore ed è l'ingresso principale utilizzato per calcolare la velocità a regime SteadyRPM.			0-1, passo 0,01
Load	DBL	Ingresso	Coefficiente di carico	Descrive l'effetto di riduzione della velocità a regime dovuto al carico. Aumentando il carico, la velocità a regime diminuisce.			0-1, passo 0,01
Tau	DBL	Ingresso	Costante di tempo di risposta	Determina con quale rapidità la velocità del ventilatore si avvicina alla velocità a regime a partire dallo stato precedente.			0,1-5, passo 0,1
KMaxRPM	DBL	Ingresso	Velocità massima	Imposta la velocità massima consentita dal modello ed è utilizzata per il limitatore di velocità e la normalizzazione.			500-6000, passo 100
Disturbance	DBL	Ingresso	Ingresso di disturbo	Rappresenta l'effetto di un disturbo esterno o di una fluttuazione del carico sulla velocità a regime, sulla corrente e sulla potenza.			0-1, passo 0,1
SpeedRPM	DBL	Uscita	Velocità effettiva	Rappresenta la velocità attuale in uscita del ventilatore ed è aggiornata attraverso dinamiche inerziali del primo ordine.			Calcolata dal modello
SteadyRPM	DBL	Uscita	Velocità a regime	Rappresenta la velocità teorica a regime nelle attuali condizioni di ingresso.			Calcolata dal modello
TimeS	DBL	Uscita	Tempo di funzionamento	Rappresenta il tempo continuo di funzionamento del modello.			Calcolato dal modello
SpeedNorm	DBL	Uscita	Velocità normalizzata	Rappresenta il rapporto tra SpeedRPM e KMaxRPM.			0-1 o calcolato dal modello
CurrentA	DBL	Uscita	Corrente	Rappresenta la corrente stimata del modello, che varia in base all'ingresso di comando e all'ingresso di disturbo.			Calcolata dal modello
PowerW	DBL	Uscita	Potenza	Rappresenta la potenza stimata del modello, calcolata a partire dalla costante di tensione e dalla corrente.			Calcolata dal modello
Setpoint	DBL	Ingresso	Posizione desiderata	Imposta la posizione che il motore deve raggiungere e forma l'errore e con la posizione effettiva Position.			-3-3, passo 0,1
Kc	DBL	Ingresso	Guadagno proporzionale	Regola l'intensità di risposta del controllore PID all'errore.			0-10, passo 0,1
Ti	DBL	Ingresso	Tempo integrale	Regola l'azione integrale del controllore PID ed è utilizzato per ridurre l'errore a regime.			0-10, passo 0,1
Td	DBL	Ingresso	Tempo derivativo	Regola l'azione derivativa del controllore PID ed è utilizzato per sopprimere variazioni eccessivamente rapide dell'errore e migliorare la risposta dinamica.			0-5, passo 0,1
Disturbance	DBL	Ingresso	Ingresso di disturbo	Rappresenta un disturbo esterno sovrapposto all'ingresso del motore, che agisce sul modello del motore insieme alla tensione di controllo.			0-10, passo 0,1
Reset control	Boolean	Ingresso	Controllo di reset	Attiva la cancellazione dello stato del modello in modo che posizione, velocità angolare, corrente, errore e termine integrale tornino ai loro stati iniziali.			True / False
Position	DBL	Uscita	Posizione effettiva	Rappresenta la posizione angolare attuale del motore e funge da variabile di retroazione per il controllo PID.			Calcolata dal modello
Voltage	DBL	Uscita	Tensione di controllo	Rappresenta l'uscita del controllore PID dopo il limitatore di tensione ed agisce sull'ingresso del motore.			Calcolata dal modello; limitata tra -24 e 24 V
Time	DBL	Uscita	Tempo di funzionamento	Rappresenta il tempo continuo di funzionamento del modello del motore.			Calcolato dal modello
Measured angular velocity	DBL	Uscita	Velocità angolare misurata	Rappresenta la velocità angolare attuale del motore ed è l'uscita dello stato meccanico del motore.			Calcolata dal modello

Tabella 1: Variabili di ingresso e di uscita utilizzate negli esempi del ventilatore e del motore in corrente continua. La tabella elenca il nome di ciascuna variabile, il tipo di dati, il ruolo di ingresso/uscita, il significato fisico, l'intervallo raccomandato e l'incremento.

Parametro	Valore	Significato fisico	Ruolo nel modello
R	1	Resistenza dell'avvolgimento	Rappresenta il termine resistivo nel circuito dell'avvolgimento del motore e determina la caduta di tensione R × im nell'equazione della corrente.
L	0,5	Induttanza dell'avvolgimento	Rappresenta l'induttanza del circuito dell'avvolgimento e determina la velocità di variazione della corrente. Un valore maggiore di L produce una risposta di corrente più lenta.
J	0,01	Momento d'inerzia	Rappresenta la resistenza del rotore del motore alle variazioni di accelerazione angolare e determina quanto rapidamente cambia la velocità angolare.
b	0,1	Coefficiente di smorzamento viscoso	Rappresenta lo smorzamento meccanico e descrive la coppia smorzante che ostacola l'aumento della velocità angolare durante la rotazione.
Kt	0,01	Costante di coppia	Rappresenta il coefficiente di proporzionalità che converte la corrente dell'avvolgimento in coppia elettromagnetica.
Ke	0,01	Costante della forza elettromotrice contraria	Rappresenta il coefficiente di proporzionalità secondo cui la velocità angolare genera la forza elettromotrice contraria e descrive l'effetto di retroazione della velocità sulla corrente.
Vmax	24	Tensione di controllo massima	Rappresenta il limite della tensione di uscita del controllore e mantiene la tensione nell'intervallo compreso tra -24 V e 24 V.
dt	0,001	Passo di simulazione discreto	Rappresenta l'intervallo di tempo per ciascun aggiornamento di stato basato su ciclo ed è utilizzato per aggiornare corrente, velocità angolare, posizione e tempo di esecuzione.

Tabella 2: Parametri interni utilizzati nel modello di controllo di posizione PID del motore in corrente continua. La tabella elenca i parametri elettrici e meccanici, i simboli, i valori numerici, le unità di misura e i ruoli all'interno del modello.

File di codice supplementari: file completi di codice sorgente e configurazione per riprodurre gli esempi del ventilatore e del motore in corrente continua. I file di codice supplementari includono il codice per il nodo formula di LabVIEW, la configurazione del reverse-proxy Caddy, i file front-end XHTML e i file sorgente VI di LabVIEW utilizzati in questo protocollo. Il documento Code in LabVIEW Formula Node.docx contiene il codice del nodo formula per i modelli di controllo posizionale PID del ventilatore e del motore CC. Il file Caddyfile.txt contiene la configurazione del server Web locale e del reverse-proxy. I file Fan_Automatic_UI.xhtml e Motor_Automatic_UI.xhtml contengono la logica front-end basata su metadati. I file fengshan.vi e Motor.vi sono i file VI di back-end di LabVIEW per gli esperimenti con ventilatore e motore.Fare clic qui per scaricare questo file.

Discussione

Un passaggio fondamentale di questo protocollo è la costruzione standardizzata e la registrazione del VI del backend LabVIEW. I controlli e gli indicatori del pannello frontale devono utilizzare nomi di variabili chiari e univoci, e i loro tipi di dati devono corrispondere alle variabili previste dal calcolo del modello e dal processo di lettura/scrittura di RIP. Nei due esempi utilizzati in questo protocollo, le variabili numeriche scalari sono definite come controlli o indicatori DBL, mentre le variabili booleane sono definite come controlli booleani. Il diagramma a blocchi deve inoltre mantenere un aggiornamento continuo dello stato attraverso il ciclo While, i registri di scorrimento (Shift Registers) e il nodo formula, in modo che variabili come la velocità della ventola, la posizione del motore, la velocità angolare del motore, la tensione e il tempo possano essere aggiornate durante l'esecuzione. Dopo aver costruito il VI, il Nome dell'esperimento nella configurazione di RIP deve corrispondere esattamente all'ID dell'esperimento utilizzato nel file XHTML corrispondente, e il percorso del VI (VI Path) deve puntare al file VI effettivamente salvato. Queste impostazioni sono importanti perché l'interfaccia web non codifica in modo fisso le variabili di ciascun esperimento. Al contrario, si basa sui metadati restituiti dal server RIP per identificare le variabili scrivibili, le variabili leggibili, i tipi di dati e le proprietà numeriche^10,11.

I principali problemi di risoluzione dei guasti sono legati alla coerenza tra l'ID dell'esperimento in formato XHTML, la configurazione di RIP, il servizio web RIP e le impostazioni del proxy Caddy. Se l'ID dell'esperimento nel file XHTML non corrisponde al nome dell'esperimento nella configurazione di RIP, la pagina web non può richiedere i metadati corretti e quindi non può generare i controlli e i campi di output previsti. Se il percorso VI è errato o il servizio web RIP non è avviato, la pagina web potrebbe aprirsi ma non riuscire a comunicare con il backend LabVIEW. Se Caddy non è in esecuzione, il browser non può accedere all'indirizzo proxy locale selezionato e potrebbe visualizzare un messaggio ERR_CONNECTION_REFUSED, come mostrato in Figura 13. Se Caddy è in esecuzione ma la destinazione del reverse-proxy non corrisponde alla porta del servizio web RIP, la pagina potrebbe caricarsi mentre le richieste POST di RIP falliscono con un errore 502 Bad Gateway, come mostrato in Figura 14. Se il percorso /RIP/SSE* non funziona correttamente, la pagina potrebbe aprirsi e mostrare i controlli, ma i valori di output non si aggiornano in tempo reale. In condizioni normali di funzionamento, gli strumenti per sviluppatori del browser dovrebbero mostrare un caricamento della pagina riuscito, richieste POST di RIP e una richiesta SSE attiva con l'ID dell'esperimento corretto, come mostrato in Figura 15. Pertanto, la risoluzione dei problemi dovrebbe iniziare verificando l'ID dell'esperimento, il percorso VI, lo stato del servizio web RIP, lo stato di esecuzione di Caddy, le porte del proxy e il percorso SSE. Se la comunicazione continua a comportarsi in modo anomalo, riavviare sia il servizio web RIP che Caddy, cancellare la cache del browser o ripetere il test in un altro browser potrebbe aiutare a distinguere comportamenti specifici del browser da problemi di configurazione di RIP o Caddy.

Il presente protocollo è riproducibile nei due esempi poiché lo stesso flusso di lavoro di creazione, registrazione, distribuzione e verifica viene applicato sia a un modello di controllo della velocità di un ventilatore sia a un modello di controllo di posizione PID per un motore in corrente continua. Per ridurre la dipendenza da toolboxes specializzati, i VI di back-end vengono ricostruiti utilizzando strutture LabVIEW di base, tra cui controlli e indicatori del pannello frontale, cicli While, shift register, nodi formula e variabili numeriche scalari standard e variabili booleane. Tuttavia, la riproducibilità tra diverse versioni di LabVIEW, installazioni di Windows e ambienti di rete locale dipende ancora da dettagli di configurazione come percorsi dei file, permessi di accesso, porte locali, comandi di avvio dei servizi e comportamento del browser. Il flusso di lavoro potrebbe essere esteso anche a esperimenti remoti legati all'hardware, ma il metodo non deve essere interpretato come un riconoscimento diretto dell'hardware da parte del lato Web. L'interfaccia Web front-end identifica i controlli e gli indicatori del pannello frontale di LabVIEW attraverso i metadati RIP. Pertanto, sensori, attuatori, strumenti o dispositivi per il controllo di processo devono innanzitutto essere collegati ed elaborati nel VI di back-end LabVIEW mediante driver hardware appropriati, moduli di acquisizione dati, moduli di controllo strumenti o altri meccanismi di adattamento hardware. Una volta che le misurazioni hardware e i comandi di controllo sono mappati sugli indicatori e controlli del pannello frontale, l'interfaccia Web front-end basata su RIP può riconoscere queste variabili nello stesso modo in cui riconosce le variabili di simulazione utilizzate nel presente protocollo. Studi precedenti su laboratori remoti basati su LabVIEW hanno dimostrato che LabVIEW può essere utilizzato come ambiente di back-end per esperimenti di ingegneria del controllo remoto, esperimenti robotici, impianti per il controllo di processo, acquisizione di dati da sensori e interazione con dispositivi fisici^{9,12,17,18,19,20}.

Figura 16 presenta un singolo esempio rappresentativo di implementazione registrato durante un esperimento con ventola locale. Il codice front-end è stato strumentato per registrare il tempo di richiesta/risposta dei metadati, il numero di variabili nei metadati, il tempo di generazione dell'interfaccia utente basata sui metadati, il tempo di apertura della connessione SSE e i dati SSE ricevuti. In questo caso, la console del browser ha riportato un tempo di richiesta/risposta dei metadati di 68,00 ms, ha identificato 7 variabili scrivibili e 7 variabili leggibili dai metadati RIP, ha generato gli elementi corrispondenti dell'interfaccia utente in 2,00 ms e ha aperto la connessione SSE in 16,00 ms. Le voci ripetute dei dati SSE hanno mostrato che variabili di uscita come SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA e PowerW venivano ricevute continuamente dal back-end LabVIEW. La vista del task manager nello stesso stato del test locale ha mostrato circa l'1,5% di utilizzo della CPU e 391,7 MB di memoria per il processo di Firefox, mentre il processo LabVIEW mostrava uno 0% di utilizzo della CPU e 9,2 MB di memoria al momento dell'acquisizione. Queste osservazioni forniscono evidenze di base che il recupero dei metadati, la generazione dell'interfaccia utente basata sui metadati, la comunicazione RIP/SSE e l'overhead della CPU a livello di processo possono essere osservati nell'ambiente di distribuzione locale. Tuttavia, questi dati sono destinati a verificare il livello di implementazione piuttosto che costituire un benchmark completo delle prestazioni. Una valutazione sistematica delle prestazioni in diversi browser, con prove ripetute, carichi maggiori di variabili, hardware fisico e più utenti simultanei rimane necessaria nei futuri sviluppi.

Questo metodo presenta anche delle limitazioni, in particolare quando viene esteso a strutture dati complesse, esperimenti hardware e operazioni multiutente. Il flusso di lavoro attuale è più adatto a variabili di ingresso/uscita numeriche scalari e booleane. Non fornisce automaticamente un supporto completo per array complessi, cluster, strutture dati annidate, relazioni tra grafici o visualizzazioni specifiche per dominio. Questi casi potrebbero richiedere regole aggiuntive per il mapping dei metadati o componenti front-end scritti manualmente. L'interfaccia utente generata automaticamente può creare controlli e visualizzazioni di base a partire dai metadati delle variabili, ma non è in grado di inferire completamente le relazioni fisiche tra le variabili, selezionare la visualizzazione più appropriata o progettare interazioni specifiche per la sicurezza dell'esperimento. Quando il flusso di lavoro viene esteso a dispositivi reali, sono necessarie ulteriori considerazioni, tra cui driver hardware, calibrazione dei dispositivi, vincoli di campionamento, limiti degli attuatori, logica di arresto di emergenza, autenticazione e meccanismi di controllo della scrittura multiutente. La distribuzione attuale può inoltre essere accessibile da più dispositivi client attraverso normali browser web nello stesso ambiente di rete locale. Come mostrato in Figura 17, la stessa pagina dell'esperimento con la ventola è stata aperta contemporaneamente su un browser desktop e su un browser mobile, e entrambi i client hanno visualizzato i controlli generati automaticamente e le corrispondenti variabili di uscita. Questa osservazione indica un accesso multi-client base simultaneo alla visualizzazione e all'interazione con la stessa pagina sperimentale. Tuttavia, ciò non deve essere interpretato come un framework completo per il controllo multiutente, poiché l'implementazione attuale non include autenticazione utente dedicata, blocco del controllo, arbitrato della scrittura concorrente, code di scrittura o meccanismi di risoluzione dei conflitti. Queste limitazioni sono coerenti con studi precedenti sui laboratori remoti, nei quali laboratori remoti complessi o collaborativi richiedono solitamente una progettazione dell'interfaccia specifica per l'esperimento, meccanismi di sincronizzazione, vincoli di sicurezza e logica di gestione degli utenti^{13,14,15,16,17}.

Il valore metodologico di questo protocollo non consiste nell'introdurre una nuova architettura RIP o nell'estendere i tipi di dati supportati da RIP. Piuttosto, il suo valore risiede nel fornire un percorso di implementazione completo e riproducibile per applicare un meccanismo consolidato di generazione automatica di interfacce utente basato su RIP a diversi sistemi LabVIEW. Rispetto alla scrittura di un'interfaccia web personalizzata per ogni esperimento, questo flusso di lavoro riduce la ripetizione dell'implementazione di elementi fondamentali come il layout di controllo, il binding delle variabili e la logica di comunicazione in lettura/scrittura, quando il VI di back-end espone variabili compatibili^8,9,10,11. Il protocollo risulta quindi utile per l'educazione ingegneristica, lo sviluppo di laboratori remoti e il rapido dispiegamento di esperimenti di simulazione o didattici a basso rischio che richiedono l'aggiustamento dei parametri tramite browser e il monitoraggio in tempo reale dello stato. Lavori futuri dovrebbero estendere il flusso di lavoro a strutture dati più complesse, dispositivi sperimentali fisici, sistemi formali di controllo d'accesso multiplo e valutazioni quantitative delle prestazioni, inclusi il tempo di generazione dell'interfaccia, la latenza di comunicazione, la stabilità della sincronizzazione, il carico del server, l'overhead della CPU e l'usabilità del front-end.

Materiali

Elenco dei materiali utilizzati in questo articolo

Nome	Azienda	Numero di catalogo	Commenti
Server proxy Caddy	Caddy	N/A	Proxy inverso utilizzato per fornire l'interfaccia web e inoltrare le richieste /RIP al servizio web RIP
Caddyfile	Preparato dagli autori	N/A	Definisce percorsi per file statici e percorsi di proxy inverso per la comunicazione RIP
Fan_Automatic_UI.xhtml	Preparato dagli autori	N/A	Interfaccia web basata su metadati per l'esperimento del ventilatore
LabVIEW	National Instruments	2026	Software utilizzato per creare ed eseguire fengshan.vi e Motor.vi
Sistema operativo Microsoft Windows	Microsoft	Win11	Sistema operativo utilizzato per eseguire LabVIEW, RIP WebService, Caddy e il browser.
Motor_Automatic_UI.xhtml	Preparato dagli autori	N/A	Interfaccia web basata su metadati per l'esperimento del motore
Browser desktop Mozilla Firefox	Mozilla	2026	Browser desktop utilizzato per l'accesso all'interfaccia web, strumenti per sviluppatori, osservazioni temporali e delle risorse, e schermate di Rete/Console.
Servizio web RIP	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Riceve richieste POST RIP e fornisce il livello di comunicazione del servizio web utilizzato dall'interfaccia front-end del browser.
Task Manager di Windows	Microsoft	Integrato in Windows	Utilizzato per registrare osservazioni a livello di processo relative a CPU e memoria per i processi del browser e di LabVIEW.