CAN, RS485 e CANopen: di quale comunicazione ha bisogno la batteria di un robot?

UN batteria del robot necessita di un'interfaccia e di un protocollo di comunicazione che corrispondano al controller del robot, al caricabatterie, ai requisiti dei dati BMS e all'architettura di rete. CAN funziona bene per la comunicazione basata sulla priorità su più nodi. RS485 fornisce una robusta interfaccia seriale differenziale ed è spesso abbinato a un protocollo applicativo come Modbus RTU. CANopen aggiunge un quadro di comunicazione standardizzato di livello superiore sopra CAN.

Non esiste un unico metodo di comunicazione che ogni AGV o AMR dovrebbe utilizzare. Per affidabile batteria del robot comunicazione, la compatibilità deve estendersi oltre il connettore. L'interfaccia elettrica, la velocità in bit o in baud, la struttura del messaggio, la mappatura dei dati, l'indirizzamento, la temporizzazione, il comportamento in caso di errore e la logica di ricarica devono tutti corrispondere al sistema host.

Di cosa ha bisogno la batteria di un robot per comunicare?

UN batteria del robot comunica perché il robot necessita di qualcosa di più della sola energia elettrica. Il suo sistema di gestione della batteria deve rendere disponibili le condizioni della batteria e i limiti operativi selezionati ad apparecchiature quali il controller del veicolo, il caricabatterie, la base di ricarica, il computer diagnostico o il gateway di gestione della flotta.

Dati della batteria necessari al robot

Un BMS per batterie AMR misura o calcola diverse categorie di informazioni. Il controller potrebbe non aver bisogno continuamente di ogni valore della cella interna, ma dovrebbe ricevere i dati necessari per il funzionamento, la ricarica, la diagnostica e la manutenzione.

Categoria di dati	Informazioni tipiche	Come utilizza il robot it
Stato elettrico	Tensione, corrente, capacità rimanente del pacco	Monitora la condizione attuale della batteria
Stato termico e delle celle	Voltaggio della cella, temperatura del pacco, temperatura della cella	Supporta le decisioni di protezione e operative
Stime della batteria	SOC, SOH	Supporta la pianificazione del runtime e della manutenzione
Limiti operativi	Corrente di carica, corrente di scarica, tensione di carica	Aiuta a mantenere il funzionamento entro i limiti del BMS
Dati su guasti e avvisi	Sovratensione, sottotensione, sovratemperatura, sovracorrente	Supporta la risposta controllata ai guasti
Stato del sistema	Carica, scarica, standby, stato di protezione	Coordina il comportamento del robot
Identificazione	Indirizzo del dispositivo, versione del protocollo, identità della batteria	Supporta il riconoscimento e il servizio

Ciò è coerente anche con la moderna progettazione BMS della robotica mobile. Le piattaforme di riferimento BMS orientate alla robotica di NXP combinano la misurazione della tensione di celle e pacchi, il rilevamento di corrente, il rilevamento della temperatura e la connettività CAN all'interno della stessa architettura di gestione della batteria.

Le specifiche di comunicazione per una batteria robot dovrebbero quindi iniziare con i dati di cui il robot ha bisogno, piuttosto che con un connettore preferito o un nome bus.

SOC, SOH e segnalazione dei guasti

Il SOC fornisce al robot una stima della carica rimanente, mentre il SOH rappresenta la condizione della batteria a lungo termine. Entrambi sono preziosi, ma nessuno dei due dovrebbe essere considerato come un requisito di comunicazione completo.

UN batteria del robot può anche riportare temperature, corrente, stati di avvertenza, condizioni di protezione e limiti di carica o scarica consentiti. Quando le condizioni operative cambiano, questi valori forniscono al controller del veicolo informazioni che può utilizzare prima che il BMS raggiunga uno stato di protezione hardware.

Ciò rende la comunicazione con la batteria del robot utile sia per il funzionamento immediato che per la manutenzione. Il software della flotta può utilizzare informazioni coerenti sullo stato e sui guasti per distinguere una condizione di basso consumo energetico da un evento termico, un evento di protezione o un guasto di comunicazione.

Handshake tra controller e caricabatterie

Il controller del veicolo e il caricabatterie non richiedono necessariamente gli stessi dati della batteria. Durante il movimento, il controller può dare priorità a SOC, tensione, corrente, temperatura, avvisi e limiti di scarica. Durante la ricarica, il sistema potrebbe anche richiedere l'autorizzazione alla ricarica, i limiti di corrente di carica, i limiti di tensione, lo stato della temperatura e le informazioni sullo stato di carica.

Questo è il motivo per cui specificare un BMS per batteria CAN o BMS per batteria RS485 è solo il primo passo. Due dispositivi possono condividere la stessa interfaccia elettrica ma utilizzare identificatori, registri, fattori di scala, intervalli di aggiornamento o logica di controllo diversi.

La ricarica automatica rende la distinzione particolarmente importante. Quando un AGV o un AMR si aggancia senza l'intervento dell'operatore, la batteria, il caricabatterie e il controller del robot necessitano di un comportamento definito per l'autorizzazione alla ricarica, i limiti operativi, la gestione dei guasti, il completamento della carica e il ritorno al servizio.

Perché la comunicazione influisce sui tempi di attività

L'utile comunicazione della batteria consente al robot di rispondere alle condizioni della batteria prima che un arresto forzato diventi l'unica risposta disponibile. Un SOC basso può avviare un'attività di ricarica, una condizione di temperatura può influenzare il comportamento di ricarica e un guasto segnalato può mettere il veicolo in uno stato di servizio definito.

Per le flotte, dati coerenti sulle batterie dei robot migliorano anche la risoluzione dei problemi. Le squadre di manutenzione possono rivedere gli stati operativi e gli allarmi invece di trattare ogni perdita di propulsione o interruzione della ricarica come lo stesso problema.

Il vantaggio non è semplicemente una maggiore telemetria. Il vero valore deriva dal rendere la batteria una parte integrata e interpretabile dell’architettura di controllo del robot.

CAN e RS485: come differiscono nei sistemi robotici

CAN e RS485 sono entrambi comuni nei sistemi industriali, ma risolvono diverse parti del problema di comunicazione. CAN fornisce meccanismi di framing dei messaggi, arbitrato, riconoscimento e gestione degli errori per un bus condiviso. RS485 definisce principalmente la segnalazione elettrica utilizzata per la comunicazione seriale.

Questa distinzione è importante quando gli ingegneri selezionano un’architettura di comunicazione per la batteria di un robot.

CAN come rete

CAN è progettato per più dispositivi che comunicano su un bus condiviso. I messaggi vengono identificati tramite identificatori CAN e i tentativi di trasmissione simultanei vengono risolti tramite arbitrato basato sulla priorità.

Per la comunicazione con la batteria del robot, questa architettura può supportare messaggi di stato regolari, limiti operativi, informazioni di avviso e segnalazione di guasti guidati da eventi. L’attuale progetto di riferimento BMS per robotica mobile MR-BMS771 di NXP include due bus CAN, fornendo un esempio pratico di integrazione CAN direttamente in una piattaforma di gestione della batteria robotica.

Una porta CAN da sola, tuttavia, non definisce il significato dei dati. Un BMS per batteria CAN e un controller robot necessitano ancora di bit rate, identificatori, definizioni di carico utile, ridimensionamento, tempi di trasmissione e logica applicativa compatibili.

RS485 come interfaccia fisica

RS485 è un'interfaccia seriale differenziale ampiamente utilizzata nella comunicazione multipunto industriale. È particolarmente utile quando le apparecchiature utilizzano già reti seriali o quando un controller comunica con più dispositivi indirizzati.

Per una batteria robot, il punto critico è che RS485 da solo non dice al controller cosa significa un byte. Un BMS a batteria RS485 necessita comunque di un protocollo applicativo definito o di una struttura dati proprietaria.

Questa distinzione spiega perché RS485 e Modbus RTU appaiono spesso insieme senza essere sinonimi. L'organizzazione Modbus documenta le implementazioni della linea seriale Modbus utilizzando EIA/TIA-485, mentre Modbus stesso definisce il comportamento di messaggistica di livello superiore.

Una specifica di acquisto dovrebbe quindi dire qualcosa di più di “RS485 richiesta”. Dovrebbe identificare il protocollo effettivo e la mappa dati previsti dal robot.

Arbitrato CAN e gestione degli errori

CAN consente ai nodi di trasmettere senza attendere che un controller centrale assegni ogni opportunità di trasmissione. Se due nodi iniziano a trasmettere contemporaneamente, l'arbitraggio basato sugli identificatori del messaggio determina quale frame continua.

CAN include anche meccanismi per rilevare errori di trasmissione e gestire nodi che generano ripetutamente errori. Queste caratteristiche lo rendono adatto a reti in cui il batteria del robot deve scambiare frequentemente dati operativi con altri controllori.

La decisione ingegneristica non dovrebbe essere ridotta ad un’affermazione generica secondo cui CAN è semplicemente “più veloce”. Ciò che conta è se i messaggi della batteria richiesti possono essere consegnati con la priorità e i tempi di aggiornamento necessari sotto il carico previsto del bus.

Per un robot mobile, un piccolo insieme di messaggi della batteria correttamente classificati e documentati è spesso più prezioso di una velocità dati teoricamente elevata con un comportamento dell'applicazione scarsamente definito.

Modbus RTU su RS485

Modbus RTU fornisce una struttura di messaggistica a livello di applicazione che può funzionare su un collegamento seriale RS485. Il protocollo definisce il modo in cui i dispositivi indirizzati scambiano richieste e risposte, mentre la mappa dei registri specifica dell'apparecchiatura identifica dove vengono memorizzati i singoli valori.

Per una batteria robot, una mappa Modbus RTU potrebbe contenere registri per tensione, corrente, SOC, temperatura, allarmi o limiti operativi del pacco. Una corretta interpretazione richiede che il controller conosca l'indirizzo del registro, il formato dei dati, il fattore di scala, l'ordine dei byte, l'indirizzo del dispositivo, la velocità di trasmissione, la parità e il comportamento di timeout.

In fase di integrazione sono importanti alcune distinzioni: RS485 non significa automaticamente Modbus RTU; due dispositivi Modbus non utilizzano automaticamente la stessa mappa di registri; un connettore RJ45 non stabilisce la compatibilità Ethernet, CAN o RS485; e una connessione elettricamente valida non garantisce la compatibilità a livello di applicazione.

Questi controlli impediscono un comune errore di integrazione: entrambe le parti sembrano supportare la stessa tecnologia di comunicazione, ma la batteria del robot e il controller non riescono a comprendere i reciproci dati.

Dove CANopen si inserisce in un sistema di batterie per robot

CANopen si trova sopra CAN nello stack di comunicazione. Non sostituisce il bus CAN. CANopen definisce invece meccanismi standardizzati per organizzare i dati del dispositivo, trasmettere informazioni di processo, accedere ai parametri di configurazione, controllare gli stati della rete e monitorare i partecipanti alla rete.

Un'implementazione della batteria CANopen richiede quindi più di un ricetrasmettitore CAN o un connettore CAN. Il BMS deve implementare le funzioni CANopen richieste dal controller host.

CAN non è CANopen

CAN fornisce il meccanismo di comunicazione di rete sottostante. CANopen aggiunge la struttura di livello superiore che determina il modo in cui i dispositivi basati su CAN organizzano e scambiano i dati delle applicazioni.

CAN in Automation, o CiA, descrive un dispositivo CANopen come dotato di uno stack di protocolli CANopen, software applicativo e un dizionario oggetti che collega il sistema di comunicazione con i parametri dell'applicazione.

Ciò rende particolarmente importante una regola sugli appalti:

Il supporto CAN non significa automaticamente il supporto CANopen.

Se un controller AMR richiede una batteria CANopen, la specifica dovrebbe identificare la funzionalità CANopen e le mappature dei dati previste dal controller. La semplice richiesta di una porta CAN non è sufficiente.

Il dizionario degli oggetti CANopen

Il dizionario oggetti è il modello di dati strutturati utilizzato dai dispositivi CANopen. CiA specifica che i parametri di comunicazione e applicazione sono organizzati tramite voci di dizionario di oggetti indicizzati, con valori di indice e sottoindice che forniscono indirizzi definiti per i dati.

Nell'integrazione di una batteria CANopen, questa struttura può fornire un modo coerente per esporre lo stato della batteria, i parametri di configurazione e le informazioni diagnostiche. Gli oggetti batteria effettivi devono comunque corrispondere ai requisiti del controller e a qualsiasi profilo applicabile o specifica di progetto.

Il vantaggio pratico è la chiarezza. Gli ingegneri non devono trattare ogni frame CAN come un messaggio proprietario isolato quando viene utilizzata un'implementazione CANopen definita. Possono lavorare con oggetti documentati e servizi di comunicazione.

PDO, SDO e diagnostica

CANopen separa diversi compiti di comunicazione attraverso servizi definiti. I Process Data Objects, o PDO, sono adatti a elaborare le informazioni scambiate durante il funzionamento. I Service Data Objects, o SDO, forniscono l'accesso alle voci nel dizionario oggetti per la configurazione e le funzioni del servizio.

CANopen fornisce inoltre meccanismi per la segnalazione degli errori e la supervisione dei nodi. La documentazione CiA identifica le funzioni PDO, SDO, emergenza, heartbeat e gestione della rete come parti dell'architettura di comunicazione CANopen.

Per una batteria CANopen, i valori operativi richiesti di frequente possono essere mappati nella comunicazione PDO, mentre l'accesso SDO può supportare la messa in servizio o la diagnostica. La mappatura esatta dovrebbe essere concordata prima dell'integrazione anziché presupposta.

Questo è anche il motivo per cui una batteria robot che comunica con successo tramite CAN proprietario non può essere automaticamente trattata come compatibile CANopen.

Gestione della rete e heartbeat

La gestione della rete CANopen, o NMT, definisce gli stati di comunicazione per un dispositivo. CiA identifica gli stati di inizializzazione, pre-operativo, operativo e arrestato all'interno della macchina a stati CANopen NMT. La comunicazione PDO diventa disponibile nello stato operativo, mentre la comunicazione SDO può essere utilizzata nello stato preoperativo.

Per la comunicazione con la batteria del robot, questi stati aiutano a definire il comportamento durante l'avvio, la messa in servizio, il funzionamento normale, l'arresto e il ripristino.

I meccanismi di heartbeat forniscono un'altra funzione utile consentendo al controller di determinare se un nodo previsto rimane presente sulla rete. Una specifica della batteria CANopen dovrebbe quindi coprire più dei semplici campi dati della batteria. Anche lo stato di avvio, la tempistica del battito cardiaco, la risposta al timeout e il comportamento di ripristino possono avere importanza per il robot.

Scegliere l'interfaccia giusta per AGV e AMR

Il metodo di comunicazione corretto è quello che si adatta all’architettura di controllo esistente del robot e fornisce le informazioni sulla batteria richieste da quel sistema.

La selezione del protocollo dovrebbe quindi iniziare con il controller host e l’architettura di ricarica piuttosto che con una preferenza generica per CAN o RS485.

Abbina la rete di robot esistente

Il primo passo è determinare esattamente cosa si aspetta il controller del robot. Un controller può utilizzare frame CAN proprietari, CANopen, RS485 con Modbus RTU o un altro protocollo documentato.

Architettura esistente	Requisiti appropriati della batteria del robot
Controller CAN proprietario	BMS della batteria CAN con bit rate e mappa dei messaggi corrispondenti
Controllore CANopen	BMS che implementa gli oggetti CANopen richiesti e il comportamento di rete
PLC o controller che utilizza Modbus RTU	BMS a batteria RS485 con impostazioni seriali corrispondenti e mappa dei registri
Reti di controllo e diagnostica separate	Definire quale connessione trasporta il controllo della batteria e quale trasporta i dati di servizio

La batteria del robot deve essere adattata a tale requisito di rete. Scegliere un pacchetto perché il connettore o l'etichetta della porta sembrano familiari inverte il processo di progettazione corretto.

Definire i dati della batteria richiesti

Prima di richiedere un pacchetto personalizzato, gli ingegneri dovrebbero creare una matrice di comunicazione che separi i dati necessari per il funzionamento dalle informazioni destinate principalmente alla diagnostica o alla manutenzione.

Per molti progetti AGV e AMR, il requisito batteria del robot i dati includono:

• Tensione e corrente del pacco
• SOC e SOH
• Temperatura della batteria
• Limiti di carica e scarica
• Stati di allerta e protezione
• Stato di carica e stato BMS
• Identità del dispositivo o indirizzo di rete
• Stato del contattore o del MOSFET quando richiesto dal sistema

Il progetto dovrebbe anche definire la direzione dei dati. Alcune informazioni vengono trasmesse dal BMS della batteria AMR all'host, mentre altre architetture potrebbero richiedere comandi di controllo, conferme o messaggi di configurazione dal controller.

Questo passaggio determina ciò che l'interfaccia deve effettivamente realizzare.

Controllare i tempi e la risposta ai guasti

Una specifica di comunicazione completa necessita di requisiti temporali oltre alle definizioni dei dati.

Gli ingegneri dovrebbero determinare la frequenza con cui devono essere aggiornate le informazioni critiche sulla batteria del robot, quanto tempo attende il controller prima di dichiarare offline il BMS e quale risposta segue un timeout di comunicazione. Le priorità dei messaggi CAN o gli intervalli di polling RS485 dovrebbero riflettere l'importanza dei dati trasferiti.

Anche il ripristino dei guasti necessita di un comportamento definito. Il sistema dovrebbe stabilire se la comunicazione riprende automaticamente dopo un evento transitorio, se il BMS richiede un ripristino e se il robot può riprendere il funzionamento immediatamente o deve prima verificare lo stato della batteria.

Queste decisioni sono specifiche dell'applicazione. Dovrebbero essere documentati durante l'integrazione anziché dedotti dall'interfaccia di comunicazione.

Pianificare la comunicazione con la stazione di ricarica

Un AGV o un AMR caricato automaticamente necessita della base di ricarica considerata parte del batteria del robot architettura.

Potrebbe essere necessario che il sistema di ricarica coordini l'autorizzazione alla carica, la tensione della batteria, i limiti di corrente, lo stato della temperatura, lo stato di carica, il completamento e le condizioni di guasto. I contatti di ricarica fisici o un ricevitore di alimentazione senza contatto forniscono il percorso di alimentazione, ma non definiscono il comportamento di comunicazione.

Il robot necessita inoltre di una sequenza chiara per rilevare la base, consentire la ricarica, rispondere ai limiti del BMS, completare il processo di ricarica e tornare al funzionamento.

L'attuale guida all'integrazione AMR di MANLY Battery identifica la comunicazione CAN o RS485, il monitoraggio della corrente e della temperatura, la progettazione del connettore e il cablaggio specifico dell'applicazione come fattori da coordinare quando si integra una batteria AMR, un BMS e un dock di ricarica.

Per le flotte autonome, la comunicazione di ricarica dovrebbe quindi essere progettata contemporaneamente alla batteria del robot e al BMS anziché dopo che il pacco è già stato finalizzato.

Considera le esigenze diagnostiche della flotta

I dati di controllo del traffico e di manutenzione non necessitano sempre di utilizzare lo stesso percorso di comunicazione. Alcuni robot inseriscono i dati della batteria sensibili al tempo sulla rete CAN primaria mentre utilizzano un'interfaccia separata per la messa in servizio, l'assistenza o una diagnostica più approfondita.

Ciò che conta è che l’architettura diagnostica sia deliberata.

Per le flotte di grandi dimensioni, definizioni coerenti dei dati delle batterie dei robot possono semplificare la risoluzione dei problemi su molti veicoli. I codici di errore, le unità, la scala, le versioni del firmware, gli stati di comunicazione e i registri di manutenzione dovrebbero avere significati ripetibili da un robot all'altro.

Ciò può diventare particolarmente utile quando il software della flotta viene utilizzato per distinguere gli eventi legati all’energia dai guasti del BMS, dai guasti del caricatore o dagli errori di comunicazione.

Cosa chiedere a un produttore di batterie prima dell'integrazione

UN produttore di batterie dovrebbe essere in grado di discutere la comunicazione BMS con gli stessi dettagli tecnici utilizzati per tensione, capacità, corrente, dimensioni e requisiti dei connettori del pacco.

“CAN disponibile” o “RS485 disponibile” è utile per lo screening iniziale, ma la batteria di un robot di produzione richiede specifiche di comunicazione più complete.

Protocollo e mappa dei messaggi

Per l'integrazione CAN, richiedere il protocollo dell'applicazione, gli identificatori CAN, le definizioni del carico utile, la scalatura, la direzione del messaggio, i tempi di trasmissione e il comportamento di timeout.

Per una batteria CANopen, definire le voci del dizionario oggetto richieste, le mappature PDO, l'accesso SDO, il comportamento NMT, i requisiti heartbeat e le funzioni specifiche del controller.

Se il progetto utilizza la comunicazione CAN specifica del produttore, la definizione del messaggio dovrebbe essere disponibile abbastanza presto per lo sviluppo del controller e il test al banco. Il team del software non dovrebbe dover decodificare il file batteria del robot dopo l'arrivo dell'hardware del prototipo.

Baud rate e ID nodo

Entrambi i lati della connessione devono utilizzare impostazioni di rete compatibili.

Per CAN, confermare il bit rate CAN e il relativo identificatore o configurazione del nodo. Per CANopen, definire anche gli ID nodo e il comportamento di gestione della rete richiesto. Per un BMS a batteria RS485, verificare la velocità di trasmissione, la parità, i bit di stop, l'indirizzamento e il comportamento di polling o risposta previsto.

Questi parametri dovrebbero essere registrati nelle specifiche di comunicazione del progetto e controllati come qualsiasi altro requisito di interfaccia a livello di sistema.

Registra la mappa e il ridimensionamento dei dati

Una connessione RS485 che utilizza Modbus RTU necessita di una mappa dei registri completa. Ogni valore richiesto dovrebbe avere un indirizzo, un tipo di dati, un fattore di scala, un'unità ingegneristica e un metodo di accesso definiti.

Ad esempio, un valore trasmesso non può essere interpretato correttamente finché il controller non sa se rappresenta volt, millivolt, decimi di volt, corrente con segno o un'altra codifica.

Lo stesso principio vale per CAN. La ricezione di un frame CAN valido non dimostra che il batteria del robot i dati sono stati interpretati correttamente. L'ordine dei byte, le definizioni dei bit, la scala, i valori con segno e i flag di stato devono comunque corrispondere.

Terminazione, piedinatura e connettori

La documentazione elettrica dovrebbe identificare ogni pin di comunicazione richiesto, inclusi CAN-H, CAN-L, RS485-A, RS485-B, massa del segnale, linee di scia, schermatura o altri conduttori specifici del progetto.

Anche la terminazione deve corrispondere alla topologia di rete selezionata. Gli ingegneri devono verificare se la terminazione è all'interno della batteria del robot, installata altrove sul robot, configurabile o omessa.

La forma del connettore non deve mai essere utilizzata come sostituto di questa documentazione. Un connettore di tipo RJ45, ad esempio, non indica automaticamente Ethernet e non stabilisce una piedinatura CAN o RS485 standardizzata.

Il design del cavo e del connettore rientra quindi nelle specifiche di comunicazione e non solo nel disegno meccanico.

Requisiti di comunicazione del caricabatterie

La batteria e il caricabatterie del robot dovrebbero essere progettati come un sistema coordinato quando il processo di ricarica richiede la comunicazione.

La specifica dovrebbe definire se il caricabatterie utilizza impostazioni elettriche fisse o riceve limiti dinamici dal BMS o dal controller del veicolo. Dovrebbe inoltre documentare la logica di abilitazione della carica, i limiti di corrente e tensione, il comportamento termico, lo stato di carica, il completamento della carica, la risposta ai guasti, l'handshaking del dock e il ripristino dopo l'interruzione della carica.

Per un AGV o un AMR che si basa sulla ricarica automatica, queste funzioni possono influenzare direttamente l’affidabilità con cui il robot ritorna al funzionamento dopo aver raggiunto la banchina.

Opzioni di comunicazione della batteria MANLY

Presso MANLY Battery, i progetti di robot e batterie industriali possono essere sviluppati attorno ai requisiti di comunicazione dell'applicazione anziché trattare l'interfaccia come un componente aggiuntivo isolato.

La batteria del robot MANLY da 24 V 50 Ah è un pacco LiFePO4 valutato a 24 V nominali, con una tensione effettiva della batteria di 25,6 V e 1.280 Wh di energia nominale. Le sue specifiche attuali forniscono la comunicazione opzionale RS485, RS232 o CANBus. È inoltre possibile configurare dimensioni, alloggiamento, connettore, custodia e cablaggio per i requisiti OEM/ODM.

Per i robot industriali che richiedono una maggiore capacità a bordo, la batteria del robot MANLY da 48 V 100 Ah fornisce una capacità di 100 Ah e un'energia nominale di 4.800 Wh. Supporta inoltre la comunicazione opzionale RS485, RS232 o CANBus, con dimensioni, alloggiamento, connettori e cablaggio personalizzabili.

Batteria del robot MANLY	Comunicazione	Focus sull’integrazione
Batteria per robot LiFePO4 da 24 V 50 Ah	RS485, RS232, CANBus opzionali	Progetti di robot e AGV che richiedono comunicazione BMS, connettori e dimensioni del pacco configurabili
Batteria per robot industriale 48V 100Ah	RS485, RS232, CANBus opzionali	Applicazioni di robot industriali ad alta capacità che richiedono l'integrazione coordinata di BMS, controller, caricabatterie e pacchetto

Se un progetto richiede specificamente la comunicazione della batteria CANopen, tale requisito deve essere definito durante la revisione tecnica. La sola disponibilità del CANBus non deve essere considerata come una conferma della compatibilità CANopen.

Il team di progetto dovrebbe fornire la mappatura degli oggetti CANopen, la configurazione di rete, il comportamento del controller e altri requisiti del protocollo richiesti in modo che l'implementazione possa essere valutata prima del batteria del robot la progettazione è finalizzata.

Per i progetti CAN o RS485 vale lo stesso principio. Fornire le specifiche del controller, la mappa dei messaggi o dei registri, la velocità di comunicazione, la piedinatura, l'architettura del caricabatterie, la tensione, la capacità, i requisiti di corrente e il comportamento di errore previsto offre al produttore della batteria un obiettivo di integrazione molto più chiaro.

Il diritto comunicazione con la batteria del robot il metodo non è quindi determinato scegliendo CAN, RS485 o CANopen isolatamente. È determinato dal fatto che il BMS, il controller del robot, il caricabatterie, il cablaggio, il protocollo e la logica operativa siano stati progettati per funzionare insieme come un unico sistema.

Scopri di più sulla batteria