CANopen

Para estructuras de red sencillas, CANopen admite una asignación predefinida de identificadores de mensajes.

Las direcciones de transmisión y recepción se dan desde el punto de vista del dispositivo. Por lo tanto, una consulta a un dispositivo en la red enviaría un 0x600+nodeid y recibiría como respuesta un 0x580+nodeid. ^{[ 1 ]}

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 protocolo de control del módulo es utilizado por el maestro NMT para cambiar el estado de los dispositivos. El COB-ID de la trama CAN de este protocolo siempre es 0, lo que significa que tiene un código de función 0 y  un ID de nodo 0, lo que implica que todos los nodos de la red procesarán este mensaje. El  ID de nodo real al que se dirige el comando se indica en la parte de datos del mensaje (en el segundo byte). Este 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 monitorizar los nodos de la red y verificar que están activos. Un productor de Heartbeat (normalmente un dispositivo esclavo) envía periódicamente un mensaje con el código de función binario 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 Heartbeat 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, como reiniciar el dispositivo o indicar un error. El formato de la trama es:

Los dispositivos CANopen deben realizar la transición del estado Inicializando al estado Preoperacional automáticamente durante el arranque. Cuando se produce esta transición, se envía un único mensaje de latido al bus. Este es el protocolo de arranque .

Existe un protocolo de respuesta/replicación (modelo pull), denominado protección de nodos, para la monitorización de esclavos.

El protocolo SDO se utiliza para configurar y leer valores del diccionario de objetos de un dispositivo remoto. El dispositivo cuyo diccionario de objetos se consulta 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 de CANopen, la comunicación se visualiza desde el servidor SDO, de modo que una lectura del diccionario de objetos resulta en una carga SDO y una escritura en una entrada del diccionario es una descarga SDO.

Dado que los valores del diccionario de objetos pueden superar el límite de ocho bytes de una trama CAN, el protocolo SDO implementa la segmentación y dessegmentación de mensajes más largos. En realidad, existen dos protocolos: descarga/carga SDO y descarga/carga de bloques SDO. La transferencia de bloques SDO es una incorporación reciente al estándar, que permite transferir grandes cantidades de datos con una sobrecarga de protocolo ligeramente menor.

Los COB-ID de los mensajes de transferencia SDO correspondientes, tanto del cliente al servidor como del servidor al 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 de cliente SDO del dispositivo se pueden configurar con variables en las direcciones 0x1280 - 0x12FF. Sin embargo, el conjunto de conexiones predefinido define un canal SDO que se puede usar incluso justo después del arranque (en el estado preoperacional) para configurar el dispositivo. Los COB-ID de este canal son 0x600 +  ID de nodo para la recepción y 0x580 +  ID de nodo para la transmisión.

Para iniciar una descarga, el cliente SDO envía los siguientes datos en un mensaje CAN con el COB-ID 'receive' del canal SDO.

• ccs es el especificador de comando del cliente para la transferencia SDO. Este valor es 0 para la descarga de un segmento SDO, 1 para iniciar la descarga, 2 para iniciar la carga, 3 para la carga de un segmento SDO, 4 para abortar una transferencia SDO, 5 para la carga de un bloque SDO y 6 para la descarga de un bloque SDO.
• n es el número de bytes en la parte de datos del mensaje que no contienen datos, válido solo si e y s están definidos.
• Si está activado, el bit e indica una transferencia acelerada, es decir, todos los datos intercambiados están contenidos en el mensaje. Si este bit está desactivado, la transferencia es segmentada, lo que significa que los datos no caben en un solo mensaje y se utilizan varios.
• Si se establece, s indica que el tamaño de los datos se especifica en n (si se establece e) o en la parte de datos del mensaje.
• El índice es el índice del diccionario de objetos de los datos a los que se va a acceder, codificado en little endian.
• subíndice es el subíndice de la variable del diccionario de objetos
• Los datos contienen la información que se va a cargar en caso de una transferencia acelerada (e está configurado), o el tamaño de los datos que se van a cargar (s está configurado, e no está configurado), a menudo codificados en little endian.

El protocolo Process Data Object (PDO) se utiliza para procesar datos en tiempo real entre distintos nodos. Se pueden transferir hasta 8 bytes (64 bits) de datos por cada PDO, ya sea desde o hacia el dispositivo. Un PDO puede contener varias entradas en el diccionario de objetos, y los objetos dentro de un PDO son configurables mediante las entradas del diccionario de objetos de asignación y de parámetros.

Existen dos tipos de PDO: de transmisión y de recepción (TPDO y RPDO). El primero se utiliza para datos provenientes del dispositivo (el dispositivo es productor de datos) y el segundo para datos enviados al dispositivo (el dispositivo es consumidor de datos); es decir, con RPDO se pueden enviar datos al dispositivo y con TPDO se pueden leer datos del dispositivo. En el conjunto de conexiones predefinido, hay identificadores disponibles para cuatro TPDO y cuatro RPDO. Con la configuración, es posible configurar hasta 512 PDO.

Los PDO se pueden enviar de forma síncrona o asíncrona. Los PDO síncronos se envían después del mensaje SYNC, mientras que los asíncronos se envían tras un activador interno o externo. Por ejemplo, puede solicitar a un dispositivo que transmita un TPDO con los datos necesarios enviando un TPDO vacío con el indicador RTR (si el dispositivo está configurado para aceptar solicitudes de TPDO).

Con los RPDO, por ejemplo, puede iniciar 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 productor de sincronización proporciona la señal de sincronización al consumidor de sincronización. Cuando el consumidor de sincronización recibe la señal, comienza a realizar sus tareas síncronas.

En general, la fijación del tiempo de transmisión de los mensajes PDO síncronos, junto con la periodicidad de transmisión del objeto Sync, garantiza que los dispositivos sensores puedan organizarse para muestrear las variables del proceso y que los dispositivos actuadores puedan aplicar su actuación de forma coordinada.

El identificador del objeto Sync está disponible en el índice 1005h.

Normalmente, 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 signo de 16 bits desde el 1 de enero de 1984. (Esto provocará un desbordamiento el 7 de junio de 2163).

Algunas aplicaciones críticas en cuanto al tiempo, especialmente en redes extensas 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 protocolo de sincronización de alta resolución opcional, que emplea un formato especial de mensaje de marca de tiempo para compensar la inevitable desviación 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) a un PDO.

Los mensajes de emergencia se activan al producirse un error interno grave en un dispositivo y se transmiten desde la aplicación afectada a los demás dispositivos con alta prioridad. Esto los hace idóneos para alertas de error de tipo interrupción. Un telegrama de emergencia solo 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 es necesario enviar más mensajes de emergencia. Mediante los códigos de error de emergencia definidos en el perfil de comunicación CANopen, el registro de errores y la información adicional específica del dispositivo se especifican en los perfiles de dispositivo.