Prácticas recomendadas para el desarrollo del módulo de código TestStand

Antes de comenzar a desarrollar un sistema de pruebas, considere la posibilidad de definir un enfoque general para los siguientes aspectos del sistema de prueba:

• Granularidad de los módulos de código: defina el alcance de la funcionalidad de cada módulo.
• Definición de una estructura de directorio para el código de prueba: una estructura de directorio bien definida facilita el intercambio de código con otros desarrolladores y la implementación de código en los sistemas de pruebas.

Granularidad de los módulos de código

Al diseñar un sistema de pruebas, es importante definir un nivel consistente de granularidad para los módulos de código.  La granularidad es el alcance de la funcionalidad de cada módulo de código en un sistema de pruebas.  Una secuencia de pruebas con baja granularidad llama a pocos módulos de código, cada uno de los cuales realiza más funciones, mientras que una secuencia con alta granularidad llama a muchos módulos de código, cada uno con un alcance menor.

Debe buscar un equilibrio entre estos extremos, ya que cada uno tiene sus propias ventajas.  

Implementar una prueba simple mediante diferentes niveles de granularidad

Para mantener una granularidad constante en todo el sistema de pruebas, cree un conjunto de estándares para el desarrollo de módulos de código, como por ejemplo:

• Realice la inicialización y el apagado del hardware en módulos de código separados para permitir que TestStand administre los ciclos de vida de las sesiones de hardware.
• Determine la granularidad en función de los requisitos de prueba mediante la creación de un solo paso de prueba para cada elemento de los requisitos.  Este enfoque facilita la cobertura de todos los requisitos.  Además, puede usar NI Requirements Gateway con TestStand para crear enlaces entre los pasos de prueba y los documentos de requisitos.  Para obtener más información, consulte el tutorial Acoplamiento de NI Requirements Gateway con TestStand.
• Use la estructura deseada de los resultados de la prueba para ayudar a determinar el alcance de los pasos individuales.  Dado que cada paso crea una entrada de resultados, la creación de una asignación individual de los pasos de prueba a las entradas de resultados requeridas facilitará la organización de los resultados de la prueba con cambios mínimos en los informes o el registro de la base de datos.

Definición de una estructura de directorio para archivos de secuencia y módulos de código

Al especificar la ruta de un módulo de código en un paso de prueba, puede elegir una ruta absoluta o relativa. Se recomienda evitar rutas absolutas por los siguientes motivos:

• Si mueve el archivo de secuencia y sus dependencias en el disco, la ruta ya no será válida.
• Si implementa el archivo de secuencia en una máquina de destino, las rutas no serán válidas a menos que los archivos se instalen en la misma ubicación.

Cuando especifica una ruta relativa, TestStand utiliza una lista de directorios de búsqueda para resolver la ruta.  Estos directorios de búsqueda suelen contener el directorio de archivos de secuencia actual, los directorios específicos de TestStand y los directorios del sistema.

Es importante definir una estructura de archivos para sus secuencias de prueba y módulos de código antes de comenzar el desarrollo.  Use las siguientes normas para definir una estrategia para almacenar archivos de secuencia y módulos de código.

• Para los módulos de código que se utilizan en un solo archivo de secuencia, guarde los archivos del módulo de código en un subdirectorio relativo al archivo de secuencia.  Esto garantizará que el archivo de secuencia pueda encontrar siempre los módulos de código si se mueve en el sistema o se copia a otro sistema.
• Para los módulos de código que se comparten entre varios archivos de secuencia relacionados, puede usar el mismo enfoque que con un solo archivo de secuencia si guarda los archivos de secuencia relacionados en el mismo directorio.  Considere la posibilidad de crear un espacio de trabajo que contenga todos los archivos de secuencia y módulos de código relacionados.
• Para los módulos de código que se comparten entre varios archivos de secuencia no relacionados, considere la posibilidad de crear un directorio específico que contenga todos los módulos de código compartidos y de crear un nuevo directorio de búsqueda que apunte a esta ubicación.  Esto asegurará que cualquier archivo de secuencia en el sistema pueda encontrar los archivos por medio de una ruta relativa a este directorio de búsqueda.  Al implementar el módulo de código, puede implementar el archivo de configuración de directorios de búsqueda, ubicado en <TestStand Application Data>\Cfg\SearchDirectories.cfg.  Si utiliza este enfoque, no mueva los archivos del módulo de código dentro del directorio para evitar romper las rutas especificadas en los archivos de la secuencia de llamada.

Defina una estructura de directorio donde los módulos de código están en un subdirectorio del archivo de secuencia

Al implementar el código de prueba con la Utilidad de implementación TestStand, puede elegir destinos específicos para los archivos de secuencia y los módulos de código dependientes.  Si existe una ruta relativa entre los directorios de destino para el archivo de secuencia y el módulo de código, la Utilidad de implementación TestStand actualiza la ruta en el archivo de secuencia para que apunte a la ubicación actualizada.  En la mayoría de los casos, es mejor hacer coincidir la estructura de directorios de su implementación con la del sistema de desarrollo, para asegurarse de que la implementación sea lo más similar posible al código en su máquina de desarrollo.

Al definir el alcance de los módulos de código para su sistema de pruebas, es importante definir una estrategia para la cual se implementará la funcionalidad en los módulos de código en lugar de en el archivo de secuencia. Las siguientes secciones pueden ayudarle a determinar el lugar más apropiado para implementar una funcionalidad común:

• Evaluación de las mediciones de prueba con respecto a los límites
• Definición de los valores de los estímulos
• Informe y registro de los resultados de las pruebas y los errores
• Operaciones de ciclos
• Realización de operaciones de conmutación
• Realizar cálculos y manipulación de datos

Evaluación de los límites y los resultados de las pruebas

Lo ideal sería que el módulo de código tuviera funcionalidades directamente relacionadas con la obtención de mediciones de prueba y que la secuencia de prueba procesara el resultado de la prueba sin procesar. Este enfoque tiene los siguientes beneficios:

• Los límites de prueba son más fáciles de administrar en el archivo de secuencia, ya que puede usar herramientas como el cargador de propiedades para administrar los límites de varios pasos en una única ubicación centralizada.
• Los límites de prueba definidos en la secuencia se incluirán automáticamente en los resultados de la prueba, como el informe o la base de datos.
• Los límites de prueba se pueden actualizar sin realizar cambios en los módulos de código y requerirán menos validación ya que solo se modifica la secuencia de prueba.

Para obtener mediciones más simples, el módulo de código puede devolver el valor de medición sin procesar a la secuencia para su procesamiento. Por ejemplo, si un paso de prueba mide el voltaje en un pin específico de la unidad bajo prueba (UUT), el módulo de código debe devolver el valor medido en lugar de realizar la verificación directamente en el módulo de código.  Puede procesar este valor para determinar el resultado de la prueba en el archivo de secuencia utilizando un paso de prueba de límite numérico.

La evaluación de los límites en el paso de prueba simplifica los módulos de código y mejora el registro de resultados

Sin embargo, debido a la complejidad de algunas pruebas, no siempre es posible procesar los resultados de la prueba sin procesar en el archivo de secuencia.  Para hacer mediciones más complejas, quizá sea necesario un procesamiento adicional de los datos de resultados.  Los datos complejos se pueden procesar en una sola cadena o resultado numérico, que luego se puede evaluar en TestStand a través de una comparación numérica o cadena.  Por ejemplo, los resultados de una prueba de barrido de frecuencia son complejos y no se pueden evaluar directamente, pero los datos se pueden procesar en un solo número que representa el valor mínimo.  En este caso, el módulo de código debe evaluar el resultado procesado y devolver los datos de frecuencia en un parámetro independiente para su registro, como se muestra en el siguiente ejemplo de prueba del dispositivo móvil:

Para datos más complejos, procese los datos en el módulo de código para generar un resultado numérico o de cadena, y use un parámetro para pasar los datos sin procesar para registrarlos

Si los datos sin procesar son de gran tamaño, pasar los datos a TestStand puede tener un impacto significativo en el rendimiento.  En este caso, plantéese registrar los datos directamente en un archivo TDMS y vincularlos al archivo desde el informe de prueba.  Esto le permite hacer referencia a los datos del informe sin la necesidad de pasarlos a TestStand.  Consulte la sección Incluir hipervínculos en un informe: archivo TDMS para obtener más información sobre este enfoque.

Si el paso no puede determinar el resultado de la prueba utilizando los tipos de evaluación disponibles en los Pasos de prueba, considere la posibilidad de crear un nuevo tipo de paso con funcionalidad adicional para manejar el tipo de prueba requerido.  Para obtener más información sobre cómo crear tipos de pasos personalizados, consulte el artículo Prácticas recomendadas para el desarrollo de tipos de pasos personalizados en esta serie.

Definición de estímulos de prueba

Para muchas pruebas, el entorno UUT o de prueba debe estar en un estado determinado antes de que se pueda realizar la prueba.  Por ejemplo, es posible que se requiera un voltaje de excitación para tomar una medida de temperatura, o que una cámara térmica deba ajustarse a una temperatura determinada.  Para estos tipos de módulos, utilice parámetros para pasar los valores de entrada, como el voltaje de excitación o la temperatura deseada.  Esto proporciona muchos de los mismos beneficios que la devolución de los datos sin procesar en los módulos de código de prueba frente a los límites de procesamiento directamente en el código, como se ha explicado en la sección anterior.

Registro de los resultados de la prueba

TestStand proporciona una funcionalidad integrada para la generación de informes y el registro de bases de datos con los resultados de los pasos de prueba. Por esta razón, evite implementar cualquier tipo de registro de datos directamente dentro de los módulos de código.  En su lugar, asegúrese de que los datos que desea registrar se pasen como un parámetro y utilice TestStand para registrar los datos.  Algunos datos, como los resultados de las pruebas, los límites y la información de errores se registran automáticamente.  Para registrar otros datos, puede usar la función de resultados adicionales para especificar parámetros adicionales que se incluirán en el informe.

Para obtener más información sobre cómo añadir resultados al informe de prueba, consulte el ejemplo Adición de datos personalizados a un informe que se incluye con TestStand.

Si tiene requisitos específicos para el registro, considere la posibilidad de modificar o crear un complemento de procesamiento de resultados. Esto le permitirá utilizar la recopilación de resultados del TestStand incorporado para reunir los resultados, mientras que podrá determinar cómo se procesan y presentan los resultados. Para obtener más información, consulte la sección Creación de complementos del documento Prácticas recomendadas para el desarrollo y la personalización del modelo de proceso de TestStand.

Operaciones de ciclos

Puede resultar difícil determinar el mejor enfoque para implementar un ciclo, ya que cada enfoque tiene sus propias ventajas y desventajas. Las pautas siguientes le ayudarán a determinar qué estrategia es la mejor para su aplicación:

Reproducción interna de ciclos en el módulo de código

• Rendimiento mejorado, especialmente cuando se reproducen ciclos con rapidez.  Dado que cada llamada al módulo de código puede introducir unos pocos milisegundos de sobrecarga, reproducir ciclos en cientos o miles de iteraciones con un ciclo externo puede afectar la velocidad de la prueba.
• Permite un comportamiento de ciclos más complejo.  

Reproducción externa en el archivo de secuencia

• Vea y modifique la configuración de ciclo directamente en el archivo de secuencia sin modificaciones en el módulo de código.
• Fácil acceso al índice de ciclos en el archivo de secuencia.  Esto es útil para determinar rutas de conmutación u otro comportamiento que cambia según la iteración actual.
• Cada iteración del ciclo se registra por separado, mostrando los resultados de cada iteración en el informe o la base de datos.

Realización de operaciones de conmutación

Muchos sistemas de pruebas utilizan la conmutación para permitir que una sola pieza de hardware pruebe varios sitios.  Los conmutadores le permiten controlar mediante programación qué pines de una Unidad bajo prueba (UUT) están conectados a un hardware específico a través de rutas predefinidas.  

Puede implementar la conmutación en los módulos de código TestStand de las siguientes maneras:

• Mediante las propiedades de conmutación integradas de un paso (requiere NI Switch Executive).
• Mediante los pasos del conmutador TestStand IVI (solo TestStand de 32 bits).
• Al llamar las funciones del controlador de conmutación directamente a los módulos de código.

Cuando utilice el hardware de NI Switch, puede usar NI Switch Executive para definir rutas rápidamente. Si tiene acceso a NI Switch Executive, el uso de la configuración de pasos integrada para la conmutación suele ser el mejor enfoque y tiene los siguientes beneficios:

• La definición de configuraciones del conmutador en el paso desacopla las funciones de conmutación del código de prueba, lo que puede aumentar la reutilización y reducir la complejidad de los módulos de código.
• Muchos de los campos de la configuración de conmutación se especifican mediante una expresión que le permite utilizar la propiedad RunState.LoopIndex u otra variable para indexar los nombres de rutas o de grupo de rutas para los pasos que itera.
• Para pruebas paralelas, puede usar el índice de socket de prueba (RunState.TestSockets.MyIndex) como parte de la cadena de enrutamiento para usar diferentes rutas de conmutación para cada socket de prueba.
• Puede vincular la duración de la conexión al paso, secuencia, subproceso o ejecución.

Utilice NI Switch Executive para especificar rutas directamente desde la configuración de pasos de TestStand, incluyendo soporte para la expresión de TestStand para determinar dinámicamente la ruta usando el índice de ciclo actual u otras propiedades

Realizar cálculos y manipulación de datos

Para evitar el mantenimiento de módulos de código para tareas más simples, puede usar el lenguaje de expresión en TestStand para realizar cálculos básicos y manipular la matriz unidimensional. Deben implementarse requisitos de programación más avanzados en los módulos de código, ya que los lenguajes de programación proporcionan una funcionalidad más robusta que se adapta mejor a estas tareas.  Por ejemplo, concatenar matrices multidimensionales es mucho más fácil de lograr con la función Build Array nativa de LabVIEW que a través del lenguaje de expresión.

En algunos casos, puede usar las clases nativas proporcionadas con .NET Framework para evitar crear expresiones demasiado complejas.  Por ejemplo, puede usar la clase System.IO.Path para realizar rápidamente la manipulación de rutas sin crear un módulo de código.

Puede usar un paso .NET para utilizar métodos de .NET Framework sin la necesidad de un módulo de código

Al implementar módulos de código, hay una serie de decisiones de diseño que afectarán a muchos de los módulos de código que cree.  Esta sección proporciona pautas para los siguientes conceptos:

• Comunicación de datos desde TestStand a módulos de código
• Manejo de la terminación de secuencia dentro de los módulos de código
• Informe de errores del módulo de código a TestStand.
• Administración de la velocidad de ejecución del módulo de código y el uso de memoria.

Comunicación de datos desde TestStand a módulos de código

Hay dos enfoques que puede usar para acceder a los datos de TestStand dentro de un módulo de código:

• Pase los datos a través de los parámetros del módulo de código.
• Acceda a los datos directamente dentro del módulo de código con la API de TestStand.

En la mayoría de los casos, es mejor utilizar parámetros para pasar datos en lugar de usar la API de TestStand para acceder a ellos directamente por las siguientes razones:

• Hay una menor tendencia a errores: cualquier error en los nombres de propiedades o tipos de datos será fácil de encontrar, ya que los valores de los parámetros se definen en la configuración de tipo de paso en TestStand, no directamente en el módulo de código.
• Es más fácil de mantener: los cambios en las propiedades de los pasos se especifican en la configuración de parámetros en TestStand sin ninguna modificación en el módulo de código.
• Es más fácil de reutilizar fuera de TestStand - Ya que el módulo de código no depende de la API de TestStand, el módulo se puede usar fuera de TestStand sin modificación

Cuando sea posible, utilice parámetros para pasar los datos requeridos a los módulos de código

Sin embargo, usar la API para acceder directamente a las propiedades puede ser útil en los casos en que el módulo de código está accediendo a una variedad de datos de forma dinámica, en función del estado del paso.  El uso de parámetros de pasos en este caso puede llevar a una larga lista de parámetros donde solo algunos se usan realmente en diversas condiciones.

Si utiliza la API de TestStand en un módulo de código, pase una referencia al objeto SequenceContext (ThisContext) como parámetro. El objeto SequenceContext da acceso a todos los demás objetos de TestStand, incluido el motor TestStand y el Runstate actual. La referencia de contexto de la secuencia también es necesaria si se utiliza el monitor de terminación o los VIs de diálogo modal.

Use SequenceContext para acceder a la API de TestStand en módulos de código, que se pueden utilizar para acceder a datos mediante programación

Si vuelve a utilizar módulos de código fuera de TestStand, tenga en cuenta que cualquier operación que use la API de TestStand solo estará disponible si se llama al módulo desde una secuencia de TestStand. Los datos que obtenga el módulo de TestStand a través de la API no estarán disponibles.  Puede definir un mecanismo alternativo para obtener datos de prueba en los casos en que se llame al módulo de código fuera de TestStand comprobando primero si la referencia de contexto de secuencia es nula.  En LabVIEW, puede usar la función Not A Number/Path/Refnum?, que devuelve un valor booleano, como se muestra en la Figura 3.

Utilice

Utilice Not a Number/Path/Refnum? para verificar la validez de la referencia del objeto SequenceContext para los módulos de código utilizados fuera de TestStand

Manejo de grandes conjuntos de datos en módulos de código

En muchos casos, los módulos de código pueden producir grandes cantidades de datos complejos a partir de mediciones o análisis.  Evite almacenar este tipo de datos en las variables de TestStand, ya que TestStand crea una copia de los datos cuando los almacena.  Estas copias pueden reducir el rendimiento del tiempo de ejecución o causar errores de falta de memoria.  Use los enfoques siguientes para administrar grandes conjuntos de datos sin crear copias innecesarias:

• Opere en grandes conjuntos de datos dentro de los módulos de código, como el análisis de datos en el mismo módulo de código que se adquiere y devuelva solo los resultados requeridos a TestStand.
• Pase los punteros de datos entre TestStand y los módulos de código.  Para los módulos de código de LabVIEW, utilice Referencias de valor de datos (DVR).

Manejo de la terminación de secuencia dentro de los módulos de código

Cuando un usuario presiona el botón Terminar, TestStand detiene la secuencia de ejecución y ejecuta los pasos de limpieza. Sin embargo, si la ejecución ha llamado a un módulo de código, el módulo debe completar la ejecución y devolver el control a TestStand antes de que la secuencia pueda terminar. Si el tiempo de ejecución de un módulo de código es superior a unos pocos segundos o cuando el módulo espera a que se produzca una condición, como la entrada de usuario, al usuario puede parecerle que se ha ignorado el comando de finalización.

Para solucionar este problema, puede usar el monitor de terminación para permitir que los módulos de código verifiquen y respondan al estado de terminación de la ejecución de la llamada. Por ejemplo, el ejemplo de envío Prueba de la tarjeta madre del equipo utiliza el monitor de terminación en el cuadro de diálogo de simulación, como se muestra a continuación.  Si la secuencia de prueba finaliza, el VI de estado comprobar terminación devuelve falso y el ciclo se detiene.

Consulte los

Consulte los ejemplos del monitor de terminación para obtener más información sobre el uso del monitor de terminación.

Manejo de errores

Un error en un sistema de pruebas es un comportamiento en tiempo de ejecución inesperado que impide que las pruebas se lleven a cabo. Cuando un módulo de código genera un error, devuelva esa información a la secuencia de prueba para determinar qué acción se debe ejecutar a continuación, como terminar la ejecución, repetir la última prueba o advertir al operador de la prueba.

Para proporcionar a TestStand cualquier información de error de los módulos de código, use el contenedor Result.Error del paso, como se muestra a continuación.  TestStand verifica automáticamente esta propiedad después de cada paso para determinar si se ha producido un error.  No necesita pasar la información de error de TestStand al módulo de código. Si el módulo de código devuelve un error a TestStand, la ejecución puede desviarse a otra parte de la secuencia de prueba, como el grupo de pasos de limpieza.

Puede usar la configuración Error en tiempo de ejecución [On Run-Time Error], ubicada en la pestaña Ejecución [Execution] de las Opciones de estación [Station Options] para determinar cómo responde TestStand a los errores de los pasos.  Por lo general, debe usar la opción Mostrar cuadro de diálogo [Show Dialog Box] mientras desarrolla sus secuencias para ayudar en la depuración, ya que esta opción le permite interrumpir la ejecución y verificar el estado actual de la secuencia.  Para los sistemas implementados, puede usar las opciones Ejecutar limpieza [Run Cleanup] o Ignorar [Ignore], en lugar de requerir la entrada de operadores de prueba.  La información del error se registra automáticamente en los resultados de la prueba, que se pueden utilizar para encontrar la causa del error.
 

Pase la información del error al contenedor Step.Result.Error para notificar a TestStand si se produce un error de paso

Administración del rendimiento y del uso de memoria de los módulos de código

De forma predeterminada, TestStand carga todos los módulos de código en un archivo de secuencia en la memoria cuando ejecuta una secuencia en el archivo y los mantiene cargados hasta que cierra el archivo de secuencia.  Con estos ajustes, puede producirse un retraso inicial cuando comienza una secuencia mientras se cargan los módulos.  Sin embargo, las ejecuciones posteriores del archivo de secuencia son más rápidas ya que los módulos permanecen en la memoria.

Puede configurar el momento de carga y descarga de un módulo de código en la pestaña Opciones de ejecución [Run Options] del panel de configuración de pasos. Por lo general, las opciones de carga predeterminadas proporcionan el mejor rendimiento, pero existen casos donde puede ser mejor cargar el módulo de código solo cuando se usa con la opción de carga Load dynamically.  En el caso de los módulos de código que no se llaman en la ejecución típica, como los diagnósticos que solo se ejecutan después de que falla una prueba en particular, deben cargarse de forma dinámica, ya que en la mayoría de los casos no es necesario cargar estos módulos en absoluto.

Al cargar dinámicamente módulos de código, tenga en cuenta que TestStand no informa sobre problemas con los módulos de código hasta que carga el módulo de código, lo que podría producirse al final de una ejecución prolongada. Sin embargo, puede usar el analizador de secuencia para verificar que no haya errores en una secuencia antes de ejecutarla.  El analizador verificará los módulos de código cargados estática y dinámicamente.

En los módulos de código que requieren mucha memoria, puede modificar la opción de descarga predeterminada para reducir el uso total de memoria.  Por ejemplo, puede establecer el módulo en Descargar después de ejecutar el paso o Descargar después de ejecutar la secuencia.  Sin embargo, este cambio aumentará los tiempos de ejecución, ya que TestStand necesitará volver a cargar el módulo para cada llamada posterior. Cuando sea posible, una alternativa mejor es usar la versión de 64 bits de TestStand y un sistema con más memoria física para obtener el rendimiento de prueba más rápido a pesar de los altos requisitos de uso de memoria.

Si sus módulos de código mantienen datos compartidos, como variables estáticas o variables globales funcionales de LabVIEW, modificar las opciones de descarga puede causar cambios en el comportamiento, ya que los datos globales se pierden cuando se descargan los módulos. Al cambiar las opciones de descarga, asegúrese de que los datos requeridos se pasen a la secuencia de TestStand o se almacenen en una ubicación más permanente para evitar la pérdida de datos.

Consulte las Prácticas recomendadas para mejorar el rendimiento del sistema NI TestStand para obtener más información sobre otras formas de optimizar el rendimiento de un sistema de pruebas.

Un uso común de los módulos de código es interactuar con el hardware de prueba para configurar estímulos y tomar mediciones de prueba.  Los métodos de comunicación con el hardware incluyen:

• Usar un controlador de hardware, como NI-DAQmx, para comunicarse directamente con el hardware.
• Usar un controlador de instrumentos, que internamente envía comandos a un instrumento a través del controlador de hardware VISA o IVI.
El método de comunicación que se utiliza depende del tipo de hardware instalado.  Para cualquier tipo de comunicación, abrirá una referencia o sesión para el controlador antes de realizar llamadas específicas del controlador y cerrará la manija después de que se complete la interacción.

Elección de enfoque para gestionar referencias de hardware

En la mayoría de los casos, se comunicará con el mismo hardware en varios pasos de prueba. Para evitar el impacto en el rendimiento de abrir y cerrar la sesión de instrumentos en cada módulo de código, es importante estudiar cómo gestionará las referencias de hardware dentro de sus secuencias de prueba.  Existen dos enfoques comunes para administrar referencias de hardware:

• Administrar manualmente las referencias de hardware llamando a las funciones de inicializar y cerrar desde los módulos de código.
• Utilizar el administrador de sesiones para administrar automáticamente la vida útil de referencia del hardware.

Si está utilizando un controlador de instrumentos, o se está comunicando directamente con instrumentos utilizando los controladores VISA o IVI, use el administrador de sesiones a menos que tenga una necesidad específica de control directo sobre las vidas útiles de las sesiones de hardware.  Si está utilizando un controlador de hardware como DAQmx, no puede usar el administrador de sesiones y debe administrar las referencias manualmente.

Administrar manualmente referencias de hardware utilizando variables de TestStand

Cuando inicialice el instrumento, pase la referencia de sesión como un parámetro de salida a la secuencia de llamada, luego almacene la referencia en una variable.  A continuación, puede pasar la variable como entrada para cada paso que requiere acceso al instrumento.

Muchos controladores, incluidos NI-DAQmx, VISA y la mayoría de los controladores de instrumentos, utilizan el tipo de datos de referencia de E/S para almacenar referencias de sesión. Utilice el tipo de datos LabviewIOControl en TestStand para almacenar estas referencias.  

Utilice una variable con el tipo LabVIEWIOControl para pasar referencias de hardware, como una referencia de tarea DAQ, entre módulos de código

Cuando pase explícitamente las manijas de instrumentos entre TestStand y los módulos de código, almacene la referencia de hardware en una variable local.  Si el hardware se usa en varias secuencias, pase la manija como un parámetro de secuencia a cada una de las secuencias que lo requiera.  Evite usar variables globales para almacenar referencias de hardware, ya que puede ser difícil garantizar que el instrumento se haya inicializado antes de usar la referencia.

Use el grupo de pasos de configuración para iniciar el hardware y el grupo de pasos de limpieza para cerrar las referencias de hardware por estos motivos:

• Las referencias de hardware seguirán cerradas si el usuario finaliza la ejecución de la secuencia, ya que el grupo de pasos de limpieza siempre se ejecuta cuando finaliza una ejecución.
• Le permite ejecutar interactivamente pasos que utilizan la referencia de hardware, ya que los grupos de pasos de configuración y limpieza se ejecutarán antes y después de los pasos seleccionados.

Use los grupos de configuración y limpieza para iniciar y cerrar referencias de hardware

Gestión automática de las referencias de hardware mediante el administrador de sesiones

Para las manijas de instrumentos VISA e IVI, puede usar el administrador de sesiones para gestionar automáticamente las referencias de hardware. El administrador de sesiones ofrece muchas ventajas; por ejemplo:

• Acoplamiento reducido: no es necesario pasar las variables de la manija de instrumentos entre los componentes del software. En su lugar, cada componente especifica un nombre de instrumento lógico para obtener una sesión.
• Se reducen las barreras de lenguaje de programación: los módulos de código escritos en diferentes lenguajes pueden compartir la misma sesión sin pasar manijas que podrían no convertirse fácilmente entre idiomas.
• Control de vida útil: debido a que las sesiones de instrumentos son objetos ActiveX con recuentos de referencias, puede vincular la vida útil de la sesión a la vida útil de una variable de referencia ActiveX y eliminar la necesidad de cerrar explícitamente el instrumento en lenguajes que admitan variables de referencia ActiveX.

El administrador de sesiones inicia automáticamente la manija después de crear la sesión y cierra la manija automáticamente cuando se libera la última referencia a la sesión. Los módulos de código y las secuencias pasan un nombre lógico, como “DMM1”, para obtener un objeto de sesión del administrador de sesiones, que contiene la manija del instrumento correspondiente.

Cuando utilice el administrador de sesiones, almacene el objeto de sesión en una variable de referencia de objeto de TestStand.  Dado que la vida útil de la sesión está vinculada a la vida útil de la variable de referencia del objeto, la manija del instrumento se inicializará y se cerrará una vez por ejecución, sin importar cuántos módulos de código de secuencia y subsecuencias accedan a la misma sesión.

En el ejemplo siguiente, el paso Obtener sesión DMM [Get DMM Session] obtiene una referencia al objeto de sesión del instrumento para el DMM para el nombre lógico. El paso almacena la referencia de sesión en una variable local para que la sesión permanezca inicializada durante la ejecución de la secuencia.

Utilice el administrador de sesiones para poder hacer referencia a instrumentos mediante un nombre lógico.  El VI de administrador de sesiones obtiene la referencia de E/S de DMM usando el nombre lógico

Consulte la Ayuda del administrador de sesiones de NI [NI Session Manager Help], ubicada en <Program Files>\National Instruments\Shared\Session Manager, para obtener más información sobre cómo utilizar el administrador de sesiones.

La secuencia de ejemplo anterior obtiene la sesión de un módulo de código de LabVIEW que llama al administrador de sesiones en lugar de llamar al administrador de sesiones directamente porque este ejemplo ha configurado el adaptador de LabVIEW para ejecutar los VI en un proceso separado.  Consulte la Ayuda del administrador de sesiones de NI [NI Session Manager Help], ubicada en <Program Files>\National Instruments\Shared\Session Manager, para obtener más información sobre cómo utilizar el administrador de sesiones.

Llamada a las bibliotecas de controlador de hardware

Para comunicarse con cualquier tipo de hardware, utilice bibliotecas de controladores, que proporcionan un conjunto de funcionalidades diseñadas para permitirle realizar un conjunto de tareas mediante lenguaje de programación.  Al utilizar bibliotecas de controladores, a menudo llama a varios VI o funciones para realizar una sola operación lógica, como tomar una medida o configurar un disparo.  Crear un módulo de código para implementar esta funcionalidad, en lugar de llamar a las funciones de la biblioteca directamente desde un paso de TestStand, tiene algunas ventajas; por ejemplo:

• Evita la sobrecarga de la funcionalidad del paso alrededor de cada función.
• Proporciona una capa de abstracción entre las llamadas del controlador y las secuencias de TestStand.
• Facilita compartir la implementación entre los programas de prueba.

Haga clic para ver otros documentos dentro de la serie de arquitectura avanzada de TestStand que cubren temas de interés para los desarrolladores avanzados de NI TestStand.