Arduino Lab 16 Leitura de dados de um servo driver SEW via rede CAN e interface com LabVIEW

Transcrição

1 Arduino Lab 16 Leitura de dados de um servo driver SEW via rede CAN e interface com LabVIEW Neste Lab explicaremos como funciona a rede de comunicação CAN (Controller Area Network) bem como a comunicação entre um controlador para redes CAN de uma CPU PC680 da empresa B&R com dois Servo Driver MDX61B da SEW Eurodriver via um shield para Arduino com o Controlador MCP2515 e o transceiver MCP2551. Detalhe do Shield para CAN montado no equipamento Funcionamento da rede CAN A rede de comunicação serial CAN foi desenvolvida pela empresa alemã Bosh em 1985 com o propósito de reduzir a quantidade de

2 cabos de comunicação entre dispositivos eletrônicos dentro de um automóvel. Desta forma, esta rede se tornou um padrão para comunicação entre dispositivos embarcados e, em 1993 foi padronizada e também ficou conhecida como ISO Desde 1994 outros protocolos de alto nível voltados para a automação industrial passaram a ser padronizados em cima do protocolo CAN como o CANopen e o DeviceNet. Praticamente todos os fabricantes adotaram e disponibilizam opções para estes que agora são padrões na indústria. Sua arquitetura básica se baseia em vários dispositivos trocando mensagens, que são enviadas em forma de broadcasting para todos os nós integrantes. Cada dispositivo possui o seu transceiver para adequar os sinais e seu controlador CAN que lê e filtra as mensagens pertinentes que circulam pelo barramento. A figura abaixo mostra a topologia básica da rede e, inclusive, mostra os resistores de terminação que são obrigatórios para o funcionamento correto da mesma. Topologia básica da rede CAN As mensagens na rede CAN As redes CAN utilizam mensagens curtas, com uma carga máxima de 94 bits no modo ID de 29 bits. Não há endereços explícitos em cada mensagem can e todos os nós recebem os mesmos dados. Tipos de mensagens São quatro os diferentes tipos de mensagens ou frames que

3 podem circular pelo bus de dados na can. Eles serão explicados subsequentemente São eles: Data Frame, Remote Frame, Error frame, Overload Frame. Neste tutorial iremos apenas explicar o Data Frame que é o que nos interessa na comunicação com o Driver de potência da SEW. Os outros frames podem ser estudados separadamente pelo leitor que assim desejar. Data Frame Este é o tipo de mensagem mais comumente encontrado nos barramentos CAN. Este frame possui as seguintes partes: Campo de arbitragem: Determina a prioridade das mensagens quando dois ou mais nós estão disputando um espaço no barramento para transmissão. O campo de arbitragem contem: Para a CAN 2.0A um identificador de 11 bits e um bit denominado RTR que é dominante para data frames. Para a CAN 2.0B um identificador de 29 bits, que contem dois bits recessivos SRR e IDE, e o tradicional RTR. O campo de dados propriamente dito, que contem no máximo 8 bytes de dados; O campo com o CRC (Ciclic Redundance Check) que contem um checksum de 15 bits para detecção de erros de transmissão; Um campo de reconhecimento ou Acknowledment. Qualquer controlador CAN na rede que corretamente recebeu os dados a ele pertinentes envia um bit de reconhecimento no final da mensagem. O transmissor confere a presença deste bit e, se não for detectado, retransmite a mensagem novamente. Abaixo podemos observar o frame completo das mensagens na rede

4 CAN para o modo padrão (11bits) e estendido (29bits). Frame Padrão CAN Frame extendido CAN Prioridade barramento de mensagens e concorrência no A concorrência para trafego de mensagens entre os dispositivos é importante para que o trafego de transmissão no barramento possa fluir, pois mais de um dispositivo pode iniciar uma transmissão ao mesmo tempo e este fato causa conflitos e perda de dados. Qualquer controlador CAN pode iniciar uma transmissão quando o barramento indica a situação Idle ou em espera. Isto resulta em dois ou mais controladores iniciando um frame de mensagem quase que ao mesmo tempo. Este conflito é resolvido da seguinte maneira: Os nós que estão transmitindo monitoram o barramento enquanto estão enviando uma mensagem. Se um nó detecta um nível dominante presente no barramento enquanto o mesmo nó envia um nível recessivo, o mesmo irá imediatamente encerrar a concorrência pelo barramento e se tornar um receptor de dados.

5 Quando o barramento torna-se disponível novamente, o nó que tentava transmitir anteriormente inicia a comunicação e tenta enviar seus fremes ao barramento. Desta forma, nenhum tempo é perdido em meio a confusão de concorrência. Uma observação importante quanto as redes CAN é que os bits dominantes apresentam o valor lógico 0 e os recessivos o valor 1. A figura abaixo ilustra um diagrama temporal deste tipo de rede. Imagem rede CAN tratada Campo de identificação das mensagens Por padrão, o campo de identificação serve para indicar a prioridade do frame de mensagem no barramento onde os identificadores de menor valor possuem alta prioridade em relação aos de maior valor. Com os 11 bits podemos ter 2048 identificadores diferentes para as mensagens no barramento. Novamente, não há mensagens explicitamente endereçadas a um dispositivo em uma rede CAN. Cada controlador irá observar o barramento e utilizar uma combinação de filtros em hardware e software para determinar se a mensagem é útil ou não à aquele nó. De fato, os controladores CAN conseguem identificar as mensagens uteis através do campo de identificação no frame de dados. A diferença entre endereçar pacotes de mensagens a nós específicos e enviar mensagens em formato de broadcasting é grande e permite que vários dispositivos possam ser

6 pendurados no barramento e ainda sim se comunicarem em altas velocidades. Comunicação entre o Servo Driver da SEW e o Arduino Este trabalho iniciou-se diante da necessidade de identificar um problema de posicionamento em uma máquina CNC, do tipo Brochadeira da empresa Froemag onde rasgos para se encaixar chavetas de montagem com engrenagens aplicadas a redutores de velocidade são feitas nessa máquina. A figura abaixo ilustra este equipamento. Brochadeira Froemag O cabo de comunicação da rede foi conectado diretamente ao último driver, no borne X12, como pode ser observado na imagem abaixo (cabo vermelho e branco).

7 Imagem conexão com o driver Inicialmente montamos o shield junto ao Arduino Mega e instalamos a biblioteca desenvolvida por Cory J. Fowler, para a comunicação via SPI com o controlador CAN MCP2515, denominada MCP_CAN_lib na pasta libraries. A imagem abaixo mostra o Shield montado sobre o Arduino Mega.

8 Imagem CAN Shield e Arduino Mega Com o analisador lógico conectado na saída de dados do transceiver MCP2515, que também faz parte do shield, nos pinos 1 e 4 (Figura abaixo) e desta forma podemos capturar os dados que circulam na rede para comparar com os capturados pelo arduino. MCP2551 Abaixo podemos observar a tela de saída de dados do analisador lógico. A esquerda temos os dados que fluem pelo barramento na ordem em que eles foram capturados pelo analisador.

9 Imagem da tela do analisador lógico Diante dos dados indicados na imagem acima, podemos concluir que temos 8 diferentes ID s circulando pelo barramento CAN. Esta troca de mensagens é feita entre o controlador CAN da CPU da máquina e os Drivers da SEW. Depois de muita procura e pesquisa, no manual de número denominado MOVIDRIVE Serial Communication, referente a comunicação serial entre os Drivers e outros dispositivos, na página de número 37, é explicado como os Identificadores devem ser construídos na rede CAN aplicado a estes drivers. A figura abaixo ilustra identificadores. a composição dos dados nos

10 Construção dos identificadores para SEW Se desmembrarmos os dados contidos nos 8 identificadores que circulam nesta rede, poderemos saber a função de cada um e qual o tipo de dado é carregado pelos frames sob estes IDs. A tabela abaixo ilustra os IDs já desmembrados. Tabela de composição dos IDs A tabela subsequente, retirada da página 38 do mesmo manual confirma e mostra o tipo de frame de acordo com o campo Function do identificador. Tabela para o tipo de frame no BUS O tipo de telegrama ou frame denominado PO (Process Output Data Telegrama) é composto pelos dados de setpoint de processo como posição final a ser deslocada pelo eixo, velocidade de

11 avança ou aceleração. É o frame de controle para os drivers. Já o PI (Process Imput Data Telegram) é a resposta do driver ao mestre que lhe enviou os comandos contidos no PO e pode apresentar a condição do driver, posicionamento atual do encoder do motor entre outros. A figura abaixo ilustra o direcionamento deste tipo de frame. Direção de PO e PI Os dados em PO e PI são programados no momento de startup do driver nos parâmetros 870 a 876. A figura abaixo mostra uma parte da tabela dos parâmetros retirada da página 41 do mesmo manual. Descrição PO e PI No caso desta aplicação, após desmembrar os IDs ao tipo de frame e em leituras in loco com o analisador lógico e com o Arduino, podemos estabelecer as seguintes relações dos frames a cada eixo da máquina:

12 Designação dos frames Leitura Arduino dos dados com o Tendo em mãos o que cada frame de dados carrega pelo barramento CAN, o shield com o MCP2515 e MCP2551 e a biblioteca instalada nós podemos iniciar a aplicação de leitura dos dados que nos interessam utilizando os filtros já embutidos dentro do controlador (In Hardware). Levando em conta a velocidade de transmissão deste barramento, que é de 500Kbps, o uso de filtros é de extrema importância nesta aplicação visto que são muitos dados a serem recebidos e processados pelo Arduino e interface no computador sem que os dados sejam corrompidos ou perdidos. A biblioteca para comunicação com este controlador pode ser baixada neste link. O código estabelece uma comunicação estável com o controlador via SPI e o autor Cory J. Fowler nos presenteou com vários exemplos e ainda presta suporte e ajuda para os usuários da mesma. O código abaixo foi modificado do exemplo referente aos filtros in hardware e é a única modificação importante do lado do Arduino para esta aplicação pois todo o processamento dos dados será feito na interface feita em LabVIEW. [crayon-5a /]

13 Os frames de dados do tipo PO e PI (0x014, 0x015, 0x01C e 0x01B) possuem um tamanho de 6 bytes. Já os frames de Parameter request / response possuem 8 bytes de tamanho. Estes dados precisam ser separados de acordo com o tipo. Lembrando a designação do dado a ser carregado pelo frame foi feita no startup do driver. A imagem abaixo detalha a composição de cada freme de dado. Indicação dos dados em cada frame As informações de obtidas após a decomposição destes dados só foi possível tendo em mãos o manual para comunicação serial, já citado acima e um analisador lógico para apanhar os dados em tempo real e em alta velocidade para comparação do que é exposto pela literatura ao que realmente acontece em campo. A fabricante do equipamento Froemag não disponibiliza as informações que obtivemos pois julga ser segredo industrial de seus equipamentos. Os valores de posicionamento foram fornecidos em valores

14 absolutos de posição pois os encoders acoplados aos motores são do tipo absoluto. Desta forma, a conversão dos pulsos em deslocamento linear foi necessária. Para o eixo vertical, após alguns cálculos e comparações com os valores encontrados na tela da máquina no momento dos testes, foi encontrado um valor constante. Uma parte da planilha utilizada nos cálculos da conversão, para o eixo vertical, está indicada abaixo. Detalhe conversão eixo vertical Já o eixo de avanço, devido ao formato em cunha do dispositivo da ferramenta de corte, os cálculos consideraram o ângulo desta cunha e o suporte de fixação para a conversão correta dos pulsos em valores de deslocamento linear. A parte da planilha responsável por este eixo está indicada abaixo.

15 Detalhe conversão eixo de avanço Um detalhe importante a ser citado é que quando o eixo está em uma posição negativa de contagem do encoder absoluto, o valor 0xFF é configurado no Byte 2. Assim os cálculos devem considerar o valor de overflow, subtraído ao valor absoluto recebido. Este procedimento está indicado nas imagens acima. Interface Arduino LabVIEW via serial com o O software LabVIEW é um ambiente de criação de sistemas de alta complexidade para interpretação de dados e criação de telas de interface que facilitam a leitura, interpretação e interação com o usuário. Utiliza como forma de programação a montagem de blocos prontos e configuráveis que são conectados entre si para construção do sistema. Nesta aplicação construímos um ambiente que recebe os dados provindos do Arduino através da porta serial, a uma velocidade de bps, e os interpreta utilizando o poder de processamento do PC e deixando para o Arduino apenas a tarefa de comunicação com o Driver CAN e envio dos dados ao PC. Na figura abaixo podemos observar o resultado da interface de

16 leitura dos dados. Interface do sistema A imagem abaixo ilustra uma pequena parte do diagrama em blocos desta aplicação feita no LabVIEW. Diagrama de blocos LabVIEW Arquivos disponíveis em:

17 Conclusão Neste Lab discutimos a implementação de um sistema para leitura dos dados de posicionamento dos encoders em um servo driver da SEW. Notamos também que o Arduino não é capaz de processar grandes quantidades de dados que circulam em uma rede CAN devido a capacidade de processamento e velocidade de transmissão dos dados no barramento. Por isso, utilizamos somente três filtros dos dados que circulam entre o PC e os Drivers da SEW.