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 R...

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 stat...

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.