bateria de rob\u00f4<\/a><\/strong> tamb\u00e9m pode relatar temperaturas, corrente, estados de alerta, condi\u00e7\u00f5es de prote\u00e7\u00e3o e limites permitidos de carga ou descarga. Quando as condi\u00e7\u00f5es de opera\u00e7\u00e3o mudam, esses valores fornecem ao controlador do ve\u00edculo informa\u00e7\u00f5es que ele pode usar antes que o BMS atinja um estado de prote\u00e7\u00e3o total.<\/p>\n\n\n\nIsso torna a comunica\u00e7\u00e3o da bateria do rob\u00f4 \u00fatil tanto para opera\u00e7\u00e3o quanto para manuten\u00e7\u00e3o imediata. O software de frota pode usar informa\u00e7\u00f5es consistentes de status e falhas para distinguir uma condi\u00e7\u00e3o de baixa energia de um evento t\u00e9rmico, evento de prote\u00e7\u00e3o ou falha de comunica\u00e7\u00e3o.<\/p>\n\n\n\n
Apertos de m\u00e3o do controlador e do carregador<\/h3>\n\n\n\n O controlador e o carregador do ve\u00edculo n\u00e3o requerem necessariamente dados id\u00eanticos da bateria. Durante o movimento, o controlador pode priorizar SOC, tens\u00e3o, corrente, temperatura, avisos e limites de descarga. Durante o carregamento, o sistema tamb\u00e9m pode precisar de permiss\u00e3o de carregamento, limites de corrente de carga, limites de tens\u00e3o, status de temperatura e informa\u00e7\u00f5es sobre o estado de carga.<\/p>\n\n\n\n
\u00c9 por isso que especificar uma bateria CAN BMS ou uma bateria RS485 BMS \u00e9 apenas o primeiro passo. Dois dispositivos podem compartilhar a mesma interface el\u00e9trica, mas usar identificadores, registros, fatores de escala, intervalos de atualiza\u00e7\u00e3o ou l\u00f3gica de controle diferentes.<\/p>\n\n\n\n
O carregamento autom\u00e1tico torna a distin\u00e7\u00e3o particularmente importante. Quando um AGV ou AMR atraca sem interven\u00e7\u00e3o do operador, a bateria, o carregador e o controlador do rob\u00f4 precisam de um comportamento definido para autoriza\u00e7\u00e3o de carregamento, limites operacionais, tratamento de falhas, conclus\u00e3o de carga e retorno ao servi\u00e7o.<\/p>\n\n\n\n
Por que a comunica\u00e7\u00e3o afeta o tempo de atividade<\/h3>\n\n\n\n A comunica\u00e7\u00e3o \u00fatil da bateria permite que o rob\u00f4 responda \u00e0s condi\u00e7\u00f5es da bateria antes que um desligamento for\u00e7ado se torne a \u00fanica resposta dispon\u00edvel. Um SOC baixo pode iniciar uma tarefa de carregamento, uma condi\u00e7\u00e3o de temperatura pode afetar o comportamento de carregamento e uma falha relatada pode colocar o ve\u00edculo em um estado de servi\u00e7o definido.<\/p>\n\n\n\n
Para frotas, dados consistentes da bateria do rob\u00f4 tamb\u00e9m melhoram a solu\u00e7\u00e3o de problemas. As equipes de manuten\u00e7\u00e3o podem revisar os estados operacionais e alarmes em vez de tratar cada perda de propuls\u00e3o ou interrup\u00e7\u00e3o de carga como o mesmo problema.<\/p>\n\n\n\n
O benef\u00edcio n\u00e3o \u00e9 simplesmente mais telemetria. O valor real vem de tornar a bateria uma parte integrada e interpret\u00e1vel da arquitetura de controle do rob\u00f4.<\/p>\n\n\n\n
CAN vs. RS485: Como eles diferem em sistemas rob\u00f3ticos<\/h2>\n\n\n\n CAN e RS485 s\u00e3o comuns em sistemas industriais, mas resolvem diferentes partes do problema de comunica\u00e7\u00e3o. CAN fornece mecanismos de enquadramento de mensagens, arbitragem, confirma\u00e7\u00e3o e gerenciamento de erros para um barramento compartilhado. RS485 define principalmente a sinaliza\u00e7\u00e3o el\u00e9trica usada para comunica\u00e7\u00e3o serial.<\/p>\n\n\n\n
Essa distin\u00e7\u00e3o \u00e9 importante quando os engenheiros selecionam uma arquitetura de comunica\u00e7\u00e3o para uma bateria de rob\u00f4.<\/p>\n\n\n\n
CAN como uma rede<\/h3>\n\n\n\n CAN foi projetado para v\u00e1rios dispositivos se comunicando em um barramento compartilhado. As mensagens s\u00e3o identificadas por identificadores CAN e as tentativas de transmiss\u00e3o simult\u00e2nea s\u00e3o resolvidas atrav\u00e9s de arbitragem baseada em prioridade.<\/p>\n\n\n\n
Para a comunica\u00e7\u00e3o da bateria do rob\u00f4, esta arquitetura pode suportar mensagens regulares de status, limites operacionais, informa\u00e7\u00f5es de aviso e relat\u00f3rios de falhas orientados por eventos. O atual projeto de refer\u00eancia BMS de rob\u00f3tica m\u00f3vel MR-BMS771 da NXP inclui dois barramentos CAN, fornecendo um exemplo pr\u00e1tico de CAN sendo integrado diretamente em uma plataforma rob\u00f3tica de gerenciamento de bateria.<\/p>\n\n\n\n
Uma porta CAN por si s\u00f3, entretanto, n\u00e3o define o significado dos dados. Um BMS de bateria CAN e um controlador de rob\u00f4 ainda precisam de taxas de bits, identificadores, defini\u00e7\u00f5es de carga \u00fatil, escala, tempo de transmiss\u00e3o e l\u00f3gica de aplica\u00e7\u00e3o compat\u00edveis.<\/p>\n\n\n\n
RS485 como interface f\u00edsica<\/h3>\n\n\n\n RS485 \u00e9 uma interface serial diferencial amplamente utilizada em comunica\u00e7\u00e3o multiponto industrial. \u00c9 particularmente \u00fatil onde o equipamento j\u00e1 utiliza redes seriais ou onde um controlador se comunica com v\u00e1rios dispositivos endere\u00e7ados.<\/p>\n\n\n\n
Para uma bateria de rob\u00f4, o ponto cr\u00edtico \u00e9 que o RS485 sozinho n\u00e3o informa ao controlador o que significa qualquer byte. Um BMS de bateria RS485 ainda precisa de um protocolo de aplica\u00e7\u00e3o definido ou de uma estrutura de dados propriet\u00e1ria.<\/p>\n\n\n\n
Esta distin\u00e7\u00e3o explica porque RS485 e Modbus RTU frequentemente aparecem juntos sem serem sin\u00f4nimos. A Organiza\u00e7\u00e3o Modbus documenta implementa\u00e7\u00f5es de linha serial Modbus usando EIA\/TIA-485, enquanto o pr\u00f3prio Modbus define o comportamento de mensagens de n\u00edvel superior.<\/p>\n\n\n\n
Uma especifica\u00e7\u00e3o de compra deve, portanto, dizer mais do que \u201cRS485 necess\u00e1rio\u201d. Deve identificar o protocolo real e o mapa de dados esperado pelo rob\u00f4.<\/p>\n\n\n\n
Arbitragem CAN e tratamento de erros<\/h3>\n\n\n\n CAN permite que os n\u00f3s transmitam sem esperar que um controlador central atribua todas as oportunidades de transmiss\u00e3o. Se dois n\u00f3s come\u00e7arem a transmitir ao mesmo tempo, a arbitragem baseada nos identificadores de mensagens determinar\u00e1 qual quadro continuar\u00e1.<\/p>\n\n\n\n
CAN tamb\u00e9m inclui mecanismos para detectar erros de transmiss\u00e3o e gerenciar n\u00f3s que geram erros repetidamente. Estas caracter\u00edsticas tornam-no adequado para redes onde o bateria de rob\u00f4<\/strong> deve trocar dados operacionais frequentes com outros controladores.<\/p>\n\n\n\nA decis\u00e3o de engenharia n\u00e3o deve ser reduzida a uma afirma\u00e7\u00e3o gen\u00e9rica de que o CAN \u00e9 simplesmente \u201cmais r\u00e1pido\u201d. O que importa \u00e9 se as mensagens de bateria necess\u00e1rias podem ser entregues com a prioridade necess\u00e1ria e atualizar o tempo sob a carga esperada do barramento.<\/p>\n\n\n\n
Para um rob\u00f4 m\u00f3vel, um pequeno conjunto de mensagens de bateria corretamente priorizadas e documentadas costuma ser mais valioso do que uma taxa de dados teoricamente alta com comportamento de aplicativo mal definido.<\/p>\n\n\n\n
Modbus RTU sobre RS485<\/h3>\n\n\n\n O Modbus RTU fornece uma estrutura de mensagens em n\u00edvel de aplicativo que pode operar em um link serial RS485. O protocolo define como os dispositivos endere\u00e7ados trocam solicita\u00e7\u00f5es e respostas, enquanto o mapa de registro espec\u00edfico do equipamento identifica onde os valores individuais s\u00e3o armazenados.<\/p>\n\n\n\n
Para uma bateria de rob\u00f4, um mapa Modbus RTU pode conter registros de tens\u00e3o do pacote, corrente, SOC, temperatura, alarmes ou limites operacionais. A interpreta\u00e7\u00e3o correta exige que o controlador conhe\u00e7a o endere\u00e7o do registro, o formato dos dados, o fator de escala, a ordem dos bytes, o endere\u00e7o do dispositivo, a taxa de transmiss\u00e3o, a paridade e o comportamento do tempo limite.<\/p>\n\n\n\n
V\u00e1rias distin\u00e7\u00f5es s\u00e3o importantes durante a integra\u00e7\u00e3o: RS485 n\u00e3o significa automaticamente Modbus RTU; dois dispositivos Modbus n\u00e3o usam automaticamente o mesmo mapa de registro; um conector RJ45 n\u00e3o estabelece compatibilidade com Ethernet, CAN ou RS485; e uma conex\u00e3o eletricamente v\u00e1lida n\u00e3o garante compatibilidade em n\u00edvel de aplica\u00e7\u00e3o.<\/p>\n\n\n\n
Estas verifica\u00e7\u00f5es evitam uma falha de integra\u00e7\u00e3o comum: ambos os lados parecem suportar a mesma tecnologia de comunica\u00e7\u00e3o, mas a bateria e o controlador do rob\u00f4 n\u00e3o conseguem compreender os dados um do outro.<\/p>\n\n\n\n
Onde o CANopen se encaixa em um sistema de bateria de rob\u00f4<\/h2>\n\n\n\n CANopen fica acima do CAN na pilha de comunica\u00e7\u00e3o. N\u00e3o substitui o barramento CAN. Em vez disso, o CANopen define mecanismos padronizados para organizar dados de dispositivos, transmitir informa\u00e7\u00f5es de processos, acessar par\u00e2metros de configura\u00e7\u00e3o, controlar estados de rede e monitorar participantes da rede.<\/p>\n\n\n\n
Uma implementa\u00e7\u00e3o de bateria CANopen requer, portanto, mais do que um transceptor CAN ou conector CAN. O BMS deve implementar as fun\u00e7\u00f5es CANopen exigidas pelo controlador host.<\/p>\n\n\n\n
CAN n\u00e3o \u00e9 CANopen<\/h3>\n\n\n\n CAN fornece o mecanismo de comunica\u00e7\u00e3o de rede subjacente. CANopen adiciona a estrutura de camada superior que determina como os dispositivos baseados em CAN organizam e trocam dados de aplica\u00e7\u00e3o.<\/p>\n\n\n\n
CAN in Automation, ou CiA, descreve um dispositivo CANopen como tendo uma pilha de protocolos CANopen, software de aplica\u00e7\u00e3o e um dicion\u00e1rio de objetos que conecta o sistema de comunica\u00e7\u00e3o com par\u00e2metros de aplica\u00e7\u00e3o.<\/p>\n\n\n\n
Isto torna uma regra de aquisi\u00e7\u00e3o especialmente importante:<\/p>\n\n\n\n
Suporte CAN n\u00e3o significa automaticamente suporte CANopen.<\/strong><\/p>\n\n\n\nSe um controlador AMR exigir uma bateria CANopen, a especifica\u00e7\u00e3o dever\u00e1 identificar a funcionalidade CANopen e os mapeamentos de dados esperados pelo controlador. Simplesmente solicitar uma porta CAN n\u00e3o \u00e9 suficiente.<\/p>\n\n\n\n
O Dicion\u00e1rio de Objetos CANopen<\/h3>\n\n\n\n O dicion\u00e1rio de objetos \u00e9 o modelo de dados estruturados utilizado pelos dispositivos CANopen. CiA especifica que os par\u00e2metros de comunica\u00e7\u00e3o e aplica\u00e7\u00e3o s\u00e3o organizados atrav\u00e9s de entradas indexadas de dicion\u00e1rio de objetos, com valores de \u00edndice e sub\u00edndice fornecendo endere\u00e7os definidos para dados.<\/p>\n\n\n\n
Em uma integra\u00e7\u00e3o de bateria CANopen, esta estrutura pode fornecer uma maneira consistente de expor o status da bateria, par\u00e2metros de configura\u00e7\u00e3o e informa\u00e7\u00f5es de diagn\u00f3stico. Os objetos reais da bateria ainda precisam atender aos requisitos do controlador e a qualquer perfil aplic\u00e1vel ou especifica\u00e7\u00e3o de projeto.<\/p>\n\n\n\n
A vantagem pr\u00e1tica \u00e9 a clareza. Os engenheiros n\u00e3o precisam tratar cada quadro CAN como uma mensagem propriet\u00e1ria isolada quando uma implementa\u00e7\u00e3o CANopen definida \u00e9 usada. Eles podem trabalhar com objetos documentados e servi\u00e7os de comunica\u00e7\u00e3o.<\/p>\n\n\n\n
PDOs, SDOs e Diagn\u00f3sticos<\/h3>\n\n\n\n CANopen separa diferentes tarefas de comunica\u00e7\u00e3o atrav\u00e9s de servi\u00e7os definidos. Process Data Objects, ou PDOs, s\u00e3o adequados para processar informa\u00e7\u00f5es trocadas durante a opera\u00e7\u00e3o. Objetos de dados de servi\u00e7o, ou SDOs, fornecem acesso a entradas no dicion\u00e1rio de objetos para configura\u00e7\u00e3o e fun\u00e7\u00f5es de servi\u00e7o.<\/p>\n\n\n\n
CANopen tamb\u00e9m fornece mecanismos para relat\u00f3rio de erros e supervis\u00e3o de n\u00f3s. A documenta\u00e7\u00e3o da CiA identifica fun\u00e7\u00f5es PDO, SDO, emerg\u00eancia, pulsa\u00e7\u00e3o e gerenciamento de rede como partes da arquitetura de comunica\u00e7\u00e3o CANopen.<\/p>\n\n\n\n
Para uma bateria CANopen, os valores operacionais frequentemente necess\u00e1rios podem ser mapeados na comunica\u00e7\u00e3o PDO, enquanto o acesso SDO pode suportar comissionamento ou diagn\u00f3stico. O mapeamento exacto deve ser acordado antes da integra\u00e7\u00e3o e n\u00e3o assumido.<\/p>\n\n\n\n
\u00c9 tamb\u00e9m por isso que uma bateria de rob\u00f4 que se comunica com sucesso atrav\u00e9s de CAN propriet\u00e1rio n\u00e3o pode ser automaticamente tratada como compat\u00edvel com CANopen.<\/p>\n\n\n\n
Gerenciamento de rede e pulsa\u00e7\u00f5es<\/h3>\n\n\n\n O CANopen Network Management, ou NMT, define os estados de comunica\u00e7\u00e3o para um dispositivo. CiA identifica estados de inicializa\u00e7\u00e3o, pr\u00e9-operacional, operacional e parado dentro da m\u00e1quina de estado CANopen NMT. A comunica\u00e7\u00e3o PDO fica dispon\u00edvel no estado operacional, enquanto a comunica\u00e7\u00e3o SDO pode ser utilizada no estado pr\u00e9-operacional.<\/p>\n\n\n\n
Para a comunica\u00e7\u00e3o da bateria do rob\u00f4, esses estados ajudam a definir o comportamento durante a inicializa\u00e7\u00e3o, comissionamento, opera\u00e7\u00e3o normal, desligamento e recupera\u00e7\u00e3o.<\/p>\n\n\n\n
Os mecanismos de pulsa\u00e7\u00e3o fornecem outra fun\u00e7\u00e3o \u00fatil, permitindo que o controlador determine se um n\u00f3 esperado permanece presente na rede. Uma especifica\u00e7\u00e3o de bateria CANopen deve, portanto, abranger mais do que campos de dados da bateria. O estado de inicializa\u00e7\u00e3o, o tempo de pulsa\u00e7\u00e3o, a resposta de tempo limite e o comportamento de recupera\u00e7\u00e3o tamb\u00e9m podem ser importantes para o rob\u00f4.<\/p>\n\n\n\n
Escolhendo a interface certa para AGVs e AMRs<\/h2>\n\n\n\n O m\u00e9todo de comunica\u00e7\u00e3o correto \u00e9 aquele que corresponde \u00e0 arquitetura de controle existente do rob\u00f4 e fornece as informa\u00e7\u00f5es da bateria exigidas por esse sistema.<\/p>\n\n\n\n
A sele\u00e7\u00e3o do protocolo deve, portanto, come\u00e7ar com o controlador host e a arquitetura de carregamento, em vez de uma prefer\u00eancia gen\u00e9rica por CAN ou RS485.<\/p>\n\n\n\n
Combine a rede de rob\u00f4s existente<\/h3>\n\n\n\n O primeiro passo \u00e9 determinar exatamente o que o controlador do rob\u00f4 espera. Um controlador pode usar quadros CAN propriet\u00e1rios, CANopen, RS485 com Modbus RTU ou outro protocolo documentado.<\/p>\n\n\n\nArquitetura existente<\/th> Requisito apropriado de bateria do rob\u00f4<\/th><\/tr><\/thead> Controlador CAN propriet\u00e1rio<\/td> Bateria CAN BMS com taxa de bits e mapa de mensagens correspondentes<\/td><\/tr> Controlador CANopen<\/td> BMS implementando os objetos CANopen necess\u00e1rios e comportamento de rede<\/td><\/tr> PLC ou controlador usando Modbus RTU<\/td> Bateria RS485 BMS com configura\u00e7\u00f5es seriais correspondentes e mapa de registro<\/td><\/tr> Redes separadas de controle e diagn\u00f3stico<\/td> Defina qual conex\u00e3o carrega o controle da bateria e qual carrega os dados de servi\u00e7o<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nA bateria do rob\u00f4 deve corresponder a esse requisito de rede. Escolher um pacote porque seu conector ou etiqueta de porta parece familiar reverte o processo de engenharia correto.<\/p>\n\n\n\n
Defina os dados necess\u00e1rios da bateria<\/h3>\n\n\n\n Antes de solicitar um pacote personalizado, os engenheiros devem criar uma matriz de comunica\u00e7\u00e3o que separe os dados necess\u00e1rios para a opera\u00e7\u00e3o das informa\u00e7\u00f5es destinadas principalmente ao diagn\u00f3stico ou manuten\u00e7\u00e3o.<\/p>\n\n\n\n
Para muitos projetos AGV e AMR, o necess\u00e1rio bateria de rob\u00f4<\/strong> os dados incluem:<\/p>\n\n\n\n\nTens\u00e3o e corrente do pacote<\/li>\n\n\n\n SOC e SOH<\/li>\n\n\n\n Temperatura da bateria<\/li>\n\n\n\n Limites de carga e descarga<\/li>\n\n\n\n Estados de aviso e prote\u00e7\u00e3o<\/li>\n\n\n\n Status de carregamento e estado do BMS<\/li>\n\n\n\n Identidade do dispositivo ou endere\u00e7o de rede<\/li>\n\n\n\n Status do contator ou MOSFET quando exigido pelo sistema<\/li>\n<\/ul>\n\n\n\nO projeto tamb\u00e9m deve definir a dire\u00e7\u00e3o dos dados. Algumas informa\u00e7\u00f5es s\u00e3o transmitidas do BMS da bateria AMR para o host, enquanto outras arquiteturas podem exigir comandos de controle, confirma\u00e7\u00f5es ou mensagens de configura\u00e7\u00e3o do controlador.<\/p>\n\n\n\n
Esta etapa determina o que a interface realmente deve realizar.<\/p>\n\n\n\n
Verifique o tempo e a resposta a falhas<\/h3>\n\n\n\n Uma especifica\u00e7\u00e3o de comunica\u00e7\u00e3o completa precisa de requisitos de temporiza\u00e7\u00e3o al\u00e9m de defini\u00e7\u00f5es de dados.<\/p>\n\n\n\n
Os engenheiros devem determinar com que frequ\u00eancia as informa\u00e7\u00f5es cr\u00edticas da bateria do rob\u00f4 devem ser atualizadas, quanto tempo o controlador espera antes de declarar o BMS offline e qual resposta segue um tempo limite de comunica\u00e7\u00e3o. As prioridades das mensagens CAN ou os intervalos de pesquisa RS485 devem refletir a import\u00e2ncia dos dados que est\u00e3o sendo transferidos.<\/p>\n\n\n\n
A recupera\u00e7\u00e3o de falhas tamb\u00e9m precisa de um comportamento definido. O sistema deve estabelecer se a comunica\u00e7\u00e3o \u00e9 retomada automaticamente ap\u00f3s um evento transit\u00f3rio, se o BMS requer uma reinicializa\u00e7\u00e3o e se o rob\u00f4 pode retomar a opera\u00e7\u00e3o imediatamente ou deve primeiro verificar o status da bateria.<\/p>\n\n\n\n
Essas decis\u00f5es s\u00e3o espec\u00edficas da aplica\u00e7\u00e3o. Devem ser documentados durante a integra\u00e7\u00e3o e n\u00e3o inferidos a partir da interface de comunica\u00e7\u00e3o.<\/p>\n\n\n\n
Planejar a comunica\u00e7\u00e3o da esta\u00e7\u00e3o de carregamento<\/h3>\n\n\n\n Um AGV ou AMR carregado automaticamente precisa da base de carregamento considerada parte do bateria de rob\u00f4<\/strong> arquitetura.<\/p>\n\n\n\nO sistema de carregamento pode precisar coordenar a permiss\u00e3o de carregamento, tens\u00e3o da bateria, limites de corrente, estado de temperatura, status de carregamento, conclus\u00e3o e condi\u00e7\u00f5es de falha. Contatos f\u00edsicos de carregamento ou um receptor de energia sem contato fornecem o caminho de energia, mas n\u00e3o definem o comportamento da comunica\u00e7\u00e3o.<\/p>\n\n\n\n
O rob\u00f4 tamb\u00e9m precisa de uma sequ\u00eancia clara para detectar a doca, permitir o carregamento, responder aos limites do BMS, concluir o processo de carregamento e retornar \u00e0 opera\u00e7\u00e3o.<\/p>\n\n\n\n
A orienta\u00e7\u00e3o atual de integra\u00e7\u00e3o AMR da bateria MANLY identifica comunica\u00e7\u00e3o CAN ou RS485, monitoramento de corrente e temperatura, design de conector e fia\u00e7\u00e3o espec\u00edfica da aplica\u00e7\u00e3o como fatores a serem coordenados ao integrar uma bateria AMR, BMS e base de carregamento.<\/p>\n\n\n\n
Para frotas aut\u00f3nomas, a comunica\u00e7\u00e3o de carregamento deve, portanto, ser concebida ao mesmo tempo que a bateria do rob\u00f4 e o BMS, e n\u00e3o depois de o pacote j\u00e1 ter sido finalizado.<\/p>\n\n\n\n
Considere as necessidades de diagn\u00f3stico da frota<\/h3>\n\n\n\n Os dados de tr\u00e1fego e manuten\u00e7\u00e3o de controle nem sempre precisam usar o mesmo caminho de comunica\u00e7\u00e3o. Alguns rob\u00f4s colocam dados da bateria sens\u00edveis ao tempo na rede CAN prim\u00e1ria enquanto usam uma interface separada para comissionamento, servi\u00e7o ou diagn\u00f3sticos mais profundos.<\/p>\n\n\n\n
O que importa \u00e9 que a arquitetura diagn\u00f3stica seja deliberada.<\/p>\n\n\n\n
Para grandes frotas, defini\u00e7\u00f5es consistentes de dados de baterias de rob\u00f4s podem simplificar a solu\u00e7\u00e3o de problemas em muitos ve\u00edculos. C\u00f3digos de falha, unidades, escala, vers\u00f5es de firmware, estados de comunica\u00e7\u00e3o e registros de manuten\u00e7\u00e3o devem ter significados repet\u00edveis de um rob\u00f4 para outro.<\/p>\n\n\n\n
Isto pode tornar-se particularmente valioso quando o software da frota \u00e9 utilizado para distinguir eventos relacionados com a energia de falhas do BMS, falhas do carregador ou falhas de comunica\u00e7\u00e3o.<\/p>\n\n\n\n
O que perguntar a um fabricante de baterias antes da integra\u00e7\u00e3o<\/h2>\n\n\n\n UM fabricante de baterias<\/a><\/strong> deve ser capaz de discutir a comunica\u00e7\u00e3o BMS com os mesmos detalhes de engenharia usados \u200b\u200bpara tens\u00e3o do pacote, capacidade, corrente, dimens\u00f5es e requisitos de conector.<\/p>\n\n\n\n\u201cCAN dispon\u00edvel\u201d ou \u201cRS485 dispon\u00edvel\u201d \u00e9 \u00fatil para triagem inicial, mas uma bateria de rob\u00f4 de produ\u00e7\u00e3o requer uma especifica\u00e7\u00e3o de comunica\u00e7\u00e3o mais completa.<\/p>\n\n\n\n
Protocolo e mapa de mensagens<\/h3>\n\n\n\n Para integra\u00e7\u00e3o CAN, solicite o protocolo de aplica\u00e7\u00e3o, identificadores CAN, defini\u00e7\u00f5es de carga \u00fatil, escala, dire\u00e7\u00e3o da mensagem, tempo de transmiss\u00e3o e comportamento de tempo limite.<\/p>\n\n\n\n
Para uma bateria CANopen, defina as entradas necess\u00e1rias do dicion\u00e1rio de objetos, mapeamentos PDO, acesso SDO, comportamento NMT, requisitos de pulsa\u00e7\u00e3o e fun\u00e7\u00f5es espec\u00edficas do controlador.<\/p>\n\n\n\n
Se o projeto usar comunica\u00e7\u00e3o CAN espec\u00edfica do fabricante, a defini\u00e7\u00e3o da mensagem dever\u00e1 estar dispon\u00edvel com anteced\u00eancia suficiente para o desenvolvimento do controlador e testes de bancada. A equipe de software n\u00e3o deveria ter que fazer engenharia reversa do bateria de rob\u00f4<\/strong> ap\u00f3s a chegada do hardware do prot\u00f3tipo.<\/p>\n\n\n\nTaxa de transmiss\u00e3o e IDs de n\u00f3<\/h3>\n\n\n\n Ambos os lados da conex\u00e3o devem usar configura\u00e7\u00f5es de rede compat\u00edveis.<\/p>\n\n\n\n
Para CAN, confirme a taxa de bits CAN e o identificador relevante ou configura\u00e7\u00e3o do n\u00f3. Para CANopen, defina tamb\u00e9m os IDs dos n\u00f3s e o comportamento de gerenciamento de rede necess\u00e1rio. Para um BMS de bateria RS485, confirme a taxa de transmiss\u00e3o, a paridade, os bits de parada, o endere\u00e7amento e o comportamento esperado de pesquisa ou resposta.<\/p>\n\n\n\n
Esses par\u00e2metros devem ser registrados na especifica\u00e7\u00e3o de comunica\u00e7\u00e3o do projeto e controlados como qualquer outro requisito de interface no n\u00edvel do sistema.<\/p>\n\n\n\n
Registrar Mapa e Dimensionamento de Dados<\/h3>\n\n\n\n Uma conex\u00e3o RS485 usando Modbus RTU necessita de um mapa de registro completo. Cada valor necess\u00e1rio deve ter endere\u00e7o, tipo de dados, fator de escala, unidade de engenharia e m\u00e9todo de acesso definidos.<\/p>\n\n\n\n
Por exemplo, um valor transmitido n\u00e3o pode ser interpretado corretamente at\u00e9 que o controlador saiba se ele representa volts, milivolts, d\u00e9cimos de volt, corrente com sinal ou outra codifica\u00e7\u00e3o.<\/p>\n\n\n\n
O mesmo princ\u00edpio se aplica ao CAN. Receber um quadro CAN v\u00e1lido n\u00e3o prova que o bateria de rob\u00f4<\/strong> os dados foram interpretados corretamente. A ordem dos bytes, as defini\u00e7\u00f5es de bits, a escala, os valores assinados e os sinalizadores de status ainda precisam corresponder.<\/p>\n\n\n\nTermina\u00e7\u00e3o, pinagem e conectores<\/h3>\n\n\n\n A documenta\u00e7\u00e3o el\u00e9trica deve identificar todos os pinos de comunica\u00e7\u00e3o necess\u00e1rios, incluindo CAN-H, CAN-L, RS485-A, RS485-B, terra de sinal, linhas de ativa\u00e7\u00e3o, blindagem ou outros condutores espec\u00edficos do projeto.<\/p>\n\n\n\n
A termina\u00e7\u00e3o tamb\u00e9m deve corresponder \u00e0 topologia de rede selecionada. Os engenheiros devem verificar se a termina\u00e7\u00e3o est\u00e1 dentro da bateria do rob\u00f4, instalada em outro lugar do rob\u00f4, configur\u00e1vel ou omitida.<\/p>\n\n\n\n
O formato do conector nunca deve ser usado como substituto desta documenta\u00e7\u00e3o. Um conector estilo RJ45, por exemplo, n\u00e3o indica automaticamente Ethernet e n\u00e3o estabelece uma pinagem CAN ou RS485 padronizada.<\/p>\n\n\n\n
O projeto do cabo e do conector, portanto, pertence \u00e0 especifica\u00e7\u00e3o de comunica\u00e7\u00e3o e n\u00e3o apenas ao desenho mec\u00e2nico.<\/p>\n\n\n\n
Requisitos de comunica\u00e7\u00e3o do carregador<\/h3>\n\n\n\n A bateria e o carregador do rob\u00f4 devem ser projetados como um sistema coordenado quando o processo de carregamento exigir comunica\u00e7\u00e3o.<\/p>\n\n\n\n
A especifica\u00e7\u00e3o deve definir se o carregador utiliza configura\u00e7\u00f5es el\u00e9tricas fixas ou recebe limites din\u00e2micos do BMS ou do controlador do ve\u00edculo. Ele tamb\u00e9m deve documentar a l\u00f3gica de habilita\u00e7\u00e3o de carga, limites de corrente e tens\u00e3o, comportamento t\u00e9rmico, status de carga, conclus\u00e3o de carga, resposta a falhas, handshake de dock e recupera\u00e7\u00e3o ap\u00f3s interrup\u00e7\u00e3o de carga.<\/p>\n\n\n\n
Para um AGV ou AMR que depende de carregamento aut\u00f4nomo, essas fun\u00e7\u00f5es podem afetar diretamente a confiabilidade com que o rob\u00f4 retorna \u00e0 opera\u00e7\u00e3o ap\u00f3s chegar \u00e0 doca.<\/p>\n\n\n\n
Op\u00e7\u00f5es de comunica\u00e7\u00e3o de bateria MANLY<\/h3>\n\n\n\n Na MANLY Battery, projetos de rob\u00f4s e baterias industriais podem ser desenvolvidos em torno dos requisitos de comunica\u00e7\u00e3o da aplica\u00e7\u00e3o, em vez de tratar a interface como um complemento isolado.<\/p>\n\n\n\n
A bateria do rob\u00f4 MANLY 24V 50Ah \u00e9 um pacote LiFePO4 avaliado em 24V nominal, com uma tens\u00e3o real de bateria de 25,6V e 1.280Wh de energia nominal. Sua especifica\u00e7\u00e3o atual fornece comunica\u00e7\u00e3o opcional RS485, RS232 ou CANBus. Dimens\u00f5es, caixa, conector, caixa e fia\u00e7\u00e3o tamb\u00e9m podem ser configurados para requisitos OEM\/ODM.<\/p>\n\n\n\n
Para rob\u00f4s industriais que exigem maior capacidade integrada, a bateria do rob\u00f4 MANLY 48V 100Ah fornece capacidade de 100Ah e 4.800Wh de energia nominal. Ele tamb\u00e9m suporta comunica\u00e7\u00e3o opcional RS485, RS232 ou CANBus, com dimens\u00f5es, inv\u00f3lucros, conectores e fia\u00e7\u00e3o personaliz\u00e1veis.<\/p>\n\n\n\nBateria do rob\u00f4 MANLY<\/th> Comunica\u00e7\u00e3o<\/th> Foco na integra\u00e7\u00e3o<\/th><\/tr><\/thead> Bateria do rob\u00f4 24V 50Ah LiFePO4<\/td> RS485, RS232, CANBus opcionais<\/td> Projetos de rob\u00f4s e AGV que exigem comunica\u00e7\u00e3o BMS, conectores e dimens\u00f5es de pacote configur\u00e1veis<\/td><\/tr> bateria de rob\u00f4 industrial 48V 100Ah<\/td> RS485, RS232, CANBus opcionais<\/td> Aplica\u00e7\u00f5es de rob\u00f4s industriais de maior capacidade que exigem integra\u00e7\u00e3o coordenada de BMS, controlador, carregador e pacote<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSe um projeto exigir especificamente comunica\u00e7\u00e3o de bateria CANopen, esse requisito dever\u00e1 ser definido durante a revis\u00e3o de engenharia. A disponibilidade do CANBus por si s\u00f3 n\u00e3o deve ser tratada como uma confirma\u00e7\u00e3o da compatibilidade do CANopen.<\/p>\n\n\n\n
A equipe do projeto deve fornecer o mapeamento de objetos CANopen, configura\u00e7\u00e3o de rede, comportamento do controlador e outros requisitos de protocolo necess\u00e1rios para que a implementa\u00e7\u00e3o possa ser avaliada antes do bateria de rob\u00f4<\/strong> o projeto est\u00e1 finalizado.<\/p>\n\n\n\nPara projetos CAN ou RS485, aplica-se o mesmo princ\u00edpio. Fornecer a especifica\u00e7\u00e3o do controlador, mapa de mensagens ou registros, velocidade de comunica\u00e7\u00e3o, pinagem, arquitetura do carregador, tens\u00e3o, capacidade, requisitos de corrente e comportamento de falha esperado d\u00e1 ao fabricante da bateria uma meta de integra\u00e7\u00e3o muito mais clara.<\/p>\n\n\n\n
A direita comunica\u00e7\u00e3o de bateria de rob\u00f4<\/strong> portanto, o m\u00e9todo n\u00e3o \u00e9 determinado pela escolha de CAN, RS485 ou CANopen isoladamente. \u00c9 determinado se o BMS, o controlador do rob\u00f4, o carregador, a fia\u00e7\u00e3o, o protocolo e a l\u00f3gica operacional foram projetados para funcionarem juntos como um sistema.<\/p>\n\n\n\n
![\"Bateria](\"https:\/\/manlybattery.com\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs.webp\")
<\/a><\/figure>\n\n\n\n![\"Bateria](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2026\/01\/Manly-agv-battery-lithum-battery-for-agvs-and-amrs-300x200.webp\")
![\"Centros](\"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\")
![\"Solu\u00e7\u00e3o](\"https:\/\/manlybattery-static-cdn.cimen.club\/manlybattery\/wp-content\/uploads\/2025\/12\/Backup-battery-solution-300x300.webp\")