Roboterbatterie<\/a><\/strong> kann auch Temperaturen, Strom, Warnzust\u00e4nde, Schutzbedingungen und zul\u00e4ssige Lade- oder Entladegrenzen melden. Wenn sich die Betriebsbedingungen \u00e4ndern, liefern diese Werte der Fahrzeugsteuerung Informationen, die sie nutzen kann, bevor das BMS einen harten Schutzzustand erreicht.<\/p>\n\n\n\nDies macht die Batteriekommunikation des Roboters sowohl f\u00fcr den sofortigen Betrieb als auch f\u00fcr die Wartung n\u00fctzlich. Flottensoftware kann konsistente Status- und Fehlerinformationen verwenden, um einen Niedrigenergiezustand von einem thermischen Ereignis, einem Schutzereignis oder einem Kommunikationsfehler zu unterscheiden.<\/p>\n\n\n\n
Controller- und Ladeger\u00e4t-Handshakes<\/h3>\n\n\n\n Fahrzeugsteuerung und Ladeger\u00e4t ben\u00f6tigen nicht unbedingt identische Batteriedaten. W\u00e4hrend der Bewegung kann die Steuerung SOC, Spannung, Strom, Temperatur, Warnungen und Entladegrenzen priorisieren. W\u00e4hrend des Ladevorgangs ben\u00f6tigt das System m\u00f6glicherweise auch eine Ladeerlaubnis, Ladestromgrenzen, Spannungsgrenzen, Temperaturstatus und Informationen zum Ladezustand.<\/p>\n\n\n\n
Aus diesem Grund ist die Angabe eines CAN-Batterie-BMS oder RS485-Batterie-BMS nur der erste Schritt. Zwei Ger\u00e4te k\u00f6nnen sich dieselbe elektrische Schnittstelle teilen, jedoch unterschiedliche Kennungen, Register, Skalierungsfaktoren, Aktualisierungsintervalle oder Steuerlogik verwenden.<\/p>\n\n\n\n
Durch die automatische Aufladung ist die Unterscheidung besonders wichtig. Wenn ein AGV oder AMR ohne Bedienereingriff andockt, ben\u00f6tigen die Roboterbatterie, das Ladeger\u00e4t und die Steuerung ein definiertes Verhalten f\u00fcr die Ladeautorisierung, Betriebsgrenzen, Fehlerbehandlung, Ladeabschluss und Wiederinbetriebnahme.<\/p>\n\n\n\n
Warum Kommunikation die Betriebszeit beeinflusst<\/h3>\n\n\n\n Durch die n\u00fctzliche Batteriekommunikation kann der Roboter auf den Batteriezustand reagieren, bevor ein hartes Herunterfahren die einzige verf\u00fcgbare Reaktion ist. Ein niedriger Ladezustand kann eine Ladeaufgabe ausl\u00f6sen, eine Temperaturbedingung kann das Ladeverhalten beeinflussen und ein gemeldeter Fehler kann das Fahrzeug in einen definierten Betriebszustand versetzen.<\/p>\n\n\n\n
Bei Flotten verbessern konsistente Roboterbatteriedaten auch die Fehlerbehebung. Wartungsteams k\u00f6nnen Betriebszust\u00e4nde und Alarme \u00fcberpr\u00fcfen, anstatt jeden Antriebsverlust oder jede Ladeunterbrechung als dasselbe Problem zu behandeln.<\/p>\n\n\n\n
Der Vorteil besteht nicht einfach nur in mehr Telemetrie. Der wahre Wert liegt darin, die Batterie zu einem integrierten und interpretierbaren Teil der Steuerungsarchitektur des Roboters zu machen.<\/p>\n\n\n\n
CAN vs. RS485: Wie sie sich in Robotersystemen unterscheiden<\/h2>\n\n\n\n CAN und RS485 sind beide in industriellen Systemen \u00fcblich, l\u00f6sen jedoch unterschiedliche Teile des Kommunikationsproblems. CAN bietet Mechanismen f\u00fcr Nachrichtenrahmen, Arbitrierung, Best\u00e4tigung und Fehlermanagement f\u00fcr einen gemeinsam genutzten Bus. RS485 definiert in erster Linie die elektrische Signalisierung, die f\u00fcr die serielle Kommunikation verwendet wird.<\/p>\n\n\n\n
Diese Unterscheidung ist wichtig, wenn Ingenieure eine Kommunikationsarchitektur f\u00fcr eine Roboterbatterie ausw\u00e4hlen.<\/p>\n\n\n\n
CAN als Netzwerk<\/h3>\n\n\n\n CAN ist f\u00fcr die Kommunikation mehrerer Ger\u00e4te \u00fcber einen gemeinsamen Bus konzipiert. Nachrichten werden durch CAN-Identifier identifiziert und gleichzeitige \u00dcbertragungsversuche werden durch priorit\u00e4tsbasierte Arbitrierung gel\u00f6st.<\/p>\n\n\n\n
F\u00fcr die Roboterbatteriekommunikation kann diese Architektur regelm\u00e4\u00dfige Statusmeldungen, Betriebsgrenzen, Warninformationen und ereignisgesteuerte Fehlerberichte unterst\u00fctzen. Das aktuelle BMS-Referenzdesign MR-BMS771 f\u00fcr mobile Robotik von NXP umfasst zwei CAN-Busse und stellt ein praktisches Beispiel f\u00fcr die direkte Integration von CAN in eine Robotik-Batteriemanagementplattform dar.<\/p>\n\n\n\n
Ein CAN-Port allein definiert jedoch nicht die Bedeutung der Daten. Ein CAN-Batterie-BMS und eine Robotersteuerung ben\u00f6tigen weiterhin kompatible Bitraten, Identifikatoren, Nutzlastdefinitionen, Skalierung, \u00dcbertragungszeitpunkt und Anwendungslogik.<\/p>\n\n\n\n
RS485 als physikalische Schnittstelle<\/h3>\n\n\n\n RS485 ist eine differenzielle serielle Schnittstelle, die h\u00e4ufig in der industriellen Mehrpunktkommunikation verwendet wird. Dies ist besonders n\u00fctzlich, wenn Ger\u00e4te bereits serielle Netzwerke verwenden oder ein Controller mit mehreren adressierten Ger\u00e4ten kommuniziert.<\/p>\n\n\n\n
Bei einer Roboterbatterie besteht der entscheidende Punkt darin, dass RS485 allein der Steuerung nicht mitteilt, was ein Byte bedeutet. Ein RS485-Batterie-BMS ben\u00f6tigt weiterhin ein definiertes Anwendungsprotokoll oder eine propriet\u00e4re Datenstruktur.<\/p>\n\n\n\n
Diese Unterscheidung erkl\u00e4rt, warum RS485 und Modbus RTU h\u00e4ufig zusammen vorkommen, ohne synonym zu sein. Die Modbus Organization dokumentiert Modbus Serial Line-Implementierungen mithilfe von EIA\/TIA-485, w\u00e4hrend Modbus selbst das Nachrichtenverhalten auf h\u00f6herer Ebene definiert.<\/p>\n\n\n\n
In einer Kaufspezifikation sollte daher mehr stehen als \u201cRS485 erforderlich\u201d. Es sollte das tats\u00e4chliche Protokoll und die vom Roboter erwartete Datenkarte identifizieren.<\/p>\n\n\n\n
CAN-Schiedsverfahren und Fehlerbehandlung<\/h3>\n\n\n\n Mit CAN k\u00f6nnen Knoten senden, ohne darauf warten zu m\u00fcssen, dass ein zentraler Controller jede \u00dcbertragungsm\u00f6glichkeit zuweist. Wenn zwei Knoten gleichzeitig mit der \u00dcbertragung beginnen, bestimmt die Schlichtung auf Basis der Nachrichtenkennungen, welcher Frame fortgesetzt wird.<\/p>\n\n\n\n
CAN umfasst auch Mechanismen zur Erkennung von \u00dcbertragungsfehlern und zur Verwaltung von Knoten, die wiederholt Fehler erzeugen. Diese Eigenschaften machen es f\u00fcr Netzwerke geeignet, in denen die Roboterbatterie<\/strong> m\u00fcssen regelm\u00e4\u00dfig Betriebsdaten mit anderen Steuerungen austauschen.<\/p>\n\n\n\nDie technische Entscheidung sollte nicht auf die allgemeine Behauptung reduziert werden, dass CAN einfach \u201cschneller\u201d sei. Entscheidend ist, ob die erforderlichen Batteriemeldungen mit der erforderlichen Priorit\u00e4t und Aktualisierungszeit unter der erwarteten Buslast zugestellt werden k\u00f6nnen.<\/p>\n\n\n\n
F\u00fcr einen mobilen Roboter ist ein kleiner Satz korrekt priorisierter und dokumentierter Batteriemeldungen oft wertvoller als eine theoretisch hohe Datenrate mit schlecht definiertem Anwendungsverhalten.<\/p>\n\n\n\n
Modbus RTU \u00fcber RS485<\/h3>\n\n\n\n Modbus RTU bietet eine Nachrichtenstruktur auf Anwendungsebene, die \u00fcber eine serielle RS485-Verbindung betrieben werden kann. Das Protokoll definiert, wie adressierte Ger\u00e4te Anfragen und Antworten austauschen, w\u00e4hrend die ger\u00e4tespezifische Registerzuordnung angibt, wo einzelne Werte gespeichert werden.<\/p>\n\n\n\n
F\u00fcr eine Roboterbatterie kann eine Modbus-RTU-Karte Register f\u00fcr Packspannung, Strom, SOC, Temperatur, Alarme oder Betriebsgrenzen enthalten. F\u00fcr eine korrekte Interpretation muss der Controller die Registeradresse, das Datenformat, den Skalierungsfaktor, die Bytereihenfolge, die Ger\u00e4teadresse, die Baudrate, die Parit\u00e4t und das Timeout-Verhalten kennen.<\/p>\n\n\n\n
Bei der Integration sind mehrere Unterscheidungen wichtig: RS485 bedeutet nicht automatisch Modbus RTU; zwei Modbus-Ger\u00e4te verwenden nicht automatisch dieselbe Registerzuordnung; ein RJ45-Anschluss stellt keine Ethernet-, CAN- oder RS485-Kompatibilit\u00e4t her; und eine elektrisch g\u00fcltige Verbindung garantiert keine Kompatibilit\u00e4t auf Anwendungsebene.<\/p>\n\n\n\n
Diese Pr\u00fcfungen verhindern einen h\u00e4ufigen Integrationsfehler: Beide Seiten unterst\u00fctzen offenbar die gleiche Kommunikationstechnologie, doch Roboterbatterie und Steuerung k\u00f6nnen die Daten des jeweils anderen nicht verstehen.<\/p>\n\n\n\n
Wo CANopen in ein Roboterbatteriesystem passt<\/h2>\n\n\n\n CANopen sitzt im Kommunikationsstapel \u00fcber CAN. Es ersetzt nicht den CAN-Bus. Stattdessen definiert CANopen standardisierte Mechanismen zur Organisation von Ger\u00e4tedaten, zur \u00dcbertragung von Prozessinformationen, zum Zugriff auf Konfigurationsparameter, zur Steuerung von Netzwerkzust\u00e4nden und zur \u00dcberwachung von Netzwerkteilnehmern.<\/p>\n\n\n\n
Eine CANopen-Batterieimplementierung erfordert daher mehr als einen CAN-Transceiver oder CAN-Stecker. Das BMS muss die vom Host-Controller ben\u00f6tigten CANopen-Funktionen implementieren.<\/p>\n\n\n\n
CAN ist nicht CANopen<\/h3>\n\n\n\n CAN stellt den zugrunde liegenden Netzwerkkommunikationsmechanismus bereit. CANopen f\u00fcgt die \u00fcbergeordnete Struktur hinzu, die bestimmt, wie CAN-basierte Ger\u00e4te Anwendungsdaten organisieren und austauschen.<\/p>\n\n\n\n
CAN in Automation (CiA) beschreibt ein CANopen-Ger\u00e4t mit einem CANopen-Protokollstapel, Anwendungssoftware und einem Objektverzeichnis, das das Kommunikationssystem mit Anwendungsparametern verbindet.<\/p>\n\n\n\n
Daher ist eine Beschaffungsregel besonders wichtig:<\/p>\n\n\n\n
CAN-Unterst\u00fctzung bedeutet nicht automatisch CANopen-Unterst\u00fctzung.<\/strong><\/p>\n\n\n\nWenn ein AMR-Controller eine CANopen-Batterie ben\u00f6tigt, sollte die Spezifikation die vom Controller erwarteten CANopen-Funktionalit\u00e4ten und Datenzuordnungen angeben. Die blo\u00dfe Anforderung eines CAN-Ports reicht nicht aus.<\/p>\n\n\n\n
Das CANopen-Objektverzeichnis<\/h3>\n\n\n\n Das Objektverzeichnis ist das strukturierte Datenmodell, das von CANopen-Ger\u00e4ten verwendet wird. CiA legt fest, dass Kommunikations- und Anwendungsparameter durch indizierte Objektw\u00f6rterbucheintr\u00e4ge organisiert werden, wobei Index- und Subindexwerte definierte Adressen f\u00fcr Daten bereitstellen.<\/p>\n\n\n\n
Bei einer CANopen-Batterieintegration kann diese Struktur eine konsistente M\u00f6glichkeit bieten, Batteriestatus, Konfigurationsparameter und Diagnoseinformationen offenzulegen. Die tats\u00e4chlichen Batterieobjekte m\u00fcssen weiterhin den Anforderungen des Controllers und allen anwendbaren Profilen oder Projektspezifikationen entsprechen.<\/p>\n\n\n\n
Der praktische Vorteil ist die Klarheit. Ingenieure m\u00fcssen nicht jeden CAN-Frame als isolierte propriet\u00e4re Nachricht behandeln, wenn eine definierte CANopen-Implementierung verwendet wird. Sie k\u00f6nnen mit dokumentierten Objekten und Kommunikationsdiensten arbeiten.<\/p>\n\n\n\n
PDOs, SDOs und Diagnose<\/h3>\n\n\n\n CANopen trennt unterschiedliche Kommunikationsaufgaben durch definierte Dienste. Process Data Objects, kurz PDOs, eignen sich zur Verarbeitung der im Betrieb ausgetauschten Informationen. Servicedatenobjekte oder SDOs bieten Zugriff auf Eintr\u00e4ge im Objektverzeichnis f\u00fcr Konfigurations- und Servicefunktionen.<\/p>\n\n\n\n
CANopen bietet au\u00dferdem Mechanismen zur Fehlerberichterstattung und Knoten\u00fcberwachung. Die CiA-Dokumentation identifiziert PDO-, SDO-, Notfall-, Heartbeat- und Netzwerkmanagementfunktionen als Teile der CANopen-Kommunikationsarchitektur.<\/p>\n\n\n\n
Bei einer CANopen-Batterie k\u00f6nnen h\u00e4ufig ben\u00f6tigte Betriebswerte in die PDO-Kommunikation abgebildet werden, w\u00e4hrend der SDO-Zugriff die Inbetriebnahme oder Diagnose unterst\u00fctzen kann. Die genaue Zuordnung sollte vor der Integration vereinbart und nicht angenommen werden.<\/p>\n\n\n\n
Aus diesem Grund kann eine Roboterbatterie, die erfolgreich \u00fcber propriet\u00e4res CAN kommuniziert, nicht automatisch als CANopen-kompatibel angesehen werden.<\/p>\n\n\n\n
Netzwerkmanagement und Heartbeats<\/h3>\n\n\n\n CANopen Network Management (NMT) definiert Kommunikationszust\u00e4nde f\u00fcr ein Ger\u00e4t. CiA identifiziert Initialisierungs-, Pre-Operational-, Operational- und Stopp-Zust\u00e4nde innerhalb der CANopen NMT-Zustandsmaschine. Die PDO-Kommunikation steht im Operational-Zustand zur Verf\u00fcgung, w\u00e4hrend die SDO-Kommunikation im Pre-Operational-Zustand genutzt werden kann.<\/p>\n\n\n\n
F\u00fcr die Roboterbatteriekommunikation helfen diese Zust\u00e4nde dabei, das Verhalten beim Start, bei der Inbetriebnahme, im Normalbetrieb, beim Herunterfahren und bei der Wiederherstellung zu definieren.<\/p>\n\n\n\n
Heartbeat-Mechanismen bieten eine weitere n\u00fctzliche Funktion, indem sie es dem Controller erm\u00f6glichen, zu bestimmen, ob ein erwarteter Knoten weiterhin im Netzwerk vorhanden ist. Eine CANopen-Batteriespezifikation sollte daher mehr als nur Batteriedatenfelder abdecken. F\u00fcr den Roboter k\u00f6nnen auch der Startstatus, das Heartbeat-Timing, die Timeout-Reaktion und das Wiederherstellungsverhalten von Bedeutung sein.<\/p>\n\n\n\n
Auswahl der richtigen Schnittstelle f\u00fcr AGVs und AMRs<\/h2>\n\n\n\n Die richtige Kommunikationsmethode ist diejenige, die zur vorhandenen Steuerungsarchitektur des Roboters passt und die von diesem System ben\u00f6tigten Batterieinformationen bereitstellt.<\/p>\n\n\n\n
Die Protokollauswahl sollte daher mit dem Host-Controller und der Ladearchitektur beginnen und nicht mit einer generischen Pr\u00e4ferenz f\u00fcr CAN oder RS485.<\/p>\n\n\n\n
Passen Sie das vorhandene Roboternetzwerk an<\/h3>\n\n\n\n Der erste Schritt besteht darin, genau zu bestimmen, was die Robotersteuerung erwartet. Ein Controller kann propriet\u00e4re CAN-Frames, CANopen, RS485 mit Modbus RTU oder ein anderes dokumentiertes Protokoll verwenden.<\/p>\n\n\n\nVorhandene Architektur<\/th> Entsprechende Anforderungen an die Roboterbatterie<\/th><\/tr><\/thead> Propriet\u00e4rer CAN-Controller<\/td> CAN-Batterie-BMS mit passender Bitrate und Nachrichtenzuordnung<\/td><\/tr> CANopen-Controller<\/td> BMS implementiert die erforderlichen CANopen-Objekte und das Netzwerkverhalten<\/td><\/tr> SPS oder Steuerung mit Modbus RTU<\/td> RS485-Batterie-BMS mit passenden seriellen Einstellungen und Registerzuordnung<\/td><\/tr> Separate Steuer- und Diagnosenetzwerke<\/td> Legen Sie fest, welche Verbindung die Batteriesteuerung und welche Servicedaten \u00fcbertr\u00e4gt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nDie Roboterbatterie sollte auf diese Netzwerkanforderungen abgestimmt sein. Wenn Sie ein Paket ausw\u00e4hlen, weil dessen Anschluss- oder Portbezeichnung bekannt vorkommt, wird der richtige Engineering-Prozess umgekehrt.<\/p>\n\n\n\n
Definieren Sie die erforderlichen Batteriedaten<\/h3>\n\n\n\n Bevor Ingenieure ein individuelles Paket anfordern, sollten sie eine Kommunikationsmatrix erstellen, die die f\u00fcr den Betrieb erforderlichen Daten von den Informationen trennt, die haupts\u00e4chlich f\u00fcr Diagnose oder Wartung bestimmt sind.<\/p>\n\n\n\n
F\u00fcr viele AGV- und AMR-Projekte ist das erforderlich Roboterbatterie<\/strong> Zu den Daten geh\u00f6ren:<\/p>\n\n\n\n\nPacken Sie Spannung und Strom ein<\/li>\n\n\n\n SOC und SOH<\/li>\n\n\n\n Batterietemperatur<\/li>\n\n\n\n Lade- und Entladegrenzen<\/li>\n\n\n\n Warn- und Schutzzust\u00e4nde<\/li>\n\n\n\n Ladestatus und BMS-Status<\/li>\n\n\n\n Ger\u00e4teidentit\u00e4t oder Netzwerkadresse<\/li>\n\n\n\n Sch\u00fctz- oder MOSFET-Status, wenn das System dies erfordert<\/li>\n<\/ul>\n\n\n\nDas Projekt sollte auch die Datenrichtung definieren. Einige Informationen werden vom AMR-Batterie-BMS an den Host \u00fcbertragen, w\u00e4hrend andere Architekturen m\u00f6glicherweise Steuerbefehle, Best\u00e4tigungen oder Konfigurationsmeldungen vom Controller erfordern.<\/p>\n\n\n\n
In diesem Schritt wird festgelegt, was die Schnittstelle tats\u00e4chlich leisten muss.<\/p>\n\n\n\n
\u00dcberpr\u00fcfen Sie das Timing und die Fehlerreaktion<\/h3>\n\n\n\n F\u00fcr eine vollst\u00e4ndige Kommunikationsspezifikation sind neben Datendefinitionen auch Timing-Anforderungen erforderlich.<\/p>\n\n\n\n
Ingenieure sollten festlegen, wie oft wichtige Informationen zur Roboterbatterie aktualisiert werden m\u00fcssen, wie lange die Steuerung wartet, bevor sie das BMS f\u00fcr offline erkl\u00e4rt, und welche Reaktion auf einen Kommunikations-Timeout folgt. CAN-Nachrichtenpriorit\u00e4ten oder RS485-Abfrageintervalle sollten die Bedeutung der \u00fcbertragenen Daten widerspiegeln.<\/p>\n\n\n\n
Auch bei der Fehlerbeseitigung ist ein definiertes Verhalten erforderlich. Das System sollte feststellen, ob die Kommunikation nach einem vor\u00fcbergehenden Ereignis automatisch wieder aufgenommen wird, ob das BMS einen Reset erfordert und ob der Roboter den Betrieb sofort wieder aufnehmen kann oder zun\u00e4chst den Batteriestatus \u00fcberpr\u00fcfen muss.<\/p>\n\n\n\n
Diese Entscheidungen sind anwendungsspezifisch. Sie sollten w\u00e4hrend der Integration dokumentiert und nicht aus der Kommunikationsschnittstelle abgeleitet werden.<\/p>\n\n\n\n
Planen Sie die Kommunikation mit der Ladestation<\/h3>\n\n\n\n Bei einem automatisch geladenen AGV oder AMR muss die Ladestation als Teil betrachtet werden Roboterbatterie<\/strong> Architektur.<\/p>\n\n\n\nDas Ladesystem muss m\u00f6glicherweise Ladeerlaubnis, Batteriespannung, Stromgrenzen, Temperaturstatus, Ladestatus, Abschluss und Fehlerbedingungen koordinieren. Physische Ladekontakte oder ein kontaktloser Stromempf\u00e4nger stellen den Strompfad bereit, sie definieren jedoch nicht das Kommunikationsverhalten.<\/p>\n\n\n\n
Der Roboter ben\u00f6tigt au\u00dferdem eine klare Reihenfolge f\u00fcr die Erkennung des Docks, die Aktivierung des Ladevorgangs, die Reaktion auf BMS-Grenzwerte, den Abschluss des Ladevorgangs und die R\u00fcckkehr zum Betrieb.<\/p>\n\n\n\n
Der aktuelle AMR-Integrationsleitfaden von MANLY Battery identifiziert CAN- oder RS485-Kommunikation, Strom- und Temperatur\u00fcberwachung, Steckerdesign und anwendungsspezifische Verkabelung als zu koordinierende Faktoren bei der Integration einer AMR-Batterie, eines BMS und einer Ladestation.<\/p>\n\n\n\n
F\u00fcr autonome Flotten sollte die Ladekommunikation daher gleichzeitig mit der Roboterbatterie und dem BMS entworfen werden und nicht erst, nachdem das Paket bereits fertiggestellt wurde.<\/p>\n\n\n\n
Ber\u00fccksichtigen Sie die Anforderungen an die Flottendiagnose<\/h3>\n\n\n\n Steuerverkehr und Wartungsdaten m\u00fcssen nicht immer denselben Kommunikationspfad verwenden. Einige Roboter platzieren zeitkritische Batteriedaten im prim\u00e4ren CAN-Netzwerk und nutzen gleichzeitig eine separate Schnittstelle f\u00fcr Inbetriebnahme, Wartung oder tiefergehende Diagnosen.<\/p>\n\n\n\n
Entscheidend ist, dass die Diagnosearchitektur bewusst ist.<\/p>\n\n\n\n
Bei gro\u00dfen Flotten k\u00f6nnen konsistente Datendefinitionen f\u00fcr Roboterbatterien die Fehlerbehebung bei vielen Fahrzeugen vereinfachen. Fehlercodes, Einheiten, Skalierung, Firmware-Versionen, Kommunikationszust\u00e4nde und Wartungsaufzeichnungen sollten von einem Roboter zum anderen wiederholbare Bedeutungen haben.<\/p>\n\n\n\n
Dies kann besonders wertvoll sein, wenn Flottensoftware verwendet wird, um energiebezogene Ereignisse von BMS-Fehlern, Ladeger\u00e4tfehlern oder Kommunikationsfehlern zu unterscheiden.<\/p>\n\n\n\n
Was Sie einen Batteriehersteller vor der Integration fragen sollten<\/h2>\n\n\n\n A Batteriehersteller<\/a><\/strong> sollte in der Lage sein, die BMS-Kommunikation mit den gleichen technischen Details zu besprechen, die auch f\u00fcr Packspannung, Kapazit\u00e4t, Strom, Abmessungen und Steckeranforderungen verwendet werden.<\/p>\n\n\n\n\u201cCAN verf\u00fcgbar\u201d oder \u201cRS485 verf\u00fcgbar\u201d ist f\u00fcr die erste \u00dcberpr\u00fcfung n\u00fctzlich, eine Produktionsroboterbatterie erfordert jedoch eine umfassendere Kommunikationsspezifikation.<\/p>\n\n\n\n
Protokoll- und Nachrichtenkarte<\/h3>\n\n\n\n Fordern Sie f\u00fcr die CAN-Integration das Anwendungsprotokoll, CAN-Identifikatoren, Nutzlastdefinitionen, Skalierung, Nachrichtenrichtung, \u00dcbertragungszeitpunkt und Timeout-Verhalten an.<\/p>\n\n\n\n
Definieren Sie f\u00fcr eine CANopen-Batterie die erforderlichen Objektverzeichniseintr\u00e4ge, PDO-Zuordnungen, SDO-Zugriffe, NMT-Verhalten, Heartbeat-Anforderungen und steuerungsspezifische Funktionen.<\/p>\n\n\n\n
Wenn das Projekt herstellerspezifische CAN-Kommunikation verwendet, sollte die Nachrichtendefinition fr\u00fch genug f\u00fcr die Controller-Entwicklung und den Pr\u00fcfstandstest verf\u00fcgbar sein. Das Softwareteam sollte kein Reverse Engineering durchf\u00fchren m\u00fcssen Roboterbatterie<\/strong> nachdem Prototyp-Hardware eingetroffen ist.<\/p>\n\n\n\nBaudrate und Knoten-IDs<\/h3>\n\n\n\n Beide Seiten der Verbindung m\u00fcssen kompatible Netzwerkeinstellungen verwenden.<\/p>\n\n\n\n
Best\u00e4tigen Sie f\u00fcr CAN die CAN-Bitrate und die relevante Kennung oder Knotenkonfiguration. Definieren Sie f\u00fcr CANopen au\u00dferdem Knoten-IDs und das erforderliche Netzwerkverwaltungsverhalten. Best\u00e4tigen Sie bei einem RS485-Batterie-BMS die Baudrate, Parit\u00e4t, Stoppbits, Adressierung und das erwartete Abfrage- oder Antwortverhalten.<\/p>\n\n\n\n
Diese Parameter sollten in der Projektkommunikationsspezifikation aufgezeichnet und wie jede andere Schnittstellenanforderung auf Systemebene gesteuert werden.<\/p>\n\n\n\n
Registrieren Sie die Karten- und Datenskalierung<\/h3>\n\n\n\n F\u00fcr eine RS485-Verbindung \u00fcber Modbus RTU ist eine vollst\u00e4ndige Registerzuordnung erforderlich. Jeder erforderliche Wert sollte eine definierte Adresse, einen Datentyp, einen Skalierungsfaktor, eine technische Einheit und eine Zugriffsmethode haben.<\/p>\n\n\n\n
Beispielsweise kann ein \u00fcbertragener Wert erst dann richtig interpretiert werden, wenn die Steuerung wei\u00df, ob er Volt, Millivolt, Zehntel Volt, vorzeichenbehafteten Strom oder eine andere Kodierung darstellt.<\/p>\n\n\n\n
Das gleiche Prinzip gilt f\u00fcr CAN. Der Empfang eines g\u00fcltigen CAN-Frames beweist nicht, dass der Roboterbatterie<\/strong> Die Daten wurden korrekt interpretiert. Bytereihenfolge, Bitdefinitionen, Skalierung, vorzeichenbehaftete Werte und Statusflags m\u00fcssen weiterhin \u00fcbereinstimmen.<\/p>\n\n\n\nTerminierung, Pinbelegung und Anschl\u00fcsse<\/h3>\n\n\n\n Die elektrische Dokumentation sollte alle erforderlichen Kommunikationspins angeben, einschlie\u00dflich CAN-H, CAN-L, RS485-A, RS485-B, Signalerde, Wake-Leitungen, Abschirmung oder andere projektspezifische Leiter.<\/p>\n\n\n\n
Auch die Terminierung muss zur gew\u00e4hlten Netzwerktopologie passen. Ingenieure sollten \u00fcberpr\u00fcfen, ob sich der Abschluss in der Roboterbatterie befindet, an anderer Stelle am Roboter installiert, konfigurierbar oder weggelassen ist.<\/p>\n\n\n\n
Die Steckerform sollte niemals als Ersatz f\u00fcr diese Dokumentation verwendet werden. Ein Stecker im RJ45-Stil weist beispielsweise nicht automatisch auf Ethernet hin und stellt keine standardisierte CAN- oder RS485-Pinbelegung dar.<\/p>\n\n\n\n
Das Kabel- und Steckerdesign geh\u00f6rt daher in die Kommunikationsspezifikation und nicht nur in die mechanische Zeichnung.<\/p>\n\n\n\n
Anforderungen an die Kommunikation mit dem Ladeger\u00e4t<\/h3>\n\n\n\n Wenn der Ladevorgang Kommunikation erfordert, sollten die Batterie und das Ladeger\u00e4t des Roboters als koordiniertes System konstruiert werden.<\/p>\n\n\n\n
Die Spezifikation sollte festlegen, ob das Ladeger\u00e4t feste elektrische Einstellungen verwendet oder dynamische Grenzwerte vom BMS oder der Fahrzeugsteuerung erh\u00e4lt. Es sollte auch die Ladeaktivierungslogik, Strom- und Spannungsgrenzen, thermisches Verhalten, Ladestatus, Ladeabschluss, Fehlerreaktion, Dock-Handshaking und Wiederherstellung nach unterbrochenem Ladevorgang dokumentieren.<\/p>\n\n\n\n
Bei einem AGV oder AMR, das auf unbeaufsichtigtes Laden angewiesen ist, k\u00f6nnen diese Funktionen direkten Einfluss darauf haben, wie zuverl\u00e4ssig der Roboter nach Erreichen des Docks wieder in Betrieb geht.<\/p>\n\n\n\n
MANLY-Batteriekommunikationsoptionen<\/h3>\n\n\n\n Bei MANLY Battery k\u00f6nnen Roboter- und Industriebatterieprojekte rund um die Kommunikationsanforderungen der Anwendung entwickelt werden, anstatt die Schnittstelle als isoliertes Add-on zu behandeln.<\/p>\n\n\n\n
Die MANLY 24V 50Ah-Roboterbatterie ist ein LiFePO4-Akku mit einer Nennspannung von 24 V, einer tats\u00e4chlichen Batteriespannung von 25,6 V und einer Nennenergie von 1.280 Wh. Die aktuelle Spezifikation bietet optionale RS485-, RS232- oder CANBus-Kommunikation. Abmessungen, Geh\u00e4use, Stecker, Geh\u00e4use und Verkabelung k\u00f6nnen auch f\u00fcr OEM\/ODM-Anforderungen konfiguriert werden.<\/p>\n\n\n\n
F\u00fcr Industrieroboter, die eine gr\u00f6\u00dfere Bordkapazit\u00e4t ben\u00f6tigen, bietet die MANLY 48V 100Ah-Roboterbatterie eine Kapazit\u00e4t von 100 Ah und eine Nennenergie von 4.800 Wh. Es unterst\u00fctzt auch optionale RS485-, RS232- oder CANBus-Kommunikation mit anpassbaren Abmessungen, Geh\u00e4use, Anschl\u00fcssen und Verkabelung.<\/p>\n\n\n\nMANLY-Roboterbatterie<\/th> Kommunikation<\/th> Integrationsschwerpunkt<\/th><\/tr><\/thead> 24V 50Ah LiFePO4 Roboterbatterie<\/td> Optional RS485, RS232, CANBus<\/td> Roboter- und AGV-Projekte, die konfigurierbare BMS-Kommunikation, Anschl\u00fcsse und Packungsabmessungen erfordern<\/td><\/tr> 48V 100Ah Industrieroboterbatterie<\/td> Optional RS485, RS232, CANBus<\/td> Industrieroboteranwendungen mit h\u00f6herer Kapazit\u00e4t, die eine koordinierte BMS-, Controller-, Ladeger\u00e4t- und Pack-Integration erfordern<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWenn ein Projekt speziell eine CANopen-Batteriekommunikation erfordert, sollte diese Anforderung w\u00e4hrend der technischen Pr\u00fcfung definiert werden. Die CANBus-Verf\u00fcgbarkeit allein sollte nicht als Best\u00e4tigung der CANopen-Kompatibilit\u00e4t gewertet werden.<\/p>\n\n\n\n
Das Projektteam sollte die erforderliche CANopen-Objektzuordnung, Netzwerkkonfiguration, Controller-Verhalten und andere Protokollanforderungen bereitstellen, damit die Implementierung vorab evaluiert werden kann Roboterbatterie<\/strong> Der Entwurf ist fertiggestellt.<\/p>\n\n\n\nF\u00fcr CAN- oder RS485-Projekte gilt das gleiche Prinzip. Durch die Bereitstellung der Controller-Spezifikation, der Nachrichten- oder Registerzuordnung, der Kommunikationsgeschwindigkeit, der Pinbelegung, der Ladeger\u00e4tarchitektur, der Spannung, der Kapazit\u00e4t, der Stromanforderungen und des erwarteten Fehlerverhaltens erh\u00e4lt der Batteriehersteller ein viel klareres Integrationsziel.<\/p>\n\n\n\n
Das Richtige Roboterbatteriekommunikation<\/strong> Die Methode wird daher nicht durch die isolierte Auswahl von CAN, RS485 oder CANopen bestimmt. Dies h\u00e4ngt davon ab, ob BMS, Robotersteuerung, Ladeger\u00e4t, Verkabelung, Protokoll und Betriebslogik so konzipiert sind, dass sie als ein System zusammenarbeiten.<\/p>\n\n\n\n
![\"Manly](\"https:\/\/manlybattery.com\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs.webp\")
<\/a><\/figure>\n\n\n\n![\"Manly](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs-300x200.webp\")
![\"Rechenzentren](\"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\")
![\"Notstromversorgungsl\u00f6sung\"](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Backup-battery-solution-300x300.webp\")