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

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 geworden^1,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 belegt⁵. Bei Regelungssystemexperimenten müssen Benutzer in der Regel Eingabeparameter in einem Browser anpassen und Ausgabezustände in Echtzeit beobachten^6,7. Herkömmliche Methoden erfordern typischerweise eine separate Webseite, eine Logik zur Steuerungsbindung sowie eine Schnittstelle zur Datenkommunikation für jedes experimentelle Objekt^8,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 bereit^10,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 Schreibmethoden¹¹. 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 erstellen¹¹. 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 bereitstellen^8,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 aufzubauen^10,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 erfordern^3,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 Sicherheitsinteraktionen¹¹. 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 Fallstudie¹¹. Webfähige Fernlabor-Architekturen, die interaktive Schnittstellen mit Ingenieursoftware und LabVIEW kombinieren, wurden ebenfalls in früheren Studien beschrieben^9,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 nutzen^10,11. Es ist weniger geeignet als eigenständige Lösung für Experimente, die komplexe Datenstrukturen, spezialisierte Visualisierungen, strikte Hardware-Sicherheitsverriegelungen oder Mehrnutzer-Schreibarbitrierung erfordern¹¹. 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 muss^9,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.¹¹.
   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 erfolgreiches Ergebnis zeigt sich anhand von drei Beobachtungen. 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üferdrehzahl, 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 Ausgangsantwort, 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 kann. Im Gegensatz dazu zeigt Abbildung 15 einen normalen browserseitigen Kommunikationszustand. Die Entwicklertools des Browsers zeigen erfolgreiches Laden der Seite, erfolgreiche RIP-POST-Anfragen und eine aktive SSE-Anfrage mit expId=fan an, was darauf hinweist, dass das Web-Frontend über den Caddy-Proxy mit dem RIP-WebService kommuniziert und über den SSE-Kanal Echtzeit-Updates empfängt.

Zusammen zeigen die erfolgreichen Ergebnisse bezüglich Lüfter und Motor sowie die browserseitigen Diagnoseergebnisse, dass derselbe metadatenbasierte 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 Fehlerbehebungsverfahren im Abschnitt „Diskussion“ erörtert werden.

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 Querursprungs-Zugriff, und die Web-Benutzeroberfläche generiert Steuerelemente automatisch. Der Name und das Logo von Caddy werden nur angezeigt, um die im Workflow verwendete Caddy-Webserver-/Proxy-Komponente zu identifizieren. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 2: Vorderseite des Ventilator-VI. Die Vorderseite enthält Eingabesteuerungen für Enable, PWM, Load, Tau, KMaxRPM und Disturbance sowie Ausgabeanzeigen für SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA und PowerW. Dieser Screenshot wurde von der Vorderseite von fengshan.vi in LabVIEW 2026 in der lokalen Versumgebung 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.

Abbildung 3: Blockschaltbild der Lüfter-VI. Das Lüftermodell ist mithilfe einer While-Schleife, Shift-Register, 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 Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Abbildung 4: Konfigurationsseite von fan.vi. Das Lüfterexperiment ist in der RIP-Konfiguration registriert mit dem Experimentnamen „fan“, dem tatsächlichen VI-Pfad, Schlüsselwortinformationen, einer Beschreibung und der Abtastfrequenz. Dieser Screenshot wurde aus der RIP-Konfigurationsoberfläche aufgezeichnet, die mit LabVIEW 2026 und RIP WebService in der lokalen Versumgebung der Autoren verwendet wurde. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 5: Einstellungen der Experiment-ID und metadatenbasierte Logik zur UI-Generierung in den XHTML-Frontend-Dateien. Die Screenshots des XHTML-Codes wurden aus den in Visual Studio Code geöffneten Dateien Fan_Automatic_UI.xhtml und Motor_Automatic_UI.xhtml erstellt. Die Seiten für Lüfter und Motor verwenden dieselbe Logik zum Lesen der Metadaten und zur Generierung der Steuerelemente; lediglich die Experiment-ID wird geändert, um dem entsprechenden Namensfeld in der RIP-Konfiguration zu entsprechen. Die Screenshots des XHTML-Codes wurden aus den in Visual Studio Code in der lokalen Entwicklungsumgebung der Autoren geöffneten Dateien Fan_Automatic_UI.xhtml und Motor_Automatic_UI.xhtml aufgenommen. Die Codedateien wurden von den Autoren speziell für dieses Protokoll erstellt. Es sind keine Daten von Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 6: Caddyfile-Konfiguration. Die Caddyfile-Datei definiert den lokalen Proxy-Zugangsport, 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-Datei in der lokalen Entwicklungsumgebung der Autoren erstellt. Die Caddyfile-Datei 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.

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 Oberflächenseite erzeugt automatisch Eingabesteuerungen und Ausgabeanzeigen basierend auf den Variablen-Metadaten, die vom RIP-Server zurückgegeben werden. Dieser Screenshot der Web-Oberfläche wurde von der lokal bereitgestellten Fan-Webseite der Autoren mit Mozilla Firefox aufgenommen. Die angezeigten Steuerungen und Ausgabefelder wurden aus den RIP-Metadaten in der lokalen Versumgebung der Autoren generiert. Es sind keine Daten von Dritten oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Abbildung 8: Vorderseite des Motor-VI. Die Vorderseite enthält Bedienelemente für Sollwert, Kc, Ti, Td, Störgröße und Rücksetzung 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 Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 9: Modellschema der PID-Positionsregelung für einen Gleichstrommotor. Das Diagramm zeigt den Signalpfad von der Soll-Ist-Abweichung ü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.

Abbildung 10: Blockschaltbild der Motor-VI. Das Motor-Modell ist realisiert mit einer While-Schleife, Schieberegistern, einem Formelknoten, Zeitsteuerungslogik und Ausgangsanzeigen. Dieser Screenshot wurde aus dem Blockschaltbild von Motor.vi in LabVIEW 2026 in der lokalen experimentellen Umgebung der Autoren aufgenommen. Es sind keine Daten von Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 11: Konfigurationsseite von Motor.vi. Das Motorexperiment ist in der RIP-Konfiguration mit dem Experimentnamen Motor, dem tatsächlichen VI-Pfad, Schlüsselwortinformationen, Beschreibung und Abtastrate registriert. Dieser Screenshot wurde aus der RIP-Konfigurationsoberfläche aufgezeichnet, die mit LabVIEW 2026 und RIP WebService in der lokalen Versumgebung der Autoren verwendet wurde. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 12: Web-Oberfläche von Motor.vi. Die Oberfläche erzeugt automatisch Eingabesteuerungen und Ausgabedatenanzeige für das PID-Positionsregelungsexperiment des Gleichstrommotors. Dieser Screenshot der Web-Oberfläche wurde von der lokal bereitgestellten Motor-Webseite der Autoren mit Mozilla Firefox aufgenommen. Die angezeigten Steuerungen und Ausgabefelder wurden aus den RIP-Metadaten in der lokalen Versumgebung der Autoren generiert. Es sind keine Daten von Drittanbietern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

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 Fehlermuster weist darauf hin, 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 ausgeführt wurde. Es sind keine Daten von Drittanwendern oder vertraulichen Informationen enthalten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 14: Kommunikationsfehler bei RIP POST nach dem Laden der Seite. Die Browser-Konsole zeigt einen 502 Bad Gateway-Fehler für die RIP POST-Anfrage an. Dieses Ergebnis weist darauf hin, 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 Browser-Konsole wurde mit den Mozilla Firefox Developer Tools in der lokalen Bereitstellungsumgebung der Autoren aufgenommen und zeigt einen Kommunikationsfehler bei RIP POST mit 502 Bad Gateway. Es werden keine Daten von Drittanwendern oder vertraulichen Informationen eingeschlossen. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 15: Kommunikationsstatus auf der Browserseite im Normalbetrieb. Die Browser-Entwicklungswerkzeuge zeigen eine erfolgreiche Seitenlade, RIP-POST-Anfragen und eine aktive SSE-Anfrage mit expId=fan. Diese Anfragen deuten darauf hin, dass die Web-Frontend über den Caddy-Proxy mit dem RIP-WebService kommuniziert und über den SSE-Kanal Echtzeit-Updates 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 vergrößerte Version dieser Abbildung anzusehen.

Abbildung 16: Einzelne repräsentative Beobachtung von 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 Metadatenanforderung/-antwort, die Anzahl der Metadatenvariablen, die Zeit für die nutzungsoberflächengenerierung basierend auf Metadaten, die Zeit zum Öffnen der SSE-Verbindung sowie die empfangenen SSE-Daten an. Die Task-Manager-Ansicht zeigt zum Zeitpunkt der Aufnahme die prozessbezogenen CPU- und Speicherwerte für die Browser- und LabVIEW-Prozesse. Diese Werte stellen beschreibende Beobachtungen aus diesem einzelnen Test dar und keine replizierten Leistungsmessungen oder statistischen Benchmarks. Der Screenshot wurde mit den Mozilla Firefox Developer Tools 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.

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 Bildschirmfotos stammen aus der eigenen lokalen Testumgebung der Autoren. Es werden keine Daten von Drittanwendern oder vertrauliche Informationen verwendet. Bitte klicken Sie hier, um eine vergrößerte Version dieser Abbildung anzusehen.

Variablenname	Datentyp	Eingabe/Ausgabe	Physikalische Bedeutung	Rolle im Modell			Bereich/Einstellung
Enable	Boolean	Eingabe	Lüfterbetriebsschalter	Steuert, ob das Modell das PWM-Signal erhält. Wenn True, dann u = PWM; wenn False, dann u = 0.			True / False
PWM	DBL	Eingabe	Ansteuereingang	Bestimmt die grundlegende Lüfterantriebsintensität und ist der Haupteingang zur Berechnung der stationären Drehzahl SteadyRPM.			0-1, Schritt 0,01
Load	DBL	Eingabe	Lastkoeffizient	Beschreibt 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
Tau	DBL	Eingabe	Zeitkonstante der Reaktion	Bestimmt, wie schnell sich die Lüfterdrehzahl von ihrem vorherigen Zustand aus der stationären Drehzahl annähert.			0,1-5, Schritt 0,1
KMaxRPM	DBL	Eingabe	Maximale Drehzahl	Legt die vom Modell zulässige maximale Drehzahl fest und wird zur Drehzahlbegrenzung und Normalisierung verwendet.			500-6000, Schritt 100
Disturbance	DBL	Eingabe	Störeingang	Stellt den Einfluss äußerer Störungen oder Lastschwankungen auf die stationäre Drehzahl, den Strom und die Leistung dar.			0-1, Schritt 0,1
SpeedRPM	DBL	Ausgabe	Tatsächliche Drehzahl	Stellt die aktuelle Ausgabedrehzahl des Lüfters dar und wird über eine dynamische Trägheitsgleichung erster Ordnung aktualisiert.			Vom Modell berechnet
SteadyRPM	DBL	Ausgabe	Stationäre Drehzahl	Stellt die theoretische stationäre Drehzahl unter den aktuellen Eingangsbedingungen dar.			Vom Modell berechnet
TimeS	DBL	Ausgabe	Betriebszeit	Stellt die kontinuierliche Laufzeit des Modells dar.			Vom Modell berechnet
SpeedNorm	DBL	Ausgabe	Normalisierte Drehzahl	Stellt das Verhältnis von SpeedRPM zu KMaxRPM dar.			0-1 oder vom Modell berechnet
CurrentA	DBL	Ausgabe	Strom	Stellt den geschätzten Modellstrom dar, der sich mit dem Ansteuereingang und dem Störeingang ändert.			Vom Modell berechnet
PowerW	DBL	Ausgabe	Leistung	Stellt die geschätzte Modellleistung dar, berechnet aus der Spannungskonstante und dem Strom.			Vom Modell berechnet
Setpoint	DBL	Eingabe	Gewünschte Position	Legt die Position fest, die der Motor erreichen soll, und bildet zusammen mit der tatsächlichen Position Position den Regelfehler e.			-3 bis 3, Schritt 0,1
Kc	DBL	Eingabe	Proportionalverstärkung	Stellt die Reaktionsstärke des PID-Reglers auf den Fehler ein.			0-10, Schritt 0,1
Ti	DBL	Eingabe	Integralzeit	Stellt die integrierende Wirkung des PID-Reglers ein und dient zur Verringerung des stationären Regelfehlers.			0-10, Schritt 0,1
Td	DBL	Eingabe	Ableitzeit	Stellt die differenzierende Wirkung des PID-Reglers ein und dient zur Unterdrückung zu schneller Fehleränderungen und zur Verbesserung der dynamischen Reaktion.			0-5, Schritt 0,1
Disturbance	DBL	Eingabe	Störeingang	Stellt eine externe Störung dar, die am Motoreingang überlagert wird und gemeinsam mit der Steuerspannung auf das Motor-Modell wirkt.			0-10, Schritt 0,1
Reset control	Boolean	Eingabe	Rücksetzsteuerung	Löst das Zurücksetzen des Modellzustands aus, sodass Position, Winkelgeschwindigkeit, Strom, Fehler und Integralterm in ihren Anfangszustand zurückkehren.			True / False
Position	DBL	Ausgabe	Tatsächliche Position	Stellt die aktuelle Winkellage des Motors dar und dient als Rückkopplungsvariable für die PID-Regelung.			Vom Modell berechnet
Voltage	DBL	Ausgabe	Steuerspannung	Stellt die Ausgabe des PID-Reglers nach Spannungsbegrenzung dar und wirkt am Motoreingang.			Vom Modell berechnet; begrenzt auf -24 bis 24 V
Time	DBL	Ausgabe	Betriebszeit	Stellt die kontinuierliche Laufzeit des Motor-Modells dar.			Vom Modell berechnet
Gemessene Winkelgeschwindigkeit	DBL	Ausgabe	Gemessene Winkelgeschwindigkeit	Stellt 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 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.

Parameter	Wert	Physikalische Bedeutung	Rolle im Modell
R	1	Widerstand der Ankerwicklung	Stellt den ohmschen Widerstand im Ankerkreis des Motors dar und bestimmt den Spannungsabfall R × im in der Stromgleichung.
L	0,5	Induktivität der Ankerwicklung	Stellt die Induktivität des Ankerkreises dar und bestimmt die Änderungsrate des Stroms. Eine größere L führt zu einer langsameren Stromantwort.
J	0,01	Trägheitsmoment	Stellt den Widerstand des Motorrotors gegenüber Änderungen der Winkelbeschleunigung dar und bestimmt, wie schnell sich die Winkelgeschwindigkeit ändert.
b	0,1	Viskoser Dämpfungskoeffizient	Stellt die mechanische Dämpfung dar und beschreibt das dämpfende Drehmoment, das der Zunahme der Winkelgeschwindigkeit während der Rotation entgegenwirkt.
Kt	0,01	Drehmomentkonstante	Stellt den Proportionalitätsfaktor dar, der den Ankerstrom in elektromagnetisches Drehmoment umwandelt.
Ke	0,01	Konstante der Gegenspannung	Stellt den Proportionalitätsfaktor dar, mit dem die Winkelgeschwindigkeit die Gegenspannung erzeugt, und beschreibt den Rückkopplungseffekt der Drehzahl auf den Strom.
Vmax	24	Maximale Steuerspannung	Stellt die Grenze der Ausgangsspannung des Reglers dar und hält die Spannung im Bereich von -24 V bis 24 V.
dt	0,001	Diskreter Simulationsschritt	Stellt das Zeitintervall für jede schleifenbasierte Zustandsaktualisierung dar und wird verwendet, um Strom, Winkelgeschwindigkeit, Position und Simulationszeit zu aktualisieren.

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

Ergänzende Programmierdateien: Vollständige Quell- und Konfigurationsdateien zur Reproduktion der Beispiele mit Lüfter und Gleichstrommotor. Die ergänzenden Programmierdateien enthalten den LabVIEW-Formula-Node-Code, die Caddy-Reverse-Proxy-Konfiguration, XHTML-Frontend-Dateien sowie 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 Modelle der PID-Positionsregelung von Lüfter und Gleichstrommotor. Caddyfile.txt enthält die Konfiguration des lokalen Webservers und des Reverse-Proxys. 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 Experimente mit Lüfter und Motor.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 identifizieren^10,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 kann^{9,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 erfordern^{13,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 werden^8,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.

Materialien

Liste der in diesem Artikel verwendeten Materialien

Name	Unternehmen	Katalognummer	Kommentare
Caddy-Proxy-Server	Caddy	N/V	Reverse-Proxy, der zur Bereitstellung der Web-Oberfläche und zur Weiterleitung von /RIP-Anfragen an den RIP-WebService verwendet wird
Caddyfile	Von den Autoren erstellt	N/V	Definiert Statische-Datei-Routen und Reverse-Proxy-Routen für die RIP-Kommunikation
Fan_Automatic_UI.xhtml	Von den Autoren erstellt	N/V	Web-Frontend basierend auf Metadaten für das Fan-Experiment
LabVIEW	National Instruments	2026	Software zur Erstellung und Ausführung von fengshan.vi und Motor.vi
Microsoft Windows-Betriebssystem	Microsoft	Win11	Betriebssystem zur Ausführung von LabVIEW, RIP-WebService, Caddy und dem Browser
Motor_Automatic_UI.xhtml	Von den Autoren erstellt	N/V	Web-Frontend basierend auf Metadaten für das Motor-Experiment
Mozilla Firefox Desktop-Browser	Mozilla	2026	Desktop-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-WebService	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Empfängt RIP-POST-Anfragen und stellt die WebService-Kommunikationsschicht bereit, die vom Browser-Frontend verwendet wird
Windows-Task-Manager	Microsoft	Im Betriebssystem integriert	Wird verwendet, um CPU- und Speicherverbrauch auf Prozessebene für den Browser und LabVIEW-Prozesse aufzuzeichnen