Artículo de método

Un protocolo para la generación automática de interfaces basadas en web para aplicaciones de LabVIEW mediante el Protocolo de Interoperabilidad Remota

158 visualizaciones

⸱

DOI:

10.3791/72765

⸱

14 de agosto de 2026

 ,  ,  , 
1School of Electrical Engineering and Automation, Wuhan University, 2School of Robotics, Wuhan University, 3Department of Computer Science and Automatic Control, National University of Distance Education, 4School of Civil Engineering, Wuhan University

En este artículo

Resumen

Este estudio valida la generación automática de interfaces de usuario web basada en un protocolo de interoperabilidad remota (RIP) con dos sistemas LabVIEW distintos: un modelo de ventilador y un modelo de control de posición de motor de corriente continua, y proporciona un procedimiento reproducible para construir, registrar, desplegar y probar ambos ejemplos.

Resumen

Las plataformas experimentales remotas permiten acceder a modelos de simulación locales o dispositivos físicos a través de una red, pero las interfaces web convencionales suelen requerir una página independiente, un diseño de controles y una lógica de comunicación de datos específica para cada experimento, lo que incrementa los costos de desarrollo. Este trabajo valida un flujo de trabajo establecido para generar automáticamente una interfaz de usuario web (UI) a partir de instrumentos virtuales (VIs) de LabVIEW utilizando el protocolo de interoperabilidad remota (RIP) y proporciona un protocolo reproducible para su implementación. El flujo de trabajo construye VIs de LabVIEW que definen controles de entrada y salidas indicadoras en el Panel Frontal, registra cada VI en la Configuración del Servidor RIP, lee los metadatos resultantes de las variables y genera los controles web y visualizaciones de salida correspondientes. Caddy se utiliza como proxy inverso para unificar la ruta de archivos estáticos del frontend y la ruta de solicitudes de la interfaz de programación de aplicaciones (API) de RIP. El flujo de trabajo se evalúa con dos sistemas diferentes: un modelo de velocidad de ventilador y un modelo de control de posición proporcional-integral-derivativo (PID) para un motor de corriente continua (DC). En ambos casos, la página web identifica las variables expuestas, escribe las entradas del usuario en el backend de LabVIEW, lee las salidas del modelo y genera la interfaz a partir de los metadatos de RIP. Estos resultados validan el mismo proceso de generación automática de interfaz de usuario en dos sistemas dinámicos diferentes y documentan los pasos necesarios para reproducirlo.

Introducción

Con el desarrollo de experimentos remotos, enseñanza en línea y tecnologías del Internet de las Cosas, proporcionar acceso web a modelos de simulación locales o dispositivos experimentales se ha convertido en una dirección importante para el desarrollo de plataformas experimentales1,2,3,4. Trabajos recientes han integrado además laboratorios equipados con Internet de las Cosas con aprendizaje basado en proyectos y acceso local o remoto, demostrando el continuo desarrollo de plataformas experimentales flexibles y en red en la educación ingenieril5. Para experimentos de sistemas de control, los usuarios normalmente necesitan ajustar parámetros de entrada en un navegador y observar los estados de salida en tiempo real6,7. Los métodos convencionales requieren típicamente una página web independiente, lógica de vinculación de control y una interfaz de comunicación de datos para cada objeto experimental8,9. Cuando las variables en el modelo de fondo cambian, la página del front-end a menudo debe modificarse en consecuencia, lo que genera un trabajo de desarrollo repetitivo considerable y limita la expansión rápida de la plataforma experimental.

El protocolo de interoperabilidad remota (RIP) proporciona una capa intermedia entre modelos experimentales de fondo y interfaces web frontales10,11. En el enfoque basado en RIP para la generación automática de interfaces de usuario descrito en trabajos previos, el servidor RIP proporciona metadatos para cada experimento, incluyendo nombres de variables, atributos de entrada/salida, tipos de datos, valores mínimos, valores máximos, precisión, descripciones y los métodos disponibles de lectura/escritura11. Un cliente web puede entonces utilizar estos metadatos para crear los elementos HTML correspondientes, tales como etiquetas, campos de entrada numérica, controles deslizantes, controles booleanos y visualizaciones de salida, durante la carga o actualización de la página11. El presente protocolo no reimplementa ni redefine la especificación de RIP. En cambio, utiliza el servicio RIP de código abierto existente y la lógica de generación de interfaces HTML a partir de metadatos basada en RIP como base para la comunicación y la generación de interfaces, y se centra en la construcción reproducible, registro, despliegue mediante proxy y verificación de dos ejemplos de VI de LabVIEW.

En comparación con el desarrollo convencional de interfaces web personalizadas, la generación automática de interfaces de usuario basada en RIP reduce la necesidad de implementar diseños de control, lógica de enlace de variables y funciones básicas de comunicación cuando múltiples experimentos en LabVIEW exponen variables escalares de entrada y salida comparables8,9,10,11. Una vez que se registra un nuevo VI y sus variables están disponibles para el servidor RIP, la misma lógica de lectura de metadatos y generación de controles puede reutilizarse para construir la interfaz web básica10,11. Esta característica es útil para la implementación rápida, demostraciones docentes y plataformas de laboratorios remotos que requieren acceso consistente a varios experimentos similares3,8,9. Sin embargo, la interfaz generada automáticamente también tiene limitaciones. No infiere completamente las relaciones físicas entre las variables, no determina automáticamente las asignaciones de gráficos ni diseña visualizaciones específicas del dominio ni interacciones de seguridad11. Por lo tanto, el desarrollo manual de la interfaz web sigue siendo preferible cuando un experimento requiere gráficos altamente personalizados, flujos de trabajo de usuario complejos, visualización avanzada, interbloqueos de seguridad de hardware o arbitraje de escritura multiusuario.

El flujo de trabajo general del protocolo se resume en la Figura 1. En este flujo de trabajo, un VI de LabVIEW primero define los controles de entrada y los indicadores de salida requeridos en el Panel Frontal. Luego, el VI se registra en la Configuración del Servidor RIP especificando el nombre del experimento y la ruta del VI. Tras el registro, el Servidor RIP lee los metadatos del experimento seleccionado y proporciona acceso de lectura y escritura a las variables disponibles. La página web XHTML utiliza los metadatos devueltos para generar automáticamente los controles de entrada y las visualizaciones de salida correspondientes, mientras que Caddy proporciona una ruta de acceso unificada para la página web estática y las rutas de comunicación RIP. En este estudio se utilizan los modelos de ventilador y motor de corriente continua como dos implementaciones del mismo flujo de trabajo. Para otros experimentos de LabVIEW que ofrezcan variables escalares, numéricas y booleanas compatibles, los desarrolladores pueden seguir el mismo flujo de trabajo de construcción-registro-despliegue-verificación para crear una interfaz web generada automáticamente, añadiendo visualización específica del experimento, lógica de seguridad o manejo de datos complejos cuando sea necesario.

Este artículo no propone una nueva arquitectura RIP ni amplía el rango de tipos de datos ya admitidos por RIP. En cambio, utiliza RIP como mecanismo establecido de comunicación y generación de interfaces de usuario basada en metadatos, y se centra en validar dicho proceso con dos sistemas LabVIEW diferentes, documentando al mismo tiempo un protocolo de implementación reproducible. Trabajos previos han presentado un método básico para la generación automática de interfaces web basada en metadatos de RIP, utilizando como estudio de caso un experimento en línea con un motor servo11. También se han reportado en estudios anteriores arquitecturas de laboratorios remotos con capacidad web que combinan interfaces interactivas con software de ingeniería y LabVIEW9,12. Sin embargo, durante la reproducción práctica, algunos modelos de LabVIEW del caso original se vieron afectados por problemas de compatibilidad entre versiones de software y módulos, lo que dificultó su uso directo en entornos más recientes. Por ello, este trabajo reconstruye dos VIs de fondo compatibles —un modelo de ventilador y un modelo de control de posición proporcional-integral-derivativo (PID) para un motor de corriente continua (CC)— y aplica el mismo proceso de generación de interfaz de usuario basado en metadatos a ambos. La contribución radica en la validación cruzada del flujo de trabajo RIP establecido y en un protocolo detallado para reproducir el proceso, más que en una extensión de la generalidad de RIP.

Los usuarios previstos de este protocolo son investigadores, instructores y desarrolladores de laboratorios que ya utilizan VIs de LabVIEW y necesitan exponer modelos de simulación o sistemas experimentales de bajo riesgo a través de un navegador Web sin tener que implementar de forma independiente una interfaz frontal personalizada completa para cada modelo. El protocolo es particularmente adecuado para experimentos que utilizan variables numéricas y booleanas estándar, ajuste de parámetros y monitoreo en tiempo real del estado10,11. Es menos adecuado como solución independiente para experimentos que requieran estructuras de datos complejas, visualización especializada, interbloqueos estrictos de seguridad de hardware o arbitraje de escritura multiusuario11. El objetivo de este trabajo es validar la generación automática de interfaces de usuario Web basadas en RIP con dos sistemas diferentes de LabVIEW y proporcionar un protocolo completo y reproducible, desde la construcción del VI de fondo hasta la interacción basada en navegador. El protocolo incluye la definición de variables de entrada y salida, el registro del experimento en el servidor RIP, la generación de la interfaz de usuario basada en metadatos, el despliegue del proxy Caddy y la verificación remota de lectura y escritura. Aplicar el mismo flujo de trabajo a los modelos del ventilador y del motor de corriente continua demuestra que el proceso establecido puede reproducirse sin tener que reescribir manualmente una interfaz frontal Web completa para cada ejemplo9,10,11.

Protocolo

Complete los siguientes pasos para construir, registrar, implementar y verificar dos experimentos en LabVIEW accesibles mediante RIP siguiendo el flujo de trabajo resumido en la Figura 1. Todas las herramientas y plataformas utilizadas en este estudio se enumeran en la Tabla de Materiales.

1. Construya e implemente el experimento del modelo de ventilador

  1. Construya el modelo de ventilador VI.
    1. Abra LabVIEW, cree un nuevo VI y guarde el archivo como fengshan.vi. Guarde el VI en cualquier directorio al que pueda acceder el proceso RIP WebService. La carpeta Private se utiliza únicamente como ejemplo de directorio y no está codificada de forma fija en RIP. Ingrese la ruta real del VI seleccionado durante el registro del experimento en RIP.
    2. En el panel frontal, agregue los controles de entrada para el modelo del ventilador. En este ejemplo, asigne nombres a los controles de entrada Habilitar, PWM, Carga, Tau, KMaxRPM y Alteración. Ajustar Habilitar como control booleano y establezca PWM, Carga, Tau, KMaxRPM, y Alteración como controles numéricos de punto flotante de doble precisión (DBL). Véase Tabla suplementaria 1 por el significado físico y el papel del modelo de las variables del ventilador.
    3. Agregue los indicadores de salida para el modelo del ventilador. En este ejemplo, asigne un nombre a los indicadores de salida SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA y PowerW. Establezca todos los indicadores de salida como indicadores DBL.
      ​NOTA: Tabla 1 describe el significado físico y el papel del modelo de estas variables de salida. El panel frontal del ventilador terminado se muestra en Figura 2. Los nombres de las variables, rangos y tamaños de paso que se muestran en Tabla 1 describen los dos ejemplos implementados en este protocolo. No son requisitos predeterminados e inmutables del RIP. Para otros experimentos en LabVIEW, los desarrolladores pueden definir diferentes nombres de variables del Panel Frontal y propiedades numéricas. El servidor RIP lee los nombres reales de las variables, los tipos de datos, los atributos de entrada/salida y las propiedades numéricas disponibles a partir de los metadatos del VI, y la página web genera los controles y visualizaciones correspondientes a partir de los metadatos devueltos.
    4. Agregue un bucle While al diagrama de bloques. Agregue dos registros de desplazamiento para almacenar velocidad_prev y tiempo_prev, e inicialice ambos valores a 0.
    5. Agregue un nodo de fórmula dentro del bucle While. Conecte Habilitar, PWM, Carga, Tau, KMaxRPM, Perturbación, velocidad_prev y tiempo_prev a los terminales de entrada izquierdos del nodo de fórmula, y configure SteadyRPM, velocidad_siguiente, VelocidadNormalizada, CorrienteA, PotenciaW y tiempo_siguiente como los terminales de salida correctos.
    6. Construya el Habilitar lógica de control fuera del nodo de fórmula. Utilice Habilitar como la señal selectora de modo que u = PWM cuando Habilitar es Verdadero y u = 0 cuando Habilitar es Falso.
    7. Introduzca el código del modelo del ventilador en el nodo de fórmula. Utilice este código para calcular la velocidad en estado estacionario, la velocidad real, la velocidad normalizada, la corriente, la potencia y el tiempo de funcionamiento; consulte el Archivo de Código Suplementario 1 para obtener el código completo.
    8. Conecte el velocidad_siguiente salida del nodo de fórmula a la SpeedRPM indicador y conectar velocidad_siguiente de regreso al Registro de Desplazamiento derecho para velocidad_prev. Conectar SteadyRPM al SteadyRPM indicador.
    9. Conectar tiempo_siguiente al Tiempo indicador y conectar tiempo_siguiente volver al registro de desplazamiento derecho para tiempo_prev. Conectar SpeedNorm, CorrienteA y PowerW a los indicadores de salida correspondientes.
    10. Agregue una función Esperar dentro del bucle Mientras y establezca el tiempo de espera en 50 ms. Agregue un botón Detener Local y conéctelo al terminal condicional del bucle Mientras.
    11. Guarde fengshan.vi. El diagrama de bloques del ventilador completado se muestra en Figura 3.
      PUNTO DE PAUSA: Tras guardar el VI del ventilador completado, se puede detener el flujo de trabajo. Para continuar más tarde, vuelva a abrir el VI guardado y confirme que todos los controles, indicadores del Panel Frontal y las conexiones del Diagrama de Bloques siguen presentes.
  2. Registre el experimento del ventilador en el servidor RIP.
    1. Abra RIPWebService.lvproj en el Explorador de proyectos de LabVIEW
      .
    2. Abra Configuration.vi desde el árbol del proyecto y localice la tabla de configuración del experimento.
    3. Agregue una nueva fila de experimento. Establezca el Nombre como fan. Establezca la ruta completa al archivo fengshan.vi guardado. Los campos de registro para el experimento fan se muestran en Figura 4.
    4. Complete los campos de configuración restantes. Establezca Autores como el autor del experimento, Palabras clave como Fan, Descripción como modelo de velocidad del ventilador y Frecuencia de muestreo como 200.
    5. En el menú de LabVIEW, seleccione Editar > Hacer que los valores actuales sean los predeterminados. Guardar configuración.vi
    6. Reinicie el servicio web RIP y confirme que el experimento del ventilador permanece listado en la interfaz de Configuración tras el reinicio.
      NOTA: El nombre del experimento distingue mayúsculas y minúsculas. El valor fan en la Configuración de RIP debe coincidir exactamente con el ID del experimento utilizado en el archivo XHTML del interfaz frontal. Para implementar otro VI de LabVIEW con la misma lógica de generación automática de interfaz, agregue una nueva entrada de experimento en la Configuración de RIP, establezca un nuevo valor de Nombre y configure Ruta al archivo VI correspondiente. Luego, utilice el mismo valor de Nombre como ID del experimento en el archivo XHTML. No es necesario reescribir la página del interfaz frontal para cada variable.
      ​PUNTO DE PAUSA: Después de guardar Configuration.vi y establecer los valores actuales como predeterminados, se puede detener el flujo de trabajo. Reanudar más tarde reiniciando RIP WebService y confirmando que el experimento del ventilador aún esté registrado.
  3. Preparar la página frontal para el experimento del ventilador.
    1. Coloque Fan_Automatic_UI.xhtml en el directorio Client utilizado como directorio raíz del front-end.
    2. Abra Fan_Automatic_UI.xhtml con un editor de texto.
    3. Localice la variable de identificación del experimento en la sección de script y establézcala en fan.
      NOTA: Este valor debe coincidir exactamente con el campo Nombre del experimento de ventilador en la Configuración de RIP. A continuación se muestran la configuración de los identificadores de experimento y la lógica compartida de generación de interfaz basada en metadatos para los archivos XHTML del front-end. Figura 5.
    4. Verifique que la página obtenga el origen de acceso actual a través de window.location.origin y solicite los metadatos del experimento mediante rip.info(), y pasa los metadatos devueltos a autobuildUI().
      NOTA: La página no debe codificar manualmente los nombres de las variables del ventilador, los rangos ni los tamaños de paso. En su lugar, las variables modificables se generan a partir de meta.writables.list, se generan variables legibles a partir de meta.legibles.lista, y los atributos numéricos como min, max y step se obtienen a partir de los metadatos devueltos por el servidor RIP.
    5. Guardar Fan_Automatic_UI.xhtml.
      ​NOTA: Para utilizar la misma lógica de generación de interfaz para otro VI de LabVIEW, establezca un nuevo ID de experimento en el archivo XHTML y registre el nombre del experimento correspondiente y la ruta del VI en la configuración de RIP. Los controles web y las visualizaciones de salida se generan según los metadatos devueltos por el experimento seleccionado.
  4. Configure la ruta de acceso de Caddy para el experimento del ventilador.
    1. Abra el archivo Caddyfile con un editor de texto.
    2. Establezca el directorio raíz del front-end en el directorio Cliente que contiene Fan_Automatic_UI.xhtml.
    3. Seleccione un puerto local no utilizado para que Caddy proporcione acceso desde el navegador a la página web y a las rutas RIP. En este protocolo, el puerto 8090 se utiliza como ejemplo de puerto de acceso proxy.
      NOTA: El puerto 8090 no es requerido por RIP ni por Caddy. Si el puerto 8090 está ocupado, sustitúyalo por otro puerto local no utilizado y utilice el mismo puerto en la dirección del navegador.
    4. Agregue una ruta que reescriba /fan a Fan_Automatic_UI.xhtml.
    5. Identifique el puerto del servicio web RIP configurado en LabVIEW. En este protocolo, se utiliza http://localhost:8001 como la dirección del servicio web RIP.
      NOTA: El puerto 8001 es el puerto de backend del servicio web LabVIEW/RIP utilizado en el entorno de prueba. Puede modificarse en la configuración del servicio web LabVIEW/RIP. Si se utiliza un puerto diferente, reemplace http://localhost:8001 en el archivo Caddyfile con la dirección correspondiente del servicio web RIP.
    6. Agregue una regla de proxy inverso que envíe las solicitudes /RIP/SSE* a la dirección del servicio web RIP, como http://localhost:8001.
    7. Agregue una regla de proxy inverso que envíe las solicitudes /RIP* a la dirección del servicio web RIP, como http://localhost:8001. La configuración del archivo Caddyfile se muestra en Figura 6.
    8. Abra el Símbolo del sistema en Windows. Cambie al directorio local de descarga o instalación de Caddy ingresando el siguiente comando:
      cd /d D:\caddy
      NOTA: En este protocolo, D:\caddy es la ruta local de descarga o instalación de Caddy utilizada en el entorno de prueba. Si Caddy se encuentra en otro directorio, sustituya D:\caddy por la ruta local correspondiente.
    9. Inicie Caddy con el Caddyfile especificado ingresando el siguiente comando:
      caddy.exe run --config Caddyfile
    10. Confirme que Caddy se inicie sin informar un error de configuración. Abra http://localhost:8090/fan en un navegador web y verifique que se genere la interfaz de usuario web del ventilador, como se muestra en Figura 7.
      ​NOTA: Si el navegador devuelve un error 502, confirme que el servicio web RIP está en ejecución, que el puerto del servicio web RIP en LabVIEW coincide con la dirección del proxy inverso en el archivo Caddyfile y que el puerto de acceso de Caddy seleccionado no esté ocupado.
  5. Verifique los resultados operativos del experimento del ventilador.
    1. Verifique que la página de inicio genere automáticamente el Habilitar, PWM, Carga, Tau, KMaxRPM, y Alteración controles de entrada
    2. Verifique que la página de inicio muestre el SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA y PowerW variables de salida
    3. Ajustar PWM y observe si SpeedRPM aumenta a medida que PWM aumentos y disminuciones como PWM disminuye.
    4. Ajuste la carga y observe si SteadyRPM y SpeedRPM disminuyen a medida que aumenta la carga.
    5. Ajuste la perturbación y observe si VelocidadRPM, CorrienteA y PowerW cambio en respuesta a la entrada de perturbación
    6. Verifique que Tiempo continúa aumentando, lo que confirma que el ventilador trasero VI está funcionando continuamente.

2. Construir e implementar el experimento de control de posición PID del motor de corriente continua

  1. Construya el modelo VI de control de posición PID del motor de corriente continua.
    1. Abra LabVIEW, cree un nuevo VI y guarde el archivo como Motor.vi. Guarde el VI en cualquier directorio al que pueda acceder el proceso RIP WebService.
      NOTA: La carpeta Private se utiliza únicamente como ejemplo de directorio y no está codificada de forma fija en RIP. Ingrese la ruta real del VI seleccionado durante el registro del experimento en RIP.
    2. En el Panel Frontal, agregue los controles de entrada para el modelo de control de posición PID del motor de corriente continua. En este ejemplo, asigne los nombres Setpoint, Kc, Ti, Td, Disturbance y Reset control a los controles de entrada. Configure Setpoint, Kc, Ti, Td y Disturbance como controles numéricos DBL, y configure Reset control como un control booleano.
      NOTA: Tabla 1 describe el significado físico, el rol en el modelo y el rango recomendado de las variables utilizadas en este ejemplo.
    3. Agregue los indicadores de salida para el modelo de control de posición PID del motor de corriente continua. En este ejemplo, asigne los nombres Position, Voltage, Time y Measured angular velocity a los indicadores de salida. Configure todos los indicadores de salida como indicadores DBL. La Tabla 1 describe el significado físico y el rol en el modelo de estas variables de salida. El Panel Frontal completado para el motor se muestra en la Figura 8.
      NOTA: Los nombres y rangos de las variables enumerados en la Tabla 1 describen los dos ejemplos implementados en este protocolo. No son requisitos fijos para el flujo de trabajo de generación automática de interfaz de usuario basado en RIP. Cuando se utiliza otro VI de LabVIEW, RIP lee los nombres reales de las variables, los tipos de datos, los atributos de entrada/salida y las propiedades numéricas disponibles a partir de los metadatos del VI. Por lo tanto, la lógica de generación del front-end no necesita codificar de forma fija los nombres de las variables, valores máximos, valores mínimos ni tamaños de paso para cada experimento.
    4. Agregue un Bucle While al Diagrama de Bloques. Agregue seis registros de desplazamiento para almacenar theta, omega, im, e_prev, integ y time, e inicialice los seis valores en 0.
    5. Agregue un Nodo de Fórmula dentro del Bucle While. De acuerdo con el diagrama del modelo de control de posición PID del motor de corriente continua mostrado en la Figura 9, utilice este Nodo de Fórmula como módulo de cálculo principal para el cálculo del error, el control PID, el limitado de voltaje, el modelo eléctrico, el modelo mecánico y la actualización de la posición.
      NOTA: Los parámetros internos del motor utilizados en este modelo, como R, L, J, b, Kt, Ke y Vmax, son parámetros normalizados para fines didácticos, no parámetros calibrados de un motor físico específico. Fueron seleccionados para producir una respuesta simulada estable y observable bajo el paso de tiempo y el límite de voltaje seleccionados, de modo que los efectos de Setpoint, Kc, Ti, Td y Disturbance puedan demostrarse claramente durante la operación web.
    6. Configure sp, theta, omega, im, e_prev, integ, Kc, Ti, Td, disturbance, reset y dt como terminales de entrada del Nodo de Fórmula. Configure theta_next, omega_next, im_next, e_next, integ_next y voltage como terminales de salida del Nodo de Fórmula.
    7. Conecte el control Setpoint al terminal de entrada sp del Nodo de Fórmula. Conecte Kc, Ti, Td y Disturbance a los terminales de entrada Kc, Ti, Td y disturbance del Nodo de Fórmula, respectivamente.
    8. Convierta la señal booleana del control Reset en una señal numérica y conéctela al terminal de entrada reset del Nodo de Fórmula. Ejecute el reinicio de estado cuando reset sea distinto de 0, y ejecute el control PID y la actualización del estado del motor cuando reset sea igual a 0.
    9. Agregue la constante numérica dt y establezca su valor en 0,001 s. Conecte dt al terminal de entrada dt del Nodo de Fórmula y utilícela para la actualización del tiempo.
    10. Establezca los parámetros internos del modelo del motor de corriente continua en el Nodo de Fórmula. Consulte la Tabla Suplementaria 2 para conocer el significado físico y el rol en el modelo de las variables del motor.
    11. Ingrese el código de control de posición PID del motor de corriente continua en el Nodo de Fórmula. Utilice este código para implementar la lógica de reinicio, el cálculo del error, el cálculo del término integral, el cálculo del término derivativo, el control PID, el limitado de voltaje, la actualización de la corriente, la actualización de la velocidad angular y la actualización de la posición; consulte los archivos de código suplementarios para obtener el código completo.
    12. Conecte theta_next al indicador Position, y reconecte theta_next al registro de desplazamiento derecho para theta. Conecte omega_next al indicador Measured angular velocity, y reconecte omega_next al registro de desplazamiento derecho para omega.
    13. Conecte el voltaje al indicador Voltage. Conecte im_next, e_next e integ_next nuevamente a los registros de desplazamiento derechos para im, e_prev e integ, respectivamente.
    14. Utilice una función Suma fuera del Nodo de Fórmula para calcular time_next = time + dt. Conecte time_next al indicador Time, y reconecte time_next al registro de desplazamiento derecho para time.
    15. Agregue una función Wait dentro del Bucle While y establezca el tiempo de espera en 1 ms. Agregue un botón de parada y conéctelo al terminal condicional del Bucle While.
    16. Guarde Motor.vi. El Diagrama de Bloques del motor completado se muestra en la Figura 10.
      PUNTO DE PAUSA: Tras guardar el VI del motor completado, el flujo de trabajo puede detenerse. Reanude más tarde abriendo nuevamente el VI guardado y confirmando que todos los controles, indicadores del Panel Frontal y conexiones del Diagrama de Bloques siguen presentes.
  2. Registre el experimento del motor en el Servidor RIP.
    1. Abra RIPWebService.lvproj en el Explorador de Proyectos de LabVIEW.
    2. Abra Configuration.vi desde el árbol del proyecto y localice la tabla de configuración del experimento.
    3. Agregue una nueva fila de experimento. Establezca Name como Motor. Establezca Path como la ruta completa del archivo Motor.vi guardado. Los campos de registro del experimento del motor se muestran en la Figura 11.
    4. Complete los campos de configuración restantes. Establezca Authors como el autor del experimento, Keywords como Motor, Description como modelo de control de posición del motor de corriente continua y Sampling Freq como 200.
    5. En el menú de LabVIEW, seleccione Edit > Make Current Values Default. Guarde Configuration.vi.
    6. Reinicie RIP WebService y confirme que el experimento Motor siga apareciendo en la interfaz de Configuración tras el reinicio.
      NOTA: El nombre del experimento distingue mayúsculas y minúsculas. El valor Motor en la Configuración de RIP debe coincidir exactamente con el ID del experimento utilizado en Motor_Automatic_UI.xhtml. Para implementar otro VI de LabVIEW con la misma lógica de generación automática de interfaz de usuario, agregue una nueva entrada de experimento en la Configuración de RIP, establezca un nuevo valor de Name y configure Path con el archivo VI correspondiente. Luego, utilice el mismo valor de Name como ID del experimento en el archivo XHTML. No es necesario reescribir la página del front-end para cada variable.
      ​PUNTO DE PAUSA: Tras guardar Configuration.vi y establecer los valores actuales como predeterminados, el flujo de trabajo puede detenerse. Reanude más tarde reiniciando RIP WebService y confirmando que el experimento Motor sigue registrado.
  3. Prepare la página del front-end para el experimento del motor.
    1. Coloque Motor_Automatic_UI.xhtml en el directorio Client utilizado como directorio raíz del front-end.
    2. Abra Motor_Automatic_UI.xhtml con un editor de texto.
    3. Localice la variable del ID del experimento en la sección de script y establézcala como Motor. Este valor debe coincidir exactamente con el campo Name del experimento del motor en la Configuración de RIP. La página del front-end del motor utiliza la misma lógica de generación de interfaz de usuario basada en metadatos mostrada en la Figura 5; únicamente se cambia el ID del experimento para que coincida con la entrada Motor en la Configuración de RIP.
    4. Verifique que la página contenga la lógica de lectura de metadatos de RIP, la lógica de generación de controles HTML, la función de escritura de RIP y la función de actualización de salidas.
      NOTA: La página no debe codificar manualmente de forma fija los nombres, rangos o tamaños de paso de las variables del motor. Estas propiedades se obtienen a partir de los metadatos devueltos por el Servidor RIP, siguiendo el mecanismo de generación de HTML a partir de metadatos basado en RIP descrito anteriormente11.
    5. Guarde Motor_Automatic_UI.xhtml.
      ​NOTA: Para utilizar la misma lógica de generación del front-end con otro VI de LabVIEW, establezca un nuevo ID de experimento en el archivo XHTML y registre el nombre del experimento correspondiente y la ruta del VI en la Configuración de RIP. Los controles web y las visualizaciones de salida se generan según los metadatos devueltos por el experimento seleccionado.
  4. Configure la ruta de acceso de Caddy para el experimento del motor.
    1. Abra el Caddyfile con un editor de texto.
    2. Establezca el directorio raíz del front-end como el directorio Client que contiene Motor_Automatic_UI.xhtml.
    3. Seleccione un puerto local no utilizado para que Caddy proporcione acceso del navegador a la página web y a las rutas de RIP. En este protocolo, el puerto 8090 se utiliza como ejemplo de puerto de acceso proxy.
      NOTA: El puerto 8090 no es requerido por RIP ni por Caddy. Si el puerto 8090 está ocupado, reemplácelo por otro puerto local no utilizado y utilice el mismo puerto en la dirección del navegador.
    4. Agregue una ruta que reescriba /motor a Motor_Automatic_UI.xhtml.
    5. Identifique el puerto de RIP WebService configurado en LabVIEW. En este protocolo, http://localhost:8001 se utiliza como dirección de RIP WebService.
      NOTA: El puerto 8001 es el puerto de back-end de LabVIEW/RIP WebService utilizado en el entorno de prueba. Puede modificarse en la configuración de LabVIEW/RIP WebService. Si se utiliza un puerto diferente, reemplace http://localhost:8001 en el Caddyfile con la dirección correspondiente de RIP WebService.
    6. Agregue una regla de proxy inverso que envíe las solicitudes /RIP/SSE* a la dirección de RIP WebService, como http://localhost:8001.
    7. Agregue una regla de proxy inverso que envíe las solicitudes /RIP* a la dirección de RIP WebService, como http://localhost:8001. La configuración del Caddyfile se muestra en la Figura 6.
    8. Abra el Símbolo del sistema en Windows. Cambie al directorio local de descarga o instalación de Caddy ingresando el siguiente comando:
      cd /d D:\caddy
      NOTA: En este protocolo, D:\caddy es la ruta local de descarga o instalación de Caddy utilizada en el entorno de prueba. Si Caddy se almacena en otro directorio, reemplace D:\caddy con la ruta local correspondiente.
    9. Inicie Caddy con el Caddyfile especificado ingresando el siguiente comando:
      caddy.exe run --config Caddyfile
    10. Confirme que Caddy se inicie sin reportar un error de configuración. Abra http://localhost:8090/motor en un navegador web y verifique que se genere la interfaz web del motor, como se muestra en la Figura 12.
      ​NOTA: Si la página web del motor se carga pero los valores de salida no se actualizan, confirme que RIP WebService esté en ejecución, que el VI del motor se esté ejecutando, que el puerto de RIP WebService en LabVIEW coincida con la dirección del proxy inverso en el Caddyfile y que la ruta /RIP/SSE* esté correctamente proxyfizada.
  5. Verifique los resultados de operación del experimento del motor.
    1. Verifique que la página del front-end genere automáticamente los controles de entrada Setpoint, Kc, Ti, Td, Disturbance y Reset.
    2. Verifique que la página del front-end muestre las variables de salida Position, Voltage, Time y Measured angular velocity.
    3. Ajuste Setpoint y observe si Position responde al cambio en la posición deseada.
    4. Ajuste Kc, Ti y Td y observe si Voltage, Position y Measured angular velocity cambian.
    5. Ajuste the disturbance y observe si la posición, el voltaje de control o la velocidad angular medida se ven afectados por la entrada disturbance.
    6. Haga clic en Reset control y observe si Position, Voltage, Measured angular velocity y los estados internos relacionados regresan a sus estados iniciales según la lógica de reinicio.

Resultados

Después de completar el flujo de trabajo descrito anteriormente, tanto el experimento del ventilador como el experimento de control de posición PID del motor de corriente continua se pueden acceder mediante la interfaz web generada automáticamente. Un resultado exitoso se indica mediante tres observaciones. Primero, la página web genera automáticamente controles de entrada y campos de visualización de salida según los metadatos de las variables devueltos por el servidor RIP. Segundo, cuando el usuario modifica una variable de entrada en la página web, el valor modificado se escribe en la VI de fondo de LabVIEW a través de la interfaz RIP. Tercero, las variables de salida calculadas por la VI de fondo se devuelven mediante RIP y se actualizan en la página web en tiempo real. Para el experimento del ventilador, después de ingresar http://localhost:8090/fan en un navegador, la página genera automáticamente controles de entrada y campos de salida a partir de los metadatos de RIP, como se muestra en Figura 7. El lado de entrada incluye Enable, PWM, Load, Tau, KMaxRPM y Disturbance, mientras que el lado de salida muestra SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA y PowerW. Durante el funcionamiento normal, TimeS aumenta continuamente, lo que indica que la VI de fondo fengshan.vi está en ejecución. Cuando se incrementa PWM, SpeedRPM y SteadyRPM aumentan en consecuencia. Cuando se incrementa Load, la velocidad del ventilador disminuye porque la carga reduce la velocidad de operación estable. Cuando se ajusta Disturbance, se pueden observar cambios correspondientes en SpeedRPM, CurrentA y PowerW. Estas observaciones confirman que las entradas del lado web se transmiten correctamente al fondo de LabVIEW y que las salidas calculadas se devuelven al frente mediante RIP.

Para el experimento de control de posición PID del motor de corriente continua, después de ingresar http://localhost:8090/motor en un navegador, la página genera automáticamente los controles y campos de salida correspondientes a partir de los metadatos RIP, como se muestra en Figura 12. Las variables de entrada incluyen Punto de consigna, Kc, Ti, Td, Perturbación, y Reiniciar control, y las variables de salida incluyen Posición, Voltaje, Tiempo, y Velocidad angular mediday. Cuando Punto de consigna se cambia, Posición responde al nuevo valor objetivo. Cuando los parámetros PID Kc, Ti, y Td se ajustan, la respuesta de salida, control voltaje, y velocidad angular medida cambie en consecuencia, indicando que los valores de los parámetros ingresados en la página web se escriben correctamente en el modelo de fondo de LabVIEW y participan en el cálculo de control. Cuando se activa el control de reinicio, las variables del modelo regresan a sus estados iniciales según la lógica de reinicio.

Los estados de fallo y comunicación del lado del navegador se muestran en la Figura 13, Figura 14, Figura 15. La Figura 13 muestra un caso de acceso fallido desde el navegador en el que Caddy no está en ejecución. El navegador intenta acceder a http://localhost:8090/motor pero muestra un mensaje ERR_CONNECTION_REFUSED, lo que indica que el servicio proxy local no está disponible o no está escuchando en el puerto de acceso seleccionado. La Figura 14 muestra un fallo de comunicación RIP POST después de que la página se ha cargado. En este caso, la consola del navegador informa un error 502 Bad Gateway para la solicitud RIP POST, lo que indica que el front end ha alcanzado la dirección del proxy, pero la solicitud no puede reenviarse ni procesarse correctamente por el back end del servicio web RIP. En contraste, la Figura 15 muestra un estado normal de comunicación del lado del navegador. Las herramientas de desarrollo del navegador muestran una carga exitosa de la página, solicitudes RIP POST y una solicitud SSE activa con expId=fan, lo que indica que el front end web se comunica con el RIP WebService a través del proxy Caddy y recibe actualizaciones en tiempo real a través del canal SSE.

En conjunto, los resultados exitosos del ventilador y del motor, junto con los resultados del diagnóstico en el navegador, demuestran que el mismo flujo de trabajo automatizado de generación de interfaz de usuario basado en metadatos puede reproducirse para dos experimentos diferentes en LabVIEW. Estos resultados también proporcionan criterios observables para distinguir la comunicación exitosa de fallos representativos en la implementación, mientras que los procedimientos correspondientes de solución de problemas se analizan en la sección de Discusión.

Diagrama del proceso de VI de LabVIEW a interfaz web, que muestra el servidor RIP y el proxy Caddy para la comunicación de datos.
Figura 1: Estructura general del sistema experimental. El sistema consta del VI de fondo de LabVIEW, el servidor RIP, el proxy Caddy y la interfaz web generada automáticamente. El VI de LabVIEW proporciona las variables del modelo, el servidor RIP lee los metadatos del VI y los valores de las variables, Caddy unifica la ruta de acceso y resuelve el acceso entre orígenes, y la interfaz web genera controles automáticamente. El nombre y el logotipo de Caddy se muestran únicamente para identificar el componente del servidor/proxy web Caddy utilizado en el flujo de trabajo. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama del sistema de control motor con gráfico de RPM, parámetros de entrada y análisis de datos de salida.
Figura 2: Panel Frontal del VI del ventilador. El Panel Frontal contiene controles de entrada para Enable, PWM, Load, Tau, KMaxRPM y Disturbance, y medidores de salida para SpeedRPM, SteadyRPM, TimeS, SpeedNorm, CurrentA y PowerW. Esta captura de pantalla se tomó del Panel Frontal de fengshan.vi en LabVIEW 2026 en el entorno experimental local de los autores. No se incluyen datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama del nodo de fórmula con registros de desplazamiento y bucle while para el análisis del proceso de control de RPM.
Figura 3: Diagrama de bloques del VI del ventilador. El modelo del ventilador se implementa con un bucle While, registros de desplazamiento, lógica de habilitación, un nodo de fórmula y los indicadores de salida. Esta captura de pantalla se tomó del diagrama de bloques de fengshan.vi en LabVIEW 2026 en el entorno experimental local propio de los autores. No se incluyen datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Interfaz de LabVIEW con configuración del modelo de ventilador, ajustes de muestreo y rutas de cámara para monitoreo del sistema.
Figura 4: Página de configuración de fan.vi. El experimento del ventilador se registra en la Configuración de RIP con el nombre del experimento «fan», la ruta real del VI, información de palabras clave, descripción y frecuencia de muestreo. Esta captura de pantalla se tomó desde la interfaz de Configuración de RIP utilizada con LabVIEW 2026 y RIP WebService en el entorno experimental local de los autores. No se incluyen datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Fragmentos de código JavaScript para la lógica de interfaz de usuario de aplicaciones web; método de creación de elementos dinámicos.
Figura 5: Configuración del ID del experimento y lógica de generación de interfaz de usuario basada en metadatos en los archivos de interfaz XHTML. Las capturas de pantalla del código XHTML se tomaron de Fan_Automatic_UI.xhtml y Motor_Automatic_UI.xhtml abiertos en Visual Studio Code. Las páginas del ventilador y del motor utilizan la misma lógica de lectura de metadatos y generación de controles; solo se modifica el ID del experimento para que coincida con el campo Nombre correspondiente en la Configuración de RIP. Las capturas de pantalla del código XHTML se realizaron desde Fan_Automatic_UI.xhtml y Motor_Automatic_UI.xhtml abiertos en Visual Studio Code en el entorno de desarrollo local de los autores. Los archivos de código fueron preparados por los autores para este protocolo. No se incluyen datos de usuarios de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama de configuración del servidor Caddy con rutas, proxies inversos y configuración de puerto de acceso.
Figura 6: Configuración del Caddyfile. El Caddyfile define el puerto de acceso del proxy local, establece el directorio raíz del interfaz frontal, reescribe las rutas /fan y /motor hacia los archivos XHTML correspondientes y realiza proxy inverso de las solicitudes /RIP/SSE* y /RIP* al puerto del WebService LabVIEW/RIP. La captura de pantalla de la configuración del Caddyfile se tomó del archivo Caddyfile abierto en Visual Studio Code, en el entorno de desarrollo local de los autores. El archivo Caddyfile fue preparado por los autores para configurar Caddy como servidor web local y proxy inverso. No se incluyen datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama del sistema de control de ventilador con controles deslizantes de entrada y visualizaciones de salida para ajuste de rendimiento.
Figura 7: Página de interfaz web de fan.vi. Esta captura de pantalla de la interfaz web se tomó de la página web de ventilador implementada localmente por los autores, utilizando Mozilla Firefox. La página frontal genera automáticamente controles de entrada y visualizaciones de salida basándose en los metadatos de variables devueltos por el servidor RIP. Los controles y campos de salida mostrados se generaron a partir de los metadatos RIP en el entorno experimental local de los autores. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama del sistema de control PID con motor, retroalimentación de posición y gráfica de respuesta dinámica.
Figura 8: Panel Frontal del VI del motor. El Panel Frontal contiene controles para Setpoint, Kc, Ti, Td, Perturbación y control de Reinicio, así como indicadores para Posición, Voltaje, Tiempo y Velocidad angular medida. Esta captura de pantalla se tomó del Panel Frontal de Motor.vi en LabVIEW 2026 en el entorno experimental local de los autores. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama de bloques del controlador PID con ecuaciones; flujo de entrada-salida entre modelos para el control del sistema.
Figura 9: Diagrama del modelo de control de posición PID para motor de corriente continua. El diagrama muestra la trayectoria de la señal desde el error del punto de consigna, el control PID, el límite de voltaje, la superposición de perturbaciones, la dinámica eléctrica, la dinámica mecánica y la actualización de la posición hasta la realimentación. Haga clic aquí para ver una versión más grande de esta figura.

Diagrama de LabVIEW del sistema de control con registros de desplazamiento, nodo de fórmula en un bucle while, para control de procesos.
Figura 10: Diagrama de bloques del VI del motor. El modelo del motor se implementa con un bucle While, registros de desplazamiento, un nodo de fórmula, lógica de temporización y visualizadores de salida. Esta captura de pantalla se tomó del diagrama de bloques de Motor.vi en LabVIEW 2026 en el entorno experimental local propio de los autores. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Interfaz de configuración del modelo de motor en LabVIEW para control de muestreo y configuración en análisis de ingeniería.
Figura 11: Página de configuración de Motor.vi. El experimento del motor se registra en RIP Configuration con el nombre del experimento Motor, la ruta real del VI, información de palabras clave, descripción y frecuencia de muestreo. Esta captura de pantalla se tomó desde la interfaz de RIP Configuration utilizada con LabVIEW 2026 y RIP WebService en el entorno experimental local de los autores. No se incluye datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Sistema de control de motor, interfaz de ajuste PID con control deslizante de entrada y visualizaciones de salida, indicador de velocidad angular.
Figura 12: Página de interfaz web de Motor.vi. La página frontal genera automáticamente controles de entrada y visualizaciones de salida para el experimento de control de posición PID del motor de corriente continua. Esta captura de pantalla de la interfaz web se tomó de la página web de motor implementada localmente por los autores utilizando Mozilla Firefox. Los controles y campos de salida mostrados se generaron a partir de metadatos RIP en el entorno experimental local de los autores. No se incluyen datos de usuarios de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Mensaje de error en página web con "ERR_CONNECTION_REFUSED" que indica problema de conexión al servidor local.
Figura 13: Acceso fallido desde el navegador cuando Caddy no está en ejecución. Cuando Caddy no se ha iniciado, no se puede acceder a la dirección local proxy http://localhost:8090/motor y el navegador muestra un mensaje ERR_CONNECTION_REFUSED. Este síntoma de fallo indica que el servicio de proxy local Caddy no está disponible o no está escuchando en el puerto de acceso seleccionado. Esta captura de pantalla del navegador se realizó utilizando Mozilla Firefox en el entorno de pruebas local de los autores y muestra el estado de acceso fallido cuando el proxy local Caddy no estaba en ejecución. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Interfaz de simulación de ventilador virtual con logotipo de la universidad en una pala giratoria del ventilador.
Figura 14: Fallo de comunicación RIP POST tras la carga de la página. La consola del navegador muestra un error 502 Bad Gateway para la solicitud RIP POST. Este resultado indica que la página web ha alcanzado la dirección del proxy Caddy, pero la solicitud no puede reenviarse ni procesarse correctamente en el servicio web RIP de fondo. Esta captura de pantalla de la consola del navegador se tomó utilizando las herramientas para desarrolladores de Mozilla Firefox en el entorno de implementación local de los autores, y muestra un fallo de comunicación RIP POST 502 Bad Gateway. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Interfaz de usuario de control de ventilador virtual con monitoreo de RPM; diagrama de configuración del modelo de ventilador; análisis de datos de red.
Figura 15: Estado de la comunicación del lado del navegador durante el funcionamiento normal. Las herramientas de desarrollo del navegador muestran una carga exitosa de la página, solicitudes POST de RIP y una solicitud SSE activa con expId=fan. Estas solicitudes indican que la interfaz web frontal se comunica con el servicio web RIP a través del proxy Caddy y recibe actualizaciones en tiempo real mediante el canal SSE. Esta captura de pantalla de las herramientas de desarrollo del navegador se tomó utilizando Mozilla Firefox en el entorno de implementación local de los autores y muestra una comunicación normal mediante solicitudes POST de RIP y SSE. No se incluyen datos de usuarios de terceros ni información confidencial. Haga clic aquí para ver una versión ampliada de esta figura.

Consola de depuración con registros de red y gráfico de uso de recursos para el análisis del programa LabVIEW.
Figura 16: Observación representativa individual del navegador y del uso de recursos a nivel de proceso para el experimento del ventilador. La captura de pantalla se realizó durante una prueba local del experimento con el ventilador. La consola muestra el tiempo de solicitud y respuesta de los metadatos, la cantidad de variables de metadatos, el tiempo de generación de la interfaz de usuario basado en metadatos, el tiempo de apertura de la conexión SSE y los datos SSE recibidos. La vista del administrador de tareas muestra los valores de CPU y memoria a nivel de proceso para los procesos del navegador y de LabVIEW en el momento de la captura. Estos valores son observaciones descriptivas de esta prueba individual y no representan mediciones de rendimiento replicadas ni una referencia estadística. Esta captura de pantalla se obtuvo utilizando las herramientas de desarrollador de Mozilla Firefox y el administrador de tareas de Windows en el entorno de pruebas local de los autores. Mozilla Firefox se utilizó para registrar la salida de la consola del navegador, y el administrador de tareas de Windows se empleó para observar el uso de CPU y memoria de los procesos del navegador y de LabVIEW. No se incluye ningún dato de usuario de terceros ni información confidencial. Haga clic aquí para ver una versión ampliada de esta figura.

Comparación de la interfaz de control del ventilador; valores de RPM, corriente y potencia vinculados en el diagrama de interfaz de escritorio y móvil.
Figura 17: Acceso simultáneo a la misma página web basada en RIP desde un navegador de escritorio y un navegador móvil. La página del experimento del ventilador se abre simultáneamente en dispositivos de PC y móviles, y ambos clientes muestran los controles y variables de salida generados automáticamente. La página web de escritorio se accedió mediante Mozilla Firefox, y la página web móvil se accedió mediante un navegador móvil en el mismo entorno de red local. Las capturas de pantalla se tomaron del entorno de pruebas local de los autores. No se incluyen datos de usuarios externos ni información confidencial. Haga clic aquí para ver una versión más grande de esta figura.

Nombre de la variableTipo de datoEntrada/SalidaSignificado físicoPapel en el modeloRango/Ajuste
HabilitarBooleanoEntradaInterruptor de funcionamiento del ventiladorControla si el modelo recibe la entrada PWM. Cuando es Verdadero, u = PWM; cuando es Falso, u = 0.Verdadero / Falso
PWMDBLEntradaEntrada de accionamientoDetermina la intensidad básica del accionamiento del ventilador y es la entrada principal utilizada para calcular la velocidad en estado estacionario SteadyRPM.0-1, paso 0,01
CargaDBLEntradaCoeficiente de cargaDescribe el efecto de debilitamiento de la carga sobre la velocidad en estado estacionario. A medida que aumenta la carga, la velocidad en estado estacionario disminuye.0-1, paso 0,01
TauDBLEntradaConstante de tiempo de respuestaDetermina qué tan rápido se aproxima la velocidad del ventilador a la velocidad en estado estacionario desde el estado anterior.0,1-5, paso 0,1
KMaxRPMDBLEntradaVelocidad máximaEstablece la velocidad máxima permitida por el modelo y se utiliza para limitar la velocidad y la normalización.500-6000, paso 100
PerturbaciónDBLEntradaEntrada de perturbaciónRepresenta el efecto de una perturbación externa o fluctuación de carga sobre la velocidad en estado estacionario, la corriente y la potencia.0-1, paso 0,1
SpeedRPMDBLSalidaVelocidad realRepresenta la velocidad de salida actual del ventilador y se actualiza mediante dinámica inercial de primer orden.Calculado por el modelo
SteadyRPMDBLSalidaVelocidad en estado estacionarioRepresenta la velocidad teórica en estado estacionario bajo las condiciones de entrada actuales.Calculado por el modelo
TimeSDBLSalidaTiempo de funcionamientoRepresenta el tiempo continuo de funcionamiento del modelo.Calculado por el modelo
SpeedNormDBLSalidaVelocidad normalizadaRepresenta la relación entre SpeedRPM y KMaxRPM.0-1 o calculado por el modelo
CurrentADBLSalidaCorrienteRepresenta la corriente estimada del modelo, que cambia con la entrada de accionamiento y la entrada de perturbación.Calculado por el modelo
PowerWDBLSalidaPotenciaRepresenta la potencia estimada del modelo, calculada a partir de la constante de voltaje y la corriente.Calculado por el modelo
ConsignaDBLEntradaPosición deseadaEstablece la posición que el motor debe alcanzar y forma el error e con la posición real Position.-3-3, paso 0,1
KcDBLEntradaGanancia proporcionalAjusta la intensidad de respuesta del controlador PID al error.0-10, paso 0,1
TiDBLEntradaTiempo integralAjusta la acción integral del controlador PID y se utiliza para reducir el error en estado estacionario.0-10, paso 0,1
TdDBLEntradaTiempo derivativoAjusta la acción derivativa del controlador PID y se utiliza para suprimir cambios excesivamente rápidos del error y mejorar la respuesta dinámica.0-5, paso 0,1
PerturbaciónDBLEntradaEntrada de perturbaciónRepresenta una perturbación externa superpuesta a la entrada del motor, que actúa sobre el modelo del motor junto con el voltaje de control.0-10, paso 0,1
Reiniciar controlBooleanoEntradaControl de reinicioActiva la limpieza del estado del modelo para que la posición, la velocidad angular, la corriente, el error y el término integral regresen a sus estados iniciales.Verdadero / Falso
PosiciónDBLSalidaPosición realRepresenta la posición angular actual del motor y sirve como variable de retroalimentación para el control PID.Calculado por el modelo
VoltajeDBLSalidaVoltaje de controlRepresenta la salida del controlador PID después del límite de voltaje y actúa sobre la entrada del motor.Calculado por el modelo; limitado a -24 a 24 V
TiempoDBLSalidaTiempo de funcionamientoRepresenta el tiempo continuo de funcionamiento del modelo del motor.Calculado por el modelo
Velocidad angular medidaDBLSalidaVelocidad angular medidaRepresenta la velocidad angular actual del motor y es la salida del estado mecánico del motor.Calculado por el modelo

Tabla 1: Variables de entrada y salida utilizadas en los ejemplos del ventilador y el motor de corriente continua. La tabla enumera el nombre de cada variable, el tipo de datos, el rol de entrada/salida, el significado físico, el rango recomendado y el tamaño del paso.

ParámetroValorSignificado físicoPapel en el modelo
R1Resistencia del inducidoRepresenta el término de resistencia en el circuito del inducido del motor y determina la caída de voltaje R × im en la ecuación de corriente.
L0.5Inductancia del inducidoRepresenta la inductancia del circuito del inducido y determina la tasa de cambio de la corriente. Un valor mayor de L produce una respuesta de corriente más lenta.
J0.01Momento de inerciaRepresenta la resistencia del rotor del motor a los cambios en la aceleración angular y determina qué tan rápidamente cambia la velocidad angular.
b0.1Coeficiente de amortiguamiento viscosoRepresenta el amortiguamiento mecánico y describe el par amortiguador que dificulta el aumento de la velocidad angular durante la rotación.
Kt0.01Constante de parRepresenta el coeficiente de proporcionalidad que convierte la corriente del inducido en par electromagnético.
Ke0.01Constante de fuerza electromotriz inversaRepresenta el coeficiente de proporcionalidad mediante el cual la velocidad angular genera la fuerza electromotriz inversa y describe el efecto de retroalimentación de la velocidad sobre la corriente.
Vmax24Voltaje de control máximoRepresenta el límite del voltaje de salida del controlador y mantiene el voltaje dentro del rango de -24 V a 24 V.
dt0.001Paso de simulación discretoRepresenta el intervalo de tiempo para cada actualización de estado basada en bucles y se utiliza para actualizar la corriente, la velocidad angular, la posición y el tiempo de ejecución.

Tabla 2: Parámetros internos utilizados en el modelo de control de posición PID del motor de corriente continua. La tabla enumera los parámetros eléctricos y mecánicos, símbolos, valores numéricos, unidades y funciones dentro del modelo.

Archivos de código complementarios: archivos completos de origen y configuración para reproducir los ejemplos del ventilador y del motor de corriente continua. Los archivos de código complementarios incluyen el código del nodo de fórmula de LabVIEW, la configuración del proxy inverso Caddy, los archivos XHTML de la interfaz frontal y los archivos fuente VI de LabVIEW utilizados en este protocolo. El archivo Código en LabVIEW Formula Node.docx contiene el código del nodo de fórmula para los modelos de control de posición PID del ventilador y del motor CC. Caddyfile.txt contiene la configuración local del servidor web y del proxy inverso. Fan_Automatic_UI.xhtml y Motor_Automatic_UI.xhtml contienen la lógica de la interfaz frontal web basada en metadatos. fengshan.vi y Motor.vi son los archivos VI de backend de LabVIEW para los experimentos del ventilador y del motor.Haga clic aquí para descargar este archivo.

Discusión

Un paso fundamental en este protocolo es la construcción y registro estandarizados del VI de backend en LabVIEW. Los controles e indicadores del Panel Frontal deben utilizar nombres de variables claros y únicos, y sus tipos de datos deben coincidir con las variables esperadas por el cálculo del modelo y por el proceso de lectura/escritura de RIP. En los dos ejemplos utilizados en este protocolo, las variables numéricas escalares se definen como controles o indicadores DBL, y las variables booleanas se definen como controles booleanos. El Diagrama de Bloques también debe mantener una actualización continua del estado mediante el Bucle While, los Registros de Desplazamiento y el Nodo de Fórmula, de modo que variables como la velocidad del ventilador, la posición del motor, la velocidad angular del motor, el voltaje y el tiempo puedan actualizarse durante la ejecución. Una vez construido el VI, el Nombre del experimento en la Configuración de RIP debe coincidir exactamente con el ID del experimento utilizado en el archivo XHTML correspondiente, y la Ruta del VI debe apuntar al VI guardado real. Estas configuraciones son importantes porque el frontend web no codifica directamente las variables de cada experimento. En cambio, depende de los metadatos devueltos por el Servidor RIP para identificar las variables escribibles, las variables legibles, los tipos de datos y las propiedades numéricas10,11.

Los principales problemas de solución de inconvenientes están relacionados con la consistencia entre el ID del experimento XHTML, la configuración de RIP, el servicio web RIP y la configuración del proxy Caddy. Si el ID del experimento en el archivo XHTML no coincide con el nombre del experimento en la configuración de RIP, la página web no puede solicitar los metadatos correctos y, por lo tanto, no puede generar los controles y campos de salida esperados. Si la ruta del VI es incorrecta o el servicio web RIP no está iniciado, la página web podría abrirse pero no puede comunicarse con el entorno de LabVIEW. Si Caddy no se está ejecutando, el navegador no puede acceder a la dirección de proxy local seleccionada y podría mostrar un mensaje ERR_CONNECTION_REFUSED, como se muestra en Figura 13. Si Caddy está en ejecución pero el destino del proxy inverso no coincide con el puerto del servicio web RIP, la página podría cargarse mientras que las solicitudes POST de RIP fallen con un error 502 Bad Gateway, como se muestra en Figura 14. Si la ruta /RIP/SSE* no funciona correctamente, la página podría abrirse y mostrar los controles, pero los valores de salida no se actualizan en tiempo real. Durante el funcionamiento normal, las herramientas de desarrollo del navegador deberían mostrar una carga exitosa de la página, solicitudes POST de RIP y una solicitud SSE activa con el ID del experimento correcto, como se muestra en Figura 15. Por lo tanto, la solución de problemas debe comenzar verificando el ID del experimento, la ruta del VI, el estado del servicio web RIP, el estado de ejecución de Caddy, los puertos del proxy y la ruta SSE. Si la comunicación aún presenta un comportamiento anómalo, reiniciar tanto el servicio web RIP como Caddy, borrar la caché del navegador o repetir la prueba en otro navegador podría ayudar a distinguir comportamientos específicos del navegador de problemas de configuración de RIP/Caddy.

El presente protocolo es reproducible en ambos ejemplos porque se aplica el mismo flujo de trabajo de creación, registro, despliegue y verificación tanto a un modelo de velocidad de ventilador como a un modelo de control de posición PID para un motor de corriente continua. Para reducir la dependencia de cajas de herramientas especializadas, los VI del back-end se reconstruyen utilizando estructuras básicas de LabVIEW, incluyendo controles e indicadores del panel frontal, bucles While, registros de desplazamiento, nodos de fórmula, y variables numéricas escalares estándar y variables booleanas. Sin embargo, la reproducibilidad entre diferentes versiones de LabVIEW, instalaciones de Windows y entornos de red local aún depende de detalles de configuración como rutas de archivos, permisos de acceso, puertos locales, comandos de inicio de servicios y comportamiento del navegador. El flujo de trabajo también puede extenderse a experimentos remotos relacionados con hardware, aunque el método no debe interpretarse como un reconocimiento directo del hardware desde el lado web. El front-end web identifica los controles e indicadores del panel frontal de LabVIEW mediante metadatos RIP. Por lo tanto, los sensores, actuadores, instrumentos o dispositivos de control de procesos deben conectarse y procesarse primero en el VI del back-end de LabVIEW mediante controladores de hardware adecuados, módulos de adquisición de datos, módulos de control de instrumentos u otros mecanismos de adaptación al hardware. Una vez que las mediciones del hardware y los comandos de control se asignan a los indicadores y controles del panel frontal, el front-end web basado en RIP puede reconocer estas variables de la misma manera en que reconoce las variables de simulación utilizadas en este protocolo. Estudios previos sobre laboratorios remotos basados en LabVIEW han demostrado que LabVIEW puede utilizarse como entorno de back-end para experimentos remotos de ingeniería de control, experimentos robóticos, bancos de pruebas de control de procesos, adquisición de datos de sensores e interacción con dispositivos físicos9,12,17,18,19,20.

Figura 16 presenta un ejemplo representativo único registrado durante un experimento con ventilador local. El código del front-end fue instrumentado para registrar el tiempo de solicitud/respuesta de metadatos, el número de variables de metadatos, el tiempo de generación de la interfaz de usuario (UI) basado en metadatos, el tiempo de apertura de la conexión SSE y los datos SSE recibidos. En este ejemplo, la consola del navegador reportó un tiempo de solicitud/respuesta de metadatos de 68,00 ms, identificó 7 variables modificables y 7 variables legibles a partir de los metadatos de RIP, generó los elementos correspondientes de la interfaz de usuario en 2,00 ms y abrió la conexión SSE en 16,00 ms. Las entradas repetidas de datos SSE mostraron que las variables de salida como SpeedRPM, TimeS, SteadyRPM, SpeedNorm, CurrentA y PowerW eran recibidas continuamente desde el back-end de LabVIEW. La vista del administrador de tareas en el mismo estado de prueba local mostró aproximadamente un 1,5 % de uso de CPU y 391,7 MB de memoria para el proceso de Firefox, mientras que el proceso de LabVIEW mostró un 0 % de uso de CPU y 9,2 MB de memoria en el momento de la captura. Estas observaciones proporcionan evidencia básica de que la recuperación de metadatos, la generación de interfaz de usuario basada en metadatos, la comunicación RIP/SSE y la sobrecarga de CPU a nivel de proceso pueden observarse en el entorno de implementación local. Sin embargo, estos datos tienen como finalidad la verificación a nivel de implementación y no constituyen una evaluación exhaustiva del rendimiento. En trabajos futuros será necesario realizar una evaluación sistemática del rendimiento bajo diferentes navegadores, ensayos repetidos, cargas mayores de variables, hardware físico y múltiples usuarios simultáneos.

Este método también tiene limitaciones, especialmente cuando se extiende a estructuras de datos complejas, experimentos con hardware y operaciones multiusuario. El flujo de trabajo actual es más adecuado para variables de entrada/salida numéricas escalares y booleanas. No proporciona automáticamente soporte completo para matrices complejas, clústeres, estructuras de datos anidadas, relaciones de gráficos o visualizaciones específicas del dominio. Estos casos pueden requerir reglas adicionales de mapeo de metadatos o componentes de interfaz de usuario escritos manualmente. La interfaz de usuario generada automáticamente puede crear controles y visualizaciones básicos a partir de los metadatos de las variables, pero no puede inferir completamente la relación física entre las variables, seleccionar la visualización más adecuada ni diseñar interacciones de seguridad específicas del experimento. Cuando el flujo de trabajo se extiende a equipos reales, se requieren consideraciones adicionales, incluyendo controladores de hardware, calibración de dispositivos, restricciones de muestreo, límites de actuadores, lógica de parada de emergencia, autenticación y mecanismos de control de escritura multiusuario. La implementación actual también puede ser accedida por múltiples dispositivos cliente mediante navegadores web estándar en el mismo entorno de red local. Como se muestra en Figura 17, la misma página del experimento del ventilador se abrió simultáneamente en un navegador de escritorio y en un navegador móvil, y ambos clientes mostraron los controles generados automáticamente y las variables de salida correspondientes. Esta observación indica un acceso básico simultáneo para múltiples clientes que desean ver e interactuar con la misma página del experimento. Sin embargo, esto no debe interpretarse como un marco completo de control multiusuario, ya que la implementación actual no incluye autenticación de usuarios dedicada, bloqueo de control, arbitraje de escritura concurrente, colas de escritura ni mecanismos de resolución de conflictos. Estas limitaciones son coherentes con estudios previos sobre laboratorios remotos, en los cuales los laboratorios remotos complejos o colaborativos generalmente requieren diseño específico de interfaz para cada experimento, mecanismos de sincronización, restricciones de seguridad y lógica de gestión de usuarios13,14,15,16,17.

El valor metodológico de este protocolo no radica en que introduzca una nueva arquitectura RIP ni en que amplíe los tipos de datos compatibles con RIP. En cambio, su valor consiste en proporcionar una ruta de implementación completa y reproducible para aplicar un mecanismo establecido de generación automática de interfaces de usuario basado en RIP a diferentes sistemas LabVIEW. En comparación con la creación de una interfaz web personalizada para cada experimento, este flujo de trabajo reduce la implementación repetida del diseño básico de controles, la vinculación de variables y la lógica de comunicación de lectura/escritura cuando la VI de fondo expone variables compatibles8,9,10,11. Por lo tanto, el protocolo resulta útil para la enseñanza de la ingeniería, el desarrollo de laboratorios remotos y la implementación rápida de simulaciones o experimentos didácticos de bajo riesgo que requieran ajuste de parámetros mediante navegador y monitoreo en tiempo real del estado. Trabajos futuros deberían extender el flujo de trabajo a estructuras de datos más complejas, dispositivos experimentales físicos, control formal de acceso multiusuario y evaluación cuantitativa del rendimiento, incluyendo el tiempo de generación de la interfaz, la latencia de comunicación, la estabilidad de sincronización, la carga del servidor, la sobrecarga de CPU y la usabilidad del front-end.

Divulgaciones

Los autores utilizaron herramientas asistidas por inteligencia artificial únicamente para mejorar el lenguaje. Todo el contenido científico, los procedimientos experimentales, la implementación del software, las figuras, los resultados, las interpretaciones y la redacción final fueron revisados, corregidos y aprobados por los autores. No se utilizó ninguna herramienta de inteligencia artificial para generar datos experimentales.

Agradecimientos

Este trabajo fue apoyado por los Programas de Formación de Pregrado para la Innovación de la Universidad de Wuhan.

Materiales

Lista de materiales utilizados en este artículo
NombreEmpresaNúmero de catálogoComentarios
Servidor proxy CaddyCaddyN/AProxy inverso utilizado para servir la interfaz web y reenviar las solicitudes /RIP al servicio web RIP
CaddyfilePreparado por los autoresN/ADefine rutas de archivos estáticos y rutas de proxy inverso para la comunicación RIP
Fan_Automatic_UI.xhtmlPreparado por los autoresN/AInterfaz web basada en metadatos para el experimento del ventilador
LabVIEWNational Instruments2026Software utilizado para construir y ejecutar fengshan.vi y Motor.vi
Sistema operativo Microsoft WindowsMicrosoftWin11Sistema operativo utilizado para ejecutar LabVIEW, RIP WebService, Caddy y el navegador.
Motor_Automatic_UI.xhtmlPreparado por los autoresN/AInterfaz web basada en metadatos para el experimento del motor
Navegador de escritorio Mozilla FirefoxMozilla2026Navegador de escritorio utilizado para acceder a la interfaz web, herramientas de desarrollo, observaciones de tiempo y recursos, y capturas de pantalla de Red/Consola.
Servicio web RIPUNEDLabshttps://github.com/Nebulous-Systems/rip-server_labviewRecibe solicitudes POST RIP y proporciona la capa de comunicación del servicio web utilizada por la interfaz frontal del navegador.
Administrador de tareas de WindowsMicrosoftIncorporado en WindowsUtilizado para registrar observaciones del uso de CPU y memoria a nivel de proceso para los procesos del navegador y LabVIEW.

Referencias

  1. Gomes, L., Bogosyan, S. Current trends in remote laboratories. IEEE Trans Ind Electron. 2009;56(12):4744–4756.
  2. Ma, J., Nickerson, J. V. Hands-on, simulated, and remote laboratories: A comparative literature review. ACM Comput Surv. 2006;38(3):7-es.
  3. Heradio, R. et al. Virtual and remote labs in education: A bibliometric analysis. Comput. Educ. 2016;98:14–38.
  4. May, D., Jahnke, I., Moore, S. Online laboratories and virtual experimentation in higher education from a sociotechnical-pedagogical design perspective. J. Comput. High. Educ. 2023;35:203–222.
  5. Amador Nelke, S. et al. Enhancing lessons on the Internet of Things in science, technology, engineering, and medical education with a remote lab. Sensors.2024;24(19):6424.
  6. Lei, Z. et al. Interactive and visualized online experimentation system for engineering education and research. J. Vis. Exp. 2021;(177):e63342.
  7. Zhang, G., Lei, Z., Hu, W., Zhou, H. Online virtual reality networked control laboratory applied in control engineering education. J. Vis. Exp. 2024;(204):e66432.
  8. Fabregas, E., Farias, G., Dormido-Canto, S., Dormido, S., Esquembre, F. Developing a remote laboratory for engineering education. Comput. Educ. 2011;57(2):1686–1697.
  9. Chacón, J., Vargas, H., Farias, G., Sánchez, J., Dormido, S. EJS, JIL Server, and LabVIEW: An architecture for rapid development of remote labs. IEEE Trans. Learn. Technol.2015;8(4):393–401.
  10. Chacón, J., Farias, G., Vargas, H., Visioli, A., Dormido, S. Remote Interoperability Protocol: A bridge between interactive interfaces and engineering systems. IFAC-PapersOnLine.2015;48(29):247–252.
  11. de la Torre, L., Chacón, J., Chaos, D., Heradio, R., Chandramouli, R. Using IoT-type metadata and smart Web design to create user interfaces automatically. IEEE Trans. Ind. Inform. 2023;19(3):3109–3118.
  12. Chaos, D., Chacón, J., Lopez-Orozco, J. A., Dormido, S. Virtual and remote robotic laboratory using EJS, MATLAB, and LabVIEW. Sensors. 2013;13(2):2595–2612.
  13. Haj-Hosseini, N., Jonasson, H., Stridsman, M., Carlsson, L. Interactive remote electrical safety laboratory module in biomedical engineering education. Educ. Inf. Technol. 2024;29:20505–20521.
  14. Galán, D. et al. Safe experimentation in optical levitation of charged droplets using remote labs. J. Vis. Exp. 2019;(143):e58699.
  15. Kurtz, M., Benabbou, A., Pons, C., Broisin, J. Collaboration in virtual and remote laboratories for education: A systematic literature review. Int. J. Comput.-Support. Collab. Learn. 2025;20:549–603.
  16. Zamarreño, J. M., Ríos, J. C., Alonso, G. Virtual and remote laboratory as a complementary support in control education. Discov. Educ. 2025;4:477.
  17. Chacón, J., Sáenz, J., de la Torre, L., Díaz, J. M., Esquembre, F. Design of a low-cost air levitation system for teaching control engineering. Sensors. 2017;17(10):2321.
  18. Stefanovic, M., Cvijetkovic, V., Matijevic, M., Simic, V. A LabVIEW-based remote laboratory experiments for control engineering education. Comput. Appl. Eng. Educ.2011; 19(3):538–549.
  19. González, I., Calderón, A. J., Mejías, A., Andújar, J. M. Novel networked remote laboratory architecture for open connectivity based on PLC-OPC-LabVIEW-EJS integration. Application in remote fuzzy control and sensors data acquisition. Sensors. 2016;16(11):1822.
  20. Abdulwahed, M., Nagy, Z. K. Developing the TriLab, a triple access mode (hands-on, virtual, remote) laboratory, of a process control rig using LabVIEW and Joomla. Comput. Appl. Eng. Educ. 2013;21(4):614–626.

Reimpresiones y permisos

Etiquetas

Interfaz de usuario webGeneraci n autom tica de IUInstrumentos virtualesConfiguraci n del servidor RIPProxy inversoProxy CaddyControl de posici n PIDMetadatos variables

Este artículo ha sido publicado

Video próximamente

Contáctenos
Recomendar a la biblioteca

Privacidad

Términos de uso

Políticas

Copyright © 2026 MyJoVE Corporation. Todos los derechos reservados.