‼️CANbus Troubleshooting
Este documento nos puede ayudar a solucionar problemas de comunicación relacionados con nuestro CANbus
Aunque poner en funcionamiento no es excesivamente complejo si que depende de diferentes factores para que funcione de forma correcta. Os vamos a sugerir algunos puntos a tener en cuenta cuando montemos nuestro CANbus:
Cableado
El primer paso a realizar en caso de problemas ha de ser todo lo relacionado con el cableado CANbus.
Asegúrate que disponemos de dos terminadores correctamente instalados en tu sistema CAN, normalmente suelen ser unos jumpers que habilitan los terminadores 120Ohm.
Dado que el cableado va a estar en unas condiciones de temperatura y movimientos especiales, en una impresora 3D se aconseja usar un cableado que sea relativamente flexible y aguante temperatura... cables PTFE suelen ser aconsejables
La sección del cable debería de ser >= 0.22mm2
La impedancia de los cables CAN debe ser de unos 120 ohms (+- 10%), para facilitar esto el cable utilizado tiene que tener una baja resistencia para mantener el umbral requerido por los receptores junto con los terminadores resistivos del bus
Revisa que las conexiones a tus dispositivos sean seguras, evitando malas conexiones y falsos contactos que pueden conllevar errores de conexión intermitentes
Es importante también que los cables, CANL y CANH, estén trenzados e incluso en según que condiciones que estos tengan un mallado extra de protección. Intenta evitar trenzar estos junto con los cables de alimentación siempre que sea posible.
Es importante encontrar la combinación adecuada entre el bitrate y la longitud del cable, al final de la guía tenéis más información al respecto
Configuración
Firmware
Es crítico que todos nuestros dispositivos tengan instalado el firmware Klipper tanto en configuración de MCU, pines CAN de comunicaciones y bitrate.
Ya os explicamos en nuestra guía CANbus como crear, aplicar y actualizar nuestros frimwares CAN.
Configuración Klipper
En ocasiones una incorrecta configuración de Klipper va a generar errores a la hora de que Klipper pueda acceder o comunicarse con nuestros dispositivos CAN.
MCU
Muchos de estos errores relacionados con problemas de comunicación entre Klipper y nuestros dispositivos CAN se pueden dar por una incorrecta configuración de las cadenas de conexión a nuestras MCU.
A modo de ejemplo, si conectamos nuestra MCU utilizando serial/USB en lugar de CAN nuestra configuración deber ser algo similar a:
Por otro lado si tenemos conectada nuestra MCU utilizando CAN la definición cambia a algo como lo siguiente, utilizando en este caso el valor UUID:
Por último, si utilizamos un toolhead CAN las definiciones de la MCU han de incluir un ID/nombre para poder identificarlo, además de obviamente el UUID:
Pins
Otro aspecto importante cuando trabajamos con dispositivos CAN, en especial aquellos extras a nuestra MCU principal, la definición de pines van a usar el ID/nombre de esta. A modo de ejemplo para un EBB:
Interfaz
Otro aspecto necesario es una correcta configuración de nuestra interfaz CAN de red nuestro host.
Aunque en las diferentes guías ya hemos explicado como montarlo dependiendo del dispositivo vamos a repasar.
Vamos a iniciar el proceso ajustando nuestra configuración de la interfaz de comunicación CAN para nuestro host Klipper. Para ello y desde el terminal SSH lanzaremos el siguiente comando:
Nano es un editor de textos en línea de comandos, podemos utilizar cualquier otro que nos sea cómodo, y deberemos añadir/actualizar el contenido de la configuración de nuestro can0 de la siguiente manera:
Usando CTRL+X y Y y ENTER guardaremos los cambios
La configuración anterior puede variar dependiendo del sistema operativo de vuestro host o el/los dispositivos utilizados, os aconsejamos revisar la documentación del fabricante de los dispositivos que utilicéis.
Una vez realizado el cambio reiniciaremos nuestro host:
Una vez reiniciado el host es aconsejable revisar que nuestro interfaz CAN se encuentre levantando. Podremos hacerlo lanzando el siguiente comando desde SSH:
Podemos levantar el interfaz can0 manualmente ejecutando:
Si diera error podemos intentar levantar el interfaz con:
En el caso que no se levante nuestro interfaz de forma automática
revisaremos el contenido del fichero de configuración, con el editor nano por ejemplo,
/etc/network/interfaceseste debería de contener algo parecido a lo siguiente si queremos que cargue nuestras configuraciones anteriores:## Include files from /etc/network/interfaces.d:source /etc/network/interfaces.d/*En caso que lo anterior este correcto, incluyendo temas de cableado y firmware, pero aún así no se levante correctamente nuestro interfaz os aconsejamos revisar el log de sistema y dmesg. Es importante revisar el orden de arranque de los dispositivos y de la interfaz, en ocasiones se hace la carga de la interfaz y a posteriori los drivers o soporte de los dispositivos relacionados haciendo que no sea posible levantar el interfaz de forma correcta. En estos casos y dado que controlar el orden de arranque de dispositivos y opciones de sistema suele ser relativamente complicado podemos crear un simple script en el arranque que lance los comandos indicados anteriormente para levantar el interfaz de forma manual.
Bitrate CANbus
Es importante en un canal de comunicación es el ancho de banda disponible en este, su latencia y porcentaje de errores de comunicación. Teniendo en cuenta esto, no todos los dispositivos CAN para 3D se comportan de igual forma y siempre deberemos configurar el bitrate de nuestro CANbus a la velocidad del dispositivo que soporte menos bitrate. Es fundamental que a un menos bitrate tendremos un menor ancho de banda para el flujo de datos y, por lo tanto, en determinadas situaciones (como gestión de acelerómetro, leds neopixel, etc...) podemos tener un cuello de botella y aumentar la latencia. Por otro lado, un alto bitrate nos va a permitir no tener problemas de latencia pero, por otro lado, y en dispositivos con características limitadas o calidad, pueden ocasionar errores de comunicación que también afectarán. Podremos obtener información de la comunicación CANbus desde SSH con este comando:
Tests
Simulando carga en nuestro CANbus
Para poder asegurarnos que nuestro bitrate y cableado funcionan de forma óptima, podemos utilizar can-utils que nos permitirá al simular una carga de datos darnos información ver si tenemos pérdida de paquetes.
Normalmente las acciones que suelen cargar más la comunicación son aquellas relacionadas con Input Shaper (si nuestro CAN dispone de acelerómetro) o gestión de tiras leds neopixel... por eso es aconsejable lanzar una de estas acciones para ver si tenemos pérdidas de paquetes.
También es aconsejable realizar por ejemplo un test de velocidad, ya que en este caso simularemos movimiento para ver si este afecta a la comunicación, normalmente por un problema de cableado.
También podremos ver desde Mainsail como explicamos en el punto anterior un resumen de las métricas de nuestro interfaz CAN.
Capturando el tráfico de nuestro CANbus
Siguiendo con las herramientas can-utils podemos encontrar candump que nos va a permitir capturar el tráfico de nuestro CANbus:
El comando anterior nos va a permitir capturar el tráfico en nuestra interfaz can0 cobre un fichero mycanlog. Una vez finalizada la captura podemos utilizar la herramienta de Klipper parsecandump.py para parsear esos mensajes:
Última actualización
