batteria del robot<\/a><\/strong> pu\u00f2 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\u00f2 utilizzare prima che il BMS raggiunga uno stato di protezione hardware.<\/p>\n\n\n\nCi\u00f2 rende la comunicazione con la batteria del robot utile sia per il funzionamento immediato che per la manutenzione. Il software della flotta pu\u00f2 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.<\/p>\n\n\n\n
Handshake tra controller e caricabatterie<\/h3>\n\n\n\n Il controller del veicolo e il caricabatterie non richiedono necessariamente gli stessi dati della batteria. Durante il movimento, il controller pu\u00f2 dare priorit\u00e0 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.<\/p>\n\n\n\n
Questo \u00e8 il motivo per cui specificare un BMS per batteria CAN o BMS per batteria RS485 \u00e8 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Perch\u00e9 la comunicazione influisce sui tempi di attivit\u00e0<\/h3>\n\n\n\n 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\u00f2 avviare un'attivit\u00e0 di ricarica, una condizione di temperatura pu\u00f2 influenzare il comportamento di ricarica e un guasto segnalato pu\u00f2 mettere il veicolo in uno stato di servizio definito.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Il vantaggio non \u00e8 semplicemente una maggiore telemetria. Il vero valore deriva dal rendere la batteria una parte integrata e interpretabile dell\u2019architettura di controllo del robot.<\/p>\n\n\n\n
CAN e RS485: come differiscono nei sistemi robotici<\/h2>\n\n\n\n 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.<\/p>\n\n\n\n
Questa distinzione \u00e8 importante quando gli ingegneri selezionano un\u2019architettura di comunicazione per la batteria di un robot.<\/p>\n\n\n\n
CAN come rete<\/h3>\n\n\n\n CAN \u00e8 progettato per pi\u00f9 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\u00e0.<\/p>\n\n\n\n
Per la comunicazione con la batteria del robot, questa architettura pu\u00f2 supportare messaggi di stato regolari, limiti operativi, informazioni di avviso e segnalazione di guasti guidati da eventi. L\u2019attuale 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
RS485 come interfaccia fisica<\/h3>\n\n\n\n RS485 \u00e8 un'interfaccia seriale differenziale ampiamente utilizzata nella comunicazione multipunto industriale. \u00c8 particolarmente utile quando le apparecchiature utilizzano gi\u00e0 reti seriali o quando un controller comunica con pi\u00f9 dispositivi indirizzati.<\/p>\n\n\n\n
Per una batteria robot, il punto critico \u00e8 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.<\/p>\n\n\n\n
Questa distinzione spiega perch\u00e9 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.<\/p>\n\n\n\n
Una specifica di acquisto dovrebbe quindi dire qualcosa di pi\u00f9 di \u201cRS485 richiesta\u201d. Dovrebbe identificare il protocollo effettivo e la mappa dati previsti dal robot.<\/p>\n\n\n\n
Arbitrato CAN e gestione degli errori<\/h3>\n\n\n\n CAN consente ai nodi di trasmettere senza attendere che un controller centrale assegni ogni opportunit\u00e0 di trasmissione. Se due nodi iniziano a trasmettere contemporaneamente, l'arbitraggio basato sugli identificatori del messaggio determina quale frame continua.<\/p>\n\n\n\n
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<\/strong> deve scambiare frequentemente dati operativi con altri controllori.<\/p>\n\n\n\nLa decisione ingegneristica non dovrebbe essere ridotta ad un\u2019affermazione generica secondo cui CAN \u00e8 semplicemente \u201cpi\u00f9 veloce\u201d. Ci\u00f2 che conta \u00e8 se i messaggi della batteria richiesti possono essere consegnati con la priorit\u00e0 e i tempi di aggiornamento necessari sotto il carico previsto del bus.<\/p>\n\n\n\n
Per un robot mobile, un piccolo insieme di messaggi della batteria correttamente classificati e documentati \u00e8 spesso pi\u00f9 prezioso di una velocit\u00e0 dati teoricamente elevata con un comportamento dell'applicazione scarsamente definito.<\/p>\n\n\n\n
Modbus RTU su RS485<\/h3>\n\n\n\n Modbus RTU fornisce una struttura di messaggistica a livello di applicazione che pu\u00f2 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.<\/p>\n\n\n\n
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\u00e0 di trasmissione, la parit\u00e0 e il comportamento di timeout.<\/p>\n\n\n\n
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\u00e0 Ethernet, CAN o RS485; e una connessione elettricamente valida non garantisce la compatibilit\u00e0 a livello di applicazione.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Dove CANopen si inserisce in un sistema di batterie per robot<\/h2>\n\n\n\n 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.<\/p>\n\n\n\n
Un'implementazione della batteria CANopen richiede quindi pi\u00f9 di un ricetrasmettitore CAN o un connettore CAN. Il BMS deve implementare le funzioni CANopen richieste dal controller host.<\/p>\n\n\n\n
CAN non \u00e8 CANopen<\/h3>\n\n\n\n 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Ci\u00f2 rende particolarmente importante una regola sugli appalti:<\/p>\n\n\n\n
Il supporto CAN non significa automaticamente il supporto CANopen.<\/strong><\/p>\n\n\n\nSe un controller AMR richiede una batteria CANopen, la specifica dovrebbe identificare la funzionalit\u00e0 CANopen e le mappature dei dati previste dal controller. La semplice richiesta di una porta CAN non \u00e8 sufficiente.<\/p>\n\n\n\n
Il dizionario degli oggetti CANopen<\/h3>\n\n\n\n Il dizionario oggetti \u00e8 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.<\/p>\n\n\n\n
Nell'integrazione di una batteria CANopen, questa struttura pu\u00f2 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.<\/p>\n\n\n\n
Il vantaggio pratico \u00e8 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.<\/p>\n\n\n\n
PDO, SDO e diagnostica<\/h3>\n\n\n\n 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Per una batteria CANopen, i valori operativi richiesti di frequente possono essere mappati nella comunicazione PDO, mentre l'accesso SDO pu\u00f2 supportare la messa in servizio o la diagnostica. La mappatura esatta dovrebbe essere concordata prima dell'integrazione anzich\u00e9 presupposta.<\/p>\n\n\n\n
Questo \u00e8 anche il motivo per cui una batteria robot che comunica con successo tramite CAN proprietario non pu\u00f2 essere automaticamente trattata come compatibile CANopen.<\/p>\n\n\n\n
Gestione della rete e heartbeat<\/h3>\n\n\n\n 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\u00f2 essere utilizzata nello stato preoperativo.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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\u00f9 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.<\/p>\n\n\n\n
Scegliere l'interfaccia giusta per AGV e AMR<\/h2>\n\n\n\n Il metodo di comunicazione corretto \u00e8 quello che si adatta all\u2019architettura di controllo esistente del robot e fornisce le informazioni sulla batteria richieste da quel sistema.<\/p>\n\n\n\n
La selezione del protocollo dovrebbe quindi iniziare con il controller host e l\u2019architettura di ricarica piuttosto che con una preferenza generica per CAN o RS485.<\/p>\n\n\n\n
Abbina la rete di robot esistente<\/h3>\n\n\n\n Il primo passo \u00e8 determinare esattamente cosa si aspetta il controller del robot. Un controller pu\u00f2 utilizzare frame CAN proprietari, CANopen, RS485 con Modbus RTU o un altro protocollo documentato.<\/p>\n\n\n\nArchitettura esistente<\/th> Requisiti appropriati della batteria del robot<\/th><\/tr><\/thead> Controller CAN proprietario<\/td> BMS della batteria CAN con bit rate e mappa dei messaggi corrispondenti<\/td><\/tr> Controllore CANopen<\/td> BMS che implementa gli oggetti CANopen richiesti e il comportamento di rete<\/td><\/tr> PLC o controller che utilizza Modbus RTU<\/td> BMS a batteria RS485 con impostazioni seriali corrispondenti e mappa dei registri<\/td><\/tr> Reti di controllo e diagnostica separate<\/td> Definire quale connessione trasporta il controllo della batteria e quale trasporta i dati di servizio<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nLa batteria del robot deve essere adattata a tale requisito di rete. Scegliere un pacchetto perch\u00e9 il connettore o l'etichetta della porta sembrano familiari inverte il processo di progettazione corretto.<\/p>\n\n\n\n
Definire i dati della batteria richiesti<\/h3>\n\n\n\n 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.<\/p>\n\n\n\n
Per molti progetti AGV e AMR, il requisito batteria del robot<\/strong> i dati includono:<\/p>\n\n\n\n\nTensione e corrente del pacco<\/li>\n\n\n\n SOC e SOH<\/li>\n\n\n\n Temperatura della batteria<\/li>\n\n\n\n Limiti di carica e scarica<\/li>\n\n\n\n Stati di allerta e protezione<\/li>\n\n\n\n Stato di carica e stato BMS<\/li>\n\n\n\n Identit\u00e0 del dispositivo o indirizzo di rete<\/li>\n\n\n\n Stato del contattore o del MOSFET quando richiesto dal sistema<\/li>\n<\/ul>\n\n\n\nIl 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.<\/p>\n\n\n\n
Questo passaggio determina ci\u00f2 che l'interfaccia deve effettivamente realizzare.<\/p>\n\n\n\n
Controllare i tempi e la risposta ai guasti<\/h3>\n\n\n\n Una specifica di comunicazione completa necessita di requisiti temporali oltre alle definizioni dei dati.<\/p>\n\n\n\n
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\u00e0 dei messaggi CAN o gli intervalli di polling RS485 dovrebbero riflettere l'importanza dei dati trasferiti.<\/p>\n\n\n\n
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\u00f2 riprendere il funzionamento immediatamente o deve prima verificare lo stato della batteria.<\/p>\n\n\n\n
Queste decisioni sono specifiche dell'applicazione. Dovrebbero essere documentati durante l'integrazione anzich\u00e9 dedotti dall'interfaccia di comunicazione.<\/p>\n\n\n\n
Pianificare la comunicazione con la stazione di ricarica<\/h3>\n\n\n\n Un AGV o un AMR caricato automaticamente necessita della base di ricarica considerata parte del batteria del robot<\/strong> architettura.<\/p>\n\n\n\nPotrebbe 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Per le flotte autonome, la comunicazione di ricarica dovrebbe quindi essere progettata contemporaneamente alla batteria del robot e al BMS anzich\u00e9 dopo che il pacco \u00e8 gi\u00e0 stato finalizzato.<\/p>\n\n\n\n
Considera le esigenze diagnostiche della flotta<\/h3>\n\n\n\n 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\u00f9 approfondita.<\/p>\n\n\n\n
Ci\u00f2 che conta \u00e8 che l\u2019architettura diagnostica sia deliberata.<\/p>\n\n\n\n
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\u00e0, la scala, le versioni del firmware, gli stati di comunicazione e i registri di manutenzione dovrebbero avere significati ripetibili da un robot all'altro.<\/p>\n\n\n\n
Ci\u00f2 pu\u00f2 diventare particolarmente utile quando il software della flotta viene utilizzato per distinguere gli eventi legati all\u2019energia dai guasti del BMS, dai guasti del caricatore o dagli errori di comunicazione.<\/p>\n\n\n\n
Cosa chiedere a un produttore di batterie prima dell'integrazione<\/h2>\n\n\n\n UN produttore di batterie<\/a><\/strong> dovrebbe essere in grado di discutere la comunicazione BMS con gli stessi dettagli tecnici utilizzati per tensione, capacit\u00e0, corrente, dimensioni e requisiti dei connettori del pacco.<\/p>\n\n\n\n\u201cCAN disponibile\u201d o \u201cRS485 disponibile\u201d \u00e8 utile per lo screening iniziale, ma la batteria di un robot di produzione richiede specifiche di comunicazione pi\u00f9 complete.<\/p>\n\n\n\n
Protocollo e mappa dei messaggi<\/h3>\n\n\n\n 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/strong> dopo l'arrivo dell'hardware del prototipo.<\/p>\n\n\n\nBaud rate e ID nodo<\/h3>\n\n\n\n Entrambi i lati della connessione devono utilizzare impostazioni di rete compatibili.<\/p>\n\n\n\n
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\u00e0 di trasmissione, la parit\u00e0, i bit di stop, l'indirizzamento e il comportamento di polling o risposta previsto.<\/p>\n\n\n\n
Questi parametri dovrebbero essere registrati nelle specifiche di comunicazione del progetto e controllati come qualsiasi altro requisito di interfaccia a livello di sistema.<\/p>\n\n\n\n
Registra la mappa e il ridimensionamento dei dati<\/h3>\n\n\n\n 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\u00e0 ingegneristica e un metodo di accesso definiti.<\/p>\n\n\n\n
Ad esempio, un valore trasmesso non pu\u00f2 essere interpretato correttamente finch\u00e9 il controller non sa se rappresenta volt, millivolt, decimi di volt, corrente con segno o un'altra codifica.<\/p>\n\n\n\n
Lo stesso principio vale per CAN. La ricezione di un frame CAN valido non dimostra che il batteria del robot<\/strong> 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.<\/p>\n\n\n\nTerminazione, piedinatura e connettori<\/h3>\n\n\n\n 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.<\/p>\n\n\n\n
Anche la terminazione deve corrispondere alla topologia di rete selezionata. Gli ingegneri devono verificare se la terminazione \u00e8 all'interno della batteria del robot, installata altrove sul robot, configurabile o omessa.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Il design del cavo e del connettore rientra quindi nelle specifiche di comunicazione e non solo nel disegno meccanico.<\/p>\n\n\n\n
Requisiti di comunicazione del caricabatterie<\/h3>\n\n\n\n La batteria e il caricabatterie del robot dovrebbero essere progettati come un sistema coordinato quando il processo di ricarica richiede la comunicazione.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Per un AGV o un AMR che si basa sulla ricarica automatica, queste funzioni possono influenzare direttamente l\u2019affidabilit\u00e0 con cui il robot ritorna al funzionamento dopo aver raggiunto la banchina.<\/p>\n\n\n\n
Opzioni di comunicazione della batteria MANLY<\/h3>\n\n\n\n Presso MANLY Battery, i progetti di robot e batterie industriali possono essere sviluppati attorno ai requisiti di comunicazione dell'applicazione anzich\u00e9 trattare l'interfaccia come un componente aggiuntivo isolato.<\/p>\n\n\n\n
La batteria del robot MANLY da 24 V 50 Ah \u00e8 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. \u00c8 inoltre possibile configurare dimensioni, alloggiamento, connettore, custodia e cablaggio per i requisiti OEM\/ODM.<\/p>\n\n\n\n
Per i robot industriali che richiedono una maggiore capacit\u00e0 a bordo, la batteria del robot MANLY da 48 V 100 Ah fornisce una capacit\u00e0 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.<\/p>\n\n\n\nBatteria del robot MANLY<\/th> Comunicazione<\/th> Focus sull\u2019integrazione<\/th><\/tr><\/thead> Batteria per robot LiFePO4 da 24 V 50 Ah<\/td> RS485, RS232, CANBus opzionali<\/td> Progetti di robot e AGV che richiedono comunicazione BMS, connettori e dimensioni del pacco configurabili<\/td><\/tr> Batteria per robot industriale 48V 100Ah<\/td> RS485, RS232, CANBus opzionali<\/td> Applicazioni di robot industriali ad alta capacit\u00e0 che richiedono l'integrazione coordinata di BMS, controller, caricabatterie e pacchetto<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSe un progetto richiede specificamente la comunicazione della batteria CANopen, tale requisito deve essere definito durante la revisione tecnica. La sola disponibilit\u00e0 del CANBus non deve essere considerata come una conferma della compatibilit\u00e0 CANopen.<\/p>\n\n\n\n
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<\/strong> la progettazione \u00e8 finalizzata.<\/p>\n\n\n\nPer i progetti CAN o RS485 vale lo stesso principio. Fornire le specifiche del controller, la mappa dei messaggi o dei registri, la velocit\u00e0 di comunicazione, la piedinatura, l'architettura del caricabatterie, la tensione, la capacit\u00e0, i requisiti di corrente e il comportamento di errore previsto offre al produttore della batteria un obiettivo di integrazione molto pi\u00f9 chiaro.<\/p>\n\n\n\n
Il diritto comunicazione con la batteria del robot<\/strong> il metodo non \u00e8 quindi determinato scegliendo CAN, RS485 o CANopen isolatamente. \u00c8 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.<\/p>\n\n\n\n
![\"Batteria](\"https:\/\/manlybattery.com\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs.webp\")
<\/a><\/figure>\n\n\n\n![\"Batteria](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs-300x200.webp\")
![\"I](\"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\")
![\"Soluzione](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Backup-battery-solution-300x300.webp\")