El manejo de errores es una parte esencial de una aplicación profesional de LabVIEW, sin embargo, es algo que a menudo se pasa por alto. Al comenzar con LabVIEW, una de las primeras cosas que se nos enseña es la importancia del manejo de errores. En estos primeros días, el consejo general es que siempre debemos encerrar el código del diagrama de bloques en un caso de error y que siempre debemos cablear los errores entre nuestros subVIs.
A menudo, cuando ocurre un error, en lugar de pasarlo río abajo, se puede tratar en ese mismo momento. La forma en que maneje el error depende del error específico y de los requisitos del software.
- A veces es posible simplemente ignorar un error ascendente. Un ejemplo común podría ser un error de tiempo de espera de comunicaciones al leer desde una conexión TCP.
- Algunos errores pueden proporcionar información que puede usarse río abajo, incluso si no los considera errores. En este caso, podría optar por degradar un error a una advertencia. En este caso, el clúster de error retiene la información útil, sin embargo, no impide que el código descendente se ejecute.
- A veces, solo le interesará un error si ocurre varias veces. Un ejemplo podría ser al intentar inicializar un dispositivo DAQ cuando el dispositivo no ha sido conectado.
- Es posible que no siempre desee manejar los errores localmente y, por lo tanto, podría ser necesario pasar la información de error a otro módulo para que sea manejada.
Errores Comunes al Llamar DLLs en LabVIEW
Solución al Código de Error 21: Problemas con DLLs Secundarias
Problema: ¿Por qué recibo el código de error 21 cuando trato de ejecutar una aplicación que construí con LabVIEW? Estoy llamando una DLL en mi VI a través del nodo Call Library Function. Este DLL primario llama otras DLLs secundarias.
Solución: Este error puede ocurrir algunas veces cuando se llama una DLL desde LabVIEW que llama otras DLLs secundarias. El ejecutable puede llamar a la DLL primaria porque se encuentran dentro del mismo directorio, sin embargo el DLL primario probablemente no tenga información sobre que las DLLs secundarias se encuentran en el mismo directorio.
Para corregir este problema coloque las DLLs secundarias en el directorio windows\system si está trabajando en Windows 9x/Me/XP o el directorio winnt\system32 si está trabajando en Windows 2000/NT. También puede especificar la ruta a los DLLs con el comando set path en el archivo autoexec.bat agregándolo a la lista dentro de la variable ambiental de rutas en Windows NT.
Lea también: IVA 21% Excel
Prevención de Fallos Generales al Llamar Funciones DLL
Hay varias razones diferentes por las que LabVIEW podría fallar al llamar a una función de DLL. Para prevenir este tipo de fallas, considere los siguientes puntos:
- Asegúrese de que está utilizando las mismas convenciones de llamada que la DLL
Si la especificación de convención de llamada en el nodo de función de biblioteca de llamadas no coincide con la convención de llamada de la DLL, se producirá un bloqueo.
Cuando se utiliza la convención de llamada C (del inglés C calling convention), el llamante es responsable de limpiar la pila (del inglés stack). Cuando se utiliza la convención de llamada estándar, la función llamada es responsable de limpiar la pila. Si la persona que llama (LabVIEW) y la función DLL llamada no usan la misma convención de llamada, ambos quitarán las cosas de la pila o ninguno de ellos lo hará. Cualquiera de estas situaciones puede hacer que LabVIEW se bloquee cuando la función llamada regresa.
- Asegúrese de conectar todas las entradas y salidas de su Call Library Function Node
Si no conecta todas las entradas y salidas de un nodo de función de biblioteca de llamadas, la función DLL sobrescribirá la memoria no asignada y causará que LabVIEW se bloquee.
Nota: Si su segunda entrada es un puntero a su primera entrada, entonces su primera entrada no requiere una salida. Si no conecta las entradas, la función DLL sobrescribirá la memoria no asignada.
Lea también: Guía IVA reducido
- Asegúrese de que la función DLL no esté sobrescribiendo la memoria de LabVIEW
Si no se asigna suficiente memoria o si la función DLL escribe más de lo que se asignó, el DLL sobrescribirá el espacio de memoria reservado de LabVIEW y causará que LabVIEW se bloquee. Asegúrese de que la memoria esté asignada correctamente antes de pasar y leer matrices, cadenas o formas de onda desde archivos DLL.
Si la memoria no está asignada correctamente, puede causar un bloqueo. Por ejemplo, considere la siguiente función: double *Waveform (double *waveform, uInt32 size); La forma correcta de asignar la memoria en este caso es inicializar la matriz con el número de elementos especificado por el parámetro de size, y no pasando una matriz vacía. Si pasa matrices o cadenas a la DLL, la función DLL no puede redimensionar dinámicamente la matriz.
- Asegúrese de que LabVIEW esté pasando parámetros a la función en el formato que la función espera
Llamar a la función DLL desde LabVIEW con tipos de datos de parámetros incorrectos (por valor, referencia, identificador, etc.) puede hacer que la función apunte involuntariamente a una ubicación de memoria incorrecta que provoque datos defectuosos, o incluso un bloqueo de LabVIEW o Windows.
- La función llamada en sí misma hace algo ilegal.
Si una función intenta realizar una operación ilegal, podría fallar LabVIEW.
Si LabVIEW falla hasta que se cierra, el problema más probable es que la función DLL que se está llamando ha dañado la memoria.
Lea también: ¿Cómo localizar tus XML del SAT?
Configuración del Nodo Call Library Function para DLLs Creadas en LabVIEW
Si construyó el DLL en LabVIEW y quiere mostrar el panel frontal del DLL VI, hay dos requisitos que debe seguir:
- El Call Library Function Node debe configurarse de modo que la llamada a DLL pueda ejecutarse en cualquier subproceso. Nota: Todas las llamadas a bibliotecas compartidas construidas en LabVIEW deben especificar Run in any thread. Si configura el Call Library Function Node utilizando bibliotecas compartidas creadas en LabVIEW y especifica Run in UI thread, LabVIEW podría bloquearse y requerir que reinicie.
- El VI que llama no debe ejecutarse en el hilo de la interfaz de usuario.
Nota: Es posible que, en modo de desarrollo, su VI aún se ejecute sin seguir estos pasos. Sin embargo, al crear una aplicación, asegúrese de configurar el VI que llama a Ejecutar en cualquier subproceso como se indica anteriormente.
Para obtener la documentación completa sobre cómo usar el código de LabVIEW con otros lenguajes de programación en LabVIEW 7.1 o anterior, consulte el Manual de Uso de Código Externo en LabVIEW. En LabVIEW 8.0 o posterior, consulte la sección Fundamentals>> en la tabla de contenido de la Ayuda de LabVIEW para obtener más información.
Niveles de Comprobación de Errores en el Nodo Call Library Function
El nodo Call Library Function ofrece diferentes niveles de comprobación de errores para optimizar el rendimiento y la robustez:
- Maximum: Permite el nivel máximo de comprobación de errores para el nodo de función de biblioteca de llamadas. Si habilita el nivel máximo de comprobación de errores, el Call Library Function Node devuelve un error si la Calling convention que selecciona en la pestaña Función no coincide con la convención de llamadas de la función a la que está llamando en la biblioteca compartida o DLL. El nivel máximo de comprobación de errores también devuelve una advertencia si la función a la que se llama en la biblioteca compartida o DLL escribe más allá del espacio asignado para la cadena o parámetro de matriz especificados. Nota: la selección del control Maximum en la pestaña Error Checking reduce la velocidad de ejecución y aumenta el uso de la memoria del Call Library Function Node.
- Default: Habilita el nivel predeterminado de comprobación de errores para el nodo de función de biblioteca de llamadas. El nivel predeterminado de verificación de errores permite que LabVIEW se recupere de las excepciones no controladas que se producen durante la ejecución de la biblioteca compartida llamada o DLL.
- Disabled: Desactiva la comprobación de errores para el nodo de función de la biblioteca de llamadas. La desactivación de la comprobación de errores para el nodo de función de la biblioteca de llamadas mejora la velocidad de ejecución del nodo de función de la biblioteca de llamadas. Sin embargo, ciertos errores pueden causar un cierre irregular de LabVIEW.
Manejo de Excepciones .NET (Error 1172)
Solución: Cualquier excepción lanzada cuando se llama a una propiedad o método de objeto .NET se convierte en el error 1172 de LabVIEW. Este error significa que LabVIEW recibió una excepción .NET de la API a la que llamó.
En LabVIEW 8.0 y versiones posteriores, se agregó más información a los mensajes de error al colocar la propiedad de Mensaje de Excepción .NET en la cadena de fuente de error en el grupo de errores. Desagrupe el elemento fuente para ver la información adicional sobre la excepción. En LabVIEW 7.x, la única información mostrada fue que ocurrió una excepción .NET. En LabVIEW 8.0 y versiones posteriores, solo recibirá la información adicional si utiliza el manejo manual de errores.
Para gestionar correctamente los ensamblados .NET y evitar el error 1172, considere lo siguiente:
- Asegúrese de que los ensamblados .NET que está utilizando estén guardados en el directorio raíz del VI de nivel superior.
- Agregue el ensamblado .NET como referencia en LabVIEW seleccionando Tools»Advanced»NET Assembly References.
- Los ensamblajes privados se deben colocar en el mismo directorio que la aplicación que realiza la llamada.
- Los conjuntos compartidos deben instalarse en el GAC. Esto incluye ensamblajes llamados desde una unidad de red. Para obtener información sobre la instalación en el GAC, consulte Enlace Externo: Instalación de un ensamblado en la caché global de ensamblados.
- Si crea una aplicación, asegúrese de incluir el ensamblaje en la compilación. LabVIEW Application Builder debería guardar automáticamente los conjuntos que no están registrados en el GAC en el subdirectorio de datos. Debe distribuir el directorio de datos con la aplicación construida.
- Al distribuir aplicaciones creadas, asegúrese de que el equipo de destino tenga instalado .NET Framework correspondiente al ensamblado .NET llamado.
- Use la Probe Tool para asegurarse de que la referencia del objeto .NET, originalmente creada por el .NET Constructor Node VI, sea válida.
- Si usa un .dll de un tercero, una excepción de .NET puede ser la causa del problema y LabVIEW simplemente está dando un mensaje de error genérico que dice que algo salió mal en ese .dll.
Gestión y Personalización de Errores
Creación de Códigos de Error Personalizados
El Error Code File Editor (Tools->Advanced->Edit Error Codes) proporciona una GUI simple para crear y editar archivos XML de errores personalizados. Estos archivos son útiles si el usuario requiere códigos de error personalizados para aplicar a varias aplicaciones, si los códigos son utilizados por varios ingenieros de software en un equipo, o si los códigos se van a distribuir con una aplicación. Después de crear el archivo XML de error personalizado, coloque el archivo en el directorio labview\user.lib\errors. Como se puede ver, se puede crear un comentario de archivo dentro del espacio de la etiqueta <nicomment>.
Ignorar o Borrar Errores Específicos
Para hacer que LabVIEW ignore un error específico, puede usar el General Error Handler VI o Clear Error VI.
Uso del General Error Handler VI
El General Error Handler VI se encuentra en la paleta Programming » Dialog & User Interface. Haga clic derecho en el terminal [exception action] y cree una constante. Ajuste esa constante para cancel error on match. Luego conecte el número de error que desea cancelar al terminal [exception code].
Uso del Clear Error VI (LabVIEW 2013 y Anteriores)
También puede escribir su propia lógica para eliminar un error utilizando Clear VI VI, que también se encuentra en la paleta Programming » Dialog & User Interface. Para hacer esto en LabVIEW 2013 y versiones anteriores, use la función Unbundle By Name para desagregar el código de error. Luego use una estructura de caso para realizar una acción basada en el código de error. El siguiente diagrama de bloques implementa este método para observar un error en particular, y luego borra ese error solamente.
Uso del Clear Error VI (LabVIEW 2014 y Posteriores)
En LabVIEW 2014 y posteriores, el Clear Error VI tiene una entrada para que se borre el código de error específico. Esto permite que un error se elimine sin tener que desagruparlo y enviar el código a una estructura de caso.