A Protocol for Automatic Generation of Web-Based Interfaces for LabVIEW Applications Using the Remote Interoperability Protocol

Summary

This study validates a remote interoperability protocol (RIP)-based automatic Web user interface generation with two distinct LabVIEW systems—a fan model and a direct current motor position-control model—and provides a reproducible procedure for constructing, registering, deploying, and testing both examples.

Abstract

Remote experimental platforms enable local simulation models or physical devices to be accessed over a network, but conventional Web front ends typically require a separate page, control layout, and data communication logic for each experiment, which increases development costs. This work validates an established workflow for automatically generating a Web user interface (UI) from LabVIEW virtual instruments (VIs) using the remote interoperability protocol (RIP) and provides a reproducible protocol for implementing it. The workflow constructs LabVIEW VIs that define input controls and output indicators on the Front Panel, registers each VI in RIP Server Configuration, reads the resulting variable metadata, and generates the corresponding Web controls and output displays. Caddy is used as a reverse proxy to unify the front-end static-file path and RIP application programming interface (API) request path. The workflow is evaluated with two distinct systems: a fan speed model and a direct current (DC) motor proportional-integral-derivative (PID) position-control model. In both cases, the Web page identifies the exposed variables, writes user inputs to the LabVIEW back end, reads model outputs, and generates the interface from RIP metadata. These results validate the same automatic UI-generation process across two different dynamic systems and document the steps required to reproduce it.

Introduction

With the development of remote experiments, online teaching, and Internet-of-Things technologies, providing Web-based access to local simulation models or experimental devices has become an important direction for experimental platform development^1,2,3,4. Recent work has further integrated Internet-of-Things-equipped laboratories with project-based learning and local or remote access, demonstrating the continued development of flexible and networked experimental platforms in engineering education⁵. For control system experiments, users usually need to adjust input parameters in a browser and observe output states in real time^6,7. Conventional methods typically require a separate Web page, control-binding logic, and data communication interface for each experimental object^8,9. When the variables in the back-end model change, the front-end page often must be modified accordingly, which creates substantial repeated development work and limits rapid expansion of the experimental platform.

Remote interoperability protocol (RIP) provides a middleware layer between back-end experimental models and Web front ends^10,11. In the RIP-based automatic UI-generation approach described in previous work, the RIP Server provides metadata for each experiment, including variable names, input/output attributes, data types, minimum values, maximum values, precision, descriptions, and the available read/write methods¹¹. A Web client can then use this metadata to create the corresponding HTML elements, such as labels, numeric input fields, sliders, Boolean controls, and output displays, during page loading or refresh¹¹. The present protocol does not reimplement or redefine the RIP specification. Instead, it uses the existing open-source RIP service and RIP-based metadata-to-HTML UI-generation logic as the foundation for communication and interface generation, and focuses on the reproducible construction, registration, proxy deployment, and verification of two LabVIEW VI examples.

Compared with conventional custom Web interface development, RIP-based automatic UI generation reduces the need to implement control layouts, variable-binding logic, and basic communication functions when multiple LabVIEW experiments expose comparable scalar input and output variables^8,9,10,11. After a new VI is registered and its variables are available to the RIP Server, the same metadata-reading and control-generation logic can be reused to construct the basic Web interface^10,11. This feature is useful for rapid deployment, teaching demonstrations, and remote-laboratory platforms that require consistent access to several similar experiments^3,8,9. However, the automatically generated interface also has limitations. It does not fully infer the physical relationships among variables, automatically determine chart mappings, or design domain-specific visualization and safety interactions¹¹. Therefore, manual Web interface development remains preferable when an experiment requires highly customized graphics, complex user workflows, advanced visualization, hardware safety interlocks, or multiuser write arbitration.

The overall workflow of the protocol is summarized in Figure 1. In this workflow, a LabVIEW VI first defines the required input controls and output indicators on the Front Panel. The VI is then registered in RIP Server Configuration by specifying the experiment name and the VI path. After registration, the RIP Server reads the metadata of the selected experiment and provides read/write access to the available variables. The XHTML Web page uses the returned metadata to generate the corresponding input controls and output displays automatically, while Caddy provides a unified access path for the static Web page and RIP communication routes. The fan and direct current motor models are used in this study as two implementations of the same workflow. For other LabVIEW experiments that provide compatible scalar, numeric, and Boolean variables, developers can follow the same build-register-deploy-verify workflow to create an automatically generated Web interface, while adding experiment-specific visualization, safety logic, or complex data handling when required.

This article does not propose a new RIP architecture or extend the range of data types already supported by RIP. Instead, it uses RIP as the established communication and metadata-based UI-generation mechanism and focuses on validating the same process with two different LabVIEW systems while documenting a reproducible implementation protocol. Previous work has presented a basic method for automatic Web UI generation based on RIP metadata and has used an online servo motor experiment as a case study¹¹. Web-enabled remote-laboratory architectures combining interactive interfaces with engineering software and LabVIEW have also been reported in earlier studies^9,12. However, during practical reproduction, some LabVIEW models in the original case were affected by software version and module compatibility, making them difficult to use directly in a newer environment. The present work, therefore, reconstructs two compatible back-end VIs—a fan model and a direct current (DC) motor proportional-integral-derivative (PID) position-control model—and applies the same metadata-driven UI-generation process to both. The contribution is the cross-system validation of the established RIP workflow and a detailed protocol for reproducing the process, rather than an extension of RIP generality.

The intended users of this protocol are researchers, instructors, and laboratory developers who already use LabVIEW VIs and need to expose simulation models or low-risk experimental systems through a Web browser without independently implementing a complete custom front end for each model. The protocol is particularly suitable for experiments that use standard numeric and Boolean variables, parameter adjustment, and real-time state monitoring^10,11. It is less suitable as a standalone solution for experiments that require complex data structures, specialized visualization, strict hardware safety interlocks, or multiuser write arbitration¹¹. The goal of this work is to validate RIP-based automatic Web UI generation with two different LabVIEW systems and to provide a complete, reproducible protocol from back-end VI construction to browser-based interaction. The protocol includes input and output variable definition, RIP Server experiment registration, metadata-based UI generation, Caddy proxy deployment, and remote read/write verification. Applying the same workflow to the fan and DC motor models demonstrates that the established process can be reproduced without manually rewriting a complete Web front end for each example^9,10,11.

Protocol

Complete the following steps to build, register, deploy, and verify two RIP-accessible LabVIEW experiments following the workflow summarized in Figure 1. All the tools and platforms used in this study are listed in the Table of Materials.

1. Build and deploy the fan model experiment

1. Build the fan model VI.
   1. Open LabVIEW, create a new VI, and save the file as fengshan.vi. Save the VI in any directory accessible by the RIP WebService process. The Private folder is used only as an example directory and is not hardcoded in RIP. Enter the actual selected VI path during RIP experiment registration.
   2. On the Front Panel, add the input controls for the fan model. In this example, name the input controls Enable, PWM, Load, Tau, KMaxRPM, and Disturbance. Set Enable as a Boolean control, and set PWM, Load, Tau, KMaxRPM, and Disturbance as double-precision floating-point (DBL) numeric controls. See Supplementary Table 1 for the physical meaning and model role of the fan variables.
   3. Add the output indicators for the fan model. In this example, name the output indicators SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA, and PowerW. Set all output indicators as DBL indicators.
      ​NOTE: Table 1 describes the physical meaning and model role of these output variables. The completed fan front panel is shown in Figure 2. The variable names, ranges, and step sizes shown in Table 1 describe the two examples implemented in this protocol. They are not hardcoded requirements of RIP. For other LabVIEW experiments, developers may define different Front Panel variable names and numeric properties. The RIP Server reads the actual variable names, data types, input/output attributes, and available numeric properties from the VI metadata, and the Web page generates the corresponding controls and displays from the returned metadata.
   4. Add a While Loop to the Block Diagram. Add two Shift Registers to store speed_prev and time_prev, and initialize both values to 0.
   5. Add a Formula Node inside the While Loop. Connect Enable, PWM, Load, Tau, KMaxRPM, Disturbance, speed_prev, and time_prev to the left input terminals of the Formula Node, and set SteadyRPM, speed_next, SpeedNorm, CurrentA, PowerW, and time_next as the right output terminals.
   6. Build the Enable control logic outside the formula node. Use Enable as the selector signal so that u = PWM when Enable is True and u = 0 when Enable is False.
   7. Enter the fan model code in the formula node. Use this code to calculate steady-state speed, actual speed, normalized speed, current, power, and run time; see Supplementary Coding File 1 for the complete code.
   8. Connect the speed_next output of the Formula Node to the SpeedRPM indicator, and connect speed_next back to the right Shift Register for speed_prev. Connect SteadyRPM to the SteadyRPM indicator.
   9. Connect time_next to the TimeS indicator, and connect time_next back to the right Shift Register for time_prev. Connect SpeedNorm, CurrentA, and PowerW to the corresponding output indicators.
   10. Add a Wait function inside the While Loop and set the wait time to 50 ms. Add a Stop Local button and connect it to the conditional terminal of the While Loop.
   11. Save fengshan.vi. The completed fan Block Diagram is shown in Figure 3.
       PAUSE POINT: After saving the completed fan VI, the workflow may be stopped. Resume later by reopening the saved VI and confirming that all Front Panel controls, indicators, and Block Diagram connections are still present.
2. Register the fan experiment in the RIP Server.
   1. Open RIPWebService.lvproj in the LabVIEW Project Explorer
      .
   2. Open Configuration.vi from the project tree and locate the experiment configuration table.
   3. Add a new experiment row. Set Name to fan. Set the full path to the saved fengshan.vi file. The registration fields for the fan experiment are shown in Figure 4.
   4. Fill in the remaining configuration fields. Set Authors to the experiment author, Keywords to Fan, Description to fan speed model, and Sampling Freq to 200.
   5. In the LabVIEW menu, select Edit > Make Current Values Default. Save Configuration.vi.
   6. Restart RIP WebService and confirm that the fan experiment remains listed in the Configuration interface after restarting.
      NOTE: The experiment name is case-sensitive. The value fan in RIP Configuration must exactly match the experiment ID used in the front-end XHTML file. To deploy another LabVIEW VI with the same automatic UI-generation logic, add a new experiment entry in RIP Configuration, set a new Name value, and set Path to the corresponding VI file. Then use the same Name value as the experiment ID in the XHTML file. The front-end page does not need to be rewritten for each variable.
      ​PAUSE POINT: After saving Configuration.vi and making the current values default, the workflow may be stopped. Resume later by restarting RIP WebService and confirming that the fan experiment is still registered.
3. Prepare the front-end page for the fan experiment.
   1. Place Fan_Automatic_UI.xhtml in the Client directory used as the front-end root directory.
   2. Open Fan_Automatic_UI.xhtml with a text editor.
   3. Locate the experiment ID variable in the script section and set it to fan.
      NOTE: This value must exactly match the Name field of the fan experiment in RIP Configuration. The experiment ID settings and the shared metadata-based UI generation logic for the XHTML front-end files are shown in Figure 5.
   4. Verify that the page obtains the current access origin through window.location.origin, requests experiment metadata through rip.info(), and passes the returned metadata to autobuildUI().
      NOTE: The page should not hardcode the fan variable names, ranges, or step sizes manually. Instead, writable variables are generated from meta.writables.list, readable variables are generated from meta.readables.list, and numeric attributes such as min, max, and step are obtained from the metadata returned by the RIP Server.
   5. Save Fan_Automatic_UI.xhtml.
      ​NOTE: To use the same front-end generation logic for another LabVIEW VI, set a new experiment ID in the XHTML file and register the corresponding experiment Name and VI Path in RIP Configuration. The Web controls and output displays are generated according to the metadata returned by the selected experiment.
4. Configure the Caddy access path for the fan experiment.
   1. Open the Caddyfile with a text editor.
   2. Set the front-end root directory to the Client directory that contains Fan_Automatic_UI.xhtml.
   3. Select an unused local port for Caddy to provide browser access to the Web page and RIP routes. In this protocol, port 8090 is used as an example proxy access port.
      NOTE: Port 8090 is not required by RIP or Caddy. If port 8090 is occupied, replace it with another unused local port and use the same port in the browser address.
   4. Add a route that rewrites /fan to Fan_Automatic_UI.xhtml.
   5. Identify the RIP WebService port configured in LabVIEW. In this protocol, http://localhost:8001 is used as the RIP WebService address.
      NOTE: Port 8001 is the LabVIEW/RIP WebService back-end port used in the test environment. It can be changed in the LabVIEW/RIP WebService configuration. If a different port is used, replace http://localhost:8001 in the Caddyfile with the corresponding RIP WebService address.
   6. Add a reverse proxy rule that sends /RIP/SSE* requests to the RIP WebService address, such as http://localhost:8001.
   7. Add a reverse proxy rule that sends /RIP* requests to the RIP WebService address, such as http://localhost:8001. The Caddyfile configuration is shown in Figure 6.
   8. Open Command Prompt on Windows. Change to the local Caddy download or installation directory by entering the following command:
      cd /d D:\caddy
      NOTE: In this protocol, D:\caddy is the local Caddy download or installation path used in the test environment. If Caddy is stored in another directory, replace D:\caddy with the corresponding local path.
   9. Start Caddy with the specified Caddyfile by entering the following command:
      caddy.exe run --config Caddyfile
   10. Confirm that Caddy starts without reporting a configuration error. Open http://localhost:8090/fan in a Web browser and verify that the fan Web UI is generated, as shown in Figure 7.
       ​NOTE: If the browser returns a 502 error, confirm that RIP WebService is running, that the RIP WebService port in LabVIEW matches the reverse proxy address in the Caddyfile, and that the selected Caddy access port is not occupied.
5. Verify the operating results of the fan experiment.
   1. Verify that the front-end page automatically generates the Enable, PWM, Load, Tau, KMaxRPM, and Disturbance input controls.
   2. Verify that the front-end page displays the SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA, and PowerW output variables.
   3. Adjust PWM and observe whether SpeedRPM increases as PWM increases and decreases as PWM decreases.
   4. Adjust Load and observe whether SteadyRPM and SpeedRPM decrease as the load increases.
   5. Adjust the disturbance and observe whether SpeedRPM, CurrentA, and PowerW change in response to the disturbance input.
   6. Verify that TimeS continues to increase, confirming that the back-end fan VI is running continuously.

2. Build and deploy the DC motor PID position control experiment

1. Build the DC motor PID position control model VI.
   1. Open LabVIEW, create a new VI, and save the file as Motor.vi. Save the VI in any directory that can be accessed by the RIP WebService process.
      NOTE: The Private folder is used only as an example directory and is not hardcoded in RIP. Enter the actual selected VI path during RIP experiment registration.
   2. On the Front Panel, add the input controls for the DC motor PID position control model. In this example, name the input controls Setpoint, Kc, Ti, Td, Disturbance, and Reset control. Set Setpoint, Kc, Ti, Td, and Disturbance as DBL numeric controls, and set Reset control as a Boolean control.
      NOTE: Table 1 describes the physical meaning, model role, and recommended range of the variables used in this example.
   3. Add the output indicators for the DC motor PID position control model. In this example, name the output indicators Position, Voltage, Time, and Measured angular velocity. Set all output indicators as DBL indicators. Table 1 describes the physical meaning and model role of these output variables. The completed Front Panel for the motor is shown in Figure 8.
      NOTE: The variable names and ranges listed in Table 1 describe the two examples implemented in this protocol. They are not fixed requirements for the RIP-based automatic UI-generation workflow. When another LabVIEW VI is used, RIP reads the actual variable names, data types, input/output attributes, and available numeric properties from the VI metadata. Therefore, the front-end generation logic does not need to hardcode the variable names, maximum values, minimum values, or step sizes for each experiment.
   4. Add a While Loop to the Block Diagram. Add six Shift Registers to store theta, omega, im, e_prev, integ, and time, and initialize all six values to 0.
   5. Add a Formula Node inside the While Loop. According to the DC motor PID position control model diagram shown in Figure 9, use this Formula Node as the core calculation module for error calculation, PID control, voltage limiting, the electrical model, the mechanical model, and position updating.
      NOTE: The internal motor parameters used in this model, such as R, L, J, b, Kt, Ke, and Vmax, are normalized teaching-model parameters rather than calibrated parameters of a specific physical motor. They were selected to produce a stable and observable simulated response under the selected time step and voltage limit, so that the effects of Setpoint, Kc, Ti, Td, and Disturbance can be clearly demonstrated during Web-based operation.
   6. Set sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, disturbance, reset, and dt as the input terminals of the Formula Node. Set theta_next, omega_next, im_next, e_next, integ_next, and voltage as the output terminals of the Formula Node.
   7. Connect the Setpoint control to the sp input terminal of the Formula Node. Connect Kc, Ti, Td, and Disturbance to the Kc, Ti, Td, and disturbance input terminals of the Formula Node, respectively.
   8. Convert the Reset control Boolean signal to a numeric signal and connect it to the reset input terminal of the Formula Node. Execute state reset when reset is not equal to 0, and execute PID control and motor state updating when reset is equal to 0.
   9. Add the numeric constant dt and set its value to 0.001 s. Connect the dt to the dt input terminal of the Formula Node and use it for Time updating.
   10. Set the internal model parameters of the DC motor in the Formula Node. See Supplementary Table 2 for the physical meaning and model role of the motor variables.
   11. Enter the DC motor PID position control code in the Formula Node. Use this code to implement reset logic, error calculation, integral-term calculation, derivative-term calculation, PID control, voltage limiting, current updating, angular-velocity updating, and position updating; see supplementary coding files for the complete code.
   12. Connect theta_next to the Position indicator, and connect theta_next back to the right Shift Register for theta. Connect omega_next to the Measured angular velocity indicator, and connect omega_next back to the right Shift Register for omega.
   13. Connect the voltage to the Voltage indicator. Connect im_next, e_next, and integ_next back to the right Shift Registers for im, e_prev, and integ, respectively.
   14. Use an Add function outside the Formula Node to calculate time_next = time + dt. Connect time_next to the Time indicator, and connect time_next back to the right Shift Register for time.
   15. Add a Wait function inside the While Loop and set the wait time to 1 ms. Add a Stop button and connect it to the conditional terminal of the While Loop.
   16. Save Motor.vi. The completed motor Block Diagram is shown in Figure 10.
       PAUSE POINT: After saving the completed motor VI, the workflow may be stopped. Resume later by reopening the saved VI and confirming that all Front Panel controls, indicators, and Block Diagram connections are still present.
2. Register the motor experiment in the RIP Server.
   1. Open RIPWebService.lvproj in the LabVIEW Project Explorer.
   2. Open Configuration.vi from the project tree and locate the experiment configuration table.
   3. Add a new experiment row. Set Name to Motor. Set Path to the complete path of the saved Motor.vi file. The motor experiment registration fields are shown in Figure 11.
   4. Fill in the remaining configuration fields. Set Authors to the experiment author, Keywords to Motor, Description to DC motor position control model, and Sampling Freq to 200.
   5. In the LabVIEW menu, select Edit > Make Current Values Default. Save Configuration.vi.
   6. Restart RIP WebService and confirm that the Motor experiment remains listed in the Configuration interface after restarting.
      NOTE: The experiment name is case-sensitive. The value Motor in RIP Configuration must exactly match the experiment ID used in Motor_Automatic_UI.xhtml. To deploy another LabVIEW VI with the same automatic UI-generation logic, add a new experiment entry in RIP Configuration, set a new Name value, and set Path to the corresponding VI file. Then use the same Name value as the experiment ID in the XHTML file. The front-end page does not need to be rewritten for each variable.
      ​PAUSE POINT: After saving Configuration.vi and setting the current values as the default, the workflow may be stopped. Resume later by restarting RIP WebService and confirming that the Motor experiment is still registered.
3. Prepare the front-end page for the motor experiment.
   1. Place Motor_Automatic_UI.xhtml in the Client directory used as the front-end root directory.
   2. Open Motor_Automatic_UI.xhtml with a text editor.
   3. Locate the experiment ID variable in the script section and set it to Motor. This value must exactly match the Name field of the motor experiment in RIP Configuration. The motor front-end page uses the same metadata-based UI-generation logic shown in Figure 5; only the experiment ID is changed to match the Motor entry in RIP Configuration.
   4. Verify that the page contains the RIP metadata-reading logic, the HTML control-generation logic, the RIP write function, and the output-update function.
      NOTE: The page should not manually hardcode the motor variable names, ranges, or step sizes. These properties are obtained from the metadata returned by the RIP Server, following the RIP-based metadata-to-HTML generation mechanism described previously¹¹.
   5. Save Motor_Automatic_UI.xhtml.
      ​NOTE: To use the same front-end generation logic for another LabVIEW VI, set a new experiment ID in the XHTML file and register the corresponding experiment Name and VI Path in RIP Configuration. The Web controls and output displays are generated according to the metadata returned by the selected experiment.
4. Configure the Caddy access path for the motor experiment.
   1. Open the Caddyfile with a text editor.
   2. Set the front-end root directory to the Client directory that contains Motor_Automatic_UI.xhtml.
   3. Select an unused local port for Caddy to provide browser access to the Web page and RIP routes. In this protocol, port 8090 is used as an example proxy access port.
      NOTE: Port 8090 is not required by RIP or Caddy. If port 8090 is occupied, replace it with another unused local port and use the same port in the browser address.
   4. Add a route that rewrites /motor to Motor_Automatic_UI.xhtml.
   5. Identify the RIP WebService port configured in LabVIEW. In this protocol, http://localhost:8001 is used as the RIP WebService address.
      NOTE: Port 8001 is the LabVIEW/RIP WebService back-end port used in the test environment. It can be changed in the LabVIEW/RIP WebService configuration. If a different port is used, replace http://localhost:8001 in the Caddyfile with the corresponding RIP WebService address.
   6. Add a reverse proxy rule that sends /RIP/SSE* requests to the RIP WebService address, such as http://localhost:8001.
   7. Add a reverse proxy rule that sends /RIP* requests to the RIP WebService address, such as http://localhost:8001. The Caddyfile configuration is shown in Figure 6.
   8. Open Command Prompt on Windows. Change to the local Caddy download or installation directory by entering the following command:
      cd /d D:\caddy
      NOTE: In this protocol, D:\caddy is the local Caddy download or installation path used in the test environment. If Caddy is stored in another directory, replace D:\caddy with the corresponding local path.
   9. Start Caddy with the specified Caddyfile by entering the following command:
      caddy.exe run --config Caddyfile
   10. Confirm that Caddy starts without reporting a configuration error. Open http://localhost:8090/motor in a Web browser and verify that the motor Web UI is generated, as shown in Figure 12.
       ​NOTE: If the motor Web page loads but the output values do not update, confirm that RIP WebService is running, that the motor VI is executing, that the RIP WebService port in LabVIEW matches the reverse proxy address in the Caddyfile, and that the /RIP/SSE* route is correctly proxied.
5. Verify the operating results of the motor experiment.
   1. Verify that the front-end page automatically generates the Setpoint, Kc, Ti, Td, Disturbance, and Reset control input controls.
   2. Verify that the front-end page displays the Position, Voltage, Time, and Measured angular velocity output variables.
   3. Adjust Setpoint and observe whether Position responds to the change in the desired position.
   4. Adjust Kc, Ti, and Td and observe whether Voltage, Position, and Measured angular velocity change.
   5. Adjust the disturbance and observe whether the position, control voltage, or measured angular velocity is affected by the disturbance input.
   6. Click Reset control and observe whether Position, Voltage, Measured angular velocity, and the related internal states return to their initial states according to the reset logic.

Results

After completing the workflow described above, both the fan experiment and the DC motor PID position control experiment can be accessed through the automatically generated Web front end. A successful result is indicated by three observations. First, the Web page automatically generates input controls and output display fields according to the variable metadata returned by the RIP Server. Second, when the user changes an input variable on the Web page, the modified value is written to the LabVIEW back-end VI through the RIP interface. Third, the output variables calculated by the back-end VI are returned through RIP and refreshed on the Web page in real time. For the fan experiment, after entering http://localhost:8090/fan in a browser, the page automatically generates input controls and output fields from the RIP metadata, as shown in Figure 7. The input side includes Enable, PWM, Load, Tau, KMaxRPM, and Disturbance, whereas the output side displays SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA, and PowerW. During normal operation, TimeS increases continuously, indicating that the back-end fengshan.vi is executing. When PWM is increased, SpeedRPM and SteadyRPM increase accordingly. When Load is increased, the fan speed decreases because the load reduces the steady operating speed. When Disturbance is adjusted, corresponding changes can be observed in SpeedRPM, CurrentA, and PowerW. These observations confirm that the Web-side inputs are transmitted correctly to the LabVIEW back end and that the calculated outputs are returned to the front end through RIP.

For the DC motor PID position control experiment, after entering http://localhost:8090/motor in a browser, the page automatically generates the corresponding controls and output fields from the RIP metadata, as shown in Figure 12. The input variables include Setpoint, Kc, Ti, Td, Disturbance, and Reset control, and the output variables include Position, Voltage, Time, and Measured angular velocity. When Setpoint is changed, Position responds to the new target value. When the PID parameters Kc, Ti, and Td are adjusted, the output response, control voltage, and measured angular velocity change accordingly, indicating that the parameter values entered on the Web page are correctly written to the LabVIEW back-end model and participate in the control computation. When Reset control is activated, the model variables return to their initial states according to the reset logic.

Browser-side failure and communication states are shown in Figure 13, Figure 14, Figure 15. Figure 13 shows a failed browser access case in which Caddy is not running. The browser attempts to access http://localhost:8090/motor but displays an ERR_CONNECTION_REFUSED message, indicating that the local proxy service is unavailable or is not listening on the selected access port. Figure 14 shows a RIP POST communication failure after the page has loaded. In this case, the browser console reports a 502 Bad Gateway error for the RIP POST request, indicating that the front end has reached the proxy address but the request cannot be successfully forwarded to, or processed by, the RIP WebService back end. In contrast, Figure 15 shows a normal browser-side communication state. The browser developer tools show successful page loading, RIP POST requests, and an active SSE request with expId=fan, indicating that the Web front end is communicating with the RIP WebService through the Caddy proxy and receiving real-time updates through the SSE channel.

Together, the successful fan and motor results and the browser-side diagnostic results demonstrate that the same metadata-based automatic UI-generation workflow can be reproduced for two different LabVIEW experiments. These results also provide observable criteria for distinguishing successful communication from representative deployment failures, while the corresponding troubleshooting procedures are discussed in the Discussion section.

Figure 1: Overall experimental system structure. The system consists of the LabVIEW back-end VI, RIP Server, Caddy proxy, and auto-generated Web UI. The LabVIEW VI provides model variables, the RIP Server reads VI metadata and variable values, Caddy unifies the access path and resolves cross-origin access, and the Web UI generates controls automatically. The Caddy name and logo are shown only to identify the Caddy Web server/proxy component used in the workflow. Please click here to view a larger version of this figure.

Figure 2: Front Panel of the fan VI. The Front Panel contains input controls for Enable, PWM, Load, Tau, KMaxRPM, and Disturbance and output indicators for SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA, and PowerW. This screenshot was captured from the Front Panel of fengshan.vi in LabVIEW 2026 in the authors' own local experimental environment. No third-party user data or confidential information are included. Please click here to view a larger version of this figure.

Figure 3: Block Diagram of the fan VI. The fan model is implemented with a While Loop, Shift Registers, Enable logic, a Formula Node, and output indicators. This screenshot was captured from the Block Diagram of fengshan.vi in LabVIEW 2026 in the authors' own local experimental environment. No third-party user data or confidential information are included. Please click here to view a larger version of this figure.

Figure 4: Configuration page of fan.vi. The fan experiment is registered in RIP Configuration with the experiment name fan, the actual VI path, keyword information, description, and sampling frequency. This screenshot was captured from the RIP Configuration interface used with LabVIEW 2026 and RIP WebService in the authors’ own local experimental environment. No third-party user data or confidential information are included. Please click here to view a larger version of this figure.

Figure 5: Experiment ID settings and metadata-based UI-generation logic in the XHTML front-end files. The XHTML code screenshots were captured from Fan_Automatic_UI.xhtml and Motor_Automatic_UI.xhtml opened in Visual Studio Code. The fan and motor pages use the same metadata-reading and control-generation logic; only the experiment ID is changed to match the corresponding Name field in RIP Configuration. The XHTML code screenshots were captured from Fan_Automatic_UI.xhtml and Motor_Automatic_UI.xhtml opened in Visual Studio Code in the authors’ own local development environment. The code files were prepared by the authors for this protocol. No third-party user data or confidential information are included. Please click here to view a larger version of this figure.

Figure 6: Caddyfile configuration. The Caddyfile defines the local proxy access port, sets the front-end root directory, rewrites the /fan and /motor routes to the corresponding XHTML files, and reverse-proxies /RIP/SSE* and /RIP* requests to the LabVIEW/RIP WebService port. The Caddyfile configuration screenshot was captured from the Caddyfile opened in Visual Studio Code in the authors’ own local development environment. The Caddyfile was prepared by the authors to configure Caddy as the local Web server and reverse proxy. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 7: Web UI page of fan.vi. This Web interface screenshot was captured from the authors’ locally deployed fan Web page using Mozilla Firefox. The front-end page automatically generates input controls and output displays based on the variable metadata returned by the RIP Server. This Web interface screenshot was captured from the authors’ locally deployed fan Web page using Mozilla Firefox. The displayed controls and output fields were generated from RIP metadata in the authors’ local experimental environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 8: Front Panel of the motor VI. The Front Panel contains controls for Setpoint, Kc, Ti, Td, Disturbance, and Reset control, and indicators for Position, Voltage, Time, and Measured angular velocity. This screenshot was captured from the Front Panel of Motor.vi in LabVIEW 2026 in the authors’ own local experimental environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 9: DC motor PID position control model diagram. The diagram shows the signal path from setpoint error, PID control, voltage limiting, disturbance superposition, electrical dynamics, mechanical dynamics, and position updating to feedback. Please click here to view a larger version of this figure.

Figure 10: Block Diagram of the motor VI. The motor model is implemented with a While Loop, Shift Registers, a Formula Node, timing logic, and output indicators. This screenshot was captured from the Block Diagram of Motor.vi in LabVIEW 2026 in the authors’ own local experimental environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 11: Configuration page of Motor.vi. The motor experiment is registered in RIP Configuration with the experiment name Motor, the actual VI path, keyword information, description, and sampling frequency. This screenshot was captured from the RIP Configuration interface used with LabVIEW 2026 and RIP WebService in the authors’ own local experimental environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 12: Web UI page of Motor.vi. The front-end page automatically generates input controls and output displays for the DC motor PID position control experiment. This Web interface screenshot was captured from the authors’ locally deployed motor Web page using Mozilla Firefox. The displayed controls and output fields were generated from RIP metadata in the authors’ local experimental environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 13: Failed browser access when Caddy is not running. When Caddy is not started, the proxied local address http://localhost:8090/motor cannot be reached, and the browser displays an ERR_CONNECTION_REFUSED message. This failure symptom indicates that the local Caddy proxy service is unavailable or is not listening on the selected access port. This browser screenshot was captured using Mozilla Firefox in the authors’ own local testing environment and shows the failed access state when the local Caddy proxy was not running. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 14: RIP POST communication failure after page loading. The browser console shows a 502 Bad Gateway error for the RIP POST request. This result indicates that the Web page has reached the Caddy proxy address, but the request cannot be successfully forwarded to, or processed by, the RIP WebService back end. This browser console screenshot was captured using Mozilla Firefox Developer Tools in the authors’ own local deployment environment and shows a RIP POST 502 Bad Gateway communication failure. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 15: Browser-side communication status under normal operation. The browser developer tools show successful page loading, RIP POST requests, and an active SSE request with expId=fan. These requests indicate that the Web front end is communicating with the RIP WebService through the Caddy proxy and receiving real-time updates through the SSE channel. This browser developer tools screenshot was captured using Mozilla Firefox in the authors’ own local deployment environment and shows normal RIP POST and SSE communication. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 16: Single representative browser-console and process-level resource observation for the fan experiment. The screenshot was recorded during a local fan experiment test. The console shows metadata request/response time, metadata variable counts, metadata-based UI generation time, SSE connection opening time, and received SSE data. The task-manager view shows process-level CPU and memory values for the browser and LabVIEW processes at the time of capture. These values are descriptive observations from this individual test and are not replicated performance measurements or a statistical benchmark. This screenshot was captured from Mozilla Firefox Developer Tools and Windows Task Manager in the authors’ own local testing environment. Mozilla Firefox was used to record browser console output, and Windows Task Manager was used to observe CPU and memory usage for the browser and LabVIEW processes. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Figure 17: Simultaneous access to the same RIP-based Web page from a desktop browser and a mobile browser. The fan experiment page is opened concurrently on PC and mobile devices, and both clients display the automatically generated controls and output variables. The desktop Web page was accessed using Mozilla Firefox, and the mobile Web page was accessed using a mobile browser in the same local network environment. The screenshots were captured from the authors’ own local testing environment. No third-party user data or confidential information is included. Please click here to view a larger version of this figure.

Variable name	Data type	Input/Output	Physical meaning	Role in the model			Range/Setting
Enable	Boolean	Input	Fan run switch	Controls whether the model receives the PWM input. When True, u = PWM; when False, u = 0.			True / False
PWM	DBL	Input	Drive input	Determines the basic fan drive intensity and is the main input used to calculate the steady-state speed SteadyRPM.			0-1, step 0.01
Load	DBL	Input	Load coefficient	Describes the weakening effect of load on the steady-state speed. As Load increases, the steady-state speed decreases.			0-1, step 0.01
Tau	DBL	Input	Response time constant	Determines how quickly the fan speed approaches the steady-state speed from the previous state.			0.1-5, step 0.1
KMaxRPM	DBL	Input	Maximum speed	Sets the maximum speed allowed by the model and is used for speed limiting and normalization.			500-6000, step 100
Disturbance	DBL	Input	Disturbance input	Represents the effect of external disturbance or load fluctuation on steady-state speed, current, and power.			0-1, step 0.1
SpeedRPM	DBL	Output	Actual speed	Represents the current output speed of the fan and is updated through first-order inertial dynamics.			Calculated by the model
SteadyRPM	DBL	Output	Steady-state speed	Represents the theoretical steady-state speed under the current input conditions.			Calculated by the model
TimeS	DBL	Output	Run time	Represents the continuous run time of the model.			Calculated by the model
SpeedNorm	DBL	Output	Normalized speed	Represents the ratio of SpeedRPM to KMaxRPM.			0-1 or calculated by the model
CurrentA	DBL	Output	Current	Represents the estimated model current, which changes with the drive input and disturbance input.			Calculated by the model
PowerW	DBL	Output	Power	Represents the estimated model power, calculated from the voltage constant and current.			Calculated by the model
Setpoint	DBL	Input	Desired position	Sets the position that the motor should reach and forms the error e with the actual position Position.			-3-3, step 0.1
Kc	DBL	Input	Proportional gain	Adjusts the response strength of the PID Controller to the error.			0-10, step 0.1
Ti	DBL	Input	Integral time	Adjusts the integral action of the PID Controller and is used to reduce steady-state error.			0-10, step 0.1
Td	DBL	Input	Derivative time	Adjusts the derivative action of the PID Controller and is used to suppress overly rapid error changes and improve dynamic response.			0-5, step 0.1
Disturbance	DBL	Input	Disturbance input	Represents an external disturbance superimposed at the motor input, acting on the motor model together with the control voltage.			0-10, step 0.1
Reset control	Boolean	Input	Reset control	Triggers model state clearing so that position, angular velocity, current, error, and integral term return to their initial states.			True / False
Position	DBL	Output	Actual position	Represents the current angular position of the motor and serves as the feedback variable for PID control.			Calculated by the model
Voltage	DBL	Output	Control voltage	Represents the PID Controller output after voltage limiting and acts on the motor input.			Calculated by the model; limited to -24 to 24 V
Time	DBL	Output	Run time	Represents the continuous run time of the motor model.			Calculated by the model
Measured angular velocity	DBL	Output	Measured angular velocity	Represents the current angular velocity of the motor and is the mechanical state output of the motor.			Calculated by the model

Table 1: Input and output variables used in the fan and DC motor examples. The table lists each variable name, data type, input/output role, physical meaning, recommended range, and step size.

Parameter	Value	Physical meaning	Role in the model
R	1	Armature resistance	Represents the resistance term in the motor armature circuit and determines the voltage drop R × im in the current equation.
L	0.5	Armature inductance	Represents the inductance of the armature circuit and determines the current change rate. A larger L produces a slower current response.
J	0.01	Moment of inertia	Represents the motor rotor resistance to angular acceleration changes and determines how quickly angular velocity changes.
b	0.1	Viscous damping coefficient	Represents mechanical damping and describes the damping torque that hinders the increase of angular velocity during rotation.
Kt	0.01	Torque constant	Represents the proportional coefficient that converts armature current into electromagnetic torque.
Ke	0.01	Back electromotive force constant	Represents the proportional coefficient by which angular velocity generates back electromotive force and describes the feedback effect of speed on current.
Vmax	24	Maximum control voltage	Represents the limit of the controller output voltage and keeps voltage within the range from -24 V to 24 V.
dt	0.001	Discrete simulation step	Represents the time interval for each loop-based state update and is used to update current, angular velocity, position, and run time.

Table 2: Internal parameters used in the DC motor PID position-control model. The table lists the electrical and mechanical parameters, symbols, numerical values, units, and roles in the model.

Supplemental Coding Files: Complete source and configuration files for reproducing the fan and DC motor examples. The supplemental coding files include the LabVIEW Formula Node code, Caddy reverse-proxy configuration, XHTML front-end files, and LabVIEW VI source files used in this protocol. Code in LabVIEW Formula Node.docx contains the Formula Node code for the fan and DC motor PID position-control models. Caddyfile.txt contains the local Web server and reverse-proxy configuration. Fan_Automatic_UI.xhtml and Motor_Automatic_UI.xhtml contain the metadata-based Web front-end logic. fengshan.vi and Motor.vi are the LabVIEW back-end VI files for the fan and motor experiments.Please click here to download this file.

Discussion

A critical step in this protocol is the standardized construction and registration of the LabVIEW back-end VI. The Front Panel controls and indicators must use clear and unique variable names, and their data types must match the variables expected by the model calculation and by the RIP read/write process. In the two examples used in this protocol, scalar numeric variables are defined as DBL controls or indicators, and Boolean variables are defined as Boolean controls. The Block Diagram must also maintain continuous state updating through the While Loop, Shift Registers, and Formula Node so that variables such as fan speed, motor position, motor angular velocity, voltage, and time can be updated during execution. After the VI is constructed, the experiment Name in RIP Configuration must exactly match the experiment ID used in the corresponding XHTML file, and the VI Path must point to the actual saved VI. These settings are important because the Web front end does not hardcode the variables of each experiment. Instead, it depends on the metadata returned by the RIP Server to identify writable variables, readable variables, data types, and numeric properties^10,11.

The main troubleshooting issues are related to the consistency among the XHTML experiment ID, RIP Configuration, RIP WebService, and Caddy proxy settings. If the experiment ID in the XHTML file does not match the experiment Name in RIP Configuration, the Web page cannot request the correct metadata and therefore cannot generate the expected controls and output fields. If the VI Path is incorrect or the RIP WebService is not started, the Web page may open but cannot communicate with the LabVIEW back end. If Caddy is not running, the browser cannot access the selected local proxy address and may display an ERR_CONNECTION_REFUSED message, as shown in Figure 13. If Caddy is running but the reverse-proxy target does not match the RIP WebService port, the page may load while RIP POST requests fail with a 502 Bad Gateway error, as shown in Figure 14. If the /RIP/SSE* route is not working correctly, the page may open and display controls, but output values do not update in real time. Under normal operation, the browser developer tools should show successful page loading, RIP POST requests, and an active SSE request with the correct experiment ID, as shown in Figure 15. Therefore, troubleshooting should begin by checking the experiment ID, VI Path, RIP WebService status, Caddy running status, proxy ports, and SSE route. If communication still behaves abnormally, restarting both RIP WebService and Caddy, clearing the browser cache, or repeating the test in another browser may help distinguish browser-specific behavior from RIP/Caddy configuration problems.

The present protocol is reproducible across the two examples because the same build-register-deploy-verify workflow is applied to both a fan speed model and a DC motor PID position control model. To reduce dependence on specialized toolboxes, the back-end VIs are reconstructed using basic LabVIEW structures, including Front Panel controls and indicators, While Loops, Shift Registers, Formula Nodes, and standard scalar numeric and Boolean variables. However, reproducibility across LabVIEW versions, Windows installations, and local network environments still depends on configuration details such as file paths, access permissions, local ports, service startup commands, and browser behavior. The workflow may also be extended to hardware-related remote experiments, but the method should not be interpreted as direct Web-side hardware recognition. The Web front end identifies LabVIEW Front Panel controls and indicators through RIP metadata. Therefore, sensors, actuators, instruments, or process-control devices must first be connected and processed in the LabVIEW back-end VI through appropriate hardware drivers, data-acquisition modules, instrument-control modules, or other hardware-adaptation mechanisms. After the hardware measurements and control commands are mapped to Front Panel indicators and controls, the RIP-based Web front end can recognize these variables in the same way as it recognizes the simulation variables used in this protocol. Previous LabVIEW-based remote laboratory studies have shown that LabVIEW can be used as a back-end environment for remote control engineering experiments, robotic experiments, process-control rigs, sensor-data acquisition, and physical-device interaction^{9,12,17,18,19,20}.

Figure 16 presents a single representative implementation example recorded during a local fan experiment. The front-end code was instrumented to record metadata request/response time, metadata variable counts, metadata-based UI generation time, SSE connection opening time, and received SSE data. In this example, the browser console reported a metadata request/response time of 68.00 ms, identified 7 writable variables and 7 readable variables from the RIP metadata, generated the corresponding UI elements in 2.00 ms, and opened the SSE connection in 16.00 ms. The repeated SSE data entries showed that output variables such as SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA, and PowerW were continuously received from the LabVIEW back end. The task manager view in the same local test state showed approximately 1.5% CPU usage and 391.7 MB of memory for the Firefox process, while the LabVIEW process showed 0% CPU usage and 9.2 MB of memory at the time of capture. These observations provide basic evidence that metadata retrieval, metadata-based UI generation, RIP/SSE communication, and process-level CPU overhead could be observed in the local deployment environment. However, these data are intended as implementation-level verification rather than a comprehensive performance benchmark. Systematic performance evaluation under different browsers, repeated trials, heavier variable loads, physical hardware, and multiple simultaneous users remains necessary in future work.

This method also has limitations, especially when it is extended to complex data structures, hardware experiments, and multiuser operation. The current workflow is most suitable for scalar numeric and Boolean input/output variables. It does not automatically provide complete support for complex arrays, clusters, nested data structures, chart relationships, or domain-specific visualizations. These cases may require additional metadata mapping rules or manually written front-end components. The automatically generated UI can create basic controls and displays from variable metadata, but it cannot fully infer the physical relationship among variables, select the most appropriate visualization, or design experiment-specific safety interactions. When the workflow is extended to real equipment, additional considerations are required, including hardware drivers, device calibration, sampling constraints, actuator limits, emergency-stop logic, authentication, and multiuser write-control mechanisms. The current deployment can also be accessed by multiple client devices through standard Web browsers in the same local network environment. As shown in Figure 17, the same fan experiment page was opened simultaneously on a desktop browser and on a mobile browser, and both clients displayed the automatically generated controls and corresponding output variables. This observation indicates basic simultaneous multi-client access for viewing and interacting with the same experiment page. However, it should not be interpreted as a complete multiuser control framework, because the present implementation does not include dedicated user authentication, control locking, concurrent write arbitration, write queues, or conflict-resolution mechanisms. These limitations are consistent with previous remote-laboratory studies, in which complex or collaborative remote laboratories usually require experiment-specific interface design, synchronization mechanisms, safety constraints, and user-management logic^{13,14,15,16,17}.

The methodological value of this protocol is not that it introduces a new RIP architecture or extends the data types supported by RIP. Instead, its value lies in providing a complete and reproducible implementation path for applying an established RIP-based automatic UI-generation mechanism to different LabVIEW systems. Compared with writing a custom Web interface for each experiment, this workflow reduces repeated implementation of basic control layout, variable binding, and read/write communication logic when the back-end VI exposes compatible variables^8,9,10,11. The protocol is therefore useful for engineering education, remote-laboratory development, and rapid deployment of low-risk simulation or teaching experiments that require browser-based parameter adjustment and real-time state monitoring. Future work should extend the workflow to more complex data structures, physical experimental devices, formal multiuser access control, and quantitative performance evaluation, including interface generation time, communication latency, synchronization stability, server load, CPU overhead, and front-end usability.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Caddy Proxy Server	Caddy	N/A	Reverse proxy used to serve the Web UI and forward /RIP requests to RIP WebService
Caddyfile	Prepared by the authors	N/A	Defines static-file routes and reverse-proxy routes for RIP communication
Fan_Automatic_UI.xhtml	Prepared by the authors	N/A	Metadata-based Web front end for the fan experiment
LabVIEW	National Instruments	2026	Software used to construct and run fengshan.vi and Motor.vi
Microsoft Windows operating system	Microsoft	Win11	Operating system used to run LabVIEW, RIP WebService, Caddy, and the browser.
Motor_Automatic_UI.xhtml	Prepared by the authors	N/A	Metadata-based Web front end for the motor experiment
Mozilla Firefox desktop browser	Mozilla	2026	Desktop browser used for Web UI access, developer tools, timing/resource observations, and Network/Console screenshots.
RIP WebService	UNEDLabs	https://github.com/Nebulous-Systems/rip-server_labview	Receives RIP POST requests and provides the WebService communication layer used by the browser front end.
Windows Task Manager	Microsoft	Built into Windows	Used to record process-level CPU and memory observations for the browser and LabVIEW processes.