CANopen vs EtherCAT vs Modbus para sistemas AGV y AMR

Seamos sinceros. Es fácil subestimar la importancia de la comunicación en un proyecto de AGV o AMR. Por lo general, solo se vuelve importante cuando el vehículo empieza a moverse y varios ejes, codificadores, frenos, sensores y controladores tienen que trabajar juntos.

Para un AGV de transporte simple, la carga de comunicación puede ser moderada. Una vez que el sistema pasa a la dirección dual, la dirección de cuatro ruedas, el levantamiento u otros movimientos coordinados, el tiempo de respuesta y la sincronización empiezan a importar mucho más.

CANopen, EtherCAT y Modbus son opciones comunes en la automatización industrial, pero se adaptan a tareas muy diferentes dentro de un AGV o AMR. Lea este artículo, exploraremos estos tres protocolos de comunicación uno por uno en detalle y le ayudaremos a elegir el mejor para su robot agv.

CANopen vs EtherCAT vs Modbus de un vistazo

Aquí hay una comparación más práctica para aplicaciones de AGV y AMR.

Artículo	CANopen	EtherCAT	Modbus
Capa física típica	CAN, normalmente ISO 11898-2	Ethernet 100BASE-TX comúnmente utilizada	RS-485 comúnmente utilizada para RTU; Ethernet/TCP/IP para Modbus TCP
Tasa de datos típica	Hasta 1 Mbit/s para CANopen CC	100 Mbit/s	Depende de la implementación; RTU comúnmente usa velocidades de baudios seriales, mientras que Modbus TCP sigue la velocidad de Ethernet
Topología de red típica	Bus lineal con derivaciones cortas	Topologías de línea, árbol, estrella y rama	Bus multiconexión para RTU; topología Ethernet estándar para TCP
Comportamiento en tiempo real	Lo suficientemente determinista para muchas aplicaciones estándar de control de movimiento	Altamente determinista y diseñado para control cíclico rápido	Generalmente menos determinista para movimiento estrechamente sincronizado
Método de sincronización	El objeto SYNC de CANopen puede coordinar la comunicación PDO síncrona	Los relojes distribuidos proporcionan sincronización a nivel de red de menos de 1 μs	No hay mecanismo nativo equivalente de reloj distribuido
Soporte de perfil de movimiento	CiA 402 comúnmente utilizado para variadores y control de movimiento	CoE soporta perfiles de aplicación CANopen, incluyendo CiA 402	Usualmente basado en mapeo de registros específico del fabricante
Coordinación multieje	Adecuado para muchos sistemas AGV multieje estándar	Muy fuerte para movimiento multieje estrechamente sincronizado	Mejor adaptado para control más simple o menos crítico en tiempo
Escalabilidad con más ejes	El ancho de banda de CAN y la carga del bus PDO deben revisarse a medida que aumenta el número de ejes	El alto ancho de banda y el procesamiento eficiente de tramas se adaptan a mayores números de ejes	El tiempo de respuesta puede aumentar a medida que se consultan más dispositivos o registros
Diagnósticos	Diccionario de objetos, EMCY, latido, estado del variador	Estado del dispositivo, contador de trabajo, diagnósticos de enlace y datos de proceso	Códigos de excepción, datos de registro/estado y diagnósticos específicos del fabricante
Esfuerzo de integración	Moderado; ecosistema maduro y amplio soporte de dispositivos	Usualmente mayor, especialmente para sistemas de movimiento sincronizado	Usualmente sencillo para comunicación básica basada en registros
Uso típico de AGV / AMR	Motores de tracción, motores de dirección, ejes servo	Dirección múltiple, AMR de alta dinámica, sistemas multieje coordinados	Sensores, E/S, cargadores, unidades de levantamiento, PLC y dispositivos auxiliares
Mejor ajuste	Control de movimiento estándar de AGV/AMR	Movimiento sincronizado de alto rendimiento	Control simple y comunicación no crítica en tiempo

CANopen para control de movimiento de AGV y AMR

CANopen ya es común en sistemas de tracción de robots móviles.

Le da al controlador una forma estandarizada de intercambiar comandos de velocidad, datos de posición, valores de corriente, información de estado y fallas con el variador servo.

El controlador puede necesitar enviar comandos de velocidad a dos motores de tracción mientras recibe velocidad real, corriente, posición del codificador, estado del variador e información de fallas. CANopen maneja bien este tipo de comunicación sin requerir una red excesivamente complicada.

CANopen también usa objetos de comunicación estandarizados como PDO y SDO.

Los PDO normalmente se usan para datos que necesitan moverse rápido durante la operación, como comandos de velocidad, comandos de torque, retroalimentación de posición o información de estado. Los SDO se usan más comúnmente para configuraciones de parámetros y configuración.

Para sistemas servo, CiA 402 es especialmente importante porque define un perfil estandarizado de variador y control de movimiento. Esto hace que sea más fácil integrar variadores servo de agv compatibles en una arquitectura de controlador en lugar de construir cada comando desde cero.

Por lo tanto, CANopen es un fuerte ajuste para muchos:

AGV de tracción diferencial
AGV de rueda de dirección única
AGV de dirección dual
AGV montacargas
AMR de almacén de bajo voltaje
AGV de trabajo pesado que operan a velocidades moderadas

No es la red industrial más rápida disponible. Claro, eso importa en algunos proyectos. Pero muchos AGV no necesitan realmente ciclos de comunicación extremadamente cortos entre un gran número de ejes sincronizados.

Para esos sistemas, CANopen puede ofrecer un muy buen equilibrio entre rendimiento, costo, cableado y esfuerzo de desarrollo. CANopen y CAN bus también se usan ampliamente en aplicaciones de variador servo de AGV debido a su robustez y relativa simplicidad de cableado.

EtherCAT para sistemas de AGV y AMR de mayor rendimiento

EtherCAT se vuelve más atractivo cuando el tiempo y la sincronización empiezan a importar más.

A diferencia de CANopen, EtherCAT se basa en la tecnología Ethernet y está diseñado para una comunicación industrial rápida y determinista. Es especialmente útil cuando varios ejes servo necesitan funcionar juntos con diferencias de tiempo muy reducidas.

Imagine un AGV con cuatro ruedas directrices.

El vehículo puede tener cuatro motores de dirección y cuatro motores de tracción. Al girar, cada eje de dirección debe alcanzar el ángulo correcto mientras cada rueda motriz de AGV mantiene la velocidad requerida. Si estos ejes no se coordinan bien, el vehículo puede experimentar arrastre de ruedas, resistencia de dirección, corrientes de motor innecesarias o movimientos inestables.

Aquí es donde EtherCAT tiene una ventaja.

Su mecanismo de reloj distribuido puede ofrecer una sincronización muy precisa entre los dispositivos. El controlador puede gestionar múltiples ejes con tiempos de comunicación predecibles, lo cual es útil para:

AGV con dirección en las cuatro ruedas
Robots móviles omnidireccionales
AMR de alta velocidad
Sistemas de elevación y tracción multieje
Robots que requieren un movimiento estrechamente coordinado
Manipuladores móviles con varios ejes servo

EtherCAT se utiliza cada vez más en arquitecturas AMR de mayor rendimiento que requieren tasas de actualización más rápidas y tiempos deterministas.

Pero EtherCAT también tiene un coste.

El controlador debe admitir EtherCAT. Los servoaccionamientos también deben admitirlo. La configuración y puesta en marcha también pueden ser más complejas que las de una red CANopen básica.

Para un AGV de almacén de movimiento lento con dos motores de tracción, EtherCAT puede ofrecer más capacidad de la que la aplicación realmente necesita.

Eso no hace que EtherCAT sea peor. Simplemente significa que el rendimiento de comunicación debe adaptarse a la arquitectura del robot en lugar de seleccionarse solo porque un protocolo parezca más avanzado sobre el papel.

Dónde encaja Modbus en los sistemas AGV y AMR

Modbus es uno de los protocolos de comunicación industrial más reconocidos. Es sencillo, maduro y compatible con numerosos dispositivos.

Sin embargo, en los AGV y AMR, su función suele ser diferente a la de CANopen o EtherCAT.

Modbus RTU suele utilizarse sobre RS485, mientras que Modbus TCP se utiliza sobre Ethernet. Ambos son útiles para intercambiar valores de estado, parámetros, comandos y otros datos relativamente sencillos.

Por ejemplo, Modbus puede utilizarse con:

PLC
Módulos de E/S
Interfaces de gestión de baterías
Cargadores
Sensores
Actuadores auxiliares
Equipos de elevación
Dispositivos de monitorización

También puede utilizarse con servoaccionamientos en algunos sistemas. Por ejemplo, los productos de servoaccionamiento y movimiento HKT ROBOT admiten opciones de comunicación que incluyen CANopen, EtherCAT y Modbus (RS485), según la configuración.

No obstante, Modbus suele ser menos adecuado cuando varios ejes servoaccionados requieren una sincronización en tiempo real muy precisa.

Las necesidades de comunicación cambian con la arquitectura del AGV

La arquitectura de tracción influye mucho en la elección del protocolo.

Un AGV diferencial de dos ruedas es relativamente sencillo. Cada motor de tracción necesita control de velocidad o par, y el controlador ajusta las velocidades de las ruedas izquierda y derecha para dirigir el vehículo.

CANopen suele ser suficiente para este tipo de sistema.

Un AGV con una sola rueda de dirección añade otro eje controlado. El motor de dirección requiere control de posición, mientras que el motor de tracción controla la velocidad del vehículo. CANopen sigue siendo adecuado en muchos casos.

Ahora añada varias ruedas de dirección.

Una plataforma de dirección de cuatro ruedas puede requerir la coordinación del ángulo de dirección, la velocidad de las ruedas, la retroalimentación de los codificadores y las actualizaciones de posición en varios ejes servoaccionados. En ese punto, la sincronización de la red adquiere una importancia mucho mayor.

Una orientación general sería la siguiente:

Arquitectura del AGV / AMR	Comunicación	Motivo principal
AGV diferencial de dos ruedas	CANopen	Número moderado de ejes, control servoaccionado fiable
AGV con una sola rueda de dirección	CANopen	Los ejes de tracción y dirección son fáciles de gestionar
AGV con dirección dual	CANopen / EtherCAT	Depende de la sincronización y la frecuencia de actualización
AGV con cuatro ruedas de dirección	EtherCAT / CANopen	Los múltiples ejes de dirección y tracción deben coordinarse
AMR de alta dinámica	EtherCAT	Actualizaciones más rápidas y sincronización más precisa
AGV de gran capacidad y baja velocidad	CANopen	A menudo no es necesaria una gran anchura de banda
Módulo de elevación / rotación	CANopen / EtherCAT / Modbus	Depende de la complejidad del movimiento
Sensores, E/S y sistemas auxiliares	Modbus	A menudo basta con un intercambio de datos sencillo

Esta es una orientación de diseño, no una regla fija. Antes de definir la red, deben comprobarse el soporte del controlador, la compatibilidad con servoaccionamientos, la plataforma de software, las funciones de seguridad y las futuras ampliaciones.

La velocidad no es la única diferencia importante

Las comparaciones de protocolos a menudo se centran demasiado en la velocidad de comunicación.

De ese modo se ignora una parte importante de la decisión de ingeniería.

Para un diseñador de AGV, el esfuerzo de integración puede ser igual de importante.

Una red EtherCAT rápida ofrece pocas ventajas si el controlador del vehículo existente solo admite CANopen. Del mismo modo, elegir un servoaccionamiento con un conector CAN no significa automáticamente que admita CANopen.

La interfaz física y el protocolo de comunicación no son lo mismo.

Un servoaccionamiento basado en CAN puede utilizar CANopen, J1939 o un protocolo CAN propietario. Si el controlador del vehículo espera CANopen, el servoaccionamiento debe admitir el mismo protocolo y estructura de objetos.

Esta es una de las razones por las que la compatibilidad del protocolo debe confirmarse mediante la documentación real del controlador y del servoaccionamiento, y no únicamente por el tipo de conector.

Lo mismo ocurre con Modbus.

RS485 describe la capa física de comunicación. Por sí sola no indica qué protocolo de comunicación se utiliza sobre ella.

Detalles como este pueden ahorrar mucho tiempo de puesta en marcha más adelante.

La selección del protocolo debe partir del sistema de accionamiento completo

En realidad, la comunicación no es solo una especificación del servodrive; forma parte de la arquitectura del vehículo en su conjunto.

El motor para AGV, el servodrive, el codificador, el controlador, la caja de engranajes y la rueda motriz funcionan en conjunto.

Por ejemplo, un AGV puede utilizar un codificador absoluto en el eje de dirección para conservar información sobre la posición de la dirección. El servodrive debe ser compatible con ese codificador, mientras que la red de comunicación debe permitir que el controlador dé órdenes al eje de dirección y lo supervise correctamente.

Lo mismo se aplica a las unidades de accionamiento diferencial para AGV.

El par del motor y la relación de transmisión determinan la salida mecánica, pero el controlador sigue necesitando una realimentación de velocidad fiable y una ejecución precisa de las órdenes para mantener sincronizadas las dos ruedas.

En HKT ROBOT, normalmente analizamos la aplicación completa en lugar de seleccionar un componente de accionamiento basándonos únicamente en la capacidad de carga. El peso del vehículo, la carga útil, la velocidad, el diámetro de las ruedas, la relación de transmisión, el codificador, el freno, el espacio de instalación y los requisitos de control influyen en la configuración final del sistema de accionamiento.

Conclusión

CANopen, EtherCAT y Modbus tienen su lugar en los sistemas AGV y AMR, pero resuelven problemas diferentes.

CANopen ofrece un excelente equilibrio para muchos sistemas de servomotores de robots móviles. EtherCAT es más adecuado para el movimiento multieje exigente en el que la sincronización y la comunicación determinista son más importantes. Modbus sigue siendo útil para la comunicación más sencilla y los dispositivos auxiliares.

Lo importante no es elegir el protocolo más potente. Es elegir uno que se adapte al sistema de servomotores, al controlador, a la arquitectura del vehículo y a los requisitos reales de movimiento.

Para los diseñadores de AGV y AMR, esto suele dar como resultado un sistema más fiable y muchos menos problemas durante la puesta en marcha.

En HKT ROBOT, nuestras soluciones de servomotores y accionamientos admiten diferentes opciones de comunicación, incluidas CANopen, EtherCAT y Modbus (RS485). El protocolo puede seleccionarse en función del sistema de control y la arquitectura del vehículo, para que el motor, el servoaccionamiento, el codificador, la caja de cambios y la interfaz de comunicación funcionen juntos como un sistema de movimiento completo.

Si está planificando un nuevo proyecto AGV o AMR, póngase en contacto con nosotros y facilítenos las especificaciones de su vehículo para que podamos ofrecerle una configuración adecuada de motor, accionamiento, caja de cambios y ruedas.

Preguntas frecuentes

1. ¿Se pueden usar CANopen y EtherCAT en el mismo AGV?

Sí. Un vehículo puede utilizar diferentes redes de comunicación para distintos subsistemas. Por ejemplo, EtherCAT puede gestionar los ejes servo sincronizados, mientras que CANopen conecta los servoaccionamientos locales o los módulos auxiliares. La arquitectura del controlador debe admitir ambas redes.

2. ¿Puede un solo bus CANopen controlar tanto los motores de dirección como los motores de tracción?

Sí. Varios servoaccionamientos pueden compartir una sola red CANopen, siempre que se diseñen adecuadamente el número de nodos, la configuración de los PDO, la carga del bus y la frecuencia de actualización. El límite práctico suele estar determinado por el rendimiento requerido del ciclo de control, más que por el número físico de nodos.

3. ¿EtherCAT reduce el deslizamiento de las ruedas de los AGV?

No. EtherCAT puede mejorar la sincronización de los comandos, pero el deslizamiento de las ruedas es principalmente un problema mecánico de tracción. El material de las ruedas, la carga normal, la aceleración, el estado del suelo y el par de tracción tienen un efecto mucho mayor.

4. ¿Se debe seleccionar el protocolo de comunicación antes que el servoaccionamiento?

Normalmente, deben seleccionarse juntos. El controlador del vehículo, el servoaccionamiento, la interfaz del codificador, los modos de movimiento admitidos, las funciones de seguridad y el protocolo de comunicación deben ser compatibles entre sí. Elegir un componente primero puede generar un trabajo de integración innecesario más adelante.

5. ¿Sigue siendo CANopen adecuado para AGV con cargas útiles elevadas?

La carga útil por sí sola no determina el protocolo. Un AGV de 20 toneladas que se mueve lentamente y cuenta con un número limitado de ejes puede seguir funcionando bien con CANopen. La complejidad del movimiento y los requisitos de sincronización son más importantes que el peso del vehículo.

6. ¿Qué ocurre si el controlador del AGV y el servoaccionamiento utilizan perfiles CANopen diferentes?

La integración puede resultar mucho más difícil. Aunque ambos dispositivos admitan CANopen, todavía es necesario comprobar el diccionario de objetos admitido, la implementación de CiA 402, el mapeo de los PDO, los modos de funcionamiento y los objetos específicos del fabricante.