Decodificando dados de mensagens neste barramento CAN

Exceto pela primeira mensagem, isso é típico de Tráfego SDO ( CANopen ), com pares de solicitação / resposta:

0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) 

Para o primeiro par, um dado morto é 0x4B no primeiro byte da resposta. Isso indica que os dados retornados têm dois bytes de tamanho (para um byte e quatro bytes, é 0x4F e 0x43, respectivamente). O 0x40 no primeiro byte da solicitação indica que é uma solicitação de leitura (o padrão usa um termo diferente, " Upload ", com o significado oposto ao da Internet (download) – é da perspectiva do dispositivo endereçado).

A solicitação CAN ID é 0x600 + ID do nó. A resposta CAN ID é 0x580 + ID do nó. Assim:

665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 

Para SDOs, o índice e subíndice CANopen está no segundo, terceiro e quarto byte (byte menos significativo primeiro para o índice CANopen). Portanto, para o primeiro par, 40 78 60 00, o solicitante diz: " Dispositivo no nó ID 0x65 (101), forneça seu valor armazenado em 6078sub0 " .

Neste caso, a informação está fluindo do dispositivo endereçado para quem fez a solicitação (o solicitante não pode ser visto no log do barramento CAN, mas geralmente é um controlador central no sistema ou uma ferramenta de serviço em execução em um PC (geralmente um adaptador USB-para-CAN)).

Assim, para o tráfego mostrado, as solicitações de leitura são feitas para (o a resposta do último não está incluída no log de barramento CAN postado):

6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) 

Estranhamente, a solicitação de 6041sub0 é repetida.

Além disso, embora os SDOs sejam geralmente apenas para informações de configuração, a faixa de índice CANopen 0x6000 a 0x6FFF é geralmente usada para informações de não configuração, como quantidades medidas ou status.

Mergulhando no manual

Os índices / subíndices SDO podem ser consultados no manual (I h ave incluiu os valores reais do exemplo de log do barramento CAN):

6078sub0 Motor current, 219 mA 6064sub0 "Position Actual Internal Value" is 6,192,612 6041sub0 Statusword, 0x0227 = 0000 0010 0010 0111, meaning: "ready to switch on", "switched on", "operation enabled", "quick stop" "remote" 606Csub0 "Velocity Actual Value". The value is not included, but it is a 32-bit signed integer. 

A primeira mensagem

Supondo que a primeira mensagem também seja CANopen, 4E5 F0 16 00 00: Para todas as mensagens CANopen CAN o ID é um código de função de quatro bits (0-15) seguido por um ID de nó de sete bits. Neste caso, 0x4E5 = 1001 1100101b. Assim, o código de função é 1001b = 9, significando " PDO4, transmitir ". A direção do fluxo de informações para PDOs (apesar, neste caso, " transmitir ") é uma questão de definição (depende da aplicação ) O ID do nó é 1100101b = 0x65.

O ID do nó para o PDO é o mesmo que para os SDOs.

As informações neste PDO, " Transmitir PDO 4 ", está contido no SDO 0x1A03, " Transmitir PDO Mapping Parâmetro 4 ". Se não tiver sido alterado do padrão, os dados no PDO são os mesmos que SDO 0x60FAsub0, um inteiro de 32 bits com sinal:

o controle esforço como a saída da malha de controle de posição. Na função de controle de posição, a notação do esforço de controle depende do modo e, portanto, não é especificado.

Conclusão

O dispositivo do motor com o ID de nó 0x65 envia o esforço de controle (provavelmente em intervalos de tempo regulares) usando um PDO .

Um controlador ou uma janela de monitor em tempo real em uma ferramenta de serviço lê e exibe outras quantidades / status medidos do mesmo dispositivo motor usando SDOs .

Comentários

• Eu trabalho com este tipo de CAN dados de ônibus em uma base diária, então isso é facilmente reconhecível. No entanto, a interpretação / significado preciso depende das informações sobre o sistema específico. Achei que essa pergunta merecia uma resposta abrangente.

Você não explicou exatamente o que sua listagem mostra, mas pode seja o ID da mensagem, seguido pelo número de bytes de dados entre colchetes, seguido pelos bytes de dados reais. Nada parece indicar explicitamente se os IDs são de 11 ou 29 bits. Talvez apenas usando 3 dígitos HEX para o ID isso a listagem indica IDs de 11 bits. Nesse caso, mostraria 8 dígitos HEX para IDs de 29 bits.

O que cada linha está, portanto (parece) mostrando a você é uma mensagem CAN. Não há mais nada para decodificar entender a mensagem CAN. Ela é mostrada explicitamente.

Por exemplo, a última linha diz que uma mensagem foi vista com ID 665h (1637 decimal), que essa mensagem tinha 8 bytes de dados e que o bytes de dados eram (em HEX) 40, 6C, 60, 0, 0, 0, 0 e 0. Os três primeiros seriam 64, 108 e 96 em decimal.

Quanto ao que significado dessa mensagem é para qualquer dispositivo que a originou ou se destina a agir sobre ela, isso é algo você deve consultar a documentação dos dispositivos específicos. Essa “uma camada acima do CAN.

Meu dispositivo tem um id de nó 101

Não há nenhum nó IDs no CAN, apenas IDs de mensagem. Se seus dispositivos usam o conceito de um ID de nó, isso é algo particular para uma camada de protocolo acima do CAN. O padrão CAN não pode ajudá-lo com isso. Você deve consultar a documentação específica do dispositivo, que pode se referir ao protocolo de nível superior que ele usa acima do CAN, possivelmente em um documento separado.

Comentários

• Não ' não é CAN básico, é CANopen, como visto no Manual.
• Elaborei em minha resposta .

O dispositivo usa um Protocolo CANopen . CANopen é um sistema de comunicação baseado em CAN. Inclui protocolos de camada superior e especificações de perfil.

É usado em automação. Existem vários analisadores de protocolo para descobrir toda a comunicação. O sistema de automação com CANopen é uma arquitetura mestre / escravo. Você encontrará algumas informações na wikipedia sobre CANopen, mas não são tão triviais quanto a própria mensagem do CAN orientado.

Comentários

• Sim, está correto. É CANopen.

Para decodificar a comunicação, você deve conhecer o motor CANopen Object Dictionary. Parece que os TPDOs e seu conteúdo depende de objetos de comunicação e mapeamento.

Você deve estudar os seguintes termos do CANopen para entender o protocolo. – Dicionário de objetos – Objetos de dados de processo (PDO) – Parâmetros de comunicação – Parâmetros de mapeamento