Transmisión y supervisión de CANopen

Introducción

CANopen es una especificación de perfiles de dispositivos y un protocolo de comunicaciones abierto estándar del sector (EN 50325-4) que se basa en el protocolo Controller Area Network (CAN). El protocolo "Capa 7" se desarrolló para aplicaciones de red incorporadas y define la comunicación y las funciones del dispositivo para sistemas basados en CAN.

CANopen admite tanto la comunicación cíclica como controlada por eventos, lo que permite minimizar la carga de bus manteniendo a la vez tiempos de reacción reducidos.

Objeto de datos de proceso (PDO)

Los PDO son objetos que proporcionan datos de proceso a la interfaz de comunicación y que permite intercambiarlos en tiempo real. En el conjunto de PDO de un dispositivo CANopen se describen los intercambios implícitos entre dicho dispositivo y sus participantes en la comunicación a través de la red. El intercambio de PDO se autoriza cuando el dispositivo se encuentra en modalidad "OPERATIONAL".

Existen dos tipos de PDO:

oPDO de transmisión (TPDO): PDO que transmite el dispositivo

oPDO de recepción (RPDO): PDO que recibe el dispositivo

Modalidades de transmisión

El Acoplador de bus TM3 CANopen admite tres tipos de modalidad de transmisión de PDO:

Hay dos opciones adicionales relacionadas con los PDO activados por eventos:

oInhibit Time: La utilidad Inhibit Time permite definir un retardo mínimo previo a la transmisión de un nuevo PDO. De este modo, se evita sobrecargar el bus en el que se producen rápida y sucesivamente una cantidad significativa de eventos. El Inhibit Time se expresa en múltiplos de 100 μs.

Esta función está disponible para la transferencia de tipo 255 (asíncrona).

En la siguiente tabla se muestran valores de ejemplo:

oTiempo de evento: El Tiempo de evento permite definir un retardo del tiempo de caducidad en el que se forzará la transmisión de un PDO aunque no se produzca ningún cambio de estado. El Tiempo de evento se expresa en milisegundos.

Esta función está disponible para el tipo 255 (asíncrona).

En la siguiente tabla se muestran valores de ejemplo:

Objeto de datos de servicio (SDO)

Un SDO permite acceder a los datos de un dispositivo mediante peticiones explícitas. El servicio SDO está disponible cuando el dispositivo se encuentra en el estado "OPERATIONAL" O "PRE-OPERATIONAL".

Existen dos tipos de SDO:

oSDO de lectura (SDO de descarga)

oSDO de escritura (SDO de carga)

El protocolo SDO está basado en un modelo cliente/servidor. En el caso de un SDO de descarga, el cliente, por lo general el controlador, envía una solicitud en la que se indica el objeto que debe leerse. El servidor, en este caso el acoplador de bus, devuelve los datos incluidos en el objeto. En el caso de un SDO de carga, el cliente, por lo general el controlador, envía una solicitud en la que se indica el objeto en el que debe escribirse y el valor deseado. Una vez que se ha cargado el objeto, el servidor, en este caso el acoplador de bus, devuelve un mensaje de confirmación.

Si el servidor (acoplador de bus) no puede procesar un SDO, devolverá un código de error (Abort Code). Esto se aplica tanto a los SDO de descarga como a los de carga. Si el servidor no responde dentro de un período de tiempo preconfigurado (tiempo de espera de SDO), el cliente emitirá un "abort code" por tiempo de espera de SDO.

Protocolos de control de errores

Los protocolos de control de errores se utilizan para detectar errores de comunicación en la red. Existen dos protocolos distintos: nodeguarding y heartbeat. Ambos mecanismos de supervisión resultan de especial importancia en el sistema CANopen. Los dispositivos conectados al bus no indican periódicamente su presencia en la modalidad de funcionamiento, sobre todo cuando se controlan mediante Evento.

NOTA: Un dispositivo CANopen no puede admitir la supervisión utilizando ambos métodos (Nodeguarding y Heartbeat) a la vez. Si el dispositivo recibe ambas configuraciones, solo utilizará el método de supervisión Heartbeat.

Nodeguarding

Con este protocolo, el maestro NMT, por lo general el controlador, sondeará a cada esclavo NMT (por ejemplo, el acoplador de bus) a intervalos regulares, conocidos como Tiempo de supervisión. El esclavo responde con su estado NMT. Si el esclavo no recibe el sondeo transcurrido un período definido, denominado Vida útil, el esclavo pasará al estado configurado en el objeto 1029H y generará un evento de life guarding. En el caso del acoplador de bus, este pasará al estado configurado en el objeto 1029H (siempre que el objeto 1029H se haya dejado como predeter­minado), se activará la gestión de retorno y se generará un evento de nodeguarding. La Duración se define de la siguiente manera: Duración = Tiempo de supervisión x Lifetime Factor. El objeto 100CH contiene el parámetro de tiempo de supervisión expresado en milisegundos. El objeto 100DH contiene el parámetro Lifetime Factor. Tiempo de supervisión y Duración pueden configurarse de manera diferente para diferentes esclavos.

Cuando uno de los dos parámetros Lifetime Factor o Tiempo de supervisión se establece en 0 (configuración predeterminada), el esclavo no realiza la supervisión. Para activar la supervisión en el tiempo, debe introducir un valor (mínimo de 2) en el objeto 100DH y especificar un tiempo en milisegundos en el objeto 100CH.

Los valores típicos para el parámetro Tiempo de supervisión se sitúan entre los 200 ms y los 2 s.

A fin de mantener un funcionamiento más fiable y seguro, introduzca un Lifetime Factor (objeto 100DH) con un valor de 2 o superior. Si se utiliza un valor de 1 y se produce un retardo a causa del procesamiento de mensajes de alta prioridad o del procesamiento interno en el maestro nodeguarding, es posible que el esclavo pase involuntariamente al estado configurado en el objeto 1029H.

La supervisión se realiza de la siguiente manera:

NOTA: Aunque se deshabilite con el tiempo la función de supervisión (los registros de Tiempo de supervisión y Lifetime-Factor se establecen en 0), el esclavo responderá a una solicitud remota del maestro. En el caso del mensaje Nodeguarding, el valor inicial del Toggle-Bit enviado en el primer mensaje de Guarding es 0. A continuación, el Toggle-Bit cambia en cada mensaje posterior de Guarding, lo que permite indicar si se ha perdido un mensaje.

El estado de red del dispositivo se indica en los siete bits restantes:

Mecanismo Heartbeat

Con este protocolo, el productor transmite periódicamente un mensaje de Heartbeat, en función del parámetro Producer Heartbeat Time (en milisegundos) configurado en el objeto 1017H. Los dispositivos responsables de supervisar este mensaje tendrán un parámetro Consumer Heartbeat Time (en milisegundos), configurado en el objeto 1016H. Si el mensaje Heartbeat del productor no se recibe en el tiempo configurado de los dispositivos consumidores, los dispositivos generarán un evento de Heartbeat. En el caso del acoplador de bus, pasará al estado CANopen configurado en el objeto 1029H, se activará la gestión de retorno y se generará un evento de Heartbeat.

El mensaje de Heartbeat indica el estado del dispositivo en un byte, que estará formado por los siguientes bits:

oEl bit más significativo está reservado y siempre presenta un valor de 0.

oLos 7 bits menos significativos proporcionan el estado del dispositivo que genera el mensaje de Heartbeat.

Sus posibles valores son: