È richiesta un abbonamento a JoVE per visualizzare questo contenuto. Accedi o inizia la tua prova gratuita.

Articolo metodologico

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

189 visualizzazioni

⸱

DOI:

10.3791/72765

⸱

14 agosto 2026

 ,  ,  , 
1School of Electrical Engineering and Automation, Wuhan University, 2School of Robotics, Wuhan University, 3Department of Computer Science and Automatic Control, National University of Distance Education, 4School of Civil Engineering, Wuhan University

In questo articolo

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 sperimentali1,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 ingegneristica5. 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 reale6,7. I metodi convenzionali richiedono tipicamente una pagina web dedicata, logica di associazione del controllo e interfaccia di comunicazione dati per ciascun oggetto sperimentale8,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-end10,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 disponibili11. 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 pagina11. 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 simili8,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 base10,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 simili3,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 sicurezza11. 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 studio11. Architetture di laboratori remoti abilitati al web, che combinano interfacce interattive con software ingegneristici e LabVIEW, sono state inoltre riportate in studi precedenti9,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 stato10,11. È meno adatto come soluzione autonoma per esperimenti che richiedono strutture dati complesse, visualizzazioni specializzate, interblocchi di sicurezza hardware rigorosi o arbitrato della scrittura multiutente11. 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 esempio9,10,11.

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

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 precedenza11.
    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.

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

Risultati

Dopo aver completato il flusso di lavoro descritto sopra, sia l'esperimento con il ventilatore sia l'esperimento di controllo in posizione PID del motore in corrente continua possono essere accessibili tramite l'interfaccia web generata automaticamente. Un risultato positivo è indicato da tre osservazioni. Primo, la pagina web genera automaticamente controlli di input e campi di visualizzazione dell'output in base ai metadati delle variabili restituiti dal RIP Server. Secondo, quando l'utente modifica una variabile di in...

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

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 ...

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

Dichiarazioni

Gli autori hanno utilizzato strumenti assistiti da intelligenza artificiale esclusivamente per la revisione linguistica. Tutti i contenuti scientifici, le procedure sperimentali, l'implementazione del software, le figure, i risultati, le interpretazioni e la formulazione finale sono stati esaminati, corretti e approvati dagli autori. Nessuno strumento di intelligenza artificiale è stato utilizzato per generare dati sperimentali.

Ringraziamenti

Questo lavoro è stato sostenuto dai programmi di formazione per studenti universitari in innovazione dell'Università di Wuhan.

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

Materiali

Elenco dei materiali utilizzati in questo articolo
NomeAziendaNumero di catalogoCommenti
Server proxy CaddyCaddyN/AProxy inverso utilizzato per fornire l'interfaccia web e inoltrare le richieste /RIP al servizio web RIP
CaddyfilePreparato dagli autoriN/ADefinisce percorsi per file statici e percorsi di proxy inverso per la comunicazione RIP
Fan_Automatic_UI.xhtmlPreparato dagli autoriN/AInterfaccia web basata su metadati per l'esperimento del ventilatore
LabVIEWNational Instruments2026Software utilizzato per creare ed eseguire fengshan.vi e Motor.vi
Sistema operativo Microsoft WindowsMicrosoftWin11Sistema operativo utilizzato per eseguire LabVIEW, RIP WebService, Caddy e il browser.
Motor_Automatic_UI.xhtmlPreparato dagli autoriN/AInterfaccia web basata su metadati per l'esperimento del motore
Browser desktop Mozilla FirefoxMozilla2026Browser desktop utilizzato per l'accesso all'interfaccia web, strumenti per sviluppatori, osservazioni temporali e delle risorse, e schermate di Rete/Console.
Servizio web RIPUNEDLabshttps://github.com/Nebulous-Systems/rip-server_labviewRiceve richieste POST RIP e fornisce il livello di comunicazione del servizio web utilizzato dall'interfaccia front-end del browser.
Task Manager di WindowsMicrosoftIntegrato in WindowsUtilizzato per registrare osservazioni a livello di processo relative a CPU e memoria per i processi del browser e di LabVIEW.

Riferimenti

  1. Gomes, L., Bogosyan, S. Current trends in remote laboratories. IEEE Trans Ind Electron. 2009;56(12):4744–4756.
  2. Ma, J., Nickerson, J. V. Hands-on, simulated, and remote laboratories: A comparative literature review. ACM Comput Surv. 2006;38(3):7-es.
  3. Heradio, R. et al. Virtual and remote labs in education: A bibliometric analysis. Comput. Educ. 2016;98:14–38.
  4. May, D., Jahnke, I., Moore, S. Online laboratories and virtual experimentation in higher education from a sociotechnical-pedagogical design perspective. J. Comput. High. Educ. 2023;35:203–222.
  5. Amador Nelke, S. et al. Enhancing lessons on the Internet of Things in science, technology, engineering, and medical education with a remote lab. Sensors.2024;24(19):6424.
  6. Lei, Z. et al. Interactive and visualized online experimentation system for engineering education and research. J. Vis. Exp. 2021;(177):e63342.
  7. Zhang, G., Lei, Z., Hu, W., Zhou, H. Online virtual reality networked control laboratory applied in control engineering education. J. Vis. Exp. 2024;(204):e66432.
  8. Fabregas, E., Farias, G., Dormido-Canto, S., Dormido, S., Esquembre, F. Developing a remote laboratory for engineering education. Comput. Educ. 2011;57(2):1686–1697.
  9. Chacón, J., Vargas, H., Farias, G., Sánchez, J., Dormido, S. EJS, JIL Server, and LabVIEW: An architecture for rapid development of remote labs. IEEE Trans. Learn. Technol.2015;8(4):393–401.
  10. Chacón, J., Farias, G., Vargas, H., Visioli, A., Dormido, S. Remote Interoperability Protocol: A bridge between interactive interfaces and engineering systems. IFAC-PapersOnLine.2015;48(29):247–252.
  11. de la Torre, L., Chacón, J., Chaos, D., Heradio, R., Chandramouli, R. Using IoT-type metadata and smart Web design to create user interfaces automatically. IEEE Trans. Ind. Inform. 2023;19(3):3109–3118.
  12. Chaos, D., Chacón, J., Lopez-Orozco, J. A., Dormido, S. Virtual and remote robotic laboratory using EJS, MATLAB, and LabVIEW. Sensors. 2013;13(2):2595–2612.
  13. Haj-Hosseini, N., Jonasson, H., Stridsman, M., Carlsson, L. Interactive remote electrical safety laboratory module in biomedical engineering education. Educ. Inf. Technol. 2024;29:20505–20521.
  14. Galán, D. et al. Safe experimentation in optical levitation of charged droplets using remote labs. J. Vis. Exp. 2019;(143):e58699.
  15. Kurtz, M., Benabbou, A., Pons, C., Broisin, J. Collaboration in virtual and remote laboratories for education: A systematic literature review. Int. J. Comput.-Support. Collab. Learn. 2025;20:549–603.
  16. Zamarreño, J. M., Ríos, J. C., Alonso, G. Virtual and remote laboratory as a complementary support in control education. Discov. Educ. 2025;4:477.
  17. Chacón, J., Sáenz, J., de la Torre, L., Díaz, J. M., Esquembre, F. Design of a low-cost air levitation system for teaching control engineering. Sensors. 2017;17(10):2321.
  18. Stefanovic, M., Cvijetkovic, V., Matijevic, M., Simic, V. A LabVIEW-based remote laboratory experiments for control engineering education. Comput. Appl. Eng. Educ.2011; 19(3):538–549.
  19. González, I., Calderón, A. J., Mejías, A., Andújar, J. M. Novel networked remote laboratory architecture for open connectivity based on PLC-OPC-LabVIEW-EJS integration. Application in remote fuzzy control and sensors data acquisition. Sensors. 2016;16(11):1822.
  20. Abdulwahed, M., Nagy, Z. K. Developing the TriLab, a triple access mode (hands-on, virtual, remote) laboratory, of a process control rig using LabVIEW and Joomla. Comput. Appl. Eng. Educ. 2013;21(4):614–626.

Accesso limitato. Accedi o avvia una prova gratuita per visualizzare questo contenuto.

Ristampe e permessi

Tag

Interfaccia Utente WebGenerazione Automatica dell'Interfaccia UtenteStrumenti VirtualiConfigurazione del Server RIPReverse ProxyProxy CaddyControllo di Posizione PIDMetadati Variabili

Questo articolo è stato pubblicato

Video in arrivo

Contattaci
Consiglia alla biblioteca

Privacy

Termini di utilizzo

Politiche

Copyright © 2026 MyJoVE Corporation. Tutti i diritti riservati.