CANopen es un protocolo de comunicación y una especificación de perfil de dispositivo para sistemas integrados utilizados en automatización . En términos del modelo OSI , CANopen implementa las capas superiores e incluyendo la capa de red . El estándar CANopen consta de un esquema de direccionamiento, varios protocolos de comunicación pequeños y una capa de aplicación definida por un perfil de dispositivo. Los protocolos de comunicación tienen soporte para la gestión de redes, monitoreo de dispositivos y comunicación entre nodos, incluida una capa de transporte simple para segmentación/desegmentación de mensajes. El protocolo de nivel inferior que implementa el enlace de datos y las capas físicas suele ser la Red de área del controlador (CAN), aunque los dispositivos que utilizan algún otro medio de comunicación (como Ethernet Powerlink , EtherCAT ) también pueden implementar el perfil de dispositivo CANopen.
El dispositivo CANopen básico y los perfiles de comunicación se proporcionan en la especificación CiA 301 publicada por CAN en Automatización . [1] Los perfiles para dispositivos más especializados se construyen sobre este perfil básico y se especifican en muchos otros estándares publicados por CAN en automatización, como CiA 401 [2] para módulos de E/S y CiA 402 [3] para control de movimiento.
Cada dispositivo CANopen tiene que implementar ciertas características estándar en su software de control.
Los dispositivos CANopen deben tener un diccionario de objetos, que se utiliza para la configuración y comunicación con el dispositivo. Una entrada en el diccionario de objetos se define por:
Los tipos de datos básicos para los valores del diccionario de objetos, como booleanos , enteros y flotantes , se definen en el estándar (su tamaño en bits se almacena opcionalmente en la definición de tipo relacionada, rango de índice 0x0001–0x001F), así como tipos de datos compuestos como cadenas, matrices. y registros (definidos en el rango de índice 0x0040–0x025F). Los tipos de datos compuestos se pueden subindexar con un índice de 8 bits; el valor en el subíndice 0 de una matriz o registro indica el número de elementos en la estructura de datos y es de tipo UNSIGNED8.
Por ejemplo, los parámetros de comunicación del dispositivo estandarizados en el perfil básico del dispositivo CiA 301 [4] están mapeados en el rango de índice 0x1000–0x1FFF ("área de perfil de comunicación"). Las primeras entradas en esta área son las siguientes:
Con las herramientas adecuadas, el contenido del diccionario de objetos de un dispositivo, basado en una hoja de datos electrónica (EDS), se puede personalizar en un archivo de configuración del dispositivo (DCF) para integrar el dispositivo en una red CANopen específica. Según CiA 306 [5] , el formato del archivo EDS es el formato de archivo INI . Existe un próximo formato de estilo XML, que se describe en CiA 311 [6] .
El bus CAN , la capa de enlace de datos de CANopen, solo puede transmitir paquetes cortos que constan de una identificación de 11 bits, un bit de solicitud de transmisión remota (RTR) y de 0 a 8 bytes de datos. El estándar CANopen divide la identificación del marco CAN de 11 bits en un código de función de 4 bits y una identificación del nodo CANopen de 7 bits. Esto limita la cantidad de dispositivos en una red CANopen a 127 (0 está reservado para transmisión). Una extensión del estándar de bus CAN (CAN 2.0 B) permite identificaciones de trama extendidas de 29 bits, pero en la práctica rara vez se ven redes CANopen lo suficientemente grandes como para necesitar el rango de identificación extendido.
En CANopen, la identificación de 11 bits de una trama CAN se conoce como identificador de objeto de comunicación o COB-ID. En caso de una colisión de transmisión, el arbitraje de bus utilizado en el bus CAN permite que la trama con la identificación más pequeña se transmita primero y sin demora. El uso de un número de código bajo para funciones críticas en el tiempo garantiza el menor retraso posible.
Contenido de un marco CANopen:
El marco de datos con un identificador de 11 bits también se denomina "formato de marco base".
La asignación CAN-ID predeterminada clasifica las tramas atribuyendo un código de función (NMT, SYNC, EMCY, PDO, SDO...) a los primeros 4 bits, de modo que se da prioridad a las funciones críticas. Sin embargo, este mapeo se puede personalizar para fines especiales (excepto NMT y SDO, necesarios para la comunicación básica).
El estándar reserva ciertos CAN-ID para la gestión de red y transferencias SDO. Algunos códigos de función y CAN-ID deben asignarse a la funcionalidad estándar después de la inicialización del dispositivo, pero se pueden configurar para otros usos más adelante.
Para estructuras de red simples, CANopen admite una asignación predefinida de identificadores de mensajes.
Las direcciones de transmisión y recepción son desde el punto de vista del dispositivo. Entonces, una consulta a un dispositivo en la red enviaría un 0x600+nodeid y obtendría un 0x580+nodeid. [1]
Se utilizan diferentes tipos de modelos de comunicación en la mensajería entre nodos CANopen.
En una relación maestro/esclavo , se designa un nodo CANopen como maestro, que envía o solicita datos de los esclavos. El protocolo NMT es un ejemplo de modelo de comunicación maestro/esclavo.
Una relación cliente/servidor se implementa en el protocolo SDO, donde el cliente SDO envía datos (el índice y subíndice del diccionario de objetos) a un servidor SDO, que responde con uno o más paquetes SDO que contienen los datos solicitados (el contenido del diccionario de objetos). en el índice dado).
Se utiliza un modelo de productor/consumidor en los protocolos Heartbeat y Node Guarding. En el modelo push de productor/consumidor, el productor envía datos al consumidor sin una solicitud específica, mientras que en el modelo pull , el consumidor tiene que solicitar los datos al productor.
Los protocolos NMT se utilizan para emitir comandos de cambio de estado de la máquina (por ejemplo, para iniciar y detener los dispositivos), detectar arranques de dispositivos remotos y condiciones de error.
El maestro NMT utiliza el protocolo de control del módulo para cambiar el estado de los dispositivos. El COB-ID del marco CAN de este protocolo es siempre 0, lo que significa que tiene un código de función 0 y un ID de nodo 0, lo que significa que cada nodo de la red procesará este mensaje. El ID de nodo real al que está destinado el comando se proporciona en la parte de datos del mensaje (en el segundo byte). También puede ser 0, lo que significa que todos los dispositivos del bus deben pasar al estado indicado.
El protocolo Heartbeat se utiliza para monitorear los nodos de la red y verificar que estén activos. Un productor de latidos (generalmente un dispositivo esclavo) envía periódicamente un mensaje con el código de función binaria 1110 y su ID de nodo (COB-ID19 = 0x700 + ID de nodo). La parte de datos de la trama contiene un byte que indica el estado del nodo. El consumidor de latidos lee estos mensajes. Si los mensajes no llegan dentro de un límite de tiempo determinado (definido en el diccionario de objetos de los dispositivos), el consumidor puede tomar medidas para, por ejemplo, restablecer el dispositivo o indicar un error. El formato del marco es:
Se requieren dispositivos CANopen para realizar la transición del estado Inicializando al Preoperativo automáticamente durante el arranque. Cuando se realiza esta transición, se envía un único mensaje de latido al bus. Este es el protocolo de inicio .
Existe un protocolo de estilo de respuesta (modelo pull), llamado protección de nodos, para el monitoreo de esclavos.
El protocolo SDO se utiliza para configurar y leer valores del diccionario de objetos de un dispositivo remoto. El dispositivo a cuyo diccionario de objetos se accede es el servidor SDO y el dispositivo que accede al dispositivo remoto es el cliente SDO. La comunicación siempre la inicia el cliente SDO. En la terminología CANopen, la comunicación se ve desde el servidor SDO, de modo que una lectura de un diccionario de objetos da como resultado una carga de SDO y una escritura en una entrada del diccionario es una descarga de SDO.
Debido a que los valores del diccionario de objetos pueden ser mayores que el límite de ocho bytes de una trama CAN, el protocolo SDO implementa la segmentación y desegmentación de mensajes más largos. En realidad, existen dos de estos protocolos: descarga/carga de SDO y descarga/carga de bloque SDO. La transferencia en bloque SDO es una incorporación más reciente al estándar, que permite transferir grandes cantidades de datos con una sobrecarga de protocolo ligeramente menor.
Los COB-ID de los respectivos mensajes de transferencia SDO de cliente a servidor y de servidor a cliente se pueden configurar en el diccionario de objetos. Se pueden configurar hasta 128 servidores SDO en el diccionario de objetos en las direcciones 0x1200 - 0x127F. De manera similar, las conexiones del cliente SDO del dispositivo se pueden configurar con variables en 0x1280 - 0x12FF. Sin embargo, el conjunto de conexiones predefinido define un canal SDO que se puede usar incluso justo después del inicio (en el estado preoperacional) para configurar el dispositivo. Los COB-ID de este canal son 0x600 + ID de nodo para recibir y 0x580 + ID de nodo para transmitir.
Para iniciar una descarga, el cliente SDO envía los siguientes datos en un mensaje CAN con el COB-ID de "recepción" del canal SDO.
El protocolo Process Data Object se utiliza para procesar datos en tiempo real entre varios nodos. Puede transferir hasta 8 bytes (64 bits) de datos por un PDO desde o hacia el dispositivo. Un PDO puede contener varias entradas del diccionario de objetos y los objetos dentro de un PDO se pueden configurar utilizando las entradas del diccionario de objetos de parámetros y mapeo.
Hay dos tipos de PDO: transmitir y recibir PDO (TPDO y RPDO). El primero es para datos provenientes del dispositivo (el dispositivo es un productor de datos) y el segundo es para datos que van al dispositivo (el dispositivo es un consumidor de datos); es decir, con RPDO puedes enviar datos al dispositivo y con TPDO puedes leer datos del dispositivo. En el conjunto de conexiones predefinido hay identificadores disponibles para cuatro TPDO y cuatro RPDO. Con la configuración son posibles 512 PDO.
Los PDO se pueden enviar de forma sincrónica o asincrónica. Los PDO sincrónicos se envían después del mensaje SYNC, mientras que los mensajes asincrónicos se envían después de un disparador interno o externo. Por ejemplo, puede realizar una solicitud a un dispositivo para transmitir TPDO que contiene los datos que necesita enviando un TPDO vacío con el indicador RTR (si el dispositivo está configurado para aceptar solicitudes de TPDO).
Con los RPDO puedes, por ejemplo, poner en marcha dos dispositivos simultáneamente. Solo necesita asignar el mismo RPDO a dos o más dispositivos diferentes y asegurarse de que esos RPDO estén asignados con el mismo COB-ID.
El Sync-Producer proporciona la señal de sincronización para el Sync-Consumer. Cuando el Sync-Consumer recibe la señal, comienza a realizar sus tareas sincrónicas.
En general, la fijación del tiempo de transmisión de mensajes PDO síncronos junto con la periodicidad de transmisión del Objeto de sincronización garantiza que los dispositivos sensores puedan prepararse para muestrear variables de proceso y que los dispositivos actuadores puedan aplicar su actuación de manera coordinada.
El identificador del objeto de sincronización está disponible en el índice 1005h.
Por lo general, el objeto Time-Stamp representa una hora como un campo de 6 bytes: un recuento de milisegundos después de la medianoche (como máximo 27 bits, almacenados en un campo de 32 bits) y un número de días sin firmar de 16 bits desde el 1 de enero. 1984. (Esto se desbordará el 7 de junio de 2163.)
Algunas aplicaciones en las que el tiempo es crítico, especialmente en redes grandes con velocidades de transmisión reducidas, requieren una sincronización muy precisa; puede ser necesario sincronizar los relojes locales con una precisión del orden de microsegundos. Esto se logra mediante el uso del protocolo de sincronización de alta resolución opcional que emplea una forma especial de mensaje de marca de tiempo para ajustar la inevitable deriva de los relojes locales.
La marca de tiempo de alta resolución está codificada como unsigned32 con una resolución de 1 microsegundo, lo que significa que el contador de tiempo se reinicia cada 72 minutos. Se configura asignando la marca de tiempo de alta resolución (objeto 1013h) a un PDO.
Los mensajes de emergencia se activan cuando se produce una situación de error fatal interno del dispositivo y se transmiten desde el dispositivo de la aplicación en cuestión a los demás dispositivos con alta prioridad. Esto los hace adecuados para alertas de error de tipo interrupción. Un telegrama de emergencia sólo puede enviarse una vez por "evento de error", es decir, los mensajes de emergencia no deben repetirse. Mientras no se produzcan nuevos errores en un dispositivo, no se deben enviar más mensajes de emergencia. Mediante códigos de error de emergencia definidos por el perfil de comunicación CANopen, el registro de errores y la información adicional específica del dispositivo se especifican en los perfiles del dispositivo.
Seguimiento de muestra de comunicaciones entre un maestro y dos transductores de presión esclavos configurados para ID 1 y ID de nodo 2.
La hoja de datos electrónica (EDS) es un formato de archivo, definido en CiA306, que describe el comportamiento de comunicación y las entradas del diccionario de objetos de un dispositivo. Esto permite que herramientas como herramientas de servicio, herramientas de configuración, herramientas de desarrollo y otras manejen los dispositivos correctamente.
Esos archivos EDS son obligatorios para pasar la prueba de conformidad CiA CANopen.
Desde finales de 2007 se define en CiA311 un nuevo formato basado en XML llamado XDD. XDD cumple con la norma ISO 15745.