bater\u00eda de robot<\/a><\/strong> Tambi\u00e9n puede informar temperaturas, corriente, estados de advertencia, condiciones de protecci\u00f3n y l\u00edmites de carga o descarga permitidos. Cuando las condiciones de operaci\u00f3n cambian, estos valores brindan al controlador del veh\u00edculo informaci\u00f3n que puede usar antes de que el BMS alcance un estado de protecci\u00f3n estricta.<\/p>\n\n\n\nEsto hace que la comunicaci\u00f3n con la bater\u00eda del robot sea \u00fatil tanto para la operaci\u00f3n como para el mantenimiento inmediato. El software de flota puede utilizar informaci\u00f3n consistente sobre el estado y las fallas para distinguir una condici\u00f3n de baja energ\u00eda de un evento t\u00e9rmico, un evento de protecci\u00f3n o una falla de comunicaci\u00f3n.<\/p>\n\n\n\n
Apretones de manos del controlador y del cargador<\/h3>\n\n\n\n El controlador del veh\u00edculo y el cargador no requieren necesariamente datos de bater\u00eda id\u00e9nticos. Durante el movimiento, el controlador puede priorizar SOC, voltaje, corriente, temperatura, advertencias y l\u00edmites de descarga. Durante la carga, es posible que el sistema tambi\u00e9n necesite permiso de carga, l\u00edmites de corriente de carga, l\u00edmites de voltaje, estado de temperatura e informaci\u00f3n del estado de carga.<\/p>\n\n\n\n
Por este motivo, especificar un BMS de bater\u00eda CAN o un BMS de bater\u00eda RS485 es s\u00f3lo el primer paso. Dos dispositivos pueden compartir la misma interfaz el\u00e9ctrica pero utilizar diferentes identificadores, registros, factores de escala, intervalos de actualizaci\u00f3n o l\u00f3gica de control.<\/p>\n\n\n\n
La carga autom\u00e1tica hace que la distinci\u00f3n sea particularmente importante. Cuando un AGV o AMR se acopla sin la intervenci\u00f3n del operador, la bater\u00eda del robot, el cargador y el controlador necesitan un comportamiento definido para la autorizaci\u00f3n de carga, los l\u00edmites operativos, el manejo de fallas, la finalizaci\u00f3n de la carga y el regreso al servicio.<\/p>\n\n\n\n
Por qu\u00e9 la comunicaci\u00f3n afecta el tiempo de actividad<\/h3>\n\n\n\n La comunicaci\u00f3n \u00fatil de la bater\u00eda permite que el robot responda a las condiciones de la bater\u00eda antes de que un apagado forzoso se convierta en la \u00fanica respuesta disponible. Un SOC bajo puede iniciar una tarea de carga, una condici\u00f3n de temperatura puede afectar el comportamiento de carga y una falla reportada puede colocar el veh\u00edculo en un estado de servicio definido.<\/p>\n\n\n\n
Para las flotas, los datos consistentes de las bater\u00edas de los robots tambi\u00e9n mejoran la resoluci\u00f3n de problemas. Los equipos de mantenimiento pueden revisar los estados operativos y las alarmas en lugar de tratar cada p\u00e9rdida de propulsi\u00f3n o interrupci\u00f3n de la carga como el mismo problema.<\/p>\n\n\n\n
El beneficio no es simplemente m\u00e1s telemetr\u00eda. El valor real proviene de hacer de la bater\u00eda una parte integrada e interpretable de la arquitectura de control del robot.<\/p>\n\n\n\n
CAN versus RS485: en qu\u00e9 se diferencian en los sistemas rob\u00f3ticos<\/h2>\n\n\n\n CAN y RS485 son comunes en sistemas industriales, pero resuelven diferentes partes del problema de comunicaci\u00f3n. CAN proporciona mecanismos de encuadre de mensajes, arbitraje, reconocimiento y gesti\u00f3n de errores para un bus compartido. RS485 define principalmente la se\u00f1alizaci\u00f3n el\u00e9ctrica utilizada para la comunicaci\u00f3n en serie.<\/p>\n\n\n\n
Esa distinci\u00f3n es importante cuando los ingenieros seleccionan una arquitectura de comunicaci\u00f3n para una bater\u00eda de robot.<\/p>\n\n\n\n
CAN como red<\/h3>\n\n\n\n CAN est\u00e1 dise\u00f1ado para m\u00faltiples dispositivos que se comunican en un bus compartido. Los mensajes se identifican mediante identificadores CAN y los intentos de transmisi\u00f3n simult\u00e1nea se resuelven mediante arbitraje basado en prioridades.<\/p>\n\n\n\n
Para la comunicaci\u00f3n de la bater\u00eda del robot, esta arquitectura puede admitir mensajes de estado regulares, l\u00edmites operativos, informaci\u00f3n de advertencia e informes de fallas basados \u200b\u200ben eventos. El actual dise\u00f1o de referencia BMS de rob\u00f3tica m\u00f3vil MR-BMS771 de NXP incluye dos buses CAN, lo que proporciona un ejemplo pr\u00e1ctico de CAN integrado directamente en una plataforma rob\u00f3tica de gesti\u00f3n de bater\u00edas.<\/p>\n\n\n\n
Sin embargo, un puerto CAN por s\u00ed solo no define el significado de los datos. Un BMS de bater\u00eda CAN y un controlador de robot a\u00fan necesitan velocidades de bits, identificadores, definiciones de carga \u00fatil, escalado, temporizaci\u00f3n de transmisi\u00f3n y l\u00f3gica de aplicaci\u00f3n compatibles.<\/p>\n\n\n\n
RS485 como interfaz f\u00edsica<\/h3>\n\n\n\n RS485 es una interfaz serie diferencial ampliamente utilizada en comunicaciones industriales multipunto. Es particularmente \u00fatil cuando el equipo ya utiliza redes seriales o cuando un controlador se comunica con m\u00faltiples dispositivos direccionados.<\/p>\n\n\n\n
Para una bater\u00eda de robot, el punto cr\u00edtico es que RS485 por s\u00ed solo no le dice al controlador qu\u00e9 significa cada byte. Un BMS de bater\u00eda RS485 todav\u00eda necesita un protocolo de aplicaci\u00f3n definido o una estructura de datos patentada.<\/p>\n\n\n\n
Esta distinci\u00f3n explica por qu\u00e9 RS485 y Modbus RTU frecuentemente aparecen juntos sin ser sin\u00f3nimos. La organizaci\u00f3n Modbus documenta las implementaciones de la l\u00ednea serie Modbus utilizando EIA\/TIA-485, mientras que el propio Modbus define el comportamiento de mensajer\u00eda de nivel superior.<\/p>\n\n\n\n
Por lo tanto, una especificaci\u00f3n de compra deber\u00eda decir algo m\u00e1s que \u201cSe requiere RS485\u201d. Debe identificar el protocolo real y el mapa de datos que espera el robot.<\/p>\n\n\n\n
CAN Arbitraje y Manejo de Errores<\/h3>\n\n\n\n CAN permite que los nodos transmitan sin esperar a que un controlador central asigne cada oportunidad de transmisi\u00f3n. Si dos nodos comienzan a transmitir al mismo tiempo, el arbitraje basado en los identificadores de mensajes determina qu\u00e9 trama contin\u00faa.<\/p>\n\n\n\n
CAN tambi\u00e9n incluye mecanismos para detectar errores de transmisi\u00f3n y gestionar nodos que generan errores repetidamente. Estas caracter\u00edsticas lo hacen adecuado para redes donde el bater\u00eda de robot<\/strong> debe intercambiar datos operativos frecuentes con otros controladores.<\/p>\n\n\n\nLa decisi\u00f3n de ingenier\u00eda no debe reducirse a una afirmaci\u00f3n gen\u00e9rica de que CAN es simplemente \u201cm\u00e1s r\u00e1pido\u201d. Lo que importa es si los mensajes de bater\u00eda requeridos se pueden entregar con la prioridad necesaria y el tiempo de actualizaci\u00f3n bajo la carga de bus esperada.<\/p>\n\n\n\n
Para un robot m\u00f3vil, un peque\u00f1o conjunto de mensajes de bater\u00eda documentados y priorizados correctamente suele ser m\u00e1s valioso que una velocidad de datos te\u00f3ricamente alta con un comportamiento de aplicaci\u00f3n mal definido.<\/p>\n\n\n\n
Modbus RTU sobre RS485<\/h3>\n\n\n\n Modbus RTU proporciona una estructura de mensajer\u00eda a nivel de aplicaci\u00f3n que puede funcionar a trav\u00e9s de un enlace serie RS485. El protocolo define c\u00f3mo los dispositivos direccionados intercambian solicitudes y respuestas, mientras que el mapa de registro espec\u00edfico del equipo identifica d\u00f3nde se almacenan los valores individuales.<\/p>\n\n\n\n
Para una bater\u00eda de robot, un mapa Modbus RTU puede contener registros de voltaje, corriente, SOC, temperatura, alarmas o l\u00edmites de funcionamiento del paquete. La interpretaci\u00f3n correcta requiere que el controlador conozca la direcci\u00f3n del registro, el formato de los datos, el factor de escala, el orden de los bytes, la direcci\u00f3n del dispositivo, la velocidad en baudios, la paridad y el comportamiento del tiempo de espera.<\/p>\n\n\n\n
Varias distinciones son importantes durante la integraci\u00f3n: RS485 no significa autom\u00e1ticamente Modbus RTU; dos dispositivos Modbus no utilizan autom\u00e1ticamente el mismo mapa de registro; un conector RJ45 no establece compatibilidad con Ethernet, CAN o RS485; y una conexi\u00f3n el\u00e9ctricamente v\u00e1lida no garantiza la compatibilidad a nivel de aplicaci\u00f3n.<\/p>\n\n\n\n
Estas comprobaciones evitan un error de integraci\u00f3n com\u00fan: ambas partes parecen admitir la misma tecnolog\u00eda de comunicaci\u00f3n, pero la bater\u00eda del robot y el controlador no pueden entender los datos del otro.<\/p>\n\n\n\n
D\u00f3nde encaja CANopen en un sistema de bater\u00eda de robot<\/h2>\n\n\n\n CANopen se encuentra encima de CAN en la pila de comunicaciones. No reemplaza al bus CAN. En cambio, CANopen define mecanismos estandarizados para organizar datos de dispositivos, transmitir informaci\u00f3n de procesos, acceder a par\u00e1metros de configuraci\u00f3n, controlar los estados de la red y monitorear a los participantes de la red.<\/p>\n\n\n\n
Por lo tanto, la implementaci\u00f3n de una bater\u00eda CANopen requiere m\u00e1s que un transceptor CAN o un conector CAN. El BMS tiene que implementar las funciones CANopen requeridas por el controlador host.<\/p>\n\n\n\n
CAN no es CANopen<\/h3>\n\n\n\n CAN proporciona el mecanismo de comunicaci\u00f3n de red subyacente. CANopen agrega la estructura de capa superior que determina c\u00f3mo los dispositivos basados \u200b\u200ben CAN organizan e intercambian datos de aplicaciones.<\/p>\n\n\n\n
CAN en Automatizaci\u00f3n, o CiA, describe un dispositivo CANopen con una pila de protocolos CANopen, software de aplicaci\u00f3n y un diccionario de objetos que conecta el sistema de comunicaci\u00f3n con los par\u00e1metros de la aplicaci\u00f3n.<\/p>\n\n\n\n
Esto hace que una regla de contrataci\u00f3n sea especialmente importante:<\/p>\n\n\n\n
La compatibilidad con CAN no significa autom\u00e1ticamente compatibilidad con CANopen.<\/strong><\/p>\n\n\n\nSi un controlador AMR requiere una bater\u00eda CANopen, la especificaci\u00f3n debe identificar la funcionalidad CANopen y las asignaciones de datos esperadas por el controlador. No basta con solicitar un puerto CAN.<\/p>\n\n\n\n
El diccionario de objetos CANopen<\/h3>\n\n\n\n El diccionario de objetos es el modelo de datos estructurados utilizado por los dispositivos CANopen. CiA especifica que los par\u00e1metros de comunicaci\u00f3n y aplicaci\u00f3n se organizan a trav\u00e9s de entradas de diccionario de objetos indexados, con valores de \u00edndice y sub\u00edndice que proporcionan direcciones definidas para los datos.<\/p>\n\n\n\n
En una integraci\u00f3n de bater\u00eda CANopen, esta estructura puede proporcionar una forma consistente de exponer el estado de la bater\u00eda, los par\u00e1metros de configuraci\u00f3n y la informaci\u00f3n de diagn\u00f3stico. Los objetos reales de la bater\u00eda a\u00fan deben coincidir con los requisitos del controlador y cualquier perfil aplicable o especificaci\u00f3n del proyecto.<\/p>\n\n\n\n
La ventaja pr\u00e1ctica es la claridad. Los ingenieros no tienen que tratar cada trama CAN como un mensaje propietario aislado cuando se utiliza una implementaci\u00f3n CANopen definida. Pueden trabajar con objetos documentados y servicios de comunicaci\u00f3n.<\/p>\n\n\n\n
PDO, SDO y diagn\u00f3stico<\/h3>\n\n\n\n CANopen separa diferentes tareas de comunicaci\u00f3n a trav\u00e9s de servicios definidos. Los objetos de datos de proceso, o PDO, son adecuados para procesar la informaci\u00f3n intercambiada durante la operaci\u00f3n. Los objetos de datos de servicio, o SDO, brindan acceso a entradas en el diccionario de objetos para funciones de configuraci\u00f3n y servicio.<\/p>\n\n\n\n
CANopen tambi\u00e9n proporciona mecanismos para informar errores y supervisar nodos. La documentaci\u00f3n de CiA identifica las funciones PDO, SDO, emergencia, latido y administraci\u00f3n de red como partes de la arquitectura de comunicaci\u00f3n CANopen.<\/p>\n\n\n\n
Para una bater\u00eda CANopen, los valores operativos requeridos con frecuencia se pueden asignar a la comunicaci\u00f3n PDO, mientras que el acceso SDO puede respaldar la puesta en servicio o el diagn\u00f3stico. El mapeo exacto deber\u00eda acordarse antes de la integraci\u00f3n, en lugar de asumirse.<\/p>\n\n\n\n
Esta es tambi\u00e9n la raz\u00f3n por la que una bater\u00eda de robot que se comunica exitosamente a trav\u00e9s de CAN propietario no puede considerarse autom\u00e1ticamente compatible con CANopen.<\/p>\n\n\n\n
Gesti\u00f3n de red y latidos<\/h3>\n\n\n\n CANopen Network Management, o NMT, define los estados de comunicaci\u00f3n de un dispositivo. CiA identifica los estados de inicializaci\u00f3n, preoperacional, operativo y detenido dentro de la m\u00e1quina de estados CANopen NMT. La comunicaci\u00f3n PDO est\u00e1 disponible en el estado operativo, mientras que la comunicaci\u00f3n SDO se puede utilizar en el estado preoperativo.<\/p>\n\n\n\n
Para la comunicaci\u00f3n de la bater\u00eda del robot, estos estados ayudan a definir el comportamiento durante el inicio, la puesta en servicio, el funcionamiento normal, el apagado y la recuperaci\u00f3n.<\/p>\n\n\n\n
Los mecanismos de latido proporcionan otra funci\u00f3n \u00fatil al permitir que el controlador determine si un nodo esperado permanece presente en la red. Por lo tanto, una especificaci\u00f3n de bater\u00eda CANopen deber\u00eda cubrir m\u00e1s que los campos de datos de la bater\u00eda. El estado de inicio, el tiempo de los latidos, la respuesta del tiempo de espera y el comportamiento de recuperaci\u00f3n tambi\u00e9n pueden ser importantes para el robot.<\/p>\n\n\n\n
Elegir la interfaz adecuada para AGV y AMR<\/h2>\n\n\n\n El m\u00e9todo de comunicaci\u00f3n correcto es aquel que coincide con la arquitectura de control existente del robot y proporciona la informaci\u00f3n de la bater\u00eda requerida por ese sistema.<\/p>\n\n\n\n
Por lo tanto, la selecci\u00f3n del protocolo debe comenzar con el controlador host y la arquitectura de carga en lugar de con una preferencia gen\u00e9rica por CAN o RS485.<\/p>\n\n\n\n
Haga coincidir la red de robots existente<\/h3>\n\n\n\n El primer paso es determinar exactamente qu\u00e9 espera el controlador del robot. Un controlador puede utilizar tramas CAN patentadas, CANopen, RS485 con Modbus RTU u otro protocolo documentado.<\/p>\n\n\n\nArquitectura existente<\/th> Requisito apropiado de bater\u00eda de robot<\/th><\/tr><\/thead> Controlador CAN propietario<\/td> Bater\u00eda CAN BMS con velocidad de bits y mapa de mensajes coincidentes<\/td><\/tr> Controlador CANopen<\/td> BMS que implementa los objetos CANopen requeridos y el comportamiento de la red<\/td><\/tr> PLC o controlador mediante Modbus RTU<\/td> BMS de bater\u00eda RS485 con configuraci\u00f3n de serie coincidente y mapa de registro<\/td><\/tr> Redes separadas de control y diagn\u00f3stico.<\/td> Definir qu\u00e9 conexi\u00f3n lleva control de bater\u00eda y cu\u00e1l lleva datos de servicio<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa bater\u00eda del robot debe adaptarse a ese requisito de red. Elegir un paquete porque su conector o etiqueta de puerto le resulta familiar invierte el proceso de ingenier\u00eda correcto.<\/p>\n\n\n\n
Definir los datos de bater\u00eda requeridos<\/h3>\n\n\n\n Antes de solicitar un paquete personalizado, los ingenieros deben crear una matriz de comunicaci\u00f3n que separe los datos necesarios para la operaci\u00f3n de la informaci\u00f3n destinada principalmente al diagn\u00f3stico o mantenimiento.<\/p>\n\n\n\n
Para muchos proyectos AGV y AMR, el requerido bater\u00eda de robot<\/strong> los datos incluyen:<\/p>\n\n\n\n\nVoltaje y corriente del paquete<\/li>\n\n\n\n SOC y SOH<\/li>\n\n\n\n Temperatura de la bater\u00eda<\/li>\n\n\n\n L\u00edmites de carga y descarga<\/li>\n\n\n\n Estados de advertencia y protecci\u00f3n<\/li>\n\n\n\n Estado de carga y estado BMS<\/li>\n\n\n\n Identidad del dispositivo o direcci\u00f3n de red<\/li>\n\n\n\n Estado del contactor o MOSFET cuando lo requiera el sistema<\/li>\n<\/ul>\n\n\n\nEl proyecto tambi\u00e9n debe definir la direcci\u00f3n de los datos. Parte de la informaci\u00f3n se transmite desde el BMS de la bater\u00eda AMR al host, mientras que otras arquitecturas pueden requerir comandos de control, reconocimientos o mensajes de configuraci\u00f3n del controlador.<\/p>\n\n\n\n
Este paso determina lo que realmente debe lograr la interfaz.<\/p>\n\n\n\n
Verifique el tiempo y la respuesta a fallas<\/h3>\n\n\n\n Una especificaci\u00f3n de comunicaci\u00f3n completa necesita requisitos de temporizaci\u00f3n adem\u00e1s de definiciones de datos.<\/p>\n\n\n\n
Los ingenieros deben determinar con qu\u00e9 frecuencia se debe actualizar la informaci\u00f3n cr\u00edtica de la bater\u00eda del robot, cu\u00e1nto tiempo espera el controlador antes de declarar el BMS fuera de l\u00ednea y qu\u00e9 respuesta sigue a un tiempo de espera de comunicaci\u00f3n. Las prioridades de los mensajes CAN o los intervalos de sondeo RS485 deben reflejar la importancia de los datos que se transfieren.<\/p>\n\n\n\n
La recuperaci\u00f3n de fallos tambi\u00e9n necesita un comportamiento definido. El sistema debe establecer si la comunicaci\u00f3n se reanuda autom\u00e1ticamente despu\u00e9s de un evento transitorio, si el BMS requiere un reinicio y si el robot puede reanudar la operaci\u00f3n inmediatamente o debe verificar primero el estado de la bater\u00eda.<\/p>\n\n\n\n
Estas decisiones son espec\u00edficas de la aplicaci\u00f3n. Deben documentarse durante la integraci\u00f3n en lugar de inferirse de la interfaz de comunicaci\u00f3n.<\/p>\n\n\n\n
Planificar la comunicaci\u00f3n del muelle de carga<\/h3>\n\n\n\n Un AGV o AMR cargado autom\u00e1ticamente necesita que la base de carga se considere parte del bater\u00eda de robot<\/strong> arquitectura.<\/p>\n\n\n\nEs posible que el sistema de carga necesite coordinar el permiso de carga, el voltaje de la bater\u00eda, los l\u00edmites de corriente, el estado de temperatura, el estado de carga, la finalizaci\u00f3n y las condiciones de falla. Los contactos de carga f\u00edsicos o un receptor de energ\u00eda sin contacto proporcionan la ruta de energ\u00eda, pero no definen el comportamiento de la comunicaci\u00f3n.<\/p>\n\n\n\n
El robot tambi\u00e9n necesita una secuencia clara para detectar la base, permitir la carga, responder a los l\u00edmites del BMS, completar el proceso de carga y volver a funcionar.<\/p>\n\n\n\n
La gu\u00eda de integraci\u00f3n AMR actual de MANLY Battery identifica la comunicaci\u00f3n CAN o RS485, el monitoreo de corriente y temperatura, el dise\u00f1o del conector y el cableado espec\u00edfico de la aplicaci\u00f3n como factores a coordinar al integrar una bater\u00eda AMR, un BMS y una base de carga.<\/p>\n\n\n\n
Por lo tanto, para las flotas aut\u00f3nomas, la comunicaci\u00f3n de carga debe dise\u00f1arse al mismo tiempo que la bater\u00eda del robot y el BMS y no despu\u00e9s de que el paquete ya est\u00e9 finalizado.<\/p>\n\n\n\n
Considere las necesidades de diagn\u00f3stico de la flota<\/h3>\n\n\n\n Los datos de control de tr\u00e1fico y mantenimiento no siempre necesitan utilizar la misma ruta de comunicaci\u00f3n. Algunos robots colocan datos de la bater\u00eda urgentes en la red CAN primaria mientras usan una interfaz separada para la puesta en servicio, el servicio o diagn\u00f3sticos m\u00e1s profundos.<\/p>\n\n\n\n
Lo que importa es que la arquitectura del diagn\u00f3stico sea deliberada.<\/p>\n\n\n\n
Para flotas grandes, las definiciones consistentes de datos de bater\u00edas de robots pueden simplificar la resoluci\u00f3n de problemas en muchos veh\u00edculos. Los c\u00f3digos de falla, las unidades, la escala, las versiones de firmware, los estados de comunicaci\u00f3n y los registros de mantenimiento deben tener significados repetibles de un robot a otro.<\/p>\n\n\n\n
Esto puede resultar particularmente valioso cuando se utiliza software de flota para distinguir eventos relacionados con la energ\u00eda de fallas de BMS, fallas del cargador o fallas de comunicaci\u00f3n.<\/p>\n\n\n\n
Qu\u00e9 preguntarle a un fabricante de bater\u00edas antes de la integraci\u00f3n<\/h2>\n\n\n\n A fabricante de bater\u00edas<\/a><\/strong> deber\u00eda poder analizar la comunicaci\u00f3n BMS con el mismo detalle de ingenier\u00eda utilizado para los requisitos de voltaje, capacidad, corriente, dimensiones y conectores del paquete.<\/p>\n\n\n\n\u201cCAN disponible\u201d o \u201cRS485 disponible\u201d es \u00fatil para la evaluaci\u00f3n inicial, pero la bater\u00eda de un robot de producci\u00f3n requiere una especificaci\u00f3n de comunicaci\u00f3n m\u00e1s completa.<\/p>\n\n\n\n
Mapa de protocolo y mensajes<\/h3>\n\n\n\n Para la integraci\u00f3n CAN, solicite el protocolo de aplicaci\u00f3n, los identificadores CAN, las definiciones de carga \u00fatil, la escala, la direcci\u00f3n del mensaje, el tiempo de transmisi\u00f3n y el comportamiento del tiempo de espera.<\/p>\n\n\n\n
Para una bater\u00eda CANopen, defina las entradas requeridas del diccionario de objetos, asignaciones de PDO, acceso a SDO, comportamiento NMT, requisitos de latido y funciones espec\u00edficas del controlador.<\/p>\n\n\n\n
Si el proyecto utiliza comunicaci\u00f3n CAN espec\u00edfica del fabricante, la definici\u00f3n del mensaje deber\u00eda estar disponible con suficiente antelaci\u00f3n para el desarrollo del controlador y las pruebas en banco. El equipo de software no deber\u00eda tener que aplicar ingenier\u00eda inversa al bater\u00eda de robot<\/strong> despu\u00e9s de que llegue el hardware prototipo.<\/p>\n\n\n\nVelocidad en baudios e ID de nodo<\/h3>\n\n\n\n Ambos lados de la conexi\u00f3n deben utilizar configuraciones de red compatibles.<\/p>\n\n\n\n
Para CAN, confirme la velocidad de bits de CAN y el identificador relevante o la configuraci\u00f3n del nodo. Para CANopen, defina tambi\u00e9n los ID de nodo y el comportamiento de administraci\u00f3n de red requerido. Para un BMS de bater\u00eda RS485, confirme la velocidad en baudios, la paridad, los bits de parada, el direccionamiento y el comportamiento de respuesta o sondeo esperado.<\/p>\n\n\n\n
Estos par\u00e1metros deben registrarse en la especificaci\u00f3n de comunicaci\u00f3n del proyecto y controlarse como cualquier otro requisito de interfaz a nivel del sistema.<\/p>\n\n\n\n
Registro Escalado de mapas y datos<\/h3>\n\n\n\n Una conexi\u00f3n RS485 mediante Modbus RTU necesita un mapa de registros completo. Cada valor requerido debe tener una direcci\u00f3n definida, tipo de datos, factor de escala, unidad de ingenier\u00eda y m\u00e9todo de acceso.<\/p>\n\n\n\n
Por ejemplo, un valor transmitido no se puede interpretar correctamente hasta que el controlador sepa si representa voltios, milivoltios, d\u00e9cimas de voltio, corriente con signo u otra codificaci\u00f3n.<\/p>\n\n\n\n
El mismo principio se aplica a CAN. Recibir una trama CAN v\u00e1lida no prueba que el bater\u00eda de robot<\/strong> los datos han sido interpretados correctamente. El orden de los bytes, las definiciones de bits, la escala, los valores con signo y los indicadores de estado a\u00fan deben coincidir.<\/p>\n\n\n\nTerminaci\u00f3n, distribuci\u00f3n de pines y conectores<\/h3>\n\n\n\n La documentaci\u00f3n el\u00e9ctrica debe identificar cada pin de comunicaci\u00f3n requerido, incluidos CAN-H, CAN-L, RS485-A, RS485-B, se\u00f1al de tierra, l\u00edneas de estela, blindaje u otros conductores espec\u00edficos del proyecto.<\/p>\n\n\n\n
La terminaci\u00f3n tambi\u00e9n debe coincidir con la topolog\u00eda de red seleccionada. Los ingenieros deben verificar si la terminaci\u00f3n est\u00e1 dentro de la bater\u00eda del robot, instalada en otro lugar del robot, configurable u omitida.<\/p>\n\n\n\n
La forma del conector nunca debe utilizarse como sustituto de esta documentaci\u00f3n. Un conector estilo RJ45, por ejemplo, no indica autom\u00e1ticamente Ethernet y no establece una distribuci\u00f3n de pines CAN o RS485 estandarizada.<\/p>\n\n\n\n
Por lo tanto, el dise\u00f1o del cable y del conector pertenece a las especificaciones de comunicaci\u00f3n, no s\u00f3lo al dibujo mec\u00e1nico.<\/p>\n\n\n\n
Requisitos de comunicaci\u00f3n del cargador<\/h3>\n\n\n\n La bater\u00eda del robot y el cargador deben dise\u00f1arse como un sistema coordinado cuando el proceso de carga requiere comunicaci\u00f3n.<\/p>\n\n\n\n
La especificaci\u00f3n debe definir si el cargador utiliza configuraciones el\u00e9ctricas fijas o recibe l\u00edmites din\u00e1micos del BMS o del controlador del veh\u00edculo. Tambi\u00e9n debe documentar la l\u00f3gica de habilitaci\u00f3n de carga, los l\u00edmites de corriente y voltaje, el comportamiento t\u00e9rmico, el estado de carga, la finalizaci\u00f3n de la carga, la respuesta a fallas, el protocolo de enlace de la base y la recuperaci\u00f3n despu\u00e9s de una carga interrumpida.<\/p>\n\n\n\n
Para un AGV o AMR que depende de la carga desatendida, estas funciones pueden afectar directamente la confiabilidad con la que el robot vuelve a funcionar despu\u00e9s de llegar al muelle.<\/p>\n\n\n\n
Opciones de comunicaci\u00f3n de la bater\u00eda MANLY<\/h3>\n\n\n\n En MANLY Battery, los proyectos de robots y bater\u00edas industriales se pueden desarrollar en torno a los requisitos de comunicaci\u00f3n de la aplicaci\u00f3n en lugar de tratar la interfaz como un complemento aislado.<\/p>\n\n\n\n
La bater\u00eda del robot MANLY de 24 V y 50 Ah es un paquete LiFePO4 con una potencia nominal de 24 V, con un voltaje de bater\u00eda real de 25,6 V y 1280 Wh de energ\u00eda nominal. Su especificaci\u00f3n actual proporciona comunicaci\u00f3n opcional RS485, RS232 o CANBus. Las dimensiones, la carcasa, el conector, la caja y el cableado tambi\u00e9n se pueden configurar para los requisitos de OEM\/ODM.<\/p>\n\n\n\n
Para robots industriales que requieren mayor capacidad a bordo, la bater\u00eda de robot MANLY 48V 100Ah proporciona 100Ah de capacidad y 4.800Wh de energ\u00eda nominal. Tambi\u00e9n admite comunicaci\u00f3n opcional RS485, RS232 o CANBus, con dimensiones, carcasa, conectores y cableado personalizables.<\/p>\n\n\n\nBater\u00eda de robot MANLY<\/th> Comunicaci\u00f3n<\/th> Enfoque de integraci\u00f3n<\/th><\/tr><\/thead> Bater\u00eda de robot LiFePO4 de 24V 50Ah<\/td> RS485, RS232, CANBus opcionales<\/td> Proyectos de robots y AGV que requieren comunicaci\u00f3n BMS configurable, conectores y dimensiones del paquete<\/td><\/tr> Bater\u00eda de robot industrial de 48V 100Ah<\/td> RS485, RS232, CANBus opcionales<\/td> Aplicaciones de robots industriales de mayor capacidad que requieren integraci\u00f3n coordinada de BMS, controlador, cargador y paquete<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSi un proyecto requiere espec\u00edficamente comunicaci\u00f3n de bater\u00eda CANopen, ese requisito debe definirse durante la revisi\u00f3n de ingenier\u00eda. La disponibilidad de CANBus por s\u00ed sola no debe considerarse como una confirmaci\u00f3n de la compatibilidad con CANopen.<\/p>\n\n\n\n
El equipo del proyecto debe proporcionar el mapeo de objetos CANopen requerido, la configuraci\u00f3n de red, el comportamiento del controlador y otros requisitos de protocolo para que la implementaci\u00f3n pueda evaluarse antes de comenzar. bater\u00eda de robot<\/strong> el dise\u00f1o est\u00e1 finalizado.<\/p>\n\n\n\nPara proyectos CAN o RS485, se aplica el mismo principio. Proporcionar la especificaci\u00f3n del controlador, el mapa de mensajes o registros, la velocidad de comunicaci\u00f3n, la configuraci\u00f3n de pines, la arquitectura del cargador, el voltaje, la capacidad, los requisitos actuales y el comportamiento de falla esperado le brinda al fabricante de bater\u00edas un objetivo de integraci\u00f3n mucho m\u00e1s claro.<\/p>\n\n\n\n
El derecho comunicaci\u00f3n de la bater\u00eda del robot<\/strong> Por lo tanto, el m\u00e9todo no se determina eligiendo CAN, RS485 o CANopen de forma aislada. Est\u00e1 determinado por si el BMS, el controlador del robot, el cargador, el cableado, el protocolo y la l\u00f3gica operativa se han dise\u00f1ado para funcionar juntos como un solo sistema.<\/p>\n\n\n\n
![\"Bater\u00eda](\"https:\/\/manlybattery.com\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs.webp\")
<\/a><\/figure>\n\n\n\n![\"Bater\u00eda](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs-300x200.webp\")
![\"Los](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Data-centers-plan-a-lithium-battery-replacement-for-aging-ups-battery-banks-300x144.webp\")
![\"Soluci\u00f3n](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Backup-battery-solution-300x300.webp\")