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 por encima e incluyendo la capa de red . El estándar CANopen consta de un esquema de direccionamiento, varios pequeños protocolos de comunicación y una capa de aplicación definida por un perfil de dispositivo. Los protocolos de comunicación tienen soporte para la administració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 yLas capas físicas suelen ser Controller Area Network (CAN), aunque los dispositivos que utilizan otros medios 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 dan en la especificación CiA 301 publicada por CAN in Automation . [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.
Modelo de dispositivo
Cada dispositivo CANopen tiene que implementar ciertas características estándar en su software de control.
- Una unidad de comunicación implementa los protocolos para la mensajería con los otros nodos de la red.
- El inicio y el restablecimiento del dispositivo se controlan mediante una máquina de estado . Debe contener los estados Inicialización, Preoperativo, Operativo y Detenido. Las transiciones entre estados se realizan emitiendo un objeto de comunicación de administración de red (NMT) al dispositivo.
- El diccionario de objetos es una matriz de variables con un índice de 16 bits. Además, cada variable puede tener un subíndice de 8 bits. Las variables se pueden utilizar para configurar el dispositivo y reflejar su entorno, es decir, contener datos de medición.
- La parte de aplicación del dispositivo realmente realiza la función deseada del dispositivo, después de que la máquina de estado se establece en el estado operativo. La aplicación se configura mediante variables en el diccionario de objetos y los datos se envían y reciben a través de la capa de comunicación.
Diccionario de objetos
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:
- Índice , la dirección de 16 bits del objeto en el diccionario.
- Nombre del objeto (tipo / tamaño de objeto), un tipo simbólico del objeto en la entrada, como una matriz, un registro o una variable simple
- Nombre , una cadena que describe la entrada.
- Tipo , da el tipo de datos de la variable (o el tipo de datos de todas las variables de una matriz)
- Atributo , que proporciona información sobre los derechos de acceso para esta entrada, esto puede ser de lectura / escritura, solo lectura o solo escritura
- El campo Obligatorio / Opcional (M / O) define si un dispositivo que cumple con la especificación del dispositivo debe implementar este objeto o no
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 pueden subindexarse 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 de dispositivo básico CiA 301 [4], se asignan en el rango de índice 0x1000–0x1FFF ("área de perfil de comunicación"). Las primeras entradas en esta área son las siguientes:
Índice | Nombre del objeto | Nombre | Tipo | Atributo | MES |
---|---|---|---|---|---|
0x1000 | VAR | tipo de dispositivo | SIN FIRMAR 32 | ro | METRO |
0x1001 | VAR | registro de errores | SIN FIRMAR 8 | ro | METRO |
... | |||||
0x1008 | VAR | nombre del dispositivo del fabricante | Vis-String | constante | O |
... |
Con las herramientas adecuadas, el contenido del diccionario de objetos de un dispositivo, basado en una hoja de datos electrónicos (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 formato de estilo XML próximo, que se describe en CiA 311 [6] .
Comunicación
Objetos de comunicación
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 el ID de trama CAN de 11 bits en un código de función de 4 bits y un ID de nodo CANopen de 7 bits. Esto limita el número 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 tramas extendidas de 29 bits, pero en la práctica, las redes CANopen lo suficientemente grandes como para necesitar el rango de identificación extendido rara vez se ven.
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 de tiempo crítico asegura el menor retraso posible.
Contenido de un marco CANopen:
CAN-ID | RTR | Longitud de datos | Datos | |
---|---|---|---|---|
Largo | 11 bits | 1 bit | 4 bits | 0-8 bytes |
La trama de datos con un identificador de 11 bits también se denomina "formato de trama base".
El mapeo CAN-ID predeterminado ordena las tramas atribuyendo un código de función (NMT, SYNC, EMCY, PDO, SDO ...) a los primeros 4 bits, de modo que se dé prioridad a las funciones críticas. Sin embargo, este mapeo se puede personalizar para fines especiales (excepto para NMT y SDO, necesarios para la comunicación básica).
Código de función | ID de nodo | |
---|---|---|
Largo | 4 bits | 7 bits |
El estándar reserva ciertos CAN-ID para la gestión de la red y las 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.
Conjunto de conexiones predefinidas [7]
Para estructuras de red simples, CANopen admite una asignación predefinida de identificadores de mensajes.
Objeto de comunicación | COB-ID (s) hexadecimal | Nodos esclavos | Especificación |
---|---|---|---|
Control de nodo NMT | 000 | Recibe solo | CiA 301 |
Comando global a prueba de fallos | 001 | ? | CiA 304 |
Sincronizar | 080 | Recibe solo | CiA 301 |
Emergencia | 080 + ID de nodo | Transmitir | CiA 301 |
TimeStamp | 100 | Recibe solo | CiA 301 |
DOP | 180 + ID de nodo 200 + ID de nodo 280 + ID de nodo 300 + ID de nodo 380 + ID de nodo 400 + ID de nodo 480 + ID de nodo 500 + ID de nodo | 1. Transmitir PDO 1. Recibir PDO 2. Transmitir PDO 2. Recibir PDO 3. Transmitir PDO 3. Recibir PDO 4. Transmitir PDO 4. Recibir PDO | CiA 301 |
SDO | 580 + ID de nodo 600 + ID de nodo | Transmitir Recibir | CiA 301 |
Monitoreo de nodo NMT (protección de nodo / latido) | 700 + ID de nodo | Transmitir | CiA 301 |
LSS | 7E4 7E5 | Transmitir Recibir | CiA 305 |
Modelos de comunicación
Se utilizan diferentes tipos de modelos de comunicación en la mensajería entre nodos CANopen.
En una relación maestro / esclavo , un nodo CANopen se designa como maestro, que envía o solicita datos a 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.
Protocolos
Protocolos de gestión de red (NMT)
Los protocolos NMT se utilizan para emitir comandos de cambio de máquina de estado (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 de la trama 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 todos los nodos de la red procesarán 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 ir al estado indicado.
COB-ID | Byte de datos 0 | Byte de datos 1 |
---|---|---|
0x000 | Estado solicitado | Nodo direccionado |
Código de comando NMT | Significado |
---|---|
0x01 | Ir a 'operativo' |
0x02 | Ir a 'detenido' |
0x80 | Ir a 'preoperativo' |
0x81 | Ir a 'restablecer nodo' |
0x82 | Vaya a 'restablecer comunicación' |
El protocolo Heartbeat se usa para monitorear los nodos en 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 cierto límite de tiempo (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:
COB-ID | Byte de datos 0 |
---|---|
0x700 + ID de nodo | Expresar |
Código de estado NMT | Estado representado |
---|---|
0x00 | Arrancar (inicializar) |
0x04 | Detenido |
0x05 | Operacional |
0x7f | Preoperacional |
Los dispositivos CANopen son necesarios para realizar la transición del estado Inicializando a 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 respuesta / estilo de respuesta (modelo de extracción), llamado protección de nodo, para la supervisión de esclavos.
Protocolo de objeto de datos de servicio (SDO)
El protocolo SDO se utiliza para configurar y leer valores del diccionario de objetos de un dispositivo remoto. El dispositivo al que se accede al diccionario de objetos 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 SDO y una escritura en una entrada de diccionario es una descarga 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 SDO y descarga / carga de bloques SDO. La transferencia en bloque SDO es una adición más reciente al estándar, que permite transferir grandes cantidades de datos con un poco menos de sobrecarga de protocolo.
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. Del mismo modo, las conexiones de 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 utilizar incluso justo después del arranque (en el estado preoperativo) 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 'recibir' del canal SDO.
Byte Nr: | Byte 0 | Byte 1-2 | Byte 3 | Byte 4-7 | ||||
---|---|---|---|---|---|---|---|---|
Largo: | 3 bits | 1 bit | 2 bits | 1 bit | 1 bit | 2 bytes | 1 byte | 4 bytes |
Significado: | ccs = 1 | reservado (= 0) | norte | mi | s | índice | subíndice | datos |
- ccs es el especificador de comando del cliente de la transferencia SDO, esto es 0 para la descarga del segmento SDO, 1 para iniciar la descarga, 2 para iniciar la carga, 3 para la carga del segmento SDO, 4 para abortar una transferencia SDO, 5 para la carga del bloque SDO y 6 para Descarga de bloques SDO
- n es el número de bytes en la parte de datos del mensaje que no contienen datos, solo es válido si eys están configurados
- e , si se establece, indica una transferencia acelerada, es decir, todos los datos intercambiados están contenidos dentro del mensaje. Si se borra este bit, el mensaje es una transferencia segmentada en la que los datos no caben en un mensaje y se utilizan varios mensajes.
- s , si se establece, indica que el tamaño de los datos se especifica en n (si se establece e) o en la parte de datos del mensaje
- índice es el índice del diccionario de objetos de los datos a los que se accede
- subíndice es el subíndice de la variable del diccionario de objetos
- data contiene los datos que se cargarán en el caso de una transferencia acelerada (e está configurado), o el tamaño de los datos que se cargarán (s está configurado, e no está configurado)
Protocolo de objeto de datos de proceso (PDO)
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 múltiples entradas de diccionario de objetos y los objetos dentro de un PDO se pueden configurar mediante las entradas del diccionario de objetos de mapeo y parámetros.
Hay dos tipos de PDO: transmitir y recibir PDO (TPDO y RPDO). El primero es para los datos que provienen del dispositivo (el dispositivo es un productor de datos) y el segundo es para los 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 desde el dispositivo. En el conjunto de conexiones predefinido hay identificadores para cuatro TPDO y cuatro RPDO disponibles. Con la configuración son posibles 512 PDO.
Los PDO se pueden enviar de forma sincrónica o asincrónica. Los PDO síncronos se envían después del mensaje SYNC, mientras que los mensajes asíncronos se envían después del disparo 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 la bandera RTR (si el dispositivo está configurado para aceptar solicitudes TPDO).
Con los RPDO puede, por ejemplo, iniciar dos dispositivos simultáneamente. Solo necesita mapear el mismo RPDO en dos o más dispositivos diferentes y asegurarse de que esos RPDO estén mapeados con el mismo COB-ID.
Protocolo de objeto de sincronización (SYNC)
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 los mensajes PDO síncronos junto con la periodicidad de la transmisión del Objeto Sync garantiza que los dispositivos sensores puedan disponer 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.
Protocolo de objeto de marca de tiempo (TIME)
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 de 16 bits sin firmar desde el 1 de enero. 1984. (Esto se desbordará el 7 de junio de 2163.)
Algunas aplicaciones críticas en el tiempo, 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 utilizando el 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 mapeando la marca de tiempo de alta resolución (objeto 1013h) en un PDO.
Protocolo de objeto de emergencia (EMCY)
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 aplicación en cuestión a los otros dispositivos con alta prioridad. Esto los hace adecuados para alertas de error de tipo de interrupción. Se puede enviar un telegrama de emergencia solo 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. Por medio de los 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.
Inicialización
Ejemplo de seguimiento de comunicaciones entre un maestro y dos transductores de presión esclavos configurados para ID 1 e ID de nodo 2.
CAN ID | LONGITUD DE DATOS | DATOS | Descripción |
---|---|---|---|
0x0 | 2 | 01 00 | El maestro pone todos los dispositivos del bus en modo operativo |
0x80 | 0 | El maestro envía un mensaje SYNC, que activa los dispositivos para enviar datos | |
0x181 | 4 | CD 82 01 00 | Nodo en ID 1 (CID-0x180), presión de lectura de 0x0182CD (99021) pascales |
0x182 | 4 | E5 83 01 00 | Nodo en ID 2 (CID-0x180), presión de lectura de 0x0183E5 (99301) pascales |
Hoja de datos electrónica
La hoja de datos electrónicos (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, en CiA311 se define un nuevo formato basado en XML llamado XDD. XDD cumple con la norma ISO 15745.
Glosario de términos CANopen
- PDO : Objeto de datos de proceso - Entradas y salidas. Valores de tipo velocidad de rotación, voltaje, frecuencia, corriente eléctrica, etc.
- SDO : Objeto de datos de servicio: ajustes de configuración, posiblemente ID de nodo, velocidad en baudios, compensación, ganancia, etc.
- COB-ID : Identificador de objeto de comunicación
- CAN ID : Identificador de CAN. Este es el identificador de mensaje CAN de 11 bits que se encuentra al comienzo de cada mensaje CAN en el bus.
- EDS : Ficha electrónica de datos. Este es un archivo con formato de estilo INI o XML.
- DCF : Archivo de configuración del dispositivo. Este es un archivo EDS modificado con configuraciones para ID de nodo y velocidad en baudios.
Ver también
- La red de área del controlador es un artículo sobre el bus CAN.
- J1939
- DeviceNet
- IEEE 1451
- TransductorML
Referencias
- ^ Especificación de la capa de aplicación CiA 301 CANopen, descarga gratuita desdeCAN en Automatización
- ^ Especificación de la hoja de datos electrónicos (EDS) de CiA 306 CANopen
- ^ Especificación CiA 311 CANopen XML-EDS
- ^ Conjunto de conexiones predefinidas de CANopen Basics[8]
- ^ Especificación de perfil de dispositivo CANopen CiA 401 para módulos de E / S genéricos, descarga gratuita desdeCAN en Automatización
- ^ Perfil de dispositivo CANopen CiA 402 para controladores de movimiento y variadores (igual que IEC 61800-7-201 / 301)
enlaces externos
- CANopen Origins - Proyecto Esprit ASPIC 1993 (Bosch, Universidad de Newcastle, Universidad de Ciencias Aplicadas en Reutlingen)
- Acerca de CANopen (canopensolutions.com)
- Uso de identificadores en redes CANopen
- CanFestival: un marco multiplataforma CANopen de código abierto
- CanOpenNode: un marco CANopen de código abierto para microcontroladores y Linux
- Lely CANopen: una biblioteca CANopen de código abierto para maestros y esclavos
- openCANopen: un maestro CANopen de código abierto
- Proyecto de pila CANopen: una pila CANopen de código abierto flexible para microcontroladores
- CANopen para Python
- CANnewsletter-Información sobre CAN, CANopen y J1939
- Páginas educativas CANopen
- Introducción a los conceptos básicos de CANopen (en www.canopen-solutions.com)
- Wiki de la comunidad CANopen-Lift
- CANeds: editor gratuito de archivos EDA y XDD
- Información CAN para la industria
- Portal en línea de CAN en Automatización
- CANopen: capa de aplicación y perfil de comunicación general
- CANopen - Una introducción simple (incluido el convertidor de ID COB)