Methodenartikel

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

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Na voltooiing van de hierboven beschreven workflow kan zowel het ventilator-experiment als het DC-motor PID-positiecontrole-experiment worden benaderd via de automatisch gegenereerde web-frontend. Een succesvol resultaat wordt gekenmerkt door drie waarnemingen. Ten eerste genereert de webpagina automatisch invoerregelaars en uitvoerweergavevelden op basis van de variabelenmetadata die door de RIP-server worden teruggestuurd. Ten tweede, wanneer de gebruiker een invoervariabele op de webpagina wijzigt, wordt de gewijzigde waarde via de RIP-interface naar de LabVIEW back-end VI geschreven. Ten derde worden de uitvoervariabelen die door de back-end VI zijn berekend via RIP teruggestuurd en in realtime op de webpagina bijgewerkt. Voor het ventilator-experiment worden, na het invoeren van http://localhost:8090/fan in een browser, de invoerregelaars en uitvoervelden automatisch gegenereerd vanuit de RIP-metadata, 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 waarnemingen bevestigen dat de invoer aan de webzijde correct wordt overgebracht naar de LabVIEW back-end en dat de berekende uitvoeren via RIP naar de front-end worden teruggestuurd.

Voor het experiment met de PID-positiebesturing van de DC-motor genereert de pagina, na het invoeren van http://localhost:8090/motor in een browser, automatisch de overeenkomstige bedieningselementen en uitvoervelden vanuit de RIP-metagegevens, zoals weergegeven in Figuur 12. De invoervariabelen omvatten Setpoint, Kc, Ti, Td, Disturbance en de Reset-besturing, en de uitvoervariabelen omvatten Position, Voltage, Time en Measured angular velocity. Wanneer het Setpoint wordt gewijzigd, reageert de Position op de nieuwe doelwaarde. Wanneer de PID-parameters Kc, Ti en Td worden aangepast, veranderen de respons van de uitvoer, de besturingsspanning (voltage) en de measured angular velocity dienovereenkomstig, wat aangeeft dat de op de webpagina ingevoerde parameterwaarden correct naar het LabVIEW back-endmodel worden geschreven en deelnemen aan de besturingsberekening. Wanneer de Reset-besturing wordt geactiveerd, keren de modelvariabelen terug naar hun beginstaten volgens de reset-logica.

Fouten aan de browserzijde en communicatiestatussen worden weergegeven in Figuur 13, Figuur 14, Figuur 15. Figuur 13 toont een geval van mislukte browseraanroep waarin Caddy niet is opgestart. De browser probeert http://localhost:8090/motor te openen, maar vertoont een ERR_CONNECTION_REFUSED-melding, wat aangeeft dat de lokale proxyservice niet beschikbaar is of niet luistert op de geselecteerde toegangspoort. Figuur 14 toont een RIP POST-communicatiefout nadat de pagina is geladen. In dit geval rapporteert de browserconsole een 502 Bad Gateway-fout voor het RIP POST-verzoek, wat aangeeft dat de front-end het proxyadres heeft bereikt, maar dat het verzoek niet succesvol kan worden doorgestuurd naar, of verwerkt door, de RIP WebService back-end. In tegenstelling hiermee toont Figuur 15 een normale communicatiestatus aan de browserzijde. De ontwikkelaarstools van de browser tonen een succesvolle paginalading, RIP POST-verzoeken en een actief SSE-verzoek met expId=fan, wat aangeeft dat de Web front-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 de ventilator en de motor, evenals de diagnostische resultaten aan de browserzijde, aan dat dezelfde workflow voor automatische UI-generatie op basis van metadata kan worden gereproduceerd voor twee verschillende LabVIEW-experimenten. Deze resultaten bieden tevens waarneembare criteria om succesvolle communicatie te onderscheiden van representatieve implementatiefouten, terwijl de bijbehorende procedures voor probleemoplossing worden besproken in de sectie Discussie.

LabVIEW VI-diagram, RIP-server, Caddy-proxy; automatisch gegenereerde web-UI-processtroom.
Afbeelding 1: Algemene structuur van het experimentele systeem. Het systeem bestaat uit de LabVIEW back-end VI, RIP-server, Caddy-proxy en de automatisch gegenereerde web-UI. De LabVIEW VI levert modelvariabelen, de RIP-server leest VI-metadata en variabelenwaarden, Caddy uniformiseert het toegangspad en lost cross-origin-toegang op, en de web-UI genereert automatisch de bedieningselementen. De Caddy-naam en het logo worden uitsluitend getoond om de Caddy-webserver/proxy-component te identificeren die in de workflow wordt gebruikt. Klik hier om een grotere versie van deze afbeelding te bekijken.

Diagram van het motorbesturingssysteem met input/output; grafiek van SnelheidRPM; PWM, KMaxRPM instellingen; data-analyse.
Figuur 2: Front Panel van de ventilator VI. Het Front Panel bevat invoerregelaars voor Enable, PWM, Load, Tau, KMaxRPM en Disturbance, en uitvoerindicatoren voor SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA en PowerW. Deze screenshot is gemaakt van het Front Panel van fengshan.vi in LabVIEW 2026 in de eigen lokale experimentele omgeving van de auteurs. Er zijn geen gebruikersgegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Diagram van het motorbesturingsalgoritme met formulaknoop, while-lus en shift-registers voor snelheidsanalyse.
Figuur 3: Blokschema van de ventilator-VI. Het ventilatormodel is geïmplementeerd met een While Loop, Shift Registers, Enable-logica, een Formula Node en output-indicatoren. Deze screenshot 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 figuur te bekijken.

LabVIEW-configuratie-interface die de instellingen van het ventilatormodel en camerapaden voor databemonstering toont.
Figuur 4: Configuratiepagina van fan.vi. Het ventilator-experiment is geregistreerd in RIP Configuration met de experimentnaam fan, het werkelijke VI-pad, trefwoordinformatie, een beschrijving en de bemonsteringsfrequentie. Dit screenshot is gemaakt vanuit de RIP Configuration-interface die gebruikt is met LabVIEW 2026 en RIP WebService in de eigen lokale experimentele omgeving van de auteurs. Er zijn geen gebruikersgegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Codeblokdiagram dat de op metadata gebaseerde UI-logica in JavaScript voor datainitialisatie illustreert.
Figuur 5: Instellingen voor experiment-ID en op metadata gebaseerde UI-generatielogica in de XHTML front-end bestanden. De screenshots van de XHTML-code zijn gemaakt van Fan_Automatic_UI.xhtml en Motor_Automatic_UI.xhtml geopend in Visual Studio Code. De ventilator- en motorpagina's maken gebruik van dezelfde logica voor het lezen van metadata en het genereren van besturingen; alleen het experiment-ID is gewijzigd om overeen te komen met het bijbehorende veld 'Name' in de RIP Configuration. 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 eigen lokale ontwikkelomgeving van de auteurs. De codebestanden zijn door de auteurs voorbereid voor dit protocol. Er zijn geen gebruikersgegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Configuratiediagram van de Caddy-server met weergave van de reverse proxy, routeringspaden en details van de poortinstellingen.
Figuur 6: Caddyfile-configuratie. De Caddyfile definieert de lokale proxy-toegangspoort, stelt de rootmap van de front-end in, herschrijft de /fan- en /motor-routes naar de overeenkomstige XHTML-bestanden en fungeert als reverse proxy voor /RIP/SSE* en /RIP*-verzoeken naar de LabVIEW/RIP WebService-poort. Het screenshot van de Caddyfile-configuratie is gemaakt van de Caddyfile geopend in Visual Studio Code in de eigen lokale ontwikkelomgeving van de auteurs. De Caddyfile is door de auteurs opgesteld om Caddy te configureren als de lokale webserver en reverse proxy. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Simulatiediagram van ventilatorsnelheidsregeling; invoerschuifregelaars, uitgaveweergaven; analyse van mechanische systemen.
Figuur 7: Web UI-pagina van fan.vi. Deze screenshot van de webinterface is gemaakt van de lokaal geïmplementeerde ventilator-webpagina van de auteurs met behulp van Mozilla Firefox. De front-endpagina genereert automatisch invoerregelaars en uitgaveweergaven op basis van de variabelenmetadata die door de RIP-server worden teruggestuurd. Deze screenshot van de webinterface is gemaakt van de lokaal geïmplementeerde ventilator-webpagina van de auteurs met behulp van Mozilla Firefox. De weergegeven regelaars en uitgavevelden zijn gegenereerd vanuit RIP-metadata 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 deze figuur te bekijken.

Diagram van het PID-regelsysteem, terugkoppeling van de motorpositie, input-outputproces, meting van de hoeksnelheid.
Figuur 8: Front Panel van de motor VI. Het Front Panel bevat bedieningselementen voor Setpoint, Kc, Ti, Td, Disturbance en Reset, en indicatoren voor Position, Voltage, Time en Measured angular velocity. Deze screenshot is gemaakt van het Front Panel van Motor.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 figuur te bekijken.

PID-regelsysteemdiagram met vergelijkingen; spanningslimiet, elektrische en mechanische modellen.
Figuur 9: Diagram van het PID-positieregelsysteem voor een DC-motor. Het diagram toont het signaalpad van de afwijking van het ingestelde punt, PID-regeling, spanningsbegrenzing, superpositie van storingen, elektrische dynamica, mechanische dynamica en positie-update naar de feedback. Klik hier om een grotere versie van deze figuur te bekijken.

LabVIEW-programmadiagram waarin shift-registers, formuleknooppunt en regelkring voor positierugkoppeling worden geïllustreerd.
Figuur 10: Blokdiagram van de motor-VI. Het motormodel is geïmplementeerd met een While-loop, shift-registers, een formuleknooppunt, timinglogica en outputindicatoren. Dit screenshot is gemaakt van het blokdiagram van Motor.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 figuur te bekijken.

LabVIEW motor model interface, padinstelling voor simulatiebesturing, bemonsteringsconfiguratie, motorbeschrijving.
Figuur 11: Configuratiepagina van Motor.vi. Het motorexperiment is geregistreerd in RIP Configuration met de experimentnaam Motor, het feitelijke VI-pad, trefwoordinformatie, beschrijving en bemonsteringsfrequentie. Dit screenshot is gemaakt van de RIP Configuration-interface gebruikt met LabVIEW 2026 en RIP WebService 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 figuur te bekijken.

Simulatie van PID-regelsysteem; diagram inclusief invoerschuifregelaar en output-weergavemetrieken voor analyse.
Figuur 12: Web UI-pagina van Motor.vi. De front-end pagina genereert automatisch invoerregelaars en output-weergaven voor het experiment voor PID-positiebesturing van de DC-motor. Dit screenshot van de webinterface is vastgelegd vanaf de lokaal geïmplementeerde motor-webpagina van de auteurs met behulp van Mozilla Firefox. De weergegeven regelaars en outputvelden zijn gegenereerd vanuit RIP-metadata 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 deze figuur te bekijken.

Foutmelding van webpagina; localhost-verbinding geweigerd; opties voor probleemoplossing in de browser.
Figuur 13: Mislukte browsertoegang wanneer Caddy niet is gestart. Wanneer Caddy niet is gestart, kan het geproxiede lokale adres http://localhost:8090/motor niet worden bereikt en geeft de browser een ERR_CONNECTION_REFUSED-melding weer. Dit symptoom van falen geeft aan dat de lokale Caddy-proxyservice niet beschikbaar is of niet luistert op de geselecteerde toegangspoort. Deze screenshot van de browser is gemaakt met Mozilla Firefox in de eigen lokale testomgeving van de auteurs en toont de status van de mislukte toegang wanneer de lokale Caddy-proxy niet draaide. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Ontwerp van ventilator met universiteitsembleem; weergegeven in de context van een browserconsolefout.
Figuur 14: RIP POST communicatiefout na het laden van de pagina. De browserconsole toont een 502 Bad Gateway-fout voor het RIP POST-verzoek. Dit resultaat geeft aan dat de webpagina het Caddy proxy-adres heeft bereikt, maar dat het verzoek niet succesvol kan worden doorgestuurd naar, of verwerkt door, de RIP WebService back-end. Dit screenshot van de browserconsole is vastgelegd met Mozilla Firefox Developer Tools in de eigen lokale implementatieomgeving van de auteurs en toont een RIP POST 502 Bad Gateway communicatiefout. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

Virtuele ventilatorbediening-UI met snelheid- en vermogensparameters, die netwerkactiviteit toont; dashboarddiagram.
Figuur 15: Communicatiestatus aan de browserzijde onder normale werking. De ontwikkelaarstools van de browser tonen het succesvol laden van de pagina, RIP POST-verzoeken en een actief SSE-verzoek met expId=fan. Deze verzoeken geven aan dat de Web front-end communiceert met de RIP WebService via de Caddy-proxy en real-time updates ontvangt via het SSE-kanaal. Dit screenshot van de ontwikkelaarstools van de browser is vastgelegd met Mozilla Firefox in de eigen 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 deze figuur te bekijken.

Firefox-ontwikkelaarsconsole die netwerkverzoekfouten en de laadstatus van variabelen toont.
Figuur 16: Enkele representatieve browserconsole- en procesniveau-resource-observaties voor het ventilator-experiment. Het screenshot is vastgelegd tijdens een lokale test van het ventilator-experiment. De console toont de verzoek-/responstijd van metadata, het aantal metadata-variabelen, de tijd voor metadata-gebaseerde UI-generatie, de openingstijd van de SSE-verbinding en de ontvangen SSE-gegevens. De weergave van de taakbeheerder toont de CPU- en geheugenwaarden op procesniveau voor de browser- en LabVIEW-processen op het moment van vastlegging. Deze waarden zijn beschrijvende observaties van deze individuele test en zijn geen gerepliceerde prestatiemetingen of een statistische benchmark. Dit screenshot is gemaakt met Mozilla Firefox Developer Tools en Windows Taakbeheer in de eigen lokale testomgeving van de auteurs. Mozilla Firefox werd gebruikt om de output van de browserconsole vast te leggen, en Windows Taakbeheer werd gebruikt om het CPU- en geheugengebruik voor 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 figuur te bekijken.

Interface voor ventilatorbesturing; diagram van datasynchronisatie met SpeedRPM- en CurrentA-instellingen op de web- en mobiele UI.
Figuur 17: Gelijktijdige toegang tot dezelfde RIP-gebaseerde webpagina via een desktopbrowser en een mobiele browser. De pagina voor het ventilatorexperiment is gelijktijdig geopend op PC- en mobiele apparaten, waarbij beide clients de automatisch gegenereerde bedieningselementen en outputvariabelen weergeven. De desktop-webpagina werd benaderd via Mozilla Firefox, en de mobiele webpagina werd benaderd via een mobiele browser in dezelfde lokale netwerkomgeving. De screenshots zijn gemaakt vanuit de eigen lokale testomgeving van de auteurs. Er zijn geen gegevens van derden of vertrouwelijke informatie opgenomen. Klik hier om een grotere versie van deze figuur te bekijken.

VariabelnaamGegevenstypeInvoer/UitvoerFysische betekenisRol in het modelBereik/Instelling
EnableBooleanInvoerSchakelaar ventilatorbedrijfBepaalt of het model de PWM-invoer ontvangt. Wanneer True is u = PWM; wanneer False is u = 0.True / False
PWMDBLInvoerAansturingsinvoerBepaalt de basisintensiteit van de ventilatorenaansturing en is de belangrijkste invoer die wordt gebruikt om de stationaire snelheid SteadyRPM te berekenen.0-1, stap 0,01
LoadDBLInvoerBelastingscoëfficiëntBeschrijft het verzwakkende effect van de belasting op de stationaire snelheid. Naarmate Load toeneemt, neemt de stationaire snelheid af.0-1, stap 0,01
TauDBLInvoerTijdsconstante van de responsBepaalt hoe snel de ventilatorsnelheid vanuit de vorige toestand de stationaire snelheid benadert.0,1-5, stap 0,1
KMaxRPMDBLInvoerMaximumsnelheidStelt de maximumsnelheid in die door het model is toegestaan en wordt gebruikt voor snelheidsbegrenzing en normalisatie.500-6000, stap 100
DisturbanceDBLInvoerStorend signaalRepresenteert het effect van externe verstoringen of belastingsschommelingen op de stationaire snelheid, stroom en vermogen.0-1, stap 0,1
SpeedRPMDBLUitvoerActuele snelheidRepresenteert de huidige outputsnelheid van de ventilator en wordt bijgewerkt via traagheidsdynamiek van de eerste orde.Berekend door het model
SteadyRPMDBLUitvoerStationaire snelheidRepresenteert de theoretische stationaire snelheid onder de huidige invoercondities.Berekend door het model
TimeSDBLUitvoerLooptijdRepresenteert de continue looptijd van het model.Berekend door het model
SpeedNormDBLUitvoerGenormaliseerde snelheidRepresenteert de verhouding tussen SpeedRPM en KMaxRPM.0-1 of berekend door het model
CurrentADBLUitvoerStroomRepresenteert de geschatte modelstroom, die verandert met de aansturingsinvoer en de storende invoer.Berekend door het model
PowerWDBLUitvoerVermogenRepresenteert het geschatte modelvermogen, berekend uit de spanningsconstante en de stroom.Berekend door het model
SetpointDBLInvoerGewenste positieStelt de positie in die de motor moet bereiken en vormt samen met de actuele positie Position de fout e.-3-3, stap 0,1
KcDBLInvoerProportionele versterkingPast de responssterkte van de PID-regelaar op de fout aan.0-10, stap 0,1
TiDBLInvoerIntegraaltijdPast de integraalwerking van de PID-regelaar aan en wordt gebruikt om de stationaire fout te verminderen.0-10, stap 0,1
TdDBLInvoerDifferentiaaltijdPast de differentiaalwerking 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
DisturbanceDBLInvoerStorend signaalRepresenteert een externe verstoring die wordt opgeteld bij de motorinvoer en samen met de regelspanning inwerkt op het motormodel.0-10, stap 0,1
Reset controlBooleanInvoerResetregelingActiveert het wissen van de modeltoestand, zodat positie, hoeksnelheid, stroom, fout en integraalterm terugkeren naar hun beginwaarden.True / False
PositionDBLUitvoerActuele positieRepresenteert de huidige hoekpositie van de motor en dient als feedbackvariabele voor de PID-regeling.Berekend door het model
VoltageDBLUitvoerRegelspanningRepresenteert de uitvoer van de PID-regelaar na spanningsbegrenzing en werkt in op de motorinvoer.Berekend door het model; beperkt tot -24 tot 24 V
TimeDBLUitvoerLooptijdRepresenteert de continue looptijd van het motormodel.Berekend door het model
Measured angular velocityDBLUitvoerGemeten hoeksnelheidRepresenteert de huidige hoeksnelheid van de motor en is de mechanische toestandsuitvoer van de motor.Berekend door het model

Tabel 1: Invoer- en uitvoervariabelen gebruikt in de voorbeelden van de ventilator en de DC-motor. De tabel vermeldt elke variabelenaam, het datatype, de rol als invoer/uitvoer, de fysische betekenis, het aanbevolen bereik en de stapgrootte.

ParameterWaardeFysische betekenisRol in het model
R1Ankerweerstandstaat voor de weerstandsterm in het ankercircuit van de motor en bepaalt de spanningsval R × im in de stroomvergelijking.
L0.5AnkerinductieStelt de inductie van het ankercircuit voor en bepaalt de snelheid van de stroomwijziging. Een grotere L resulteert in een tragere stroomrespons.
J0.01TraagheidsmomentStelt de weerstand van de motorrotor tegen veranderingen in de hoekversnelling voor en bepaalt hoe snel de hoeksnelheid verandert.
b0.1Viskeuze dempingscoëfficiëntStelt de mechanische demping voor en beschrijft het dempingsmoment dat de toename van de hoeksnelheid tijdens rotatie belemmert.
Kt0.01KoppelconstanteStelt de proportionele coëfficiënt voor die de ankerstroom omzet in elektromagnetisch koppel.
Ke0.01Tegenelektromotorische krachtconstanteStelt de proportionele coëfficiënt voor waarmee hoeksnelheid een tegenelektromotorische kracht genereert en beschrijft het feedbackeffect van snelheid op de stroom.
Vmax24Maximale stuurspanningStelt de limiet van de uitgangsspanning van de controller in en houdt de spanning binnen het bereik van -24 V tot 24 V.
dt0.001Discrete simulatiestapGeeft het tijdsinterval voor elke loop-gebaseerde statusupdate aan en wordt gebruikt voor het bijwerken van de stroom, hoeksnelheid, positie en looptijd.

Tabel 2: Interne parameters gebruikt in het PID-positiecontrolesysteem van de DC-motor. De tabel bevat de elektrische en mechanische parameters, symbolen, numerieke waarden, eenheden en hun rollen in het model.

Aanvullende coderingsbestanden: Volledige bron- en configuratiebestanden voor het reproduceren van de voorbeelden met de ventilator en de DC-motor. De aanvullende coderingsbestanden omvatten de LabVIEW Formula Node-code, de Caddy reverse-proxy-configuratie, de XHTML front-end-bestanden en de LabVIEW VI-bronbestanden die in dit protocol worden gebruikt. Code in LabVIEW Formula Node.docx bevat de Formula Node-code voor de PID-positiebesturingsmodellen van de ventilator en de DC-motor. Caddyfile.txt bevat de configuratie van de lokale webserver en de reverse-proxy. Fan_Automatic_UI.xhtml en Motor_Automatic_UI.xhtml bevatten de metadata-gebaseerde logica van de web-front-end. fengshan.vi en Motor.vi zijn de LabVIEW back-end VI-bestanden voor de experimenten met de ventilator en de motor.Klik hier om dit bestand te downloaden.

Discussie

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  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

Toestemming aanvragen om de tekst of afbeeldingen van dit JoVE-artikel te hergebruiken

Toestemming aanvragen

Trefwoorden

WebgebruikersinterfaceAutomatische UI generatieVirtuele InstrumentenRIP serverconfiguratieReverse ProxyCaddy ProxyPID positiecontroleVariabele Metadata
Video binnenkort beschikbaar

Gerelateerde artikelen