CANopen transmisión a múltiples ID al mismo tiempo

Para tener éxito con este proyecto, necesita saber cómo funciona CANopen y cómo funciona el dispositivo específico. Por ejemplo, si puede leer el elemento 1000h del Diccionario de objetos, revelará qué perfil de dispositivo está utilizando el robot.

Todos los datos en CANopen se envían a través de PDO (objetos de datos de proceso). Los mensajes que salen de un nodo CANopen se denominan TPDO (PDO de transmisión) y los mensajes que llegan a un nodo se denominan RPDO (PDO de recepción). Por supuesto, esto significa que el TPDO de un nodo debe ser el RPDO de otro nodo.

Algunas ideas sobre la ingeniería inversa CANopen:

• 181h es la identificación CAN estándar para el primer TPDO del nodo 1.
• 301h es el ID CAN estándar para el segundo RPDO del nodo 1.

Esto está de acuerdo con, por ejemplo, el "módulo de E / S genérico" del perfil de dispositivo más común DS401, pero también puede coincidir con otros perfiles de dispositivo.

En particular, sin embargo, es poco probable que 181 y 301 tengan una funcionalidad similar. Yo esperaría que uno de ellos sean datos entrantes y el otro datos salientes.

Si este es el perfil de dispositivo DS401, entonces 181h serán datos digitales en una dirección, mientras que 301h serán datos analógicos en la otra dirección. Es poco probable que estos 2 correspondan a 2 botones diferentes (digital). En los perfiles de dispositivos como DS401, se especifica cómo se deben almacenar los datos. En una aplicación CANopen genérica, esto no se especifica, pero los datos se pueden asignar a PDO de manera personalizada.

Por lo tanto, lo que describe no parece tener ningún sentido. Tampoco está claro por qué estos dos DOP tienen un valor de 0xFB al final. Esto también es algún tipo de datos: las sumas de comprobación son manejadas por hardware.

Para controlar cualquier dispositivo CANOpen, primero debes estudiar el diccionario de objetos del dispositivo. En el diccionario encontrará objetos de Datos de Servicio y Proceso, que son ubicaciones básicamente direccionables para datos de configuración, estado, comandos de control, etc.

Entonces, en lugar de tratar de averiguar qué mensajes CAN enviar y cómo enviarlos, primero debe aprender cómo funciona CANOpen, encontrar los objetos de comunicación a los que necesita acceder y luego enviarlos en formato CANOpen para realizar las funciones que usted necesita.

Lo más probable es que estos no sean mensajes "botón A presionado" o "botón B presionado", sino algo así como "Nodo NNN Cambie el objeto 0x6063 al valor XXXX", que se interpretará como "establecer una nueva velocidad para el motor izquierdo ".

Hay muchos perfiles de comunicación utilizados en robótica, como CiA 402 (unidades CANopen y perfil de control de movimiento). Tu robot podría soportar uno de ellos.

Si no conoce el diccionario de objetos de su dispositivo CANOpen específico y ni siquiera sabe si es compatible con uno de los perfiles de dispositivo estándar, es muy poco lo que puede hacer.

Por su pregunta, parece que tiene algún tipo de dispositivo de control remoto y está intentando realizar una ingeniería inversa de la comunicación. Esto podría ser un proceso tedioso, ya que algunos comandos CANOpen requieren varios mensajes CAN de un lado a otro para hacer algo. Mi único consejo en esta situación sería intentar obtener la hoja de datos del fabricante.

Esto es, en cierto sentido, trivial y se puede hacer con (creo) cualquier implementación de CANBus, pero no se realiza a nivel de CANopen.

En general, cualquier controlador CANBus en el mercado, como el venerable SJA1000, permitirá la implementación de una "máscara de aceptación". Básicamente, esto hará que la interfaz trate algunos bits del campo de dirección como "no importa". La configuración, por ejemplo, de los últimos 3 bits de la máscara para no preocuparse hará que el dispositivo responda a un bloque de 8 direcciones. Solo como punto de referencia, el SJA1000 tiene cuatro máscaras de aceptación independientes. Por lo tanto, puede configurar hasta cuatro bloques de direcciones de diferentes tamaños para que responda cada unidad. Consulte, por ejemplo, la nota de la aplicación SJA1000 .

Por lo tanto, el trabajo que debe hacer es configurar sus unidades para aprovechar las capacidades de la interfaz. Una vez hecho esto, simplemente transmite una identificación a un bloque de direcciones para mensajes individuales y a otro para mensajes grupales.

CAN (y creo que CANopen también) solo puede transmitir una ID a la vez.

Pero hay algunas soluciones basadas en lo que necesita:

1. Envíe una única ID que reciben varios dispositivos CAN (partes de robot). Creo que esto es lo que necesitas.
2. Si necesita actuar en una respuesta que es una combinación de diferentes dispositivos (de donde provienen los botones), use un mensaje (ID) CAN separado para establecer un modo, y si todos los modos (botones) están activos, actúe sobre él por las partes del robot que deben responder.

En el caso 2, por ej. Si tiene el botón A, B y C que necesita presionar para realizar una acción D, puede definir:

BUTTON_A_PRESSED_ID, sent by the part that has button A
BUTTON_B_PRESSED_ID, sent by the part that has button B
BUTTON_C_PRESSED_ID, sent by the part that has button C

La parte que debe actuar sobre ella, recibe estos mensajes, establece 3 indicadores y, si los 3 son válidos / recibidos, se realiza la acción D y se restablecen los indicadores.

Actualizar

Ver comentario Maple a continuación ... lo anterior solo funciona si se puede cambiar el código del receptor, lo que parece no ser así.