Methodenartikel

Een protocol voor de automatische generatie van webgebaseerde interfaces voor LabVIEW-applicaties met behulp van het Remote Interoperability Protocol

158 weergaven

⸱

DOI:

10.3791/72765

⸱

14 augustus 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 dit artikel

Samenvatting

Deze studie valideert een automatische generatie van een webgebruikersinterface op basis van een remote interoperability protocol (RIP) met twee verschillende LabVIEW-systemen — een ventilatormodel en een positie-regelmodel voor een gelijkstroommotor — en biedt een reproduceerbare procedure voor het construeren, registreren, implementeren en testen van beide voorbeelden.

Samenvatting

Remote experimentele platforms maken het mogelijk om lokale simulatiemodellen of fysieke apparaten via een netwerk te benaderen, maar conventionele web-front-ends vereisen doorgaans een aparte pagina, een lay-out van de bedieningselementen en een logica voor datacommunicatie voor elk experiment, wat de ontwikkelingskosten verhoogt. Dit werk valideert een vastgestelde workflow voor het automatisch genereren van een web-gebruikersinterface (UI) vanuit LabVIEW-virtuele instrumenten (VI's) met behulp van het remote interoperability protocol (RIP) en biedt een reproduceerbaar protocol voor de implementatie hiervan. De workflow construeert LabVIEW-VI's die invoerregelaars en uitvogeindicatoren op het Front Panel definiëren, registreert elke VI in de RIP Server Configuration, leest de resulterende variabele-metadata uit en genereert de overeenkomstige web-bedieningselementen en outputschermen. Caddy wordt gebruikt als reverse proxy om het pad van de statische bestanden van de front-end en het aanvraagpad van de RIP-application programming interface (API) te verenigen. De workflow wordt geëvalueerd met twee verschillende systemen: een ventilator-snelheidsmodel en een proportional-integral-derivative (PID) positie-regelmodel voor een gelijkstroommotor (DC-motor). In beide gevallen identificeert de webpagina de blootgestelde variabelen, schrijft gebruikersinvoeren naar de LabVIEW-back-end, leest modeloutputs uit en genereert de interface op basis van RIP-metadata. Deze resultaten valideren hetzelfde automatische UI-generatieproces over twee verschillende dynamische systemen en documenteren de stappen die nodig zijn om dit te reproduceren.

Inleiding

Met de ontwikkeling van experimenten op afstand, online onderwijs en Internet-of-Things-technologieën is het bieden van webgebaseerde toegang tot lokale simulatiemodellen of experimentele apparatuur een belangrijke richting geworden voor de ontwikkeling van experimentele platforms1,2,3,4. Recent werk heeft laboratoria die zijn uitgerust met Internet-of-Things verder geïntegreerd met projectgebaseerd leren en lokale of remote toegang, wat de voortdurende ontwikkeling van flexibele en genetwerkte experimentele platforms in het technisch onderwijs aantoont5. Voor experimenten met controlesystemen moeten gebruikers doorgaans invoerparameters in een browser aanpassen en outputtoestanden in real-time observeren6,7. Conventionele methoden vereisen doorgaans een aparte webpagina, aansturingslogica en een datacommunicatie-interface voor elk experimenteel object8,9. Wanneer de variabelen in het back-endmodel wijzigen, moet de front-endpagina vaak dienovereenkomstig worden aangepast, wat leidt tot aanzienlijk herhalend ontwikkelingswerk en de snelle uitbreiding van het experimentele platform beperkt.

Het Remote Interoperability Protocol (RIP) biedt een middleware-laag tussen back-end experimentele modellen en Web front-ends10,11. In de op RIP gebaseerde benadering voor automatische UI-generatie, zoals beschreven in eerder werk, levert de RIP-server metadata voor elk experiment, inclusief variabelenamen, input/output-attributen, datatypen, minimumwaarden, maximumwaarden, precisie, beschrijvingen en de beschikbare lees- en schrijfmethode11. Een Web-client kan deze metadata vervolgens gebruiken om tijdens het laden of vernieuwen van de pagina de overeenkomstige HTML-elementen te creëren, zoals labels, numerieke invoervelden, schuifregelaars, Booleaanse bedieningselementen en output-displays11. Het huidige protocol implementeert of definieert de RIP-specificatie niet opnieuw. In plaats daarvan gebruikt het de bestaande open-source RIP-service en de op RIP gebaseerde logica voor metadata-naar-HTML UI-generatie als basis voor communicatie en interfacegeneratie, en richt het zich op de reproduceerbare constructie, registratie, proxy-implementatie en verificatie van twee LabVIEW VI-voorbeelden.

In vergelijking met de conventionele ontwikkeling van op maat gemaakte webinterfaces, vermindert de op RIP gebaseerde automatische generatie van de gebruikersinterface (UI) de noodzaak om control-layouts, variabele-bindingslogica en basiscommunicatiefuncties te implementeren wanneer meerdere LabVIEW-experimenten vergelijkbare scalaire invoer- en uitvoervariabelen vertonen8,9,10,11. Nadat een nieuwe VI is geregistreerd en de variabelen beschikbaar zijn voor de RIP-server, kan dezelfde logica voor het lezen van metadata en het genereren van controls worden hergebruikt om de basis-webinterface te construeren10,11. Deze functie is nuttig voor snelle implementatie, demonstraties in het onderwijs en remote-laboratory-platforms die consistente toegang vereisen tot verschillende soortgelijke experimenten3,8,9. De automatisch gegenereerde interface kent echter ook beperkingen. De fysieke relaties tussen variabelen worden niet volledig afgeleid, grafiekkoppelingen worden niet automatisch bepaald en domeinspecifieke visualisaties en veiligheidsinteracties worden niet ontworpen11. Daarom blijft handmatige ontwikkeling van de webinterface bij voorkeur worden toegepast wanneer een experiment sterk aangepaste graphics, complexe gebruikersworkflows, geavanceerde visualisatie, hardwarematige veiligheidsinterlocks of schrijfarbitrage voor meerdere gebruikers vereist.

De algemene workflow van het protocol is samengevat in Figuur 1. In deze workflow definieert een LabVIEW VI eerst de vereiste invoerregelaars en uitvogeindicatoren op het Front Panel. De VI wordt vervolgens geregistreerd in de RIP Server Configuration door de experimentnaam en het VI-pad op te geven. Na registratie leest de RIP Server de metadata van het geselecteerde experiment en biedt lees-/schrijftoegang tot de beschikbare variabelen. De XHTML-webpagina gebruikt de teruggeleverde metadata om automatisch de bijbehorende invoerregelaars en uitvoerschermen te genereren, terwijl Caddy een uniform toegangspad biedt voor de statische webpagina en de RIP-communicatieroutes. De modellen van de ventilator en de gelijkstroommotor worden in deze studie gebruikt als twee implementaties van dezelfde workflow. Voor andere LabVIEW-experimenten die compatibele scalaire, numerieke en Booleaanse variabelen bieden, kunnen ontwikkelaars dezelfde workflow van bouwen-registreren-implementeren-verifiëren volgen om een automatisch gegenereerde webinterface te maken, waarbij indien nodig experimentspecifieke visualisatie, veiligheidslogica of complexe gegevensverwerking kan worden toegevoegd.

Dit artikel stelt geen nieuwe RIP-architectuur voor en breidt het bereik van de door RIP ondersteunde datatype niet uit. In plaats daarvan wordt RIP gebruikt als het gevestigde mechanisme voor communicatie en metadata-gebaseerde UI-generatie, waarbij de focus ligt op het valideren van dit proces met twee verschillende LabVIEW-systemen, terwijl een reproduceerbaar implementatieprotocol wordt gedocumenteerd. In eerder werk is een basismethode gepresenteerd voor automatische Web UI-generatie op basis van RIP-metadata, waarbij een online servomotorexperiment als casestudy is gebruikt11. Architecturen voor remote laboratoria met webondersteuning, die interactieve interfaces combineren met engineeringsoftware en LabVIEW, zijn ook beschreven in eerdere studies9,12. Tijdens praktische reproductie bleken sommige LabVIEW-modellen in de oorspronkelijke casus echter beïnvloed door softwareversies en modulecompatibiliteit, waardoor ze moeilijk direct te gebruiken waren in een nieuwere omgeving. In het huidige werk worden daarom twee compatibele back-end VIs gereconstrueerd — een ventilatormodel en een proportional-integral-derivative (PID) positie-regelmodel voor een gelijkstroom- (DC) motor — waarbij hetzelfde metadata-gestuurde UI-generatieproces op beide wordt toegepast. De bijdrage bestaat uit de cross-systeemvalidatie van de gevestigde RIP-workflow en een gedetailleerd protocol voor het reproduceren van dit proces, in plaats van een uitbreiding van de generaliteit van RIP.

De beoogde gebruikers van dit protocol zijn onderzoekers, instructeurs en laboratoriumontwikkelaars die reeds LabVIEW VI's gebruiken en simulatiemodellen of experimentele systemen met een laag risico via een webbrowser toegankelijk willen maken, zonder voor elk model onafhankelijk een volledige, op maat gemaakte front-end te implementeren. Het protocol is bijzonder geschikt voor experimenten die gebruikmaken van standaard numerieke en Booleaanse variabelen, parameterinstellingen en real-time statusbewaking10,11. Het is minder geschikt als stand-alone oplossing voor experimenten die complexe datastructuren, gespecialiseerde visualisatie, strikte hardwarematige veiligheidsinterlocks of schrijfarbitrage voor meerdere gebruikers vereisen11. Het doel van dit werk is om RIP-gebaseerde automatische Web UI-generatie te valideren met twee verschillende LabVIEW-systemen en om een volledig, reproduceerbaar protocol te bieden, van de constructie van de back-end VI tot de browsergebaseerde interactie. Het protocol omvat de definitie van in- en uitgangsvariabelen, de registratie van het experiment in de RIP-server, metadata-gebaseerde UI-generatie, de implementatie van de Caddy-proxy en de verificatie van op afstand lezen/schrijven. Door dezelfde workflow toe te passen op de ventilator- en DC-motormodellen wordt aangetoond dat het vastgestelde proces gereproduceerd kan worden zonder voor elk voorbeeld handmatig een volledige Web front-end te herschrijven9,10,11.

Protocol

Voltooi de volgende stappen om twee RIP-toegankelijke LabVIEW-experimenten te bouwen, te registreren, te implementeren en te verifiëren volgens de workflow die is samengevat in Figuur 1Alle instrumenten en platforms die in deze studie zijn gebruikt, staan vermeld in de Tabel met materialen.

1. Bouw en implementeer het experiment met het ventilatormodel

  1. Bouw het ventilatormodel VI.
    1. Open LabVIEW, maak een nieuwe VI aan en sla het bestand op als fengshan.vi. Sla de VI op in een willekeurige directory die toegankelijk is voor het RIP WebService-proces. De map Private wordt alleen als voorbeeldmap gebruikt en is niet hardcoded in RIP. Voer het daadwerkelijk geselecteerde VI-pad in tijdens de registratie van het RIP-experiment.
    2. Voeg op het voorpaneel de ingangssturingen voor het ventilatormodel toe. Geef in dit voorbeeld de ingangssturingen een naam Inschakelen, PWM, Belasting, Tau, KMaxRPM, en VerstoringStel in Inschakelen als booleaanse controle, en stel PWM, Belasting, Tau, KMaxRPMen Verstoring als numerieke regelaars met dubbele precisie drijvende-kommapuntgetallen (DBL). Zie Aanvullende tabel 1 voor de fysische betekenis en de rol binnen het model van de ventilatorvariabelen.
    3. Voeg de outputindicatoren voor het ventilatormodel toe. Benoem in dit voorbeeld de outputindicatoren SnelheidRPM, ConstanteRPM, TijdS, SnelheidNorm, StroomA, en PowerWStel alle output-indicatoren in als DBL-indicatoren.
      ​OPMERKING: Tabel 1 beschrijft de fysieke betekenis en de rol in het model van deze outputvariabelen. Het voltooide voorpaneel van de ventilator wordt getoond in Figuur 2De variabelenamen, bereiken en stapgroottes die worden weergegeven in Tabel 1 beschrijf de twee voorbeelden die in dit protocol zijn geïmplementeerd. Deze zijn geen hardgecodeerde vereisten van RIP. Voor andere LabVIEW-experimenten kunnen ontwikkelaars verschillende variabelenamen en numerieke eigenschappen voor het Front Panel definiëren. De RIP-server leest de feitelijke variabelenamen, datatypes, invoer/uitvoer-attributen en beschikbare numerieke eigenschappen uit de VI-metadata, waarna de webpagina de overeenkomstige bedieningselementen en weergaven genereert op basis van de teruggegeven metadata.
    4. Voeg een While-loop toe aan het blokdiagram. Voeg twee shift-registers toe om op te slaan snelheid_vorig en tijd_vorige, en initialiseer beide waarden naar 0.
    5. Voeg een Formuleknooppunt (Formula Node) toe binnen de While-loop. Verbind Inschakelen, PWM, Belasting, Tau, KMaxRPM, Verstoring, snelheid_vorig, en vorige_tijd naar de linker ingangsterminals van de Formula Node, en stel... in SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW, en volgende_tijd als de juiste uitgangsklemmen.
    6. Bouw de Inschakelen besturingslogica buiten de formulanode. Gebruik Inschakelen als selectorsignaal, zodat u = PWM wanneer Inschakelen is waar en u = 0 wanneer Inschakelen is onjuist.
    7. Voer de modelcode van de ventilator in de formulaknoop in. Gebruik deze code om de stationaire snelheid, de werkelijke snelheid, de genormaliseerde snelheid, de stroomsterkte, het vermogen en de looptijd te berekenen; raadpleeg Aanvullend Codebestand 1 voor de volledige code.
    8. Verbind de volgende_snelheid uitvoer van de Formule-node naar de Snelheid RPM indicator en verbinden volgende_snelheid terug naar het juiste schuifregister voor snelheid_vorigVerbind SteadyRPM naar de SteadyRPM indicator
    9. Verbinden volgende_tijd naar de TimeS indicator, en verbinden volgende_tijd terug naar het juiste verschuifregister voor vorige_tijdVerbind SpeedNorm, CurrentA, en PowerW naar de overeenkomstige output-indicatoren.
    10. Voeg een Wait-functie toe binnen de While-loop en stel de wachttijd in op 50 ms. Voeg een Stop Local-knop toe en verbind deze met de conditionele terminal van de While-loop.
    11. Sla fengshan.vi op. Het voltooide blokdiagram van de ventilator wordt getoond in Figuur 3.
      PAUSEERPUCKT: Na het opslaan van de voltooide fan VI kan de workflow worden gestopt. Hervat dit later door de opgeslagen VI opnieuw te openen en te bevestigen dat alle bedieningselementen, indicatoren en Block Diagram-verbindingen op het Front Panel nog steeds aanwezig zijn.
  2. Registreer het ventilator-experiment in de RIP-server.
    1. Open RIPWebService.lvproj in de LabVIEW Project Explorer
      .
    2. Open Configuration.vi vanuit de projectboom en zoek de configuratietabel voor het experiment.
    3. Voeg een nieuwe experimentrij toe. Stel de naam in op fan. Stel het volledige pad in naar het opgeslagen fengshan.vi-bestand. De registratievelden voor het fan-experiment worden getoond in Figuur 4.
    4. Vul de resterende configuratievelden in. Stel Authors in op de auteur van het experiment, Keywords op Fan, Description op fan speed model en Sampling Freq op 200.
    5. Selecteer in het LabVIEW-menu Bewerken > Huidige waarden als standaard instellen. Sla configuratie op.vi.
    6. Start de RIP WebService opnieuw op en bevestig dat het ventilatorexperiment nog steeds vermeld staat in de Configuratie-interface na het opnieuw opstarten.
      OPMERKING: De naam van het experiment is hoofdlettergevoelig. De waarde van fan in de RIP-configuratie moet exact overeenkomen met de experiment-ID die in het front-end XHTML-bestand wordt gebruikt. Om een andere LabVIEW VI te implementeren met dezelfde automatische UI-generatielogica, voegt u een nieuwe experimentinvoer toe in de RIP-configuratie, stelt u een nieuwe waarde in voor Name en stelt u Path in op het bijbehorende VI-bestand. Gebruik vervolgens dezelfde waarde voor Name als de experiment-ID in het XHTML-bestand. De front-endpagina hoeft niet voor elke variabele opnieuw te worden geschreven.
      ​PAUZEERPUCKT: Na het opslaan van Configuration.vi en het instellen van de huidige waarden als standaard, kan de workflow worden gestopt. Hervat dit later door de RIP WebService opnieuw te starten en te bevestigen dat het ventilator-experiment nog steeds is geregistreerd.
  3. Bereid de front-endpagina voor voor het ventilator-experiment.
    1. Plaats Fan_Automatic_UI.xhtml in de Client-directory die als front-end root-directory wordt gebruikt.
    2. Open Fan_Automatic_UI.xhtml met een teksteditor.
    3. Zoek de variabele voor de experiment-ID in de scriptsectie en stel deze in op fan.
      OPMERKING: Deze waarde moet exact overeenkomen met het veld 'Naam' van het waaierexperiment in de RIP-configuratie. De instellingen voor de experiment-ID en de gedeelde, op metadata gebaseerde logica voor de generatie van de gebruikersinterface voor de XHTML-front-endbestanden worden weergegeven in Figuur 5.
    4. Verifieer dat de pagina de huidige toegangsorigine verkrijgt via window.location.origin en experimentmetagegevens opvraagt via rip.info()en geeft de geretourneerde metadata door aan autobuildUI().
      OPMERKING: De pagina mag de variabelenamen, bereiken of stapgroottes van de ventilator niet handmatig hardcoden. In plaats daarvan worden beschrijfbare variabelen gegenereerd vanuit meta.beschrijfbare.lijst, leesbare variabelen worden gegenereerd uit meta.leesbare.lijsten numerieke attributen zoals min, max en stap worden verkregen uit de metadata die door de RIP-server worden teruggegeven.
    5. Sla Fan_Automatic_UI.xhtml op.
      ​OPMERKING: Om dezelfde logica voor de generatie van de front-end te gebruiken voor een andere LabVIEW VI, stelt u een nieuw experiment-ID in het XHTML-bestand in en registreert u de bijbehorende experimentnaam en het VI-pad in de RIP-configuratie. De webbesturingen en outputschermen worden gegenereerd op basis van de metadata die worden geretourneerd door het geselecteerde experiment.
  4. Configureer het toegangspad van de Caddy voor het ventilatorexperiment.
    1. Open het Caddyfile met een teksteditor.
    2. Stel de rootdirectory van de front-end in op de Client-directory die Fan_Automatic_UI.xhtml bevat.
    3. Selecteer een ongebruikte lokale poort voor Caddy om browser toegang te bieden tot de webpagina en RIP-routes. In dit protocol wordt poort 8090 als voorbeeld gebruikt voor de proxy-toegangspoort.
      OPMERKING: Poort 8090 is niet vereist door RIP of Caddy. Als poort 8090 bezet is, vervang deze dan door een andere ongebruikte lokale poort en gebruik dezelfde poort in het browseradres.
    4. Voeg een route toe die /fan herschrijft naar Fan_Automatic_UI.xhtml.
    5. Identificeer de RIP WebService-poort die in LabVIEW is geconfigureerd. In dit protocol wordt http://localhost:8001 gebruikt alsHet RIP WebService-adres.
      OPMERKING: Poort 8001 is de LabVIEW/RIP WebService back-end poort die in de testomgeving wordt gebruikt. Deze kan worden gewijzigd in de LabVIEW/RIP WebService-configuratie. Indien er een andere poort wordt gebruikt, vervang dan http://localhost:8001 in het Caddyfile door het bijbehorende RIP WebService-adres.
    6. Voeg een reverse proxy-regel toe die /RIP/SSE*-verzoeken doorstuurt naar het RIP WebService-adres, zoals http://localhost:8001.
    7. Voeg een reverse proxy-regel toe die /RIP*-verzoeken doorstuurt naar het adres van de RIP WebService, zoals http://localhost:8001. De Caddyfile-configuratie wordt getoond in Figuur 6.
    8. Open de opdrachtprompt op Windows. Ga naar de lokale download- of installatiemap van Caddy door het volgende commando in te voeren:
      cd /d D:\caddy
      OPMERKING: In dit protocol is D:\caddy het lokale download- of installatiepad van Caddy dat in de testomgeving wordt gebruikt. Als Caddy in een andere directory is opgeslagen, vervang D:\caddy dan door het overeenkomstige lokale pad.
    9. Start Caddy met het opgegeven Caddyfile door het volgende commando in te voeren:
      caddy.exe run --config Caddyfile
    10. Bevestig dat Caddy start zonder een configuratiefout te melden. Open http://localhost:8090/fan in een webbrowser en verifieer dat de fan web-UI wordt gegenereerd, zoals weergegeven in Figuur 7.
      ​OPMERKING: Als de browser een 502-fout geeft, controleer dan of de RIP WebService is gestart, of de RIP WebService-poort in LabVIEW overeenkomt met het reverse proxy-adres in het Caddyfile, en of de geselecteerde Caddy-toegangspoort niet bezet is.
  5. Verifieer de bedrijfsresultaten van het ventilatorexperiment.
    1. Verifieer dat de front-end pagina automatisch de Inschakelen, PWM, belasting, tau, KMaxRPM, en Verstoring inputcontroles
    2. Controleer of de front-endpagina de SnelheidRPM, ConstanteRPM, TijdS, SnelheidNorm, StroomA, en PowerW outputvariabelen
    3. Aanpassen PWM en observeer of Snelheid RPM neemt toe naarmate PWM neemt toe en afhankelijk van ... af PWM neemt af.
    4. Pas de belasting aan en observeer of SteadyRPM en SnelheidRPM nemen af naarmate de belasting toeneemt.
    5. Pas de verstoring aan en observeer of SnelheidRPM, StroomA, en PowerW verandering als reactie op de storingsinput.
    6. Verifieer dat TimeS blijft stijgen, wat bevestigt dat de back-end ventilator VI continu draait.

2. Opbouwen en implementeren van het experiment voor PID-positiebesturing van een DC-motor

  1. Bouw het VI-model voor de PID-positiebesturing van de DC-motor.
    1. Open LabVIEW, maak een nieuwe VI aan en sla het bestand op als Motor.vi. Sla de VI op in een willekeurige directory die toegankelijk is voor het RIP WebService-proces.
      OPMERKING: De map 'Private' wordt uitsluitend als voorbeeldmap gebruikt en is niet hardcoded in RIP. Voer het daadwerkelijk geselecteerde VI-pad in tijdens de registratie van het RIP-experiment.
    2. Voeg op het voorpaneel de ingangsregelaars toe voor het PID-positiecontrollmodel van de DC-motor. Geef de ingangsregelaars in dit voorbeeld de volgende namen Stelwaarde, Kc, Ti, Td, Verstoring, en ResetcontroleStel in Sinstelling, Kc, Ti, Td, en Verstoring als numerieke DBL-regelaars, en stel de Reset-regelaar in als een Booleaanse regelaar.
      OPMERKING: Tabel 1 beschrijft de fysieke betekenis, de rol in het model en het aanbevolen bereik van de variabelen die in dit voorbeeld worden gebruikt.
    3. Voeg de output-indicatoren toe voor het PID-positiebesturingsmodel van de DC-motor. Geef in dit voorbeeld de output-indicatoren een naam Positie, Spanning, Tijd, en Gemeten hoeksnelheidStel alle output-indicatoren in als DBL-indicatoren. Tabel 1 beschrijft de fysische betekenis en de rol in het model van deze uitgangsvariabelen. Het voltooide Front Panel voor de motor wordt getoond in Figuur 8.
      OPMERKING: De variabelenamen en bereiken die vermeld staan in Tabel 1 beschrijf de twee voorbeelden die in dit protocol zijn geïmplementeerd. Deze zijn geen vaste vereisten voor de RIP-gebaseerde workflow voor automatische UI-generatie. Wanneer een andere LabVIEW VI wordt gebruikt, leest RIP de feitelijke variabelenamen, datatypes, in- en uitvoerkenmerken en beschikbare numerieke eigenschappen uit de VI-metadata. Daarom is het niet nodig om de variabelenamen, maximumwaarden, minimumwaarden of stapgroottes voor elk experiment hardcoded in de logica voor de generatie van de front-end op te nemen.
    4. Voeg een While-loop toe aan het blokdiagram. Voeg zes verschuifregisters (Shift Registers) toe om op te slaan theta, omega, im, e_prev, integ, en tijd, en initialiseer alle zes waarden naar 0.
    5. Voeg een Formule-knooppunt (Formula Node) toe binnen de While-lus. Volgens het getoonde diagram van het PID-positiecontrolemodel voor de DC-motor in Figuur 9gebruik deze Formula Node als de centrale berekeningsmodule voor de foutberekening, PID-regeling, spanningsbegrenzing, het elektrische model, het mechanische model en de positie-update.
      OPMERKING: De interne motorparameters die in dit model worden gebruikt, zoals R, L, J, b, Kt, Ke, en Vmax, zijn genormaliseerde parameters van een onderwijmodel in plaats van gekalibreerde parameters van een specifieke fysieke motor. Ze zijn geselecteerd om een stabiele en observeerbare gesimuleerde respons te produceren onder de gekozen tijdstap en spanningslimiet, zodat de effecten van Instelwaarde, Kc, Ti, Td, en Verstoring kan duidelijk worden aangetoond tijdens de webgebaseerde bediening.
    6. Setten sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, verstoring, reset, en dt ade ingangsterminals van de Formula Node. Stel theta_volgende, omega_volgende, im_volgende, e_volgende, integ_volgende, en spanning als de uitgangsterminals van de Formula Node.
    7. Verbind de Instelwaarde controle op de sp ingangsterminal van de Formula Node. Verbind Kc, Ti, Td, en Storing naar de Kc, Ti, Td, en dverstoring iingangsterminals van de Formula Node, respectievelijk.
    8. Zet het Reset-besturingsbooleaanse signaal om in een numeriek signaal en verbind dit met de herstellen ingangsterminal van de Formula Node. Voer een reset van de status uit wanneer Hervoorstelt is niet gelijk aan 0, en voer PID-regeling en het bijwerken van de motorstatus uit wanneer herstellen is gelijk aan 0.
    9. Voeg de numerieke constante toe dt en stel de waarde hiervan in op 0,001 s. Verbind de dt naar de dt de invoerterminal van de Formula Node en gebruik deze voor het bijwerken van de tijd.
    10. Stel de interne modelparameters van de DC-motor in de Formula Node in. Zie Aanvullende Tabel 2 voor de fysieke betekenis en de modelrol van de motorvariabelen.
    11. Voer de PID-positiecontrolecode voor de DC-motor in de Formula Node in. Gebruik deze code om de resetlogica, foutberekening, berekening van de integraalterm, berekening van de afgeleideterm, PID-regeling, spanningsbegrenzing, stroombijwerking, hoeksnelheidsbijwerking en positiebijwerking te implementeren; zie de aanvullende codebestanden voor de volledige code.
    12. Verbinden theta_volgende naar de Positie indicator en verbinden theta_volgende terug naar het juiste schuifregister voor theta Verbinden omega_volgende naar de Indicator voor gemeten hoeksnelheid, en verbind omega_volgende terug naar het juiste schuifregister voor omega
    13. Sluit de spanning aan op de spanningsindicator. Sluit aan im_volgend, e_volgend, en integ_volgende terug naar de juiste schuifregisters voor im, e_prev, en integ, respectievelijk.
    14. Gebruik een Add-functie buiten de Formula Node om te berekenen tijd_volgende = tijd + dt. Verbinden volgende_tijd naar de Tijd indicator en verbinden volgende_tijd terug naar het juiste Shift Register voor de tijd.
    15. Voeg een Wait-functie toe binnen de While-lus en stel de wachttijd in op 1 ms. Voeg een Stop-knop toe en verbind deze met de conditionele terminal van de While-lus.
    16. Sla Motor.vi op. Het voltooide blokdiagram van de motor wordt getoond in Figuur 10.
      PAUZEPUNT: Na het opslaan van de voltooide motor-VI kan de workflow worden gestopt. Hervat het proces later door de opgeslagen VI opnieuw te openen en te controleren of alle bedieningselementen, indicatoren en Block Diagram-verbindingen op het Front Panel nog aanwezig zijn.
  2. Registreer het motorexperiment in de RIP Server.
    1. Open RIPWebService.lvproj in de LabVIEW Project Explorer.
    2. Open Configuration.vi vanuit de projectboom en zoek de tabel voor de experimentconfiguratie.
    3. Voeg een nieuwe experimentrij toe. Stel de Naam in op Motor. Stel het Pad in op het volledige pad van het opgeslagen Motor.vi-bestand. De registratievelden voor het motorexperiment worden getoond in Figuur 11.
    4. Vul de resterende configuratievelden in. Stel Auteurs in op de auteur van het experiment, Trefwoorden op Motor, Beschrijving op DC-motor positiebesturingsmodel en Bemonsteringsfreq op 200.
    5. Selecteer in het LabVIEW-menu Bewerken > Stel huidige waarden in als standaard. Sla configuratie op.vi.
    6. Herstart de RIP WebService en bevestig dat het Motor-experiment na het herstarten nog steeds wordt vermeld in de Configuratie-interface.
      OPMERKING: De experimentnaam is hoofdlettergevoelig. De waarde Motor in RIP Configuration moet exact overeenkomen met de experiment-ID die wordt gebruikt in Motor_Automatic_UI.xhtml. Om een andere LabVIEW VI te implementeren met dezelfde automatische UI-generatielogica, voegt u een nieuwe experimentvermelding toe in RIP Configuration, stelt u een nieuwe waarde in bij Name en stelt u Path in op het corresponderende VI-bestand. Gebruik vervolgens dezelfde waarde bij Name als de experiment-ID in het XHTML-bestand. De front-endpagina hoeft niet voor elke variabele opnieuw te worden geschreven.
      ​PAUSEERPUNT: Nadat Configuration.vi is opgeslagen en de huidige waarden als standaard zijn ingesteld, kan de workflow worden gestopt. Hervat dit later door de RIP WebService opnieuw te starten en te bevestigen dat het Motor-experiment nog steeds is geregistreerd.
  3. Bereid de voorpagina voor het motorexperiment voor.
    1. Plaats Motor_Automatic_UI.xhtml in de Client-directory die als front-end-worteldirectory wordt gebruikt.
    2. Open Motor_Automatic_UI.xhtml met een teksteditor.
    3. Zoek de variabele experiment ID in het scriptgedeelte en stel deze in op Motor. Deze waarde moet exact overeenkomen met het veld Name van het motor-experiment in de RIP-configuratie. De front-endpagina voor het motor-experiment maakt gebruik van dezelfde logica voor UI-generatie op basis van metadata als getoond in Figuur 5; alleen het experiment-ID is gewijzigd om overeen te komen met de Motor-vermelding in de RIP-configuratie.
    4. Verifieer of de pagina de logica voor het lezen van RIP-metagegevens, de logica voor het genereren van HTML-besturingselementen, de RIP-schrijffunctie en de functie voor het bijwerken van de output bevat.
      OPMERKING: De pagina mag de variabelenamen, bereiken of stapgroottes van de motoren niet handmatig hardcoderen. Deze eigenschappen worden verkregen uit de metadata die door de RIP-server worden teruggegeven, volgens het eerder beschreven RIP-gebaseerde mechanisme voor de generatie van metadata naar HTML.11.
    5. Sla Motor_Automatic_UI.xhtml op.
      ​OPMERKING: Om dezelfde logica voor de generatie van de front-end te gebruiken voor een andere LabVIEW VI, stelt u een nieuw experiment-ID in het XHTML-bestand in en registreert u de bijbehorende experimentnaam en het VI-pad in de RIP-configuratie. De webbesturingselementen en outputschermen worden gegenereerd op basis van de metadata die door het geselecteerde experiment worden teruggegeven.
  4. Configureer het toegangspad van de Caddy voor het motorexperiment.
    1. Open het Caddyfile met een teksteditor.
    2. Stel de rootdirectory van de front-end in op de Client-directory die Motor_Automatic_UI.xhtml bevat.
    3. Selecteer een ongebruikte lokale poort voor Caddy om browser toegang te bieden tot de webpagina en RIP-routes. In dit protocol wordt poort 8090 als voorbeeld gebruikt voor de proxy-toegangspoort.
      OPMERKING: Poort 8090 is niet vereist voor RIP of Caddy. Als poort 8090 bezet is, vervang deze dan door een andere ongebruikte lokale poort en gebruik dezelfde poort in het browseradres.
    4. Voeg een route toe die /motor herschrijft naar Motor_Automatic_UI.xhtml.
    5. Identificeer de RIP WebService-poort die in LabVIEW is geconfigureerd. In dit protocol wordt http://localhost:8001 gebruikt als het RIP WebService-adres.
      OPMERKING: Poort 8001 is de LabVIEW/RIP WebService back-end poort die in de testomgeving wordt gebruikt. Deze kan worden gewijzigd in de LabVIEW/RIP WebService-configuratie. Als er een andere poort wordt gebruikt, vervang dan http://localhost:8001 in het Caddyfile door het overeenkomstige RIP WebService-adres.
    6. Voeg een reverse proxy-regel toe die /RIP/SSE*-verzoeken doorstuurt naar het RIP WebService-adres, zoals http://localhost:8001.
    7. Voeg een reverse proxy-regel toe die /RIP*-verzoeken doorstuurt naar het adres van de RIP WebService, zoals http://localhost:8001. De configuratie van het Caddyfile is weergegeven in Figuur 6.
    8. Open de opdrachtprompt op Windows. Ga naar de lokale download- of installatiemap van Caddy door het volgende commando in te voeren:
      cd /d D:\caddy
      OPMERKING: In dit protocol is D:\caddy het lokale download- of installatiepad van Caddy dat in de testomgeving wordt gebruikt. Als Caddy in een andere directory is opgeslagen, vervang D:\caddy dan door het overeenkomstige lokale pad.
    9. Start Caddy met het opgegeven Caddyfile door het volgende commando in te voeren:
      caddy.exe run --config Caddyfile
    10. Bevestig dat Caddy start zonder een configuratiefout te rapporteren. Open http://localhost:8090/motor in een webbrowser en verifieer dat de webinterface van de motor wordt gegenereerd, zoals weergegeven in Figuur 12.
      ​OPMERKING: Als de webpagina van de motor wordt geladen maar de outputwaarden niet worden bijgewerkt, controleer dan of de RIP WebService is actief, of de motor VI wordt uitgevoerd, of de RIP WebService-poort in LabVIEW overeenkomt met het reverse proxy-adres in het Caddyfile en of de /RIP/SSE*-route correct is geproxy'd.
  5. Verifieer de bedrijfsresultaten van het motorexperiment.
    1. Verifieer dat de front-endpagina automatisch de Stelwaarde, Kc, Ti, Td, Verstoring, en Herstellen controle-inputcontroles.
    2. Controleer of de front-endpagina de volgende informatie weergeeft: Positie, Spanning, Tijd, en Gemeten hoeksnelheid uitgangsvariabelen
    3. Aanpassen Instelpunt en observeer of de positie reageert op de wijziging van de gewenste positie.
    4. Aanpassen Kc, Ti, en Td en observeer of Spanning, Positie, en Gemeten hoeksnelheid verandering
    5. Afstellen de verstoring en observeer of de positie, de stuurspanning of de gemeten hoeksnelheid wordt beïnvloed door de verstoring U heeft geen brontekst opgegeven om te vertalen. Voer aub de Engelse tekst in die u naar het Nederlands vertaald wilt hebben.
    6. Klik op Reset control en observeer of Positie, spanning, gemeten hoeksnelheid, en de bijbehorende interne toestanden keren terug naar hun begintoestanden volgens de resetlogica.

Resultaten

Nadat de hierboven beschreven werkvloei is voltooid, zijn zowel het ventilatorexperiment als het experiment voor PID-positieregeling van een gelijkstroommotor toegankelijk via de automatisch gegenereerde webinterface. Een succesvol resultaat wordt aangegeven door drie observaties. Ten eerste genereert de webpagina automatisch invoercontroles en uitvoerweergavevelden op basis van de variabele metagegevens die worden geretourneerd door de RIP-server. Ten tweede wordt, wanneer de gebruiker een invoervariabele op de webpagina wijzigt, de gewijzigde waarde via de RIP-interface naar de LabVIEW-back-end VI geschreven. Ten derde worden de door de back-end VI berekende uitvoervariabelen via RIP geretourneerd en in real-time vernieuwd op de webpagina. Voor het ventilatorexperiment genereert de pagina, na het invoeren van http://localhost:8090/fan in een browser, automatisch invoercontroles en uitvoervelden op basis van de RIP-metagegevens, zoals weergegeven in Figuur 7. De invoerkant bevat Enable, PWM, Load, Tau, KMaxRPM en Disturbance, terwijl de uitvoerkant SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA en PowerW weergeeft. Tijdens normale werking neemt TimeS continu toe, wat aangeeft dat de back-end fengshan.vi wordt uitgevoerd. Wanneer PWM wordt verhoogd, nemen SpeedRPM en SteadyRPM dienovereenkomstig toe. Wanneer Load wordt verhoogd, neemt de ventilatorsnelheid af, omdat de load de stationaire bedrijfssnelheid verlaagt. Wanneer Disturbance wordt aangepast, kunnen overeenkomstige veranderingen worden waargenomen in SpeedRPM, CurrentA en PowerW. Deze observaties bevestigen dat de invoer aan de webkant correct wordt overgedragen naar de LabVIEW-back-end en dat de berekende uitvoer via RIP wordt geretourneerd naar de front-end.

Voor het experiment van PID-positieregeling met een gelijkstroommotor, genereert de pagina na het invoeren van http://localhost:8090/motor in een browser automatisch de bijbehorende bedieningselementen en uitvoervelden op basis van de RIP-metadata, zoals weergegeven in Figuur 12. De ingangsvariabelen omvatten Stelpunt, Kc, Ti, Td, Storing en Reset-bediening, en de uitgangsvariabelen omvatten Positie, Voltage, Tijd en gemeten hoeksnelheid. Wanneer het Stelpunt wordt gewijzigd, reageert de Positie op de nieuwe doelwaarde. Wanneer de PID-parameters Kc, Ti en Td worden aangepast, veranderen de uitgangsrespons, het regelvoltage en de gemeten hoeksnelheid dienovereenkomstig, wat aangeeft dat de op de webpagina ingevoerde parameterwaarden correct worden geschreven naar het LabVIEW-back-endmodel en deelnemen aan de regelberekening. Wanneer de Reset-bediening wordt geactiveerd, keren de modelvariabelen terug naar hun beginwaarden volgens de resetlogica.

Fout- en communicatiestaten aan de browserzijde worden weergegeven in Figuur 13, Figuur 14, Figuur 15. Figuur 13 toont een mislukte browser-toegang waarbij Caddy niet actief is. De browser probeert toegang te krijgen tot http://localhost:8090/motor, maar toont een ERR_CONNECTION_REFUSED-bericht, wat aangeeft dat de lokale proxy-service niet beschikbaar is of niet luistert op de geselecteerde toegangspoort. Figuur 14 toont een mislukte RIP POST-communicatie na het laden van de pagina. In dit geval rapporteert de browserconsole een 502 Bad Gateway-fout voor het RIP POST-verzoek, wat betekent dat de front-end de proxyadres heeft bereikt, maar het verzoek niet succesvol kan worden doorgestuurd naar of verwerkt door de RIP WebService-back-end. In tegenstelling daarmee toont Figuur 15 een normale communicatiestatus aan de browserzijde. De ontwikkeltools van de browser tonen succesvol laden van de pagina, RIP POST-verzoeken en een actief SSE-verzoek met expId=fan, wat aangeeft dat de webfront-end communiceert met de RIP WebService via de Caddy-proxy en real-time updates ontvangt via het SSE-kanaal.

Samen tonen de succesvolle resultaten van ventilator en motor en de resultaten van de browserzijde-diagnostiek aan dat dezelfde op metadata gebaseerde werkwijze voor automatische UI-generatie kan worden gereproduceerd voor twee verschillende LabVIEW-experimenten. Deze resultaten bieden ook waarneembare criteria om succesvolle communicatie te onderscheiden van representatieve implementatieproblemen, terwijl de bijbehorende probleemoplossingsprocedures worden besproken in de discussiesectie.

LabVIEW VI naar Web UI-procesdiagram, met RIP-server en Caddy-proxy voor gegevenscommunicatie.
Figuur 1: Algemene structuur van het experimentele systeem. Het systeem bestaat uit de LabVIEW back-end VI, RIP-server, Caddy-proxy en een automatisch gegenereerde webgebruikersinterface. De LabVIEW VI levert modelvariabelen, de RIP-server leest metagegevens en variabele waarden uit de VI, Caddy standaardiseert het toegangspad en lost cross-origin toegang op, en de webgebruikersinterface genereert bedieningselementen automatisch. De naam en het logo van Caddy worden uitsluitend getoond om de gebruikte Caddy-webserver/proxy-component in de werkstroom te identificeren. Klik hier om een grotere versie van deze figuur te bekijken.

Diagram van het motorsysteem met toerentallijngrafiek, ingangsparameters en analyse van uitgangsgegevens.
Figuur 2: Voorkant van de ventilator VI. De voorkant bevat bedieningselementen voor Enable, PWM, Load, Tau, KMaxRPM en Disturbance, en indicatoren voor de uitgangswaarden SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA en PowerW. Deze schermafbeelding is gemaakt van de voorkant van fengshan.vi in LabVIEW 2026 in de eigen lokale experimentele omgeving van de auteurs. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Formulediagram met shiftregisters en while-lus voor RPM-regelprocesanalyse.
Figuur 3: Blokschema van de ventilator-VI. Het ventilatormodel is geïmplementeerd met een While-lus, shiftregisters, Enable-logica, een formuleknooppunt en uitgangsindicatoren. Deze schermafbeelding is gemaakt van het blokschema van fengshan.vi in LabVIEW 2026 in de eigen lokale experimentele omgeving van de auteurs. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze afbeelding te bekijken.

LabVIEW-interface met ventilatormodelopstelling, bemonsteringsinstellingen en camerapaden voor systeemmonitoring.
Figuur 4: Configuratiepagina van fan.vi. Het ventilator-experiment is geregistreerd in RIP-configuratie met de experimentnaam fan, het werkelijke VI-pad, trefwoordinformatie, beschrijving en bemonsteringsfrequentie. Deze schermafbeelding is gemaakt met de RIP-configuratie-interface in gebruik met LabVIEW 2026 en RIP WebService in de lokale experimentele omgeving van de auteurs. Geen gegevens van derden of vertrouwelijke informatie zijn opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

JavaScript-codefragmenten voor UI-logica van webapplicatie; methode voor dynamische elementcreatie.
Figuur 5: Instellingen voor experiment-ID en op metagegevens gebaseerde logica voor UI-generatie in de XHTML-frontendbestanden. De screenshots van de XHTML-code zijn gemaakt van Fan_Automatic_UI.xhtml en Motor_Automatic_UI.xhtml, geopend in Visual Studio Code. De pagina's voor ventilator en motor gebruiken dezelfde logica voor het lezen van metagegevens en het genereren van bedieningselementen; alleen de experiment-ID wordt gewijzigd om overeen te komen met het bijbehorende Naam-veld in de RIP-configuratie. De screenshots van de XHTML-code zijn gemaakt van Fan_Automatic_UI.xhtml en Motor_Automatic_UI.xhtml, geopend in Visual Studio Code in de lokale ontwikkelomgeving van de auteurs. De codebestanden zijn door de auteurs voor dit protocol voorbereid. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Configuratiediagram van Caddy-server met routes, reverse proxies en toegangspoortinstelling.
Figuur 6: Configuratie van Caddyfile. De Caddyfile definieert de lokale proxytoegangspoort, stelt de hoofdmap van de front-end in, herschrijft de routes /fan en /motor naar de overeenkomstige XHTML-bestanden en stuurt verzoeken naar /RIP/SSE* en /RIP* via een reverse proxy door naar de LabVIEW/RIP-webservicepoort. De schermafbeelding van de Caddyfile-configuratie is gemaakt vanuit de Caddyfile die geopend was in Visual Studio Code in de lokale ontwikkelomgeving van de auteurs. De Caddyfile is door de auteurs samengesteld om Caddy in te stellen als lokale webserver en reverse proxy. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Diagram van ventilatorbediensysteem met invoerschuifregelaars en uitgangsdisplays voor prestatieafstelling.
Figuur 7: Web UI-pagina van fan.vi. Deze schermafbeelding van de webinterface is gemaakt van de lokaal geïmplementeerde fan-webpagina van de auteurs met behulp van Mozilla Firefox. De front-endpagina genereert automatisch invoerbedieningen en uitgangsdisplays op basis van de variabele metagegevens die door de RIP-server worden geretourneerd. Deze schermafbeelding van de webinterface is gemaakt van de lokaal geïmplementeerde fan-webpagina van de auteurs met behulp van Mozilla Firefox. De weergegeven bedieningselementen en uitvoervelden zijn gegenereerd op basis van RIP-metagegevens in de lokale experimentele omgeving van de auteurs. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Diagram van PID-regelsysteem met motor, positie-terugkoppeling en dynamische responsgrafiek.
Figuur 8: Voorkantpaneel van de motor VI. Het voorkantpaneel bevat bedieningselementen voor Stelpunt, Kc, Ti, Td, Storing en Reset, en indicatoren voor Positie, Voltage, Tijd en Gemeten hoeksnelheid. Deze schermafbeelding is gemaakt van het voorkantpaneel van Motor.vi in LabVIEW 2026 in de eigen lokale experimentele omgeving van de auteurs. Er is geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze afbeelding te bekijken.

Blokdiagram van PID-regelaar met vergelijkingen; doorstroom van input-output over modellen voor systeemregeling.
Figuur 9: Blokdiagram van PID-positieregeling voor gelijkstroommotor. Het diagram toont het signaalpad van setpuntfout, PID-regeling, spanningsbegrenzing, superpositie van storingen, elektrische dynamiek, mechanische dynamiek en positie-updating naar terugkoppeling. Klik hier om een grotere versie van dit figuur te bekijken.

LabVIEW-diagram van regelsysteem met shiftregisters, formuleknooppunt in een while-lus, voor procesregeling.
Figuur 10: Blokdiagram van de motor VI. Het motor model is geïmplementeerd met een While-lus, Shiftregisters, een Formuleknooppunt, tijdslogica en uitgangsindicatoren. Deze schermafbeelding is gemaakt van het Blokdiagram van Motor.vi in LabVIEW 2026 in de eigen lokale experimentele omgeving van de auteurs. Geen gegevens van derden of vertrouwelijke informatie zijn opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

LabVIEW-motor modelinstellinginterface voor bemonsteringscontrole en configuratie in technische analyse.
Figuur 11: Configuratiescherm van Motor.vi. Het motorexperiment wordt geregistreerd in RIP-configuratie met de experimentnaam Motor, het werkelijke VI-pad, trefwoordinformatie, beschrijving en bemonsteringsfrequentie. Deze schermafbeelding is gemaakt met de RIP-configuratieinterface die wordt gebruikt met LabVIEW 2026 en RIP WebService in de eigen lokale experimentele omgeving van de auteurs. Geen gegevens van derden of vertrouwelijke informatie zijn opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Besturingssysteem van motor, interface voor PID-afstemming met invoerschuifregelaar en uitvoerdisplays, draaisnelheidsklok.
Figuur 12: Webgebruikersinterface van Motor.vi. De front-endpagina genereert automatisch bedieningselementen en uitvoerdisplays voor het experiment met PID-positieregeling van een gelijkstroommotor. Deze schermafbeelding van de webinterface is gemaakt vanaf de lokaal geïmplementeerde motorwebpagina van de auteurs, met behulp van Mozilla Firefox. De weergegeven bedieningselementen en uitvoervelden zijn gegenereerd op basis van RIP-metagegevens in de lokale experimentele omgeving van de auteurs. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Foutmelding op webpagina met "ERR_CONNECTION_REFUSED", wat wijst op een probleem met de verbinding met de lokale server.
Figuur 13: Mislukte browser toegang wanneer Caddy niet actief isWanneer Caddy niet is gestart, kan het geproxiede lokale adres http://localhost:8090/motor niet worden bereikt, en toont de browser een ERR_CONNECTION_REFUSED-bericht. Dit symptoom wijst erop dat de lokale Caddy-proxy-service niet beschikbaar is of niet luistert op de geselecteerde toegangspoort. Deze browserscreenshot is gemaakt met Mozilla Firefox in de lokale testomgeving van de auteurs en laat de mislukte toegangstoestand zien wanneer de lokale Caddy-proxy niet actief was. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze afbeelding te bekijken.

Virtuele ventilatorsimulatie-interface met universiteitslogo op een roterende ventilatorblad.
Figuur 14: RIP POST-communicatieprobleem na het laden van de pagina. In de browserconsole wordt een 502 Bad Gateway-fout weergegeven voor het RIP POST-verzoek. Dit resultaat geeft aan dat de webpagina de Caddy-proxyadres heeft bereikt, maar dat het verzoek niet succesvol kan worden doorgestuurd naar of verwerkt door het RIP-webserviceachtergrondproces. Deze schermafbeelding van de browserconsole is gemaakt met behulp van Mozilla Firefox Developer Tools in de lokale implementatieomgeving van de auteurs en toont een mislukte RIP POST-communicatie met fout 502 Bad Gateway. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Virtuele ventilatorbediening UI met toerentalmonitoring; diagram van ventilatormodelopstelling; netwerkgegevensanalyse.
Figuur 15: Communicatiestatus aan de browserzijde tijdens normale werking. De ontwikkelaargereedschappen van de browser tonen succesvolle paginalading, RIP POST-verzoeken en een actief SSE-verzoek met expId=fan. Deze verzoeken geven aan dat de webfrontend communiceert met de RIP-webservice via de Caddy-proxy en real-time updates ontvangt via het SSE-kanaal. Deze schermafbeelding van de browserontwikkelaargereedschappen is gemaakt met Mozilla Firefox in de lokale implementatieomgeving van de auteurs en toont normale RIP POST- en SSE-communicatie. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Debugconsole met netwerklogs en grafiek van resourcegebruik voor LabVIEW-programma-analyse.
Figuur 16: Eén representatieve browserconsole- en procesniveau-resourceobservatie voor het ventilatorexperiment. De screenshot is gemaakt tijdens een lokaal testexperiment met een ventilator. De console toont de aanvraag- en reactietijd van metadatavariabelen, het aantal metadatavariabelen, de tijd voor metadatabasede generatie van de gebruikersinterface, de tijd voor het openen van de SSE-verbinding en de ontvangen SSE-gegevens. De taakbeheerderweergave toont procesniveau-CPU- en geheugenwaarden voor de browser- en LabVIEW-processen op het moment van vastlegging. Deze waarden zijn beschrijvende observaties uit deze individuele test en geen gerepliceerde prestatiemetingen of een statistische benchmark. Deze screenshot is gemaakt met behulp van Mozilla Firefox Developer Tools en Windows Taakbeheer in de eigen lokale testomgeving van de auteurs. Mozilla Firefox werd gebruikt om de uitvoer van de browserconsole vast te leggen, en Windows Taakbeheer werd gebruikt om het CPU- en geheugenverbruik van de browser- en LabVIEW-processen te observeren. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze afbeelding te bekijken.

Vergelijking van de ventilatorbedieningsinterface; RPM-, stroom- en vermogenswaarden gekoppeld in diagram van desktop- en mobiele interface.
Figuur 17: Gelijktijdige toegang tot dezelfde op RIP gebaseerde webpagina vanaf een desktopbrowser en een mobiele browser. De webpagina voor het ventilatorexperiment is gelijktijdig geopend op een pc en mobiele apparaten, waarbij beide clients de automatisch gegenereerde bedieningselementen en uitvoervariabelen weergeven. De desktopwebpagina werd geopend met Mozilla Firefox en de mobiele webpagina met een mobiele browser binnen hetzelfde lokale netwerkomgeving. De schermafbeeldingen zijn gemaakt in de eigen lokale testomgeving van de auteurs. Geen gegevens van derden of vertrouwelijke informatie zijn opgenomen. Klik hier om een grotere versie van dit figuur te bekijken.

Naam van variabeleGegevenstypeInvoer/UitvoerFysieke betekenisRol in het modelBereik/Instelling
EnableBooleanInvoerSchakelaar voor ventilatorbedieningBepaalt of het model het PWM-signaal ontvangt. Indien Waar, u = PWM; indien Onwaar, u = 0.Waar / Onwaar
PWMDBLInvoerAandrijfingangBepaalt de basisintensiteit van de ventilatoraandrijving en is de belangrijkste ingang voor de berekening van het stationaire toerental SteadyRPM.0-1, stap 0,01
LoadDBLInvoerBelastingscoëfficiëntBeschrijft het verzwakkende effect van belasting op het stationaire toerental. Naarmate Load toeneemt, neemt het stationaire toerental af.0-1, stap 0,01
TauDBLInvoerTijdconstante van responsBepaalt hoe snel de ventilatorsnelheid het stationaire toerental bereikt vanuit de vorige toestand.0,1-5, stap 0,1
KMaxRPMDBLInvoerMaximaal toerentalStelt het maximaal toegestane toerental van het model in en wordt gebruikt voor snelheidsbegrenzing en normalisatie.500-6000, stap 100
DisturbanceDBLInvoerStooringsingangVertegenwoordigt het effect van externe storingen of belastingschommelingen op stationair toerental, stroom en vermogen.0-1, stap 0,1
SpeedRPMDBLUitvoerWerkelijke snelheidVertegenwoordigt de huidige uitvoersnelheid van de ventilator en wordt bijgewerkt via eerste-orde traagheidsdynamica.Berekend door het model
SteadyRPMDBLUitvoerStationaire snelheidVertegenwoordigt het theoretische stationaire toerental onder de huidige invoervoorwaarden.Berekend door het model
TimeSDBLUitvoerBedrijfstijdVertegenwoordigt de continue bedrijfstijd van het model.Berekend door het model
SpeedNormDBLUitvoerGenormaliseerde snelheidVertegenwoordigt de verhouding van SpeedRPM tot KMaxRPM.0-1 of berekend door het model
CurrentADBLUitvoerStroomVertegenwoordigt de geschatte modelstroom, die verandert met het aandrijfsignaal en het stooringsignaal.Berekend door het model
PowerWDBLUitvoerVermogenVertegenwoordigt het geschatte modelvermogen, berekend uit de spanningsconstante en stroom.Berekend door het model
SetpointDBLInvoerGewenste positieStelt de positie in die de motor moet bereiken en vormt de fout e met de werkelijke positie Position.-3-3, stap 0,1
KcDBLInvoerProportionele versterkingPast de responssterkte van de PID-regelaar aan de fout aan.0-10, stap 0,1
TiDBLInvoerIntegrale tijdPast de integrale actie van de PID-regelaar aan en wordt gebruikt om stationaire fout te verkleinen.0-10, stap 0,1
TdDBLInvoerAfgeleide tijdPast de afgeleide actie van de PID-regelaar aan en wordt gebruikt om te snelle foutveranderingen te onderdrukken en de dynamische respons te verbeteren.0-5, stap 0,1
DisturbanceDBLInvoerStooringsingangVertegenwoordigt een externe storing die wordt opgelegd aan de motoringang en samen met de regelspanning op het motor model inwerkt.0-10, stap 0,1
Reset controlBooleanInvoerResetregelingActiveert het wissen van de modeltoestand, zodat positie, hoeksnelheid, stroom, fout en integraalterm terugkeren naar hun beginwaarden.Waar / Onwaar
PositionDBLUitvoerWerkelijke positieVertegenwoordigt de huidige hoekpositie van de motor en dient als terugkoppelingsvariabele voor PID-regeling.Berekend door het model
VoltageDBLUitvoerRegelspanningVertegenwoordigt de uitgang van de PID-regelaar na spanningsbegrenzing en werkt op de motoringang.Berekend door het model; begrensd tot -24 tot 24 V
TimeDBLUitvoerBedrijfstijdVertegenwoordigt de continue bedrijfstijd van het motor model.Berekend door het model
Measured angular velocityDBLUitvoerGemeten hoeksnelheidVertegenwoordigt de huidige hoeksnelheid van de motor en is de mechanische toestandsuitgang van de motor.Berekend door het model

Tabel 1: Invoer- en uitvoervariabelen gebruikt in de ventilator- en gelijkstroommotorenvoorbeelden. De tabel vermeldt voor elke variabele de naam, datatypen, invoer-/uitvoerrol, fysica betekenis, aanbevolen bereik en stapgrootte.

ParameterWaardeFysische betekenisRol in het model
R1WekkerweerstandVertegenwoordigt de weerstandsterm in de motorwekkerkring en bepaalt de spanningsval R × im in de stroomvergelijking.
L0,5WekkerinductieVertegenwoordigt de inductie van de wekkerkring en bepaalt de stroomveranderingsnelheid. Een grotere L levert een trager stroomantwoord op.
J0,01MassatraagheidsmomentVertegenwoordigt de weerstand van de motorrotor tegen veranderingen in hoekversnelling en bepaalt hoe snel de hoeksnelheid verandert.
b0,1Viskeuze dempingscoëfficiëntVertegenwoordigt mechanische demping en beschrijft het dempend koppel dat de toename van hoeksnelheid tijdens rotatie belemmert.
Kt0,01KoppelconstanteVertegenwoordigt de evenredigheidscoëfficiënt die ankerstroom omzet in elektromagnetisch koppel.
Ke0,01Terugwerkende elektromotorische krachtconstanteVertegenwoordigt de evenredigheidscoëfficiënt waarmee hoeksnelheid een terugwerkende elektromotorische kracht genereert en beschrijft het terugkoppelend effect van snelheid op stroom.
Vmax24Maximale regelspanningVertegenwoordigt de limiet van de uitgangsspanning van de regelaar en houdt de spanning binnen het bereik van -24 V tot 24 V.
dt0,001Discrete simulatiestapVertegenwoordigt het tijdsinterval voor elke lusgebaseerde toestandsupdate en wordt gebruikt om stroom, hoeksnelheid, positie en looptijd bij te werken.

Tabel 2: Interne parameters gebruikt in het PID-positieregelmodel van de gelijkstroommotor. De tabel geeft de elektrische en mechanische parameters, symbolen, numerieke waarden, eenheden en hun rol in het model weer.

Supplementaire codebestanden: Volledige bron- en configuratiebestanden voor het reproduceren van de ventilator- en gelijkstroommotorvoorbeelden. De supplementaire codebestanden bevatten de LabVIEW Formula Node-code, Caddy reverse-proxyconfiguratie, XHTML front-endbestanden en LabVIEW VI-bronbestanden die in dit protocol zijn gebruikt. Code in LabVIEW Formula Node.docx bevat de Formula Node-code voor de PID-positieregelsystemen van de ventilator en de gelijkstroommotor. Caddyfile.txt bevat de configuratie voor de lokale webserver en de reverse-proxy. Fan_Automatic_UI.xhtml en Motor_Automatic_UI.xhtml bevatten de op metadata gebaseerde webfront-endlogica. fengshan.vi en Motor.vi zijn de LabVIEW back-end VI-bestanden voor de ventilator- en motorexperimenten.Klik hier om dit bestand te downloaden.

Discussie

Een kritische stap in dit protocol is de gestandaardiseerde constructie en registratie van de LabVIEW back-end VI. De regelaars en indicatoren op het Front Panel moeten duidelijke en unieke variabelenamen hebben, en hun datatypen moeten overeenkomen met de variabelen die worden verwacht door de modelberekening en door het RIP lees-/schrijfproces. In de twee voorbeelden die in dit protocol worden gebruikt, zijn scalaire numerieke variabelen gedefinieerd als DBL-regelaars of -indicatoren, en Booleaanse variabelen zijn gedefinieerd als Booleaanse regelaars. Het Block Diagram moet bovendien een continue statusupdate behouden via de While Loop, Shift Registers en Formula Node, zodat variabelen zoals ventilatorsnelheid, motorpositie, hoeksnelheid van de motor, spanning en tijd tijdens de uitvoering kunnen worden bijgewerkt. Nadat de VI is geconstrueerd, moet de experimentnaam in de RIP-configuratie exact overeenkomen met de experiment-ID die wordt gebruikt in het bijbehorende XHTML-bestand, en het VI-pad moet verwijzen naar de daadwerkelijk opgeslagen VI. Deze instellingen zijn belangrijk omdat de web-frontend de variabelen van elk experiment niet hardcodeert. In plaats daarvan is het afhankelijk van de metadata die door de RIP-server worden teruggegeven om beschrijfbare variabelen, leesbare variabelen, datatypen en numerieke eigenschappen te identificeren10,11.

De belangrijkste problemen bij het oplossen van storingen hebben betrekking op de consistentie tussen de XHTML-experiment-ID, de RIP-configuratie, de RIP-WebService en de Caddy-proxyinstellingen. Als de experiment-ID in het XHTML-bestand niet overeenkomt met de experimentnaam in de RIP-configuratie, kan de webpagina de juiste metadata niet opvragen en kunnen de verwachte bedieningselementen en uitvoervelden niet worden gegenereerd. Als het VI-pad onjuist is of de RIP-WebService niet is gestart, kan de webpagina mogelijk wel openen, maar kan deze niet communiceren met de LabVIEW-backend. Als Caddy niet draait, kan de browser het geselecteerde lokale proxyadres niet bereiken en kan er een ERR_CONNECTION_REFUSED-melding verschijnen, zoals weergegeven in Afbeelding 13. Als Caddy wel draait, maar het reverse-proxydoel niet overeenkomt met de poort van de RIP-WebService, kan de pagina wel laden terwijl RIP-POST-verzoeken mislukken met een 502 Bad Gateway-fout, zoals weergegeven in Afbeelding 14. Als de /RIP/SSE*-route niet correct werkt, kan de pagina openen en bedieningselementen tonen, maar worden de uitkomstwaarden niet in real-time bijgewerkt. Bij normaal gebruik moeten de ontwikkelaarstools van de browser een succesvol laden van de pagina, RIP-POST-verzoeken en een actieve SSE-aanvraag met de juiste experiment-ID tonen, zoals weergegeven in Afbeelding 15. Daarom moet het oplossen van storingen beginnen met het controleren van de experiment-ID, het VI-pad, de status van de RIP-WebService, de draaistatus van Caddy, de proxypoorten en de SSE-route. Als de communicatie nog steeds abnormaal verloopt, kan het opnieuw starten van zowel de RIP-WebService als Caddy, het wissen van de browsercache of het herhalen van de test in een andere browser helpen om browser-specifiek gedrag te onderscheiden van RIP/Caddy-configuratieproblemen.

Het huidige protocol is reproduceerbaar in de twee voorbeelden omdat dezelfde build-register-deploy-verify workflow wordt toegepast op zowel een ventilatorsnelheidsmodel als een DC-motor PID-positiebesturingsmodel. Om de afhankelijkheid van gespecialiseerde toolboxes te verminderen, zijn de back-end VI's gereconstrueerd met behulp van basis LabVIEW-structuren, waaronder Front Panel-bedieningselementen en indicatoren, While-loops, Shift Registers, Formula Nodes en standaard scalaire numerieke en Booleaanse variabelen. De reproduceerbaarheid over verschillende LabVIEW-versies, Windows-installaties en lokale netwerkomgevingen blijft echter afhankelijk van configuratiedetails zoals bestandspaden, toegangsrechten, lokale poorten, opstartcommando's voor services en browsergedrag. De workflow kan ook worden uitgebreid naar hardware-gerelateerde experimenten op afstand, maar de methode mag niet worden geïnterpreteerd als directe hardwareherkenning aan de webzijde. De web-frontend identificeert LabVIEW Front Panel-bedieningselementen en indicatoren via RIP-metadata. Daarom moeten sensoren, actuatoren, instrumenten of procesbesturingsapparaten eerst worden aangesloten en verwerkt in de LabVIEW back-end VI via geschikte hardware-drivers, data-acquisitemodules, instrumentbesturingsmodules of andere hardware-adaptatiemechanismen. Nadat de hardwaremetingen en besturingscommando's zijn gekoppeld aan Front Panel-indicatoren en bedieningselementen, kan de RIP-gebaseerde web-frontend deze variabelen herkennen op dezelfde manier als de simulatievariabelen die in dit protocol worden gebruikt. Eerdere studies naar LabVIEW-gebaseerde laboratoria op afstand hebben aangetoond dat LabVIEW kan worden gebruikt als back-end omgeving voor experimenten op afstand in de regeltechniek, robotica-experimenten, procesbesturingsopstellingen, sensor-data-acquisitie en interactie met fysieke apparaten9,12,17,18,19,20.

Figuur 16 toont een enkel representatief implementatievoorbeeld vastgelegd tijdens een lokaal ventilator-experiment. De front-end code was geïnstrumenteerd om de verzoeks-/responstijd van metadata, het aantal metadata-variabelen, de generatietijd van de metadata-gebaseerde gebruikersinterface (UI), de tijd voor het openen van de SSE-verbinding en de ontvangen SSE-gegevens te registreren. In dit voorbeeld rapporteerde de browserconsole een verzoeks-/responstijd voor metadata van 68,00 ms, identificeerde 7 schrijfbare variabelen en 7 leesbare variabelen uit de RIP-metadata, genereerde de overeenkomstige UI-elementen in 2,00 ms en opende de SSE-verbinding in 16,00 ms. De herhaalde SSE-gegevensvermeldingen lieten zien dat uitvoervariabelen zoals SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA en PowerW continu werden ontvangen van de LabVIEW back-end. De weergave van de taakbeheerder in dezelfde lokale testtoestand toonde ongeveer 1,5% CPU-gebruik en 391,7 MB geheugen voor het Firefox-proces, terwijl het LabVIEW-proces 0% CPU-gebruik en 9,2 MB geheugen vertoonde op het moment van vastlegging. Deze waarnemingen leveren basaal bewijs dat metadata-ophaling, metadata-gebaseerde UI-generatie, RIP/SSE-communicatie en CPU-overhead op procesniveau konden worden waargenomen in de lokale implementatieomgeving. Deze gegevens zijn echter bedoeld als verificatie op implementatieniveau en niet als een uitgebreide prestatiebenchmark. Een systematische prestatie-evaluatie met verschillende browsers, herhaalde tests, zwaardere variabelaste lasten, fysieke hardware en meerdere gelijktijdige gebruikers blijft noodzakelijk in toekomstig werk.

Deze methode kent ook beperkingen, vooral wanneer deze wordt uitgebreid naar complexe datastructuren, hardware-experimenten en multiuser-bediening. De huidige workflow is het meest geschikt voor scalaire numerieke en Booleaanse input-/outputvariabelen. Er is geen automatische, volledige ondersteuning voor complexe arrays, clusters, geneste datastructuren, grafiekrelaties of domeinspecifieke visualisaties. Deze gevallen kunnen aanvullende regels voor metadata-mapping of handmatig geschreven front-endcomponenten vereisen. De automatisch gegenereerde UI kan basisregelaars en displays creëren op basis van variabelenmetadata, maar kan de fysieke relatie tussen variabelen niet volledig afleiden, de meest geschikte visualisatie niet selecteren of experiment-specifieke veiligheidsinteracties ontwerpen. Wanneer de workflow wordt uitgebreid naar echte apparatuur, zijn aanvullende overwegingen vereist, waaronder hardware-drivers, apparaatkalibratie, bemonsteringsbeperkingen, actuatorlimieten, noodstoplogica, authenticatie en multiuser-schrijfbeveiligingsmechanismen. De huidige implementatie kan ook via standaard webbrowsers door meerdere clientapparaten in dezelfde lokale netwerkomgeving worden benaderd. Zoals getoond in Figuur 17, werd dezelfde pagina van het ventilator-experiment gelijktijdig geopend in een desktopbrowser en in een mobiele browser, waarbij beide clients de automatisch gegenereerde regelaars en de bijbehorende outputvariabelen weergaven. Deze waarneming wijst op basis gelijktijdige multi-clienttoegang voor het bekijken van en interageren met dezelfde experimentpagina. Dit mag echter niet worden geïnterpreteerd als een volledig multiuser-besturingsraamwerk, aangezien de huidige implementatie geen specifieke gebruikersauthenticatie, besturingsvergrendeling, arbitrage bij gelijktijdige schrijfacties, schrijfrijen of conflictresolutiemechanismen bevat. Deze beperkingen komen overeen met eerdere studies naar remote-laboratoria, waarin complexe of collaboratieve remote-laboratoria gewoonlijk experiment-specifiek interface-ontwerp, synchronisatiemechanismen, veiligheidsbeperkingen en gebruikersbeheerlogica vereisen13,14,15,16,17.

De methodologische waarde van dit protocol ligt niet in de introductie van een nieuwe RIP-architectuur of het uitbreiden van de door RIP ondersteunde datatypes. In plaats daarvan ligt de waarde in het bieden van een volledig en reproduceerbaar implementatiepad voor het toepassen van een gevestigd, op RIP gebaseerd mechanisme voor automatische UI-generatie op verschillende LabVIEW-systemen. In vergelijking met het schrijven van een aangepaste webinterface voor elk experiment, vermindert deze workflow de herhaalde implementatie van de basisindeling van de bediening, variabele koppeling en lees/schrijfcommunicatielogica wanneer de back-end VI compatibele variabelen ontsluit8,9,10,11. Het protocol is daarom nuttig voor technisch onderwijs, de ontwikkeling van remote-laboratoria en de snelle implementatie van simulatie- of onderwijsexperimenten met een laag risico die browsergebaseerde parameterinstellingen en real-time statusbewaking vereisen. Toekomstig werk zou de workflow moeten uitbreiden naar complexere datastructuren, fysieke experimentele apparaten, formele toegangscontrole voor meerdere gebruikers en kwantitatieve prestatie-evaluatie, inclusief de tijd voor interfacegeneratie, communicatielatentie, synchronisatiestabiliteit, serverbelasting, CPU-overhead en front-end bruikbaarheid.

Openbaarmakingen

De auteurs hebben AI-ondersteunde tools uitsluitend gebruikt voor het polijsten van de taal. Alle wetenschappelijke inhoud, experimentele procedures, software-implementaties, figuren, resultaten, interpretaties en de definitieve bewoording zijn door de auteurs gecontroleerd, gecorrigeerd en goedgekeurd. Er is geen AI-tool gebruikt voor het genereren van experimentele gegevens.

Dankbetuigingen

Dit werk werd ondersteund door de Undergraduate Training Programs for Innovation van de Wuhan University.

Materialen

Lijst van materialen gebruikt in dit artikel
NaamBedrijfCatalogusnummerOpmerkingen
Caddy Proxy ServerCaddyN/AReverse proxy gebruikt om de Web UI te serveren en /RIP-verzoeken door te sturen naar de RIP WebService
CaddyfileVoorbereid door de auteursN/ADefinieert static-file routes en reverse-proxy routes voor RIP-communicatie
Fan_Automatic_UI.xhtmlVoorbereid door de auteursN/AOp metadata gebaseerde Web front end voor het ventilator-experiment
LabVIEWNational Instruments2026Software gebruikt om fengshan.vi en Motor.vi te bouwen en uit te voeren
Microsoft Windows besturingssysteemMicrosoftWin11Besturingssysteem gebruikt om LabVIEW, RIP WebService, Caddy en de browser uit te voeren.
Motor_Automatic_UI.xhtmlVoorbereid door de auteursN/AOp metadata gebaseerde Web front end voor het motor-experiment
Mozilla Firefox desktopbrowserMozilla2026Desktopbrowser gebruikt voor toegang tot de Web UI, ontwikkelaarstools, timing-/resource-observaties en Network/Console-screenshots.
RIP WebServiceUNEDLabshttps://github.com/Nebulous-Systems/rip-server_labviewOntvangt RIP POST-verzoeken en biedt de WebService-communicatielaag die wordt gebruikt door de browser front end.
Windows TaakbeheerMicrosoftIngebouwd in WindowsGebruikt om CPU- en geheugenobservaties op procesniveau vast te leggen voor de browser- en LabVIEW-processen.

Referenties

  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.

Herprints en machtigingen

Tags

WebgebruikersinterfaceAutomatische UI generatieVirtuele InstrumentenRIP serverconfiguratieReverse ProxyCaddy ProxyPID positiecontroleVariabele Metadata

Dit artikel is gepubliceerd

Video binnenkort beschikbaar

Neem contact met ons op
Aanbevelen aan de bibliotheek

Privacy

Gebruiksvoorwaarden

Beleidsoverzicht

Copyright © 2026 MyJoVE Corporation. Alle rechten voorbehouden.