Articolo metodologico

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

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

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.

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 input sulla pagina web, il valore modificato viene scritto nel VI di back-end LabVIEW attraverso l'interfaccia RIP. Terzo, 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 con il 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 Setpoint, Kc, Ti, Td, Disturboe Reimposta controllo, e le variabili di uscita includono Posizione, Voltaggio, 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 tensionee velocità angolare misurata modificare di conseguenza, indicando che i valori dei parametri inseriti sulla pagina Web vengono correttamente scritti nel modello di backend LabVIEW 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 di 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 riporta un errore 502 Bad Gateway per la richiesta RIP POST, indicando che il frontend ha raggiunto l'indirizzo del proxy ma la richiesta non può essere correttamente inoltrata o elaborata dal backend del servizio Web RIP. Al contrario, Figura 15 mostra uno stato normale di comunicazione lato browser. Gli strumenti di sviluppo del browser mostrano un caricamento della pagina avvenuto con successo, richieste RIP POST corrette e una richiesta SSE attiva con expId=fan, indicando che l'interfaccia Web frontend comunica 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 della diagnostica lato browser, dimostrano che lo stesso flusso di lavoro per la generazione automatica dell'interfaccia utente basato sui metadati può essere riprodotto per due esperimenti diversi in LabVIEW. Questi risultati forniscono inoltre criteri osservabili per distinguere una comunicazione riuscita da guasti rappresentativi del sistema, mentre le relative procedure di risoluzione dei problemi sono trattate nella sezione Discussione.

Diagramma del processo da LabVIEW VI a Web UI, che mostra il server RIP e il proxy Caddy per la comunicazione dei dati.
Figura 1: Struttura complessiva del sistema sperimentale. Il sistema è costituito dal VI di backend LabVIEW, dal server RIP, dal proxy Caddy e dall'interfaccia web (Web UI) generata automaticamente. Il VI 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 i problemi di accesso cross-origin, mentre l'interfaccia web 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.

Diagramma del sistema di controllo motore con grafico RPM, parametri di ingresso e analisi dei dati di uscita.
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 o informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Diagramma del nodo formula con registri a scorrimento e ciclo while per l'analisi del processo di controllo del numero di giri.
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 o informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Interfaccia LabVIEW con configurazione del modello del ventilatore, impostazioni di campionamento e percorsi della telecamera per il monitoraggio del sistema.
Figura 4: Pagina di configurazione di fan.vi. L'esperimento relativo al ventilatore viene 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.

Frammenti di codice JavaScript per la logica dell'interfaccia utente di un'applicazione web; metodo per la creazione dinamica di elementi.
Figura 5: Impostazioni dell'ID dell'esperimento e logica di generazione dell'interfaccia utente basata su metadati nei file front-end XHTML. Gli screenshot del codice XHTML sono stati catturati 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 catturati 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.

Diagramma di configurazione del server Caddy con percorsi, proxy inversi e impostazione della porta di accesso.
Figura 6: Configurazione del Caddyfile. Il Caddyfile definisce la porta di accesso del proxy locale, imposta la directory radice 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 file 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.

Diagramma del sistema di controllo della ventola con cursori di input e visualizzazioni di output per l'ottimizzazione delle prestazioni.
Figura 7: Pagina dell'interfaccia web di fan.vi. Questo screenshot dell'interfaccia web è stato acquisito dalla pagina web fan, 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. I controlli e i campi di output mostrati 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.

Diagramma del sistema di controllo PID con motore, retroazione della posizione e grafico della risposta dinamica.
Figura 8: Pannello frontale del VI del motore. Il pannello frontale contiene i controlli per Setpoint, Kc, Ti, Td, Disturbo e Ripristino, 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.

Diagramma a blocchi del controllore PID con equazioni; flusso ingresso-uscita tra modelli per il controllo del sistema.
Figura 9: Diagramma del modello di controllo della posizione PID per motore in corrente continua. Il diagramma mostra il percorso del segnale, dall'errore del punto di riferimento, attraverso il controllo PID, il limite di tensione, la sovrapposizione del disturbo, la dinamica elettrica, la dinamica meccanica e l'aggiornamento della posizione, fino al feedback. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Diagramma LabVIEW del sistema di controllo con registri a scorrimento, nodo formula in un ciclo while, per il controllo del processo.
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 di temporizzazione 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.

Interfaccia di configurazione del modello del motore in LabVIEW per il controllo e la configurazione del campionamento nell'analisi ingegneristica.
Figura 11: Pagina di configurazione di Motor.vi. L'esperimento sul motore viene registrato nella configurazione RIP con il nome dell'esperimento (Motor), il percorso effettivo del VI, informazioni sui keyword, descrizione e frequenza di campionamento. Questa schermata è stata acquisita dall'interfaccia RIP Configuration 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.

Sistema di controllo del motore, interfaccia di taratura PID con cursore di ingresso e visualizzazioni di uscita, quadrante della velocità angolare.
Figura 12: Pagina dell'interfaccia web di Motor.vi. La pagina front-end genera automaticamente controlli di ingresso e visualizzazioni di uscita 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 uscita 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.

Messaggio di errore della pagina web con "ERR_CONNECTION_REFUSED" che indica un problema di connessione al server locale.
Figura 13: Accesso dal 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 locale Caddy 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 locale Caddy 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.

Interfaccia di simulazione di un ventilatore virtuale con logo dell'università su una pala del ventilatore in rotazione.
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. Questa schermata della console del browser è stata acquisita 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.

Interfaccia utente virtuale di controllo del ventilatore con monitoraggio RPM; diagramma dell'allestimento del modello del ventilatore; analisi dei dati di rete.
Figura 15: Stato della comunicazione lato browser durante il funzionamento normale. Gli strumenti di sviluppo del browser mostrano un caricamento della pagina avvenuto con successo, 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.

Console di debug con log di rete e grafico dell'utilizzo delle risorse per l'analisi di programmi LabVIEW.
Figura 16: Osservazione rappresentativa singola della console del browser e dell'utilizzo delle risorse a livello di processo per l'esperimento sul ventilatore. Lo screenshot è stato registrato durante un test locale dell'esperimento sul ventilatore. La console mostra il tempo delle richieste/risposte 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 di sviluppo 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 impiegato 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.

Confronto dell'interfaccia utente di controllo del ventilatore; valori di RPM, corrente e potenza collegati nel diagramma dell'interfaccia desktop e mobile.
Figura 17: Accesso contemporaneo 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 visualizzano 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 testing locale degli autori. Non sono inclusi dati utente di terze parti né informazioni riservate. Cliccare qui per visualizzare una versione ingrandita di questa figura.

Nome della variabileTipo di datoIngresso/UscitaSignificato fisicoRuolo nel modelloIntervallo/Impostazione
EnableBooleanIngressoInterruttore di accensione del ventilatoreControlla se il modello riceve l'ingresso PWM. Quando è True, u = PWM; quando è False, u = 0.True / False
PWMDBLIngressoIngresso di comandoDetermina l'intensità base del comando del ventilatore ed è l'ingresso principale utilizzato per calcolare la velocità a regime SteadyRPM.0-1, passo 0.01
LoadDBLIngressoCoefficiente di caricoDescrive l'effetto riduttivo del carico sulla velocità a regime. Aumentando il carico, la velocità a regime diminuisce.0-1, passo 0.01
TauDBLIngressoCostante di tempo di rispostaDetermina con quale rapidità la velocità del ventilatore si avvicina alla velocità a regime partendo dallo stato precedente.0,1-5, passo 0,1
KMaxRPMDBLIngressoVelocità massimaImposta la velocità massima consentita dal modello ed è utilizzata per limitare la velocità e per la normalizzazione.500-6000, passo 100
DisturbanceDBLIngressoIngresso di disturboRappresenta 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
SpeedRPMDBLUscitaVelocità effettivaRappresenta la velocità attuale in uscita dal ventilatore ed è aggiornata attraverso dinamiche inerziali del primo ordine.Calcolata dal modello
SteadyRPMDBLUscitaVelocità a regimeRappresenta la velocità teorica a regime sotto le attuali condizioni di ingresso.Calcolata dal modello
TimeSDBLUscitaTempo di esecuzioneRappresenta il tempo continuativo di funzionamento del modello.Calcolata dal modello
SpeedNormDBLUscitaVelocità normalizzataRappresenta il rapporto tra SpeedRPM e KMaxRPM.0-1 oppure calcolata dal modello
CurrentADBLUscitaCorrenteRappresenta la corrente stimata dal modello, che varia in base all'ingresso di comando e all'ingresso di disturbo.Calcolata dal modello
PowerWDBLUscitaPotenzaRappresenta la potenza stimata dal modello, calcolata a partire dalla costante di tensione e dalla corrente.Calcolata dal modello
SetpointDBLIngressoPosizione desiderataImposta la posizione che il motore deve raggiungere e forma l'errore e insieme alla posizione effettiva Position.-3-3, passo 0,1
KcDBLIngressoGuadagno proporzionaleRegola l'intensità di risposta del controllore PID all'errore.0-10, passo 0,1
TiDBLIngressoTempo integraleRegola l'azione integrale del controllore PID ed è utilizzato per ridurre l'errore a regime.0-10, passo 0,1
TdDBLIngressoTempo derivativoRegola l'azione derivativa del controllore PID ed è utilizzato per sopprimere variazioni troppo rapide dell'errore e migliorare la risposta dinamica.0-5, passo 0,1
DisturbanceDBLIngressoIngresso di disturboRappresenta 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 controlBooleanIngressoControllo di resetAttiva la cancellazione dello stato del modello in modo che posizione, velocità angolare, corrente, errore e termine integrale tornino ai loro stati iniziali.True / False
PositionDBLUscitaPosizione effettivaRappresenta la posizione angolare corrente del motore e funge da variabile di retroazione per il controllo PID.Calcolata dal modello
VoltageDBLUscitaTensione di controlloRappresenta l'uscita del controllore PID dopo il limitamento della tensione ed agisce sull'ingresso del motore.Calcolata dal modello; limitata tra -24 e 24 V
TimeDBLUscitaTempo di esecuzioneRappresenta il tempo continuativo di funzionamento del modello del motore.Calcolata dal modello
Measured angular velocityDBLUscitaVelocità angolare misurataRappresenta la velocità angolare corrente 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, il campo raccomandato e l'incremento.

ParametroValoreSignificato fisicoRuolo nel modello
R1Resistenza dell'avvolgimentoRappresenta il termine resistivo nel circuito dell'avvolgimento del motore e determina la caduta di tensione R × im nell'equazione della corrente.
L0,5Induttanza dell'avvolgimentoRappresenta l'induttanza del circuito dell'avvolgimento e determina il tasso di variazione della corrente. Un valore maggiore di L produce una risposta di corrente più lenta.
J0,01Momento d'inerziaRappresenta la resistenza del rotore del motore alle variazioni di accelerazione angolare e determina la rapidità con cui cambia la velocità angolare.
b0,1Coefficiente di smorzamento viscosoRappresenta lo smorzamento meccanico e descrive la coppia smorzante che ostacola l'aumento della velocità angolare durante la rotazione.
Kt0,01Costante di coppiaRappresenta il coefficiente di proporzionalità che converte la corrente nell'avvolgimento in coppia elettromagnetica.
Ke0,01Costante della forza elettromotrice inversaRappresenta il coefficiente di proporzionalità con cui la velocità angolare genera la forza elettromotrice inversa e descrive l'effetto di retroazione della velocità sulla corrente.
Vmax24Tensione di controllo massimaRappresenta il limite della tensione in uscita dal controllore e mantiene la tensione nell'intervallo compreso tra -24 V e 24 V.
dt0,001Passo di simulazione discretoRappresenta l'intervallo temporale per ciascun aggiornamento dello stato basato su ciclo e viene 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 le funzioni all'interno del modello.

File di codice supplementari: file completi di sorgente e configurazione per riprodurre gli esempi del ventilatore e del motore in corrente continua. I file di codice supplementari includono il codice LabVIEW Formula Node, 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 Formula Node 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 LabVIEW per gli esperimenti con il ventilatore e il motore.Fare clic qui per scaricare il 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à numeriche10,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 fisici9,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 utenti13,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 compatibili8,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.

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.

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.

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.