CAN, RS485 et CANopen : de quelle communication une batterie de robot a-t-elle besoin ?

UN batterie de robot a besoin d'une interface et d'un protocole de communication adaptés au contrôleur du robot, au chargeur, aux exigences en matière de données BMS et à l'architecture réseau. CAN fonctionne bien pour la communication basée sur les priorités entre plusieurs nœuds. RS485 fournit une interface série différentielle robuste et est souvent associé à un protocole d'application tel que Modbus RTU. CANopen ajoute un cadre de communication standardisé de couche supérieure au-dessus de CAN.

Il n’existe pas de méthode de communication unique que chaque AGV ou AMR devrait utiliser. Pour fiable batterie de robot communication, la compatibilité doit s’étendre au-delà du connecteur. L'interface électrique, le débit binaire ou en bauds, la structure des messages, le mappage des données, l'adressage, la synchronisation, le comportement en cas de panne et la logique de charge doivent tous correspondre au système hôte.

De quoi une batterie de robot a-t-elle besoin pour communiquer ?

UN batterie de robot communique car le robot a besoin de plus que de l’énergie électrique. Son système de gestion de batterie doit mettre les conditions de batterie et les limites de fonctionnement sélectionnées à la disposition d'équipements tels que le contrôleur du véhicule, le chargeur, la station de chargement, l'ordinateur de diagnostic ou la passerelle de gestion de flotte.

Données de batterie dont le robot a besoin

Un BMS pour batterie AMR mesure ou calcule plusieurs catégories d’informations. Le contrôleur n'a peut-être pas besoin de chaque valeur de cellule interne en permanence, mais il doit recevoir les données requises pour le fonctionnement, la charge, les diagnostics et la maintenance.

Catégorie de données	Informations typiques	Comment le robot utilise it
État électrique	Tension du pack, courant, capacité restante	Surveille l'état actuel de la batterie
État thermique et cellulaire	Tension des cellules, température du pack, température des cellules	Prend en charge les décisions de protection et d’exploitation
Estimations de batterie	SOC, SOH	Prend en charge la planification de l'exécution et de la maintenance
Limites de fonctionnement	Courant de charge, courant de décharge, tension de charge	Aide à maintenir le fonctionnement dans les limites du BMS
Données de défauts et d'avertissements	Surtension, sous-tension, surchauffe, surintensité	Prend en charge la réponse aux pannes contrôlée
État du système	Charge, décharge, veille, état de protection	Coordonne le comportement du robot
Identification	Adresse de l'appareil, version du protocole, identité de la batterie	Prend en charge la reconnaissance et le service

Ceci est également cohérent avec la conception moderne des BMS de robotique mobile. Les plates-formes de référence BMS orientées robotique de NXP combinent la mesure de la tension des cellules et des packs, la détection du courant, la détection de la température et la connectivité CAN au sein de la même architecture de gestion de batterie.

Les spécifications de communication d'une batterie de robot doivent donc commencer par les données dont le robot a besoin, plutôt que par un connecteur ou un nom de bus préféré.

SOC, SOH et rapports de défauts

SOC donne au robot une estimation de la charge restante, tandis que SOH représente l'état de la batterie à plus long terme. Les deux sont précieux, mais aucun ne doit être considéré comme une exigence de communication complète.

UN batterie de robot peut également signaler les températures, le courant, les états d'avertissement, les conditions de protection et les limites de charge ou de décharge autorisées. Lorsque les conditions de fonctionnement changent, ces valeurs fournissent au contrôleur du véhicule des informations qu'il peut utiliser avant que le BMS n'atteigne un état de protection strict.

Cela rend la communication avec la batterie du robot utile à la fois pour le fonctionnement et la maintenance immédiats. Le logiciel de flotte peut utiliser des informations cohérentes sur l'état et les défauts pour distinguer une condition de faible consommation d'énergie d'un événement thermique, d'un événement de protection ou d'un défaut de communication.

Poignées de main du contrôleur et du chargeur

Le contrôleur du véhicule et le chargeur ne nécessitent pas nécessairement des données de batterie identiques. Pendant le mouvement, le contrôleur peut donner la priorité au SOC, à la tension, au courant, à la température, aux avertissements et aux limites de décharge. Pendant la charge, le système peut également avoir besoin d'une autorisation de charge, de limites de courant de charge, de limites de tension, d'informations sur l'état de la température et sur l'état de charge.

C'est pourquoi la spécification d'un BMS de batterie CAN ou d'un BMS de batterie RS485 n'est que la première étape. Deux appareils peuvent partager la même interface électrique tout en utilisant des identifiants, des registres, des facteurs d'échelle, des intervalles de mise à jour ou une logique de contrôle différents.

La recharge automatique rend la distinction particulièrement importante. Lorsqu'un AGV ou un AMR s'amarre sans intervention de l'opérateur, la batterie, le chargeur et le contrôleur du robot doivent avoir un comportement défini pour l'autorisation de charge, les limites de fonctionnement, la gestion des pannes, l'achèvement de la charge et la remise en service.

Pourquoi la communication affecte la disponibilité

Une communication utile avec la batterie permet au robot de réagir aux conditions de la batterie avant qu'un arrêt brutal ne devienne la seule réponse disponible. Un faible SOC peut lancer une tâche de charge, une condition de température peut affecter le comportement de charge et un défaut signalé peut placer le véhicule dans un état de service défini.

Pour les flottes, des données cohérentes sur les batteries des robots améliorent également le dépannage. Les équipes de maintenance peuvent examiner les états de fonctionnement et les alarmes au lieu de traiter chaque perte de propulsion ou interruption de charge comme le même problème.

L’avantage n’est pas simplement davantage de télémétrie. La véritable valeur réside dans le fait de faire de la batterie une partie intégrée et interprétable de l’architecture de contrôle du robot.

CAN vs RS485 : en quoi ils diffèrent dans les systèmes robotisés

CAN et RS485 sont tous deux courants dans les systèmes industriels, mais ils résolvent différentes parties du problème de communication. CAN fournit des mécanismes de tramage de messages, d'arbitrage, d'accusé de réception et de gestion des erreurs pour un bus partagé. RS485 définit principalement la signalisation électrique utilisée pour la communication série.

Cette distinction est importante lorsque les ingénieurs sélectionnent une architecture de communication pour une batterie de robot.

CAN en tant que réseau

CAN est conçu pour plusieurs appareils communiquant sur un bus partagé. Les messages sont identifiés par des identifiants CAN et les tentatives de transmission simultanées sont résolues grâce à un arbitrage basé sur les priorités.

Pour la communication avec la batterie du robot, cette architecture peut prendre en charge des messages d'état réguliers, des limites de fonctionnement, des informations d'avertissement et des rapports de pannes déclenchés par des événements. La conception de référence actuelle du BMS de robotique mobile MR-BMS771 de NXP comprend deux bus CAN, fournissant un exemple pratique d'intégration directe de CAN dans une plate-forme robotique de gestion de batterie.

Un port CAN à lui seul ne définit cependant pas la signification des données. Un BMS de batterie CAN et un contrôleur de robot ont toujours besoin de débits binaires, d'identifiants, de définitions de charge utile, de mise à l'échelle, de synchronisation de transmission et de logique d'application compatibles.

RS485 comme interface physique

RS485 est une interface série différentielle largement utilisée dans la communication multipoint industrielle. Il est particulièrement utile lorsque l'équipement utilise déjà des réseaux série ou lorsqu'un contrôleur communique avec plusieurs appareils adressés.

Pour une batterie de robot, le point critique est que le RS485 à lui seul n'indique pas au contrôleur la signification d'un octet. Un BMS de batterie RS485 nécessite toujours un protocole d'application défini ou une structure de données propriétaire.

Cette distinction explique pourquoi RS485 et Modbus RTU apparaissent fréquemment ensemble sans être synonymes. L'organisation Modbus documente les implémentations de ligne série Modbus à l'aide d'EIA/TIA-485, tandis que Modbus définit lui-même le comportement de messagerie de niveau supérieur.

Une spécification d’achat devrait donc dire plus que “ RS485 requis ”. Il doit identifier le protocole réel et la carte de données attendus par le robot.

Arbitrage CAN et gestion des erreurs

CAN permet aux nœuds de transmettre sans attendre qu'un contrôleur central attribue chaque opportunité de transmission. Si deux nœuds commencent à transmettre en même temps, l'arbitrage basé sur les identifiants de message détermine quelle trame continue.

CAN comprend également des mécanismes pour détecter les erreurs de transmission et gérer les nœuds qui génèrent des erreurs de manière répétée. Ces caractéristiques le rendent adapté aux réseaux où le batterie de robot doit échanger fréquemment des données d’exploitation avec d’autres contrôleurs.

La décision technique ne doit pas être réduite à une affirmation générique selon laquelle CAN est simplement “ plus rapide ”. Ce qui compte est de savoir si les messages de batterie requis peuvent être transmis avec la priorité et le timing de mise à jour nécessaires sous la charge de bus attendue.

Pour un robot mobile, un petit ensemble de messages de batterie correctement hiérarchisés et documentés est souvent plus précieux qu'un débit de données théoriquement élevé avec un comportement d'application mal défini.

Modbus RTU sur RS485

Modbus RTU fournit une structure de messagerie au niveau de l'application qui peut fonctionner sur une liaison série RS485. Le protocole définit la manière dont les appareils adressés échangent des demandes et des réponses, tandis que la carte de registre spécifique à l'équipement identifie l'emplacement de stockage des valeurs individuelles.

Pour une batterie de robot, une carte Modbus RTU peut contenir des registres pour la tension, le courant, le SOC, la température, les alarmes ou les limites de fonctionnement du pack. Une interprétation correcte nécessite que le contrôleur connaisse l'adresse du registre, le format des données, le facteur de mise à l'échelle, l'ordre des octets, l'adresse du périphérique, le débit en bauds, la parité et le comportement du délai d'attente.

Plusieurs distinctions sont importantes lors de l'intégration : RS485 ne signifie pas automatiquement Modbus RTU ; deux appareils Modbus n'utilisent pas automatiquement la même carte de registre ; un connecteur RJ45 n'établit pas la compatibilité Ethernet, CAN ou RS485 ; et une connexion électriquement valide ne garantit pas la compatibilité au niveau de l'application.

Ces contrôles évitent un échec d’intégration courant : les deux parties semblent prendre en charge la même technologie de communication, mais la batterie du robot et le contrôleur ne peuvent pas comprendre les données de chacun.

Où CANopen s'intègre dans un système de batterie de robot

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éfinit des mécanismes standardisés pour organiser les données des appareils, transmettre les informations sur les processus, accéder aux paramètres de configuration, contrôler les états du réseau et surveiller les participants au réseau.

Une implémentation de batterie CANopen nécessite donc plus qu'un émetteur-récepteur CAN ou un connecteur CAN. Le BMS doit implémenter les fonctions CANopen requises par le contrôleur hôte.

CAN n'est pas CANopen

CAN fournit le mécanisme de communication réseau sous-jacent. CANopen ajoute la structure de couche supérieure qui détermine la manière dont les appareils basés sur CAN organisent et échangent les données d'application.

CAN in Automation, ou CiA, décrit un appareil CANopen comme doté d'une pile de protocoles CANopen, d'un logiciel d'application et d'un dictionnaire d'objets qui connecte le système de communication aux paramètres d'application.

Cela rend une règle de passation des marchés particulièrement importante :

La prise en charge CAN ne signifie pas automatiquement la prise en charge CANopen.

Si un contrôleur AMR nécessite une batterie CANopen, la spécification doit identifier la fonctionnalité CANopen et les mappages de données attendus par le contrôleur. Il ne suffit pas de demander simplement un port CAN.

Le dictionnaire d'objets CANopen

Le dictionnaire d'objets est le modèle de données structurées utilisé par les appareils CANopen. CiA spécifie que les paramètres de communication et d'application sont organisés via des entrées de dictionnaire d'objets indexées, avec des valeurs d'index et de sous-index fournissant des adresses définies pour les données.

Dans une intégration de batterie CANopen, cette structure peut fournir un moyen cohérent d'exposer l'état de la batterie, les paramètres de configuration et les informations de diagnostic. Les objets de batterie réels doivent toujours correspondre aux exigences du contrôleur et à tout profil ou spécification de projet applicable.

L'avantage pratique est la clarté. Les ingénieurs n'ont pas besoin de traiter chaque trame CAN comme un message propriétaire isolé lorsqu'une implémentation CANopen définie est utilisée. Ils peuvent travailler avec des objets documentés et des services de communication.

PDO, SDO et diagnostics

CANopen sépare les différentes tâches de communication via des services définis. Les objets de données de processus, ou PDO, sont adaptés au traitement des informations échangées pendant le fonctionnement. Les objets de données de service, ou SDO, permettent d'accéder aux entrées du dictionnaire d'objets pour les fonctions de configuration et de service.

CANopen fournit également des mécanismes de rapport d'erreurs et de supervision des nœuds. La documentation CiA identifie les fonctions PDO, SDO, d'urgence, de battement de cœur et de gestion de réseau comme faisant partie de l'architecture de communication CANopen.

Pour une batterie CANopen, les valeurs de fonctionnement fréquemment requises peuvent être mappées dans la communication PDO, tandis que l'accès SDO peut prendre en charge la mise en service ou les diagnostics. La cartographie exacte doit être convenue avant l’intégration plutôt que supposée.

C'est également la raison pour laquelle une batterie de robot qui communique avec succès via CAN propriétaire ne peut pas automatiquement être considérée comme compatible CANopen.

Gestion du réseau et battements de cœur

CANopen Network Management, ou NMT, définit les états de communication d'un appareil. CiA identifie les états d'initialisation, pré-opérationnel, opérationnel et arrêté au sein de la machine à états CANopen NMT. La communication PDO devient disponible dans l'état opérationnel, tandis que la communication SDO peut être utilisée dans l'état pré-opérationnel.

Pour la communication avec la batterie du robot, ces états aident à définir le comportement lors du démarrage, de la mise en service, du fonctionnement normal, de l'arrêt et de la récupération.

Les mécanismes Heartbeat fournissent une autre fonction utile en permettant au contrôleur de déterminer si un nœud attendu reste présent sur le réseau. Une spécification de batterie CANopen doit donc couvrir plus que les champs de données sur la batterie. L’état de démarrage, le timing des battements de cœur, le délai d’attente et le comportement de récupération peuvent également être importants pour le robot.

Choisir la bonne interface pour les AGV et les AMR

La bonne méthode de communication est celle qui correspond à l’architecture de contrôle existante du robot et fournit les informations sur la batterie requises par ce système.

La sélection du protocole doit donc commencer par le contrôleur hôte et l'architecture de charge plutôt que par une préférence générique pour CAN ou RS485.

Faites correspondre le réseau de robots existant

La première étape consiste à déterminer exactement ce qu’attend le contrôleur du robot. Un contrôleur peut utiliser des trames CAN propriétaires, CANopen, RS485 avec Modbus RTU ou un autre protocole documenté.

Architecture existante	Exigence appropriée en matière de batterie du robot
Contrôleur CAN propriétaire	BMS de batterie CAN avec débit binaire et carte de messages correspondants
Contrôleur CANopen	BMS implémentant les objets CANopen requis et le comportement du réseau
Automate ou contrôleur utilisant Modbus RTU	BMS de batterie RS485 avec paramètres série correspondants et carte de registre
Réseaux de contrôle et de diagnostic séparés	Définir quelle connexion transporte le contrôle de la batterie et laquelle transporte les données de service

La batterie du robot doit être adaptée à ces exigences du réseau. Choisir un pack parce que son étiquette de connecteur ou de port semble familière inverse le processus d'ingénierie correct.

Définir les données de batterie requises

Avant de demander un pack personnalisé, les ingénieurs doivent créer une matrice de communication qui sépare les données nécessaires au fonctionnement des informations destinées principalement au diagnostic ou à la maintenance.

Pour de nombreux projets AGV et AMR, le batterie de robot les données comprennent :

• Tension et courant du paquet
• SOC et SOH
• Température de la batterie
• Limites de charge et de décharge
• États d'avertissement et de protection
• État de charge et état du BMS
• Identité de l'appareil ou adresse réseau
• État du contacteur ou du MOSFET lorsque le système l'exige

Le projet devrait également définir la direction des données. Certaines informations sont transmises du BMS de la batterie AMR à l'hôte, tandis que d'autres architectures peuvent nécessiter des commandes de contrôle, des accusés de réception ou des messages de configuration de la part du contrôleur.

Cette étape détermine ce que l'interface doit réellement accomplir.

Vérifier le timing et la réponse aux pannes

Une spécification de communication complète nécessite des exigences de timing en plus des définitions de données.

Les ingénieurs doivent déterminer la fréquence à laquelle les informations critiques sur la batterie du robot doivent être mises à jour, combien de temps le contrôleur attend avant de déclarer le BMS hors ligne et quelle réponse suit un délai d'attente de communication. Les priorités des messages CAN ou les intervalles d'interrogation RS485 doivent refléter l'importance des données transférées.

La récupération après panne nécessite également un comportement défini. Le système doit déterminer si la communication reprend automatiquement après un événement transitoire, si le BMS nécessite une réinitialisation et si le robot peut reprendre son fonctionnement immédiatement ou doit d'abord vérifier l'état de la batterie.

Ces décisions sont spécifiques à l'application. Ils doivent être documentés lors de l'intégration plutôt que déduits de l'interface de communication.

Planifier la communication de la station de recharge

Un AGV ou un AMR chargé automatiquement nécessite que la station de chargement soit considérée comme faisant partie du batterie de robot architecture.

Le système de charge peut avoir besoin de coordonner l'autorisation de charge, la tension de la batterie, les limites de courant, l'état de température, l'état de charge, l'achèvement et les conditions de panne. Des contacts de charge physiques ou un récepteur d'alimentation sans contact fournissent le chemin d'alimentation, mais ils ne définissent pas le comportement de communication.

Le robot a également besoin d'une séquence claire pour détecter la station d'accueil, permettre le chargement, répondre aux limites du BMS, terminer le processus de chargement et reprendre ses activités.

Les conseils d'intégration AMR actuels de MANLY Battery identifient la communication CAN ou RS485, la surveillance du courant et de la température, la conception des connecteurs et le câblage spécifique à l'application comme facteurs à coordonner lors de l'intégration d'une batterie AMR, d'un BMS et d'une station de chargement.

Pour les flottes autonomes, la communication de charge doit donc être conçue en même temps que la batterie du robot et le BMS plutôt qu'une fois le pack finalisé.

Tenir compte des besoins en matière de diagnostic de flotte

Les données de contrôle du trafic et de maintenance n’ont pas toujours besoin d’utiliser le même chemin de communication. Certains robots placent des données de batterie sensibles au temps sur le réseau CAN principal tout en utilisant une interface distincte pour la mise en service, l'entretien ou des diagnostics plus approfondis.

Ce qui compte, c’est que l’architecture du diagnostic soit délibérée.

Pour les grandes flottes, des définitions cohérentes des données sur les batteries des robots peuvent simplifier le dépannage sur de nombreux véhicules. Les codes d'erreur, les unités, la mise à l'échelle, les versions du micrologiciel, les états de communication et les enregistrements de maintenance doivent avoir des significations reproductibles d'un robot à l'autre.

Cela peut devenir particulièrement utile lorsque le logiciel de flotte est utilisé pour distinguer les événements liés à l'énergie des défauts du BMS, des défauts du chargeur ou des échecs de communication.

Que demander à un fabricant de batteries avant l'intégration

UN fabricant de batteries devrait être en mesure de discuter de la communication BMS avec les mêmes détails techniques que ceux utilisés pour la tension, la capacité, le courant, les dimensions et les exigences en matière de connecteurs du pack.

“ CAN disponible ” ou “ RS485 disponible ” est utile pour le contrôle initial, mais une batterie de robot de production nécessite une spécification de communication plus complète.

Carte des protocoles et des messages

Pour l'intégration CAN, demandez le protocole d'application, les identifiants CAN, les définitions de charge utile, la mise à l'échelle, la direction des messages, la synchronisation de la transmission et le comportement du délai d'expiration.

Pour une batterie CANopen, définissez les entrées de dictionnaire d'objets requises, les mappages PDO, l'accès SDO, le comportement NMT, les exigences de pulsation et les fonctions spécifiques au contrôleur.

Si le projet utilise une communication CAN spécifique au fabricant, la définition du message doit être disponible suffisamment tôt pour le développement du contrôleur et les tests sur banc. L'équipe logicielle ne devrait pas avoir à procéder à une rétro-ingénierie du batterie de robot après l'arrivée du matériel prototype.

Débit en bauds et identifiants de nœud

Les deux côtés de la connexion doivent utiliser des paramètres réseau compatibles.

Pour CAN, confirmez le débit binaire CAN et l’identifiant ou la configuration du nœud pertinent. Pour CANopen, définissez également les ID de nœud et le comportement de gestion de réseau requis. Pour un BMS de batterie RS485, confirmez le débit en bauds, la parité, les bits d'arrêt, l'adressage et le comportement d'interrogation ou de réponse attendu.

Ces paramètres doivent être enregistrés dans la spécification de communication du projet et contrôlés comme toute autre exigence d'interface au niveau du système.

Enregistrer la mise à l'échelle de la carte et des données

Une connexion RS485 utilisant Modbus RTU nécessite une carte de registre complète. Chaque valeur requise doit avoir une adresse, un type de données, un facteur d'échelle, une unité technique et une méthode d'accès définis.

Par exemple, une valeur transmise ne peut pas être interprétée correctement tant que le contrôleur ne sait pas si elle représente des volts, des millivolts, des dixièmes de volt, un courant signé ou un autre codage.

Le même principe s'applique à CAN. La réception d'une trame CAN valide ne prouve pas que le batterie de robot les données ont été interprétées correctement. L'ordre des octets, les définitions de bits, la mise à l'échelle, les valeurs signées et les indicateurs d'état doivent toujours correspondre.

Terminaison, brochage et connecteurs

La documentation électrique 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écifique au projet.

La terminaison doit également correspondre à la topologie du réseau sélectionnée. Les ingénieurs doivent vérifier si la terminaison se trouve à l'intérieur de la batterie du robot, installée ailleurs sur le robot, configurable ou omise.

La forme du connecteur ne doit jamais être utilisée comme substitut à cette documentation. Un connecteur de type RJ45, par exemple, n'indique pas automatiquement Ethernet et n'établit pas de brochage CAN ou RS485 standardisé.

La conception du câble et du connecteur appartient donc aux spécifications de communication, et pas seulement au dessin mécanique.

Exigences de communication du chargeur

La batterie et le chargeur du robot doivent être conçus comme un système coordonné lorsque le processus de charge nécessite une communication.

La spécification doit définir si le chargeur utilise des paramètres électriques fixes ou reçoit des limites dynamiques du BMS ou du contrôleur du véhicule. Il doit également documenter la logique d'activation de la charge, les limites de courant et de tension, le comportement thermique, l'état de charge, l'achèvement de la charge, la réponse aux pannes, l'établissement de liaison au quai et la récupération après une charge interrompue.

Pour un AGV ou un AMR qui repose sur une recharge sans surveillance, ces fonctions peuvent directement affecter la fiabilité du retour en fonctionnement du robot après avoir atteint le quai.

Options de communication de la batterie MANLY

Chez MANLY Battery, les projets de robots et de batteries industrielles peuvent être développés autour des exigences de communication de l'application plutôt que de traiter l'interface comme un module complémentaire isolé.

La batterie du robot MANLY 24 V 50 Ah est un pack LiFePO4 évalué à 24 V nominal, avec une tension de batterie réelle de 25,6 V et 1 280 Wh d'énergie nominale. Sa spécification actuelle offre une communication RS485, RS232 ou CANBus en option. Les dimensions, le boîtier, le connecteur, le boîtier et le câblage peuvent également être configurés pour répondre aux exigences OEM/ODM.

Pour les robots industriels nécessitant une plus grande capacité embarquée, la batterie robot MANLY 48V 100Ah offre une capacité de 100Ah et 4 800Wh d'énergie nominale. Il prend également en charge la communication RS485, RS232 ou CANBus en option, avec des dimensions, un boîtier, des connecteurs et un câblage personnalisables.

Batterie robot MANLY	Communication	Objectif intégration
Batterie robot 24V 50Ah LiFePO4	RS485, RS232, CANBus en option	Projets de robots et d'AGV nécessitant une communication BMS, des connecteurs et des dimensions d'emballage configurables
Batterie de robot industriel 48V 100Ah	RS485, RS232, CANBus en option	Applications de robots industriels de plus grande capacité nécessitant une intégration coordonnée du BMS, du contrôleur, du chargeur et du pack

Si un projet nécessite spécifiquement une communication avec la batterie CANopen, cette exigence doit être définie lors de l'examen technique. La disponibilité du CANBus à elle seule ne doit pas être considérée comme une confirmation de la compatibilité CANopen.

L'équipe du projet doit fournir le mappage d'objets CANopen requis, la configuration réseau, le comportement du contrôleur et d'autres exigences de protocole afin que la mise en œuvre puisse être évaluée avant le lancement. batterie de robot la conception est finalisée.

Pour les projets CAN ou RS485, le même principe s'applique. En fournissant les spécifications du contrôleur, la carte des messages ou des registres, la vitesse de communication, le brochage, l'architecture du chargeur, la tension, la capacité, les exigences de courant et le comportement attendu des pannes, le fabricant de batteries dispose d'un objectif d'intégration beaucoup plus clair.

Le droit communication avec la batterie du robot La méthode n'est donc pas déterminée par le choix de CAN, RS485 ou CANopen isolément. Cela dépend si le BMS, le contrôleur du robot, le chargeur, le câblage, le protocole et la logique de fonctionnement ont été conçus pour fonctionner ensemble comme un seul système.

En savoir plus sur la batterie