CAN, RS485 und CANopen: Welche Kommunikation benötigt eine Roboterbatterie?

A Roboterbatterie benötigt eine Kommunikationsschnittstelle und ein Protokoll, die zur Robotersteuerung, zum Ladegerät, zu den BMS-Datenanforderungen und zur Netzwerkarchitektur passen. CAN eignet sich gut für die prioritätsbasierte Kommunikation über mehrere Knoten hinweg. RS485 bietet eine robuste differenzielle serielle Schnittstelle und wird häufig mit einem Anwendungsprotokoll wie Modbus RTU kombiniert. CANopen fügt CAN ein standardisiertes übergeordnetes Kommunikations-Framework hinzu.

Es gibt keine einheitliche Kommunikationsmethode, die jedes AGV oder AMR verwenden sollte. Für zuverlässig Roboterbatterie Kommunikation muss die Kompatibilität über den Stecker hinausgehen. Die elektrische Schnittstelle, Bit- oder Baudrate, Nachrichtenstruktur, Datenzuordnung, Adressierung, Timing, Fehlerverhalten und Ladelogik müssen alle zum Hostsystem passen.

Was muss eine Roboterbatterie kommunizieren?

A Roboterbatterie kommuniziert, weil der Roboter mehr als nur elektrische Energie benötigt. Sein Batteriemanagementsystem muss ausgewählte Batteriezustände und Betriebsgrenzen für Geräte wie Fahrzeugsteuerung, Ladegerät, Ladestation, Diagnosecomputer oder Flottenmanagement-Gateway verfügbar machen.

Batteriedaten, die der Roboter benötigt

Ein AMR-Batterie-BMS misst oder berechnet mehrere Kategorien von Informationen. Der Controller benötigt möglicherweise nicht kontinuierlich jeden internen Zellenwert, sollte aber die für Betrieb, Ladung, Diagnose und Wartung erforderlichen Daten erhalten.

Datenkategorie	Typische Informationen	So verwendet der Roboter it
Elektrischer Status	Packspannung, Strom, Restkapazität	Überwacht den aktuellen Batteriezustand
Wärme- und Zellstatus	Zellspannung, Packtemperatur, Zelltemperatur	Unterstützt Schutz- und Betriebsentscheidungen
Batterieschätzungen	SOC, SOH	Unterstützt die Laufzeit- und Wartungsplanung
Betriebsgrenzen	Ladestrom, Entladestrom, Ladespannung	Hilft dabei, den Betrieb innerhalb der BMS-Grenzwerte zu halten
Fehler- und Warndaten	Überspannung, Unterspannung, Übertemperatur, Überstrom	Unterstützt eine kontrollierte Fehlerreaktion
Systemstatus	Laden, Entladen, Standby, Schutzzustand	Koordiniert das Roboterverhalten
Identifikation	Geräteadresse, Protokollversion, Batterieidentität	Unterstützt Anerkennung und Service

Dies steht auch im Einklang mit dem modernen BMS-Design für mobile Robotik. Die robotikorientierten BMS-Referenzplattformen von NXP kombinieren Zell- und Packspannungsmessung, Strommessung, Temperaturmessung und CAN-Konnektivität innerhalb derselben Batteriemanagementarchitektur.

Die Kommunikationsspezifikation für eine Roboterbatterie sollte daher mit den Daten beginnen, die der Roboter benötigt, und nicht mit einem bevorzugten Stecker oder Busnamen.

SOC, SOH und Fehlerberichterstattung

Der SOC gibt dem Roboter eine Schätzung der verbleibenden Ladung, während der SOH den längerfristigen Batteriezustand darstellt. Beide sind wertvoll, aber keines davon sollte als vollständige Kommunikationsanforderung betrachtet werden.

A Roboterbatterie kann auch Temperaturen, Strom, Warnzustände, Schutzbedingungen und zulässige Lade- oder Entladegrenzen melden. Wenn sich die Betriebsbedingungen ändern, liefern diese Werte der Fahrzeugsteuerung Informationen, die sie nutzen kann, bevor das BMS einen harten Schutzzustand erreicht.

Dies macht die Batteriekommunikation des Roboters sowohl für den sofortigen Betrieb als auch für die Wartung nützlich. Flottensoftware kann konsistente Status- und Fehlerinformationen verwenden, um einen Niedrigenergiezustand von einem thermischen Ereignis, einem Schutzereignis oder einem Kommunikationsfehler zu unterscheiden.

Controller- und Ladegerät-Handshakes

Fahrzeugsteuerung und Ladegerät benötigen nicht unbedingt identische Batteriedaten. Während der Bewegung kann die Steuerung SOC, Spannung, Strom, Temperatur, Warnungen und Entladegrenzen priorisieren. Während des Ladevorgangs benötigt das System möglicherweise auch eine Ladeerlaubnis, Ladestromgrenzen, Spannungsgrenzen, Temperaturstatus und Informationen zum Ladezustand.

Aus diesem Grund ist die Angabe eines CAN-Batterie-BMS oder RS485-Batterie-BMS nur der erste Schritt. Zwei Geräte können sich dieselbe elektrische Schnittstelle teilen, jedoch unterschiedliche Kennungen, Register, Skalierungsfaktoren, Aktualisierungsintervalle oder Steuerlogik verwenden.

Durch die automatische Aufladung ist die Unterscheidung besonders wichtig. Wenn ein AGV oder AMR ohne Bedienereingriff andockt, benötigen die Roboterbatterie, das Ladegerät und die Steuerung ein definiertes Verhalten für die Ladeautorisierung, Betriebsgrenzen, Fehlerbehandlung, Ladeabschluss und Wiederinbetriebnahme.

Warum Kommunikation die Betriebszeit beeinflusst

Durch die nützliche Batteriekommunikation kann der Roboter auf den Batteriezustand reagieren, bevor ein hartes Herunterfahren die einzige verfügbare Reaktion ist. Ein niedriger Ladezustand kann eine Ladeaufgabe auslösen, eine Temperaturbedingung kann das Ladeverhalten beeinflussen und ein gemeldeter Fehler kann das Fahrzeug in einen definierten Betriebszustand versetzen.

Bei Flotten verbessern konsistente Roboterbatteriedaten auch die Fehlerbehebung. Wartungsteams können Betriebszustände und Alarme überprüfen, anstatt jeden Antriebsverlust oder jede Ladeunterbrechung als dasselbe Problem zu behandeln.

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.

CAN vs. RS485: Wie sie sich in Robotersystemen unterscheiden

CAN und RS485 sind beide in industriellen Systemen üblich, lösen jedoch unterschiedliche Teile des Kommunikationsproblems. CAN bietet Mechanismen für Nachrichtenrahmen, Arbitrierung, Bestätigung und Fehlermanagement für einen gemeinsam genutzten Bus. RS485 definiert in erster Linie die elektrische Signalisierung, die für die serielle Kommunikation verwendet wird.

Diese Unterscheidung ist wichtig, wenn Ingenieure eine Kommunikationsarchitektur für eine Roboterbatterie auswählen.

CAN als Netzwerk

CAN ist für die Kommunikation mehrerer Geräte über einen gemeinsamen Bus konzipiert. Nachrichten werden durch CAN-Identifier identifiziert und gleichzeitige Übertragungsversuche werden durch prioritätsbasierte Arbitrierung gelöst.

Für die Roboterbatteriekommunikation kann diese Architektur regelmäßige Statusmeldungen, Betriebsgrenzen, Warninformationen und ereignisgesteuerte Fehlerberichte unterstützen. Das aktuelle BMS-Referenzdesign MR-BMS771 für mobile Robotik von NXP umfasst zwei CAN-Busse und stellt ein praktisches Beispiel für die direkte Integration von CAN in eine Robotik-Batteriemanagementplattform dar.

Ein CAN-Port allein definiert jedoch nicht die Bedeutung der Daten. Ein CAN-Batterie-BMS und eine Robotersteuerung benötigen weiterhin kompatible Bitraten, Identifikatoren, Nutzlastdefinitionen, Skalierung, Übertragungszeitpunkt und Anwendungslogik.

RS485 als physikalische Schnittstelle

RS485 ist eine differenzielle serielle Schnittstelle, die häufig in der industriellen Mehrpunktkommunikation verwendet wird. Dies ist besonders nützlich, wenn Geräte bereits serielle Netzwerke verwenden oder ein Controller mit mehreren adressierten Geräten kommuniziert.

Bei einer Roboterbatterie besteht der entscheidende Punkt darin, dass RS485 allein der Steuerung nicht mitteilt, was ein Byte bedeutet. Ein RS485-Batterie-BMS benötigt weiterhin ein definiertes Anwendungsprotokoll oder eine proprietäre Datenstruktur.

Diese Unterscheidung erklärt, warum RS485 und Modbus RTU häufig zusammen vorkommen, ohne synonym zu sein. Die Modbus Organization dokumentiert Modbus Serial Line-Implementierungen mithilfe von EIA/TIA-485, während Modbus selbst das Nachrichtenverhalten auf höherer Ebene definiert.

In einer Kaufspezifikation sollte daher mehr stehen als “RS485 erforderlich”. Es sollte das tatsächliche Protokoll und die vom Roboter erwartete Datenkarte identifizieren.

CAN-Schiedsverfahren und Fehlerbehandlung

Mit CAN können Knoten senden, ohne darauf warten zu müssen, dass ein zentraler Controller jede Übertragungsmöglichkeit zuweist. Wenn zwei Knoten gleichzeitig mit der Übertragung beginnen, bestimmt die Schlichtung auf Basis der Nachrichtenkennungen, welcher Frame fortgesetzt wird.

CAN umfasst auch Mechanismen zur Erkennung von Übertragungsfehlern und zur Verwaltung von Knoten, die wiederholt Fehler erzeugen. Diese Eigenschaften machen es für Netzwerke geeignet, in denen die Roboterbatterie müssen regelmäßig Betriebsdaten mit anderen Steuerungen austauschen.

Die technische Entscheidung sollte nicht auf die allgemeine Behauptung reduziert werden, dass CAN einfach “schneller” sei. Entscheidend ist, ob die erforderlichen Batteriemeldungen mit der erforderlichen Priorität und Aktualisierungszeit unter der erwarteten Buslast zugestellt werden können.

Für einen mobilen Roboter ist ein kleiner Satz korrekt priorisierter und dokumentierter Batteriemeldungen oft wertvoller als eine theoretisch hohe Datenrate mit schlecht definiertem Anwendungsverhalten.

Modbus RTU über RS485

Modbus RTU bietet eine Nachrichtenstruktur auf Anwendungsebene, die über eine serielle RS485-Verbindung betrieben werden kann. Das Protokoll definiert, wie adressierte Geräte Anfragen und Antworten austauschen, während die gerätespezifische Registerzuordnung angibt, wo einzelne Werte gespeichert werden.

Für eine Roboterbatterie kann eine Modbus-RTU-Karte Register für Packspannung, Strom, SOC, Temperatur, Alarme oder Betriebsgrenzen enthalten. Für eine korrekte Interpretation muss der Controller die Registeradresse, das Datenformat, den Skalierungsfaktor, die Bytereihenfolge, die Geräteadresse, die Baudrate, die Parität und das Timeout-Verhalten kennen.

Bei der Integration sind mehrere Unterscheidungen wichtig: RS485 bedeutet nicht automatisch Modbus RTU; zwei Modbus-Geräte verwenden nicht automatisch dieselbe Registerzuordnung; ein RJ45-Anschluss stellt keine Ethernet-, CAN- oder RS485-Kompatibilität her; und eine elektrisch gültige Verbindung garantiert keine Kompatibilität auf Anwendungsebene.

Diese Prüfungen verhindern einen häufigen Integrationsfehler: Beide Seiten unterstützen offenbar die gleiche Kommunikationstechnologie, doch Roboterbatterie und Steuerung können die Daten des jeweils anderen nicht verstehen.

Wo CANopen in ein Roboterbatteriesystem passt

CANopen sitzt im Kommunikationsstapel über CAN. Es ersetzt nicht den CAN-Bus. Stattdessen definiert CANopen standardisierte Mechanismen zur Organisation von Gerätedaten, zur Übertragung von Prozessinformationen, zum Zugriff auf Konfigurationsparameter, zur Steuerung von Netzwerkzuständen und zur Überwachung von Netzwerkteilnehmern.

Eine CANopen-Batterieimplementierung erfordert daher mehr als einen CAN-Transceiver oder CAN-Stecker. Das BMS muss die vom Host-Controller benötigten CANopen-Funktionen implementieren.

CAN ist nicht CANopen

CAN stellt den zugrunde liegenden Netzwerkkommunikationsmechanismus bereit. CANopen fügt die übergeordnete Struktur hinzu, die bestimmt, wie CAN-basierte Geräte Anwendungsdaten organisieren und austauschen.

CAN in Automation (CiA) beschreibt ein CANopen-Gerät mit einem CANopen-Protokollstapel, Anwendungssoftware und einem Objektverzeichnis, das das Kommunikationssystem mit Anwendungsparametern verbindet.

Daher ist eine Beschaffungsregel besonders wichtig:

CAN-Unterstützung bedeutet nicht automatisch CANopen-Unterstützung.

Wenn ein AMR-Controller eine CANopen-Batterie benötigt, sollte die Spezifikation die vom Controller erwarteten CANopen-Funktionalitäten und Datenzuordnungen angeben. Die bloße Anforderung eines CAN-Ports reicht nicht aus.

Das CANopen-Objektverzeichnis

Das Objektverzeichnis ist das strukturierte Datenmodell, das von CANopen-Geräten verwendet wird. CiA legt fest, dass Kommunikations- und Anwendungsparameter durch indizierte Objektwörterbucheinträge organisiert werden, wobei Index- und Subindexwerte definierte Adressen für Daten bereitstellen.

Bei einer CANopen-Batterieintegration kann diese Struktur eine konsistente Möglichkeit bieten, Batteriestatus, Konfigurationsparameter und Diagnoseinformationen offenzulegen. Die tatsächlichen Batterieobjekte müssen weiterhin den Anforderungen des Controllers und allen anwendbaren Profilen oder Projektspezifikationen entsprechen.

Der praktische Vorteil ist die Klarheit. Ingenieure müssen nicht jeden CAN-Frame als isolierte proprietäre Nachricht behandeln, wenn eine definierte CANopen-Implementierung verwendet wird. Sie können mit dokumentierten Objekten und Kommunikationsdiensten arbeiten.

PDOs, SDOs und Diagnose

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äge im Objektverzeichnis für Konfigurations- und Servicefunktionen.

CANopen bietet außerdem Mechanismen zur Fehlerberichterstattung und Knotenüberwachung. Die CiA-Dokumentation identifiziert PDO-, SDO-, Notfall-, Heartbeat- und Netzwerkmanagementfunktionen als Teile der CANopen-Kommunikationsarchitektur.

Bei einer CANopen-Batterie können häufig benötigte Betriebswerte in die PDO-Kommunikation abgebildet werden, während der SDO-Zugriff die Inbetriebnahme oder Diagnose unterstützen kann. Die genaue Zuordnung sollte vor der Integration vereinbart und nicht angenommen werden.

Aus diesem Grund kann eine Roboterbatterie, die erfolgreich über proprietäres CAN kommuniziert, nicht automatisch als CANopen-kompatibel angesehen werden.

Netzwerkmanagement und Heartbeats

CANopen Network Management (NMT) definiert Kommunikationszustände für ein Gerät. CiA identifiziert Initialisierungs-, Pre-Operational-, Operational- und Stopp-Zustände innerhalb der CANopen NMT-Zustandsmaschine. Die PDO-Kommunikation steht im Operational-Zustand zur Verfügung, während die SDO-Kommunikation im Pre-Operational-Zustand genutzt werden kann.

Für die Roboterbatteriekommunikation helfen diese Zustände dabei, das Verhalten beim Start, bei der Inbetriebnahme, im Normalbetrieb, beim Herunterfahren und bei der Wiederherstellung zu definieren.

Heartbeat-Mechanismen bieten eine weitere nützliche Funktion, indem sie es dem Controller ermöglichen, zu bestimmen, ob ein erwarteter Knoten weiterhin im Netzwerk vorhanden ist. Eine CANopen-Batteriespezifikation sollte daher mehr als nur Batteriedatenfelder abdecken. Für den Roboter können auch der Startstatus, das Heartbeat-Timing, die Timeout-Reaktion und das Wiederherstellungsverhalten von Bedeutung sein.

Auswahl der richtigen Schnittstelle für AGVs und AMRs

Die richtige Kommunikationsmethode ist diejenige, die zur vorhandenen Steuerungsarchitektur des Roboters passt und die von diesem System benötigten Batterieinformationen bereitstellt.

Die Protokollauswahl sollte daher mit dem Host-Controller und der Ladearchitektur beginnen und nicht mit einer generischen Präferenz für CAN oder RS485.

Passen Sie das vorhandene Roboternetzwerk an

Der erste Schritt besteht darin, genau zu bestimmen, was die Robotersteuerung erwartet. Ein Controller kann proprietäre CAN-Frames, CANopen, RS485 mit Modbus RTU oder ein anderes dokumentiertes Protokoll verwenden.

Vorhandene Architektur	Entsprechende Anforderungen an die Roboterbatterie
Proprietärer CAN-Controller	CAN-Batterie-BMS mit passender Bitrate und Nachrichtenzuordnung
CANopen-Controller	BMS implementiert die erforderlichen CANopen-Objekte und das Netzwerkverhalten
SPS oder Steuerung mit Modbus RTU	RS485-Batterie-BMS mit passenden seriellen Einstellungen und Registerzuordnung
Separate Steuer- und Diagnosenetzwerke	Legen Sie fest, welche Verbindung die Batteriesteuerung und welche Servicedaten überträgt

Die Roboterbatterie sollte auf diese Netzwerkanforderungen abgestimmt sein. Wenn Sie ein Paket auswählen, weil dessen Anschluss- oder Portbezeichnung bekannt vorkommt, wird der richtige Engineering-Prozess umgekehrt.

Definieren Sie die erforderlichen Batteriedaten

Bevor Ingenieure ein individuelles Paket anfordern, sollten sie eine Kommunikationsmatrix erstellen, die die für den Betrieb erforderlichen Daten von den Informationen trennt, die hauptsächlich für Diagnose oder Wartung bestimmt sind.

Für viele AGV- und AMR-Projekte ist das erforderlich Roboterbatterie Zu den Daten gehören:

• Packen Sie Spannung und Strom ein
• SOC und SOH
• Batterietemperatur
• Lade- und Entladegrenzen
• Warn- und Schutzzustände
• Ladestatus und BMS-Status
• Geräteidentität oder Netzwerkadresse
• Schütz- oder MOSFET-Status, wenn das System dies erfordert

Das Projekt sollte auch die Datenrichtung definieren. Einige Informationen werden vom AMR-Batterie-BMS an den Host übertragen, während andere Architekturen möglicherweise Steuerbefehle, Bestätigungen oder Konfigurationsmeldungen vom Controller erfordern.

In diesem Schritt wird festgelegt, was die Schnittstelle tatsächlich leisten muss.

Überprüfen Sie das Timing und die Fehlerreaktion

Für eine vollständige Kommunikationsspezifikation sind neben Datendefinitionen auch Timing-Anforderungen erforderlich.

Ingenieure sollten festlegen, wie oft wichtige Informationen zur Roboterbatterie aktualisiert werden müssen, wie lange die Steuerung wartet, bevor sie das BMS für offline erklärt, und welche Reaktion auf einen Kommunikations-Timeout folgt. CAN-Nachrichtenprioritäten oder RS485-Abfrageintervalle sollten die Bedeutung der übertragenen Daten widerspiegeln.

Auch bei der Fehlerbeseitigung ist ein definiertes Verhalten erforderlich. Das System sollte feststellen, ob die Kommunikation nach einem vorübergehenden Ereignis automatisch wieder aufgenommen wird, ob das BMS einen Reset erfordert und ob der Roboter den Betrieb sofort wieder aufnehmen kann oder zunächst den Batteriestatus überprüfen muss.

Diese Entscheidungen sind anwendungsspezifisch. Sie sollten während der Integration dokumentiert und nicht aus der Kommunikationsschnittstelle abgeleitet werden.

Planen Sie die Kommunikation mit der Ladestation

Bei einem automatisch geladenen AGV oder AMR muss die Ladestation als Teil betrachtet werden Roboterbatterie Architektur.

Das Ladesystem muss möglicherweise Ladeerlaubnis, Batteriespannung, Stromgrenzen, Temperaturstatus, Ladestatus, Abschluss und Fehlerbedingungen koordinieren. Physische Ladekontakte oder ein kontaktloser Stromempfänger stellen den Strompfad bereit, sie definieren jedoch nicht das Kommunikationsverhalten.

Der Roboter benötigt außerdem eine klare Reihenfolge für die Erkennung des Docks, die Aktivierung des Ladevorgangs, die Reaktion auf BMS-Grenzwerte, den Abschluss des Ladevorgangs und die Rückkehr zum Betrieb.

Der aktuelle AMR-Integrationsleitfaden von MANLY Battery identifiziert CAN- oder RS485-Kommunikation, Strom- und Temperaturüberwachung, Steckerdesign und anwendungsspezifische Verkabelung als zu koordinierende Faktoren bei der Integration einer AMR-Batterie, eines BMS und einer Ladestation.

Für autonome Flotten sollte die Ladekommunikation daher gleichzeitig mit der Roboterbatterie und dem BMS entworfen werden und nicht erst, nachdem das Paket bereits fertiggestellt wurde.

Berücksichtigen Sie die Anforderungen an die Flottendiagnose

Steuerverkehr und Wartungsdaten müssen nicht immer denselben Kommunikationspfad verwenden. Einige Roboter platzieren zeitkritische Batteriedaten im primären CAN-Netzwerk und nutzen gleichzeitig eine separate Schnittstelle für Inbetriebnahme, Wartung oder tiefergehende Diagnosen.

Entscheidend ist, dass die Diagnosearchitektur bewusst ist.

Bei großen Flotten können konsistente Datendefinitionen für Roboterbatterien die Fehlerbehebung bei vielen Fahrzeugen vereinfachen. Fehlercodes, Einheiten, Skalierung, Firmware-Versionen, Kommunikationszustände und Wartungsaufzeichnungen sollten von einem Roboter zum anderen wiederholbare Bedeutungen haben.

Dies kann besonders wertvoll sein, wenn Flottensoftware verwendet wird, um energiebezogene Ereignisse von BMS-Fehlern, Ladegerätfehlern oder Kommunikationsfehlern zu unterscheiden.

Was Sie einen Batteriehersteller vor der Integration fragen sollten

A Batteriehersteller sollte in der Lage sein, die BMS-Kommunikation mit den gleichen technischen Details zu besprechen, die auch für Packspannung, Kapazität, Strom, Abmessungen und Steckeranforderungen verwendet werden.

“CAN verfügbar” oder “RS485 verfügbar” ist für die erste Überprüfung nützlich, eine Produktionsroboterbatterie erfordert jedoch eine umfassendere Kommunikationsspezifikation.

Protokoll- und Nachrichtenkarte

Fordern Sie für die CAN-Integration das Anwendungsprotokoll, CAN-Identifikatoren, Nutzlastdefinitionen, Skalierung, Nachrichtenrichtung, Übertragungszeitpunkt und Timeout-Verhalten an.

Definieren Sie für eine CANopen-Batterie die erforderlichen Objektverzeichniseinträge, PDO-Zuordnungen, SDO-Zugriffe, NMT-Verhalten, Heartbeat-Anforderungen und steuerungsspezifische Funktionen.

Wenn das Projekt herstellerspezifische CAN-Kommunikation verwendet, sollte die Nachrichtendefinition früh genug für die Controller-Entwicklung und den Prüfstandstest verfügbar sein. Das Softwareteam sollte kein Reverse Engineering durchführen müssen Roboterbatterie nachdem Prototyp-Hardware eingetroffen ist.

Baudrate und Knoten-IDs

Beide Seiten der Verbindung müssen kompatible Netzwerkeinstellungen verwenden.

Bestätigen Sie für CAN die CAN-Bitrate und die relevante Kennung oder Knotenkonfiguration. Definieren Sie für CANopen außerdem Knoten-IDs und das erforderliche Netzwerkverwaltungsverhalten. Bestätigen Sie bei einem RS485-Batterie-BMS die Baudrate, Parität, Stoppbits, Adressierung und das erwartete Abfrage- oder Antwortverhalten.

Diese Parameter sollten in der Projektkommunikationsspezifikation aufgezeichnet und wie jede andere Schnittstellenanforderung auf Systemebene gesteuert werden.

Registrieren Sie die Karten- und Datenskalierung

Für eine RS485-Verbindung über Modbus RTU ist eine vollständige Registerzuordnung erforderlich. Jeder erforderliche Wert sollte eine definierte Adresse, einen Datentyp, einen Skalierungsfaktor, eine technische Einheit und eine Zugriffsmethode haben.

Beispielsweise kann ein übertragener Wert erst dann richtig interpretiert werden, wenn die Steuerung weiß, ob er Volt, Millivolt, Zehntel Volt, vorzeichenbehafteten Strom oder eine andere Kodierung darstellt.

Das gleiche Prinzip gilt für CAN. Der Empfang eines gültigen CAN-Frames beweist nicht, dass der Roboterbatterie Die Daten wurden korrekt interpretiert. Bytereihenfolge, Bitdefinitionen, Skalierung, vorzeichenbehaftete Werte und Statusflags müssen weiterhin übereinstimmen.

Terminierung, Pinbelegung und Anschlüsse

Die elektrische Dokumentation sollte alle erforderlichen Kommunikationspins angeben, einschließlich CAN-H, CAN-L, RS485-A, RS485-B, Signalerde, Wake-Leitungen, Abschirmung oder andere projektspezifische Leiter.

Auch die Terminierung muss zur gewählten Netzwerktopologie passen. Ingenieure sollten überprüfen, ob sich der Abschluss in der Roboterbatterie befindet, an anderer Stelle am Roboter installiert, konfigurierbar oder weggelassen ist.

Die Steckerform sollte niemals als Ersatz für 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.

Das Kabel- und Steckerdesign gehört daher in die Kommunikationsspezifikation und nicht nur in die mechanische Zeichnung.

Anforderungen an die Kommunikation mit dem Ladegerät

Wenn der Ladevorgang Kommunikation erfordert, sollten die Batterie und das Ladegerät des Roboters als koordiniertes System konstruiert werden.

Die Spezifikation sollte festlegen, ob das Ladegerät feste elektrische Einstellungen verwendet oder dynamische Grenzwerte vom BMS oder der Fahrzeugsteuerung erhält. Es sollte auch die Ladeaktivierungslogik, Strom- und Spannungsgrenzen, thermisches Verhalten, Ladestatus, Ladeabschluss, Fehlerreaktion, Dock-Handshaking und Wiederherstellung nach unterbrochenem Ladevorgang dokumentieren.

Bei einem AGV oder AMR, das auf unbeaufsichtigtes Laden angewiesen ist, können diese Funktionen direkten Einfluss darauf haben, wie zuverlässig der Roboter nach Erreichen des Docks wieder in Betrieb geht.

MANLY-Batteriekommunikationsoptionen

Bei MANLY Battery können Roboter- und Industriebatterieprojekte rund um die Kommunikationsanforderungen der Anwendung entwickelt werden, anstatt die Schnittstelle als isoliertes Add-on zu behandeln.

Die MANLY 24V 50Ah-Roboterbatterie ist ein LiFePO4-Akku mit einer Nennspannung von 24 V, einer tatsächlichen Batteriespannung von 25,6 V und einer Nennenergie von 1.280 Wh. Die aktuelle Spezifikation bietet optionale RS485-, RS232- oder CANBus-Kommunikation. Abmessungen, Gehäuse, Stecker, Gehäuse und Verkabelung können auch für OEM/ODM-Anforderungen konfiguriert werden.

Für Industrieroboter, die eine größere Bordkapazität benötigen, bietet die MANLY 48V 100Ah-Roboterbatterie eine Kapazität von 100 Ah und eine Nennenergie von 4.800 Wh. Es unterstützt auch optionale RS485-, RS232- oder CANBus-Kommunikation mit anpassbaren Abmessungen, Gehäuse, Anschlüssen und Verkabelung.

MANLY-Roboterbatterie	Kommunikation	Integrationsschwerpunkt
24V 50Ah LiFePO4 Roboterbatterie	Optional RS485, RS232, CANBus	Roboter- und AGV-Projekte, die konfigurierbare BMS-Kommunikation, Anschlüsse und Packungsabmessungen erfordern
48V 100Ah Industrieroboterbatterie	Optional RS485, RS232, CANBus	Industrieroboteranwendungen mit höherer Kapazität, die eine koordinierte BMS-, Controller-, Ladegerät- und Pack-Integration erfordern

Wenn ein Projekt speziell eine CANopen-Batteriekommunikation erfordert, sollte diese Anforderung während der technischen Prüfung definiert werden. Die CANBus-Verfügbarkeit allein sollte nicht als Bestätigung der CANopen-Kompatibilität gewertet werden.

Das Projektteam sollte die erforderliche CANopen-Objektzuordnung, Netzwerkkonfiguration, Controller-Verhalten und andere Protokollanforderungen bereitstellen, damit die Implementierung vorab evaluiert werden kann Roboterbatterie Der Entwurf ist fertiggestellt.

Für CAN- oder RS485-Projekte gilt das gleiche Prinzip. Durch die Bereitstellung der Controller-Spezifikation, der Nachrichten- oder Registerzuordnung, der Kommunikationsgeschwindigkeit, der Pinbelegung, der Ladegerätarchitektur, der Spannung, der Kapazität, der Stromanforderungen und des erwarteten Fehlerverhaltens erhält der Batteriehersteller ein viel klareres Integrationsziel.

Das Richtige Roboterbatteriekommunikation Die Methode wird daher nicht durch die isolierte Auswahl von CAN, RS485 oder CANopen bestimmt. Dies hängt davon ab, ob BMS, Robotersteuerung, Ladegerät, Verkabelung, Protokoll und Betriebslogik so konzipiert sind, dass sie als ein System zusammenarbeiten.

Erfahren Sie mehr über Batterien