Protocolo de capa de aplicación CAN: CANopen

Sinopsis CANopen

CANopen es otro protocolo de capa de aplicación CAN como DeviceNet y J1939. Al igual que esas otras capas de aplicación, CANopen es un protocolo de capa de aplicación industrial de bajo nivel para aplicaciones de automatización. CANopen conecta dispositivos de automatización entre sí mediante mensajes entre pares. Basado en el estándar de comunicaciones físicas CAN (Controller Area Network), CANopen utiliza el hardware de CAN para definir un protocolo de capa de aplicación que estructura la tarea de configuración, acceso y mensajería entre varios tipos de dispositivos de automatización. La estructura de datos de CANopen también es la base del nuevo protocolo de alta velocidad EtherCAT.

Estructura de datos

CANopen es un protocolo de comunicaciones basado en objetos, un diccionario de objetos describe la funcionalidad completa de un dispositivo, el diccionario de objetos es el punto de conexión entre la interfaz de comunicación y el programa de aplicación, todos los objetos de comunicación se describen en el diccionario de objetos de forma estandarizada, se puede acceder a estos objetos mediante un índice de 16 bits y, en el caso de algunos objetos en un subíndice adicional de 8 bits.

El diccionario de objetos CANopen proporciona objetos de comunicación estandarizados para datos en tiempo real (PDO – Objetos de datos de proceso), datos de configuración (SDO – Objetos de datos de servicio) y funciones especiales (sello de tiempo, mensaje de sincronización y mensaje de emergencia), así como gestión de red datos (mensaje de inicio, mensaje NMT y mensaje de control de errores).

Hay mensajes explícitos e implícitos que están incrustados en la capa de aplicación CAN que permiten el acceso al diccionario de objetos, los mensajes explícitos permiten que un dispositivo solicite el valor de datos de un elemento específico en el diccionario de objetos o establezca el valor de un elemento en el diccionario de objetos, los mensajes implícitos permiten transferencias de datos predefinidas de un dispositivo a otro sin sobrecarga.

Los dispositivos CANopen no son dispositivos estrictamente iguales ni dispositivos estrictamente maestros esclavos, es posible que un dispositivo CANopen sea un Maestro para otro dispositivo CANopen y le ordene que tome alguna acción, al mismo tiempo, puede ser un dispositivo esclavo para otro dispositivo CANopen que desea ordenarle que tome alguna acción, y al mismo tiempo, puede intercambiar datos de pares con otro dispositivo CANopen.

Todo esto es posible gracias al diccionario de objetos, la estructura organizativa de todas las comunicaciones y todos los datos expuestos a la red dentro de un dispositivo CANopen, si se permite el acceso, un dispositivo en una red CANopen puede configurar otro dispositivo CANopen para realizar comunicaciones entre pares o aceptar mensajes acíclicos, normalmente, este tipo de acceso general no está disponible para nodos aleatorios en la red, en cambio, la comunicación está preconfigurada y se proporciona a los dispositivos que actúan como CANopen Master.

El diccionario de objetos CANopen es el núcleo de un dispositivo CANopen, el Diccionario de objetos CANopen contiene los tipos de datos admitidos, objetos de comunicación, objetos específicos del proveedor y el dispositivo y objetos específicos de cualquier perfil compatible.

En el siguiente seminario hablamos de manera muy superficial sobre CANopen pero profundizamos más en otros protocolos:

Mensajes y tipos de datos

La especificación requiere que los objetos requeridos se incluyan en cada dispositivo CIP, estos objetos incluyen el objeto de identidad, un objeto de enrutador de mensajes y un objeto de red.

PDO

Las transferencias de datos de PDO son transferencias de datos de alta prioridad y no confirmadas que mueven las E/S y la información de estado de alta prioridad de un dispositivo a otro, las PDO son el mecanismo más común para que dos dispositivos intercambien datos. Las PDO se inician internamente por el dispositivo o desde algún tipo de mensaje externo.

Para simplificar la configuración de dispositivos y evitar el problema de configurar todos los PDO en ambos dispositivos CANopen, la especificación CANopen define un conjunto de conexiones predefinidas. Esto es simplemente un conjunto de PDO bien entendidos y preconfigurados, al utilizar el conjunto de conexión predefinido, no necesita pasar por el problema de configurar los PDO en ambos lados, asegurarse de que coincidan y probar las comunicaciones, tiene un conjunto de PDO que ya tienen COB-ID preconfigurados que puede usar. El conjunto de conexiones predefinidas incluye cuatro PDO de transmisión, cuatro PDO de recepción, 1 SDO, 1 objeto de emergencia y 1 identificador de control de error de nodo.

Objetos de datos de servicio

Los objetos de datos de servicio admiten la transferencia de comandos y datos asíncronos entre dos dispositivos CANopen. Los SDO (Service Data Objects) existen principalmente para la configuración, aunque parece que a algunos proveedores les gusta usarlos para la transferencia de datos. El destino del mensaje SDO, el Diccionario de objetos sobre el que se actúa, es el Servidor para el SDO. El iniciador es el cliente del SDO.

Los SDO tienen dos propósitos; para leer una entrada del Directorio de objetos en otro dispositivo CANopen o para escribir una entrada del Diccionario de objetos en otro dispositivo CANopen. Cada SDO contiene un complemento completo de 8 bytes de datos, aunque a veces los bytes de datos no se utilizan, a diferencia de los PDO, las transferencias SDO siempre son confirmadas por el receptor,además, a diferencia de los PDO, los SDO pueden transferir muchos más datos y tener varios tipos.

Para simplificar la configuración de los dispositivos y evitar de nuevo el problema de configurar todos los SDO en ambos dispositivos CANopen, la especificación CANopen define un conjunto de conexiones predefinidas, el conjunto de conexiones predefinidas contiene un solo SDO en cada dirección.

Al igual que con la conexión predefinida establecida para PDO, las ID de conexión de los SDO se configuran con la dirección de nodo del dispositivo CANopen para que un dispositivo tipo Maser pueda enviar fácilmente SDO al dispositivo y obtener los mensajes de respuesta de SDO.

CANopen también admite varios tipos de mensajes:

Mensajes de sincronización

Un conjunto de mensajes emitidos por un dispositivo de tipo Maestro que sirve para sincronizar las acciones de un grupo de dispositivos CANopen. CANopen reserva una ID de conexión en el grupo de mayor prioridad (ID CAN más baja) para garantizar que el mensaje de SINCRONIZACIÓN se transmita de manera confiable a través de la red.

Mensajes NMT

Un conjunto de mensajes que utiliza un maestro con un conjunto de dispositivos esclavos CANopen que implementan el conjunto de conexiones predefinidas. El protocolo NMT (gestión de red) se implementa utilizando una sola trama CAN y se le asigna la ID de CAN de mayor prioridad (0). El comando NMT consiste en un byte de comando que indica la acción a realizar y una ID de nodo. Se utiliza un ID de nodo de cero para indicar que todos los dispositivos en la red deben ejecutar el comando dado.

Mensajes de emergencia

El conjunto de mensajes utilizados por un dispositivo CANopen para transmitir alguna condición de error interno. El Protocolo de emergencia transmite el objeto de datos de emergencia una vez por cada error interno del dispositivo. No se transmiten mensajes adicionales a menos que se genere una condición de error interno del dispositivo diferente. Normalmente, el dispositivo maestro CANopen es el único dispositivo que consumirá el mensaje del Protocolo de emergencia.

Mensajes de HEARTBEAT

Una única trama CAN que transmite periódicamente el estado actual de NMT del dispositivo.

CiA (CAN In Automation) proporciona un laboratorio de prueba de certificación y una herramienta de prueba. El laboratorio de certificación prueba los dispositivos y los certifica compatibles con la especificación CANopen. La herramienta de prueba evalúa si un dispositivo se comporta correctamente en una red CANopen. La herramienta de prueba está disponible para su compra en CiA.

Contáctanos

ventas@logicbus.com | soporte@logicbus.com | 55-5431-67-18 | Iniciar conversación