Estoy trabajando con el bus CAN y necesito ayuda con la decodificación de datos de mensajes.
Aquí está una muestra de los datos que veo en el bus CAN.
root@petalinux:/var/volatile/tmp# /tmp/candump -n 10 can0 can0 4E5 [4] F0 16 00 00 can0 665 [8] 40 78 60 00 00 00 00 00 can0 5E5 [8] 4B 78 60 00 DB 00 00 00 can0 665 [8] 40 64 60 00 00 00 00 00 can0 5E5 [8] 43 64 60 00 E4 7D 5E 00 can0 665 [8] 40 41 60 00 00 00 00 00 can0 5E5 [8] 4B 41 60 00 27 02 00 00 can0 665 [8] 40 41 60 00 00 00 00 00 can0 5E5 [8] 4B 41 60 00 27 02 00 00 can0 665 [8] 40 6C 60 00 00 00 00 00 root@petalinux:/var/volatile/tmp# No puedo averiguar cómo rastrear los datos hasta un CAN en particular mensaje de bus.
Mi dispositivo tiene un ID de nodo de 101 (base 10) y es un motor paso a paso StepIM. Aquí hay una referencia al manual: http://servotronix.com/wp-content/uploads/dlm_uploads/2015/05/stepIM_CANopen_fw0.0.2.85_Rev.1.3.pdf . Intentemos decodificar el último mensaje de arriba. Eso sería « can0 665 8 40 6C 60 00 00 00 00 00 «
No puedo» entender cómo traducir la cadena hexadecimal «* 40 6C 60 ..» en un comando que el documento para el motor paso a paso conoce …
Comentarios
- los stepIM son con el protocolo CANopen, que es un protocolo superior basado en el bus CAN. Intercambie la etiqueta CAN con CANopen.
Respuesta
Excepto por el primer mensaje, este es el típico Tráfico SDO ( CANopen ), con pares de solicitud / respuesta:
0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) Para el primer par, un indicio es el 0x4B en el primer byte de la respuesta. Esto indica que los datos devueltos tienen un tamaño de dos bytes (para un byte y cuatro bytes, son 0x4F y 0x43, respectivamente). El 0x40 en el primer byte de la solicitud indica que es una solicitud de lectura (el estándar usa un término diferente, » Upload «, con el significado opuesto que en Internet (descarga) – es desde la perspectiva del dispositivo direccionado).
La solicitud CAN ID es 0x600 + ID de nodo. La respuesta CAN ID es 0x580 + ID de nodo. Por lo tanto:
665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 Para los SDO, el índice y subíndice CANopen está en el segundo, tercer y cuarto byte (el byte menos significativo primero para el índice CANopen). Entonces, para el primer par, 40 78 60 00, el solicitante dice: » Dispositivo en el ID de nodo 0x65 (101), dame tu valor almacenado en 6078sub0 » .
En este caso, la información fluye desde el dispositivo direccionado a quien hizo la solicitud (el solicitante no puede verse en el registro del bus CAN, pero generalmente es un controlador central en el sistema o una herramienta de servicio que se ejecuta en una PC (generalmente un adaptador de USB a CAN)).
Por lo tanto, para el tráfico mostrado, las solicitudes de lectura se realizan para (el la respuesta para el último no está incluida en el registro de bus CAN publicado):
6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) Curiosamente, la solicitud de 6041sub0 se repite.
Además, aunque los SDO generalmente son solo para información de configuración, el rango de índice CANopen 0x6000 a 0x6FFF generalmente se usa para información que no es de configuración, como cantidades medidas o estado.
Profundizando en el manual
Los índices / subíndices SDO se pueden buscar en el manual (I h ha incluido los valores reales del registro de bus CAN de muestra):
6078sub0 Motor current, 219 mA 6064sub0 "Position Actual Internal Value" is 6,192,612 6041sub0 Statusword, 0x0227 = 0000 0010 0010 0111, meaning: "ready to switch on", "switched on", "operation enabled", "quick stop" "remote" 606Csub0 "Velocity Actual Value". The value is not included, but it is a 32-bit signed integer. El primer mensaje
Suponiendo que el primer mensaje también es CANopen, 4E5 F0 16 00 00: Para todos los mensajes CAN de CANopen, el ID es un código de función de cuatro bits (0-15) seguido de un ID de nodo de siete bits. En este caso, 0x4E5 = 1001 1100101b. Por lo tanto, el código de función es 1001b = 9, lo que significa » PDO4, transmit «. La dirección del flujo de información para los PDO (a pesar, en este caso, » transmit «) es una cuestión de definición (depende de la aplicación ). El ID de nodo es 1100101b = 0x65.
El ID de nodo para el PDO es el mismo que para los SDO.
La información en este PDO, » Transmitir PDO 4 «, está contenido en SDO 0x1A03, » Transmitir el parámetro de asignación de PDO 4 «. Si no se ha cambiado el valor predeterminado, los datos en el PDO son los mismos que SDO 0x60FAsub0, un entero de 32 bits con signo:
el control esfuerzo como la salida del bucle de control de posición. En la función de control de posición, la notación del esfuerzo de control depende del modo y, por lo tanto, no se especifica.
Conclusión
El dispositivo motor con ID de nodo 0x65 envía el esfuerzo de control (probablemente a intervalos de tiempo regulares) usando un PDO .
Un controlador o una ventana de monitoreo en tiempo real en una herramienta de servicio lee y muestra otras cantidades / estados medidos desde el mismo dispositivo motor usando SDO .
Comentarios
- Trabajo con este tipo de CAN datos de bus a diario, por lo que es fácilmente reconocible. Sin embargo, la interpretación / significado preciso depende de la información sobre el sistema en particular. Pensé que esta pregunta merecía una respuesta completa.
Respuesta
No ha explicado qué muestra exactamente su lista, pero podría sea el ID del mensaje, seguido del número de bytes de datos entre paréntesis, seguido de los bytes de datos reales. Nada parece indicar explícitamente si los ID son de 11 o 29 bits. Tal vez solo use 3 dígitos HEX para el ID. la lista indica ID de 11 bits. Si es así, mostraría 8 dígitos HEX para ID de 29 bits.
Por lo tanto, lo que cada línea (parece) muestra es un mensaje CAN. No hay nada más que decodificar comprender el mensaje CAN. Se le muestra explícitamente.
Por ejemplo, la última línea dice que se vio un mensaje con ID 665h (1637 decimal), que este mensaje tenía 8 bytes de datos y que el Los bytes de datos eran (en HEX) 40, 6C, 60, 0, 0, 0, 0 y 0. Los primeros tres serían 64, 108 y 96 en decimal.
En cuanto a lo que significado de ese mensaje es para cualquier dispositivo que lo haya originado o esté destinado a actuar sobre él, eso es algo tienes que buscar en la documentación de los dispositivos específicos. Esa «es una capa por encima de CAN.
Mi dispositivo tiene una identificación de nodo de 101
No hay ningún nodo ID en CAN, solo ID de mensaje. Si sus dispositivos utilizan el concepto de ID de nodo, entonces esto es algo particular para una capa de protocolo por encima de CAN. El estándar CAN no puede ayudarlo con eso. Debe consultar la documentación del dispositivo específico, que puede referirse al protocolo de nivel superior que usa por encima de CAN, posiblemente en un documento separado.
Comentarios
- Este ‘ no es CAN básico, es CANopen, como se ve en el Manual.
- Lo he desarrollado en mi respuesta .
Respuesta
El dispositivo usa un Protocolo CANopen . CANopen es un sistema de comunicación basado en CAN. Comprende protocolos de capa superior y especificaciones de perfil.
Se utiliza en Automatización. Hay varios analizadores de protocolo para descubrir toda la comunicación. El sistema de automatización que utiliza CANopen es una arquitectura maestro / esclavo. Encontrará información en wikipedia sobre CANopen, pero no es tan trivial como el propio CAN orientado a mensajes.
Comentarios
- Sí, eso es correcto. Es CANopen.
Respuesta
Para decodificar la comunicación, es necesario conocer el Diccionario de Objetos CANopen del motor. Parece que los TPDO y su contenido dependen de la comunicación y los objetos de mapeo.
Debe estudiar los siguientes términos de CANopen para comprender el protocolo. – Diccionario de objetos – Objetos de datos de proceso (PDO) – Parámetros de comunicación – Parámetros de mapeo