Methodenartikel

Ein Protokoll zur automatischen Generierung webbasierter Schnittstellen für LabVIEW-Anwendungen unter Verwendung des Remote-Interoperability-Protokolls

158 Aufrufe

⸱

DOI:

10.3791/72765

⸱

14. August 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 diesem Artikel

Zusammenfassung

Diese Studie validiert eine auf einem Remote-Interoperabilitätsprotokoll (RIP) basierende automatische Generierung von Web-Benutzeroberflächen anhand zweier unterschiedlicher LabVIEW-Systeme – einem Lüftermodell und einem Modell zur Positionsregelung eines Gleichstrommotors – und stellt ein reproduzierbares Verfahren zur Konstruktion, Registrierung, Bereitstellung und Prüfung beider Beispiele bereit.

Zusammenfassung

Mit Fernexperimentierplattformen können lokale Simulationsmodelle oder physische Geräte über ein Netzwerk zugänglich gemacht werden. Herkömmliche Web-Frontends erfordern jedoch typischerweise eine separate Seite, eine individuelle Steuerungsanordnung und eine dedizierte Datenkommunikationslogik für jedes Experiment, was die Entwicklungskosten erhöht. Diese Arbeit bestätigt einen etablierten Workflow zur automatischen Erzeugung einer Web-Benutzeroberfläche (UI) aus LabVIEW-Virtuellen Instrumenten (VIs) mithilfe des Remote-Interoperabilitätsprotokolls (RIP) und stellt ein reproduzierbares Protokoll für dessen Implementierung bereit. Der Workflow erstellt LabVIEW-VIs, die Eingabesteuerungen und Ausgabeindikatoren auf der Bedienoberfläche definieren, registriert jedes VI in der RIP-Server-Konfiguration, liest die resultierenden Variablen-Metadaten aus und generiert die entsprechenden Web-Steuerelemente und Ausgabedisplayelemente. Caddy wird als Reverse-Proxy verwendet, um den Pfad für statische Frontend-Dateien und den Pfad für RIP-Anwendungsprogrammierschnittstellen (API)-Anfragen zu vereinheitlichen. Der Workflow wird anhand zweier unterschiedlicher Systeme evaluiert: einem Lüfterdrehzahlmodell und einem Modell zur positionsregelnden Proportional-Integral-Differenzial- (PID-)Regelung eines Gleichstrommotors (DC). In beiden Fällen identifiziert die Webseite die bereitgestellten Variablen, schreibt Benutzereingaben an das LabVIEW-Hintergrundsystem, liest Modellausgaben aus und generiert die Benutzeroberfläche basierend auf den RIP-Metadaten. Diese Ergebnisse bestätigen denselben automatischen UI-Generierungsprozess für zwei verschiedene dynamische Systeme und dokumentieren die Schritte, die erforderlich sind, um ihn zu reproduzieren.

Einleitung

Mit der Entwicklung von Fernexperimenten, Online-Lehre und Technologien des Internets der Dinge ist der webbasierte Zugriff auf lokale Simulationsmodelle oder experimentelle Geräte zu einer wichtigen Richtung bei der Entwicklung experimenteller Plattformen geworden1,2,3,4. Aktuelle Arbeiten haben zudem Labore, die mit Technologien des Internets der Dinge ausgestattet sind, in projektorientiertes Lernen sowie in lokalen oder entfernten Zugriff integriert und damit die kontinuierliche Weiterentwicklung flexibler und vernetzter experimenteller Plattformen im ingenieurwissenschaftlichen Unterricht belegt5. Bei Regelungssystemexperimenten müssen Benutzer in der Regel Eingabeparameter in einem Browser anpassen und Ausgabezustände in Echtzeit beobachten6,7. Herkömmliche Methoden erfordern typischerweise eine separate Webseite, eine Logik zur Steuerungsbindung sowie eine Schnittstelle zur Datenkommunikation für jedes experimentelle Objekt8,9. Wenn sich die Variablen im Backend-Modell ändern, muss die Frontend-Seite oft entsprechend angepasst werden, was erheblichen wiederholten Entwicklungsaufwand verursacht und die schnelle Erweiterung der experimentellen Plattform einschränkt.

Das Remote-Interoperabilitätsprotokoll (RIP) stellt eine Middleware-Schicht zwischen Backend-Experimentmodellen und Web-Frontends bereit10,11. Bei dem in früheren Arbeiten beschriebenen, auf RIP basierenden Ansatz zur automatischen Benutzeroberflächengenerierung liefert der RIP-Server Metadaten für jedes Experiment, einschließlich Variablennamen, Eingabe-/Ausgabe-Attribute, Datentypen, Minimalwerte, Maximalwerte, Genauigkeit, Beschreibungen sowie verfügbare Lese- und Schreibmethoden11. Ein Web-Client kann diese Metadaten anschließend nutzen, um während des Seitenladens oder der Aktualisierung die entsprechenden HTML-Elemente wie Beschriftungen, numerische Eingabefelder, Schieberegler, boolesche Steuerelemente und Ausgabeanzeigen zu erstellen11. Das vorliegende Protokoll implementiert die RIP-Spezifikation nicht neu und definiert sie auch nicht um. Stattdessen verwendet es den bestehenden quelloffenen RIP-Dienst sowie die auf RIP basierende Logik zur Umwandlung von Metadaten in HTML-Benutzeroberflächen als Grundlage für Kommunikation und Oberflächengenerierung und konzentriert sich auf den reproduzierbaren Aufbau, die Registrierung, die Proxy-Bereitstellung und die Verifizierung von zwei LabVIEW-VI-Beispielen.

Im Vergleich zur herkömmlichen, benutzerdefinierten Entwicklung von Web-Schnittstellen reduziert die auf RIP basierende automatische Benutzeroberflächengenerierung den Aufwand für die Implementierung von Steuerungs-Layouts, Variablen-Bindungslogik und grundlegenden Kommunikationsfunktionen, wenn mehrere LabVIEW-Experimente vergleichbare skalare Ein- und Ausgabewerte bereitstellen8,9,10,11. Sobald eine neue VI registriert ist und ihre Variablen dem RIP-Server zur Verfügung stehen, kann dieselbe Logik zum Auslesen der Metadaten und zur Generierung von Steuerelementen wiederverwendet werden, um die grundlegende Web-Schnittstelle aufzubauen10,11. Diese Funktion ist nützlich für eine schnelle Bereitstellung, Lehrdemonstrationen und Plattformen für Fernlabore, die einen konsistenten Zugriff auf mehrere ähnliche Experimente erfordern3,8,9. Die automatisch generierte Schnittstelle weist jedoch auch Einschränkungen auf. Sie leitet nicht vollständig die physikalischen Beziehungen zwischen den Variablen ab, bestimmt nicht automatisch die Zuordnung von Diagrammen und entwirft keine domänenspezifischen Visualisierungen oder Sicherheitsinteraktionen11. Daher bleibt die manuelle Entwicklung einer Web-Schnittstelle vorzuziehen, wenn ein Experiment hochgradig angepasste Grafiken, komplexe Benutzerabläufe, erweiterte Visualisierungen, hardwarebasierte Sicherheitsverriegelungen oder eine Schreibzugriffsarbitrierung für mehrere Benutzer erfordert.

Der gesamte Ablauf des Protokolls ist in Abbildung 1 zusammengefasst. In diesem Ablauf definiert eine LabVIEW-VI zunächst die erforderlichen Eingabesteuerungen und Ausgabeanzeigen auf dem Bedienfeld. Die VI wird anschließend in der RIP-Server-Konfiguration registriert, indem der Experimentname und der VI-Pfad angegeben werden. Nach der Registrierung liest der RIP-Server die Metadaten des ausgewählten Experiments ein und bietet Lese- und Schreibzugriff auf die verfügbaren Variablen. Die XHTML-Webseite nutzt die zurückgegebenen Metadaten, um automatisch die entsprechenden Eingabesteuerungen und Ausgabedisplayelemente zu erzeugen, während Caddy einen einheitlichen Zugriffspfad für die statische Webseite und die RIP-Kommunikationswege bereitstellt. Im Rahmen dieser Studie werden das Lüfter- und das Gleichstrommotor-Modell als zwei Implementierungen desselben Arbeitsablaufs verwendet. Für andere LabVIEW-Experimente, die kompatible skalare, numerische und boolesche Variablen bereitstellen, können Entwickler denselben Ablauf aus Erstellen, Registrieren, Bereitstellen und Überprüfen befolgen, um eine automatisch generierte Weboberfläche zu erstellen, und dabei bei Bedarf experiment-spezifische Visualisierungen, Sicherheitslogik oder komplexe Datenverarbeitung hinzufügen.

Dieser Artikel schlägt keine neue RIP-Architektur vor oder erweitert den Umfang der Datentypen, die von RIP bereits unterstützt werden. Stattdessen nutzt er RIP als etablierten Mechanismus für die Kommunikation und die auf Metadaten basierende Generierung von Benutzeroberflächen und konzentriert sich darauf, denselben Prozess mit zwei verschiedenen LabVIEW-Systemen zu validieren, während gleichzeitig ein reproduzierbares Implementierungsprotokoll dokumentiert wird. Frühere Arbeiten stellten eine grundlegende Methode zur automatischen Generierung von Web-Benutzeroberflächen basierend auf RIP-Metadaten vor und verwendeten ein Online-Servomotorexperiment als Fallstudie11. Webfähige Fernlabor-Architekturen, die interaktive Schnittstellen mit Ingenieursoftware und LabVIEW kombinieren, wurden ebenfalls in früheren Studien beschrieben9,12. Bei praktischen Reproduktionen waren jedoch einige LabVIEW-Modelle im ursprünglichen Fall von Softwareversionen und Modulkompatibilitäten betroffen, was ihre direkte Verwendung in neueren Umgebungen erschwerte. Die vorliegende Arbeit rekonstruiert daher zwei kompatible Backend-VIs – ein Lüftermodell und ein Modell zur positionsregelbasierten Regelung eines Gleichstrommotors (DC-Motor) mittels Proportional-Integral-Differenzial-Regler (PID) – und wendet denselben, auf Metadaten basierenden Prozess zur Benutzeroberflächengenerierung auf beide an. Der Beitrag liegt in der plattformübergreifenden Validierung des etablierten RIP-Arbeitsablaufs und in einem detaillierten Protokoll zur Reproduktion des Prozesses, nicht in einer Erweiterung der Allgemeingültigkeit von RIP.

Die Zielgruppe dieses Protokolls sind Forscher, Dozenten und Laborentwickler, die bereits LabVIEW-VIs verwenden und Simulationsmodelle oder Experimentalsysteme mit geringem Risiko über einen Webbrowser zugänglich machen möchten, ohne für jedes Modell eigenständig eine vollständige benutzerdefinierte Oberfläche implementieren zu müssen. Das Protokoll eignet sich besonders gut für Experimente, die Standard-Numerik- und Boolesche Variablen, Parameteranpassungen und Echtzeit-Statusüberwachung nutzen10,11. Es ist weniger geeignet als eigenständige Lösung für Experimente, die komplexe Datenstrukturen, spezialisierte Visualisierungen, strikte Hardware-Sicherheitsverriegelungen oder Mehrnutzer-Schreibarbitrierung erfordern11. Ziel dieser Arbeit ist es, die automatische Generierung webbasierter Benutzeroberflächen mittels RIP anhand zweier unterschiedlicher LabVIEW-Systeme zu validieren und ein vollständiges, reproduzierbares Protokoll von der Erstellung der Backend-VIs bis zur browserbasierten Interaktion bereitzustellen. Das Protokoll umfasst die Definition von Eingabe- und Ausgabevariablen, die Registrierung des Experiments am RIP-Server, die metadatenbasierte Generierung der Benutzeroberfläche, die Bereitstellung des Caddy-Proxys sowie die Verifizierung des Fernzugriffs auf Lese- und Schreiboperationen. Die Anwendung desselben Workflows auf die Modellbeispiele Lüfter und Gleichstrommotor zeigt, dass der etablierte Prozess reproduziert werden kann, ohne dass für jedes Beispiel eine komplette Web-Oberfläche manuell neu geschrieben werden muss9,10,11.

Protokoll

Führen Sie die folgenden Schritte aus, um zwei über RIP zugängliche LabVIEW-Experimente gemäß dem in Abbildung 1 zusammengefassten Workflow zu erstellen, zu registrieren, bereitzustellen und zu verifizieren. Alle in dieser Studie verwendeten Werkzeuge und Plattformen sind in der Tabelle der Materialien aufgelistet.

1. Aufbau und Durchführung des Ventilatormodellexperiments

  1. Baue das Lüftermodell VI.
    1. Öffnen Sie LabVIEW, erstellen Sie ein neues VI und speichern Sie die Datei als fengshan.vi. Speichern Sie das VI in einem beliebigen Verzeichnis, auf das der RIP-WebService-Prozess zugreifen kann. Der Ordner „Private“ wird lediglich als Beispielverzeichnis verwendet und ist nicht im RIP fest codiert. Geben Sie während der RIP-Experimentregistrierung den tatsächlich gewählten VI-Pfad ein.
    2. Fügen Sie auf dem Frontpanel die Eingabesteuerelemente für das Lüftermodell hinzu. Benennen Sie in diesem Beispiel die Eingabesteuerelemente Aktivieren, PWM, Laden, Tau, KMaxDrehzahl, und Störung. Einstellen Aktivieren als boolesche Steuerung und einstellen PWM, Last, Tau, KMaxU/minund Störung als numerische Steuerungen mit doppelter Genauigkeit (DBL). Siehe Zusatz-Tabelle 1 für die physikalische Bedeutung und die Modellfunktion der Ventilatorenvariablen.
    3. Fügen Sie die Ausgabekenngrößen für das Lüftermodell hinzu. Benennen Sie in diesem Beispiel die Ausgabekenngrößen SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA und PowerW. Stellen Sie alle Ausgabeindikatoren als DBL-Indikatoren ein.
      ​HINWEIS: Tabelle 1 beschreibt die physikalische Bedeutung und die Modellfunktion dieser Ausgabegrößen. Die fertige Lüfter-Frontplatte ist dargestellt in Abbildung 2Die angezeigten Variablennamen, Bereiche und Schrittgrößen in Tabelle 1 beschreiben die beiden in diesem Protokoll implementierten Beispiele. Sie stellen keine fest codierten Anforderungen von RIP dar. Für andere LabVIEW-Experimente können Entwickler unterschiedliche Namen für Frontpanel-Variablen und numerische Eigenschaften festlegen. Der RIP-Server liest die tatsächlichen Variablennamen, Datentypen, Eingabe-/Ausgabe-Attribute und verfügbaren numerischen Eigenschaften aus den VI-Metadaten aus, und die Webseite generiert die entsprechenden Steuerelemente und Anzeigen anhand der zurückgegebenen Metadaten.
    4. Fügen Sie eine While-Schleife zum Blockdiagramm hinzu. Fügen Sie zwei Shift-Register hinzu, um Geschwindigkeit_zuvor und Zeit_vorherund initialisieren Sie beide Werte auf 0.
    5. Fügen Sie einen Formelknoten innerhalb der While-Schleife hinzu. Verbinden Sie Aktivieren, PWM, Last, Tau, KMaxDrehzahl, Störung, Drehzahl_vorher, und Zeit_vorher zu den linken Eingangsterminals des Formelknotens, und setzen Sie SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW und zeit_nächste als die rechten Ausgangsklemmen.
    6. Aufbau des Aktivieren Steuerlogik außerhalb des Formelknotens. Verwenden Sie Aktivieren als das Auswahlsignal, sodass u = PWM wenn Aktivieren ist wahr und u = 0 wenn Aktivieren ist falsch.
    7. Geben Sie den Lüfter-Modellcode in den Formelknoten ein. Verwenden Sie diesen Code, um die stationäre Drehzahl, die tatsächliche Drehzahl, die normierte Drehzahl, den Strom, die Leistung und die Betriebszeit zu berechnen; siehe Ergänzende Codierungsdatei 1 für den vollständigen Code.
    8. Verbinden Sie das speed_next Ausgabe des Formelknotens an die SpeedRPM Indikator und anschließen speed_next zurück zum rechten Schieberegister für Geschwindigkeit_vorher. Verbinden SteadyRPM zum SteadyRPM Indikator
    9. Verbinden zeit_nächste zum ZeitS Indikator und Verbindung zeit_nächste zurück zum rechten Schieberegister für Zeit_prev. Verbinden SpeedNorm, StromA, und PowerW zu den entsprechenden Ausgabeindikatoren.
    10. Fügen Sie eine Warte-Funktion innerhalb der While-Schleife hinzu und stellen Sie die Wartezeit auf 50 ms ein. Fügen Sie eine Schaltfläche „Lokal stoppen“ hinzu und verbinden Sie sie mit dem Bedingungs-Terminal der While-Schleife.
    11. Speichern Sie fengshan.vi. Das fertige Blockschaltbild des Lüfters ist dargestellt in Abbildung 3.
      PAUSEPUNKT: Nachdem das fertige Fan-VI gespeichert wurde, kann der Workflow unterbrochen werden. Setzen Sie später fort, indem Sie das gespeicherte VI erneut öffnen und überprüfen, ob alle Steuerelemente, Anzeigen und Blockdiagramm-Verbindungen auf der Vorderseite weiterhin vorhanden sind.
  2. Registrieren Sie das Fan-Experiment im RIP-Server.
    1. Öffnen Sie RIPWebService.lvproj im LabVIEW-Projektexplorer
      .
    2. Öffnen Sie Configuration.vi im Projektbaum und suchen Sie die Experimentkonfigurationstabelle.
    3. Fügen Sie eine neue Experimentzeile hinzu. Legen Sie den Namen auf fan fest. Geben Sie den vollständigen Pfad zur gespeicherten Datei fengshan.vi an. Die Registrierungsfelder für das fan-Experiment werden angezeigt in Abbildung 4.
    4. Füllen Sie die verbleibenden Konfigurationsfelder aus. Legen Sie Autoren auf den Experimentautor fest, Schlüsselwörter auf Fan, Beschreibung auf Lüftergeschwindigkeitsmodell und Abtastrate auf 200.
    5. Im LabVIEW-Menü wählen Sie aus Bearbeiten > Aktuelle Werte als Standard festlegen. Save Configuration.vi
    6. Neustart des RIP-Webservices und Überprüfung, ob das Lüfterexperiment nach dem Neustart weiterhin in der Konfigurationsoberfläche aufgeführt ist.
      HINWEIS: Der Experimentname beachtet die Groß- und Kleinschreibung. Der Wert fan in der RIP-Konfiguration muss exakt mit der Experiment-ID in der XHTML-Datei der Benutzeroberfläche übereinstimmen. Um ein weiteres LabVIEW-VI mit derselben Logik zur automatischen Benutzeroberflächenerstellung bereitzustellen, fügen Sie einen neuen Experimenteintrag in der RIP-Konfiguration hinzu, legen Sie einen neuen Namenwert fest und weisen Sie unter „Pfad“ die entsprechende VI-Datei zu. Verwenden Sie anschließend denselben Namenwert als Experiment-ID in der XHTML-Datei. Die Seite der Benutzeroberfläche muss nicht für jede Variable neu geschrieben werden.
      ​PAUSE-POSITION: Nachdem Configuration.vi gespeichert und die aktuellen Werte als Standard festgelegt wurden, kann der Workflow angehalten werden. Setzen Sie später fort, indem Sie den RIP-WebService neu starten und bestätigen, dass das Lüfterexperiment weiterhin registriert ist.
  3. Bereiten Sie die Vorderseite für das Lüfterexperiment vor.
    1. Fan_Automatic_UI.xhtml in das Client-Verzeichnis kopieren, das als Front-End-Stammverzeichnis verwendet wird.
    2. Öffnen Sie Fan_Automatic_UI.xhtml mit einem Texteditor.
    3. Suchen Sie die Versuchs-ID-Variable im Skriptabschnitt und setzen Sie sie auf fan.
      HINWEIS: Dieser Wert muss exakt mit dem Namensfeld des Lüfterexperiments in der RIP-Konfiguration übereinstimmen. Die Einstellungen der Experiment-ID und die gemeinsame, auf Metadaten basierende Logik zur Erzeugung der Benutzeroberfläche für die XHTML-Frontend-Dateien sind dargestellt in Abbildung 5.
    4. Überprüfen Sie, ob die Seite den aktuellen Zugriffsursprung über window.location.origin erhält und Metadaten zum Experiment anfordert über rip.info()und übergibt die zurückgegebene Metadaten an autobuildUI().
      HINWEIS: Die Seite sollte die Variablennamen, Bereiche oder Schrittgrößen für Lüfter nicht manuell fest codieren. Stattdessen werden beschreibbare Variablen aus meta.schreibbare.liste, lesbare Variablen werden generiert aus meta.readables.listund numerische Attribute wie min, max und step werden aus den vom RIP-Server zurückgegebenen Metadaten abgerufen.
    5. Fan_Automatic_UI.xhtml speichern.
      ​HINWEIS: Um dieselbe Frontend-Generierungslogik für eine andere LabVIEW-VI zu verwenden, legen Sie eine neue Experiment-ID in der XHTML-Datei fest und registrieren Sie den entsprechenden Experimentnamen und den VI-Pfad in der RIP-Konfiguration. Die Web-Steuerelemente und Ausgabedisplays werden entsprechend den Metadaten generiert, die vom ausgewählten Experiment zurückgegeben werden.
  4. Konfigurieren Sie den Caddy-Zugriffspfad für das Fan-Experiment.
    1. Öffnen Sie die Caddyfile mit einem Texteditor.
    2. Legen Sie das Stammverzeichnis der Front-End-Oberfläche auf das Client-Verzeichnis fest, das Fan_Automatic_UI.xhtml enthält.
    3. Wählen Sie einen ungenutzten lokalen Port für Caddy, um den Browserzugriff auf die Webseite und die RIP-Routen bereitzustellen. In diesem Protokoll wird Port 8090 als Beispiel für einen Proxy-Zugriffsport verwendet.
      HINWEIS: Port 8090 wird weder von RIP noch von Caddy benötigt. Falls Port 8090 belegt ist, ersetzen Sie ihn durch einen anderen freien lokalen Port und verwenden Sie denselben Port in der Browser-Adresse.
    4. Fügen Sie eine Route hinzu, die /fan in Fan_Automatic_UI.xhtml umschreibt.
    5. Identifizieren Sie den im LabVIEW konfigurierten RIP-WebService-Port. In diesem Protokoll wird http://localhost:8001 als RIP-WebService-Adresse verwendet.
      HINWEIS: Port 8001 ist der im Testumfeld verwendete Backend-Port des LabVIEW/RIP-Webservices. Er kann in der Konfiguration des LabVIEW/RIP-Webservices geändert werden. Falls ein anderer Port verwendet wird, ist http://localhost:8001 in der Caddyfile durch die entsprechende RIP-Webservice-Adresse zu ersetzen.
    6. Fügen Sie eine Reverse-Proxy-Regel hinzu, die Anfragen an /RIP/SSE* an die RIP-WebService-Adresse, beispielsweise http://localhost:8001, weiterleitet.
    7. Fügen Sie eine Reverse-Proxy-Regel hinzu, die /RIP*-Anfragen an die RIP-WebService-Adresse, beispielsweise http://localhost:8001, weiterleitet. Die Caddyfile-Konfiguration ist dargestellt in Abbildung 6.
    8. Öffnen Sie die Eingabeaufforderung unter Windows. Wechseln Sie mithilfe des folgenden Befehls in das lokale Caddy-Download- oder Installationsverzeichnis:
      cd /d D:\caddy
      HINWEIS: In diesem Protokoll ist D:\caddy der lokale Pfad für den Caddy-Download bzw. die Caddy-Installation, der in der Testumgebung verwendet wird. Falls Caddy in einem anderen Verzeichnis gespeichert ist, ersetzen Sie D:\caddy durch den entsprechenden lokalen Pfad.
    9. Starten Sie Caddy mit der angegebenen Caddyfile, indem Sie den folgenden Befehl eingeben:
      caddy.exe run --config Caddyfile
    10. Stellen Sie sicher, dass Caddy ohne Meldung eines Konfigurationsfehlers startet. Öffnen Sie http://localhost:8090/fan in einem Webbrowser und überprüfen Sie, dass die Web-Oberfläche für den Fan angezeigt wird, wie in Abbildung 7.
      ​HINWEIS: Wenn der Browser einen 502-Fehler zurückgibt, überprüfen Sie, ob der RIP-WebService ausgeführt wird, ob der RIP-WebService-Port in LabVIEW mit der Reverse-Proxy-Adresse in der Caddyfile übereinstimmt und ob der ausgewählte Caddy-Zugriffsport belegt ist.
  5. Überprüfen Sie die Betriebsergebnisse des Lüfterexperiments.
    1. Stellen Sie sicher, dass die Front-End-Seite automatisch die Aktivieren, PWM, Last, Tau, KMaxU/min, und Störung Eingabekontrollen
    2. Stellen Sie sicher, dass die Frontend-Seite die anzeigt SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA und PowerW Ausgabegrößen
    3. Anpassen PWM und beobachten Sie, ob SpeedRPM steigt an, wenn PWM steigt und fällt, wenn PWM nimmt ab.
    4. Last anpassen und beobachten, ob SteadyRPM und SpeedRPM nimmt ab, wenn die Last zunimmt.
    5. Stellen Sie die Störung ein und beobachten Sie, ob DrehzahlRPM, StromA und PowerW Änderung als Reaktion auf die Störgrößeneingabe.
    6. Stellen Sie sicher, dass ZeitS steigt weiter an, was bestätigt, dass der hinterste Lüfter VI kontinuierlich läuft.

2. Aufbau und Durchführung des PID-Regelungsexperiments für die Position eines Gleichstrommotors

  1. Erstellen Sie das PID-Regelungsmodell für die Position des Gleichstrommotors VI.
    1. Öffnen Sie LabVIEW, erstellen Sie ein neues VI und speichern Sie die Datei als Motor.vi. Speichern Sie das VI in einem beliebigen Verzeichnis, auf das der RIP-WebService-Prozess zugreifen kann.
      HINWEIS: Der Ordner „Private“ wird nur als Beispielverzeichnis verwendet und ist in RIP nicht fest codiert. Geben Sie während der Registrierung des RIP-Experiments den tatsächlich ausgewählten VI-Pfad ein.
    2. Fügen Sie auf dem Bedienfeld die Eingangssteuerungen für das PID-Positionsregelungsmodell des Gleichstrommotors hinzu. Benennen Sie in diesem Beispiel die Eingangssteuerungen Sollwert, Kc, Ti, Td, Störgrößeund Steuerung zurücksetzen. Einstellen Sollwert, Kc, Ti, Td und Störung als DBL-numerische Steuerelemente und legen Sie das Reset-Steuerelement als boolesches Steuerelement fest.
      HINWEIS: Tabelle 1 beschreibt die physikalische Bedeutung, die Modellrolle und den empfohlenen Bereich der in diesem Beispiel verwendeten Variablen.
    3. Fügen Sie die Ausgangsindikatoren für das PID-Positionsregelungsmodell des Gleichstrommotors hinzu. Benennen Sie in diesem Beispiel die Ausgangsindikatoren Position, Spannung, Zeit und Gemessene Winkelgeschwindigkeit. Stellen Sie alle Ausgangsindikatoren als DBL-Indikatoren ein. Tabelle 1 beschreibt die physikalische Bedeutung und die Modellfunktion dieser Ausgabegrößen. Die fertige Frontplatte für den Motor ist dargestellt in Abbildung 8.
      HINWEIS: Die in der Liste angegebenen Variablennamen und -bereiche in Tabelle 1 beschreiben die beiden in diesem Protokoll implementierten Beispiele. Sie stellen keine festen Vorgaben für den auf RIP basierenden automatischen Workflow zur Benutzeroberflächengenerierung dar. Wenn ein anderes LabVIEW-VI verwendet wird, liest RIP die tatsächlichen Variablennamen, Datentypen, Eingabe-/Ausgabe-Attribute und verfügbaren numerischen Eigenschaften aus den VI-Metadaten. Daher muss die Logik zur Generierung der Benutzeroberfläche keine Variablennamen, Maximalwerte, Minimalwerte oder Schrittgrößen für jedes Experiment fest einprogrammieren.
    4. Fügen Sie eine While-Schleife zum Blockdiagramm hinzu. Fügen Sie sechs Schieberegister hinzu, um theta, omega, im, e_prev, integ und Zeit, und initialisieren Sie alle sechs Werte auf 0.
    5. Fügen Sie einen Formelknoten innerhalb der While-Schleife hinzu. Gemäß dem in der PID-Positionsregelungsmodellskizze für Gleichstrommotoren gezeigten Schema Abbildung 9, verwenden Sie diesen Formelknoten als zentrales Berechnungsmodul für die Fehlerberechnung, die PID-Regelung, die Spannungsbegrenzung, das elektrische Modell, das mechanische Modell und die Positionsaktualisierung.
      HINWEIS: Die in diesem Modell verwendeten internen Motorparameter, wie R, L, J, b, Kt, Ke und Vmax, sind normalisierte Lehrmodell-Parameter und keine kalibrierten Parameter eines spezifischen physischen Motors. Sie wurden so gewählt, dass unter dem gewählten Zeitschritt und der gewählten Spannungsgrenze eine stabile und beobachtbare simulierte Antwort erzeugt wird, sodass die Effekte von Sollwert, Kc, Ti, Td und Störung lässt sich während des webbasierten Betriebs eindeutig nachweisen.
    6. Einstellen sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, Störgröße, Rücksetzen und dt as die Eingangsterminals des Formelknotens. Setzen Sie theta_next, omega_next, im_next, e_next, integ_next und Spannung als die Ausgangsklemmen des Formelknotens.
    7. Verbinden Sie Sollwert Kontrolle zur sp Eingangsklemme des Formelknotens. Verbinden Kc, Ti, Td und Störung zum Kc, Ti, Td und dStörung iEingangsterminals des Formelknotens, jeweils.
    8. Konvertieren Sie das boolesche Signal der Reset-Steuerung in ein numerisches Signal und verbinden Sie es mit dem zurücksetzen Eingangsklemme des Formelknotens. Zustandsrücksetzung ausführen, wenn zurücksetzen ist nicht gleich 0, und führen Sie die PID-Regelung und die Aktualisierung des Motorzustands durch, wenn zurücksetzen ist gleich 0.
    9. Fügen Sie die numerische Konstante hinzu dt und setzen Sie dessen Wert auf 0,001 s. Verbinden Sie das dt zur dt Eingangsklemme des Formelknotens und verwenden Sie sie zur Zeitaktualisierung.
    10. Stellen Sie die internen Modellparameter des Gleichstrommotors im Formelknoten ein. Siehe Zusatz-Tabelle 2 für die physikalische Bedeutung und die Modellfunktion der Motorenvariablen.
    11. Geben Sie den PID-Regelungscode für die Position des Gleichstrommotors in den Formelknoten ein. Verwenden Sie diesen Code, um die Logik für die Rücksetzung, Fehlerberechnung, Berechnung des Integralanteils, Berechnung des Differenzialanteils, PID-Regelung, Spannungsbegrenzung, Stromaktualisierung, Winkelgeschwindigkeitsaktualisierung und Positionsaktualisierung zu implementieren; für den vollständigen Code siehe die ergänzenden Codedateien.
    12. Verbinden theta_next zum Position Indikator und anschließen theta_next zurück zum rechten Schieberegister für theta Verbinden omega_next zur Gemessener Winkelgeschwindigkeitsanzeigerund verbinden omega_next zurück zum rechten Schieberegister für omega
    13. Schließen Sie die Spannung an den Spannungsanzeiger an. Schließen Sie im_next, e_next und integ_next zurück zu den rechten Schieberegistern für im, e_prev, und integ, bzw.
    14. Verwenden Sie eine Add-Funktion außerhalb des Formelknotens zur Berechnung time_next = time + dt. Verbinden zeit_nächste zur Zeit Indikator und anschließen zeit_nächste zurück zum rechten Schieberegister für die Zeit.
    15. Fügen Sie eine Warte-Funktion innerhalb der While-Schleife ein und stellen Sie die Wartezeit auf 1 ms ein. Fügen Sie eine Stop-Taste hinzu und verbinden Sie sie mit dem Bedingungs-Terminal der While-Schleife.
    16. Motor.vi speichern. Das fertige Blockdiagramm des Motors ist dargestellt in Abbildung 10.
      PAUSEPUNKT: Nachdem das abgeschlossene Motor-VI gespeichert wurde, kann der Workflow angehalten werden. Setzen Sie später fort, indem Sie das gespeicherte VI erneut öffnen und überprüfen, ob alle Steuerelemente, Anzeigen und Blockdiagramm-Verbindungen auf der Vorderseite weiterhin vorhanden sind.
  2. Registrieren Sie das Motorexperiment im RIP-Server.
    1. Öffnen Sie RIPWebService.lvproj im LabVIEW-Projektexplorer.
    2. Öffnen Sie Configuration.vi im Projektbaum und suchen Sie die Experiment-Konfigurationstabelle.
    3. Fügen Sie eine neue Experimentzeile hinzu. Legen Sie Name auf Motor fest. Legen Sie Pfad auf den vollständigen Pfad der gespeicherten Datei Motor.vi fest. Die Registrierungsfelder für das Motor-Experiment werden angezeigt in Abbildung 11.
    4. Füllen Sie die verbleibenden Konfigurationsfelder aus. Legen Sie Autoren auf den Experimentautor fest, Stichwörter auf Motor, Beschreibung auf Modell zur Positionsregelung eines Gleichstrommotors und Abtastfrequenz auf 200.
    5. Im LabVIEW-Menü wählen Sie aus Bearbeiten > Aktuelle Werte als Standard festlegen. Save Configuration.vi
    6. Neustart des RIP-Webservices und Überprüfung, ob das Motor-Experiment nach dem Neustart weiterhin in der Konfigurationsoberfläche aufgeführt ist.
      HINWEIS: Der Experimentname beachtet die Groß- und Kleinschreibung. Der Wert Motor in der RIP-Konfiguration muss exakt mit der Experiment-ID in Motor_Automatic_UI.xhtml übereinstimmen. Um eine andere LabVIEW-VI mit derselben Logik zur automatischen Benutzeroberflächengenerierung bereitzustellen, fügen Sie einen neuen Experimenteintrag in der RIP-Konfiguration hinzu, legen Sie einen neuen Namenwert fest und weisen Sie dem Pfad die entsprechende VI-Datei zu. Verwenden Sie anschließend denselben Namenwert als Experiment-ID in der XHTML-Datei. Die Frontend-Seite muss nicht für jede Variable neu geschrieben werden.
      ​PAUSE-POSITION: Nachdem die Datei Configuration.vi gespeichert und die aktuellen Werte als Standard festgelegt wurden, kann der Workflow angehalten werden. Setzen Sie später fort, indem Sie den RIP-WebService neu starten und bestätigen, dass das Motor-Experiment weiterhin registriert ist.
  3. Bereiten Sie die Startseite für das Motorexperiment vor.
    1. Platzieren Sie Motor_Automatic_UI.xhtml im Client-Verzeichnis, das als Frontend-Stammverzeichnis verwendet wird.
    2. Öffnen Sie Motor_Automatic_UI.xhtml mit einem Texteditor.
    3. Suchen Sie die Experiment-ID-Variable im Skriptabschnitt und setzen Sie sie auf Motor. Dieser Wert muss exakt mit dem Namensfeld des Motor-Experiments in der RIP-Konfiguration übereinstimmen. Die Motor-Oberflächen-Seite verwendet dieselbe, auf Metadaten basierende Logik zur Generierung der Benutzeroberfläche, die in Abbildung 5; lediglich die Experiment-ID wird geändert, um der Motor-Eingabe in der RIP-Konfiguration zu entsprechen.
    4. Stellen Sie sicher, dass die Seite die RIP-Metadatenleselogik, die HTML-Steuerelementgenerierungslogik, die RIP-Schreibfunktion und die Ausgabedatenaktualisierungsfunktion enthält.
      HINWEIS: Die Seite sollte die Namen, Bereiche oder Schrittgrößen der Motorenvariablen nicht manuell fest codieren. Diese Eigenschaften werden aus den Metadaten abgeleitet, die vom RIP-Server zurückgegeben werden, gemäß dem zuvor beschriebenen RIP-basierten Mechanismus zur Generierung von HTML aus Metadaten.11.
    5. Motor_Automatic_UI.xhtml speichern.
      ​HINWEIS: Um dieselbe Frontend-Generierungslogik für eine andere LabVIEW-VI zu verwenden, legen Sie eine neue Experiment-ID in der XHTML-Datei fest und registrieren Sie den entsprechenden Experimentnamen und den VI-Pfad in der RIP-Konfiguration. Die Websteuerelemente und Ausgabedisplay werden entsprechend den Metadaten generiert, die vom ausgewählten Experiment zurückgegeben werden.
  4. Konfigurieren Sie den Caddy-Zugriffspfad für das Motorexperiment.
    1. Öffnen Sie die Caddyfile mit einem Texteditor.
    2. Legen Sie das Frontend-Stammverzeichnis auf das Client-Verzeichnis fest, das Motor_Automatic_UI.xhtml enthält.
    3. Wählen Sie einen nicht verwendeten lokalen Port für Caddy aus, um den Browserzugriff auf die Webseite und die RIP-Routen bereitzustellen. In diesem Protokoll wird Port 8090 als Beispiel für einen Proxy-Zugriffsport verwendet.
      HINWEIS: Port 8090 wird weder von RIP noch von Caddy benötigt. Falls Port 8090 belegt ist, ersetzen Sie ihn durch einen anderen freien lokalen Port und verwenden Sie denselben Port in der Browser-Adresse.
    4. Fügen Sie eine Route hinzu, die /motor in Motor_Automatic_UI.xhtml umschreibt.
    5. Identifizieren Sie den im LabVIEW konfigurierten RIP-WebService-Port. In diesem Protokoll wird http://localhost:8001 als RIP-WebService-Adresse verwendet.
      HINWEIS: Port 8001 ist der im Testumfeld verwendete Backend-Port des LabVIEW/RIP-Webservices. Er kann in der Konfiguration des LabVIEW/RIP-Webservices geändert werden. Falls ein anderer Port verwendet wird, ersetzen Sie http://localhost:8001 in der Caddyfile durch die entsprechende RIP-Webservice-Adresse.
    6. Fügen Sie eine Reverse-Proxy-Regel hinzu, die Anfragen an /RIP/SSE* an die RIP-WebService-Adresse, beispielsweise http://localhost:8001, weiterleitet.
    7. Fügen Sie eine Reverse-Proxy-Regel hinzu, die Anfragen an /RIP* an die RIP-WebService-Adresse, beispielsweise http://localhost:8001, weiterleitet. Die Caddyfile-Konfiguration ist in Abbildung 6 dargestellt.
    8. Öffnen Sie die Eingabeaufforderung unter Windows. Wechseln Sie mithilfe des folgenden Befehls in das lokale Caddy-Download- oder Installationsverzeichnis:
      cd /d D:\caddy
      HINWEIS: In diesem Protokoll ist D:\caddy der lokale Pfad für den Caddy-Download oder die Caddy-Installation, der in der Testumgebung verwendet wird. Falls Caddy in einem anderen Verzeichnis gespeichert ist, ist D:\caddy durch den entsprechenden lokalen Pfad zu ersetzen.
    9. Starten Sie Caddy mit der angegebenen Caddyfile, indem Sie den folgenden Befehl eingeben:
      caddy.exe run --config Caddyfile
    10. Stellen Sie sicher, dass Caddy startet, ohne einen Konfigurationsfehler zu melden. Öffnen Sie http://localhost:8090/motor in einem Webbrowser und überprüfen Sie, ob die Web-Benutzeroberfläche für den Motor angezeigt wird, wie in Abbildung 12.
      ​HINWEIS: Wenn die Motor-Webseite geladen wird, aber die Ausgabewerte sich nicht aktualisieren, überprüfen Sie, ob der RIP-WebService ausgeführt wird, ob die Motor-VI ausgeführt wird, ob der RIP-WebService-Port in LabVIEW mit der Reverse-Proxy-Adresse in der Caddyfile übereinstimmt und ob die Route /RIP/SSE* korrekt weitergeleitet wird.
  5. Überprüfen Sie die Betriebsergebnisse des Motorexperiments.
    1. Überprüfen Sie, ob die Front-End-Seite automatisch die Sollwert, Kc, Ti, Td, Störgröße, und Zurücksetzen Kontrolleingangssteuerungen.
    2. Stellen Sie sicher, dass die Frontend-Seite die anzeigt Position, Spannung, Zeit, und Gemessene Winkelgeschwindigkeit Ausgabewerte
    3. Anpassen Sollwert und beobachten Sie, ob die Position auf die Änderung der gewünschten Position reagiert.
    4. Anpassen Kc, Ti und Td und beobachten Sie, ob Spannung, Position, und Gemessene Winkelgeschwindigkeit Veränderung.
    5. Anpassen die Störung und beobachten Sie, ob die Position, die Steuerspannung oder die gemessene Winkelgeschwindigkeit wird beeinflusst von dem Störung Eingabe.
    6. Klicken Sie auf die Schaltfläche „Zurücksetzen“ und beobachten Sie, ob Position, Spannung, gemessene Winkelgeschwindigkeit, und die zugehörigen internen Zustände kehren gemäß der Reset-Logik in ihre Anfangszustände zurück.

Ergebnisse

Nach Abschluss des oben beschriebenen Workflows können sowohl das Lüfterexperiment als auch das Experiment zur PID-Regelung der Position eines Gleichstrommotors über die automatisch generierte Web-Oberfläche aufgerufen werden. Ein erfolgreicher Versuch wird durch drei Beobachtungen bestätigt. Erstens erzeugt die Webseite automatisch Eingabesteuerungen und Ausgabedisplayfelder gemäß den Variablen-Metadaten, die vom RIP-Server zurückgegeben werden. Zweitens wird beim Ändern einer Eingabevariablen durch den Benutzer auf der Webseite der modifizierte Wert über die RIP-Schnittstelle an die LabVIEW-Hintergrundanwendung (VI) übertragen. Drittens werden die von der Hintergrundanwendung berechneten Ausgabevariablen über RIP zurückgesendet und in Echtzeit auf der Webseite aktualisiert. Beim Lüfterexperiment erzeugt die Seite nach Eingabe von http://localhost:8090/fan in einem Browser automatisch Eingabesteuerungen und Ausgabefelder aus den RIP-Metadaten, wie in Abbildung 7 dargestellt. Der Eingabebereich umfasst Enable, PWM, Load, Tau, KMaxRPM und Disturbance, während der Ausgabebereich SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA und PowerW anzeigt. Im Normalbetrieb steigt TimeS kontinuierlich an, was anzeigt, dass die Hintergrundanwendung fengshan.vi ausgeführt wird. Wenn PWM erhöht wird, steigen SpeedRPM und SteadyRPM entsprechend an. Bei Erhöhung von Load verringert sich die Lüfterdrehzahl, da die Load-Einstellung die stationäre Betriebsdrehzahl reduziert. Bei Änderung von Disturbance sind entsprechende Veränderungen in SpeedRPM, CurrentA und PowerW zu beobachten. Diese Beobachtungen bestätigen, dass die Eingaben auf der Web-Seite korrekt an die LabVIEW-Hintergrundanwendung übertragen werden und dass die berechneten Ausgaben über RIP an die Vorderseite zurückgegeben werden.

Für das Experiment zur PID-Positionsregelung eines Gleichstrommotors werden nach dem Aufruf von http://localhost:8090/motor in einem Browser automatisch die entsprechenden Steuer- und Ausgabefelder anhand der RIP-Metadaten generiert, wie in Abbildung 12 dargestellt. Zu den Eingangsvariablen gehören Sollwert, Kc, Ti, Td, Störgröße und die Rücksetz-Steuerung, während zu den Ausgangsvariablen Position, Spannung, Zeit und gemessene Winkelgeschwindigkeit zählen. Wenn der Sollwert geändert wird, reagiert die Position auf den neuen Zielwert. Bei einer Anpassung der PID-Reglerparameter Kc, Ti und Td ändern sich die Ausgangsreaktion, die Regelspannung und die gemessene Winkelgeschwindigkeit entsprechend, was darauf hinweist, dass die auf der Webseite eingegebenen Parameterwerte korrekt in das LabVIEW-Hintergrundmodell übernommen werden und an der Regelberechnung beteiligt sind. Wenn die Rücksetz-Steuerung aktiviert wird, kehren die Modellvariablen gemäß der Rücksetzlogik in ihren Anfangszustand zurück.

Browserseitige Fehler und Kommunikationszustände sind in Abbildung 13, Abbildung 14, Abbildung 15 dargestellt. Abbildung 13 zeigt einen fehlgeschlagenen Browserzugriff, bei dem Caddy nicht ausgeführt wird. Der Browser versucht, auf http://localhost:8090/motor zuzugreifen, zeigt jedoch eine ERR_CONNECTION_REFUSED-Meldung an, was darauf hinweist, dass der lokale Proxydienst nicht verfügbar ist oder nicht am ausgewählten Zugriffsport lauscht. Abbildung 14 zeigt einen RIP-POST-Kommunikationsfehler nach dem Laden der Seite. In diesem Fall meldet die Browserkonsole einen 502 Bad Gateway-Fehler für die RIP-POST-Anfrage, was bedeutet, dass das Frontend die Proxyadresse erreicht hat, die Anfrage jedoch nicht erfolgreich an den RIP-WebService-Back-End weitergeleitet oder dort verarbeitet werden konnte. Im Gegensatz dazu zeigt Abbildung 15 einen normalen browserseitigen Kommunikationszustand. Die Entwicklertools des Browsers zeigen erfolgreiches Laden der Seite, erfolgreiche RIP-POST-Anfragen sowie eine aktive SSE-Anfrage mit expId=fan an, was darauf hindeutet, dass das Web-Frontend über den Caddy-Proxy mit dem RIP-WebService kommuniziert und Echtzeit-Updates über den SSE-Kanal erhält.

Zusammen zeigen die erfolgreichen Ergebnisse des Lüfters und Motors sowie die Diagnoseergebnisse auf Browser-Seite, dass der gleiche, auf Metadaten basierende Workflow zur automatischen Benutzeroberflächengenerierung für zwei verschiedene LabVIEW-Experimente reproduziert werden kann. Diese Ergebnisse liefern zudem beobachtbare Kriterien, um erfolgreiche Kommunikation von repräsentativen Bereitstellungsfehlern zu unterscheiden, während die entsprechenden Fehlersuchverfahren im Abschnitt „Diskussion“ erörtert werden.

LabVIEW-VI-zu-Web-UI-Prozessdiagramm mit RIP-Server und Caddy-Proxy für die Datenkommunikation.
Abbildung 1: Gesamtstruktur des experimentellen Systems. Das System besteht aus der LabVIEW-Hintergrund-VI, dem RIP-Server, dem Caddy-Proxy und der automatisch generierten Web-Benutzeroberfläche. Die LabVIEW-VI stellt Modellvariablen bereit, der RIP-Server liest Metadaten und Variablenwerte der VI aus, Caddy vereinheitlicht den Zugriffspfad und löst Probleme beim Zugriff aus verschiedenen Ursprungsquellen (Cross-Origin), und die Web-Benutzeroberfläche generiert Steuerelemente automatisch. Der Name und das Logo von Caddy werden nur angezeigt, um die verwendete Caddy-Webserver-/Proxy-Komponente im Workflow zu identifizieren. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Diagramm des Motorsteuersystems mit Drehzahlkurve, Eingabeparametern und Ausgabedatenanalyse.
Abbildung 2: Vorderseite des Lüfter-VI. Die Vorderseite enthält Eingabesteuerungen für Enable, PWM, Load, Tau, KMaxRPM und Disturbance sowie Ausgabeindikatoren für SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA und PowerW. Dieser Screenshot wurde aus der Vorderseite von fengshan.vi in LabVIEW 2026 in der lokalen experimentellen Umgebung der Autoren aufgenommen. Es sind keine Daten von Dritten oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Diagramm des Formelknotens mit Schieberegistern und einer While-Schleife zur Analyse des Drehzahlregelungsprozesses.
Abbildung 3: Blockschaltbild der Lüfter-VI. Das Lüftermodell ist mithilfe einer While-Schleife, Schieberegistern, Aktivierungs-Logik, eines Formelknotens und Ausgangsanzeigen realisiert. Dieser Screenshot wurde aus dem Blockschaltbild von fengshan.vi in LabVIEW 2026 in der lokalen experimentellen Umgebung der Autoren aufgenommen. Es sind keine Daten von Dritten oder vertrauliche Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Ansicht dieser Abbildung einzusehen.

LabVIEW-Benutzeroberfläche mit Lüftermodell, Abfrageeinstellungen und Kamerapfaden zur Systemüberwachung.
Abbildung 4: Konfigurationsseite von fan.vi. Das Lüfterexperiment wird in der RIP-Konfiguration mit dem Experimentnamen „fan“, dem tatsächlichen VI-Pfad, Schlüsselwortinformationen, einer Beschreibung und der Abtastfrequenz registriert. Dieser Screenshot wurde aus der RIP-Konfigurationsoberfläche aufgenommen, die mit LabVIEW 2026 und RIP WebService in der lokalen Versumgebung der Autoren verwendet wurde. Es sind keine Daten von Drittanbietern oder vertrauliche Informationen enthalten. Klicken Sie hier, um eine vergrößerte Ansicht dieser Abbildung anzuzeigen.

JavaScript-Code-Snippets für die UI-Logik einer Webanwendung; Methode zur dynamischen Elementerstellung.
Abbildung 5: Einstellungen der Experiment-ID und logikbasierte, auf Metadaten basierende Erzeugung der Benutzeroberfläche in den XHTML-Frontend-Dateien. Die Screenshots des XHTML-Codes stammen aus den Dateien Fan_Automatic_UI.xhtml und Motor_Automatic_UI.xhtml, die in Visual Studio Code geöffnet wurden. Die Seiten für Lüfter und Motor verwenden dieselbe Logik zum Lesen der Metadaten und zur Erzeugung der Steuerelemente; lediglich die Experiment-ID wird angepasst, sodass sie mit dem entsprechenden Namensfeld in der RIP-Konfiguration übereinstimmt. Die Screenshots des XHTML-Codes wurden aus den Dateien Fan_Automatic_UI.xhtml und Motor_Automatic_UI.xhtml aufgenommen, die im lokalen Entwicklungsumfeld der Autoren in Visual Studio Code geöffnet waren. Die Codedateien wurden von den Autoren speziell für dieses Protokoll vorbereitet. Es sind keine Daten von Drittanwendern oder vertrauliche Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Caddy-Server-Konfigurationsdiagramm mit Routen, Reverse-Proxys und Zugriffsport-Einrichtung.
Abbildung 6: Caddyfile-Konfiguration. Die Caddyfile definiert den lokalen Proxy-Zugriffsport, legt das Stammverzeichnis der Benutzeroberfläche fest, leitet die Routen /fan und /motor auf die entsprechenden XHTML-Dateien um und leitet Anfragen an /RIP/SSE* und /RIP* per Reverse-Proxy an den LabVIEW/RIP-WebService-Port weiter. Der Screenshot der Caddyfile-Konfiguration wurde aus der in Visual Studio Code geöffneten Caddyfile in der lokalen Entwicklungsumgebung der Autoren aufgenommen. Die Caddyfile wurde von den Autoren erstellt, um Caddy als lokalen Webserver und Reverse-Proxy zu konfigurieren. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Diagramm des Lüftersteuersystems mit Eingabereglern und Ausgabeanzeigen zur Leistungsoptimierung.
Abbildung 7: Web-Oberfläche der fan.vi. Dieser Screenshot der Web-Oberfläche wurde von der lokal bereitgestellten fan-Webseite der Autoren mit Mozilla Firefox aufgenommen. Die Frontend-Seite erzeugt automatisch Eingabesteuerungen und Ausgabeanzeigen basierend auf den von dem RIP-Server zurückgegebenen Variablen-Metadaten. Die dargestellten Steuerungen und Ausgabefelder wurden aus den RIP-Metadaten in der lokalen Versumgebung der Autoren generiert. Es werden keine Daten von Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Ansicht dieser Abbildung anzuzeigen.

Diagramm eines PID-Regelungssystems mit Motor, Positions-Rückkopplung und Diagramm der dynamischen Antwort.
Abbildung 8: Vorderseite des Motor-VI. Die Vorderseite enthält Bedienelemente für Sollwert, Kc, Ti, Td, Störgröße und Rücksetz-Steuerung sowie Anzeigen für Position, Spannung, Zeit und gemessene Winkelgeschwindigkeit. Dieser Screenshot wurde von der Vorderseite von Motor.vi in LabVIEW 2026 in der lokalen experimentellen Umgebung der Autoren aufgenommen. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Blockdiagramm eines PID-Reglers mit Gleichungen; Ein- und Ausgabefluss über Modelle zur Systemsteuerung.
Abbildung 9: Blockdiagramm des PID-Positionsregelungssystems für einen Gleichstrommotor. Das Diagramm zeigt den Signalpfad von der Soll-Ist-Wert-Differenz über die PID-Regelung, Spannungsbegrenzung, Störgrößenaufschaltung, elektrische Dynamik, mechanische Dynamik und Positionsaktualisierung bis zur Rückführung. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

LabVIEW-Diagramm der Steuerung mit Schieberegistern, Formelknoten in einer While-Schleife zur Prozesssteuerung.
Abbildung 10: Blockdiagramm der Motor-VI. Das Motor-Modell ist realisiert mithilfe einer While-Schleife, Schieberegistern, einem Formelknoten, einer Zeitsteuerung und Ausgabeanzeigen. Dieser Screenshot wurde aus dem Blockdiagramm von Motor.vi in LabVIEW 2026 in der lokalen experimentellen Umgebung der Autoren aufgenommen. Es sind keine Daten von Drittanbietern oder vertrauliche Informationen enthalten. Klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

LabVIEW-Motor-Modell-Einrichtungsoberfläche zur Steuerung und Konfiguration der Abtastung in der ingenieurwissenschaftlichen Analyse.
Abbildung 11: Konfigurationsseite von Motor.vi. Das Motorexperiment wird in der RIP-Konfiguration mit dem Verschiffsnamen Motor, dem tatsächlichen VI-Pfad, Schlüsselwortinformationen, einer Beschreibung und der Abtastrate registriert. Dieser Screenshot wurde aus der RIP-Konfigurationsoberfläche aufgenommen, die mit LabVIEW 2026 und RIP WebService in der lokalen Versuchsumgebung der Autoren verwendet wurde. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Ansicht dieser Abbildung anzuzeigen.

Motorkontrollsystem, PID-Abstimmungsschnittstelle mit Eingaberegler und Ausgabeanzeigen, Drehgeschwindigkeitsanzeige.
Abbildung 12: Web-Oberfläche von Motor.vi. Die Frontend-Seite erzeugt automatisch Eingabesteuerungen und Ausgabeanzeigen für das Experiment zur PID-Positionsregelung eines Gleichstrommotors. Dieser Screenshot der Web-Schnittstelle wurde von der lokal bereitgestellten Motor-Webseite der Autoren mit Mozilla Firefox aufgenommen. Die angezeigten Steuerelemente und Ausgabefelder wurden aus RIP-Metadaten in der lokalen Versumgebung der Autoren generiert. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Fehlermeldung im Webbrowser mit „ERR_CONNECTION_REFUSED“, die auf ein Problem bei der Verbindung zum lokalen Server hinweist.
Abbildung 13: Fehlgeschlagener Browserzugriff, wenn Caddy nicht ausgeführt wird. Wenn Caddy nicht gestartet ist, kann die weitergeleitete lokale Adresse http://localhost:8090/motor nicht erreicht werden, und der Browser zeigt eine ERR_CONNECTION_REFUSED-Meldung an. Dieses Fehlerverhalten zeigt an, dass der lokale Caddy-Proxydienst nicht verfügbar ist oder nicht am ausgewählten Zugriffsport lauscht. Dieser Browser-Screenshot wurde mit Mozilla Firefox in der lokalen Testumgebung der Autoren aufgenommen und zeigt den Zustand des fehlgeschlagenen Zugriffs, wenn der lokale Caddy-Proxy nicht lief. Es werden keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Virtuelle Lüftersimulations-Oberfläche mit Universitätslogo auf einer rotierenden Lüfterflügel.
Abbildung 14: Kommunikationsfehler bei RIP POST nach dem Laden der Seite. Die Browserkonsole zeigt einen 502 Bad Gateway-Fehler für die RIP POST-Anfrage an. Dieses Ergebnis zeigt an, dass die Webseite die Caddy-Proxy-Adresse erreicht hat, die Anfrage jedoch nicht erfolgreich an den RIP-WebService-Back-End weitergeleitet oder dort verarbeitet werden kann. Dieser Screenshot der Browserkonsole wurde mit den Mozilla Firefox Developer Tools in der lokalen Testumgebung der Autoren aufgenommen und zeigt einen Kommunikationsfehler mit dem Status RIP POST 502 Bad Gateway. Es werden keine Daten von Drittanwendern oder vertrauliche Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Virtuelle Lüftersteuerungs-Oberfläche mit Drehzahlüberwachung; Diagramm des Lüftermodell-Aufbaus; Netzwerkdatenanalyse.
Abbildung 15: Kommunikationsstatus auf der Browserseite im Normalbetrieb. Die Browser-Entwicklungswerkzeuge zeigen eine erfolgreiche Seitenladevorgänge, RIP-POST-Anfragen und eine aktive SSE-Anfrage mit expId=Lüfter. Diese Anfragen deuten darauf hin, dass die Web-Oberfläche über den Caddy-Proxy mit dem RIP-Webdienst kommuniziert und über den SSE-Kanal Echtzeitaktualisierungen empfängt. Dieser Screenshot der Browser-Entwicklungswerkzeuge wurde in der lokalen Bereitstellungsumgebung der Autoren mit Mozilla Firefox aufgenommen und zeigt normale RIP-POST- und SSE-Kommunikation. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Debugging-Konsole mit Netzwerkprotokollen und Ressourcennutzungsdiagramm zur Analyse eines LabVIEW-Programms.
Abbildung 16: Einzelne repräsentative Beobachtung der Browserkonsole und prozessbezogenen Ressourcen für das Lüfterexperiment. Der Screenshot wurde während eines lokalen Tests des Lüfterexperiments aufgezeichnet. Die Konsole zeigt die Zeit für Anfrage/Antwort von Metadaten, die Anzahl der Metadatenvariablen, die Zeit für die metadatenbasierte Generierung der Benutzeroberfläche, die Zeit zum Öffnen der SSE-Verbindung sowie die empfangenen SSE-Daten. Die Task-Manager-Ansicht zeigt die prozessbezogenen CPU- und Speicherwerte für die Browser- und LabVIEW-Prozesse zum Zeitpunkt der Aufnahme. Diese Werte stellen beschreibende Beobachtungen aus diesem einzelnen Test dar und entsprechen keinen replizierten Leistungsmessungen oder einem statistischen Benchmark. Der Screenshot wurde mit den Entwicklertools von Mozilla Firefox und dem Windows Task-Manager in der lokalen Testumgebung der Autoren erstellt. Mozilla Firefox wurde verwendet, um die Ausgabe der Browserkonsole aufzuzeichnen, und der Windows Task-Manager diente der Beobachtung der CPU- und Speicherauslastung der Browser- und LabVIEW-Prozesse. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Vergleich der Lüftersteuerungs-Benutzeroberfläche; RPM-, Strom- und Leistungswerte verknüpft in der Desktop- und Mobilinterface-Diagramm.
Abbildung 17: Gleichzeitiger Zugriff auf dieselbe RIP-basierte Webseite über einen Desktop-Browser und einen mobilen Browser. Die Webseite für das Lüfterexperiment wird gleichzeitig auf PC- und mobilen Geräten geöffnet, wobei beide Clients die automatisch generierten Steuerelemente und Ausgabewerte anzeigen. Auf die Desktop-Webseite wurde über Mozilla Firefox zugegriffen, auf die mobile Webseite über einen mobilen Browser in derselben lokalen Netzwerkumgebung. Die Screenshots stammen aus der eigenen lokalen Testumgebung der Autoren. Es sind keine Daten von Drittanwendern oder vertrauliche Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

VariablennameDatentypEingabe/AusgabePhysikalische BedeutungRolle im ModellBereich/Einstellung
EnableBooleanEingabeLüfterbetriebsschalterSteuert, ob das Modell das PWM-Signal erhält. Bei True gilt u = PWM; bei False gilt u = 0.True / False
PWMDBLEingabeAntriebseingangBestimmt die grundlegende Lüfterantriebsintensität und ist der Haupteingang zur Berechnung der stationären Drehzahl SteadyRPM.0-1, Schritt 0,01
LoadDBLEingabeLastkoeffizientBeschreibt die abschwächende Wirkung der Last auf die stationäre Drehzahl. Mit zunehmender Last nimmt die stationäre Drehzahl ab.0-1, Schritt 0,01
TauDBLEingabeZeitkonstante der ReaktionBestimmt, wie schnell sich die Lüfterdrehzahl von ihrem vorherigen Zustand der stationären Drehzahl nähert.0,1-5, Schritt 0,1
KMaxRPMDBLEingabeMaximale DrehzahlLegt die vom Modell maximal zulässige Drehzahl fest und wird zur Drehzahlbegrenzung und Normalisierung verwendet.500-6000, Schritt 100
DisturbanceDBLEingabeStöreingangStellt den Einfluss äußerer Störungen oder Lastschwankungen auf die stationäre Drehzahl, den Strom und die Leistung dar.0-1, Schritt 0,1
SpeedRPMDBLAusgabeTatsächliche DrehzahlStellt die aktuelle Ausgabedrehzahl des Lüfters dar und wird über eine trägheitsbehaftete Dynamik erster Ordnung aktualisiert.Vom Modell berechnet
SteadyRPMDBLAusgabeStationäre DrehzahlStellt die theoretische stationäre Drehzahl unter den aktuellen Eingangsbedingungen dar.Vom Modell berechnet
TimeSDBLAusgabeBetriebszeitStellt die kontinuierliche Betriebszeit des Modells dar.Vom Modell berechnet
SpeedNormDBLAusgabeNormalisierte DrehzahlStellt das Verhältnis von SpeedRPM zu KMaxRPM dar.0-1 oder vom Modell berechnet
CurrentADBLAusgabeStromStellt den geschätzten Modellstrom dar, der sich mit dem Antriebseingang und dem Störeingang ändert.Vom Modell berechnet
PowerWDBLAusgabeLeistungStellt die geschätzte Modellleistung dar, berechnet aus der Spannungskonstante und dem Strom.Vom Modell berechnet
SetpointDBLEingabeGewünschte PositionLegt die Position fest, die der Motor erreichen soll, und bildet zusammen mit der tatsächlichen Position Position den Regelfehler e.-3-3, Schritt 0,1
KcDBLEingabeProportionalverstärkungRegelt die Reaktionsstärke des PID-Reglers auf den Fehler.0-10, Schritt 0,1
TiDBLEingabeIntegrierzeitRegelt die integrierende Wirkung des PID-Reglers und dient zur Verringerung des stationären Fehlers.0-10, Schritt 0,1
TdDBLEingabeAbleitzeitRegelt die differenzierende Wirkung des PID-Reglers und dient zur Unterdrückung übermäßiger Fehleränderungen und zur Verbesserung der dynamischen Reaktion.0-5, Schritt 0,1
DisturbanceDBLEingabeStöreingangStellt eine äußere Störung dar, die am Motoreingang überlagert wird und zusammen mit der Regelspannung auf das Motor-Modell wirkt.0-10, Schritt 0,1
Reset controlBooleanEingabeReset-SteuerungLöst das Zurücksetzen des Modellzustands aus, sodass Position, Winkelgeschwindigkeit, Strom, Fehler und Integralanteil in ihren Anfangszustand zurückkehren.True / False
PositionDBLAusgabeTatsächliche PositionStellt die aktuelle Winkellage des Motors dar und dient als Rückkopplungsvariable für die PID-Regelung.Vom Modell berechnet
VoltageDBLAusgabeRegelspannungStellt die Ausgabe des PID-Reglers nach Spannungsbegrenzung dar und wirkt am Motoreingang.Vom Modell berechnet; auf -24 bis 24 V begrenzt
TimeDBLAusgabeBetriebszeitStellt die kontinuierliche Betriebszeit des Motor-Modells dar.Vom Modell berechnet
Measured angular velocityDBLAusgabeGemessene WinkelgeschwindigkeitStellt die aktuelle Winkelgeschwindigkeit des Motors dar und ist die mechanische Zustandsgröße des Motors.Vom Modell berechnet

Tabelle 1: Eingabe- und Ausgabevariablen, die in den Beispielen mit Lüfter und Gleichstrommotor verwendet werden. Die Tabelle enthält für jede Variable den Namen, den Datentyp, die Rolle als Eingabe- oder Ausgabevariable, die physikalische Bedeutung, den empfohlenen Bereich und die Schrittgröße.

ParameterWertPhysikalische BedeutungRolle im Modell
R1AnkerwiderstandStellt den Widerstandsterm im Ankerkreis des Motors dar und bestimmt den Spannungsabfall R × im in der Stromgleichung.
L0.5AnkerinduktivitätStellt die Induktivität des Ankerkreises dar und bestimmt die Änderungsrate des Stroms. Ein größeres L führt zu einer langsameren Stromantwort.
J0.01TrägheitsmomentStellt den Widerstand des Motorrotors gegen Änderungen der Winkelbeschleunigung dar und bestimmt, wie schnell sich die Winkelgeschwindigkeit ändert.
b0.1Viskoser DämpfungskoeffizientStellt die mechanische Dämpfung dar und beschreibt das dämpfende Drehmoment, das dem Anstieg der Winkelgeschwindigkeit während der Rotation entgegenwirkt.
Kt0.01DrehmomentkonstanteStellt den Proportionalitätsfaktor dar, der den Ankerstrom in elektromagnetisches Drehmoment umwandelt.
Ke0.01Konstante der GegenspannungStellt den Proportionalitätsfaktor dar, mit dem die Winkelgeschwindigkeit die Gegenspannung erzeugt, und beschreibt den Rückkopplungseffekt der Drehzahl auf den Strom.
Vmax24Maximale SteuerspannungStellt die Grenze der Ausgangsspannung des Reglers dar und hält die Spannung im Bereich von -24 V bis 24 V.
dt0.001Diskreter SimulationsschrittStellt das Zeitintervall für jede schleifenbasierte Zustandsaktualisierung dar und wird verwendet, um Strom, Winkelgeschwindigkeit, Position und Laufzeit zu aktualisieren.

Tabelle 2: Interne Parameter, die im PID-Positionsregelmodell für Gleichstrommotoren verwendet werden. Die Tabelle enthält elektrische und mechanische Parameter, Symbole, numerische Werte, Einheiten und deren Rolle im Modell.

Ergänzende Programmdateien: Vollständige Quell- und Konfigurationsdateien zur Reproduktion der Lüfter- und Gleichstrommotor-Beispiele. Die ergänzenden Programmdateien enthalten den LabVIEW-Formula-Node-Code, die Caddy-Reverse-Proxy-Konfiguration, XHTML-Frontend-Dateien und die LabVIEW-VI-Quelldateien, die in diesem Protokoll verwendet wurden. Die Datei Code in LabVIEW Formula Node.docx enthält den Formula-Node-Code für die PID-Regelungsmodelle zur Positionsregelung von Lüfter und Gleichstrommotor. Caddyfile.txt enthält die Konfiguration für den lokalen Webserver und den Reverse-Proxy. Fan_Automatic_UI.xhtml und Motor_Automatic_UI.xhtml enthalten die webbasierte Frontend-Logik auf Grundlage von Metadaten. fengshan.vi und Motor.vi sind die LabVIEW-Backend-VI-Dateien für die Lüfter- und Motorexperimente.Bitte klicken Sie hier, um diese Datei herunterzuladen.

Diskussion

Ein entscheidender Schritt in diesem Protokoll ist der standardisierte Aufbau und die Registrierung der LabVIEW-Hintergrund-VI. Die Steuerelemente und Anzeigen des Front Panels müssen klare und eindeutige Variablennamen verwenden, und ihre Datentypen müssen mit den von der Modellberechnung und dem RIP-Lese-/Schreibvorgang erwarteten Variablen übereinstimmen. In den beiden in diesem Protokoll verwendeten Beispielen werden skalare numerische Variablen als DBL-Steuerelemente oder -Anzeigen definiert, und boolesche Variablen werden als boolesche Steuerelemente festgelegt. Im Blockdiagramm muss außerdem eine kontinuierliche Zustandsaktualisierung über die While-Schleife, Shift-Register und Formelknoten gewährleistet sein, sodass Variablen wie Lüfterdrehzahl, Motorposition, Winkelgeschwindigkeit des Motors, Spannung und Zeit während der Ausführung aktualisiert werden können. Nachdem die VI erstellt wurde, muss der Experimentname in der RIP-Konfiguration exakt mit der Experiment-ID in der entsprechenden XHTML-Datei übereinstimmen, und der VI-Pfad muss auf die tatsächlich gespeicherte VI zeigen. Diese Einstellungen sind wichtig, da die Web-Oberfläche die Variablen jedes Experiments nicht fest codiert. Stattdessen hängt sie von den Metadaten ab, die vom RIP-Server zurückgegeben werden, um beschreibbare Variablen, lesbare Variablen, Datentypen und numerische Eigenschaften zu identifizieren10,11.

Die wichtigsten Fehlerbehebungsprobleme betreffen die Konsistenz zwischen der XHTML-Experiment-ID, der RIP-Konfiguration, dem RIP-WebService und den Caddy-Proxy-Einstellungen. Wenn die Experiment-ID in der XHTML-Datei nicht mit dem Experimentnamen in der RIP-Konfiguration übereinstimmt, kann die Webseite nicht die korrekten Metadaten anfordern und daher weder die erwarteten Steuerelemente noch die Ausgabefelder generieren. Falls der VI-Pfad falsch ist oder der RIP-WebService nicht gestartet wurde, kann die Webseite zwar geöffnet werden, jedoch nicht mit dem LabVIEW-Hintergrundsystem kommunizieren. Wenn Caddy nicht läuft, kann der Browser nicht auf die ausgewählte lokale Proxy-Adresse zugreifen und zeigt möglicherweise eine Fehlermeldung „ERR_CONNECTION_REFUSED“ an, wie in Abbildung 13 dargestellt. Wenn Caddy läuft, das Ziel des Reverse-Proxys aber nicht mit dem Port des RIP-WebServices übereinstimmt, kann die Seite geladen werden, während RIP-POST-Anfragen mit einem 502-Bad-Gateway-Fehler fehlschlagen, wie in Abbildung 14 gezeigt. Wenn die Route /RIP/SSE* nicht korrekt funktioniert, kann die Seite geöffnet werden und Steuerelemente anzeigen, aber die Ausgabewerte aktualisieren sich nicht in Echtzeit. Im Normalbetrieb sollten die Entwicklerwerkzeuge des Browsers eine erfolgreiche Seitenlade, RIP-POST-Anfragen und eine aktive SSE-Anfrage mit der korrekten Experiment-ID anzeigen, wie in Abbildung 15 dargestellt. Daher sollte die Fehlersuche zunächst mit der Überprüfung der Experiment-ID, des VI-Pfads, des RIP-WebService-Status, des Caddy-Laufzustands, der Proxy-Ports und der SSE-Route beginnen. Wenn die Kommunikation weiterhin ungewöhnlich verläuft, kann das Neustarten sowohl des RIP-WebServices als auch von Caddy, das Löschen des Browser-Cache oder das Wiederholen des Tests in einem anderen Browser helfen, browserabhängiges Verhalten von Konfigurationsproblemen bei RIP/Caddy zu unterscheiden.

Das vorliegende Protokoll ist in beiden Beispielen reproduzierbar, da für das Lüfterdrehzahlmodell und das DC-Motor-PID-Positionsregelungsmodell derselbe Build-Register-Deploy-Verify-Arbeitsablauf angewendet wird. Um die Abhängigkeit von spezialisierten Toolboxen zu verringern, wurden die Backend-VIs mithilfe grundlegender LabVIEW-Strukturen neu erstellt, darunter Bedienelemente und Anzeigen auf dem Bedienfeld, While-Schleifen, Schieberegister, Formelknoten sowie standardmäßige skalare numerische und boolesche Variablen. Die Reproduzierbarkeit über verschiedene LabVIEW-Versionen, Windows-Installationen und lokale Netzwerkumgebungen hinweg hängt jedoch weiterhin von Konfigurationsdetails ab, wie beispielsweise Dateipfaden, Zugriffsberechtigungen, lokalen Ports, Befehlen zum Starten von Diensten und dem Verhalten des Browsers. Der Arbeitsablauf kann auch auf hardwarebezogene Fernexperimente erweitert werden, sollte jedoch nicht als direkte Hardwareerkennung auf der Web-Seite interpretiert werden. Die Web-Oberfläche identifiziert die Bedienelemente und Anzeigen des LabVIEW-Bedienfelds über RIP-Metadaten. Sensoren, Aktoren, Messgeräte oder Prozessregelgeräte müssen daher zunächst über geeignete Hardwaretreiber, Datenerfassungsmodulen, Gerätesteuerungsmodulen oder andere Hardwareanpassungsmechanismen mit dem Backend-VI von LabVIEW verbunden und verarbeitet werden. Sobald die Hardwaremesswerte und Steuerbefehle den Anzeigen und Bedienelementen des Bedienfelds zugeordnet sind, kann die auf RIP basierende Web-Oberfläche diese Variablen genauso erkennen wie die in diesem Protokoll verwendeten Simulationsvariablen. Frühere Studien zu auf LabVIEW basierenden Fernlaboren haben gezeigt, dass LabVIEW als Backend-Umgebung für Fernsteuerungsexperimente, Robotikexperimente, Prozessregelstrecken, Sensordatenerfassung und die Interaktion mit physischen Geräten verwendet werden kann9,12,17,18,19,20.

Abbildung 16 zeigt ein einzelnes repräsentatives Implementierungsbeispiel, das während eines lokalen Fan-Experiments aufgezeichnet wurde. Der Frontend-Code wurde so instrumentiert, dass er die Zeit für Metadaten-Anfrage/Antwort, die Anzahl der Metadaten-Variablen, die Zeit für die Erzeugung der nutzerspezifischen Oberfläche basierend auf Metadaten, die Zeit zum Öffnen der SSE-Verbindung sowie die empfangenen SSE-Daten aufzeichnet. In diesem Beispiel meldete die Browserkonsole eine Metadaten-Anfrage/Antwort-Zeit von 68,00 ms, identifizierte 7 beschreibbare und 7 lesbarere Variablen aus den RIP-Metadaten, erzeugte die entsprechenden UI-Elemente innerhalb von 2,00 ms und öffnete die SSE-Verbindung innerhalb von 16,00 ms. Die wiederholten SSE-Datensätze zeigten, dass Ausgangsvariablen wie SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA und PowerW kontinuierlich vom LabVIEW-Backend empfangen wurden. Die Task-Manager-Ansicht im selben lokalen Testzustand zeigte etwa 1,5 % CPU-Auslastung und 391,7 MB Speicher für den Firefox-Prozess, während der LabVIEW-Prozess zum Zeitpunkt der Aufnahme 0 % CPU-Auslastung und 9,2 MB Speicher belegte. Diese Beobachtungen liefern grundlegende Hinweise darauf, dass die Abrufung von Metadaten, die Erzeugung der nutzerspezifischen Oberfläche basierend auf Metadaten, die RIP/SSE-Kommunikation sowie der CPU-Overhead auf Prozessebene in der lokalen Einsatzumgebung beobachtet werden konnten. Diese Daten dienen jedoch der Verifizierung auf Implementierungsebene und stellen keine umfassende Leistungsbewertung dar. Eine systematische Leistungsanalyse unter verschiedenen Browsern, wiederholten Versuchen, höherer Variablenlast, physischer Hardware und mehreren gleichzeitig nutzenden Benutzern bleibt zukünftigen Arbeiten vorbehalten.

Diese Methode weist jedoch auch Einschränkungen auf, insbesondere wenn sie auf komplexe Datenstrukturen, Hardware-Experimente und Mehrbenutzerbetrieb ausgeweitet wird. Der derzeitige Workflow eignet sich am besten für skalare numerische und boolesche Ein- und Ausgabewerte. Er bietet keine automatische vollständige Unterstützung für komplexe Arrays, Cluster, geschachtelte Datenstrukturen, Diagrammbeziehungen oder domänenspezifische Visualisierungen. Solche Fälle erfordern möglicherweise zusätzliche Regeln zur Metadatenzuordnung oder manuell erstellte Frontend-Komponenten. Die automatisch generierte Benutzeroberfläche kann grundlegende Steuerelemente und Anzeigen aus den Variablen-Metadaten erzeugen, kann jedoch nicht automatisch die physikalischen Beziehungen zwischen den Variablen erschließen, die geeignetste Visualisierung auswählen oder experimentbezogene Sicherheitsinteraktionen entwerfen. Wenn der Workflow auf reale Geräte ausgedehnt wird, sind zusätzliche Aspekte zu berücksichtigen, darunter Hardwaretreiber, Gerätekalibrierung, Abtastbeschränkungen, Aktuator-Grenzen, Not-Aus-Logik, Authentifizierung und Mechanismen zur Schreibzugriffskontrolle bei Mehrfachnutzung. Die aktuelle Bereitstellung kann außerdem von mehreren Client-Geräten aus über Standard-Webbrowser in derselben lokalen Netzwerkumgebung aufgerufen werden. Wie in Abbildung 17 gezeigt, wurde dieselbe Experimentseite für einen Lüfter gleichzeitig in einem Desktop-Browser und in einem mobilen Browser geöffnet, wobei beide Clients die automatisch generierten Steuerelemente und die entsprechenden Ausgabewerte anzeigten. Diese Beobachtung zeigt einen grundlegenden simultanen Mehrfachclient-Zugriff zum Anzeigen und Interagieren mit derselben Experimentseite an. Dies sollte jedoch nicht als vollständiges Mehrbenutzer-Steuerungskonzept interpretiert werden, da die derzeitige Implementierung keine dedizierte Benutzerauthentifizierung, Steuerungssperren, parallele Schreibarbitrierung, Schreibwarteschlangen oder Konfliktlösungsmechanismen enthält. Diese Einschränkungen stimmen mit früheren Studien zu Fernlaboren überein, bei denen komplexe oder kollaborative Fernlabore in der Regel experimentbezogene Schnittstellendesigns, Synchronisationsmechanismen, Sicherheitsbeschränkungen und Benutzerverwaltungslogik erfordern13,14,15,16,17.

Der methodologische Wert dieses Protokolls liegt nicht darin, eine neue RIP-Architektur einzuführen oder die von RIP unterstützten Datentypen zu erweitern. Vielmehr besteht sein Nutzen darin, einen vollständigen und reproduzierbaren Implementierungsweg bereitzustellen, um einen etablierten, auf RIP basierenden Mechanismus zur automatischen Benutzeroberflächengenerierung auf verschiedene LabVIEW-Systeme anzuwenden. Im Vergleich zum manuellen Schreiben einer individuellen Weboberfläche für jedes Experiment reduziert dieser Arbeitsablauf die wiederholte Implementierung grundlegender Steuerungslayouts, Variablenbindungen sowie Lese-/Schreibkommunikationslogik, sofern die Variablen der Backend-VI kompatibel bereitgestellt werden8,9,10,11. Das Protokoll ist daher nützlich für die ingenieurwissenschaftliche Ausbildung, die Entwicklung von Fernlaboren sowie die schnelle Bereitstellung risikoarmer Simulations- oder Lehrversuche, die eine parameterbasierte Anpassung über den Browser und die Echtzeit-Überwachung des Systemzustands erfordern. Zukünftige Arbeiten sollten den Arbeitsablauf auf komplexere Datenstrukturen, physikalische Experimentiergeräte, formale Mehrbenutzer-Zugriffskontrollen sowie eine quantitative Leistungsbewertung ausdehnen, einschließlich der Zeit für die Oberflächengenerierung, Kommunikationslatenz, Synchronisationsstabilität, Serverlast, CPU-Overhead und die Benutzerfreundlichkeit der Oberfläche.

Offenlegungen

Die Autoren verwendeten KI-gestützte Werkzeuge ausschließlich zur sprachlichen Überarbeitung. Der gesamte wissenschaftliche Inhalt, die experimentellen Verfahren, die Software-Implementierung, die Abbildungen, Ergebnisse, Interpretationen und die endgültige Formulierung wurden von den Autoren geprüft, korrigiert und genehmigt. Es wurde kein KI-Tool zur Erzeugung experimenteller Daten verwendet.

Danksagungen

Diese Arbeit wurde unterstützt durch die Ausbildungsprogramme für Studierende zur Förderung der Innovation der Wuhan-Universität.

Materialien

Liste der in diesem Artikel verwendeten Materialien
NameUnternehmenKatalognummerKommentare
Caddy-Proxy-ServerCaddyN/VReverse-Proxy, der zur Bereitstellung der Web-Oberfläche und zur Weiterleitung von /RIP-Anfragen an den RIP-WebService verwendet wird
CaddyfileVon den Autoren erstelltN/VDefiniert Statische-Datei-Routen und Reverse-Proxy-Routen für die RIP-Kommunikation
Fan_Automatic_UI.xhtmlVon den Autoren erstelltN/VWeb-Frontend basierend auf Metadaten für das Fan-Experiment
LabVIEWNational Instruments2026Software zur Erstellung und Ausführung von fengshan.vi und Motor.vi
Microsoft Windows-BetriebssystemMicrosoftWin11Betriebssystem zur Ausführung von LabVIEW, RIP-WebService, Caddy und dem Browser
Motor_Automatic_UI.xhtmlVon den Autoren erstelltN/VWeb-Frontend basierend auf Metadaten für das Motor-Experiment
Mozilla Firefox Desktop-BrowserMozilla2026Desktop-Browser zur Zugriffnahme auf die Web-Oberfläche, zur Nutzung von Entwicklerwerkzeugen, zur Beobachtung von Zeit- und Ressourcenverbrauch sowie zur Erstellung von Screenshots von Netzwerk- und Konsolenausgaben
RIP-WebServiceUNEDLabshttps://github.com/Nebulous-Systems/rip-server_labviewEmpfängt RIP-POST-Anfragen und stellt die WebService-Kommunikationsschicht bereit, die vom Browser-Frontend verwendet wird
Windows-Task-ManagerMicrosoftIm Betriebssystem integriertWird verwendet, um CPU- und Speicherverbrauch auf Prozessebene für den Browser und LabVIEW-Prozesse aufzuzeichnen

Referenzen

  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.

Nachdrucke und Genehmigungen

Tags

Web Benutzeroberfl cheautomatische UI Generierungvirtuelle InstrumenteRIP Server KonfigurationReverse ProxyCaddy ProxyPID Positionsregelungvariable Metadaten

Dieser Artikel wurde veröffentlicht

Video demnächst verfügbar

Kontaktieren Sie uns
Der Bibliothek empfehlen

Datenschutz

Nutzungsbedingungen

Richtlinien

Urheberrecht © 2026 MyJoVE Corporation. Alle Rechte vorbehalten.