Diagnóstico CANopen
El capítulo describe las opciones de diagnóstico que ofrece el protocolo CANopen .
Estado CANopen
Una red CANopen consta de un maestro NMT (gestión de red) y esclavos NMT. En este caso, el maestro NMT controla todos los dispositivos y puede cambiar sus estados de comunicación. Un dispositivo CANopen se encuentra en uno de cuatro estados posibles:
Inicialización: Tras el encendido, el nodo pasa a este estado. En este momento, se inicializan la aplicación y la comunicación del dispositivo (velocidad de bits y dirección del nodo). Posteriormente, el nodo pasa automáticamente al estado "Preoperativo".
Preoperacional: La comunicación con el nodo es posible mediante SDO. Sin embargo, el nodo no puede comunicarse PDO .
Operational: El nodo CANopen está completamente operativo. Puede enviar y recibir datos de proceso de forma independiente.
Detenido: El nodo está completamente separado de la red. No es posible la comunicación SDO ni PDO . El nodo solo puede cambiar a otro estado de red mediante el comando de red correspondiente (por ejemplo, iniciar nodo).
Registro de errores
Según CiA 301, cada dispositivo CANopen tiene un registro de errores (objeto 16#1001). Este registro se puede leer mediante SDO y, en caso de error, proporciona información adicional sobre el mismo.
Solo se requiere el bit 0 (error genérico) en el registro de errores. Los demás bits son opcionales y no los configura cada esclavo. En cuanto un dispositivo detecta un error, se configura al menos el bit 0 de este objeto.
Poco | Descripción |
|---|---|
0 | Error genérico |
1 | Actual |
2 | Voltaje |
3 | Temperatura |
4 | Error de comunicación (estado de error de desbordamiento) |
5 | Perfil del dispositivo |
6 | Reservado (siempre 0) |
7 | Específico del fabricante |
Campo de emergencia y error predefinido (EMCY)
CANopen define el protocolo de emergencia opcional (EMCY) para indicar errores. Una emergencia es un mensaje CAN que se transmite según la conexión predefinida con el ID CAN 16#80 + ID de nodo.
El telegrama tiene la siguiente estructura:
La longitud de un mensaje de emergencia siempre es de 8 bytes. El código de error de emergencia (EEC) correspondiente se transmite en los dos primeros bytes. A continuación, se incluye el valor actual del registro de error 0x1011 (ER: registro de error) y 5 bytes específicos del fabricante (MEF: campo de error específico del fabricante).
La interpretación correspondiente de los códigos de error debe consultarse en el manual del fabricante. El protocolo de emergencia no es compatible con todos los esclavos y debe configurarse según corresponda mediante el administrador CANopen .
El historial de emergencias ocurridas (historial de errores) se puede leer desde el objeto 16#1003 mediante SDO. Aquí, el subíndice 0 contiene el número de errores almacenados y los subobjetos siguientes contienen el contenido de los datos de las emergencias transmitidas.
Para obtener más información, consulte: Campo de error predefinido y registro de error
Mecanismos de monitorización: latidos y Guarding de nodos
Se requiere la monitorización de un nodo CAN si no envía mensajes continuamente ( PDO (Process Data Objects) cíclicos). Para ello, se proporcionan los mecanismos de "latido" y "protección de nodos", que pueden utilizarse alternativamente.
Vigilancia de nodos: Con este protocolo, el maestro NMT envía mensajes (tramas remotas CAN) a los esclavos CANopen existentes. Los esclavos deben responder a estos mensajes en un plazo determinado. Si no hay respuesta, el maestro NMT lo registra. Dado que, en general, se deben evitar las tramas remotas CAN, es preferible la monitorización mediante latidos.
Latido: El protocolo de latido se lanzó con CANopen versión 4.0 y es el método de monitorización preferido. En este protocolo, cada nodo envía un mensaje de forma independiente en intervalos cíclicos. Este mensaje puede ser monitorizado por cualquier otro suscriptor de la red.