batterie de robot<\/a><\/strong> peut \u00e9galement signaler les temp\u00e9ratures, le courant, les \u00e9tats d'avertissement, les conditions de protection et les limites de charge ou de d\u00e9charge autoris\u00e9es. Lorsque les conditions de fonctionnement changent, ces valeurs fournissent au contr\u00f4leur du v\u00e9hicule des informations qu'il peut utiliser avant que le BMS n'atteigne un \u00e9tat de protection strict.<\/p>\n\n\n\nCela rend la communication avec la batterie du robot utile \u00e0 la fois pour le fonctionnement et la maintenance imm\u00e9diats. Le logiciel de flotte peut utiliser des informations coh\u00e9rentes sur l'\u00e9tat et les d\u00e9fauts pour distinguer une condition de faible consommation d'\u00e9nergie d'un \u00e9v\u00e9nement thermique, d'un \u00e9v\u00e9nement de protection ou d'un d\u00e9faut de communication.<\/p>\n\n\n\n
Poign\u00e9es de main du contr\u00f4leur et du chargeur<\/h3>\n\n\n\n Le contr\u00f4leur du v\u00e9hicule et le chargeur ne n\u00e9cessitent pas n\u00e9cessairement des donn\u00e9es de batterie identiques. Pendant le mouvement, le contr\u00f4leur peut donner la priorit\u00e9 au SOC, \u00e0 la tension, au courant, \u00e0 la temp\u00e9rature, aux avertissements et aux limites de d\u00e9charge. Pendant la charge, le syst\u00e8me peut \u00e9galement avoir besoin d'une autorisation de charge, de limites de courant de charge, de limites de tension, d'informations sur l'\u00e9tat de la temp\u00e9rature et sur l'\u00e9tat de charge.<\/p>\n\n\n\n
C'est pourquoi la sp\u00e9cification d'un BMS de batterie CAN ou d'un BMS de batterie RS485 n'est que la premi\u00e8re \u00e9tape. Deux appareils peuvent partager la m\u00eame interface \u00e9lectrique tout en utilisant des identifiants, des registres, des facteurs d'\u00e9chelle, des intervalles de mise \u00e0 jour ou une logique de contr\u00f4le diff\u00e9rents.<\/p>\n\n\n\n
La recharge automatique rend la distinction particuli\u00e8rement importante. Lorsqu'un AGV ou un AMR s'amarre sans intervention de l'op\u00e9rateur, la batterie, le chargeur et le contr\u00f4leur du robot doivent avoir un comportement d\u00e9fini pour l'autorisation de charge, les limites de fonctionnement, la gestion des pannes, l'ach\u00e8vement de la charge et la remise en service.<\/p>\n\n\n\n
Pourquoi la communication affecte la disponibilit\u00e9<\/h3>\n\n\n\n Une communication utile avec la batterie permet au robot de r\u00e9agir aux conditions de la batterie avant qu'un arr\u00eat brutal ne devienne la seule r\u00e9ponse disponible. Un faible SOC peut lancer une t\u00e2che de charge, une condition de temp\u00e9rature peut affecter le comportement de charge et un d\u00e9faut signal\u00e9 peut placer le v\u00e9hicule dans un \u00e9tat de service d\u00e9fini.<\/p>\n\n\n\n
Pour les flottes, des donn\u00e9es coh\u00e9rentes sur les batteries des robots am\u00e9liorent \u00e9galement le d\u00e9pannage. Les \u00e9quipes de maintenance peuvent examiner les \u00e9tats de fonctionnement et les alarmes au lieu de traiter chaque perte de propulsion ou interruption de charge comme le m\u00eame probl\u00e8me.<\/p>\n\n\n\n
L\u2019avantage n\u2019est pas simplement davantage de t\u00e9l\u00e9m\u00e9trie. La v\u00e9ritable valeur r\u00e9side dans le fait de faire de la batterie une partie int\u00e9gr\u00e9e et interpr\u00e9table de l\u2019architecture de contr\u00f4le du robot.<\/p>\n\n\n\n
CAN vs RS485 : en quoi ils diff\u00e8rent dans les syst\u00e8mes robotis\u00e9s<\/h2>\n\n\n\n CAN et RS485 sont tous deux courants dans les syst\u00e8mes industriels, mais ils r\u00e9solvent diff\u00e9rentes parties du probl\u00e8me de communication. CAN fournit des m\u00e9canismes de tramage de messages, d'arbitrage, d'accus\u00e9 de r\u00e9ception et de gestion des erreurs pour un bus partag\u00e9. RS485 d\u00e9finit principalement la signalisation \u00e9lectrique utilis\u00e9e pour la communication s\u00e9rie.<\/p>\n\n\n\n
Cette distinction est importante lorsque les ing\u00e9nieurs s\u00e9lectionnent une architecture de communication pour une batterie de robot.<\/p>\n\n\n\n
CAN en tant que r\u00e9seau<\/h3>\n\n\n\n CAN est con\u00e7u pour plusieurs appareils communiquant sur un bus partag\u00e9. Les messages sont identifi\u00e9s par des identifiants CAN et les tentatives de transmission simultan\u00e9es sont r\u00e9solues gr\u00e2ce \u00e0 un arbitrage bas\u00e9 sur les priorit\u00e9s.<\/p>\n\n\n\n
Pour la communication avec la batterie du robot, cette architecture peut prendre en charge des messages d'\u00e9tat r\u00e9guliers, des limites de fonctionnement, des informations d'avertissement et des rapports de pannes d\u00e9clench\u00e9s par des \u00e9v\u00e9nements. La conception de r\u00e9f\u00e9rence actuelle du BMS de robotique mobile MR-BMS771 de NXP comprend deux bus CAN, fournissant un exemple pratique d'int\u00e9gration directe de CAN dans une plate-forme robotique de gestion de batterie.<\/p>\n\n\n\n
Un port CAN \u00e0 lui seul ne d\u00e9finit cependant pas la signification des donn\u00e9es. Un BMS de batterie CAN et un contr\u00f4leur de robot ont toujours besoin de d\u00e9bits binaires, d'identifiants, de d\u00e9finitions de charge utile, de mise \u00e0 l'\u00e9chelle, de synchronisation de transmission et de logique d'application compatibles.<\/p>\n\n\n\n
RS485 comme interface physique<\/h3>\n\n\n\n RS485 est une interface s\u00e9rie diff\u00e9rentielle largement utilis\u00e9e dans la communication multipoint industrielle. Il est particuli\u00e8rement utile lorsque l'\u00e9quipement utilise d\u00e9j\u00e0 des r\u00e9seaux s\u00e9rie ou lorsqu'un contr\u00f4leur communique avec plusieurs appareils adress\u00e9s.<\/p>\n\n\n\n
Pour une batterie de robot, le point critique est que le RS485 \u00e0 lui seul n'indique pas au contr\u00f4leur la signification d'un octet. Un BMS de batterie RS485 n\u00e9cessite toujours un protocole d'application d\u00e9fini ou une structure de donn\u00e9es propri\u00e9taire.<\/p>\n\n\n\n
Cette distinction explique pourquoi RS485 et Modbus RTU apparaissent fr\u00e9quemment ensemble sans \u00eatre synonymes. L'organisation Modbus documente les impl\u00e9mentations de ligne s\u00e9rie Modbus \u00e0 l'aide d'EIA\/TIA-485, tandis que Modbus d\u00e9finit lui-m\u00eame le comportement de messagerie de niveau sup\u00e9rieur.<\/p>\n\n\n\n
Une sp\u00e9cification d\u2019achat devrait donc dire plus que \u201c RS485 requis \u201d. Il doit identifier le protocole r\u00e9el et la carte de donn\u00e9es attendus par le robot.<\/p>\n\n\n\n
Arbitrage CAN et gestion des erreurs<\/h3>\n\n\n\n CAN permet aux n\u0153uds de transmettre sans attendre qu'un contr\u00f4leur central attribue chaque opportunit\u00e9 de transmission. Si deux n\u0153uds commencent \u00e0 transmettre en m\u00eame temps, l'arbitrage bas\u00e9 sur les identifiants de message d\u00e9termine quelle trame continue.<\/p>\n\n\n\n
CAN comprend \u00e9galement des m\u00e9canismes pour d\u00e9tecter les erreurs de transmission et g\u00e9rer les n\u0153uds qui g\u00e9n\u00e8rent des erreurs de mani\u00e8re r\u00e9p\u00e9t\u00e9e. Ces caract\u00e9ristiques le rendent adapt\u00e9 aux r\u00e9seaux o\u00f9 le batterie de robot<\/strong> doit \u00e9changer fr\u00e9quemment des donn\u00e9es d\u2019exploitation avec d\u2019autres contr\u00f4leurs.<\/p>\n\n\n\nLa d\u00e9cision technique ne doit pas \u00eatre r\u00e9duite \u00e0 une affirmation g\u00e9n\u00e9rique selon laquelle CAN est simplement \u201c plus rapide \u201d. Ce qui compte est de savoir si les messages de batterie requis peuvent \u00eatre transmis avec la priorit\u00e9 et le timing de mise \u00e0 jour n\u00e9cessaires sous la charge de bus attendue.<\/p>\n\n\n\n
Pour un robot mobile, un petit ensemble de messages de batterie correctement hi\u00e9rarchis\u00e9s et document\u00e9s est souvent plus pr\u00e9cieux qu'un d\u00e9bit de donn\u00e9es th\u00e9oriquement \u00e9lev\u00e9 avec un comportement d'application mal d\u00e9fini.<\/p>\n\n\n\n
Modbus RTU sur RS485<\/h3>\n\n\n\n Modbus RTU fournit une structure de messagerie au niveau de l'application qui peut fonctionner sur une liaison s\u00e9rie RS485. Le protocole d\u00e9finit la mani\u00e8re dont les appareils adress\u00e9s \u00e9changent des demandes et des r\u00e9ponses, tandis que la carte de registre sp\u00e9cifique \u00e0 l'\u00e9quipement identifie l'emplacement de stockage des valeurs individuelles.<\/p>\n\n\n\n
Pour une batterie de robot, une carte Modbus RTU peut contenir des registres pour la tension, le courant, le SOC, la temp\u00e9rature, les alarmes ou les limites de fonctionnement du pack. Une interpr\u00e9tation correcte n\u00e9cessite que le contr\u00f4leur connaisse l'adresse du registre, le format des donn\u00e9es, le facteur de mise \u00e0 l'\u00e9chelle, l'ordre des octets, l'adresse du p\u00e9riph\u00e9rique, le d\u00e9bit en bauds, la parit\u00e9 et le comportement du d\u00e9lai d'attente.<\/p>\n\n\n\n
Plusieurs distinctions sont importantes lors de l'int\u00e9gration : RS485 ne signifie pas automatiquement Modbus RTU ; deux appareils Modbus n'utilisent pas automatiquement la m\u00eame carte de registre ; un connecteur RJ45 n'\u00e9tablit pas la compatibilit\u00e9 Ethernet, CAN ou RS485 ; et une connexion \u00e9lectriquement valide ne garantit pas la compatibilit\u00e9 au niveau de l'application.<\/p>\n\n\n\n
Ces contr\u00f4les \u00e9vitent un \u00e9chec d\u2019int\u00e9gration courant : les deux parties semblent prendre en charge la m\u00eame technologie de communication, mais la batterie du robot et le contr\u00f4leur ne peuvent pas comprendre les donn\u00e9es de chacun.<\/p>\n\n\n\n
O\u00f9 CANopen s'int\u00e8gre dans un syst\u00e8me de batterie de robot<\/h2>\n\n\n\n CANopen se situe au-dessus de CAN dans la pile de communication. Il ne remplace pas le bus CAN. Au lieu de cela, CANopen d\u00e9finit des m\u00e9canismes standardis\u00e9s pour organiser les donn\u00e9es des appareils, transmettre les informations sur les processus, acc\u00e9der aux param\u00e8tres de configuration, contr\u00f4ler les \u00e9tats du r\u00e9seau et surveiller les participants au r\u00e9seau.<\/p>\n\n\n\n
Une impl\u00e9mentation de batterie CANopen n\u00e9cessite donc plus qu'un \u00e9metteur-r\u00e9cepteur CAN ou un connecteur CAN. Le BMS doit impl\u00e9menter les fonctions CANopen requises par le contr\u00f4leur h\u00f4te.<\/p>\n\n\n\n
CAN n'est pas CANopen<\/h3>\n\n\n\n CAN fournit le m\u00e9canisme de communication r\u00e9seau sous-jacent. CANopen ajoute la structure de couche sup\u00e9rieure qui d\u00e9termine la mani\u00e8re dont les appareils bas\u00e9s sur CAN organisent et \u00e9changent les donn\u00e9es d'application.<\/p>\n\n\n\n
CAN in Automation, ou CiA, d\u00e9crit un appareil CANopen comme dot\u00e9 d'une pile de protocoles CANopen, d'un logiciel d'application et d'un dictionnaire d'objets qui connecte le syst\u00e8me de communication aux param\u00e8tres d'application.<\/p>\n\n\n\n
Cela rend une r\u00e8gle de passation des march\u00e9s particuli\u00e8rement importante :<\/p>\n\n\n\n
La prise en charge CAN ne signifie pas automatiquement la prise en charge CANopen.<\/strong><\/p>\n\n\n\nSi un contr\u00f4leur AMR n\u00e9cessite une batterie CANopen, la sp\u00e9cification doit identifier la fonctionnalit\u00e9 CANopen et les mappages de donn\u00e9es attendus par le contr\u00f4leur. Il ne suffit pas de demander simplement un port CAN.<\/p>\n\n\n\n
Le dictionnaire d'objets CANopen<\/h3>\n\n\n\n Le dictionnaire d'objets est le mod\u00e8le de donn\u00e9es structur\u00e9es utilis\u00e9 par les appareils CANopen. CiA sp\u00e9cifie que les param\u00e8tres de communication et d'application sont organis\u00e9s via des entr\u00e9es de dictionnaire d'objets index\u00e9es, avec des valeurs d'index et de sous-index fournissant des adresses d\u00e9finies pour les donn\u00e9es.<\/p>\n\n\n\n
Dans une int\u00e9gration de batterie CANopen, cette structure peut fournir un moyen coh\u00e9rent d'exposer l'\u00e9tat de la batterie, les param\u00e8tres de configuration et les informations de diagnostic. Les objets de batterie r\u00e9els doivent toujours correspondre aux exigences du contr\u00f4leur et \u00e0 tout profil ou sp\u00e9cification de projet applicable.<\/p>\n\n\n\n
L'avantage pratique est la clart\u00e9. Les ing\u00e9nieurs n'ont pas besoin de traiter chaque trame CAN comme un message propri\u00e9taire isol\u00e9 lorsqu'une impl\u00e9mentation CANopen d\u00e9finie est utilis\u00e9e. Ils peuvent travailler avec des objets document\u00e9s et des services de communication.<\/p>\n\n\n\n
PDO, SDO et diagnostics<\/h3>\n\n\n\n CANopen s\u00e9pare les diff\u00e9rentes t\u00e2ches de communication via des services d\u00e9finis. Les objets de donn\u00e9es de processus, ou PDO, sont adapt\u00e9s au traitement des informations \u00e9chang\u00e9es pendant le fonctionnement. Les objets de donn\u00e9es de service, ou SDO, permettent d'acc\u00e9der aux entr\u00e9es du dictionnaire d'objets pour les fonctions de configuration et de service.<\/p>\n\n\n\n
CANopen fournit \u00e9galement des m\u00e9canismes de rapport d'erreurs et de supervision des n\u0153uds. La documentation CiA identifie les fonctions PDO, SDO, d'urgence, de battement de c\u0153ur et de gestion de r\u00e9seau comme faisant partie de l'architecture de communication CANopen.<\/p>\n\n\n\n
Pour une batterie CANopen, les valeurs de fonctionnement fr\u00e9quemment requises peuvent \u00eatre mapp\u00e9es dans la communication PDO, tandis que l'acc\u00e8s SDO peut prendre en charge la mise en service ou les diagnostics. La cartographie exacte doit \u00eatre convenue avant l\u2019int\u00e9gration plut\u00f4t que suppos\u00e9e.<\/p>\n\n\n\n
C'est \u00e9galement la raison pour laquelle une batterie de robot qui communique avec succ\u00e8s via CAN propri\u00e9taire ne peut pas automatiquement \u00eatre consid\u00e9r\u00e9e comme compatible CANopen.<\/p>\n\n\n\n
Gestion du r\u00e9seau et battements de c\u0153ur<\/h3>\n\n\n\n CANopen Network Management, ou NMT, d\u00e9finit les \u00e9tats de communication d'un appareil. CiA identifie les \u00e9tats d'initialisation, pr\u00e9-op\u00e9rationnel, op\u00e9rationnel et arr\u00eat\u00e9 au sein de la machine \u00e0 \u00e9tats CANopen NMT. La communication PDO devient disponible dans l'\u00e9tat op\u00e9rationnel, tandis que la communication SDO peut \u00eatre utilis\u00e9e dans l'\u00e9tat pr\u00e9-op\u00e9rationnel.<\/p>\n\n\n\n
Pour la communication avec la batterie du robot, ces \u00e9tats aident \u00e0 d\u00e9finir le comportement lors du d\u00e9marrage, de la mise en service, du fonctionnement normal, de l'arr\u00eat et de la r\u00e9cup\u00e9ration.<\/p>\n\n\n\n
Les m\u00e9canismes Heartbeat fournissent une autre fonction utile en permettant au contr\u00f4leur de d\u00e9terminer si un n\u0153ud attendu reste pr\u00e9sent sur le r\u00e9seau. Une sp\u00e9cification de batterie CANopen doit donc couvrir plus que les champs de donn\u00e9es sur la batterie. L\u2019\u00e9tat de d\u00e9marrage, le timing des battements de c\u0153ur, le d\u00e9lai d\u2019attente et le comportement de r\u00e9cup\u00e9ration peuvent \u00e9galement \u00eatre importants pour le robot.<\/p>\n\n\n\n
Choisir la bonne interface pour les AGV et les AMR<\/h2>\n\n\n\n La bonne m\u00e9thode de communication est celle qui correspond \u00e0 l\u2019architecture de contr\u00f4le existante du robot et fournit les informations sur la batterie requises par ce syst\u00e8me.<\/p>\n\n\n\n
La s\u00e9lection du protocole doit donc commencer par le contr\u00f4leur h\u00f4te et l'architecture de charge plut\u00f4t que par une pr\u00e9f\u00e9rence g\u00e9n\u00e9rique pour CAN ou RS485.<\/p>\n\n\n\n
Faites correspondre le r\u00e9seau de robots existant<\/h3>\n\n\n\n La premi\u00e8re \u00e9tape consiste \u00e0 d\u00e9terminer exactement ce qu\u2019attend le contr\u00f4leur du robot. Un contr\u00f4leur peut utiliser des trames CAN propri\u00e9taires, CANopen, RS485 avec Modbus RTU ou un autre protocole document\u00e9.<\/p>\n\n\n\nArchitecture existante<\/th> Exigence appropri\u00e9e en mati\u00e8re de batterie du robot<\/th><\/tr><\/thead> Contr\u00f4leur CAN propri\u00e9taire<\/td> BMS de batterie CAN avec d\u00e9bit binaire et carte de messages correspondants<\/td><\/tr> Contr\u00f4leur CANopen<\/td> BMS impl\u00e9mentant les objets CANopen requis et le comportement du r\u00e9seau<\/td><\/tr> Automate ou contr\u00f4leur utilisant Modbus RTU<\/td> BMS de batterie RS485 avec param\u00e8tres s\u00e9rie correspondants et carte de registre<\/td><\/tr> R\u00e9seaux de contr\u00f4le et de diagnostic s\u00e9par\u00e9s<\/td> D\u00e9finir quelle connexion transporte le contr\u00f4le de la batterie et laquelle transporte les donn\u00e9es de service<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa batterie du robot doit \u00eatre adapt\u00e9e \u00e0 ces exigences du r\u00e9seau. Choisir un pack parce que son \u00e9tiquette de connecteur ou de port semble famili\u00e8re inverse le processus d'ing\u00e9nierie correct.<\/p>\n\n\n\n
D\u00e9finir les donn\u00e9es de batterie requises<\/h3>\n\n\n\n Avant de demander un pack personnalis\u00e9, les ing\u00e9nieurs doivent cr\u00e9er une matrice de communication qui s\u00e9pare les donn\u00e9es n\u00e9cessaires au fonctionnement des informations destin\u00e9es principalement au diagnostic ou \u00e0 la maintenance.<\/p>\n\n\n\n
Pour de nombreux projets AGV et AMR, le batterie de robot<\/strong> les donn\u00e9es comprennent :<\/p>\n\n\n\n\nTension et courant du paquet<\/li>\n\n\n\n SOC et SOH<\/li>\n\n\n\n Temp\u00e9rature de la batterie<\/li>\n\n\n\n Limites de charge et de d\u00e9charge<\/li>\n\n\n\n \u00c9tats d'avertissement et de protection<\/li>\n\n\n\n \u00c9tat de charge et \u00e9tat du BMS<\/li>\n\n\n\n Identit\u00e9 de l'appareil ou adresse r\u00e9seau<\/li>\n\n\n\n \u00c9tat du contacteur ou du MOSFET lorsque le syst\u00e8me l'exige<\/li>\n<\/ul>\n\n\n\nLe projet devrait \u00e9galement d\u00e9finir la direction des donn\u00e9es. Certaines informations sont transmises du BMS de la batterie AMR \u00e0 l'h\u00f4te, tandis que d'autres architectures peuvent n\u00e9cessiter des commandes de contr\u00f4le, des accus\u00e9s de r\u00e9ception ou des messages de configuration de la part du contr\u00f4leur.<\/p>\n\n\n\n
Cette \u00e9tape d\u00e9termine ce que l'interface doit r\u00e9ellement accomplir.<\/p>\n\n\n\n
V\u00e9rifier le timing et la r\u00e9ponse aux pannes<\/h3>\n\n\n\n Une sp\u00e9cification de communication compl\u00e8te n\u00e9cessite des exigences de timing en plus des d\u00e9finitions de donn\u00e9es.<\/p>\n\n\n\n
Les ing\u00e9nieurs doivent d\u00e9terminer la fr\u00e9quence \u00e0 laquelle les informations critiques sur la batterie du robot doivent \u00eatre mises \u00e0 jour, combien de temps le contr\u00f4leur attend avant de d\u00e9clarer le BMS hors ligne et quelle r\u00e9ponse suit un d\u00e9lai d'attente de communication. Les priorit\u00e9s des messages CAN ou les intervalles d'interrogation RS485 doivent refl\u00e9ter l'importance des donn\u00e9es transf\u00e9r\u00e9es.<\/p>\n\n\n\n
La r\u00e9cup\u00e9ration apr\u00e8s panne n\u00e9cessite \u00e9galement un comportement d\u00e9fini. Le syst\u00e8me doit d\u00e9terminer si la communication reprend automatiquement apr\u00e8s un \u00e9v\u00e9nement transitoire, si le BMS n\u00e9cessite une r\u00e9initialisation et si le robot peut reprendre son fonctionnement imm\u00e9diatement ou doit d'abord v\u00e9rifier l'\u00e9tat de la batterie.<\/p>\n\n\n\n
Ces d\u00e9cisions sont sp\u00e9cifiques \u00e0 l'application. Ils doivent \u00eatre document\u00e9s lors de l'int\u00e9gration plut\u00f4t que d\u00e9duits de l'interface de communication.<\/p>\n\n\n\n
Planifier la communication de la station de recharge<\/h3>\n\n\n\n Un AGV ou un AMR charg\u00e9 automatiquement n\u00e9cessite que la station de chargement soit consid\u00e9r\u00e9e comme faisant partie du batterie de robot<\/strong> architecture.<\/p>\n\n\n\nLe syst\u00e8me de charge peut avoir besoin de coordonner l'autorisation de charge, la tension de la batterie, les limites de courant, l'\u00e9tat de temp\u00e9rature, l'\u00e9tat de charge, l'ach\u00e8vement et les conditions de panne. Des contacts de charge physiques ou un r\u00e9cepteur d'alimentation sans contact fournissent le chemin d'alimentation, mais ils ne d\u00e9finissent pas le comportement de communication.<\/p>\n\n\n\n
Le robot a \u00e9galement besoin d'une s\u00e9quence claire pour d\u00e9tecter la station d'accueil, permettre le chargement, r\u00e9pondre aux limites du BMS, terminer le processus de chargement et reprendre ses activit\u00e9s.<\/p>\n\n\n\n
Les conseils d'int\u00e9gration AMR actuels de MANLY Battery identifient la communication CAN ou RS485, la surveillance du courant et de la temp\u00e9rature, la conception des connecteurs et le c\u00e2blage sp\u00e9cifique \u00e0 l'application comme facteurs \u00e0 coordonner lors de l'int\u00e9gration d'une batterie AMR, d'un BMS et d'une station de chargement.<\/p>\n\n\n\n
Pour les flottes autonomes, la communication de charge doit donc \u00eatre con\u00e7ue en m\u00eame temps que la batterie du robot et le BMS plut\u00f4t qu'une fois le pack finalis\u00e9.<\/p>\n\n\n\n
Tenir compte des besoins en mati\u00e8re de diagnostic de flotte<\/h3>\n\n\n\n Les donn\u00e9es de contr\u00f4le du trafic et de maintenance n\u2019ont pas toujours besoin d\u2019utiliser le m\u00eame chemin de communication. Certains robots placent des donn\u00e9es de batterie sensibles au temps sur le r\u00e9seau CAN principal tout en utilisant une interface distincte pour la mise en service, l'entretien ou des diagnostics plus approfondis.<\/p>\n\n\n\n
Ce qui compte, c\u2019est que l\u2019architecture du diagnostic soit d\u00e9lib\u00e9r\u00e9e.<\/p>\n\n\n\n
Pour les grandes flottes, des d\u00e9finitions coh\u00e9rentes des donn\u00e9es sur les batteries des robots peuvent simplifier le d\u00e9pannage sur de nombreux v\u00e9hicules. Les codes d'erreur, les unit\u00e9s, la mise \u00e0 l'\u00e9chelle, les versions du micrologiciel, les \u00e9tats de communication et les enregistrements de maintenance doivent avoir des significations reproductibles d'un robot \u00e0 l'autre.<\/p>\n\n\n\n
Cela peut devenir particuli\u00e8rement utile lorsque le logiciel de flotte est utilis\u00e9 pour distinguer les \u00e9v\u00e9nements li\u00e9s \u00e0 l'\u00e9nergie des d\u00e9fauts du BMS, des d\u00e9fauts du chargeur ou des \u00e9checs de communication.<\/p>\n\n\n\n
Que demander \u00e0 un fabricant de batteries avant l'int\u00e9gration<\/h2>\n\n\n\n UN fabricant de batteries<\/a><\/strong> devrait \u00eatre en mesure de discuter de la communication BMS avec les m\u00eames d\u00e9tails techniques que ceux utilis\u00e9s pour la tension, la capacit\u00e9, le courant, les dimensions et les exigences en mati\u00e8re de connecteurs du pack.<\/p>\n\n\n\n\u201c CAN disponible \u201d ou \u201c RS485 disponible \u201d est utile pour le contr\u00f4le initial, mais une batterie de robot de production n\u00e9cessite une sp\u00e9cification de communication plus compl\u00e8te.<\/p>\n\n\n\n
Carte des protocoles et des messages<\/h3>\n\n\n\n Pour l'int\u00e9gration CAN, demandez le protocole d'application, les identifiants CAN, les d\u00e9finitions de charge utile, la mise \u00e0 l'\u00e9chelle, la direction des messages, la synchronisation de la transmission et le comportement du d\u00e9lai d'expiration.<\/p>\n\n\n\n
Pour une batterie CANopen, d\u00e9finissez les entr\u00e9es de dictionnaire d'objets requises, les mappages PDO, l'acc\u00e8s SDO, le comportement NMT, les exigences de pulsation et les fonctions sp\u00e9cifiques au contr\u00f4leur.<\/p>\n\n\n\n
Si le projet utilise une communication CAN sp\u00e9cifique au fabricant, la d\u00e9finition du message doit \u00eatre disponible suffisamment t\u00f4t pour le d\u00e9veloppement du contr\u00f4leur et les tests sur banc. L'\u00e9quipe logicielle ne devrait pas avoir \u00e0 proc\u00e9der \u00e0 une r\u00e9tro-ing\u00e9nierie du batterie de robot<\/strong> apr\u00e8s l'arriv\u00e9e du mat\u00e9riel prototype.<\/p>\n\n\n\nD\u00e9bit en bauds et identifiants de n\u0153ud<\/h3>\n\n\n\n Les deux c\u00f4t\u00e9s de la connexion doivent utiliser des param\u00e8tres r\u00e9seau compatibles.<\/p>\n\n\n\n
Pour CAN, confirmez le d\u00e9bit binaire CAN et l\u2019identifiant ou la configuration du n\u0153ud pertinent. Pour CANopen, d\u00e9finissez \u00e9galement les ID de n\u0153ud et le comportement de gestion de r\u00e9seau requis. Pour un BMS de batterie RS485, confirmez le d\u00e9bit en bauds, la parit\u00e9, les bits d'arr\u00eat, l'adressage et le comportement d'interrogation ou de r\u00e9ponse attendu.<\/p>\n\n\n\n
Ces param\u00e8tres doivent \u00eatre enregistr\u00e9s dans la sp\u00e9cification de communication du projet et contr\u00f4l\u00e9s comme toute autre exigence d'interface au niveau du syst\u00e8me.<\/p>\n\n\n\n
Enregistrer la mise \u00e0 l'\u00e9chelle de la carte et des donn\u00e9es<\/h3>\n\n\n\n Une connexion RS485 utilisant Modbus RTU n\u00e9cessite une carte de registre compl\u00e8te. Chaque valeur requise doit avoir une adresse, un type de donn\u00e9es, un facteur d'\u00e9chelle, une unit\u00e9 technique et une m\u00e9thode d'acc\u00e8s d\u00e9finis.<\/p>\n\n\n\n
Par exemple, une valeur transmise ne peut pas \u00eatre interpr\u00e9t\u00e9e correctement tant que le contr\u00f4leur ne sait pas si elle repr\u00e9sente des volts, des millivolts, des dixi\u00e8mes de volt, un courant sign\u00e9 ou un autre codage.<\/p>\n\n\n\n
Le m\u00eame principe s'applique \u00e0 CAN. La r\u00e9ception d'une trame CAN valide ne prouve pas que le batterie de robot<\/strong> les donn\u00e9es ont \u00e9t\u00e9 interpr\u00e9t\u00e9es correctement. L'ordre des octets, les d\u00e9finitions de bits, la mise \u00e0 l'\u00e9chelle, les valeurs sign\u00e9es et les indicateurs d'\u00e9tat doivent toujours correspondre.<\/p>\n\n\n\nTerminaison, brochage et connecteurs<\/h3>\n\n\n\n La documentation \u00e9lectrique doit identifier chaque broche de communication requise, y compris CAN-H, CAN-L, RS485-A, RS485-B, la masse du signal, les lignes de sillage, le blindage ou tout autre conducteur sp\u00e9cifique au projet.<\/p>\n\n\n\n
La terminaison doit \u00e9galement correspondre \u00e0 la topologie du r\u00e9seau s\u00e9lectionn\u00e9e. Les ing\u00e9nieurs doivent v\u00e9rifier si la terminaison se trouve \u00e0 l'int\u00e9rieur de la batterie du robot, install\u00e9e ailleurs sur le robot, configurable ou omise.<\/p>\n\n\n\n
La forme du connecteur ne doit jamais \u00eatre utilis\u00e9e comme substitut \u00e0 cette documentation. Un connecteur de type RJ45, par exemple, n'indique pas automatiquement Ethernet et n'\u00e9tablit pas de brochage CAN ou RS485 standardis\u00e9.<\/p>\n\n\n\n
La conception du c\u00e2ble et du connecteur appartient donc aux sp\u00e9cifications de communication, et pas seulement au dessin m\u00e9canique.<\/p>\n\n\n\n
Exigences de communication du chargeur<\/h3>\n\n\n\n La batterie et le chargeur du robot doivent \u00eatre con\u00e7us comme un syst\u00e8me coordonn\u00e9 lorsque le processus de charge n\u00e9cessite une communication.<\/p>\n\n\n\n
La sp\u00e9cification doit d\u00e9finir si le chargeur utilise des param\u00e8tres \u00e9lectriques fixes ou re\u00e7oit des limites dynamiques du BMS ou du contr\u00f4leur du v\u00e9hicule. Il doit \u00e9galement documenter la logique d'activation de la charge, les limites de courant et de tension, le comportement thermique, l'\u00e9tat de charge, l'ach\u00e8vement de la charge, la r\u00e9ponse aux pannes, l'\u00e9tablissement de liaison au quai et la r\u00e9cup\u00e9ration apr\u00e8s une charge interrompue.<\/p>\n\n\n\n
Pour un AGV ou un AMR qui repose sur une recharge sans surveillance, ces fonctions peuvent directement affecter la fiabilit\u00e9 du retour en fonctionnement du robot apr\u00e8s avoir atteint le quai.<\/p>\n\n\n\n
Options de communication de la batterie MANLY<\/h3>\n\n\n\n Chez MANLY Battery, les projets de robots et de batteries industrielles peuvent \u00eatre d\u00e9velopp\u00e9s autour des exigences de communication de l'application plut\u00f4t que de traiter l'interface comme un module compl\u00e9mentaire isol\u00e9.<\/p>\n\n\n\n
La batterie du robot MANLY 24 V 50 Ah est un pack LiFePO4 \u00e9valu\u00e9 \u00e0 24 V nominal, avec une tension de batterie r\u00e9elle de 25,6 V et 1 280 Wh d'\u00e9nergie nominale. Sa sp\u00e9cification actuelle offre une communication RS485, RS232 ou CANBus en option. Les dimensions, le bo\u00eetier, le connecteur, le bo\u00eetier et le c\u00e2blage peuvent \u00e9galement \u00eatre configur\u00e9s pour r\u00e9pondre aux exigences OEM\/ODM.<\/p>\n\n\n\n
Pour les robots industriels n\u00e9cessitant une plus grande capacit\u00e9 embarqu\u00e9e, la batterie robot MANLY 48V 100Ah offre une capacit\u00e9 de 100Ah et 4 800Wh d'\u00e9nergie nominale. Il prend \u00e9galement en charge la communication RS485, RS232 ou CANBus en option, avec des dimensions, un bo\u00eetier, des connecteurs et un c\u00e2blage personnalisables.<\/p>\n\n\n\nBatterie robot MANLY<\/th> Communication<\/th> Objectif int\u00e9gration<\/th><\/tr><\/thead> Batterie robot 24V 50Ah LiFePO4<\/td> RS485, RS232, CANBus en option<\/td> Projets de robots et d'AGV n\u00e9cessitant une communication BMS, des connecteurs et des dimensions d'emballage configurables<\/td><\/tr> Batterie de robot industriel 48V 100Ah<\/td> RS485, RS232, CANBus en option<\/td> Applications de robots industriels de plus grande capacit\u00e9 n\u00e9cessitant une int\u00e9gration coordonn\u00e9e du BMS, du contr\u00f4leur, du chargeur et du pack<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSi un projet n\u00e9cessite sp\u00e9cifiquement une communication avec la batterie CANopen, cette exigence doit \u00eatre d\u00e9finie lors de l'examen technique. La disponibilit\u00e9 du CANBus \u00e0 elle seule ne doit pas \u00eatre consid\u00e9r\u00e9e comme une confirmation de la compatibilit\u00e9 CANopen.<\/p>\n\n\n\n
L'\u00e9quipe du projet doit fournir le mappage d'objets CANopen requis, la configuration r\u00e9seau, le comportement du contr\u00f4leur et d'autres exigences de protocole afin que la mise en \u0153uvre puisse \u00eatre \u00e9valu\u00e9e avant le lancement. batterie de robot<\/strong> la conception est finalis\u00e9e.<\/p>\n\n\n\nPour les projets CAN ou RS485, le m\u00eame principe s'applique. En fournissant les sp\u00e9cifications du contr\u00f4leur, la carte des messages ou des registres, la vitesse de communication, le brochage, l'architecture du chargeur, la tension, la capacit\u00e9, les exigences de courant et le comportement attendu des pannes, le fabricant de batteries dispose d'un objectif d'int\u00e9gration beaucoup plus clair.<\/p>\n\n\n\n
Le droit communication avec la batterie du robot<\/strong> La m\u00e9thode n'est donc pas d\u00e9termin\u00e9e par le choix de CAN, RS485 ou CANopen isol\u00e9ment. Cela d\u00e9pend si le BMS, le contr\u00f4leur du robot, le chargeur, le c\u00e2blage, le protocole et la logique de fonctionnement ont \u00e9t\u00e9 con\u00e7us pour fonctionner ensemble comme un seul syst\u00e8me.<\/p>\n\n\n\n
![\"Batterie](\"https:\/\/manlybattery.com\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs.webp\")
<\/a><\/figure>\n\n\n\n![\"Batterie](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs-300x200.webp\")
![\"Les](\"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\")
![\"Solution](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Backup-battery-solution-300x300.webp\")