CIA 301 - CANopen (PT)

Machine Translated by Google
Especificação disponível ao público
CiA 301
Versão 4.2.0
Camada de aplicação CANopen e perfil de

comunicação
21 de fevereiro de 2011
© CAN em Automação (CiA) e. V.

Camada de aplicação CANopen e perfil de comunicação
HISTÓRIA
Encontro Mudanças
01-11-1994 Publicação da versão 1.0 como proposta padrão preliminar
22-09-1995 Publicação da versão 2.0 como rascunho da proposta padrão
1996-10-30 Publicação da versão 3.0 como rascunho da norma
16-06-1999 Publicação da versão 4.0 como padrão de rascunho
01-06-2000 Publicação da versão 4.0.1 como rascunho da norma
13-02-2002 Publicação da versão 4.0.2 como rascunho da norma
21-02-2011 Publicação da versão 4.2.0 como especificação pública

NOTA: Este documento foi convertido em “formato docx”.
A conversão causou pequenas diferenças de layout para o documento predecessor em “formato doc”. O conteúdo técnico palavra
por palavra é o mesmo.
Informações gerais sobre licenciamento e patentes
CAN in AUTOMATION (CiA) chama a atenção para a possibilidade de alguns dos elementos desta especificação CiA estarem sujeitos a
direitos de patente. A CiA não será responsável por identificar nenhum ou todos esses direitos de patente.
Como esta especificação é licenciada gratuitamente, não há garantia para esta especificação, na extensão permitida pela lei aplicável.
Exceto quando declarado de outra forma por escrito, o detentor dos direitos autorais e/ou outras partes fornecem esta especificação
"como está" sem garantia de qualquer tipo, expressa ou implícita, incluindo, mas não se limitando às garantias implícitas de
comercialização e adequação a uma finalidade específica . Todo o risco quanto à exatidão e integridade da especificação é com você.
Se esta especificação provar falhas, você assume o custo de todos os serviços, reparos ou correções necessários.
A CiA tem o compromisso de usar linguagem inclusiva em suas especificações e relatórios técnicos. Os documentos da CiA serão
atualizados com os termos inclusivos. Uma lista dos termos inclusivos e os termos que eles substituem é fornecida no documento
de estilo da casa da CiA; fornecido no site da CiA (https://can-cia.org/s/housestyle).
Marcas registradas
CANopen e CiA são marcas registradas da comunidade CAN in Automation. O uso é restrito para membros da CiA ou proprietários de
ID de fornecedor CANopen®. Termos mais detalhados para o uso estão disponíveis na CiA.
© CiA 2011
Todos os direitos reservados. A menos que especificado de outra forma, nenhuma parte desta publicação pode ser reproduzida
ou utilizada de qualquer forma ou por qualquer meio, eletrônico ou mecânico, incluindo fotocópia e microfilme, sem permissão por
escrito da CiA no endereço abaixo.
CAN em Automação e. V.
Jardim Kontumaz 3
DE - 90429 Nuremberga, Alemanha
Tel.: +49-911-928819-0
Fax: +49-911-928819-79
URL: www.can-cia.org
E-mail: sede@can-cia.org
2 © CiA 2011 – Todos os direitos reservados

CONTEÚDO
1 Alcance................................................. .................................................. .......................................... 12

2 Referências.............................................. .................................................. ................................... 13
2.1 Referências normativas .............................................. .................................................. .............. 13
2.2 Referências informativas ............................................. .................................................. ............ 13
3 Abreviaturas e definições .............................................. .................................................. ..... 14
3.1 Abreviaturas ....................................................... .................................................. ......................... 14
3.2 Definições ........................................................ .................................................. .............................. 14
4 Modelagem ........................................................ .................................................. ....................................... 16

4.1 Modelo do dispositivo de campo ............................................. .................................................. .................. 16
4.2 Modelo de referência de comunicação ............................................. .............................................. 17
4.2.1 Em geral ................................................. .................................................. .............................. 17
4.2.2 Camada de aplicação CANopen ............................................. .................................................. 17

4.2.2.1 Em geral ................................................. .................................................. ......... 17
4.2.2.2 Primitivas de serviço ......................................... .................................................. ... 17
4.2.2.3 Serviços da camada de aplicação .................................................. ....................................... 18
4.3 Modelo do dispositivo CANopen ............................................. .................................................. ........... 18
4.3.1 Em geral ................................................. .................................................. .............................. 18
4.4 Sequências do protocolo de comunicação ............................................. ......................................... 19

4.4.1 Em geral ................................................. .................................................. .............................. 19
4.4.2 Protocolo mestre/escravo ............................................. .................................................. ....... 19
4.4.3 Protocolo cliente/servidor ............................................. .................................................. ........ 20
4.4.4 Protocolo produtor/consumidor – modelo pull/push ..................................... ....................... 20
4.4.5 O dicionário de objetos .................................................. .................................................. .......... 21
4.5 Modelo do sistema de rede ............................................. .................................................. ............ 21
4.5.1 Perfil do dispositivo............................................. .................................................. ....................... 21
4.5.2 Perfil do aplicativo ............................................. .................................................. .............. 21
5 Camada física ........................................................ .................................................. .............................. 22

5.1 Referência ao modelo OSI ............................................. .................................................. ........... 22
5.2 Interface dependente do meio ............................................. .................................................. ... 22

5.3 Fixação do meio físico ............................................. .................................................. ... 22
5.4 Sinalização física ............................................. .................................................. ................... 22
6 Camada de enlace de dados ............................................. .................................................. ......................... 24
6.1 Geral ........................................................ .................................................. ......................... 24
6.2 Tipo de estrutura CAN ............................................. .................................................. ....................... 24

7 Camada de aplicativo.............................................. .................................................. .............................. 25
7.1 Tipos de dados e regras de codificação ............................................. .................................................. .. 25
7.1.1 Descrição geral dos tipos de dados e regras de codificação ............................................. ........... 25
7.1.2 Definições de tipo de dados ............................................. .................................................. ........... 25
7.1.3 Sequências de bits ......................................................... .................................................. .................. 26
7.1.3.1 Definição de sequências de bits ............................................. .......................................... 26
7.1.3.2 Sintaxe de transferência para sequências de bits ............................................. .............................. 26
7.1.4 Tipos de dados básicos ............................................. .................................................. .................. 27
7.1.4.1 Em geral ................................................. .................................................. .................. 27
7.1.4.2 NADA................................................. .................................................. ....................... 27
© CiA 2011 – Todos os direitos reservados 3


7.1.4.3 Boleano................................................. .................................................. .................. 27
7.1.4.4 Vazio................................................. .................................................. ....................... 27
7.1.4.5 Inteiro não assinado .............................................. .................................................. ... 27
7.1.4.6 Número inteiro assinado................................................ .................................................. ........ 28
7.1.4.7 Números de ponto flutuante .............................................. ............................................. 28
7.1.5 Tipos de dados compostos ............................................. .................................................. ........ 29
7.1.6 Tipos de dados estendidos............................................. .................................................. ........... 30
7.1.6.1 Em geral ................................................. .................................................. .................. 30
7.1.6.2 Cadeia de Octetos ............................................. .................................................. .............. 30
7.1.6.3 Cadeia Visível................................................ .................................................. .......... 30
7.1.6.4 Cadeia Unicode ........................................................ .................................................. ....... 30
7.1.6.5 Hora do dia............................................... .................................................. .............. 30
7.1.6.6 Diferença de tempo................................................ .................................................. ...... 30
7.1.6.7 Domínio................................................. .................................................. .................. 31
7.2 Objetos de comunicação .............................................. .................................................. .......... 31

7.2.1 Em geral ................................................. .................................................. .............................. 31
7.2.2 Objeto de dados de processo (PDO)......................................... .................................................. .... 31

7.2.2.1 Em geral ................................................. .................................................. .................. 31
7.2.2.2 Modos de transmissão................................................ ......................................... 32
7.2.2.3 Modos de disparo ......................................... .................................................. ... 33
7.2.2.4 Serviços PDO ............................................. .................................................. ............ 33
7.2.2.4.1 Em geral................................................. .................................................. .............. 33
7.2.2.4.2 Serviço de gravação PDO ............................................. .................................................. ... 33
7.2.2.4.3 Serviço de leitura do PDO.............................. .................................................. .... 34
7.2.2.5 Protocolo PDO ............................................. .................................................. .............. 34

7.2.2.5.1 Gravação do protocolo PDO ............................................. .............................................. 34
7.2.2.5.2 Leitura do protocolo PDO .................................................. ............................................. 35

7.2.3 Multiplex PDO (MPDO) ............................................. .................................................. ..... 35
7.2.3.1 Geral ............................................. .................................................. ................... 35
7.2.3.2 Modos de endereço MPDO ............................................. ......................................... 35
7.2.3.2.1 Modo de endereço de destino (DAM) ............................................. .......................... 35

7.2.3.2.2 Modo de endereço de origem (SAM).................................... ....................................... 35
7.2.3.3 Serviço MPDO............................................. .................................................. ........... 36
7.2.3.3.1 Em geral................................................. .................................................. .............. 36

7.2.3.3.2 Serviço de gravação MPDO ............................................. .................................................. 36
7.2.3.4 Protocolo MPDO ............................................. .................................................. ......... 36

7.2.3.4.1 Gravação de protocolo MPDO ............................................. ......................................... 36
7.2.4 Objeto de dados de serviço (SDO)......................................... .................................................. .. 37
7.2.4.1 Em geral ................................................. .................................................. .................. 37
7.2.4.2 Serviços SDO ............................................. .................................................. .............. 38
7.2.4.2.1 Em geral................................................. .................................................. .............. 38
7.2.4.2.2 Download de SDO de Serviço ............................................. ............................................. 39
7.2.4.2.3 Início do download do SDO do serviço ........................................ ................................... 39
7.2.4.2.4 Segmento de download de SDO de serviço ........................................ .............................. 40

7.2.4.2.5 Carregamento de SDO de serviço ............................................. .................................................. 41
7.2.4.2.6 Início do upload do SDO do serviço ........................................ ....................................... 41
7.2.4.2.7 Segmento de upload de SDO de serviço ....................... .................................... 42

7.2.4.2.8 Download do bloco SDO do serviço ........................................ ....................................... 43
7.2.4.2.9 Início do download do bloco SDO do serviço ....................... .............................. 43
7.2.4.2.10 Sub-bloco de download do bloco SDO de serviço ...................................... ....................... 44
7.2.4.2.11 Fim do download do bloco SDO do serviço ........................................ .............................. 44
7.2.4.2.12 Carregamento de bloco SDO de serviço ........................................ ....................................... 45
7.2.4.2.13 Inicialização do upload do bloco SDO do serviço................................. .............................. 45
7.2.4.2.14 Sub-bloco de upload do bloco SDO de serviço................................... .......................... 46
7.2.4.2.15 Fim do upload do bloco SDO do serviço ......................... ................................... 47

7.2.4.2.16 Serviço SDO abortar transferência ........................................ ....................................... 47
7.2.4.3 Protocolos SDO............................................. .................................................. ........... 48

7.2.4.3.1 Em geral................................................. .................................................. .............. 48
7.2.4.3.2 Download do protocolo SDO ............................................. ....................................... 48
7.2.4.3.3 Início do download do protocolo SDO ............................................. ....................... 49
7.2.4.3.4 Segmento de download do protocolo SDO ............................................. ......................... 50

7.2.4.3.5 Carregamento de protocolo SDO ............................................. .......................................... 50
7.2.4.3.6 Início do upload do protocolo SDO ............................................. ......................... 51
7.2.4.3.7 Segmento de upload do protocolo SDO ............................................. .............................. 52
7.2.4.3.8 Download do bloco de protocolo SDO............................................. .............................. 53
7.2.4.3.9 Início do download do bloco SDO do protocolo ............................................. ................... 53
7.2.4.3.10 Sub-bloco de download do bloco SDO do protocolo ....................... ....................... 55
7.2.4.3.11 Fim do download do bloco do protocolo SDO ........................................ ......................... 56
7.2.4.3.12 Carregamento de bloco de protocolo SDO ........................................ ....................................... 57
7.2.4.3.13 Inicialização do upload do bloco SDO do protocolo ........................................ ......................... 58
7.2.4.3.14 Sub-bloco de upload de bloco de protocolo SDO ..................................... .............................. 59
7.2.4.3.15 Fim do upload do bloco SDO do protocolo ....................... ......................... 59
7.2.4.3.16 Algoritmo de cálculo CRC para verificar a transferência do bloco SDO ..................................... 60
7.2.4.3.17 Protocolo SDO abortar transferência ........................................ ....................................... 61
7.2.5 Objeto de sincronização (SYNC) ............................................. .......................................... 62

7.2.5.1 Geral .............................................. .................................................. ................... 62
7.2.5.2 Serviços de SINCRONIZAÇÃO............................................. .................................................. ......... 62
7.2.5.2.1 Em geral................................................. .................................................. .............. 62
7.2.5.2.2 Gravação de SINCRONIZAÇÃO de Serviço ............................................. .................................................. 62
7.2.5.3 Protocolo SYNC ............................................. .................................................. ......... 63

7.2.5.3.1 Gravação de SINCRONIZAÇÃO de protocolo ............................................. ............................................. 63
7.2.6 Objeto de carimbo de hora (TIME) ........................................ .................................................. ..... 63

7.2.6.1 Em geral ................................................. .................................................. ......... 63
7.2.6.2 Serviços TIME .................................................. .................................................. ........ 63
7.2.6.2.1 Em geral................................................. .................................................. .............. 63
7.2.6.2.2 Gravação de TEMPO de serviço ............................................. .................................................. .. 63
7.2.6.3 protocolo TIME .................................................. .................................................. ......... 64

7.2.6.3.1 Gravação do protocolo TIME ................................................. ............................................. 64
7.2.7 Objeto de emergência (EMCY) ............................................. .................................................. ... 64

7.2.7.1 Uso de objetos de emergência ......................................... .......................................... 64
7.2.7.2 Serviços de objetos de emergência ............................................. ....................................... 67
7.2.7.2.1 Em geral................................................. .................................................. .............. 67
7.2.7.2.2 Serviço de gravação EMCY ............................................. .................................................. 67
7.2.7.3 Protocolo de objeto de emergência ......................................... ....................................... 67


7.2.7.3.1 Gravação do protocolo EMCY ............................................. .......................................... 67
7.2.8 Gerenciamento de rede ............................................. .................................................. ...... 68

7.2.8.1 Em geral ................................................. .................................................. ......... 68
7.2.8.2 Serviços NMT ............................................. .................................................. ............ 68
7.2.8.2.1 Serviços de controle de nós ............................................. ......................................... 68
7.2.8.2.2 Serviços de controle de erros ......................................... .......................................... 70
7.2.8.2.3 Serviço de inicialização........................................ .................................................. ......... 72

7.2.8.3 Protocolos NMT ............................................. .................................................. ........... 72
7.2.8.3.1 Protocolos de controle de nós ............................................. ............................................. 72
7.2.8.3.2 Protocolos de controle de erros ............................................. ....................................... 74
7.2.8.3.3 Inicialização do protocolo ............................................. .................................................. .. 77
7.3 Inicialização da rede e inicialização do sistema ............................................. ....................................... 77
7.3.1 Inicialização simplificada do NMT .................................................. .................................................. .... 77
7.3.2 Máquina de estado NMT ............................................. .................................................. ............ 77
7.3.2.1 Visão geral ................................................. .................................................. ............... 77
7.3.2.2 Estados NMT ............................................. .................................................. ................ 78
7.3.2.2.1 Inicialização do estado NMT ............................................. ............................................. 78
7.3.2.2.2 Estado NMT Pré-operacional ........................................ .......................................... 79

7.3.2.2.3 Estado NMT Operacional ............................................. ............................................. 79
7.3.2.2.4 Estado NMT Parado ............................................. .................................................. 79
7.3.2.2.5 Estados NMT e relação de objeto de comunicação ......................... ........... 80
7.3.2.3 Transições de estado NMT ........................................ .................................................. . 80
7.3.3 Conjunto de conexão predefinido genérico ........................................ ....................................... 80

7.3.4 Conjunto de conexão predefinido específico ......................................... ....................................... 81
7.3.5 CAN-IDs restritos ............................................. .................................................. .......... 81
7.4 Dicionário de objetos ............................................. .................................................. ....................... 82

7.4.1 Estrutura geral................................................ .................................................. ............ 82
7.4.2 Uso de índice e subíndice ........................................ .................................................. ... 83

7.4.3 Uso do código objeto ............................................. .................................................. .............. 84
7.4.4 Uso do tipo de dados ............................................. .................................................. .................. 84

7.4.5 Uso de acesso ............................................. .................................................. ................... 85
7.4.6 Uso de categoria e categoria de entrada ............................................. ....................................... 85
7.4.7 Uso de entrada de tipo de dados ............................................. .................................................. ......... 85
7.4.7.1 Em geral ................................................. .................................................. .................. 85
7.4.7.2 Organização de entradas de dicionário de objetos estruturados .................................. .... 88
7.4.8 Especificação de tipos de dados complexos pré-definidos ............................................. ................... 88
7.4.8.1 Especificação do registro de parâmetros de comunicação PDO................................................ .... 88
7.4.8.2 Especificação de registro de parâmetro de mapeamento PDO ............................................. .............. 88
7.4.8.3 Especificação de registro de parâmetro SDO ............................................. .......................... 89
7.4.8.4 Especificação do registro de identidade ............................................. ....................................... 89
7.4.8.5 Especificação do registro de depuração do SO ............................................. ....................................... 89
7.4.8.6 Especificação de registro de comando do SO ............................................. .............................. 90
7.5 Especificação do perfil de comunicação ............................................. .......................................... 90
7.5.1 Especificação da descrição do objeto e da entrada ............................................. .......................... 90
7.5.2 Especificação detalhada de objetos específicos do perfil de comunicação ......................... 91
7.5.2.1 Objeto 1000h: Tipo de dispositivo ............................................. .......................................... 91
7.5.2.2 Objeto 1001h: Registro de erros............................................. ....................................... 92

7.5.2.3 Objeto 1002h: Cadastro de status do fabricante ............................................. .................. 93

7.5.2.4 Objeto 1003h: Campo de erro pré-definido ............................................. ......................... 93
7.5.2.5 Objeto 1005h: mensagem COB-ID SYNC........................................... ......................... 95
7.5.2.6 Objeto 1006h: Período do ciclo de comunicação................................................. ......... 96
7.5.2.7 Objeto 1007h: Comprimento da janela síncrona ............................................. ......... 97
7.5.2.8 Objeto 1008h: Nome do dispositivo do fabricante ............................................. ................... 97
7.5.2.9 Objeto 1009h: Versão de hardware do fabricante ............................................. ............ 98
7.5.2.10 Objeto 100Ah: Versão do software do fabricante............................................. .............. 98
7.5.2.11 Objeto 100Ch: Tempo de guarda ............................................. .......................................... 98
7.5.2.12 Objeto 100Dh: Fator de tempo de vida................................................. ....................................... 99
7.5.2.13 Objeto 1010h: Armazenar parâmetros ............................................. .............................. 100
7.5.2.14 Objeto 1011h: Restaurar parâmetros padrão ............................................. ............... 102
7.5.2.15 Objeto 1012h: objeto de carimbo de data/hora COB-ID ........................................ ....................... 105
7.5.2.16 Objeto 1013h: carimbo de data/hora de alta resolução ............................................. .................... 106
7.5.2.17 Objeto 1014h: COB-ID EMCY........................................... ....................................... 106
7.5.2.18 Objeto 1015h: Tempo de inibição EMCY ............................................. .............................. 107
7.5.2.19 Objeto 1016h: Tempo de pulsação do consumidor ............................................. ................... 107
7.5.2.20 Objeto 1017h: Tempo de pulsação do produtor ............................................. ....................... 109
7.5.2.21 Objeto 1018h: Objeto de identidade............................................. ....................................... 109
7.5.2.22 Objeto 1019h: Valor de estouro do contador síncrono........................................... ...111
7.5.2.23 Objeto 1020h: Verificar configuração ............................................. .......................... 112
7.5.2.24 Objeto 1021h: Armazenar EDS............................................. .......................................... 114
7.5.2.25 Objeto 1022h: Formato de armazenamento ............................................. ....................................... 114
7.5.2.26 Objeto 1023h: comando do SO ............................................. ....................................... 116
7.5.2.27 Objeto 1024h: modo de comando do SO ............................................. .......................... 117
7.5.2.28 Objeto 1025h: interface do depurador do sistema operacional ............................................. ....................... 118
7.5.2.29 Objeto 1026h: prompt do SO............................................. .......................................... 119
7.5.2.30 Objeto 1027h: Lista de módulos............................................. .......................................... 120
7.5.2.31 Objeto 1028h: Objeto consumidor de emergência ............................................. .............. 122
7.5.2.32 Objeto 1029h: Objeto de comportamento de erro ............................................. .......................... 123
7.5.2.33 Objeto 1200h a 127Fh: parâmetro do servidor SDO........................................... ........... 125
7.5.2.34 Objeto 1280h a 12FFh: parâmetro do cliente SDO ............................................. ............127
7.5.2.35 Objeto 1400h a 15FFh: Parâmetro de comunicação RPDO...................................129
7.5.2.36 Objeto 1600h a 17FFh: Parâmetro de mapeamento RPDO ........................................... ....134
7.5.2.37 Objeto 1800h a 19FFh: Parâmetro de comunicação TPDO ...................................136
7.5.2.38 Objeto 1A00h a 1BFFh: parâmetro de mapeamento TPDO........................................... ....141
7.5.2.39 Objeto 1FA0h a 1FCFh: Lista de varredura de objetos ............................................. ................144
7.5.2.40 Objeto 1FD0h a 1FFFh: Lista de despacho de objetos ............................................. ........... 145
Anexo A (informativo) ............................................. .................................................. ......................... 148
Recomendações de Implementação .................................................. .................................................. 148

COBs inválidos................................................. .................................................. .............................. 148
Tempos de espera .................................................. .................................................. ....................................... 148
Tipo de transmissão PDO 0, 254, 255 ............................................. .................................................. 148
Visão geral de objetos de dicionário de objetos para comunicação .................................. ....................... 148

Tabelas
Tabela 1: Configurações de temporização de bits recomendadas.................................. .................................................. 22 Tabela 2:
Comprimentos de ônibus estimados ............................................. .................................................. ................ 23 Tabela 3: Exemplo de
cálculo do número PDO .......................... .................................................. ............... 32

Tabela 4: Gravação de PDO de serviço ............................................. .................................................. ....................... 33
Tabela 5: Leitura do PDO de serviço .................................................. .................................................. ....................... 34
Tabela 6: Gravação de serviço MPDO ............................................. .................................................. ................... 36
Tabela 7: Download de SDO de serviço .................................................. .................................................. .............. 39
Tabela 8: Início do download do SDO de serviço ............................................. .................................................. ... 40
Tabela 9: Segmento de download de SDO de serviço ............................................. .................................................. 40 Tabela 10:
Carregamento de SDO de serviço ............................................. .................................................. ......... 41 Tabela 11: Início de upload de
SDO de serviço ........................ .................................................. ......................... 42 Tabela 12: Segmento de upload de SDO de
serviço......... .................................................. .......................... 42

Tabela 13: Download do bloco SDO de serviço ............................................. .................................................. ... 43
Tabela 14: Início do download do bloco SDO de serviço ............................................. .......................................... 43
Tabela 15: Sub-bloco de download do bloco SDO de serviço ........................................ ....................................... 44
Tabela 16: Fim do download do bloco SDO do serviço ............................................. ............................................. 45
Tabela 17: Carregamento do bloco SDO de serviço ............................................. .................................................. ........ 45 Tabela 18:
Inicialização do upload do bloco SDO do serviço ....................... .................................................. ....... 46 Tabela 19: Sub-bloco de upload
do bloco SDO de serviço ....................... .................................................. ... 46 Tabela 20: Fim do upload do bloco SDO do
serviço ........................ .................................................. ...... 47

Tabela 21: Transferência de interrupção do serviço SDO ............................................. .................................................. ...... 47
Tabela 22: Códigos de interrupção SDO ............................................. .................................................. ....................... 61
Tabela 23: Gravação de SINCRONIZAÇÃO de serviço ............................................. .................................................. ................... 63
Tabela 24: Gravação de TIME de serviço .................................................. .................................................. ................... 64
Tabela 25: Classes de código de erro de emergência ............................................. .................................................. 64 Tabela 26: Códigos
de erro de emergência............................................. .................................................. .............. 65

Tabela 27: Gravação do serviço EMCY ............................................. .................................................. ......... 67
Tabela 28: Nó remoto de início de serviço............................................. .................................................. ......... 68
Tabela 29: Nó remoto de parada de serviço ............................................. .................................................. ......... 69 Tabela 30: Entrada de
serviço pré-operacional ........................ .................................................. ............... 69

Tabela 31: Nó de redefinição de serviço ............................................. .................................................. ................... 69
Tabela 32: Comunicação de redefinição de serviço......................................... .................................................. ... 70
Tabela 33: Evento de proteção do nó de serviço ............................................. .................................................. .... 71 Tabela 34: Evento
de proteção da vida útil ........................................ .................................................. .............. 71

Tabela 35: Evento de pulsação do serviço ............................................. .................................................. ........... 72
Tabela 36: Evento de inicialização do serviço ............................................. .................................................. ................ 72 Tabela 37:
Estados NMT e objetos de comunicação ........................ .................................................. ..... 80 Tabela 38: Objetos de broadcast do
conjunto de conexão predefinido genérico ....................... .................. 81 Tabela 39: Objetos ponto a ponto do conjunto de conexões
predefinido genérico............... .................................. 81 Tabela 40: CAN-IDs

restritos............ .................................................. .................................................. 82
Tabela 41: Estrutura do dicionário de objetos ............................................. .................................................. ....... 82 Tabela 42: Definições
de objetos do Dicionário de Objetos................................... .................................................. ... 84 Tabela 43: Atributos de acesso para
objetos de dados ........................................ .................................................. .. 85 Tabela 44: Tipos de dados do dicionário de
objetos........................................ .................................................. ......... 85 Tabela 45: exemplo de tipo de dado
complexo ....................... .................................................. ................ 87

Tabela 46: Registro de parâmetros de comunicação PDO ........................................ ......................... 88 Tabela 47: Registro de parâmetros
de mapeamento PDO.... .................................................. ....................................... 88 Tabela 48: Registro de parâmetro
SDO..... .................................................. .................................................. .. 89 Tabela 49: Registro de
identidade................................................ .................................................. ......................... 89 Tabela 50: Registro de depuração do
SO ............ .................................................. .................................................. .. 89

Tabela 51: Registro de comando do SO .................................................. .................................................. ................ 90
Tabela 52: Formato de uma descrição de objeto ............................................. .................................................. .. 90 Tabela 53: Formato de
descrição do valor do objeto ........................................ .................................................. ... 91 Tabela 54: Estrutura do registro de
erros.............................. .................................................. ......... 92 Tabela 55: Descrição do SYNC COB-
ID .............................. .................................................. ............... 95

Tabela 56: Estrutura de acesso de leitura ............................................. .................................................. .........100
Tabela 57: Estrutura do acesso de leitura de restauração............................................. ....................................... 103
Tabela 58: Descrição do TIME COB-ID........................................ .................................................. .....105 Tabela 59: Descrição do EMCY
COB-ID ................................... .................................................. .........106

Tabela 60: Valores para formatos de armazenamento EDS ............................................. .................................................. ..115
Tabela 61: Valores do modo de comando do SO............................................. .................................................. .....117
Tabela 62: Descrição do EMCY COB-ID ........................................ .................................................. ...122

Tabela 63: Valores da classe de erro......................................... .................................................. ................... 124
Tabela 64: Descrição do servidor SDO COB-ID................................................ ............................................. 125 Tabela 65: Descrição do
cliente SDO COB-ID ............................................. .......................................... 128 Tabela 66: Descrição de RPDO COB-
ID .............................................. ......................................... 130 Tabela 67: Conjunto de conexão predefinido genérico para
RPDO ......................... .......................130 Tabela 68: Descrição do tipo de transmissão RPDO........... .................................................. .........131
Tabela 69: Valores de mapeamento de RPDO........................... .................................................. .......................134 Tabela 70: Descrição
do TPDO COB-ID ............ .................................................. ..............................137 Tabela 71: Conjunto de conexões predefinidos genéricos
para TPDO...... ........... .................................................. ..137 Tabela 72: Descrição do tipo de transmissão
TPDO ........................................ ....................................... 138 Tabela 73: Valores de mapeamento
TPDO ... .................................................. .................................................. ..141 Tabela 74: Objetos
padrão ............................................. .................................................. ....................... 148

Figuras
Figura 1: Modelo do dispositivo de campo .................................................. .................................................. ..........

16 Figura 2: Dispositivo de campo mínimo ....................... .................................................. ......................... 17
Figura 3: Modelo de referência de comunicação...... .................................................. ......................... 17 Figura
4: Serviços da camada de aplicação ....... .................................................. ............................................. 18 Figura
5: Modelo do dispositivo CANopen ............................................. .................................................. ......... 19 Figura
6: Protocolo de comunicação mestre/escravo não confirmado ....................... ......................... 19 Figura 7:
Protocolo de comunicação mestre/escravo confirmado........ .................................................. ......... 20 Figura 8:
Comunicação cliente/servidor protocolo................................................. .................................... 20 Figura 9:
Modelo de empurrar ........ .................................................. .................................................. ......... 20 Figura 10:
Modelo de tração .............................. .................................................. .............................................. 21 Figura
11: Modelo de referência da camada física ............................................. .................................................. 22
Figura 12: Sintaxe de transferência para sequências de bits ............................................. ..............................................
27 Figura 13 : Sintaxe de transferência para o tipo de dados UNSIGNEDn........................................ ..............................
28 Figura 14: Sintaxe de transferência para o tipo de dados INTEGERn......... .................................................. ..........
28 Figura 15: Sintaxe de transferência do tipo de dados REAL32...................... . .................................................. ..........
29 Figura 16: Transmissão síncrona e acionada por evento .............................. ......................................... 32
Figura 17: Gravação do protocolo PDO . .................................................. .................................................. ..........
34 Figura 18: Leitura do protocolo PDO ....................... .................................................. ......................... 35
Figura 19: Gravação do protocolo MPDO .............. .................................................. .........................................
37 Figura 20: Protocolo SDO download................................................. .................................................. ..... 48
Figura 21: Início do download do protocolo SDO ....................... .................................................. ..... 49 Figura
22: Download do segmento SDO do protocolo..................................... ....................... ......................... 50 Figura
23: Upload do protocolo SDO ............ .................................................. ............................................. 50 Figura
24: Início do carregamento do protocolo SDO ............................................. .................................................. 51
Figura 25: Upload do segmento SDO do protocolo ........................................ .................................................. ..
52 Figura 26: Download do bloco SDO do protocolo ........................................ .................................................. ....
53 Figura 27: Início do download do bloco SDO do protocolo..................................... .............................................
54 Figura 28: Sub-bloco de download do bloco SDO do protocolo .................................. ......................... 55
Figura 29: Fim do download do bloco SDO do protocolo ....... .................................................. ..............................
56 Figura 30: Carregamento de bloco de protocolo SDO ............................................. .................................................. ...
57 Figura 31: Inicialização do upload do bloco SDO do protocolo ....................... ......................................... 58
Figura 32: Sub-bloco de upload do bloco SDO do protocolo ........................................ .........................................
59 Figura 33: Upload do bloco SDO do protocolo fim................................................. .........................................
60 Figura 34: Aborto do protocolo SDO transferência .................................................... ........................................
61 Figura 35: Gravação do protocolo SYNC ............................................. .................................................. ..............
63 Figura 36: Gravação do protocolo TIME................................. .................................................. .........................
64 Figura 37: Transição do estado de emergência diagrama ........................................................ ...................................
67 Figura 38: Gravação do protocolo EMCY....... .................................................. .................................................. ..
68 Figura 39: Nó remoto de início de protocolo ........................................ .................................................. .........
72 Figura 40: Nó remoto de parada de protocolo ....................... .................................................. ......... 73 Figura
41: Protocolo entrar pré-operacional ........................ .................................................. .......... 73 Figura 42: Nó de
reinicialização do protocolo ....................... .................................................. ......................... 73 Figura 43:
Comunicação de reset de protocolo ..... .................................................. ....................................... 74 Figura 44:
Proteção do nó do protocolo.... ......................... .................................................. ......................... 75 Figura 45:
Pulsação do protocolo........... .................................................. .................................................. .. 76
Figura 46: Inicialização do protocolo................................................. .................................................. ......................... 77 Figura 47:
Inicialização NMT simples .......... .................................................. ......................................... 77 Figura 48: Diagrama de estado NMT de
um Dispositivo CANopen .................................................. ......................... 78 Figura 49: Estrutura do estado NMT
Inicialização ............ .................................................. ......... 79 Figura 50: Esquema de alocação de CAN-ID para o conjunto de conexão
predefinido genérico .............. ......... 80 Figura 51: Sub-índice de estrutura FFh ........................ .................................................. ..............................
88 Figura 52: Estrutura do parâmetro tipo de dispositivo .......... .................................................. .......... 92 Figura 53: Estrutura do campo
de erro pré-definido.. .................................................. .............................. 94 Figura 54: Estrutura do SYNC COB-
ID .......... .................................................. ......................... 95 Figura 55: Assinatura de acesso de gravação de
armazenamento... .................................................. .........................100 Figura 56: Estrutura de acesso de leitura de
armazenamento.... .................................................. .........................................100 Figura 57: Restaurar assinatura de acesso de gravação
padrão... .................................................. ..............................102 Figura 58: Procedimento de
restauração .................. .................................................. .............................................103 Figura 59: Restaurar o acesso de leitura padrão
estrutura................................................. ..............................103 Figura 60: Estrutura do TIME COB-
ID ......... .................................................. .... ..............................105 Figura 61: Estrutura do Identificador
EMCY...... .................................................. .........................106 Figura 62: Estrutura do tempo de pulsação do
consumidor........ .................................................. .........108 Figura 63: Estrutura do número de
revisão ....................... .................................................. ......................... 110 Figura 64: Estrutura do EMCY COB-
ID ............... .................................................. ..............................122 Figura 65: Estrutura do servidor SDO COB-
ID........ .................................................. ..............................125 Figura 66: Estrutura do cliente SDO COB-
ID ......... .................................................. ..............................127 Figura 67: Estrutura do RPDO COB-
ID .......... .................................................. .................................... 130 Figura 68: Barramento s sincronização e
acionamento ........................................................ .........................................131 Figura 69: Estrutura do mapeamento
RPDO .... .................................................. .........................................134 Figura 70: Princípio do mapeamento
RPDO. .................................................. .............................................135 Figura 71: Estrutura do TPDO COB-
ID................................................ .................................................. ..137 Figura 72: Sincronização e amostragem do
barramento ........................................ ............................................. 139 Figura 73: Estrutura de mapeamento
TPDO ............................................. .............................................. 142 Figura 74: Princípio do mapeamento
TPDO .................................................. .................................................. ..143 Figura 75: Entrada de objetos da lista do scanner de
objetos....................... .................................................. .........144 Figura 76: Entrada de objeto na lista de despacho de
objetos ....................... .................................................. .......... 145

1 Escopo
Esta especificação especifica a camada de aplicação CANopen. Isso inclui os tipos de dados, regras de
codificação e objetos de dicionário de objetos, bem como os serviços e protocolos de comunicação CANopen.
Além disso, esta especificação especifica os serviços e protocolos de gerenciamento de rede CANopen.
Esta especificação especifica o perfil de comunicação CANopen, por exemplo, a camada física, o conjunto de
conexão do identificador de objeto de comunicação pré-definido e o conteúdo dos objetos de comunicação de
Emergência, Carimbo de Tempo e Sincronização.

2 Referências
2.1 Referências normativas
/EN61131-3/ EN 61131-3, Controladores programáveis – Parte 3: Linguagens de programação
/ISO7498-1/ ISO 7498-1, Tecnologia da Informação – Interconexão de Sistemas Abertos – Básico

Modelo de referência: o modelo básico
/ISO8859/ ISO 8859, Tecnologia da informação – conjuntos de caracteres gráficos codificados de byte único de 8 bits
/ISO11898-1/ ISO 11898-1, Veículos rodoviários – Rede de área do controlador (CAN) – Parte 1: Camada de enlace de dados e
sinalização física
/ISO11898-2/ ISO 11898-2, Veículos rodoviários – Rede de área do controlador (CAN) – Parte 2: Unidade de acesso médio de alta
velocidade
/ISO11898-3/ ISO 11898-3, Veículos rodoviários – Rede de área do controlador (CAN) – Parte 3: Interface de baixa velocidade,
tolerante a falhas e dependente do meio
/ISO10646/ ISO 10646, Tecnologia da informação – Conjunto universal de caracteres codificados com vários octetos
(UCS)
2.2 Referências informativas
/IEEE754/ IEEE 754, Padrão para aritmética binária de ponto flutuante

/IEC62390/ IEC TR 62390, Dispositivo de automação comum – Diretriz de perfil

3 Abreviaturas e definições
3.1 Abreviações
ARQ Solicitação de repetição automática
POSSO Rede de área do controlador
CAN-ID Identificador CAN
COB Objeto de comunicação
COB-ID identificador COB
CRC Verificação de redundância Cíclica
CSDO Cliente-SDO
BARRAGEM Modo de endereço de destino
FSA Autômato de estado finito
LLC Controle de link lógico
LSB Bit/byte menos significativo
MAC Controle de acesso médio
MDI Interface dependente do meio
MPDO Multiplexado-PDO
MSB Bit/byte mais significativo
NMT Gerenciamento de rede
ID do nó Identificador de nó
TAMBÉM
Interconexão de sistemas abertos
DOP Processar objeto de dados
PLS Sinalização da camada física
PMA Fixação do meio físico
RPDO Receber-PDO
RTR Solicitação de transmissão remota
ELE MESMO Modo de endereço de origem
SDO Objeto de dados de serviço
SSDO Servidor-SDO
SINCRONIZAR Objeto de sincronização
TPDO Transmitir-PDO
3.2 Definições
Estrutura de base CAN
mensagem que contém até 8 bytes e é identificada por 11 bits conforme definido em /ISO11898-1/
CAN quadro estendido
mensagem que contém até 8 bytes e é identificada por 29 bits conforme definido em /ISO11898-1/

CAN-ID
identificador para dados CAN e frames remotos conforme definido em /ISO11898-1/
COB-ID
identificador que contém o CAN-ID e bits de controle adicionais
Entidade
coisa particular, como uma pessoa, lugar, processo, conceito, associação ou evento
FSA
modelo de computação que consiste em um conjunto de estados, um estado inicial, um alfabeto de entrada e uma função de
transição que mapeia símbolos de entrada e estados atuais para um próximo estado; a computação começa no estado inicial
com uma string de entrada; muda para novos estados dependendo da função de transição
Dispositivo de campo
1. entidade física independente em rede de um sistema de automação capaz de realizar

funções especificadas em um contexto particular e delimitadas por suas interfaces
2. entidade que executa funções de controle, atuação e/ou detecção e interfaces para outros
entidades dentro de um sistema de automação
Dispositivo lógico
representação de um dispositivo de campo em termos de seus objetos e comportamento de acordo com um modelo de dispositivo
de campo que descreve os dados e o comportamento do dispositivo como visualizados através de uma rede
ID do nó
identificador exclusivo de toda a rede para cada dispositivo CANopen
Objeto
entidade com um limite bem definido e identidade que encapsula estado e comportamento
Dispositivo virtual
entidade de software capaz de realizar um elemento funcional de um dispositivo de campo

4 Modelagem
4.1 Modelo do dispositivo de campo
O dispositivo de campo mostrado na Figura 1 deve possuir pelo menos um dispositivo CANopen. Cada dispositivo CANopen dentro do
dispositivo de campo deve ter pelo menos uma interface de rede associada compreendendo um protocolo de camada de enlace de dados
(consulte a cláusula 6) e uma definição de camada física (consulte a cláusula 5), um ID de nó e pelo menos um FSA de comunicação. O
primeiro FSA de comunicação contém a máquina de estado escravo NMT (consulte a subcláusula 7.3.2). FSAs de comunicação adicionais
contêm uma máquina de estado de emergência (ver subcláusula 7.2.7) e outras. A definição de FSAs de comunicação adicionais não se
enquadra no escopo desta especificação. A definição é feita nos chamados frameworks. Um dispositivo CANopen deve ter no mínimo
um e até oito dispositivos lógicos e não deve ser distribuído para vários dispositivos de campo. Cada dispositivo lógico pode conter vários
dispositivos virtuais e, opcionalmente, um dispositivo lógico FSA. Um dispositivo lógico não deve ser distribuído para vários dispositivos
CANopen. A definição de um dispositivo lógico não se enquadra no escopo desta especificação. A definição é feita nos chamados perfis
de dispositivos (ver subcláusula 4.5.1). Um dispositivo virtual contém um FSA de dispositivo virtual e não é distribuído para vários
dispositivos lógicos.
A definição de um dispositivo virtual não se enquadra no escopo desta especificação. A definição é feita nos chamados perfis de aplicação
(ver subcláusula 4.5.2). O dispositivo de campo mínimo é mostrado na Figura 2.
Figura 1: Modelo do dispositivo de campo

Figura 2: Dispositivo de campo mínimo
4.2 Modelo de referência de comunicação
4.2.1 Geral
Figura 3: Modelo de referência de comunicação
O conceito de comunicação está em conformidade com o modelo de referência ISO-OSI (lado esquerdo da Figura 3;
consulte /ISO7498-1/).
4.2.2 Camada de aplicação CANopen
4.2.2.1 Geral
A camada de aplicação descreve um conceito para configurar e comunicar dados em tempo real, bem como os mecanismos
de sincronização entre dispositivos CANopen. A funcionalidade que a camada de aplicativo oferece a um aplicativo é
dividida logicamente em diferentes objetos de serviço na camada de aplicativo. Um objeto de serviço oferece uma
funcionalidade específica e todos os serviços relacionados. Esses serviços são descritos na especificação de serviço desse
objeto de serviço.
Um aplicativo interage chamando serviços de um objeto de serviço na camada de aplicativo. Para realizar esses serviços,
esse objeto troca dados por meio da camada de enlace de dados com (um) objeto(s) de serviço de mesmo nível por meio
de um protocolo. Esse protocolo é descrito na especificação de protocolo desse objeto de serviço.
4.2.2.2 Primitivas de serviço
As primitivas de serviço são os meios pelos quais o aplicativo e a camada de aplicativo interagem. Existem quatro primitivas
diferentes:
• Uma solicitação é emitida pelo aplicativo para a camada de aplicativo para solicitar um serviço.
• Uma indicação é emitida pela camada do aplicativo ao aplicativo para relatar um evento interno
detectado pela camada de aplicação ou indicar que um serviço é solicitado.
• Uma resposta é emitida pelo aplicativo para a camada de aplicativo para responder a um recebimento anterior
indicação.

• Uma confirmação é emitida pela camada do aplicativo para o aplicativo para relatar o resultado de uma
solicitação previamente emitida.
4.2.2.3 Serviços da camada de aplicação
Figura 4: Serviços da camada de aplicativo
Um serviço de camada de aplicativo define as primitivas que são trocadas entre a camada de aplicativo e os aplicativos
cooperantes para um serviço específico de um objeto de serviço. Os serviços da camada de aplicação suportados pelo
CANopen são mostrados na Figura 4.
• Um serviço local envolve apenas o objeto de serviço local. O aplicativo emite uma solicitação para seu objeto de serviço local
que executa o serviço solicitado sem se comunicar com (um) objeto(s) de serviço de mesmo nível.
• Um serviço iniciado pelo provedor envolve apenas o objeto de serviço local. O objeto de serviço (sendo o provedor de
serviço) detecta um evento não solicitado por um serviço solicitado. Este evento é então indicado para a aplicação.
• Um serviço não confirmado envolve um ou mais objetos de serviço de mesmo nível. O aplicativo emite uma solicitação para
seu objeto de serviço local. Essa solicitação é transferida para o(s) objeto(s) de serviço de mesmo nível que cada um a
passa para seu aplicativo como uma indicação. O resultado não é confirmado de volta.
• Um serviço confirmado envolve apenas um objeto de serviço de mesmo nível. O aplicativo emite uma solicitação para seu
objeto de serviço local. Essa solicitação é transferida para o objeto de serviço de mesmo nível que a passa para o outro
aplicativo como uma indicação. O outro aplicativo emite uma resposta que é transferida para o objeto de serviço de
origem que a transmite como uma confirmação para o aplicativo solicitante.
Serviços não confirmados e confirmados são chamados coletivamente de serviços remotos.
4.3 Modelo de dispositivo CANopen
4.3.1 Geral
Um dispositivo CANopen é estruturado da seguinte forma (mostrado na Figura 5):

• Comunicação – Esta unidade de função fornece os objetos de comunicação e a funcionalidade apropriada para transportar
itens de dados através da estrutura de rede subjacente.
• Dicionário de objetos – O dicionário de objetos é uma coleção de todos os itens de dados que influenciam o comportamento
dos objetos de aplicação, os objetos de comunicação e a máquina de estado usada neste dispositivo.
• Aplicativo – O aplicativo compreende a funcionalidade do dispositivo no que diz respeito à interação com o ambiente do
processo.
Assim, o dicionário de objetos serve como uma interface entre a comunicação e a aplicação.


Comunicação Inscrição
Dicionário de objetos
Máquina de estado
Inscrição
objeto
Entrada 1
Entrada 2 Inscrição
Com.
objeto
objeto
Com. :::
objeto Inscrição
objeto
Com.
objeto Entrada n
Com. Inscrição
objeto objeto
Rede Processo
Figura 5: Modelo do dispositivo CANopen
4.4 Sequências do protocolo de comunicação
4.4.1 Geral
As sequências do protocolo de comunicação descrevem os diferentes princípios do protocolo de comunicação e

os modos disponíveis de disparo de transmissão de mensagem.
As sequências do protocolo de comunicação CANopen suportam a transmissão de mensagens síncronas e
orientadas a eventos. Por meio da transmissão síncrona de mensagens, é possível uma aquisição e atuação
coordenada de dados em toda a rede. A transmissão síncrona de mensagens é suportada por objetos de
comunicação pré-definidos. As mensagens síncronas são transmitidas em relação a uma mensagem de
sincronização pré-definida; mensagens orientadas a eventos são transmitidas a qualquer momento.
Devido ao caráter de evento do mecanismo de comunicação subjacente, é possível definir tempos de inibição para
a comunicação. Para garantir que não ocorra inanição na rede para objetos de comunicação com baixa prioridade,
é possível atribuir um tempo de inibição ao objeto de comunicação. O tempo de inibição de um objeto de
comunicação define o tempo mínimo decorrido entre duas invocações consecutivas de um serviço de transmissão
para aquele objeto de comunicação.
No que diz respeito à sua funcionalidade, distinguem-se três tipos de modelos de protocolo de comunicação
• Protocolo Mestre/Escravo (ver subcláusula 4.4.2) •
Protocolo Cliente/Servidor (ver subcláusula 4.4.3)
• Protocolo produtor/consumidor (ver subcláusula 4.4.4)
4.4.2 Protocolo mestre/escravo

A qualquer momento há exatamente um dispositivo CANopen na rede servindo como mestre para uma
funcionalidade específica. Todos os outros dispositivos CANopen na rede são considerados escravos. O mestre
emite uma solicitação e o(s) escravo(s) endereçado(s) responde(respondem) se o protocolo exigir esse comportamento. Figura 6
define o protocolo de comunicação mestre/escravo não confirmado. A Figura 7 define o protocolo de comunicação
mestre/escravo confirmado.
Mestre Escravos
solicitar
dados
indicação
indicação
indicação
Figura 6: Protocolo de comunicação mestre/escravo não confirmado

Figura 7: Protocolo de comunicação mestre/escravo confirmado
4.4.3 Protocolo cliente/servidor

Este é um protocolo de comunicação usado entre um único cliente e um único servidor. Um cliente emite um
pedido (upload/download) fazendo com que o servidor execute uma determinada tarefa. Depois de terminar a
tarefa o servidor responde ao pedido. A Figura 8 define o protocolo de comunicação cliente/servidor.
Cliente Servidor
solicitar
dados
indicação
resposta
confirmação dados
Figura 8: Protocolo de comunicação cliente/servidor
4.4.4 Protocolo produtor/consumidor – modelo pull/push

O protocolo produtor/consumidor envolve um produtor e zero ou mais consumidores. O modelo push conforme
definido na Figura 9 é caracterizado por um protocolo não confirmado solicitado pelo produtor. O modelo pull
conforme definido na Figura 10 é caracterizado por um protocolo confirmado solicitado pelo consumidor.
Produtor Consumidores
solicitar
dados
indicação
indicação
indicação
Figura 9: Modelo push

Figura 10: Modelo de tração
4.4.5 O dicionário de objetos
O dicionário de objetos é essencialmente um agrupamento de objetos acessíveis através da rede de uma forma
ordenada pré-definida. Cada objeto dentro do dicionário de objetos é endereçado usando um índice de 16 bits e um
subíndice de 8 bits.
4.5 Modelo do sistema de rede
4.5.1 Perfil do dispositivo
Um perfil de dispositivo é uma descrição dos objetos do dicionário de objetos de um dispositivo lógico que compreende
um dispositivo virtual. Esta descrição inclui uma descrição funcional dos objetos e uma descrição formal dos objetos.
A descrição funcional define o comportamento de um objeto dentro do dicionário de objetos. A descrição formal define
se um objeto deve ser implementado ou pode ser implementado, bem como o acesso de e para a rede CANopen. O
acesso depende do método de como um objeto é acessado.
4.5.2 Perfil do aplicativo
O perfil do aplicativo é uma descrição dos objetos do dicionário de objetos de um dispositivo virtual e inclui uma
configuração de rede de todos os dispositivos CANopen. Esta descrição inclui uma descrição funcional dos objetos e
uma descrição formal dos objetos. A descrição funcional define o comportamento de um objeto dentro do dicionário de
objetos. A descrição formal define se um objeto deve ser implementado ou pode ser implementado, bem como o
acesso de e para a rede. O acesso depende do método de como um índice e um subíndice são acessados.

5 Camada física
5.1 Referência ao modelo OSI
De acordo com o modelo de referência OSI, a camada física (mostrada na Figura 11) é dividida em três subcamadas:
• Interface dependente do meio,

• Fixação do meio físico e
• Sinalização física.
PLS
Codificação/decodificação de bits
Tempo de bits
Sincronização
PMA
Características do driver/receptor
MDI
Conectores
Figura 11: Modelo de referência da camada física
5.2 Interface dependente do meio
A interface dependente do meio não se enquadra no escopo desta especificação.
5.3 Fixação do meio físico
O meio físico para um dispositivo CANopen deve ser uma linha de barramento de dois fios acionada diferencialmente com
retorno comum de acordo com a especificação de transmissão de alta velocidade em /ISO11898-2/.
NOTA Outras tecnologias de acesso ao meio físico como /ISO11898-3/ podem ser usadas.
Usando o transceptor de alta velocidade de acordo com /ISO11898-2/ a classificação máxima para VCAN_H e VCAN_L
deve ser +16V. O isolamento galvânico entre dispositivos CANopen é opcional. Recomenda-se usar um transceptor que
seja capaz de sustentar a desconexão de qualquer um dos fios do conector, incluindo as tensões V+ opcionais de até 30
V.
5.4 Sinalização física
A codificação/decodificação e sincronização de bits devem atender aos requisitos definidos em /ISO11898-1/.

A temporização do bit deve atender aos requisitos definidos em /ISO11898-1/ e é recomendável seguir as definições
fornecidas na Tabela 1 (as estimativas de comprimento de barramento correspondentes são mostradas na Tabela 2). Uma
dessas taxas de bits deve ser suportada, taxas de bits adicionais podem ser suportadas.
Tabela 1: configurações de tempo de bit recomendadas
Intervalo válido Localização

Tempo de bits nominal
Taxa de bits para localização do recomendada do ponto
tb
ponto de amostra de amostragem
1 Mbit/s 1µs 75% a 90% 87,5%
800 kbit/s 1,25µs 75% a 90% 87,5%
500 kbit/s 2µs 85% a 90% 87,5%
250 kbit/s 4µs 85% a 90% 87,5%
125 kbit/s 8µs 85% a 90% 87,5%
50 kbit/s 20µs 85% a 90% 87,5%
20 kbit/s 50µs 85% a 90% 87,5%
10 kbit/s 100µs 85% a 90% 87,5%

Tabela 2: Comprimentos de ônibus estimados
Taxa de bits Comprimento do barramento (1)
1 Mbit/s 25 m
800 kbit/s 50 m
500 kbit/s 100 m
250 kbit/s 250 m
125 kbit/s 500 m
50 kbit/s 1.000 m
20 kbit/s 2.500m
10 kbit/s 5.000 m
Nota 1: A estimativa do comprimento do barramento é baseada na localização recomendada da amostra

ponto.
A estimativa do comprimento do barramento é baseada em um atraso de propagação de 5 ns/m. Os tempos

de atraso de controladores CAN usados, transceptores CAN e optoacopladores precisam ser considerados
adicionalmente.

6 Camada de enlace de dados
6.1 Geral
As redes descritas devem ser baseadas em uma camada de enlace de dados e suas subcamadas de acordo com /ISO11898-
1/.
6.2 Tipo de quadro CAN
Esta especificação é baseada nos frames base CAN com CAN-ID de 11 bits. Não é necessário suportar o quadro estendido
CAN com campo identificador de 29 bits.
NOTA: No entanto, como certas aplicações exigem o uso do quadro estendido CAN com CAN-ID de 29 bits, a rede também é
operada neste modo se for suportada em todos os dispositivos CANopen.

7 Camada de aplicação
7.1 Tipos de dados e regras de codificação
7.1.1 Descrição geral dos tipos de dados e regras de codificação
Para poder trocar dados significativos pela rede, é necessário que o formato desses dados e seu significado sejam
conhecidos pelo produtor e consumidor(es). Esta especificação modela isso pelo conceito de tipos de dados.
As regras de codificação definem a representação de valores de tipos de dados e a sintaxe de transferência para o
representações. Os valores são representados como sequências de bits. As sequências de bits são transferidas em
sequências de octetos (bytes). Para tipos de dados numéricos, a codificação é estilo little endian.
Os aplicativos geralmente exigem tipos de dados além dos tipos de dados básicos. Usando o mecanismo de tipo de dados
composto, é possível estender a lista de tipos de dados disponíveis. Alguns tipos de dados estendidos gerais são definidos
como “Cadeia Visível” ou “Hora do Dia”, por exemplo (ver subcláusula 7.1.6.3 e subcláusula 7.1.6.5). Os tipos de dados
compostos são um meio para implementar “DEFTYPES” definidos pelo usuário na terminologia desta especificação e não
“DEFSTRUCTS”.
7.1.2 Definições de tipo de dados
Um tipo de dados determina uma relação entre valores e codificação para dados desse tipo. Os nomes são atribuídos aos
tipos de dados em suas definições de tipo. A sintaxe de definições de dados e tipos de dados é a seguinte (consulte /
EN61131-3/).
definição_de_dados ::= type_name data_name

tipo_definição ::= construtor type_name
construtor ::= construtor_composto |
construtor_básico
composto_construtor ::= construtor_array |
estrutura_construtor
array_constructor ::= 'ARRAY' '[' comprimento ']' 'OF' type_name
estrutura_construtor ::= 'STRUCT' 'OF' component_list
component_list ::= componente { ',' componente }
componente ::= type_name component_name
basic_constructor ::= 'BOOLEANO' |
'VOID' bit_size |
'INTEIRO' bit_size |
'UNSIGNED' bit_size |
'REAL32' |
'REAL64' |
'NADA'
bit_size ::= '1' | '2' | <...> | '64'

::= positive_integer
comprimento ::= nome_simbólico
data_name ::= nome_simbólico
type_name ::= nome_simbólico
component_name ::= letra { [ '_' ] ( letra | dígito ) } ::=
symbol_name positive_integer ( '1' | '2' | <...> | '9' ) { dígito }
carta ::= 'A' | 'B' | <...> | 'Z' | 'um' | 'b' | <...> | 'z'
dígito ::= '0' | '1' | <...> | '9'
Definições recursivas não devem ser usadas.
O tipo de dados definido por type_definition é chamado básico (res.~compound) quando o construtor é basic_constructor
(res. composto_constructor).

7.1.3 Sequências de bits
7.1.3.1 Definição de sequências de bits
Um bit deve ter os valores 0 ou 1. Uma sequência de bits b é um conjunto ordenado de 0 ou mais bits. Se uma sequência de
bits b contém mais de 0 bits, eles são denotados como bj, j > 0. Sejam b0, ..., bn-1 bits, n um inteiro positivo.
Então
b = b0 b1 ... bn-1
é chamada de sequência de bits de comprimento |b| = n. A sequência de bits vazia de comprimento 0 é denotada por H.
Exemplos: 10110100b, 1b, 101b, etc. são sequências de bits.

O operador de inversão ( ) em sequências de bits atribui a uma sequência de bits
b = b0 b1 ... bn-1
a sequência de bits
b = b0 b1 ... bn-1
Aqui 0 = 1 e 1 = 0 em bits.
A operação básica em sequências de bits é a concatenação.

Sejam a = a0 ... am-1 e b = b0 ... bn-1 sequências de bits. Então a concatenação de a e b, denotada ab, é
ab = a0 ... am-1 b0 ... bn-1
Exemplo: (10)(111) = 10111 é a concatenação de 10 e 111.

O seguinte vale para sequências de bits arbitrárias a e b:
|ab| = |a| + |b|
e
Hum = umH = um
7.1.3.2 Sintaxe de transferência para sequências de bits
Para transmissão pela rede, uma sequência de bits é reordenada em uma sequência de octetos. Aqui e na seguinte notação
hexadecimal é usada para octetos. Seja b = b0...bn-1 uma sequência de bits com n < 64. Denote k um inteiro não negativo
tal que 8(k - 1) < n < 8k. Então b é transferido em k octetos montados conforme especificado na Figura 12. Os bits bi, i > n do
octeto numerado mais alto são bits "do not care".
Octeto 1 é transmitido primeiro e octeto k é transmitido por último. Portanto, a sequência de bits é transferida da seguinte
maneira pela rede:
b7, b6, ..., b0, b15, ..., b8, ...

número do octeto 1. 2. k.
b7 .. b0 b15 .. b8 b8k -1 .. b8k -8
Figura 12: Sintaxe de transferência para sequências de bits
Exemplo:
Bit 9 ... Bit 0
10b 0001b 1100b
2h 1h Canal
= 21 canais
A sequência de bits b = b0 .. b9 = 0011 1000 01b representa um UNSIGNED10 com o valor 21Ch e é transferido em
dois octetos:
Primeiro 1Ch e depois 02h.
7.1.4 Tipos de dados básicos
7.1.4.1 Geral
Para tipos de dados básicos “type_name” é igual à string literal do construtor associado (aka symbol_name), por exemplo,
BOOLEAN BOOLEAN
é a definição de tipo para o tipo de dados BOOLEAN.
7.1.4.2 NIL
Os dados do tipo de dados básico NIL são representados por H.
7.1.4.3 Booleano
Os dados do tipo de dados básico BOOLEAN atingem os valores TRUE ou FALSE. Os valores são representados como
sequências de bits de comprimento 1. O valor TRUE (res. FALSE) é representado pela sequência de bits 1 (res. 0).
7.1.4.4 Nulo
Os dados do tipo de dados básico VOIDn são representados como sequências de bits de comprimento n bits. O valor dos
dados do tipo VOIDn é indefinido. Os bits na seqüência de dados do tipo VOIDn devem ser especificados explicitamente ou
marcados como "do not care".
Dados do tipo VOIDn são úteis para campos reservados e para alinhar componentes de valores compostos em limites de
octetos.
7.1.4.5 Inteiro não assinado
Os dados do tipo de dados básico UNSIGNEDn possuem valores nos inteiros não negativos. O intervalo de valores é 0, ...,
2n-1. Os dados são representados como sequências de bits de comprimento n. A sequência de bits
b = b0 ...bn-1
é atribuído o valor
NÃO ASSINADOn(b) = bn-1 2n-1+ ...+ b1 21 + b0 20
Observe que a sequência de bits começa à esquerda com o byte menos significativo.
Exemplo: O valor 266 = 10Ah com tipo de dados UNSIGNED16 é transferido em dois octetos pelo barramento,
primeiro 0Ah e depois 01h.

Os tipos de dados UNSIGNEDn transferidos são definidos na Figura 13.
número do octeto 1. 2. 3. 4. 5. 6. 7. 8.
NÃO ASSINADO8 b7..b0
NÃO ASSINADO16 b7..b0 b15..b8

NÃO ASSINADO24 b7..b0 b15..b8 b23..b16
NÃO ASSINADO32 b7..b0 b15..b8 b23..b16 b31..b24
NÃO ASSINADO40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32
NÃO ASSINADO48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40
NÃO ASSINADO56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48

NÃO ASSINADO64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56
Figura 13: Sintaxe de transferência para o tipo de dados UNSIGNEDn
7.1.4.6 Inteiro assinado
Os dados do tipo de dados básico INTEGERn possuem valores nos inteiros. O intervalo de valores é de -2n-1 a 2n-1-
1. Os dados são representados como sequências de bits de comprimento n. A sequência de bits
b = b0 .. bn-1
é atribuído o valor
INTEGRn(b) = bn-2 2n-2 + ...+ b1 21 + b0 20 se bn-1 = 0
e, realizando a aritmética em complemento de dois,
INTEGERn(b) = - INTEGERn(^b) - 1 se bn-1 = 1
Observe que a sequência de bits começa à esquerda com o bit menos significativo.
Exemplo: O valor –266 = FEF6h com tipo de dados INTEGER16 é transferido em dois octetos pelo barramento, primeiro F6h
e depois FEh.
Os tipos de dados INTEGERn transferidos são definidos na Figura 14.
número do octeto 1. 2. 3. 4. 5. 6. 7. 8.
INTEIRO8 b7..b0
INTEIRO 16 b7..b0 b15..b8
INTEIRO 24 b7..b0 b15..b8 b23..b16
INTEIRO32 b7..b0 b15..b8 b23..b16 b31..b24
INTEIRO 40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32
INTEIRO 48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40
INTEIRO 56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48
INTEIRO 64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56
Figura 14: Sintaxe de transferência para o tipo de dados INTEGERn
7.1.4.7 Números de Ponto Flutuante
Os dados dos tipos de dados básicos REAL32 e REAL64 têm valores nos números reais.
O tipo de dados REAL32 é representado como uma sequência de bits de comprimento 32. A codificação dos valores segue /IEEE754/. A
sintaxe de transferência é especificada na Figura 15.
O tipo de dados REAL64 é representado como uma sequência de bits de comprimento 64. A codificação dos valores segue /IEEE754/.

Uma sequência de bits de comprimento 32 tem um valor (número real finito diferente de zero, +0, + _) ou é NaN (não é um
número). A sequência de bits
b = b0 … b31
é atribuído o valor (número finito diferente de zero)
REAL32(b) = (-1)S 2E - 127 (1 + F)

Aqui
S = b31 é o sinal.
E = b30 27 + …+ b23 20, 0 < E < 255, é o expoente não polarizado.
F = 2-23 (b22 222 + …+ b1 21 + b0 20) é a parte fracionária do número.

+
E = 0 é usado para representar 0. E = 255 é usado para representar infinitos e NaN's.
Observe que a sequência de bits começa à esquerda com o bit menos significativo.
Exemplo:
6,25 = 2E -127 (1 + F) com
E =129 =27 +20 e
F = 2-1 +2-4 = 2 -23(222+219), portanto, o número é representado como:
S E F
b31 b30..b23 b22 .. b0
0 100 0000 1b 100 1000 0000 0000 0000 0000b
6,25 = b0 .. b31 = 0000 0000 0000 0000 0001 0011 0000 0010b
Ele é transferido na seguinte ordem:
número do octeto 1. 2. 3. 4.
REAL32 00h 00h C8h 40h
b7..b0 b15..b8 b23..b16 b31..b24
Figura 15: Sintaxe de transferência do tipo de dados REAL32
7.1.5 Tipos de dados compostos
As definições de tipo de tipos de dados compostos se expandem para uma lista exclusiva de definições de tipo envolvendo apenas
tipos de dados básicos. Correspondentemente, os dados do tipo composto ´type_name´ são listas ordenadas de dados do
componente denominados ´component_name_i´ do tipo básico ´basic_type_i´.
Os construtores de tipos de dados compostos são ARRAY e STRUCT OF.
ESTRUTURA DE
basic_type_1 nome_componente_1,
basic_type_2 nome_componente_2,
… …
basic_type_N nome_componente_N
type_name
ARRAY [ comprimento ] OF basic_type type_name
A sequência de bits que representa os dados do tipo composto é obtida pela concatenação das sequências de bits que representam
os dados do componente.

Suponha que os componentes ´component_name_i´ sejam representados por suas seqüências de bits
b(i), para i = 1,…,N
Em seguida, os dados compostos são representados pela sequência concatenada
b0(1) .. bn-1(1) .. bn-1(N).
Exemplo:
Considere o tipo de dados
ESTRUTURA DE
INTEIRO 10 x,
NÃO ASSINADO5 dentro
Novos dados
Suponha que x = - 423 = 259h eu = 30 = 1Eh. Sejam b(x) e b(u) as seqüências de bits que representam os valores de x e u,
respectivamente. Então:
b(x) = b0(x) .. b9(x) b(u) = b0(u) .. b4(u) b(xu) = 1001101001b
= b(x) b(u) = b0(xu) .. b14(xu) = 1001101001

01111b = 01111b
O valor da estrutura é transferido com dois octetos, primeiro 59h e depois 7Ah.
7.1.6 Tipos de dados estendidos
7.1.6.1 Geral
Os tipos de dados estendidos consistem nos tipos de dados básicos e nos tipos de dados compostos definidos nas subseções a seguir.
7.1.6.2 Cadeia de Octetos
O tipo de dados OCTET_STRINGlength é definido abaixo; length é o comprimento da string do octeto.
ARRAY [ comprimento ] DE UNSIGNED8 OCTET_STRINGcomprimento
7.1.6.3 String Visível
O tipo de dados VISIBLE_STRINGlength é definido abaixo. Os valores admissíveis de dados do tipo VISIBLE_CHAR são 0h e o intervalo
de 20h a 7Eh. Os dados são interpretados como ISO 646-1973(E) 7-
caracteres codificados por bits. length é o comprimento da string visível.
NÃO ASSINADO8 VISIBLE_CHAR
ARRAY [ comprimento ] OF VISIBLE_CHAR VISIBLE_STRING comprimento
Não há 0h necessário para terminar a string.
7.1.6.4 Cadeia Unicode
O tipo de dados UNICODE_STRINGlength é definido abaixo; length é o comprimento da string unicode.
ARRAY [ comprimento ] DE NÃO ASSINADO 16 UNICODE_STRINGcomprimento
7.1.6.5 Hora do dia
O tipo de dados TIME_OF_DAY representa o tempo absoluto. Segue da definição e das regras de codificação que TIME_OF_DAY é
representado como uma sequência de bits de comprimento 48.
O componente ms é o tempo em milissegundos após a meia-noite. Dias componentes é o número de dias desde 1º de janeiro de 1984.
ESTRUTURA DE
NÃO ASSINADO 28 ms,

VOID4 reservado,
NÃO ASSINADO16 dias
HORA DO DIA
7.1.6.6 Diferença de Horário
O tipo de dados TIME_DIFFERENCE representa uma diferença de tempo. Segue da definição e das regras de codificação que
TIME_DIFFERENCE é representado como uma sequência de bits de comprimento 48.

As diferenças de tempo são somas de números de dias e milissegundos. O componente ms é o número de milissegundos. Dias
componentes é o número de dias.
ESTRUTURA DE
NÃO ASSINADO 28 ms,

VOID4 reservado,
NÃO ASSINADO16 dias

DIFERENÇA DE TEMPO
7.1.6.7 Domínio
Os domínios são usados para transferir um grande bloco arbitrário de dados de um cliente para um servidor e vice-versa.
O conteúdo de um bloco de dados é específico da aplicação e não se enquadra no escopo desta especificação.
7.2 Objetos de comunicação
7.2.1 Geral
Os objetos de comunicação são descritos pelos serviços e protocolos.

Todos os serviços são descritos em uma forma tabular que contém os parâmetros de cada primitiva de serviço definida para
esse serviço. As primitivas que são definidas para um determinado serviço determinam o tipo de serviço (por exemplo, não
confirmado, confirmado, etc.).
Todos os serviços assumem que não ocorrem falhas na camada de enlace de dados e na camada física do CAN. Essas falhas
são resolvidas pelo aplicativo e não se enquadram no escopo desta especificação.
7.2.2 Objeto de dados de processo (PDO)
7.2.2.1 Geral
A transferência de dados em tempo real é realizada por meio de "Process Data Objects (PDO)". A transferência de PDO é
realizada sem sobrecarga de protocolo.
O PDO corresponde aos objetos do dicionário de objetos e fornece a interface para os objetos da aplicação. O tipo de dados e
o mapeamento de objetos de aplicativo em um PDO são determinados por uma estrutura de mapeamento de PDO padrão
correspondente dentro do dicionário de objetos. Se o mapeamento de PDO variável for suportado, o número de PDO e o
mapeamento de objetos de aplicação em um PDO podem ser transmitidos para um dispositivo CANopen durante o processo de
configuração (ver cláusula 7.3.1) aplicando os serviços SDO aos objetos correspondentes do dicionário de objetos .
O número e o comprimento do PDO de um dispositivo CANopen são específicos do aplicativo e podem ser especificados no
perfil do dispositivo ou no perfil do aplicativo.
Existem dois tipos de uso para PDO. A primeira é a transmissão de dados e a segunda a recepção de dados. Distingue-se em
Transmitir-PDO (TPDO) e Receber-PDO (RPDO). Dispositivos CANopen que suportam TPDO são produtores de PDO e
dispositivos CANopen que suportam RPDO são chamados de consumidores de PDO. PDO são descritos pelo parâmetro de
comunicação PDO e pelo parâmetro de mapeamento PDO. A estrutura desses tipos de dados é explicada na cláusula 7.4.8. O
parâmetro de comunicação PDO descreve as capacidades de comunicação do PDO. O parâmetro de mapeamento PDO contém
informações sobre o conteúdo do PDO.
Para cada PDO é obrigatório o par de parâmetros de comunicação e mapeamento. Os objetos apresentados acima são descritos
na cláusula 7.4.
A definição de PDO dentro de um perfil de dispositivo sempre se refere ao 1º dispositivo lógico dentro de um dispositivo
CANopen. Se as definições forem usadas para o 2º dispositivo lógico, o número PDO no dispositivo CANopen utilizado deve ser
o número PDO definido no perfil do dispositivo acrescido do valor de 64 (40h) conforme definido na Tabela 3.
NOTA: O número de PDOs não é limitado para um dispositivo lógico, por exemplo, um dispositivo CANopen com apenas um
dispositivo lógico pode ter 512 PDOs.

Tabela 3: Exemplo de cálculo do número PDO
Dispositivo lógico em
Número PDO no dispositivo CANopen Número PDO no perfil do dispositivo
dispositivo CANopen
Número PDO + 0 Número PDO

1º dispositivo lógico
(PDO1 a PDO64) (PDO1 a PDO64)

Número DOP + 192 Número PDO



7.2.2.2 Modos de transmissão
Os seguintes modos de transmissão PDO são distinguidos:

• Transmissão síncrona
• Transmissão orientada a eventos
Para sincronizar os dispositivos CANopen, um objeto de sincronização (objeto SYNC) é transmitido periodicamente por
um aplicativo de sincronização. O objeto SYNC é representado por um objeto de comunicação pré-definido (ver subcláusula
7.2.5). Na Figura 16 é mostrado o princípio da transmissão síncrona e acionada por eventos. Os PDOs síncronos são
transmitidos dentro de uma janela de tempo pré-definida imediatamente após o objeto SYNC.
Síncrono Síncrono
comprimento da janela comprimento da janela
Tempo
Objeto de sincronização PDO síncrono PDO orientado a eventos
Figura 16: Transmissão síncrona e orientada a eventos
O parâmetro de tipo de transmissão de um PDO especifica o modo de transmissão, bem como o modo de disparo.
Para TPDOs síncronos, o tipo de transmissão também especifica a taxa de transmissão na forma de um fator baseado no
período básico de transmissão do objeto SYNC. Um tipo de transmissão de 0 significa que a mensagem deve ser
transmitida após a ocorrência do SYNC, mas acíclica (não periodicamente), somente se um evento ocorreu antes do
SYNC. O tipo de transmissão 1 significa que a mensagem deve ser transmitida com cada objeto SYNC. Um tipo de
transmissão de n significa que a mensagem deve ser transmitida com cada n-ésimo objeto SYNC. TPDOs acionados por
eventos são transmitidos sem qualquer relação com o objeto SYNC.

Os dados dos RPDOs síncronos recebidos após a ocorrência do objeto SYNC são passados para a aplicação com a ocorrência do
seguinte SYNC, independente da taxa de transmissão especificada pelo tipo de transmissão. Os dados de RPDOs controlados por
eventos são passados diretamente para o aplicativo.
7.2.2.3 Modos de disparo
Três modos de disparo de mensagens são distinguidos:

- Acionado por evento e temporizador
A transmissão da mensagem é acionada pela ocorrência de um evento específico do aplicativo especificado no perfil do
dispositivo, perfil do aplicativo ou específico do fabricante, ou se um tempo especificado (evento-tempo) tiver decorrido sem a
ocorrência de um evento.
- Solicitado remotamente
A transmissão de um PDO acionado por evento é iniciada no recebimento de um RTR iniciado por um PDO
consumidor.
- Acionado de forma síncrona

A transmissão da mensagem é acionada pela ocorrência do objeto SYNC. A condição de disparo é o número de Sync e
opcionalmente um evento interno.
7.2.2.4 Serviços PDO
7.2.2.4.1 Geral
A transmissão de PDO segue a relação produtor/consumidor conforme descrito na subcláusula 4.4.4.

Atributos:
- Número PDO: Número PDO [1..512] para cada tipo de usuário no dispositivo local
- tipo de usuário: um dos valores {consumidor, produtor}
- tipo de dados: de acordo com o mapeamento PDO

- tempo de inibição: n*100 µs, n > 0
7.2.2.4.2 Serviço de gravação PDO
A escrita do serviço PDO está de acordo com o modelo push. Há zero ou mais consumidores do DOP.
A DOP deverá ter exatamente um produtor.
Através deste serviço o produtor do PDO envia os dados dos objetos de aplicação mapeados para o(s) consumidor(es). Os parâmetros
para este serviço são definidos na Tabela 4.
Tabela 4: Gravação de PDO de serviço
Parâmetro Pedido / Indicação
Argumento Obrigatoriedade
Número PDO
obrigatoriedade
Dados
obrigatoriedade

7.2.2.4.3 Serviço de leitura do PDO
A leitura do serviço PDO está de acordo com o modelo pull. Há um ou mais consumidores da DOP.
A DOP deverá ter exatamente um produtor.
Através deste serviço o consumidor do PDO solicita ao produtor que forneça os dados dos objetos de aplicação mapeados. O serviço está
confirmado. O parâmetro de resultado remoto confirmará o valor. Os parâmetros para este serviço são definidos na Tabela 5.
Tabela 5: Leitura do PDO de serviço
Parâmetro Pedido / Indicação Resposta / Confirmar
Número PDO obrigatoriedade
Resultado remoto Obrigatoriedade
Dados obrigatoriedade
7.2.2.5 Protocolo PDO
7.2.2.5.1 Gravação do protocolo PDO
A solicitação de gravação do serviço PDO não está confirmada. O produtor de PDO deve enviar os dados do processo dentro de um PDO
para a rede. Pode haver de 0 a n consumidores de PDO. No(s) consumidor(es) de DOP é indicada a recepção de um DOP válido. A Figura 17
define o protocolo de gravação PDO.
Dados do processo: L bytes de dados do aplicativo
Figura 17: Gravação do protocolo PDO


7.2.2.5.2 Protocolo PDO lido
O serviço para uma solicitação de leitura de PDO é confirmado. Um ou mais consumidores PDO devem transmitir um RTR
para a rede. Na recepção do RTR, o produtor de DOP para o DOP solicitado deverá transmitir o DOP. Em todos os
consumidores de DOP para este DOP deverá ser indicada a recepção. Pode haver de 1 a n consumidores de PDO. O serviço
de leitura é opcional e depende dos recursos de hardware. Figura 18
especifica o protocolo de leitura PDO.
Dados do processo: L bytes de dados do aplicativo

Figura 18: Leitura do protocolo PDO
7.2.3 Multiplex PDO (MPDO)
7.2.3.1 Geral
Um MPDO fornece acesso direto de gravação a objetos do dicionário de objetos de um dispositivo CANopen. O tamanho dos
dados desses objetos é limitado a um máximo de 4 bytes.
Existem dois tipos de uso para o MPDO. O primeiro é o modo de endereço de destino (DAM) MPDO e o segundo é o modo
de endereço de origem (SAM) MPDO. Os dispositivos CANopen que suportam a recepção de MPDOs são consumidores de
MPDO e os dispositivos CANopen que suportam a transmissão de MPDOs são produtores de MPDO.
Os MPDOs correspondem a objetos no dicionário de objetos e fornecem a interface para os objetos de aplicação.
7.2.3.2 Modos de endereço MPDO
7.2.3.2.1 Modo de endereço de destino (DAM)
Um multiplexador (ver 7.2.3.4.1) identifica o objeto no dicionário de objetos do consumidor MPDO. Um MPDO DAM pode
ser recebido por todos os consumidores desse MPDO simultaneamente ou por um único consumidor. Como o serviço de
gravação usado não é confirmado, uma mensagem EMCY é gerada se o objeto não existir.
A transmissão de um MPDO no produtor MPDO deve ser acionada por eventos e não por temporizador, solicitada
remotamente, acionada de forma síncrona.
7.2.3.2.2 Modo de endereço de origem (SAM)
Um multiplexador do MPDO refere-se ao produtor do MPDO. Apenas um produtor de MPDO deste tipo é permitido para cada
dispositivo CANopen. A transmissão deve ser acionada por eventos e não deve ser acionada por temporizador, solicitada
remotamente, acionada de forma síncrona. O produtor de MPDO pode utilizar uma lista de scanners para saber qual objeto
deve ser enviado. Os consumidores de MPDO podem usar uma lista de despachantes para saber qual multiplexador de
origem faz referência a qual multiplexador de destino.

7.2.3.3 Serviço MPDO
7.2.3.3.1 Geral
A transmissão do MPDO segue a relação produtor/consumidor conforme descrito na subcláusula 4.4.4.

Atributos:
- Número PDO: Número PDO [1..512] para cada tipo de usuário no dispositivo local
- tipo de um dos valores {consumidor, produtor}
usuário: - multiplexador: contendo índice e subíndice do tipo STRUCTURE OF UNSIGNED16, UNSIGNED8, com índice
especificando um objeto do dicionário de objetos do dispositivo CANopen e subíndice
especificando um componente do objeto do dicionário de objetos de um dispositivo CANopen
- tipo de endereço: um dos valores {origem, destino}

- ID do nó do consumidor ou produtor
7.2.3.3.2 Serviço de gravação MPDO
A escrita do serviço MPDO está de acordo com o modelo push. Há zero ou mais consumidores do MPDO. O MPDO terá exatamente um
produtor.
Os parâmetros para este serviço são definidos na Tabela 6.
Tabela 6: Gravação de MPDO de serviço
Número PDO
obrigatoriedade
Tipo de endereço obrigatoriedade

ID do nó
obrigatoriedade
Multiplexador obrigatoriedade
Dados
obrigatoriedade
7.2.3.4 Protocolo MPDO
7.2.3.4.1 Gravação do protocolo MPDO
A solicitação de gravação do serviço MPDO não está confirmada. O produtor de MPDO deve enviar os dados do processo dentro de um
MPDO para a rede. Pode haver de 0 a n consumidores de MPDO, dependendo do ID de nó fornecido. No(s) consumidor(es) do MPDO
deverá ser indicado o recebimento de um DOP válido. Figura 19
especifica o protocolo de gravação MPDO.

Produtor de MPDO Consumidores de MPDO
solicitar
f endereço m d
7 6 .. 0 0 0
indicação
0 1 34 7
indicação
indicação
• f: tipo de endereço
0: endereçamento de origem
1: Endereçamento de destino
• addr: node-ID do consumidor MPDO no endereçamento de destino ou produtor MPDO na origem

endereçamento.
0: Deve ser reservado no modo de endereçamento de origem. Deve endereçar todos os dispositivos CANopen da rede configurados
para recepção MPDO no modo de endereçamento de destino.
1..127: Deve endereçar o dispositivo CANopen na rede com o mesmo node-ID.
• m: multiplexador. Representa o índice/sub-índice dos dados do processo a serem transferidos pelo MPDO. Dependendo do tipo de
endereço, o índice/sub-índice deve ser usado para identificar os dados do dispositivo CANopen transmissor (endereçamento de
origem) ou para identificar os dados no dispositivo CANopen receptor (endereçamento de destino).
• d: dados do processo. O comprimento de dados inferior a 4 bytes é preenchido para caber em 32 bits.
Figura 19: Gravação do protocolo MPDO
7.2.4 Objeto de dados de serviço (SDO)
7.2.4.1 Geral
Um SDO está fornecendo acesso direto às entradas de objetos do dicionário de objetos de um dispositivo CANopen. Como essas
entradas de objetos podem conter dados de tamanho e tipo de dados arbitrários. Os SDOs podem ser usados para transferir vários
conjuntos de dados (cada um contendo um grande bloco arbitrário de dados) de um cliente para um servidor e vice-versa.
O cliente deve controlar através de um multiplexador (índice e sub-índice do dicionário de objetos) qual conjunto de dados deve ser
transferido. O conteúdo do conjunto de dados é definido no dicionário de objetos.
Basicamente, um SDO é transferido como uma sequência de segmentos. Antes de transferir os segmentos há uma fase de inicialização
onde cliente e servidor se preparam para transferir os segmentos. Para SDOs, também é possível transferir um conjunto de dados de até
quatro bytes durante a fase de inicialização. Esse mecanismo é chamado de transferência acelerada SDO.
Opcionalmente, um SDO pode ser transferido como uma sequência de blocos onde cada bloco pode consistir em uma sequência de até
127 segmentos contendo um número de sequência e os dados. Antes da transferência dos blocos deve haver uma fase de inicialização
onde cliente e servidor podem se preparar para transferir os blocos e negociar o número de segmentos em um bloco. Após a transferência
dos blocos haverá uma fase de finalização onde cliente e servidor poderão verificar a correção da transferência de dados anterior
comparando checksums derivados do conjunto de dados. O tipo de transferência mencionado acima é chamado de transferência de
bloco SDO, que é mais rápido que a transferência segmentada para um grande conjunto de dados.
No upload de bloco SDO, é possível que o tamanho do conjunto de dados não justifique o uso de uma transferência de bloco devido à
sobrecarga de protocolo implícita. Nesses casos, pode ser implementado um suporte para um fallback para a transferência SDO normal
(segmentada) ou SDO acelerada na fase de inicialização. Como a suposição do tamanho mínimo do conjunto de dados para o qual uma
transferência de bloco SDO supera os outros tipos de transferência depende de vários parâmetros, o cliente indica esse valor limite em
bytes para o servidor na fase de inicialização.
Para a transferência de bloco SDO, um esquema Go-Back-n ARQ é usado para confirmar cada bloco:
• Após o download do bloco SDO, o servidor indica ao cliente o último segmento recebido com sucesso desta transferência de bloco
SDO, reconhecendo o número de sequência deste segmento. Ao fazer isso, o servidor reconhece implicitamente todos os segmentos
anteriores a esse segmento. O cliente deve iniciar o seguinte

Transferência de bloco SDO com retransmissão de todos os dados não reconhecidos. Além disso, o servidor deve indicar
o número de segmentos por bloco SDO para a próxima transferência de bloco SDO.
• Após o upload do bloco SDO, o cliente indica ao servidor o último segmento recebido com sucesso da transferência do bloco
SDO, reconhecendo este número de sequência de segmento. Fazendo isso, o cliente reconhece implicitamente todos os
segmentos anteriores a este segmento. O servidor deve iniciar a seguinte transferência de blocos SDO com a
retransmissão de todos os dados não reconhecidos. Adicionalmente, o cliente deverá indicar o número de segmentos por
bloco SDO para a próxima transferência de bloco SDO.
Sempre o cliente inicia uma transferência SDO para qualquer tipo de transferência. O proprietário do dicionário de objetos
acessados é o servidor do SDO. Tanto o cliente quanto o servidor podem tomar a iniciativa de abortar a transferência de um
SDO.
Por meio de um SDO é estabelecido um canal de comunicação peer-to-peer entre dois dispositivos CANopen. Um dispositivo
CANopen pode suportar mais de um SDO. Um servidor-SDO suportado é o caso padrão (SDO padrão).
SDOs são descritos pelo registro de parâmetro de comunicação SDO. A estrutura deste tipo de dados é explicada na
subcláusula 7.4.8. O parâmetro de comunicação SDO descreve os recursos de comunicação do SSDO e do CSDO.
Para cada SDO os parâmetros de comunicação são obrigatórios. Se existir apenas um SSDO, os parâmetros de comunicação
podem ser omitidos. Os objetos mencionados acima estão descritos na subcláusula 7.4.
7.2.4.2 Serviços SDO
7.2.4.2.1 Geral
O modelo para a comunicação SDO é o modelo Cliente/Servidor conforme descrito na subcláusula 4.4.3.
Atributos:
- Número SDO: Número SDO [1..128] para cada tipo de usuário no dispositivo local
- tipo de um dos valores {cliente, servidor}
usuário: - tipo de dados mux: multiplexador contendo índice e subíndice do tipo STRUCTURE OF UNSIGNED16,
UNSIGNED8, com índice especificando um objeto do dicionário de objetos do
dispositivo CANopen e subíndice especificando um componente do objeto do dicionário
de objetos de um dispositivo CANopen
- tipo de transferência: depende do comprimento dos dados a serem transferidos: acelerado,
normal (segmentado) ou bloco para até 4 bytes de dados; normal (segmentado)
ou bloco para mais de 4 bytes de dados
- tipo de dados: de acordo com o índice referenciado e sub-índice
Os seguintes serviços podem ser aplicados em um SDO, dependendo dos requisitos do aplicativo:
• Download SDO, que é subdividido em
- Início de download SDO
- Segmento de download SDO
• Upload de SDO, que é subdividido em

- Início de upload SDO
- Segmento de upload SDO
• SDO abortar transferência
Ao utilizar os serviços de download SDO normal (segmentado) e upload SDO normal (segmentado), o software de comunicação
será responsável por transferir o SDO como uma sequência de segmentos.
A transferência acelerada SDO deve ser suportada. A transferência segmentada SDO deve ser suportada se objetos maiores
que 4 Bytes forem suportados. Opcionalmente, os seguintes serviços SDO para fazer uma transferência de bloco SDO com
maior utilização de barramento e desempenho para um grande tamanho de conjunto de dados podem ser implementados:
• Download do bloco SDO, que é subdividido em
- Início do download do bloco SDO
- Bloco de download do bloco SDO
- Fim do download do bloco SDO

• Upload do bloco SDO, que é subdividido em
- Início de upload de bloco SDO - Bloco
de upload de bloco SDO
- Fim do upload do bloco SDO
Ao utilizar os serviços de download de blocos SDO e upload de blocos SDO, o software de comunicação será responsável por transferir os
dados como uma sequência de blocos.
No protocolo de upload de bloco SDO, um suporte para uma mudança para protocolo de upload SDO no início do upload de bloco SDO pode
ser implementado para aumentar o desempenho da transferência para dados cujo tamanho não justifique o uso da sobrecarga de protocolo
do protocolo de upload de bloco SDO.
Para abortar uma transferência de bloco SDO, o serviço de transferência de abortar SDO é usado.
7.2.4.2.2 Download de SDO de serviço
O cliente está utilizando o serviço SDO download para transferir dados do cliente para o servidor (proprietário do dicionário de objetos). Os
dados, o multiplexador (índice e subíndice) do conjunto de dados e seu tamanho são indicados ao servidor. Os parâmetros para este serviço
são definidos na Tabela 7.
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso ou falha da solicitação. Em caso de falha, opcionalmente o
motivo é confirmado.
O download de SDO consiste no mínimo no serviço de início de download de SDO e, opcionalmente, nos serviços de segmento de download
de SDO (comprimento de dados > 4 bytes).
Tabela 7: Download de SDO de serviço
Número SDO obrigatoriedade
Tamanho opcional
Sucesso seleção
Falha seleção
Razão opcional
7.2.4.2.3 Início do download do SDO do serviço
O cliente solicita que o servidor prepare o download de dados usando o serviço de início de download SDO. Opcionalmente, o tamanho dos
dados a serem baixados é indicado ao servidor. Os parâmetros para este serviço são definidos na Tabela 8.
O multiplexador do conjunto de dados e o tipo de transferência são indicados ao servidor. No caso de download acelerado de SDO, os dados
do conjunto de dados identificado pelo multiplexador e tamanho são indicados ao servidor.

Tabela 8: Início do download do SDO de serviço
Tipo de transferência obrigatoriedade
Normal seleção
seleção
Acelerado
Tamanho opcional
Obrigatoriedade
Resultado remoto obrigatoriedade
Sucesso
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de falha, uma solicitação de transferência
de abortamento SDO deve ser iniciada. No caso de um download rápido SDO bem sucedido de um DOMÍNIO multiplexado, este serviço conclui o
download do conjunto de dados identificado pelo multiplexador.
7.2.4.2.4 Segmento de download de SDO de serviço
O cliente transfere os dados segmentados para o servidor usando o serviço de download SDO. Os dados do segmento e opcionalmente seu
tamanho são indicados ao servidor. O parâmetro continue indica ao servidor se ainda há mais segmentos a serem baixados ou se este foi o último
segmento a ser baixado. Os parâmetros para este serviço são definidos na Tabela 9.
Tabela 9: Segmento de download de SDO de serviço
Continuar obrigatoriedade
Mais seleção
Último seleção
Tamanho obrigatoriedade
Obrigatoriedade
Resultado remoto obrigatoriedade
Sucesso
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de falha, uma solicitação de transferência
de abortamento SDO deve ser iniciada. Em caso de sucesso, o servidor aceitou os dados do segmento e está pronto para aceitar o próximo
segmento. Deve haver no máximo um serviço de segmento de download SDO pendente para uma transferência SDO.
Um serviço de início de download SDO bem-sucedido com tipo de transferência segmentada deve ter sido executado antes desse serviço.

7.2.4.2.5 Upload de SDO de serviço
O cliente está utilizando o serviço de upload SDO para transferir os dados do servidor (proprietário do dicionário de objetos) para o
cliente. O multiplexador (índice e subíndice) do conjunto de dados é indicado ao servidor. Os parâmetros para este serviço são definidos
na Tabela 10.
O upload de SDO consiste em pelo menos o serviço de inicialização de upload de SDO e opcional de serviços de segmento de upload
de SDO (comprimento de dados > 4 bytes).
Tabela 10: Upload de SDO de serviço
Sucesso seleção
Tamanho opcional
Dados obrigatório
Falha seleção
Razão opcional
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso ou falha da solicitação. Em caso de falha, opcionalmente
o motivo é confirmado. Em caso de sucesso, os dados e seu tamanho são confirmados.
7.2.4.2.6 Início de upload de SDO de serviço
O cliente solicita que o servidor prepare os dados para upload usando o serviço de inicialização de upload SDO. O multiplexador (índice
e subíndice) do conjunto de dados cujo upload é iniciado é indicado ao servidor. Os parâmetros para este serviço são definidos na Tabela
11.
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de falha, uma solicitação de
transferência de abortamento SDO deve ser executada. Em caso de sucesso, o tamanho dos dados é confirmado. Em caso de
carregamento rápido SDO bem sucedido, este serviço conclui o carregamento do conjunto de dados identificado pelo multiplexador e os
dados correspondentes são confirmados.

Tabela 11: Início de upload de SDO de serviço
Número SDO obrigatório
Multiplexador obrigatório
Resultado remoto Obrigatório
Sucesso Obrigatório
Obrigatório
Multiplexador
Tipo de transferência obrigatoriedade
Normal seleção
seleção
Acelerado
Tamanho opcional
Dados obrigatório
7.2.4.2.7 Segmento de upload de SDO de serviço
O cliente solicita ao servidor que forneça os dados do próximo segmento usando o serviço de segmento de upload SDO. O parâmetro continue
indica ao cliente se ainda há mais segmentos a serem carregados ou se este foi o último segmento a ser carregado. Deve haver no máximo
um serviço de segmento de upload SDO pendente para um SDO. Os parâmetros para este serviço são definidos na Tabela 12.
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de falha, uma solicitação de
transferência de abortamento SDO deve ser iniciada. Em caso de sucesso, os dados do segmento e, opcionalmente, seu tamanho são
confirmados.
Um serviço de início de upload de SDO bem-sucedido com tipo de transferência normal (segmentado) deve ser executado antes desse serviço.
Tabela 12: Segmento de upload de SDO de serviço
Número SDO
obrigatoriedade
Continuar Obrigatório
Mais seleção
Último seleção
Tamanho obrigatoriedade

7.2.4.2.8 Download do bloco SDO de serviço
O cliente está utilizando o serviço de download do bloco SDO para transferir os dados do cliente para o servidor (proprietário do dicionário
de objetos). Os dados, o multiplexador (índice e sub-índice) do conjunto de dados e opcionalmente seu tamanho são indicados ao
servidor. Os parâmetros para este serviço são definidos na Tabela 13.
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso ou falha da solicitação. Em caso de falha, opcionalmente
o motivo é confirmado.
Tabela 13: Download do bloco SDO de serviço
Argumento Obrigatório
Número SDO Obrigatório
Multiplexador Obrigatório
Tamanho Obrigatório
Dados Obrigatório
Sucesso seleção
Falha seleção
Razão opcional
7.2.4.2.9 Início do download do bloco SDO do serviço
O cliente solicita que o servidor se prepare para download usando o serviço de início de download de bloco SDO. Os parâmetros para
este serviço são definidos na Tabela 14.
O multiplexador do conjunto de dados e opcionalmente o tamanho são indicados ao servidor.
Tanto o cliente quanto o servidor estão indicando sua capacidade e demanda para verificar a transferência completa com uma soma de
verificação no final do download do bloco SDO.
Tabela 14: Início do download do bloco SDO de serviço
Capacidade CRC obrigatório

seleção
sim
não seleção
Tamanho opcional
Capacidade CRC Obrigatório

seleção
sim
não seleção
Tamanho preto obrigatoriedade

O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação, o número de segmentos por bloco que o servidor
pode receber e sua capacidade e demanda para verificar a transferência completa com uma soma de verificação. Em caso de falha, um serviço
de transferência de aborto SDO deve ser iniciado.
7.2.4.2.10 Sub-bloco de download do bloco SDO de serviço
O cliente transfere os dados do próximo bloco para o servidor usando o serviço de subbloco de download de bloco SDO. Os dados do bloco são
transferidos para o servidor por uma sequência de segmentos. Cada segmento consiste nos dados e um número de sequência começando em 1,
que é aumentado para cada segmento em 1 até blksize. O parâmetro blksize é negociado entre servidor e cliente no serviço de início de download
de bloco SDO e pode ser alterado pelo servidor a cada confirmação de transferência de bloco. O parâmetro continue indica se o servidor deve
permanecer na fase de sub-bloco de download do bloco SDO ou mudar na fase final de download do bloco SDO. Os parâmetros para este serviço
são definidos na Tabela 15.
Tabela 15: Sub-bloco de download do bloco SDO de serviço
Continuar obrigatoriedade
Mais seleção
Último seleção
Sucesso obrigatoriedade
obrigatoriedade
Ackseq
obrigatoriedade
Tamanho preto
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de sucesso, o parâmetro ackseq indica o
número de sequência do último segmento que o servidor recebeu com sucesso. Se este número não corresponder ao número de sequência do
último segmento enviado pelo cliente durante esta transferência de bloco, o cliente deverá retransmitir todos os segmentos descartados pelo
servidor na próxima transferência de bloco. Em caso de falha fatal, um serviço de transferência de aborto SDO deve ser iniciado. Em caso de
sucesso, o servidor aceitou todos os dados de segmento reconhecidos e está pronto para aceitar o próximo bloco. Deve haver no máximo um
serviço de sub-bloco de download de bloco SDO pendente para uma transferência SDO.
Um serviço de início de download de bloco SDO bem-sucedido deve ser executado antes desse serviço.
7.2.4.2.11 Fim do download do bloco SDO do serviço
O cliente indica o fim da transferência para o servidor usando o serviço final de download do bloco SDO. O número de bytes que não contém
dados válidos nos últimos segmentos transmitidos é indicado ao servidor. Os parâmetros para este serviço são definidos na Tabela 16.
Se tanto o servidor quanto o cliente indicaram sua capacidade e demanda para verificar a transferência completa com um checksum no bloco de
download SDO, o cliente indica o checksum dos dados transferidos para o servidor. O servidor também deve gerar o checksum que deve ser
comparado com o gerado pelo cliente.

Tabela 16: Fim do download do bloco SDO de serviço
Valid_data obrigatoriedade
Soma de verificação condicional,

obrigatório se negociado
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação (correspondência de somas de verificação
entre cliente e servidor, se negociado) e conclui o download do conjunto de dados. Em caso de falha, um serviço de transferência de aborto
SDO deve ser iniciado.
7.2.4.2.12 Carregamento de bloco SDO de serviço
O cliente está utilizando o serviço de upload de bloco SDO para transferir os dados do servidor (proprietário do dicionário de objetos) para o
cliente. O multiplexador (índice e subíndice) do conjunto de dados solicitado é indicado ao servidor. Os parâmetros para este serviço são
definidos na Tabela 17.
O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso ou falha da solicitação. Em caso de falha, opcionalmente o
motivo é confirmado. Em caso de sucesso, os dados e opcionalmente seu tamanho são confirmados.
Tabela 17: Upload do bloco SDO de serviço
Sucesso seleção
Tamanho opcional
Falha seleção
Razão opcional
7.2.4.2.13 Início do upload do bloco SDO do serviço
O cliente solicita que o servidor se prepare para fazer upload de dados usando o serviço de inicialização de upload de bloco SDO. O
multiplexador do conjunto de dados cujo upload é iniciado e o número de segmentos que o cliente pode receber são indicados ao servidor.
Um valor de limite de troca de protocolo é indicado para o servidor. Se o número de bytes que devem ser carregados for menor ou igual a
este valor o servidor poderá confirmar esta transferência de dados com o serviço de upload SDO conforme descrito na subcláusula 7.2.4.2.5.
Tanto o cliente quanto o servidor estão indicando sua capacidade e demanda para verificar a transferência completa por meio de uma soma
de verificação. Opcionalmente, o tamanho do upload
dados são indicados ao cliente.

Tabela 18: Início do upload do bloco SDO de serviço
Tamanho preto obrigatório
Capacidade CRC obrigatório
Sim seleção
Não seleção
Limite obrigatório
Sucesso obrigatório
Capacidade CRC obrigatoriedade
Sim seleção
Não seleção
Tamanho opcional
O serviço está confirmado. Em caso de falha, um serviço de transferência de aborto SDO deve ser iniciado. Em caso de sucesso o
tamanho dos dados é opcionalmente indicado ao cliente.
7.2.4.2.14 Sub-bloco de upload do bloco SDO de serviço
Este serviço é iniciado pelo cliente com o serviço de inicialização de upload de SDO anterior ou o serviço de sub-bloco de upload de
bloco de SDO anterior. O servidor transfere os dados do próximo bloco para o cliente usando o serviço de sub-bloco de upload de bloco
SDO. Os dados do bloco são indicados ao cliente por uma sequência de segmentos. Cada segmento consiste nos dados do segmento e
um número de sequência começando em 1, que é aumentado para cada segmento em 1 até blksize. O parâmetro blksize é indicado pelo
cliente ao servidor durante o serviço de início de upload de bloco SDO e pode ser alterado pelo cliente a cada confirmação de
transferência de bloco. O parâmetro continue indica ao cliente se deve permanecer na fase de upload do bloco SDO ou mudar na fase
final de upload do bloco SDO. Os parâmetros para este serviço são definidos na Tabela 19.
Tabela 19: Sub-bloco de upload do bloco SDO de serviço
Continuar obrigatório
Mais seleção
Último seleção
Sucesso obrigatório
Ackseq obrigatório
Tamanho preto obrigatório

O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação. Em caso de sucesso, o parâmetro ackseq indica o
número de sequência do último segmento que o cliente recebeu com sucesso. Se este número não corresponder ao número de sequência do
último segmento enviado pelo servidor durante esta transferência de bloco, o servidor deverá retransmitir todos os segmentos descartados pelo
cliente na próxima transferência de bloco. Em caso de falha fatal, um serviço de transferência de aborto SDO deve ser iniciado. Em caso de
sucesso, o cliente aceitou todos os dados do segmento reconhecidos e está pronto para aceitar o próximo bloco. Deve haver no máximo um
serviço de sub-bloco de upload de bloco SDO pendente para uma transferência SDO.
Um serviço de inicialização de upload de bloco SDO bem-sucedido deve ser executado antes desse serviço.
7.2.4.2.15 Fim do upload do bloco SDO do serviço
O servidor indica o fim da transferência para o cliente usando o serviço final de upload de bloco SDO.
O número de bytes que não contém dados válidos nos últimos segmentos transmitidos é indicado ao cliente. Os parâmetros para este serviço são
definidos na Tabela 20.
Se tanto o servidor quanto o cliente indicaram sua capacidade e demanda para verificar a transferência completa usando checksum durante o
carregamento do bloco SDO, este checksum é indicado ao cliente pelo servidor. O cliente também deve gerar o checksum que deve ser comparado
com o gerado pelo servidor.
Tabela 20: Fim do upload do bloco SDO de serviço
Valid_data obrigatoriedade
Soma de verificação obrigatoriedade

se negociado

O serviço está confirmado. O parâmetro de resultado remoto indicará o sucesso da solicitação (correspondência de somas de verificação entre
cliente e servidor, se negociado) e conclui o download do conjunto de dados. Em caso de falha, um serviço de transferência de aborto SDO deve
ser iniciado.
7.2.4.2.16 Serviço SDO abortar transferência
O serviço de transferência de aborto de SDO aborta o serviço de upload de SDO ou o serviço de download de SDO de um SDO referenciado por
seu número. O motivo é indicado. O serviço não está confirmado. Tanto o cliente quanto o servidor de um SDO podem executar o serviço a
qualquer momento. Se o cliente de um SDO tiver um serviço confirmado pendente, a indicação do aborto é considerada a confirmação desse
serviço. Os parâmetros para este serviço são definidos na Tabela 21.
Tabela 21: Transferência de interrupção do serviço SDO
Razão obrigatoriedade


7.2.4.3 Protocolos SDO
7.2.4.3.1 Geral
Seis serviços confirmados (download de SDO, upload de SDO, início de upload de SDO, início de download de SDO,
segmento de download de SDO e segmento de upload de SDO) e um serviço não confirmado (transferência de
aborto de SDO) são definidos para SDOs fazendo o SDO normal (segmentado) e SDO acelerado transferir.
Oito serviços confirmados (download de bloco SDO, upload de bloco SDO, início de upload de bloco SDO, início de
download de bloco SDO, sub-bloco de download de bloco SDO, sub-bloco de upload de bloco SDO, fim de upload de
bloco SDO e fim de download de bloco SDO) e um não confirmado service (transferência de aborto SDO) são
definidos para SDOs fazendo a transferência de bloco SDO opcional.
7.2.4.3.2 Download do protocolo SDO
Download SDO (normal) Download SDO (acelerado)

Cliente Servidor Cliente Servidor
Iniciar download SDO Iniciar download SDO
(e = 0) (e = 1)
Segmento de download SDO

(t = 0, c = 0)

(t = 1, c = 0)

(t = 0, c = 0)

(t = x, c = 1)
Figura 20: Download do protocolo SDO
Este protocolo (especificado na Figura 20) deve ser usado para implementar o serviço de download SDO. Os SDOs
são baixados como uma sequência de zero ou mais serviços de segmento de download de SDO precedidos por um
serviço de início de download de SDO. A sequência é terminada por:
• Uma solicitação/indicação de início de download de SDO com o e-bit definido como 1 seguido por uma resposta/
confirmação de início de download de SDO, indicando a conclusão bem-sucedida de uma sequência de download
acelerada.
• Uma resposta/confirmação de segmento de download SDO com o bit c definido como 1, indicando a conclusão bem-
sucedida de uma sequência de download normal.
• Uma solicitação/indicação de transferência de aborto de SDO, indicando a conclusão malsucedida do download
seqüência.
• Uma nova solicitação/indicação de início de download de SDO, indicando a conclusão malsucedida do

sequência de download e o início de uma nova sequência de download SDO.
Se no download de dois segmentos consecutivos o bit de alternância não for alterado, o conteúdo do último segmento
deve ser ignorado. Se tal erro for relatado ao aplicativo, o aplicativo pode decidir abortar o download.

7.2.4.3.3 Início do download do protocolo SDO
O protocolo conforme definido na Figura 21 deve ser usado para implementar o serviço de início de download SDO.
Cliente Servidor
solicitar
cc = 1 x n e s m d
7 .. 5 4 3 .. 2 1 0 0 0
indicação
0 134 7
resposta
sc = 3 x m reservado
confirmação 7 .. 5 4 .. 0 0 0
0 134 7
• ccs: especificador de comando do cliente

1: inicia solicitação de download
• scs: especificador de comando do servidor

3: iniciar resposta de download
• n: válido somente se e = 1 e s = 1, caso contrário 0. Se válido indica o número de bytes em d que não contém dados. Bytes [8-n, 7] não
contêm dados.
• e: tipo de transferência
0: transferência normal
1: transferência acelerada
• s: indicador de tamanho
0: o tamanho do conjunto de dados não é indicado
1: o tamanho do conjunto de dados é indicado
• m: multiplexador. Representa o índice/sub-índice dos dados a serem transferidos pelo SDO.

• d: dados
e = 0, s = 0: d é reservado para uso posterior.
e = 0, s = 1: d contém o número de bytes a serem baixados.
O byte 4 contém o LSB e o byte 7 contém o MSB. e = 1, s = 1: d contém
os dados de comprimento 4-n a serem baixados,
a codificação depende do tipo dos dados referenciados pelo índice e subíndice
e = 1, s = 0: d contém um número não especificado de bytes a serem baixados
• x: não usado, sempre 0 •
reservado: reservado para uso posterior, sempre 0

Figura 21: Início do download do protocolo SDO

7.2.4.3.4 Segmento de download do protocolo SDO
O protocolo conforme definido na Figura 22 deve ser usado para implementar o serviço de segmento de download SDO.
Cliente Servidor
solicitar
cc = 0 t n c dados de segmento
7 .. 5 4 3 .. 1 0 0
indicação
0 1 7
resposta
sc = 1 t x reservado
confirmação 7 .. 5 4 3 .. 0 0
0 1 7
0: solicitação de segmento de download
1: resposta do segmento de download
• seg-data: no máximo 7 bytes de dados de segmento a serem baixados. A codificação depende do tipo de dados referenciados por
índice e subíndice
• n: indica o número de bytes em seg-data que não contém dados de segmento. Bytes [8-n, 7] não contêm dados de segmento. Se n = 0
bytes 1 a 7 devem conter dados de segmento.
NOTA: Se o tamanho na iniciação for indicado, isso se aplica aos dados gerais transferidos.
• c: indica se ainda há mais segmentos a serem baixados.
mais 0 segmentos para serem baixados
1: não há mais segmentos a serem baixados
• t: bit de alternância. Este bit deve alternar para cada segmento subsequente que é baixado. O primeiro segmento deve ter o bit de
alternância definido como 0. O bit de alternância deve ser igual para a solicitação e a mensagem de resposta.
• X: não usado, sempre 0
• reservado: reservado para uso posterior, sempre 0

Figura 22: Download do segmento SDO do protocolo
7.2.4.3.5 Upload do protocolo SDO
Upload de SDO (normal) Upload de SDO (expedido)

Iniciar upload de SDO Iniciar upload de SDO

(e = 0) (e = 1)
Segmento de upload SDO

(t = 0, c = 0)

(t = 1, c = 0)

(t = 0, c = 0)

(t = x, c = 1)
Figura 23: Upload do protocolo SDO

Este protocolo (especificado na Figura 23) deve ser usado para implementar o serviço de upload SDO. Os SDOs são carregados como
uma sequência de zero ou mais serviços de segmento de carregamento de SDO precedidos por um serviço de inicialização de
carregamento de SDO. A sequência é terminada por:
• Uma resposta/confirmação de inicialização de upload SDO com o e-bit definido como 1, indicando a conclusão bem-sucedida de uma
sequência de upload acelerada.
• Uma resposta/confirmação do segmento de upload SDO com o bit c definido como 1, indicando a conclusão bem-sucedida de uma
sequência de upload normal.
• Uma solicitação/indicação de transferência de aborto de SDO, indicando a conclusão malsucedida do upload

seqüência.
• Uma nova solicitação/indicação de início de upload de SDO, indicando a conclusão malsucedida da sequência de upload e o início de
uma nova sequência.
Se no upload de dois segmentos consecutivos o bit de alternância não for alterado, o conteúdo do último segmento deve ser ignorado.
Se tal erro for relatado ao aplicativo, o aplicativo pode decidir abortar o upload.
7.2.4.3.6 Início do upload do protocolo SDO
O protocolo conforme definido na Figura 24 deve ser usado para implementar o serviço de inicialização de upload SDO.
Cliente Servidor
solicitar
cc = 2 x m reservado
7 .. 5 4 .. 0 0 0
indicação
0 134 7
resposta
sc = 2 x n e s m d
confirmação 7 .. 5 4 3 .. 2 1 0 0 0
0 134 7

2: iniciar solicitação de upload

2: iniciar resposta de upload
• n: válido somente se e = 1 e s = 1, caso contrário 0. Se válido indica o número de bytes em d que não
conter dados. Bytes [8-n, 7] não contêm dados de segmento.
• e: tipo de transferência
0: transferência normal
1: transferência acelerada

• d: dados
e = 0, s = 0: d é reservado para uso posterior.
e = 0, s = 1: d contém o número de bytes a serem carregados.
O byte 4 contém o lsb e o byte 7 contém o msb.
e = 1, s = 1: d contém os dados de comprimento 4-n a serem carregados,
a codificação depende do tipo dos dados referenciados pelo índice e subíndice
e = 1, s = 0: d contém um número não especificado de bytes a serem carregados.

Figura 24: Início do upload do protocolo SDO

7.2.4.3.7 Segmento de upload do protocolo SDO
O protocolo conforme definido na Figura 25 deve ser usado para implementar o serviço de segmento de upload SDO.
Cliente Servidor
solicitar
cc = 3 t x reservado
7 .. 5 4 3 .. 0 0
indicação
0 1 7
resposta
sc = 0 t n c dados de segmento
confirmação 7 .. 5 4 3 .. 1 0 0
0 1 7
3: enviar solicitação de segmento
0: resposta do segmento de upload
• t: bit de alternância. Este bit deve alternar para cada segmento subsequente que é carregado. O primeiro segmento deve ter o bit de
alternância definido como 0. O bit de alternância deve ser igual para a solicitação e a mensagem de resposta.
• c: indica se ainda há mais segmentos a serem carregados.
0: mais segmentos a serem carregados
1: não há mais segmentos a serem carregados
• seg-data: no máximo 7 bytes de dados de segmento a serem carregados. A codificação depende do tipo de dados referenciados por
índice e subíndice
• n: indica o número de bytes em seg-data que não contém dados de segmento. Bytes [8-n, 7] não contêm dados de segmento. Se n = 0
bytes 1 a 7 devem conter dados de segmento.
NOTA: Se o tamanho na iniciação for indicado, isso se aplica aos dados gerais transferidos.

Figura 25: Upload de segmento de protocolo SDO

7.2.4.3.8 Download do bloco SDO do protocolo
Download do bloco SDO

Cliente Servidor
Iniciar download do bloco SDO
Sub-bloco de download do bloco SDO
(normal)
(normal)
(último)
Fim do download do bloco SDO
Download do bloco SDO Download do bloco SDO

Cliente sub-bloco (normal) Servidor Cliente sub-bloco (último) Servidor
Baixar segmento Baixar segmento

(c = 0, sequência = 1) (c = 0, sequência = 1)



(c = 0, sequência = n) (c = 1, sequência = n)
Confirmar bloqueio Confirmar bloqueio
Figura 26: Download do bloco SDO do protocolo
Este protocolo (especificado na Figura 26) deve ser usado para implementar um serviço de download de blocos SDO.
Os SDOs são baixados como uma sequência de serviços de sub-bloco de download de bloco SDO precedidos por um serviço de início
de download de bloco SDO. A sequência de sub-blocos de download do bloco SDO é encerrada por:
• Um segmento baixado dentro de um bloco com o c-bit definido como 1, indicando a conclusão do
Sequência de download do bloco SDO.
• Uma solicitação/indicação de interrupção de transferência de SDO, indicando a conclusão malsucedida da sequência de download.
O serviço de download de bloco SDO é encerrado com o serviço final de download de bloco SDO. Se tanto o cliente quanto o servidor
tiverem indicado a capacidade de gerar um CRC durante o serviço de início de download do bloco SDO, o servidor deverá gerar o CRC
nos dados recebidos. Se este CRC for diferente do CRC gerado pelo cliente, o servidor deve indicar isso com uma indicação de
transferência de abortar SDO.
7.2.4.3.9 Início do download do bloco SDO do protocolo
O protocolo conforme definido na Figura 27 deve ser usado para implementar o serviço de início de download do bloco SDO.

Cliente Servidor
solicitar
cc = 6 x cc s cs=0 m Tamanho
7 .. 5 4 .. 3 2 1 0 0 0
indicação
0 134 7
resposta
sc = 5 x sc s=0 m tamanho preto reservado

confirmação 7 .. 5 4 .. 3 2 1 .. 0 0 0 0
0 13 4 5 7

6: bloquear download

• cs: subcomando cliente
0: iniciar solicitação de download

• ss: subcomando do servidor
0: iniciar resposta de download
• cc: suporte CRC do cliente

cc = 0: O cliente não suporta a geração de CRC nos dados
cc = 1: O cliente suporta a geração de CRC nos dados
• sc: suporte CRC do servidor
sc = 0: O servidor não suporta a geração de CRC nos dados
sc = 1: o servidor suporta a geração de CRC nos dados
• tamanho: tamanho do download em bytes

s = 0: tamanho é reservado para uso posterior, sempre 0
s = 1: size contém o número de bytes a serem baixados
O byte 4 contém o LSB e o byte 7 o MSB
• blksize: Número de segmentos por bloco que deve ser utilizado pelo cliente para o bloco seguinte
baixar com 0 < blksize < 128

Figura 27: Início do download do bloco SDO do protocolo


7.2.4.3.10 Sub-bloco de download do bloco SDO do protocolo
O protocolo conforme definido na Figura 28 deve ser usado para implementar o serviço de sub-bloco de download de bloco
SDO.
Cliente Servidor
solicitar
0 1 7
c sequência dados de segmento
7 c 6 ..sequência
0 0
7 6 .. 0
dados de segmento
0 indicação
7 6 .. 0 0
resposta
sc = 5 x ss = 2 ackseq tamanho preto reservado

confirmação 7 .. 5 4 .. 2 1 .. 0 0 0 0
0 1 2 3 7
scs: especificador de comando do servidor

ss: subcomando do servidor
2: bloquear resposta de download
• c: indica se ainda há mais segmentos a serem baixados

0: mais segmentos a serem baixados
1: não há mais segmentos a serem baixados, entre na fase final de download do bloco SDO
seqno: número de sequência do segmento 0 < seqno < 128.
seg-data: no máximo 7 bytes de dados de segmento a serem baixados.
ackseq: número seqüencial do último segmento recebido com sucesso durante o último download do bloco. Se ackseq for
definido como 0, o servidor indica ao cliente que o segmento com o número de sequência 1 não foi recebido corretamente e
todos os segmentos devem ser retransmitidos pelo cliente.
• blksize: Número de segmentos por bloco que deve ser utilizado pelo cliente para o bloco seguinte
baixe com 0 < blksize < 128.

Figura 28: Sub-bloco de download do bloco SDO do protocolo

7.2.4.3.11 Fim do download do bloco SDO do protocolo
O protocolo conforme definido na Figura 29 deve ser usado para implementar o serviço final de download do bloco SDO.
ccs: especificador de comando do cliente

scs: especificador de comando do servidor

cs: subcomando cliente
1: solicitação de download do bloco final

ss: subcomando do servidor
1: resposta de download do bloco final
n: indica o número de bytes no último segmento do último bloco que não contém dados. Bytes [8-n, 7] não contêm dados de segmento.
crc: soma de verificação de redundância cíclica de 16 bits (CRC) para o conjunto de dados. O algoritmo para geração do CRC está descrito
na subcláusula 7.2.4.3.16. CRC só é válido se no bloco SDO iniciar o download cc e sc forem definidos como 1, caso contrário, CRC deve
ser definido como 0.
X: não usado, sempre 0
reservado: reservado para uso posterior, sempre 0

Figura 29: Fim do download do bloco SDO do protocolo

7.2.4.3.12 Carregamento de bloco de protocolo SDO
Upload de bloco SDO (normal) Upload de bloco SDO (fallback)

Iniciar upload do bloco SDO Iniciar upload do bloco SDO

(fase I) (fase I; pst != 0)
Iniciar upload do bloco SDO Voltar para

(Fase II) Protocolo de upload SDO
Sub-bloco de upload de bloco SDO
(normal)
Sub-bloco de upload de bloco SDO
(último)
Fim do upload do bloco SDO
Carregamento de bloco SDO Carregamento de bloco SDO

Cliente sub-bloco (normal) Servidor Cliente sub-bloco (último) Servidor
Carregar segmento Carregar segmento




(c = 0, sequência = n) (c = 1, sequência = n)
Confirmar bloqueio Confirmar bloqueio
Figura 30: Upload do bloco SDO do protocolo
Este protocolo (especificado na Figura 30) deve ser usado para implementar um serviço de upload de bloco SDO que começa com o
serviço de inicialização de upload de bloco SDO. O cliente pode indicar um valor limite para o servidor que é o valor mínimo em bytes
para aumentar o desempenho da transferência usando o protocolo de upload de bloco SDO em vez do protocolo de upload SDO. Se o
tamanho do conjunto de dados for menor ou igual a esse valor, o servidor poderá continuar com a transferência normal ou acelerada do
protocolo de upload de bloco SDO.
Caso contrário, os SDOs são carregados como uma sequência de serviços de sub-bloco de carregamento de bloco SDO. A sequência
de sub-blocos de upload de bloco SDO é encerrada por:
• Um segmento carregado dentro de um bloco com o c-bit definido como 1, indicando a conclusão do SDO
seqüência de sub-bloco de upload de bloco.
• UMA solicitação/indicação de transferência de aborto SDO está indicando a conclusão malsucedida do upload
seqüência.
O serviço de upload de bloco SDO é encerrado com o serviço final de upload de bloco SDO. Se tanto o cliente quanto o servidor tiverem
indicado a capacidade de gerar um CRC durante o serviço de inicialização do upload do bloco SDO, o cliente deverá gerar o CRC nos
dados recebidos. Se este CRC for diferente do CRC gerado pelo servidor, o cliente deverá indicá-lo com uma indicação SDO abort
transfer.

7.2.4.3.13 Início do upload do bloco SDO do protocolo
O protocolo conforme definido na Figura 31 deve ser usado para implementar o serviço de inicialização de upload de bloco SDO.
Se o valor do parâmetro de limite de troca de protocolo indicado pelo cliente na primeira solicitação for menor ou igual ao tamanho do
conjunto de dados a ser carregado, o servidor pode continuar com o carregamento do protocolo SDO conforme descrito na subcláusula
7.2.4.3.5.

5: bloquear upload
6: bloquear upload
0: iniciar solicitação de upload
3: iniciar envio
0: iniciar resposta de upload
• cc: suporte CRC do cliente
cc = 0: O cliente não suporta a geração de CRC nos dados
cc = 1: o cliente suporta a geração de CRC nos dados
• sc: suporte CRC do servidor

sc = 0: O servidor não suporta a geração de CRC nos dados
sc = 1: O servidor suporta a geração de CRC nos dados • pst: limite
de troca de protocolo em bytes para alterar o protocolo de transferência SDO
pst = 0: Mudança de protocolo de transferência não permitida. pst
> 0: Se o tamanho dos dados
servidor pode em bytes
mudar foromenor
para ou igual
protocolo SDOaupload
pst o transmitindo a resposta do servidor do protocolo SDO upload
conforme descrito na subcláusula 7.2.4.3.5.
size: tamanho do upload em bytes

s = 0: tamanho é reservado para uso posterior, sempre 0
s = 1: size contém o número de bytes a serem baixados
O byte 4 contém o lsb e o byte 7 o msb
• blksize: Número de segmentos por bloco com 0 < blksize < 128. • X: não usado, sempre
0
Figura 31: Início do upload do bloco SDO do protocolo

7.2.4.3.14 Sub-bloco de upload do bloco SDO do protocolo
O protocolo conforme definido na Figura 32 deve ser usado para implementar o serviço de sub-bloco de upload de bloco SDO.
Cliente Servidor
solicitar
0 1 7
indicação 7
7
c 6 ..sequência
0
6 .. 0
0
dados de segmento
0
7 6 .. 0 0
resposta
cc = 5 x cs = 2 ackseq tamanho preto reservado

7 .. 5 4 .. 2 1 .. 0 0 0 0
confirmação
0 1 2 3 7

5: bloquear upload
cs: subcomando cliente
2: bloquear resposta de upload
• c: indica se ainda há mais segmentos a serem baixados
0: mais segmentos a serem carregados
1: não há mais segmentos a serem carregados, entre na fase 'End block upload'
seqno: número de sequência do segmento 0 < seqno < 128.
• seg-data: no máximo 7 bytes de dados de segmento a serem carregados.
• ackseq: número seqüencial do último segmento recebido com sucesso durante o último upload do bloco. Se ackseq for definido como
0, o cliente indica ao servidor que o segmento com o número de sequência 1 não foi recebido corretamente e todos os segmentos
devem ser retransmitidos pelo servidor.
• blksize: Número de segmentos por bloco que deve ser usado pelo servidor para o seguinte upload de bloco com 0 < blksize < 128.

Figura 32: Sub-bloco de upload do bloco SDO do protocolo
7.2.4.3.15 Fim do upload do bloco SDO do protocolo
O protocolo conforme definido na Figura 33 deve ser usado para implementar o serviço final de upload do bloco SDO.

ccs: especificador de comando do cliente

5: bloquear upload

6: bloquear upload
1: solicitação de upload de bloco final

1: resposta de upload do bloco final
• n: indica o número de bytes no último segmento do último bloco que não contém dados.
Bytes [8-n, 7] não contêm dados de segmento.
crc: soma de verificação de redundância cíclica de 16 bits (CRC) do conjunto de dados. O algoritmo para geração do CRC está descrito na
cláusula 7.2.4.3.16. CRC só é válido se em SDO bloco upload iniciar cc e sc forem definidos como 1, caso contrário, crc deve ser definido
como 0.

Figura 33: Fim do upload do bloco SDO do protocolo
7.2.4.3.16 Algoritmo de cálculo CRC para verificar a transferência do bloco SDO
Para verificar a exatidão de um cliente e servidor de upload de bloco SDO e download de bloco SDO calculando um CRC que é trocado e
verificado durante o final do download do bloco SDO e o protocolo final do upload do bloco SDO. O CRC deve ter os seguintes parâmetros:
— Polinômio CRC: x16 + x12 + x5 + 1
— Largura do CRC: 16 bits
- valor inicial: 0000h
— Verificação CRC (resultado para CRC de 123456789): 31C3h

7.2.4.3.17 Protocolo SDO abortar transferência
O protocolo conforme definido na Figura 34 deve ser usado para implementar o serviço de transferência de aborto SDO.
Servidor cliente Servidor/Cliente
solicitar
cs = 4 x m d
7 .. 5 4 .. 0 0 0 indicação
0 134 7
• cs: especificador de comando
4: abortar solicitação de transferência
• X: não usado, sempre 0 • m:
multiplexador. Representa índice e sub-índice do SDO. • d: contém um código de aborto
de 4 bytes sobre o motivo do aborto.
Figura 34: Transferência de aborto do protocolo SDO
O código de aborto conforme definido na Tabela 22 é codificado como valor UNSIGNED32.
Tabela 22: Códigos de aborto SDO
Código de aborto Descrição
0503 0000h Bit de alternância não alternado.
0504 0000h O protocolo SDO expirou.
0504 0001h Especificador de comando cliente/servidor inválido ou desconhecido.
0504 0002h Tamanho de bloco inválido (somente modo de bloco).
0504 0003h Número de sequência inválido (somente modo de bloco).
0504 0004h Erro CRC (somente modo bloco).
0504 0005h Sem memória.
0601 0000h Acesso não suportado a um objeto.
0601 0001h Tentativa de ler um objeto somente de escrita.
0601 0002h Tentativa de gravar um objeto somente leitura.
0602 0000h O objeto não existe no dicionário de objetos.
0604 0041h O objeto não pode ser mapeado para o PDO.
0604 0042h O número e o comprimento dos objetos a serem mapeados excederiam o comprimento do PDO.
0604 0043h Motivo de incompatibilidade de parâmetros gerais.
0604 0047h Incompatibilidade geral interna no aparelho.
0606 0000h Falha no acesso devido a um erro de hardware.
0607 0010h O tipo de dados não corresponde, o parâmetro de duração do serviço não corresponde
0607 0012h O tipo de dados não corresponde, parâmetro de duração do serviço muito alto
0607 0013h O tipo de dados não corresponde, parâmetro de duração do serviço muito baixo
0609 0011h O subíndice não existe.

Código de aborto Descrição
0609 0030h Valor inválido para parâmetro (somente download).
0609 0031h Valor do parâmetro escrito muito alto (somente download).
0609 0032h Valor do parâmetro escrito muito baixo (somente download).
0609 0036h O valor máximo é menor que o valor mínimo.
060A 0023h Recurso não disponível: conexão SDO
0800 0000h Erro geral
0800 0020h Os dados não podem ser transferidos ou armazenados no aplicativo.
0800 0021h Os dados não podem ser transferidos ou armazenados no aplicativo devido ao controle local.
0800 0022h Os dados não podem ser transferidos ou armazenados no aplicativo devido ao estado atual do dispositivo.
0800 0023h A geração dinâmica do dicionário de objetos falha ou nenhum dicionário de objetos está presente (p.
dicionário de objetos é gerado a partir do arquivo e a geração falha devido a um erro de arquivo).
0800 0024h Sem dados disponíveis
Os códigos de aborto não listados devem ser reservados.
7.2.5 Objeto de sincronização (SYNC)
7.2.5.1 Geral
O produtor SYNC transmite o objeto de sincronização periodicamente. Este SYNC fornece o mecanismo básico de sincronização de
rede. O período de tempo entre os SYNCs é especificado pelo período do ciclo de comunicação do parâmetro padrão (ver subcláusula
7.5.2.6), que pode ser escrito por uma ferramenta de configuração nos dispositivos CANopen durante o processo de inicialização.
Pode haver um jitter de tempo na transmissão pelo produtor SYNC correspondendo aproximadamente à latência devido a alguma
outra mensagem sendo transmitida imediatamente antes do SYNC. O consumidor SYNC pode utilizar o período do ciclo de
comunicação específico do fabricante.
O contador de parâmetros opcional é usado para definir um relacionamento explícito entre o ciclo SYNC atual e a transmissão PDO
(consulte o valor inicial SYNC do parâmetro de comunicação PDO na subseção 7.5.2.37).
Para garantir o acesso oportuno à rede, o SYNC recebe um CAN-ID de altíssima prioridade (consulte a subcláusula 7.5.2.5).
Dispositivos CANopen que operam de forma síncrona podem usar o objeto SYNC para sincronizar seu próprio tempo com o do
produtor do objeto de sincronização. Os detalhes dessa sincronização são específicos do aplicativo e não se enquadram no escopo
desta especificação.
7.2.5.2 Serviços de SINCRONIZAÇÃO
7.2.5.2.1 Geral
A transmissão SYNC segue o modelo push produtor/consumidor conforme descrito na cláusula 4.4.4. O serviço não está confirmado.
Atributos:
- tipo de dados: NÃO ASSINADO8
7.2.5.2.2 Serviço de gravação SYNC
Para o serviço de gravação SYNC, o modelo push é válido. Há zero ou mais consumidores para SYNC. O SYNC tem exatamente um
produtor. O parâmetro para este serviço é definido na Tabela 23.
Através deste serviço o produtor do SYNC envia um evento de disparo ao(s) consumidor(es).


Tabela 23: Gravação do serviço SYNC
contador opcional
O serviço não está confirmado. O contador de parâmetros opcional deve ser incrementado em 1 a cada transmissão. O
valor máximo deve ser o valor atual conforme definido no valor de estouro do contador síncrono (ver subcláusula
7.5.2.22). Caso o valor máximo seja atingido, o contador deve ser ajustado para 1 na próxima transmissão. O valor
inicial do contador após a inicialização do serviço NMT deve ser 1. O valor do contador deve ser redefinido para 1 se o
dispositivo CANopen transitar do estado NMT parado para o estado NMT pré-operacional ou para o estado NMT
operacional .
7.2.5.3 Protocolo SYNC
7.2.5.3.1 Gravação do protocolo SYNC
Este protocolo conforme definido na Figura 35 deve ser usado para implementar o serviço SYNC write.
Produtor de SINCRONIZAÇÃO SINCRONIZAR consumidores
solicitar
Contador
indicação
0ÿLÿ1
indicação
indicação
• Contador: 1 byte de um contador

Figura 35: Gravação do protocolo SYNC
7.2.6 Objeto de carimbo de hora (TIME)
7.2.6.1 Geral
O produtor TIME transmite o objeto timestamp. Este TIME fornece o relógio de rede simples.
Pode haver um jitter de tempo na transmissão pelo produtor TIME correspondendo aproximadamente à latência devido
a alguma outra mensagem sendo transmitida imediatamente antes do TIME.
Para garantir o acesso oportuno à rede, o TIME recebe um CAN-ID de altíssima prioridade (ver subcláusula 7.5.2.15).
Dispositivos CANopen que operam um relógio local podem usar o objeto TIME para ajustar sua própria base de tempo
àquela do produtor do objeto time stamp. Os detalhes desse mecanismo são específicos da implementação e não se
enquadram no escopo desta especificação.
7.2.6.2 Serviços TIME
7.2.6.2.1 Geral
A transmissão do objeto time stamp segue o produtor/consumidor conforme descrito na subcláusula 4.4.4.
O serviço não está confirmado.
Atributos:

- tipo de dados: HORA DO DIA
7.2.6.2.2 Serviço de gravação de TEMPO
Para o serviço de gravação TIME, o modelo push é válido. Há zero ou mais consumidores de um TIME. A TIME tem
exatamente um produtor. O parâmetro para este serviço é definido na Tabela 24.
Através deste serviço o produtor de uma HORA envia a hora atual para o(s) consumidor(es).

Tabela 24: Gravação de TIME de serviço
7.2.6.3 Protocolo TIME
7.2.6.3.1 Gravação do protocolo TIME
Este protocolo conforme definido na Figura 36 deve ser utilizado para implementar o serviço TIME write.
TIME produtor TIME consumidores
solicitar
Carimbo de hora
indicação
0 5
indicação
indicação
• Carimbo de hora: 6 bytes do objeto de carimbo de hora

Figura 36: Gravação do protocolo TIME
7.2.7 Objeto de emergência (EMCY)
7.2.7.1 Uso de objetos de emergência
Objetos de emergência são acionados pela ocorrência de uma situação de erro interno do dispositivo CANopen e são transmitidos de
um produtor de emergência no dispositivo CANopen. Objetos de emergência são adequados para alertas de erro do tipo interrupção. Um
objeto de emergência é transmitido apenas uma vez por 'evento de erro'. Nenhum outro objeto de emergência deve ser transmitido desde
que não ocorram novos erros em um dispositivo CANopen.
Zero ou mais consumidores de emergência podem receber o objeto de emergência. A reação no(s) consumidor(es) de emergência não
é especificada e não se enquadra no escopo desta especificação.
Por meio desta especificação são especificadas as classes de códigos de erro de emergência (Tabela 25), os códigos de erro de
emergência (Tabela 26) e o registro de erro (ver subcláusula 7.5.2.2). Informações adicionais específicas do aplicativo no byte inferior do
código de erro de emergência e a condição de emergência não se enquadram no escopo desta especificação. Códigos de erro adicionais
são definidos por outras especificações de perfil.
Tabela 25: Classes de código de erro de emergência
Descrição do código de erro
00xxh Redefinição de erro ou nenhum erro
10xxh Erro genérico
20xxh Atual
21xxh Corrente, lado de entrada do dispositivo CANopen
22xxh Corrente dentro do dispositivo CANopen
23h Corrente, lado de saída do dispositivo CANopen
30xxh Tensão
31xxh Voltagem da rede

32xxh Tensão dentro do dispositivo CANopen
33xxh Voltagem de saída
40xxh Temperatura
41xxh Temperatura ambiente
42xxh Temperatura do dispositivo CANopen
50xxh Hardware do dispositivo CANopen
60xxh software do dispositivo CANopen
61xxh Software interno
62xxh Software do usuário
63xxh Conjunto de dados
70xxh Módulos adicionais
80xxh Monitoramento
81xxh Comunicação
82xxh Erro de protocolo
90xxh Erro externo
F0xxh Funções adicionais
FFxxh Dispositivo CANopen específico
Tabela 26: Códigos de erro de emergência
0000h Redefinição de erro ou nenhum erro
1000h Erro genérico
2000h Atual – erro genérico
21:00h Corrente, lado de entrada do dispositivo CANopen – genérico
22:00h Corrente dentro do dispositivo CANopen – genérico
23:00h Corrente, lado de saída do dispositivo CANopen – genérico
3000h Voltagem - erro genérico
31:00h Tensão de rede - genérico
32:00h Tensão dentro do dispositivo CANopen – genérico
3300h Tensão de saída - genérico
4000h Temperatura - erro genérico
41:00h Temperatura ambiente – genérico
4200h Temperatura do dispositivo – genérico
5000h Hardware do dispositivo CANopen – erro genérico
6000h Software do dispositivo CANopen – erro genérico

61:00h Software interno – genérico
6200h Software do usuário – genérico
6300h Conjunto de dados - genérico
7000h Módulos adicionais – erro genérico
8000h Monitoramento – erro genérico
81:00h Comunicação – genérico
8110h CAN ultrapassagem (objetos perdidos)
8120h CAN em modo passivo de erro
8130h Erro de salva-vidas ou erro de batimento cardíaco
8140h recuperado de ônibus
8150h Colisão CAN-ID
8200h Erro de protocolo - genérico
8210h PDO não processado devido a erro de comprimento
8220h Comprimento do PDO excedido
8230h DAM MPDO não processado, objeto de destino não disponível
8240h Comprimento de dados SYNC inesperado
8250h Tempo limite RPDO
9000h Erro externo – erro genérico
F000h Funções adicionais – erro genérico
FF00h Específico do dispositivo - erro genérico
O objeto de emergência é opcional. Se um dispositivo CANopen suporta o objeto de emergência, ele deve suportar pelo menos os dois
códigos de erro 0000h e 1000h. Todos os outros códigos de erro são opcionais.
Um dispositivo CANopen deve estar em um dos dois estados de emergência (Figura 37). Dependendo das transições, os objetos de
emergência devem ser transmitidos. As ligações entre a máquina de estado de erro e a máquina de estado NMT são definidas pelo objeto
1029h (ver subcláusula 7.5.2.32).
0. Após a inicialização, o dispositivo CANopen entra no estado livre de erros se nenhum erro for detectado. Não
mensagem de erro é enviada.
1. O dispositivo CANopen detecta um erro interno indicado nos três primeiros bytes do
mensagem de emergência (código de erro e registro de erro). O dispositivo CANopen entra no estado de erro. Um objeto
de emergência com o código de erro e registro de erro apropriados é transmitido.
O código de erro é preenchido na localização do objeto 1003h (campo de erro pré-definido).
2. Um, mas nem todos os motivos de erro desapareceram. Uma mensagem de emergência contendo o código de erro 0000h
(Error reset) pode ser transmitido juntamente com os erros restantes no registro de erros e no campo de erro específico do
fabricante.
3. Ocorre um novo erro no dispositivo CANopen. O dispositivo CANopen permanece em estado de erro e transmite um objeto de
emergência com o código de erro apropriado. O novo código de erro é preenchido no topo da matriz de códigos de erro (1003h).
Deve ser garantido que os códigos de erro sejam classificados em tempo hábil (erro mais antigo - subíndice mais alto, ver
objeto 1003h).
4. Todos os erros são reparados. O dispositivo CANopen entra no estado livre de erros e transmite um
objeto de emergência com o código de erro 'reset error/no error'.
5. Reinicie ou desligue.

Figura 37: Diagrama de transição do estado de emergência
7.2.7.2 Serviços de objetos de emergência
7.2.7.2.1 Geral
A transmissão do objeto emergencial segue o produtor/consumidor conforme descrito na subcláusula 4.4.4.

Os seguintes atributos de objeto são especificados para objetos de emergência:
- tipo de dados: ESTRUTURA DE

UNSIGNED16 Emergency_error_code,
UNSIGNED8 error_register,
ARRAY (5) de UNSIGNED8 fabricante_específico_erro_campo
7.2.7.2.2 Serviço de gravação EMCY
Para o serviço de gravação EMCY, o modelo push é válido. Há zero ou mais consumidores para EMCY.
EMCY tem exatamente um produtor. O parâmetro para este serviço é definido na Tabela 27.
Através deste serviço, o produtor do EMCY envia os dados de emergência atuais ao(s) consumidor(es).
Tabela 27: Gravação do serviço EMCY
7.2.7.3 Protocolo de objeto de emergência
7.2.7.3.1 Gravação do protocolo EMCY
Este protocolo conforme definido na Figura 38 deve ser usado para implementar o serviço de gravação EMCY.

Produtor EMCY consumidores EMCY
solicitar
eec é msef
indicação
0 123 7
indicação
indicação
• eec: código de erro de emergência (consulte a Tabela 26)
• er: registro de erro (ver objeto 1001h)
• msef: código de erro específico do fabricante

Figura 38: Gravação do protocolo EMCY
Um RTR não tem permissão para solicitar uma transmissão de emergência. Um RTR recebido não deve ser respondido.
7.2.8 Gerenciamento de rede
7.2.8.1 Geral
O gerenciamento de rede (NMT) é orientado a dispositivos CANopen e segue uma estrutura mestre-escravo.
Os objetos NMT são usados para executar serviços NMT. Através dos serviços NMT, os dispositivos CANopen são inicializados,
iniciados, monitorados, resetados ou parados. Todos os dispositivos CANopen são considerados escravos NMT. Um escravo NMT
é identificado exclusivamente na rede por seu node-ID, um valor na faixa de [1..127].
NMT requer que um dispositivo CANopen na rede cumpra a função do mestre NMT.
7.2.8.2 Serviços NMT
7.2.8.2.1 Serviços de controle de nós
7.2.8.2.1.1 Geral
Por meio de serviços de controle de nó, o mestre NMT controla o estado NMT dos escravos NMT. O atributo de estado NMT é um
dos valores {Parado, Pré-operacional, Operacional, Inicialização}. Os serviços de controle de nós podem ser executados com um
determinado dispositivo CANopen ou com todos os dispositivos CANopen simultaneamente. O mestre NMT controla sua própria
máquina de estado NMT por meio de serviços locais, que dependem da implementação. Os serviços de controle de nó podem ser
iniciados pelo aplicativo local.
7.2.8.2.1.2 Serviço iniciar nó remoto
O mestre NMT usa o nó remoto de início de serviço NMT para alterar o estado NMT dos escravos NMT selecionados. O novo estado
NMT deve ser o estado NMT operacional. Os parâmetros para este serviço são definidos na Tabela 28.
Tabela 28: Nó remoto de início de serviço
Parâmetro Indicação/ Solicitação
ID do nó seleção
Tudo seleção
O serviço é não confirmado e obrigatório.

7.2.8.2.1.3 Nó remoto de parada de serviço
O mestre NMT usa o nó remoto de parada de serviço NMT para alterar o estado NMT dos escravos NMT selecionados. O novo
estado NMT deve ser o estado NMT parado. Os parâmetros para este serviço são definidos na Tabela 29.
Tabela 29: Nó remoto de parada de serviço
Parâmetro Pedido/ Indicação
ID do nó seleção
Tudo seleção
7.2.8.2.1.4 Serviço entra pré-operacional
O mestre NMT usa o serviço NMT para entrar em pré-operacional para alterar o estado NMT dos escravos NMT selecionados. O novo
estado NMT deve ser o estado NMT pré-operacional. Os parâmetros para este serviço são definidos na Tabela 30.
Tabela 30: Entrada de serviço pré-operacional
ID do nó seleção
Tudo seleção
7.2.8.2.1.5 Nó de reinicialização de serviço
O mestre NMT usa o nó de reinicialização do serviço NMT para alterar o estado NMT dos escravos NMT selecionados. O novo estado
NMT deve ser o aplicativo de redefinição do subestado NMT. Os parâmetros para este serviço são definidos na Tabela 31.
Tabela 31: Nó de redefinição de serviço
ID do nó seleção
Tudo seleção
7.2.8.2.1.6 Comunicação de reset de serviço
O mestre NMT usa a comunicação de reinicialização do serviço NMT para alterar o estado NMT dos escravos NMT selecionados. O
novo estado NMT deve ser a comunicação de reinicialização do subestado NMT. Os parâmetros para este serviço são definidos na
Tabela 32.

Tabela 32: Comunicação de redefinição de serviço
ID do nó seleção
Tudo seleção
7.2.8.2.2 Serviços de controle de erros
Os serviços de controle de erros são usados para detectar falhas em uma rede baseada em CAN.
Erros locais em um dispositivo CANopen podem, por exemplo, levar a um reset ou mudança de estado. A definição desses erros locais
não se enquadra no escopo desta especificação.
Os serviços de controle de erros são realizados principalmente através da transmissão periódica de mensagens por um dispositivo
CANopen. Existem duas possibilidades para realizar o controle de erros.
A guarda é conseguida transmitindo pedidos de guarda (protocolo de guarda de nó) pelo mestre NMT. Se um escravo NMT não
respondeu dentro de um intervalo de tempo definido (tempo de vida do nó) ou se o status de comunicação do escravo NMT mudou, o
mestre NMT informa seu aplicativo mestre NMT sobre esse evento.
Se a proteção de vida (o escravo NMT protegendo o mestre NMT) for suportada, o escravo NMT usa o tempo de guarda e o fator de
tempo de vida de seu dicionário de objetos para determinar o tempo de vida do nó. Se o escravo NMT não for protegido durante seu
tempo de vida, o escravo NMT informará seu aplicativo local sobre esse evento. Se o tempo de guarda e o fator de tempo de vida forem
0 (valores padrão), o escravo NMT não protege o mestre NMT.
A guarda começa para o escravo NMT quando o primeiro RTR para seu CAN-ID de guarda é recebido. Isso pode ser durante a fase de
inicialização ou mais tarde.
O mecanismo de pulsação para um dispositivo CANopen é estabelecido pela transmissão cíclica da mensagem de pulsação pelo produtor
de pulsação. Um ou mais dispositivos CANopen na rede estão cientes desta mensagem de pulsação. Se o ciclo de pulsação falhar para
o produtor de pulsação, o aplicativo local no consumidor de pulsação será informado sobre esse evento.
A implementação de guarda ou pulsação é obrigatória.
OBSERVAÇÃO: Embora Heartbeat e Guarding estejam desabilitados por padrão, é recomendável usar mecanismos de controle de erros.
7.2.8.2.2.1 Evento de guarda do nó de serviço
Por meio deste serviço, o provedor de serviços NMT no mestre NMT indica que ocorreu um erro remoto ou foi resolvido para o dispositivo
CANopen remoto identificado pelo node-ID. Os parâmetros para este serviço são definidos na Tabela 33.
O evento resolvido é indicado
• quando após a ocorrência do evento com a mudança de estado de razão, o estado esperado é recebido, ou
• quando após o evento ocorreu com o motivo time out uma das indicações remotas subsequentes
está confirmado.

Tabela 33: Evento de proteção do nó de serviço
Parâmetro Indicação
ID do nó obrigatoriedade
Estado obrigatoriedade
Ocorreu seleção
Resolvido seleção
Razão opcional
Tempo esgotado seleção
seleção
Mudança de estado
O serviço é iniciado pelo provedor e opcional.
7.2.8.2.2.2 Evento de guarda de vida útil
Por meio desse serviço, o provedor de serviços NMT em um escravo NMT indica que ocorreu um erro remoto ou foi resolvido. Os
parâmetros para este serviço são definidos na Tabela 34.
O evento resolvido é indicado quando, após a ocorrência do evento, uma solicitação remota subsequente é recebida.
Tabela 34: Evento de proteção da vida útil
Estado obrigatoriedade
Ocorreu seleção
Resolvido seleção
O serviço é iniciado pelo provedor e opcional.
7.2.8.2.2.3 Evento de pulsação do serviço
Através deste serviço, o consumidor de heartbeat deverá indicar que ocorreu ou foi solucionado um erro de heartbeat ou ocorreu uma
mudança de estado NMT para o dispositivo CANopen identificado pelo node-ID.
O evento resolvido é indicado quando após a ocorrência do evento uma indicação remota subsequente é recebida.

Tabela 35: Evento de pulsação do serviço
ID do nó obrigatório
Estado obrigatório
Ocorreu seleção
Resolvido seleção
Razão obrigatoriedade
Tempo esgotado seleção
Mudança de estado seleção
O serviço é iniciado pelo consumidor e opcional.
7.2.8.2.3 Serviço de inicialização
7.2.8.2.3.1 Evento de inicialização do serviço
Através deste serviço, o escravo NMT indica que ocorreu uma transição de estado local do estado NMT Inicialização para o estado NMT
Pré-operacional. O parâmetro para este serviço é definido na Tabela 36.
Tabela 36: Evento de inicialização do serviço
Argumento Obrigatório
ID do nó obrigatório
O serviço é iniciado pelo provedor e obrigatório.
7.2.8.3 Protocolos NMT
7.2.8.3.1 Protocolos de controle de nós
7.2.8.3.1.1 Protocolo iniciar nó remoto
O protocolo conforme definido na Figura 39 deve ser usado para implementar o nó remoto de início de serviço NMT.
mestre NMT escravos NMT
solicitar CAN-ID = 0
cs = 1 ID do nó
indicação
0 1
indicação
indicação
cs: especificador de comando NMT

1: começar
Figura 39: Nó remoto de início de protocolo

7.2.8.3.1.2 Nó remoto de parada de protocolo
O protocolo conforme definido na Figura 40 deve ser usado para implementar o nó remoto de parada de serviço NMT.
cs = 2 ID do nó
indicação
0 1
indicação
indicação
2: parar
Figura 40: Nó remoto de parada de protocolo
7.2.8.3.1.3 Protocolo de entrada pré-operacional
O protocolo conforme definido na Figura 41 deve ser utilizado para implementar o serviço NMT no pré-operacional.
cs = 128 ID do nó
indicação
0 1
indicação
indicação
128: entrar pré-operacional

Figura 41: Protocolo de entrada pré-operacional
7.2.8.3.1.4 Nó de reset de protocolo
O protocolo conforme definido na Figura 42 deve ser usado para implementar o nó de reinicialização do serviço NMT.
cs = 129 ID do nó
indicação
0 1
indicação
indicação

129: redefinir nó
Figura 42: Nó de redefinição de protocolo

7.2.8.3.1.5 Comunicação de reset de protocolo
O protocolo conforme definido na Figura 43 deve ser usado para implementar a comunicação de reinicialização do serviço NMT.
cs = 130 ID do nó
indicação
0 1
indicação
indicação

130: redefinir comunicação
Figura 43: Comunicação de redefinição de protocolo
7.2.8.3.2 Protocolos de Controle de Erros
7.2.8.3.2.1 Proteção de nó de protocolo
O protocolo conforme definido na Figura 44 deve ser usado para detectar erros remotos na rede. Cada escravo NMT serve um RTR para
o protocolo de guarda de nó. Este protocolo implementa os serviços de controle de erros iniciados pelo provedor.

s: o estado do escravo NMT

4: Parou
5: Operacional
127: Pré-operacional
t: alternar bit. O valor deste bit deve alternar entre duas respostas consecutivas do escravo NMT. O valor do bit de
alternância da primeira resposta após o protocolo de proteção se tornar ativo deve ser 0. O bit de alternância no
protocolo de proteção deve ser redefinido para 0 quando a comunicação de redefinição do subestado NMT for
passada (nenhuma outra alteração do estado NMT redefine o bit de alternância). Se uma resposta for recebida
com o mesmo valor do bit de alternância da resposta anterior, a nova resposta será tratada como se não tivesse
sido recebida.
Figura 44: Proteção de nó de protocolo
O mestre NMT sonda cada escravo NMT em intervalos de tempo regulares. Este intervalo de tempo é chamado de
tempo de guarda e pode ser diferente para cada escravo NMT. A resposta do escravo NMT contém o estado NMT
desse escravo NMT. O tempo de vida do nó é dado pelo tempo de guarda multiplicado pelo fator de tempo de vida. O
tempo de vida do nó pode ser diferente para cada escravo NMT. Se o escravo NMT não tiver sido consultado durante
sua vida útil, um erro de nó remoto será indicado através do evento de proteção de vida de serviço NMT.
Um erro de nó remoto é indicado por meio do evento de proteção do nó de serviço NMT se
• O RTR não é confirmado dentro do tempo de vida do nó
• O estado escravo NMT relatado não corresponde ao estado esperado

Se tiver sido indicado que ocorreu um erro remoto e os erros no protocolo de proteção desapareceram, será indicado
que o erro remoto foi resolvido através do evento de proteção de nó de serviço NMT e do evento de proteção de vida
de serviço NMT.
Para o tempo de guarda e o fator de tempo de vida existem valores padrão especificados nos objetos apropriados do
dicionário de objetos.


7.2.8.3.2.2 Pulsação do protocolo
O protocolo de pulsação conforme definido na Figura 45 define um serviço de controle de erros sem necessidade de RTRs.
Um produtor de pulsação transmite uma mensagem de pulsação ciclicamente. Um ou mais consumidores de pulsação
recebem a indicação. A relação entre produtor e consumidor é configurável através do dicionário de objetos. O consumidor
de pulsação protege a recepção da pulsação dentro do tempo do consumidor de pulsação. Se a pulsação não for recebida
dentro do tempo do consumidor de pulsação, um evento de pulsação será gerado.
Batimento cardiaco Batimento cardiaco
produtor consumidores
solicitar CAN-ID = 1792 + Node-ID

r s
7 6 .. 0
0 indicação
batimentos
cardíacos
produtor
Tempo
de
do
indicação Tempo
solicitar indicação
Consumidor
batimentos
cardíacos
de
r s
7 6 .. 0
0 indicação
indicação Tempo
indicação
Consumidor
batimentos
cardíacos
de
Evento de pulsação
• r: reservado (sempre 0)
• s: o estado do produtor de batimentos cardíacos
0: Inicialização
4: Parou
5: Operacional
127: Pré-operacional
Figura 45: Pulsação do protocolo
Se o horário do produtor de pulsação estiver configurado em um dispositivo CANopen, o protocolo de pulsação será
iniciado imediatamente. Se um dispositivo CANopen iniciar com um valor para o tempo produtor de pulsação diferente de
0, o protocolo de pulsação inicia na transição do estado NMT Inicialização para o estado NMT Pré operacional. Neste caso,
a mensagem de inicialização é considerada como a primeira mensagem de pulsação. Não é permitido usar os dois
mecanismos de controle de erro que guardam o protocolo e o protocolo de pulsação em um escravo NMT ao mesmo
tempo. Se o tempo do produtor de pulsação for diferente de 0, o protocolo de pulsação será usado.

7.2.8.3.3 Inicialização do protocolo
O protocolo conforme definido na Figura 46 deve ser usado para sinalizar que um escravo NMT entrou no estado NMT Pré-operacional
após a inicialização do estado NMT. O protocolo usa o mesmo CAN-ID dos protocolos de controle de erros.
Produtor de inicialização Consumidor de inicialização
solicitar CAN-ID = 1792 + Node-ID
0
indicação
0
Um byte de dados é transmitido com valor 0.

Figura 46: Inicialização do protocolo
7.3 Inicialização da rede e inicialização do sistema
7.3.1 Inicialização NMT simplificada
Um exemplo de inicialização NMT simplificada é mostrado na Figura 47. A definição do processo de inicialização NMT não se enquadra
no escopo desta especificação.
Figura 47: Inicialização NMT simples
7.3.2 máquina de estado NMT
7.3.2.1 Visão geral
Na Figura 48 é especificado o diagrama de estado NMT de um dispositivo CANopen. Os dispositivos CANopen entram no estado NMT
Pré-operacional diretamente após terminar a inicialização dos dispositivos CANopen. Durante este estado NMT, é possível a
parametrização do dispositivo CANopen e a alocação de CAN-ID via SDO (por exemplo, usando uma ferramenta de configuração). Em
seguida, os dispositivos CANopen podem ser comutados diretamente para o estado NMT Operacional.
A máquina de estado NMT determina o comportamento da unidade de função de comunicação (ver subcláusula 4.3). O acoplamento da
máquina de estado de aplicação à máquina de estado NMT depende do dispositivo CANopen e se enquadra no escopo de perfis de
dispositivo e perfis de aplicação.

(1) Em Power on the NMT, a inicialização do estado é inserida de forma autônoma
(2) Estado NMT Inicialização concluída - entrar no estado NMT Pré-operacional automaticamente
(3) Serviço NMT inicia indicação de nó remoto ou por controle local
(4),(7) O serviço NMT entra na indicação pré-operacional
(5),(8) Indicação de nó remoto de parada de serviço NMT
(6) Indicação de nó remoto de início de serviço NMT
(9),(10),(11) Indicação do nó de reinicialização do serviço NMT
(12),(13),(14) Indicação de comunicação de reinicialização do serviço NMT
Figura 48: Diagrama de estado NMT de um dispositivo CANopen
7.3.2.2 estados NMT
7.3.2.2.1 Inicialização do estado NMT
A inicialização do estado NMT deve ser dividida em três subestados NMT (especificados na Figura 49) para permitir um reset completo
ou parcial de um dispositivo CANopen.
1. Inicializando: Este é o primeiro subestado NMT que o dispositivo CANopen entra após a inicialização ou reinicialização do hardware.
Depois de terminar a inicialização básica do dispositivo CANopen, o dispositivo CANopen entra de forma autônoma na aplicação de
reset de subestado NMT.
2. Aplicação de reset: Neste subestado NMT, os parâmetros da área de perfil específica do fabricante e da área de perfil do dispositivo
padronizado são ajustados para seus valores de inicialização. Após o ajuste dos valores de inicialização, a comunicação de
reinicialização do subestado NMT é inserida de forma autônoma.
3. Reinicializar a comunicação: Neste subestado NMT, os parâmetros da área do perfil de comunicação são ajustados para seus
valores de inicialização. Depois disso, a inicialização do estado NMT é concluída e o dispositivo CANopen executa a gravação de
inicialização do serviço NMT e entra no estado NMT Pré-operacional.
Os valores de inicialização são os últimos parâmetros armazenados. Se o armazenamento não for suportado ou não tiver sido executado
ou se a reinicialização for precedida pelo comando restaurar padrões (consulte a cláusula 7.5.2.14), os valores de inicialização são os
valores padrão de acordo com as especificações de comunicação e perfil do dispositivo.

(1)
Inicializando
(15)
Inicialização
Redefinir aplicativo
(16)
(11)
Redefinir comunicação (10)
(14) (9)
(2)
(13)
(12)
(1) Ao ligar a inicialização do estado NMT é inserida de forma autônoma
(2) Estado NMT Inicialização concluída - entrar no estado NMT Pré-operacional automaticamente
(12), (13), (14) Indicação de comunicação de reinicialização do serviço NMT
(9), (10), (11) Indicação do nó de reinicialização do serviço NMT
(15) Inicialização do subestado NMT concluída – o aplicativo de redefinição do subestado NMT é inserido de
forma autônoma
(16) A aplicação de redefinição de subestado NMT é concluída – a comunicação de redefinição de subestado

NMT é inserida de forma autônoma
Figura 49: Estrutura do estado NMT Inicialização
7.3.2.2.2 Estado NMT Pré-operacional
No estado NMT Pré-operacional, a comunicação via SDOs é possível. PDOs não existem, então a comunicação PDO não é permitida. A
configuração de PDOs, parâmetros e também a alocação de objetos de aplicação (mapeamento de PDO) pode ser realizada por um
aplicativo de configuração.
O dispositivo CANopen pode ser comutado para o estado NMT Operacional diretamente enviando o nó remoto de início de serviço NMT
ou por meio de controle local.
7.3.2.2.3 Estado NMT Operacional
No estado NMT Operacional todos os objetos de comunicação estão ativos. A transição para o estado NMT Operacional cria todos os
PDOs; o construtor usa os parâmetros conforme descrito no dicionário de objetos. O acesso ao dicionário de objetos via SDO é possível.
Aspectos de implementação ou a máquina de estado do aplicativo, no entanto, podem exigir a limitação do acesso a certos objetos
enquanto estiverem no estado NMT Operacional, por exemplo, um objeto pode conter o programa do aplicativo que não pode ser alterado
durante a execução.
7.3.2.2.4 Estado NMT Parado
Ao mudar um dispositivo CANopen para o estado NMT Stopped, ele é forçado a parar a comunicação completamente (exceto proteção
de nó e heartbeat, se ativo). Além disso, esse estado NMT pode ser usado para obter determinado comportamento do aplicativo. A
definição desse comportamento se enquadra no escopo de perfis de dispositivos e perfis de aplicativos.
Se houver mensagens EMCY acionadas neste estado NMT, elas estão pendentes. O motivo EMCY ativo mais recente pode ser
transmitido após o dispositivo CANopen transitar para outro estado NMT.
NOTA: O histórico de erros pode ser lido acessando o objeto 1003h, se implementado.


7.3.2.2.5 Estados NMT e relação de objeto de comunicação
A Tabela 37 especifica a relação entre estados NMT e objetos de comunicação. Os serviços nos objetos de
comunicação listados só podem ser executados se os dispositivos CANopen envolvidos na comunicação estiverem
nos estados NMT apropriados.
Tabela 37: Estados NMT e objetos de comunicação
Pré-operacional Operacional Parou
DOP X
SDO X X
SINCRONIZAR X X
TEMPO X X
EMCY X X
Controle de nós e
X X X
controle de erros
7.3.2.3 Transições de estado NMT
As transições de estado NMT são causadas por
• recepção de um serviço NMT usado para serviços de controle de nó,

• reinicialização de hardware, ou
• serviços de controle de nós iniciados localmente por eventos de aplicativos, definidos por perfis de dispositivos e
perfis de aplicativos
7.3.3 Conjunto de conexão predefinido genérico

A fim de reduzir o esforço de configuração para redes simples, um esquema de alocação CAN-ID é definido.
Esses CAN-IDs devem estar disponíveis no estado NMT Pré-operacional diretamente após a inicialização do
estado NMT (se nenhuma modificação tiver sido armazenada). Os objetos SYNC, TIME, EMCY write e PDO
podem ser apagados e recriados com novos CAN-IDs por meio de distribuição dinâmica. Um dispositivo CANopen
deve fornecer os CAN-IDs correspondentes apenas para os objetos de comunicação suportados.
O esquema de alocação CAN-ID (definido na Tabela 38 e Tabela 39) consiste em uma parte funcional, que
determina a prioridade do objeto e uma parte node-ID, que permite distinguir entre dispositivos CANopen da
mesma funcionalidade. Isso permite uma comunicação ponto a ponto entre um único dispositivo CANopen mestre
e até 127 dispositivos CANopen escravos NMT. Ele também suporta a transmissão de mensagens NMT, SYNC e
TIME não confirmadas. A transmissão é indicada por um node-ID de zero.
O conjunto de conexão predefinido genérico suporta um objeto de emergência, um SDO, no máximo 4 RPDOs e
4 TPDOs e os objetos NMT.
10 9 8 7 6 5 4 3 2 1 0
CAN-ID
Código de função ID do nó
MSB LSB
Figura 50: Esquema de alocação de CAN-ID para a conexão predefinida genérica

definir
A Tabela 38 e a Tabela 39 mostram os objetos suportados e seus CAN-IDs alocados.

Tabela 38: Objetos de transmissão do conjunto de conexão predefinido genérico
Código de
COB CAN-ID resultante
função
NMT 0000b 0 (000h)

SINCRONIZAR 0001b 128 (080h)
TEMPO
0010b 256 (100h)
Tabela 39: Objetos ponto a ponto do conjunto de conexão predefinido genérico
Código de
COB função
CAN-IDs resultantes
EMCY 0001b 129 (081h) - 255 (0FFh)

PDO1 (tx) 0011b 385 (181h) - 511 (1FFh)
PDO1 (rx) 0100b 513 (201h) - 639 (27Fh)
PDO2 (tx) 0101b 641 (281h) - 767 (2FFh)
PDO2 (rx) 0110b 769 (301h) - 895 (37Fh)
PDO3 (tx) 0111b 897 (381h) - 1023 (3FFh)
PDO3 (rx) 1000b 1025 (401h) - 1151 (47Fh)
PDO4 (tx) 1001b 1153 (481h) - 1279 (4FFh)
PDO4 (rx) 1010b 1281 (501h) - 1407 (57Fh)
SDO (tx) 1011b 1409 (581h) - 1535 (5FFh)
SDO (rx) 1100b 1537 (601h) - 1663 (67Fh)
Controle de erro NMT 1110b 1793 (701h) – 1919 (77Fh)
A Tabela 39 é vista do ponto de vista dos dispositivos CANopen.

O conjunto de conexão predefinido genérico sempre se aplica ao quadro base CAN com CAN-ID de 11 bits, mesmo se quadros
estendidos CAN estiverem presentes na rede.
O conjunto genérico de conexões pré-definidas deve ser aplicado para todos os dispositivos CANopen que seguem um
determinado perfil de dispositivo e não seguem nenhum perfil de aplicação.
7.3.4 Conjunto de conexão predefinido específico
O conjunto de conexão predefinido específico deve substituir o conjunto de conexão predefinido genérico para dispositivos
CANopen que seguem um perfil de aplicação. A definição do conjunto de conexão pré-definido específico não se enquadra no
escopo desta especificação; ele se enquadra no escopo do perfil de aplicativo apropriado.
7.3.5 CAN-IDs restritos
Qualquer CAN-ID listado na Tabela 40 é de uso restrito. Esse CAN-ID restrito não deve ser usado como CAN-ID por nenhum
objeto de comunicação configurável, nem para SYNC, TIME, EMCY, PDO e SDO.


Tabela 40: CAN-IDs restritos
CAN-ID usado por COB
0 (000h) NMT
1 (001h) - 127 (07Fh) reservado
257 (101h) – 384 (180h) reservado
1409 (581h) - 1535 (5FFh) SDO padrão (tx)
1537 (601h) - 1663 (67Fh) SDO padrão (rx)
1760 (6E0h) – 1791 (6FFh) reservado
1793 (701h) – 1919 (77Fh) Controle de erros NMT
2020 (780h) – 2047 (7FFh) reservado
7.4 Dicionário de objetos
7.4.1 Estrutura geral
O layout geral do dicionário de objetos padrão é especificado na Tabela 41.
Tabela 41: Estrutura do dicionário de objetos
Índice Objeto
0000h não usado
0001h – 001Fh Tipos de dados estáticos
0020h – 003Fh Tipos de dados complexos
0040h – 005Fh Tipos de dados complexos específicos do fabricante
0060h – 025Fh Tipos de dados específicos do perfil do dispositivo
0260h – 03FFh reservado
0400h – 0FFFh reservado
1000h – 1FFFh Área de perfil de comunicação
2000h – 5FFFh Área de perfil específica do fabricante
6000h – 67FFh Área de perfil padronizada 1º dispositivo lógico
6800h – 6FFFh Área de perfil padronizada 2º dispositivo lógico
A000h – AFFFh Área variável de rede padronizada
B000h – BFFFh Área variável de sistema padronizada
C000h – FFFFh reservado

O dicionário de objetos contém no máximo 65.536 objetos que devem ser endereçados por meio de um índice de 16 bits e até
256 subíndices por objeto, que devem ser endereçados por meio de um subíndice de 8 bits.
Os tipos de dados estáticos em índices de 0001h a 001Fh devem conter definições de tipo para tipos de dados padrão como
BOOLEAN, INTEGER, UNSIGNED, ponto flutuante, string, etc.
Tipos de dados complexos em índices de 0020h a 003Fh devem ser estruturas pré-definidas que são compostas por tipos de
dados padrão e são comuns a todos os dispositivos CANopen.
Tipos de dados complexos específicos do fabricante em índices de 0040h a 005Fh devem ser estruturas compostas de tipos
de dados padrão, mas são específicos para um determinado dispositivo CANopen.
Os perfis de dispositivo podem definir tipos de dados adicionais específicos para seu tipo de dispositivo. Os tipos de dados
estáticos e os tipos de dados complexos definidos pelo perfil do dispositivo devem ser listados em índices de 0060h a 025Fh.
Um dispositivo CANopen pode opcionalmente fornecer a estrutura dos tipos de dados complexos suportados (índices
de 0020h a 005Fh e de 0060h a 025Fh) no acesso de leitura ao índice correspondente. O subíndice 0 deve fornecer o subíndice
mais alto suportado neste índice, e os seguintes subíndices devem conter o tipo de dados codificado como UNSIGNED16 de
acordo com a Tabela 44.
A área do perfil de comunicação nos índices de 1000h a 1FFFh deverá conter os parâmetros específicos de comunicação.
Esses objetos são comuns a todos os dispositivos CANopen.
A área de perfil padronizada nos índices de 6000h a 9FFFh deve conter todos os objetos de dados comuns a uma classe de
dispositivos CANopen que podem ser lidos ou escritos via rede. Os perfis de dispositivos podem usar objetos de 6000h a
9FFFh para descrever parâmetros e funcionalidades.
O conceito de dicionário de objetos atende a recursos opcionais, o que significa que um fabricante pode não fornecer certas
funcionalidades estendidas em seus dispositivos CANopen, mas se desejar fazê-lo, deve fazê-lo de maneira pré-definida. O
espaço é deixado no dicionário de objetos em índices de 2000h a 5FFFh para uma funcionalidade verdadeiramente específica
do fabricante.
As variáveis de rede nos índices de A000h a AFFFh devem conter variáveis de entrada e variáveis de saída, que fazem parte
de um dispositivo CANopen programável. A definição dessas variáveis de rede não se enquadra no escopo deste documento
e fazem parte de perfis e frameworks futuros.
As variáveis do sistema nos índices de B000h a BFFFh devem conter variáveis de entrada e saída
variáveis, que fazem parte de uma rede CANopen subjacente em um sentido hierárquico. A definição dessas variáveis de
sistema não se enquadra no escopo deste documento e fazem parte de perfis e frameworks futuros.
7.4.2 Uso de índice e subíndice
Um índice de 16 bits é usado para endereçar todos os objetos dentro do dicionário de objetos. No caso de uma variável
simples, o índice referencia o valor dessa variável diretamente. No caso de registros e arrays, no entanto, o índice aborda toda
a estrutura de dados.
Para permitir que elementos individuais de estruturas de dados sejam acessados através da rede, um subíndice é definido.
Para objetos de dicionário de objeto único, como UNSIGNED8, BOOLEAN, INTEGER32 etc., o valor do subíndice é sempre
00h. Para objetos de dicionário de objetos complexos, como matrizes ou registros com vários campos de dados, o subíndice
faz referência a campos dentro de uma estrutura de dados apontada pelo índice principal. Os campos acessados pelo subíndice
podem ser de diferentes tipos de dados.

7.4.3 Uso do código objeto
O código do objeto deve denotar que tipo de objeto está naquele índice específico dentro do dicionário de objetos.
As seguintes definições são usadas:
Tabela 42: Definições de objetos do Dicionário de Objetos
Comentários
Nome do objeto Código
do objeto
NULO Um objeto sem campos de dados 00h
DOMÍNIO Grande quantidade variável de dados, por 02h

exemplo, código de programa executável
DEFTYPE Denota uma definição de tipo, como um 05h

BOOLEAN, UNSIGNED16, FLOAT
e assim por diante
DESTRUIR Define um novo tipo de registro, por exemplo, 06h

a estrutura de mapeamento PDO às 21h
FOI Um único valor, como UNSIGNED8, 07h

BOOLEAN, FLOAT, INTEGER16, VISIBLE
STRING etc.
VARIEDADE Um objeto de campo de dados múltiplo em 08h

que cada campo de dados é uma variável simples
do MESMO tipo de dados básico, por exemplo,
matriz de UNSIGNED16 etc. O subíndice 0 é de
UNSIGNED8 e, portanto, não faz parte dos dados
ARRAY
REGISTRO Um objeto de campo de dados múltiplos em que 09h

os campos de dados podem ser qualquer
combinação de variáveis simples. O sub-índice 0 é
de UNSIGNED8 e o sub-índice 255 é de
UNSIGNED32 e, portanto, não faz parte dos dados
RECORD
7.4.4 Uso do tipo de dados
As informações de tipo de dados de um objeto incluem os seguintes tipos predefinidos: BOOLEAN, FLOAT, UNSIGNED, INTEGER,
VISIBLE/OCTET STRING, TIME_OF_DAY, TIME_DIFFERENCE e DOMAIN (ver subcláusula 7.1). Ele também inclui o mapeamento PDO
de tipo de dados complexo predefinido e também pode incluir outros que são específicos do fabricante, específicos do perfil do dispositivo
ou específicos do perfil do aplicativo. Não é possível definir registros de registros, matrizes de registros ou registros com matrizes como
campos desse registro. No caso de um objeto ser um array ou um registro, o subíndice é usado para referenciar um campo de dados
dentro do objeto.

7.4.5 Uso de acesso
O Atributo define os direitos de acesso para um determinado objeto. O ponto de vista é da rede para o dispositivo CANopen.
Deve ser um dos seguintes:
Tabela 43: Atributos de acesso para objetos de dados
Descrição
Atributo
rw acesso de leitura e gravação
Onde acesso somente gravação
ro acesso somente leitura
const acesso somente leitura, o valor é constante

O valor pode mudar na inicialização do estado NMT.
O valor não deve mudar nos estados NMT pré-operação,
operacional e parado.
7.4.6 Uso de categoria e categoria de entrada
A categoria e a categoria de entrada definem se o objeto é obrigatório, opcional ou condicional. Um objeto obrigatório deve ser
implementado em um dispositivo CANopen. Um objeto opcional pode ser implementado em um dispositivo CANopen. O suporte
de determinados objetos ou recursos, no entanto, pode exigir a implementação de objetos relacionados. Neste caso, as relações
são descritas na especificação detalhada do objeto e o objeto é definido como um objeto condicional.
7.4.7 Uso de entrada de tipo de dados
7.4.7.1 Geral
Os tipos de dados estáticos são colocados no dicionário de objetos apenas para fins de definição. Índices na faixa de 0001h a
0007h, 0010h, de 0012h a 0016h e de 0018h a 001Bh podem ser mapeados para definir o espaço apropriado no RPDO como
não sendo utilizado por este dispositivo CANopen (não importa). Outros objetos do código de objeto DEFTYPE e DEFSTRUCT
não devem ser mapeados em RPDOs.
A ordem dos tipos de dados é a seguinte:
Tabela 44: Tipos de dados do dicionário de objetos
Objeto Nome
Índice
0001h DEFTYPE BOOLEAN
0002h DEFTYPE INTEGER8
0005h DEFTYPE NÃO ASSINADO 8
0008h DEFTYPE REAL32
0009h DEFTYPE VISIBLE_STRING
000Ah DEFTYPE OCTET_STRING
000Bh DEFTYPE UNICODE_STRING

Objeto Nome
Índice
000 canais DEFTYPE TIME_OF_DAY
000 Dh DEFTYPE TIME_DIFFERENCE
000Eh reservado
000Fh DEFTYPE DOMÍNIO
0010h DEFTYPE INTEGER 24
0011h DEFTYPE REAL64
0017h reservado
001Ah DEFTYPE NÃO ASSINADO 56
001Bh DEFTYPE NÃO ASSINADO 64
001Ch – 001Fh reservado
0020h DESSTRUCTAR PDO_COMMUNICATION_PARAMETER
0021h DEFSTRUCT PDO_MAPPING
0022h DEFSTRUCT SDO_PARAMETER
0023h DESTRUIR IDENTIDADE
0024h – 003Fh reservado
0040h – 005Fh DEFSTRUCT Tipos de dados complexos específicos do fabricante
0060h – 007Fh DEFTYPE Perfil de dispositivo específico Tipos de dados padrão 1º dispositivo lógico
0080h – 009Fh DEFSTRUCT Perfil de dispositivo específico Tipos de dados complexos 1º dispositivo lógico
00A0h – 00BFh DEFTYPE Perfil de dispositivo específico Tipos de dados padrão 2º dispositivo lógico
00C0h – 00DFh DEFSTRUCT Perfil de dispositivo específico Tipos de dados complexos 2º dispositivo lógico
00E0h – 00FFh DEFTYPE Perfil de dispositivo específico Tipos de dados padrão 3º dispositivo lógico
01A0h – 01BFh DEFTYPE Perfil de dispositivo específico Tipos de dados padrão 6º dispositivo lógico

Objeto Nome
Índice
01C0h – 01DFh DEFSTRUCT Perfil de dispositivo específico Tipos de dados complexos 6º dispositivo lógico
01E0h – 01FFh DEFTYPE Perfil de dispositivo específico Tipos de dados padrão 7º dispositivo lógico
As representações de tipos de dados utilizadas são detalhadas na subcláusula 7.1. Cada dispositivo CANopen não precisa suportar todos
os tipos de dados definidos. Um dispositivo CANopen só pode suportar os tipos de dados que usa com os objetos na faixa de 1000h a
AFFFh.
Os tipos de dados complexos predefinidos são colocados após os tipos de dados padrão. Esses tipos de dados complexos predefinidos
são definidos na subcláusula 7.4.8.
Um dispositivo CANopen pode opcionalmente fornecer o comprimento dos tipos de dados padrão codificados como UNSIGNED32 no
acesso de leitura à entrada do objeto que se refere ao tipo de dados. Por exemplo, índice 000Ch
(TIME_OF_DAY) contém o valor 0000 0030h = 48d , pois o tipo de dados TIME_OF_DAY é codificado usando uma sequência de bits de
48 bits. Se o comprimento for variável (por exemplo, 000Fh = Domínio), a entrada do objeto contém 0000 0000h.
Para os tipos de dados complexos suportados, um dispositivo CANopen pode opcionalmente fornecer a estrutura desse tipo de dados no
acesso de leitura ao índice de tipo de dados correspondente. O subíndice 00h fornece o subíndice mais alto suportado neste índice sem
contar os subíndices 00h e FFh e os seguintes subíndices contêm o tipo de dados de acordo com a Tabela 44 codificado como
UNSIGNED16 (UNSIGNED8 é usado por implementações antigas). O objeto no índice 0020h que descreve a estrutura do parâmetro de
comunicação PDO tem a seguinte aparência (veja também objetos de 1400h a 15FFh):
Tabela 45: exemplo de tipo de dados complexo
Valor do Subíndice (Descrição)
00h 04h (seguindo 4 subíndices)
01h 0007h (SEM ASSINADO32)
02h 0005h (NÃO ASSINADO8)
03h 0006h (SEM ASSINADO16)
04h 0005h (NÃO ASSINADO8)
Tipos de dados específicos do fabricante padrão (simples) e complexos podem ser distinguidos ao tentar ler o subíndice 01h: Em um tipo
de dado complexo, o dispositivo retorna um valor e o subíndice 00h contém o número de subíndices que seguem, em um tipo de dados
padrão o dispositivo aborta a transferência SDO como nenhum sub-índice 01h disponível.
Observe que algumas entradas de objetos do tipo de dados UNSIGNED32 têm o caráter de uma estrutura (por exemplo, PDO COB-ID,
veja a Figura 67).

7.4.7.2 Organização das entradas do dicionário de objetos estruturados
Se um objeto de dicionário de objetos contém vários subíndices, então o subíndice 00h descreve o maior subíndice disponível que
segue, sem considerar FFh. Esta entrada de objeto é codificada como UNSIGNED8.
O subíndice FFh descreve a estrutura do objeto fornecendo o tipo de dados e o tipo de objeto do objeto. Está codificado como
UNSIGNED32 e organizado da seguinte forma:
31 24 23 16 15 8 7 0
Tipo de dados Código do objeto

reservado (ver Tabela 44) (ver Tabela 42)
(00h)
Não assinado16 Não assinado8
MSB LSB
Figura 51: Subíndice de estrutura FFh
É opcional suportar o subíndice FFh. Se for suportado em todo o dicionário de objetos e a estrutura dos tipos de dados complexos
também for fornecida, permite carregar toda a estrutura do dicionário de objetos.
7.4.8 Especificação de tipos de dados complexos predefinidos
Esta seção descreve a estrutura dos tipos de dados complexos predefinidos usados para comunicação.
A faixa de valores e o significado são explicados na descrição detalhada dos objetos que utilizam esses tipos.
7.4.8.1 Especificação de registro de parâmetro de comunicação PDO
A Tabela 46 especifica o registro do parâmetro de comunicação PDO.
Tabela 46: Registro de parâmetro de comunicação PDO
Nome do subíndice do índice Tipo de dados
0020h 00h O subíndice mais alto suportado NÃO ASSINADO8
01h COB-ID NÃO ASSINADO32
02h Tipo de transmissão NÃO ASSINADO8
03h Tempo de inibição NÃO ASSINADO 16
04h reservado NÃO ASSINADO8
05h Temporizador de eventos NÃO ASSINADO 16
06h Valor inicial de SINCRONIZAÇÃO NÃO ASSINADO8
7.4.8.2 Especificação de registro de parâmetro de mapeamento PDO
A Tabela 47 especifica o registro do parâmetro de mapeamento do PDO.
Tabela 47: Registro de parâmetro de mapeamento PDO
Nome
Índice Sub-índice
Tipo de dados
00h Número de objetos mapeados no PDO NÃO ASSINADO8

0021h
01h 1º objeto a ser mapeado NÃO ASSINADO32
: :: :: : :: :: :: : : :: :: ::

7.4.8.3 Especificação de registro de parâmetro SDO
A Tabela 48 especifica o registro do parâmetro SDO.
Tabela 48: Registro de parâmetro SDO
Nome
Índice Sub-índice
Tipo de dados
01h Cliente COB-ID -> servidor NÃO ASSINADO32
02h Servidor COB-ID -> cliente NÃO ASSINADO32
03h Node-ID do cliente do SDO resp. servidor NÃO ASSINADO8
7.4.8.4 Especificação do registro de identidade
A Tabela 49 especifica o registro de identidade.
Tabela 49: Registro de identidade
01h ID do fornecedor NÃO ASSINADO32
02h Código do produto NÃO ASSINADO32
03h Número de revisão NÃO ASSINADO32
04h Número de série NÃO ASSINADO32
7.4.8.5 Especificação do registro de depuração do SO
A Tabela 50 especifica o registro de depuração do SO.
Tabela 50: registro de depuração do SO
01h Comando OCTET_STRING
02h Status
NÃO ASSINADO8
00h - Comando concluído - sem erro
01h - Comando concluído - erro
02h - reservado
: ::::
FEh - reservado
FFh - Comando em execução
03h Responder OCTET_STRING

7.4.8.6 Especificação de registro de comando do SO
A Tabela 51 especifica o registro de comando do SO.
Tabela 51: registro de comando do SO
01h Comando OCTET_STRING
02h Status
NÃO ASSINADO8
00h - Comando concluído – sem erro – sem resposta
01h - Comando concluído – sem erro – resposta
02h - Comando concluído – erro – sem resposta
03h - Comando concluído – erro – resposta
04h - reservado
: :: ::
FEh - reservado
FFh - Comando em execução
03h Responder OCTET_STRING
7.5 Especificação do perfil de comunicação
7.5.1 Especificação de descrição de objeto e entrada
A estrutura das entradas de objeto do dicionário de objetos é descrita da seguinte maneira: Todos os perfis de dispositivo, perfis de
interface e perfis de aplicativo baseados neste perfil de comunicação usam a descrição de objeto e entrada conforme especificado na
Tabela 52 e na Tabela 53.
Tabela 52: Formato de uma descrição de objeto
DESCRIÇÃO DO OBJETO
Índice Número de índice do perfil
Nome Nome do parâmetro
Código do objeto Classificação variável
Tipo de dados Classificação do tipo de dados
Categoria Opcional ou Obrigatório
O código do objeto deve ser um daqueles definidos na descrição do objeto Tabela 52 acima. Para melhor legibilidade, a descrição do
objeto contém adicionalmente o nome simbólico do objeto.

Tabela 53: Formato de descrição do valor do objeto
DESCRIÇÃO DA ENTRADA
Sub-índice Número do sub-descrito
Descrição Nome descritivo do subíndice (campo usado apenas para arrays, registros e
estruturas)
Tipo de dados Classificação do tipo de dados (campo usado apenas para registros e estruturas)
Categoria de entrada Especifica se a entrada do objeto é opcional ou obrigatória ou condicional caso o objeto
esteja presente
Acesso Somente leitura (ro) ou leitura/gravação (rw) ou somente gravação (wo) ou const
Mapeamento PDO Deve definir se este objeto deve ser mapeado para um PDO. Descrição:
Opcional: O objeto pode ser mapeado em um PDO
Padrão: O objeto faz parte do mapeamento padrão (consulte o perfil do dispositivo ou

perfil do aplicativo)
TPDO: O objeto pode ser mapeado em um TPDO e não deve ser mapeado em um
RPDO
RPDO: O objeto pode ser mapeado em um RPDO e não deve ser mapeado em um
TPDO
Não: O objeto não deve ser mapeado em um PDO
Faixa de valor intervalo de valores possíveis ou nome do tipo de dados para intervalo completo
Valor padrão Não: nenhum valor padrão aplicável.
Específico do perfil: valor padrão de um objeto deve ser definido em um perfil.
Específico do fabricante: o valor padrão de um objeto deve ser definido pelo fabricante do
dispositivo CANopen.
Valor valor padrão de um objeto após a inicialização do

dispositivo CANopen
Para variáveis simples, a definição de valor aparece uma vez sem categoria de entrada. Para tipos de dados complexos, a definição de Valor
deve ser definida para cada elemento (sub-índice).
7.5.2 Especificação detalhada de objetos específicos do perfil de comunicação
7.5.2.1 Objeto 1000h: Tipo de dispositivo
Este objeto deve fornecer informações sobre o tipo de dispositivo. O objeto descreve o tipo do dispositivo lógico e sua funcionalidade. Deve
ser composto por um campo de 16 bits que descreve o perfil do dispositivo ou o perfil do aplicativo que é usado e um segundo campo de 16
bits, que fornece informações adicionais sobre a funcionalidade opcional do dispositivo lógico. O parâmetro de informações adicionais é
específico do perfil do dispositivo e específico do perfil do aplicativo. Sua especificação não se enquadra no escopo desta especificação; ele
é definido no perfil do dispositivo e no perfil do aplicativo apropriados.
DEFINIÇÃO DE VALOR
O valor 0000h para o número do perfil do dispositivo deve indicar um dispositivo lógico que não segue um perfil padronizado. Neste
caso, a informação adicional deve ser 0000h (se nenhum outro dispositivo lógico for implementado) ou FFFFh (se um outro dispositivo
lógico for implementado).
Para módulos de dispositivos lógicos múltiplos, o parâmetro de informação adicional deve ser FFFFh e o número do perfil do dispositivo
referenciado pelo objeto 1000h deve ser o perfil do primeiro dispositivo lógico no dicionário de objetos. Todos os outros perfis de um
módulo de dispositivo lógico múltiplo devem identificar seus perfis nos objetos 67FFh + x 800h com x = número interno do dispositivo
*
lógico (de 1 a 8) menos 1. Esses objetos devem
de valor
descrever
do objeto
o tipo
1000h.
de dispositivo do dispositivo lógico anterior, tendo a mesma definição

32 16 15 0
Informação adicional Número do perfil do dispositivo
MSB LSB
Figura 52: Estrutura do parâmetro do tipo de dispositivo
Índice 1000h
Nome Tipo de dispositivo
Código do objeto FOI
Tipo de dados NÃO ASSINADO32
Categoria Obrigatoriedade
Sub-índice 00h
Acesso ro
Mapeamento PDO Não
Faixa de valor Ver definição de valor
Valor padrão Perfil específico ou fabricante
7.5.2.2 Objeto 1001h: Registro de erros
Este objeto deve fornecer informações de erro. O dispositivo CANopen mapeia erros internos neste objeto. É uma parte de um
objeto de emergência.
Tabela 54: Estrutura do registro de erros
Significado do Bit M/O
0 M Erro genérico
1 O Corrente
Tensão de 2 O
3O Temperatura
4 O Erro de comunicação (superação, estado de erro)
5 O específico do perfil do dispositivo
6 O reservado (sempre 0b)
7 O específico do fabricante
Se ocorrer um erro específico, o bit correspondente deve ser definido como 1b. O bit de erro genérico deve ser suportado. Os
outros bits podem ser suportados. O erro genérico deve ser sinalizado em qualquer situação de erro.

Índice 1001h
Nome Registro de erros
FOI
Código do objeto
Sub-índice 00h
Acesso ro
Mapeamento PDO Opcional
Valor padrão Não
7.5.2.3 Objeto 1002h: Registro de status do fabricante
Este objeto deve fornecer um registro de status comum para fins específicos do fabricante. Nesta especificação apenas o tamanho e a
localização deste objeto são definidos.
Índice 1002h
Nome
Registro de status do fabricante
Categoria Opcional
Sub-índice 00h
Acesso ro
Faixa de valor NÃO ASSINADO32
Valor padrão Não
7.5.2.4 Objeto 1003h: Campo de erro predefinido
Este objeto deve fornecer os erros ocorridos no dispositivo CANopen e que foram sinalizados através do objeto de emergência. Ao fazer
isso, ele fornece um histórico de erros.
• A entrada do objeto no subíndice 00h deve conter o número de erros reais que são registrados em
a matriz começando no sub-índice 01h.
NOTA: Se nenhum erro estiver presente, o valor do subíndice 00h é 00h e um acesso de leitura ao subíndice 01h é respondido
com uma mensagem de aborto SDO (código de cancelamento: 0800 0024h ou 0800 0000h).
• Cada novo erro deve ser armazenado no subíndice 01h; erros mais antigos devem ser movidos para o próximo
sub-índice superior.
• Gravar 00h no subíndice 00h excluirá todo o histórico de erros (esvazia o array). Outros valores além de 00h não são permitidos e
devem levar a uma mensagem de aborto (código de erro: 0609 0030h).

• Os números de erro são do tipo UNSIGNED32 (consulte a Tabela 26) e são compostos por um código de erro de 16 bits e um campo
de informações de erro adicional de 16 bits, específico do fabricante. O código de erro deve estar contido nos 2 bytes inferiores
(LSB) e as informações adicionais devem ser incluídas nos 2 bytes superiores (MSB). Se este objeto for suportado, deve consistir
em pelo menos duas entradas de objeto. A entrada de comprimento no subíndice 00h e pelo menos uma entrada de erro no
subíndice 01h.
32 16 15 0
Informação adicional Erro de código
MSB LSB
Figura 53: Estrutura do campo de erro pré-definido
Índice 1003h
Nome Campo de erro predefinido
Código do objeto VARIEDADE
Categoria Opcional
Sub-índice 00h
Descrição Número de erros
Categoria de entrada Obrigatoriedade
Acesso rw
Mapeamento PDO Não
Faixa de valor 00h a FEh
Valor padrão 00h
Sub-índice 01h
Descrição Campo de erro padrão
Acesso ro
Mapeamento PDO Não
Valor padrão Não

Sub-índice 02h a FEh
Descrição Campo de erro padrão
Categoria de entrada Opcional
Acesso ro
Mapeamento PDO Não
Valor padrão Não
7.5.2.5 Objeto 1005h: mensagem COB-ID SYNC
Este objeto deve indicar o COB-ID configurado do objeto de sincronização (SYNC). Além disso, define se o dispositivo CANopen
gera o SYNC. A estrutura deste objeto é especificada na Figura 54 e na Tabela 55.
31 30 29 28 11 10 0
0 0000h ID CAN de 11 bits

x geração quadro
ID CAN de 29 bits
MSB LSB
Figura 54: Estrutura do SYNC COB-ID
Tabela 55: Descrição do SYNC COB-ID
Descrição
Bit(s) Valor
x x não se importa
geração 0b Dispositivo CANopen não gera mensagem SYNC
1b dispositivo CANopen gera mensagem SYNC
quadro 0b 11 bits CAN-ID válido (quadro base CAN)
1b CAN-ID de 29 bits válido (quadro estendido CAN)
CAN-ID de 29 bits x CAN-ID de 29 bits do quadro estendido CAN
CAN-ID de 11 bits x CAN-ID de 11 bits do quadro base CAN
Os bits 29 (quadro) e o bit 30 (geração) podem ser estáticos (não alteráveis). Se um dispositivo CANopen não for capaz de
gerar mensagens SYNC, uma tentativa de definir o bit 30 (gen.) para 1b é respondida com o serviço de transferência de
aborto SDO (código de aborto: 0609 0030h). Dispositivos CANopen que suportam apenas o tipo de quadro base CAN, uma
tentativa de definir o bit 29 (quadro) para 1b é respondida com o serviço de transferência de aborto SDO (código de aborto:
0609 0030h). A primeira transmissão do objeto SYNC começa dentro de 1 ciclo de sincronização após definir o bit 30 para
1b. Ajustando o bit 30 para 1b enquanto o valor de overflow do contador síncrono for maior que 0 a primeira mensagem
SYNC deve iniciar com o contador resetado para 1. Não é permitido alterar os bits 0 para 29, enquanto o objeto existir (bit 30
= 1b) .

Índice 1005h
Nome SINCRONIZAÇÃO COB-ID
FOI
Código do objeto
Categoria Condicional;
Obrigatório, se a comunicação PDO em uma base síncrona for suportada
Sub-índice 00h
Acesso rw;
const, se o COB-ID não for alterável
Mapeamento PDO Não
Valor padrão 0000 0080h ou 8000 0080h
7.5.2.6 Objeto 1006h: Período do ciclo de comunicação
Este objeto deve fornecer o período do ciclo de comunicação. Este período define o intervalo SYNC.
O valor deve ser dado em múltiplos de µs. Se o valor for definido para 0000 0000h a transmissão de mensagens SYNC deve ser
desabilitada. Ao alterar o valor de 0000 0000h e o valor de overflow do contador síncrono for maior que 0, a primeira mensagem
SYNC deve iniciar com o valor do contador redefinido para 1.
A transmissão de mensagens SYNC deve começar dentro de um período de ciclo de comunicação dado pelo valor após ser
ajustado para o novo valor.
Índice 1006h
Nome
Período do ciclo de comunicação
Obrigatório para produtores SYNC
Sub-índice 00h
Acesso rw
Mapeamento PDO Não
Valor padrão 0000 0000h

7.5.2.7 Objeto 1007h: Comprimento da janela síncrona
Este objeto deve indicar a duração da janela de tempo configurada para PDOs síncronos.
Se o comprimento da janela síncrona expirar, todos os TPDOs síncronos podem ser descartados e uma mensagem EMCY pode ser
transmitida; todos os RPDOs síncronos podem ser descartados até que a próxima mensagem SYNC seja recebida. O processamento
síncrono de RPDO é retomado com a próxima mensagem SYNC.
O valor é dado em múltiplos de µs. Se o valor for definido para 0000 0000h , a janela síncrona deve ser desabilitada.
Índice 1007h
Nome Comprimento da janela síncrona
Categoria Opcional
Sub-índice 00h
Acesso rw
Mapeamento PDO Não
7.5.2.8 Objeto 1008h: Nome do dispositivo do fabricante
Este objeto deve fornecer o nome do dispositivo fornecido pelo fabricante.
Índice 1008h
Nome Nome do dispositivo do fabricante
FOI
Código do objeto
Tipo de dados VISIBLE_STRING
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor VISIBLE_STRING
Valor padrão Específico do fabricante

7.5.2.9 Objeto 1009h: Versão de hardware do fabricante
Este objeto deve fornecer a descrição da versão do hardware do fabricante.

Índice 1009h
Nome Versão de hardware do fabricante
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
7.5.2.10 Objeto 100Ah: Versão do software do fabricante
Este objeto deve fornecer a descrição da versão do software do fabricante.

Índice 100Ah
Nome Versão do software do fabricante
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
7.5.2.11 Objeto 100Ch: Tempo de guarda
Os objetos no índice 100Ch e 100Dh devem indicar o tempo de guarda configurado respectivamente o fator de tempo de vida.
O fator de tempo de vida multiplicado pelo tempo de guarda dá o tempo de vida para o protocolo de guarda de vida.
O valor deve ser dado em múltiplos de ms. O valor de 0000h deve desabilitar o salva-vidas.

Índice 100 canais
Nome Tempo de guarda
Tipo de dados NÃO ASSINADO 16
Obrigatório, se a proteção do nó for suportada
Sub-índice 00h
Acesso rw;
ro, se o salva-vidas não for suportado
Mapeamento PDO Não
Faixa de valor NÃO ASSINADO 16
Valor padrão 0000h
7.5.2.12 Objeto 100Dh: Fator de tempo de vida
O fator de tempo de vida multiplicado pelo tempo de guarda dá o tempo de vida para o protocolo de guarda de vida.
O valor de 00h deve desabilitar o salva-vidas.
Índice 100 Dh
Nome Fator de tempo de vida
FOI
Código do objeto
Obrigatório, se a proteção do nó for suportada
Sub-índice 00h
Acesso rw;
ro, se o salva-vidas não for suportado
Mapeamento PDO Não
Valor padrão 00h

7.5.2.13 Objeto 1010h: Armazenar parâmetros
Este objeto deve controlar o salvamento dos parâmetros na memória não volátil.
Por acesso de leitura o dispositivo CANopen deve fornecer informações sobre suas capacidades de salvamento.
Vários grupos de parâmetros são distinguidos:
• O subíndice 00h contém o subíndice mais alto suportado. • O subíndice 01h refere-se a
todos os parâmetros que podem ser armazenados no dispositivo CANopen.
• O subíndice 02h refere-se aos parâmetros relacionados à comunicação (índice de 1000h a 1FFFh).
• O subíndice 03h refere-se aos parâmetros relacionados à aplicação (índice de 6000h a 9FFFh).
• Os fabricantes de subíndices de 04h a 7Fh podem armazenar sua escolha de parâmetros individualmente.
• Os subíndices de 80h a FEh são reservados para uso futuro.
Para evitar o armazenamento de parâmetros por engano, o armazenamento só deve ser executado quando uma assinatura específica for
gravada no subíndice apropriado. A assinatura que deve ser escrita é "salvar":
Assinatura MSB LSB
/ISO8859/ caractere e dentro uma s
hexágono 65h 76h 61h 73 horas
Figura 55: Assinatura de acesso de gravação de armazenamento
Ao receber a assinatura correta no sub-índice apropriado, o dispositivo CANopen deve armazenar o parâmetro e, em seguida, deve
confirmar a transmissão SDO (resposta de início de download SDO).
Se o armazenamento falhar, o dispositivo CANopen responderá com o serviço de transferência de aborto SDO (código de aborto: 0606
0000h).
Se uma assinatura errada for escrita, o dispositivo CANopen se recusará a armazenar e responderá com o serviço de transferência de
aborto SDO (código de aborto: 0800 002xh).
No acesso de leitura ao subíndice apropriado, o dispositivo CANopen deve fornecer informações sobre sua funcionalidade de armazenamento
com o seguinte formato:
31 2 1 0
reservado
cmd automático
(00 0000 0000 0000 0000 0000 0000 0000b)
MSB LSB
Figura 56: Estrutura de acesso de leitura de armazenamento
Tabela 56: Estrutura de acesso de leitura
Descrição do valor do bit
auto 0b O dispositivo CANopen não salva os parâmetros de forma autônoma
1b O dispositivo CANopen salva os parâmetros de forma autônoma
cmd 0b dispositivo CANopen não salva parâmetros no comando
1b O dispositivo CANopen salva os parâmetros no comando
Salvamento autônomo significa que um dispositivo CANopen armazena os parâmetros armazenáveis de maneira não volátil sem solicitação
do usuário.

Índice 10h10
Nome armazenar parâmetros
Categoria Opcional
Sub-índice 00h
Descrição mais alto sub-índice suportado
Acesso const
Mapeamento PDO Não
Faixa de valor 01h às 7Fh
Valor padrão específico do perfil ou do fabricante
Sub-índice 01h
Descrição salvar todos os parâmetros
Acesso rw
ro, se o armazenamento autônomo for suportado
Mapeamento PDO Não
Faixa de valor ver definição de valor
(Figura 55 para acesso de gravação; Figura 56 para acesso de leitura)
Valor padrão
perfil ou fabricante específico
Sub-índice 02h
Descrição salvar parâmetros de comunicação
Acesso rw
Mapeamento PDO Não

Sub-índice 03h
Descrição salvar parâmetros do aplicativo
Acesso rw
Mapeamento PDO Não
Valor padrão
específico do perfil ou do fabricante
Sub-índice 04h às 7Fh
Descrição salvar parâmetros definidos pelo fabricante
Acesso rw
Mapeamento PDO Não
Valor padrão
7.5.2.14 Objeto 1011h: Restaurar parâmetros padrão
Com este objeto são restaurados os valores padrão dos parâmetros de acordo com o perfil de comunicação, perfil do dispositivo e perfil
do aplicativo.
Por acesso de leitura o dispositivo CANopen deve fornecer informações sobre sua capacidade de restaurar esses valores. Vários
grupos de parâmetros são distinguidos:
• O subíndice 00h contém o subíndice mais alto suportado. • O subíndice 01h refere-se
a todos os parâmetros que podem ser restaurados.
• O subíndice 02h refere-se aos parâmetros relacionados à comunicação (Índice de 1000h a 1FFFh).
• O subíndice 03h refere-se aos parâmetros relacionados à aplicação (Índice de 6000h a 9FFFh).
• Os fabricantes de subíndices de 04h a 7Fh podem restaurar sua escolha individual de parâmetros.
• Os subíndices de 80h a FEh são reservados para uso futuro.
Para evitar a restauração de parâmetros padrão por engano, a restauração deve ser executada somente quando uma assinatura
específica for gravada no subíndice apropriado. A assinatura que deve ser escrita é "load":
Assinatura MSB LSB
/ISO8859/ caractere d uma o eu
hexágono 64h 61h 6Fh 6 canais
Figura 57: Restaurar assinatura de acesso de gravação padrão
Ao receber a assinatura correta no subíndice apropriado, o dispositivo CANopen deve restaurar os parâmetros padrão e, em
seguida, confirmar a transmissão SDO (download SDO

iniciar a resposta). Se a restauração falhar, o dispositivo CANopen responderá com o serviço de transferência de aborto SDO (código
de aborto: 0606 0000h). Se uma assinatura errada for escrita, o dispositivo CANopen se recusará a restaurar os padrões e responderá
com o serviço de transferência de aborto SDO (código de aborto: 0800 002xh).
Os valores padrão devem ser definidos como válidos após o reset do dispositivo CANopen (nó de reset de serviço NMT para
subíndice de 01h a 7Fh, comunicação de reset de serviço NMT para subíndice 02h) ou desligado e ligado.
restaurar padrão
reset / ciclo de energia
valores padrão válidos
Figura 58: Procedimento de restauração
No acesso de leitura ao subíndice apropriado, o dispositivo CANopen deve fornecer informações sobre sua capacidade de restauração
de parâmetros padrão com o seguinte formato:
31 1 0
reservado
cmd
(000 0000 0000 0000 0000 0000 0000 0000b)
MSB LSB
Figura 59: Restaurar a estrutura de acesso de leitura padrão
Tabela 57: Estrutura do acesso de leitura de restauração
Descrição do valor do bit
cmd 0b dispositivo CANopen não restaura os parâmetros padrão
1b O dispositivo CANopen restaura os parâmetros
Índice 1011h
Nome restaurar parâmetros padrão
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não

Sub-índice 01h
Descrição restaurar todos os parâmetros padrão
Acesso rw
Mapeamento PDO Não
Valor padrão
Sub-índice 02h
Descrição restaurar parâmetros padrão de comunicação
Acesso rw
Mapeamento PDO Não
Valor padrão
Sub-índice 03h
Descrição restaurar parâmetros padrão do aplicativo
Acesso rw
Mapeamento PDO Não
Descrição restaurar parâmetros padrão definidos pelo fabricante
Mapeamento PDO Não

7.5.2.15 Objeto 1012h: objeto de carimbo de hora COB-ID
Este objeto deve indicar o COB-ID configurado do objeto Time-Stamp (TIME). Além disso, define se o dispositivo CANopen consome
o TIME ou se o dispositivo CANopen gera o TIME. A estrutura deste objeto é especificada na Figura 60 e na Tabela 58.
31 30 29 28 11 10 0

consumir produzir quadro
ID CAN de 29 bits
MSB LSB
Figura 60: Estrutura do TIME COB-ID
Tabela 58: Descrição do TIME COB-ID
Bit(s) Descrição do valor
consumir 0b dispositivo CANopen não consome mensagem TIME
1b dispositivo CANopen consome mensagem TIME
produzir 0b Dispositivo CANopen não produz mensagem TIME
1b dispositivo CANopen produz mensagem TIME
quadro 0b CAN-ID de 11 bits válido (frame base CAN)
11 bits CAN-ID x CAN-ID de 11 bits do quadro base CAN
Os bits 29 (quadro), 30 (produção) podem ser estáticos (não alteráveis). Se um dispositivo CANopen não for capaz de gerar
mensagens TIME, uma tentativa de definir o bit 30 (produção) para 1b deve ser respondida com o serviço de transferência de
aborto SDO (código de aborto: 0609 0030h). Dispositivos CANopen que suportam apenas o tipo de frame base CAN, uma
tentativa de definir o bit 29 (frame) para 1b deve ser respondida com o serviço de transferência de aborto SDO (código de
aborto: 0609 0030h). Os bits 0 a 29 não devem ser alterados enquanto o objeto existir (bit 30 = 1b ou bit 31 = 1b).
Índice 1012h
Nome Mensagem de carimbo de hora COB-ID
Categoria Opcional
Sub-índice 00h
Acesso rw
Mapeamento PDO Não
Valor padrão CAN-ID: 100h

quadro: 0b
válido: específico do perfil ou do fabricante

7.5.2.16 Objeto 1013h: carimbo de hora de alta resolução
Este objeto deve indicar o timestamp de alta resolução configurado. Ele pode ser mapeado em um PDO para trocar uma mensagem
de carimbo de hora de alta resolução. O uso específico da aplicação adicional é incentivado.
O valor é dado em múltiplos de 1 µs.
Índice 1013h
Nome carimbo de hora de alta resolução
Categoria Opcional
Sub-índice 00h
Acesso rw;
ro, se apenas o produtor de carimbo de data/hora de alta resolução for suportado
rw ou wo, se apenas o consumidor de carimbo de hora de alta resolução for suportado
Valor padrão 0
7.5.2.17 Objeto 1014h: COB-ID EMCY
Este objeto deve indicar o COB-ID configurado para o serviço de gravação EMCY.
31 30 29 28 11 10 0

quadro 0b válido
ID CAN de 29 bits
MSB LSB
Figura 61: Estrutura do Identificador EMCY
Tabela 59: Descrição do EMCY COB-ID
0b EMCY existe / é válido

válido
1b EMCY não existe / não é válido
30 0b reservado (sempre 0b)
CAN-ID de 29 bits válido (quadro estendido CAN)

1b
CAN-ID de 11 bits x CAN-ID de 11 bits do quadro base CAN

Dispositivos CANopen que suportam apenas o tipo de frame base CAN devem responder com o serviço de transferência de aborto
SDO (código de aborto: 0609 0030h) no caso de uma tentativa de definir o bit 29 (quadro) para 1b. Os bits 0 a 29 não devem ser
alterados enquanto o objeto existir e for válido (bit 31 = 0b).
Índice 1014h
Nome Mensagem de emergência COB-ID
Obrigatório, se a Emergência for suportada
Sub-índice 00h
Acesso rw;
Mapeamento PDO Não
Valor padrão CAN-ID: 80h + Node-ID

quadro: 0b
7.5.2.18 Objeto 1015h: Tempo de inibição EMCY
Este objeto deve indicar o tempo de inibição configurado para a mensagem EMCY.
O valor deve ser dado em múltiplos de 100 µs. O valor 0 deve desabilitar o tempo de inibição.
Índice 1015h
Nome inibir o tempo EMCY
Categoria Opcional
Sub-índice 00h
Acesso rw
Mapeamento PDO Não
Valor padrão 0
7.5.2.19 Objeto 1016h: Tempo de pulsação do consumidor
O objeto de tempo de pulsação do consumidor deve indicar os tempos de ciclo de pulsação esperados. A monitorização do produtor de
batimentos cardíacos terá início após a recepção do primeiro batimento cardíaco.

NOTA: O tempo de pulsação do consumidor deve ser maior que o tempo de pulsação do produtor correspondente.
NOTA: Antes da recepção da primeira pulsação, o status do produtor de pulsação é desconhecido.
31 24 23 16 15 0
reservado
ID do nó Tempo de batimento cardíaco
(00h)
MSB LSB
Figura 62: Estrutura do tempo de pulsação do consumidor
Se o tempo de pulsação for 0 ou o node-ID for 0 ou maior que 127, a entrada do objeto correspondente não deve ser usada. O tempo
de pulsação deve ser dado em múltiplos de 1ms.
Uma tentativa de configurar vários tempos de pulsação diferentes de 0 para o mesmo node-ID o dispositivo CANopen deve ser
respondido com o serviço de transferência de aborto SDO (código de aborto: 0604 0043h).
Índice 1016h
Nome Tempo de pulsação do consumidor
Categoria Opcional
Sub-índice 00h
Descrição O subíndice mais alto suportado
Acesso const
Mapeamento PDO Não
Sub-índice 01h
Descrição Tempo de pulsação do consumidor
Acesso rw
Mapeamento PDO Não
Faixa de valor NÃO ASSINADO 32 (Figura 62)

Descrição Tempo de pulsação do consumidor
Acesso rw
Mapeamento PDO Não
Faixa de valor NÃO ASSINADO 32 (Figura 62)
7.5.2.20 Objeto 1017h: Tempo de pulsação do produtor
O tempo de pulsação do produtor deve indicar o tempo de ciclo configurado da pulsação.
O valor deve ser dado em múltiplos de 1 ms. O valor 0 deve desabilitar a pulsação do produtor.
Índice 1017h
Nome Tempo de batimento cardíaco do produtor
Obrigatório, se a proteção não for suportada
Sub-índice 00h
Acesso rw
const, se o valor padrão for específico do perfil e não alterável
Mapeamento PDO Não
Valor padrão 0 ou específico do perfil
7.5.2.21 Objeto 1018h: Objeto de identidade
Este objeto deve fornecer informações gerais de identificação do dispositivo CANopen.
O subíndice 01h deve conter o valor único1 que é atribuído exclusivamente a cada fornecedor de um dispositivo CANopen. O valor
0000 0000h deve indicar um ID de fornecedor inválido.
O subíndice 02h deve conter o valor único que identifica um tipo específico de dispositivos CANopen.
O valor de 0000 0000h deve ser reservado.
O subíndice 03h deve conter o número de revisão principal e o número de revisão secundária da revisão do dispositivo CANopen
(ver Figura 63). O número de revisão principal deve identificar um comportamento CANopen específico. Isso significa que se a
funcionalidade CANopen for diferente, o número de revisão principal deve ser incrementado. O número de revisão secundária deve
identificar diferentes versões do dispositivo CANopen com o mesmo comportamento CANopen. O valor de 0000 0000h deve ser
reservado.
1 O valor é atribuído exclusivamente pelo CAN em Automação (CiA).

31 16 15 0
Número de revisão principal Número de revisão secundária
MSB LSB
Figura 63: Estrutura do número de revisão
O subíndice 04h deve conter o número de série que identifica exclusivamente um dispositivo CANopen dentro de um grupo de
produtos e uma revisão específica. O valor de 0000 0000h deve ser reservado.
Índice 1018h
Nome Objeto de identidade
Código do objeto REGISTRO
Tipo de dados Identidade
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor 01h às 04h
Sub-índice 01h
Descrição ID do fornecedor
Acesso ro
Mapeamento PDO Não
Valor padrão Atribuído exclusivamente aos fabricantes pela CiA

Sub-índice 02h
Descrição Código do produto
Acesso ro
Mapeamento PDO Não
Valor padrão
Perfil específico ou fabricante
Sub-índice 03h
Descrição Número de revisão
Acesso ro
Mapeamento PDO Não
Valor padrão
Sub-índice 04h
Descrição Número de série
Acesso ro
Mapeamento PDO Não
Valor padrão
7.5.2.22 Objeto 1019h: Valor de estouro do contador síncrono
Este objeto deve indicar o valor mais alto configurado que o contador síncrono suporta. Este objeto deve ser implementado pelo produtor
e pelo consumidor, caso o contador síncrono seja suportado pelo dispositivo CANopen. Se o valor for maior que 1, a mensagem SYNC
deve ter um comprimento de dados de 1 byte. O consumidor SYNC deve ignorar o valor em si. Uma mensagem EMCY (código de erro:
8240h –
comprimento de dados SYNC inesperado) pode ser transmitido por um consumidor SYNC no caso de o comprimento de dados
configurado da mensagem SYNC não atender ao comprimento de dados de uma mensagem SYNC recebida.


Descrição
Valor
A mensagem SYNC deve ser transmitida como uma mensagem CAN de

0
comprimento de dados 0.
reservado
1
A mensagem SYNC deve ser transmitida como uma mensagem CAN de

2 a 240
comprimento de dados 1. O primeiro byte de dados contém o contador.
reservado
241 a 255
O valor utilizado deve ser o mínimo múltiplo comum de todos os tipos de transmissão TPDO (1 < n <= 240) utilizados. Isso
garante que eventos SYNC periódicos sempre ocorram nos ciclos SYNC com o mesmo valor do contador.
Uma alteração do valor deve ser respondida com uma interrupção SDO (código de interrupção: 0800 0022h ou 0800 0000h)
caso o período do ciclo de sincronização seja diferente de 0.
Índice 1019h
Nome Valor de estouro do contador síncrono
Categoria Opcional
Sub-índice 00h
Acesso rw;
const, se o valor padrão for específico do perfil e não alterável
Mapeamento PDO Não
Valor padrão 0 ou específico do perfil
7.5.2.23 Objeto 1020h: Verificar configuração
Este objeto deve indicar a data e hora da configuração baixada. Se um dispositivo CANopen suporta o salvamento de parâmetros
em memória não volátil, uma ferramenta de configuração de rede ou um gerenciador CANopen utiliza este objeto para verificar a
configuração após um reset do dispositivo CANopen e verificar se uma reconfiguração é necessária. A ferramenta de configuração
armazena a data e hora nesse objeto e armazena os mesmos valores no DCF. Agora a ferramenta de configuração permite que o
dispositivo CANopen salve sua configuração escrevendo no índice 1010h sub-índice 01h a assinatura "save". Após um reset o
dispositivo CANopen deve restaurar a última configuração e a assinatura automaticamente ou por solicitação. Se qualquer outro
comando alterar os valores de configuração de inicialização, o dispositivo CANopen deve redefinir o objeto Verify Configuration
para 0.
O Configuration Manager compara a assinatura e a configuração com o valor do DCF e decide se uma reconfiguração é necessária
ou não.
Nota: O uso deste objeto permite uma aceleração significativa do processo de inicialização. Caso seja utilizado, o integrador de
sistemas considera que um usuário altera um valor de configuração e posteriormente ativa o comando store configuration
1010h sem alterar o valor de 1020h. Assim, o integrador de sistemas garante um uso 100% conseqüente desse recurso.

O subíndice 01h (data de configuração) deve conter o número de dias desde 1º de janeiro de 1984.
O subíndice 02h (hora de configuração) será o número de ms após a meia-noite.
Índice 1020h
Nome Verificar configuração
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor 02h
Valor padrão 02h
Sub-índice 01h
Descrição Data de configuração
Acesso rw
Mapeamento PDO Não
Sub-índice 02h
Descrição Tempo de configuração
Acesso rw
Mapeamento PDO Não

7.5.2.24 Objeto 1021h: Armazenar EDS
Este objeto deve indicar o EDS baixado. O armazenamento de arquivos EDS no dispositivo CANopen tem algumas vantagens:
• O fabricante não tem o problema de distribuir o EDS via discos
• O gerenciamento de diferentes versões de EDS para diferentes versões de software é menos propenso a erros, se
eles são armazenados juntos
• As configurações de rede completas são armazenadas na rede. Isso torna a tarefa de analisar ou
reconfigurando uma rede mais fácil para as ferramentas e mais transparente para os usuários.
O nome do arquivo não precisa ser armazenado, pois cada EDS contém seu próprio nome de arquivo.
Índice 1021h
Nome Armazenar EDS
Tipo de dados DOMÍNIO
Categoria Opcional
Sub-índice 00h
Acesso ro
Mapeamento PDO Não
Faixa de valor Específico do fabricante
Valor padrão Não
7.5.2.25 Objeto 1022h: Formato de armazenamento
O objeto deve indicar o formato do armazenamento. Isso permite o uso de formatos compactados. O objeto descreve apenas o
comportamento externo.

Tabela 60: Valores para formatos de armazenamento EDS
Descrição do valor
00h /ISO10646/, não compactado
01h reservado
::::: :::::
7Fh reservado
80h específico do fabricante
::::: :::::
FF específico do fabricante
Índice 1022h
Nome Formato da loja
Obrigatório se o EDS da loja for suportado
Sub-índice 00h
Acesso ro
Mapeamento PDO Não
Valor padrão Não

7.5.2.26 Objeto 1023h: comando do SO
O objeto Comando do SO deve ser usado como uma interface orientada a comandos para dispositivos programáveis. O conteúdo do
comando são caracteres /ISO8859/ ou binários e são completamente específicos do fabricante. O sistema host coloca o comando no
comando do SO do objeto.
Se um dispositivo CANopen implementa esta função, todos os subíndices são obrigatórios, entradas de objetos adicionais são
específicas do fabricante. Um novo comando pode ser inserido, se o status estiver na faixa de 0 a 3: O comando e todos os
parâmetros devem ser transmitidos em um bloco para o subíndice 01h. A execução do comando terá início imediatamente após a
conclusão da transferência. O host pesquisa o sub-índice 02h, até que seja um valor de 0 a 3. Ele pode então transferir a resposta,
se o status for um valor de 1 ou 3. O dispositivo CANopen deve retornar a mesma resposta, se a resposta for solicitada mais de
uma vez, ou pode mudar o status de 1 para 0 ou 3 para 2, se não for capaz de armazenar em buffer a resposta.
Índice 1023h
Nome Comando do SO
Tipo de dados Registro de comando do SO
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor 03h
Valor padrão 03h
Sub-índice 01h
Descrição Comando
Acesso rw;
wo, se apenas a escrita for suportada
Mapeamento PDO Não
Faixa de valor Não

Sub-índice 02h
Descrição Status
Acesso ro
Mapeamento PDO Não
Valor padrão Não
Sub-índice 03h
Descrição Responder
Acesso ro
Mapeamento PDO Não
Faixa de valor Não
Valor padrão Não
7.5.2.27 Objeto 1024h: modo de comando do SO
Este objeto deve controlar a execução do comando na fila específica da aplicação. Pretende-se que este objeto represente o comando
mais recente de uma fila específica do programa aplicativo.
Tabela 61: Valores do modo de comando do SO
00h Execute o próximo comando imediatamente
01h Buffer o próximo comando
02h Execute os comandos no buffer
03h Abortar o comando atual e todos os comandos no buffer
04h Específico do fabricante
::::: :::::
FF Específico do fabricante
Índice 1024h
Nome Modo de comando do SO
Categoria Opcional

Sub-índice 00h
Acesso Onde
Mapeamento PDO Não
7.5.2.28 Objeto 1025h: interface do depurador do SO
Este objeto deve fornecer a interface do depurador do SO. É a interface de comando binário para os agentes depuradores do dispositivo
CANopen programável. O conteúdo dos comandos é específico do fabricante. Este objeto permite que o usuário se conecte a um depurador
remoto.
veja o comando do SO
Índice 1025h
Nome Interface do depurador do SO
Tipo de dados Registro de depuração do SO
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor 03h
Valor padrão 03h
Sub-índice 01h
Descrição Comando
Acesso rw;
wo, se apenas a escrita for suportada
Mapeamento PDO Não
Faixa de valor Não

Sub-índice 02h
Descrição Status
Acesso ro
Mapeamento PDO Não
Valor padrão Não
Sub-índice 03h
Descrição Responder
Acesso ro
Mapeamento PDO Não
Faixa de valor Não
Valor padrão Não
7.5.2.29 Objeto 1026h: prompt do SO
O objeto prompt do SO é uma interface de comando orientada por caracteres para dispositivos CANopen programáveis.
O conteúdo dos comandos é específico do fabricante. Este objeto permite que o usuário tenha o controle remoto do teclado.
O subíndice 01h StdIn é usado para transmitir caracteres simples para o dispositivo CANopen por SDO ou PDO. Cada novo caractere deve
ser anexado à fila de entrada interna. As respostas do dispositivo CANopen devem ser emitidas no subíndice 02h StdOut. Este objeto é
mapeável para um PDO orientado a eventos ou pesquisado por SDO. O subíndice 03h StdErr é usado para saída de erro. Este objeto é
mapeável para um PDO orientado a eventos ou pesquisado por SDO.
Índice 1026h
Nome SO de prompt
Categoria Opcional

Sub-índice 00h
Acesso const
Mapeamento PDO Não
Valor padrão Não
Sub-índice 01h
Descrição StdIn
Acesso Onde
Sub-índice 02h
Descrição StdOut
Acesso ro
Valor padrão Não
Sub-índice 03h
Descrição StdErr
Acesso ro
Valor padrão Não
7.5.2.30 Objeto 1027h: Lista de módulos
Um método comum para fornecer dispositivos CANopen modulares é o uso de um acoplador de barramento que permite conectar várias
combinações de módulos. O objeto deve fornecer informações sobre os módulos atualmente anexados.

Os subíndices consecutivos (1 ÿ N ÿ 254) descrevem os módulos correspondentes na ordem em que são anexados. Cada entrada de
objeto deve conter um número que identifica o módulo. Para isso, o número deve ser único dentro de todos os tipos de módulos que estão
conectados a este tipo de dispositivo acoplador de barramento.
A entrada do objeto no subíndice 00h deve conter o número real de módulos que estão conectados ao acoplador de barramento.
NOTA: Se nenhum módulo estiver presente, o valor do subíndice 00h é 00h e um acesso de leitura ao subíndice 01h é respondido com
uma mensagem de aborto SDO (código de cancelamento: 0800 0024h ou 0800 0000h).
Índice 1027h
Nome Lista de módulos
Obrigatório, se houver suporte para dispositivos modulares
Sub-índice 00h
Descrição número de módulos conectados
Acesso const
Mapeamento PDO Não
Valor padrão Não
Sub-índice 01h
Descrição Módulo 1
Acesso ro
Mapeamento PDO Não
Valor padrão Não

Descrição Módulo 2 ao Módulo 254
Acesso ro
Mapeamento PDO Não
Valor padrão Não
7.5.2.31 Objeto 1028h: Objeto consumidor emergencial
Esses objetos devem indicar os COB-IDs configurados para os objetos EMCY que o dispositivo CANopen está consumindo.
31 30 29 28 11 10 0

quadro de resolução válido
ID CAN de 29 bits
MSB LSB
Figura 64: Estrutura do EMCY COB-ID
Tabela 62: Descrição do EMCY COB-ID
0b O consumidor EMCY existe/é válido

válido
1b O consumidor EMCY não existe/não é válido
res 0b reservado (sempre 0b)
ID CAN de 11 bits x CAN-ID de 11 bits do quadro base CAN
Dispositivos CANopen que suportam apenas o tipo de frame base CAN, uma tentativa de definir o bit 29 (frame) para 1b
será respondido com o serviço de transferência de aborto SDO (código de aborto: 0609 0030h). Os bits 0 a 29 não devem ser
alterados enquanto o objeto existir e for válido (bit 31 = 0b).
O Sub-índice deve referir-se ao ID do nó relacionado.
Índice 1028h
Nome Consumidor de emergência
Categoria Opcional

Sub-índice 00h
Acesso const
Mapeamento PDO Não
Sub-índice 01h
Descrição Consumidor de emergência 1
Acesso rw;
const, se o valor do consumidor de emergência não for mutável
Mapeamento PDO Não
Descrição Consumidor de emergência 2 a 127
Acesso rw;
const, se o valor do consumidor de emergência não for mutável
Mapeamento PDO Não
7.5.2.32 Objeto 1029h: Objeto de comportamento de erro
Se uma falha grave do dispositivo CANopen for detectada no estado NMT Operacional, o dispositivo CANopen deverá entrar por padrão
de forma autônoma no estado NMT Pré-operacional. Se o objeto estiver implementado, o dispositivo CANopen é configurável para entrar
alternativamente no estado NMT Stopped ou permanecer no estado NMT atual. As falhas do dispositivo CANopen devem incluir os
seguintes erros de comunicação:
• Condições de desconexão da interface CAN
• Evento de salva-vidas com o estado 'ocorreu' e o motivo 'tempo limite'

• Evento de pulsação com estado 'ocorreu' e o motivo 'tempo limite'
Erros graves do dispositivo CANopen também podem ser causados por falhas internas do dispositivo CANopen.

Tabela 63: Valores de classe de erro
00h Mudança para o estado NMT Pré-operacional

(somente se atualmente no estado NMT Operacional)
01h Sem alteração do estado NMT
02h Mudar para o estado NMT Parado
03h reservado
::::: :::::
7Fh reservado
80h Específico do fabricante
::::: :::::
FF Específico do fabricante
Índice 1029h
Nome Comportamento de erro
Categoria Opcional
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Sub-índice 01h
Descrição Erro de comunicação
Acesso rw;
const, se o comportamento de erro para erros de comunicação não for alterável
Mapeamento PDO Não
Valor padrão 00h

Descrição erro específico do perfil ou do fabricante
Acesso rw;
const, se o comportamento do erro não for alterável
Mapeamento PDO Não
Valor padrão perfil ou específico do fabricante
7.5.2.33 Objeto 1200h a 127Fh: parâmetro do servidor SDO
Para descrever os SDOs usados em um dispositivo CANopen, o tipo de dado Parâmetro SDO é introduzido. O tipo de dado tem o
índice 22h no dicionário de objetos. A estrutura é definida na cláusula 7.4.8.
O número de entradas de objeto com suporte no registro de objeto SDO é especificado no subíndice 00h.
Os valores no subíndice 01h e no subíndice 02h especificam o COB-ID para este SDO. O subíndice 03h é o node-ID do cliente
SDO associado a este dispositivo CANopen.
31 30 29 28 11 10 0

quadro dinâmico válido
ID CAN de 29 bits
MSB LSB
Figura 65: Estrutura do servidor SDO COB-ID
Tabela 64: Descrição do COB-ID do servidor SDO
SDO existe / é válido

válido 0b
1b SDO não existe / não é válido
cara 0b O valor é atribuído estaticamente
1b O valor é atribuído dinamicamente
ID CAN de 29 bits x CAN-ID de 29 bits do quadro estendido CAN
Um SDO existe somente se tanto no subíndice 01h quanto no subíndice 02h o bit válido (bit 31) estiver definido como 0b.
é respondido com o serviço de transferência de aborto SDO (código de aborto: 0609 0030h). Não é permitido alterar os bits 0
para 29 enquanto o objeto existir e for válido (bit 31 = 0b).
Se o bit dyn (bit 30) do subíndice 01h ou subíndice 02h for definido como 1b , os valores de todos os subíndices deste objeto
não devem ser armazenados em memória não volátil. O bit dyn pode ser usado para marcar conexões SDO dinâmicas entre
dispositivos CANopen. As conexões SDO dinâmicas são configuradas temporariamente. As conexões SDO estáticas são
configuradas de forma não temporária e podem ser salvas em

memória volátil. O gerenciador CANopen pode usar o bit dyn para detectar conexões SDO configuradas temporariamente.
Índice 1200h a 127Fh
Nome Parâmetro do servidor SDO
Tipo de dados Registro de parâmetro SDO
Categoria Condicional
Índice 1200h: Opcional
Índice 1201h a 127Fh: Obrigatório para cada servidor SDO suportado

adicionalmente
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor Índice 1200h: 02h
Índice 1201h a 127Fh: 02h às 03h
Valor padrão perfil ou específico do fabricante
Sub-índice 01h
Descrição Cliente COB-ID -> servidor (rx)
Acesso Índice 1200h: const
Índice 1201h a 127Fh: rw;

const, se definido pelo perfil do aplicativo
Valor padrão Índice 1200h: CAN-ID: 600h + Node-ID

quadro: 0b
seu: 0b
válido: 0b
Índice 1201h a 127Fh: CAN-ID: específico do fabricante (consulte a cláusula

7.3.5)
quadro: específico do fabricante
dyn: 0b
válido: 1b ou definido pelo perfil do aplicativo

Sub-índice 02h
Descrição Servidor COB-ID -> cliente (tx)
Acesso Índice 1200h: ro
Índice 1201h a 127Fh: rw;

Valor padrão Índice 1200h: CAN-ID: 580h + Node-ID

quadro: 0b
seu: 0b
válido: 0b
Índice 1201h a 127Fh: CAN-ID: específico do fabricante (consulte a cláusula

7.3.5)
dyn: 0b
Sub-índice 03h
Descrição Node-ID do cliente SDO
Acesso rw
Mapeamento PDO Não
Valor padrão específico do fabricante
7.5.2.34 Objeto 1280h a 12FFh: parâmetro do cliente SDO
Esses objetos contêm os parâmetros para os SDOs para os quais o dispositivo CANopen é o cliente SDO. Se o objeto for suportado,
todos os subíndices estarão disponíveis. A partir do índice 1280h e índices subsequentes.
O número de entradas de objeto com suporte no registro de objeto SDO é especificado no subíndice 00h.
Os valores no subíndice 01h e no subíndice 02h especificam o COB-ID para este SDO. O subíndice 03h é o node-ID do servidor
SDO associado a este dispositivo CANopen.
31 30 29 28 11 10 0

quadro dinâmico válido
ID CAN de 29 bits
MSB LSB
Figura 66: Estrutura do cliente SDO COB-ID

Tabela 65: Descrição do cliente SDO COB-ID
SDO existe / é válido

válido 0b
1b SDO não existe / não é válido
cara 0b O valor é atribuído estaticamente
1b O valor é atribuído dinamicamente
Um SDO existe somente se tanto no subíndice 01h quanto no subíndice 02h o bit válido (bit 31) estiver definido como 0b.
é respondido com o serviço de transferência de aborto SDO (código de aborto: 0609 0030h). Não é permitido alterar os bits 0 para
29 enquanto o objeto existir e for válido (bit 31 = 0b). Dispositivos CANopen que suportam a habilitação (bit 31 = 0b) e desabilitação
(bit 31 = 1b) do cliente SDO somente devem responder com o serviço de transferência de abortar SDO (código de abortamento:
0609 0030h ou 0800 000h) na tentativa de alterar os valores de bit 0 a bit 30.
Se o bit dyn (bit 30) do subíndice 01h ou subíndice 02h for definido como 1b , os valores de todos os subíndices deste objeto não
devem ser armazenados em memória não volátil. O bit dyn pode ser usado para marcar conexões SDO dinâmicas entre dispositivos
CANopen. As conexões SDO dinâmicas são configuradas temporariamente. As conexões SDO estáticas são configuradas de
forma não temporária e podem ser salvas em memória não volátil. O gerenciador CANopen pode usar o bit dyn para detectar
conexões SDO configuradas temporariamente.
Índice 1280h a 12FFh
Nome Parâmetro do cliente SDO
Tipo de dados Parâmetro SDO
Obrigatório para cada cliente SDO suportado
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Faixa de valor 03h
Valor padrão 03h

Sub-índice 01h
Descrição Cliente COB-ID -> servidor (tx)
Acesso rw;
Valor padrão CAN-ID: específico do fabricante (consulte a cláusula 7.3.5)

dyn: 0b
Sub-índice 02h
Descrição Servidor COB-ID -> cliente (rx)
Acesso rw;
Valor padrão CAN-ID: específico do fabricante (consulte a cláusula 7.3.5)

dyn: 0b
Sub-índice 03h
Descrição Node-ID do servidor SDO
Acesso rw;
const, se o valor não for alterável
Mapeamento PDO Não
7.5.2.35 Objeto 1400h a 15FFh: parâmetro de comunicação RPDO
Este objeto contém os parâmetros de comunicação dos PDOs que o dispositivo CANopen pode receber.
O subíndice 00h contém o número de entradas de objeto válidas no registro. Seu valor é de no mínimo 02h. Se o tempo de inibição
for suportado o valor é 03h e se o temporizador de evento for suportado o valor é 05h.
O subíndice 01h contém o COB-ID do RPDO (ver Figura 67 e Tabela 66).

31 30 29 28 11 10 0

quadro reservado válido
ID CAN de 29 bits
MSB LSB
Figura 67: Estrutura do RPDO COB-ID
Tabela 66: Descrição do RPDO COB-ID
válido 0b PDO existe / é válido
1b PDO não existe / não é válido
reservado x não ligue
O bit válido (bit 31) permite selecionar quais RPDOs serão utilizados no estado NMT Operacional.
Pode haver PDOs totalmente configurados (por exemplo, por padrão), mas não usados e, portanto, definidos como
"não válidos" (excluídos). O recurso é necessário para dispositivos CANopen que suportem mais de 4 RPDOs, pois
cada dispositivo CANopen possui apenas CAN-IDs padrão para os quatro primeiros RPDOs no conjunto de conexão
predefinido genérico. Dispositivos CANopen que suportam o tipo de frame base CAN apenas uma tentativa de definir
o bit 29 (frame) para 1b é respondida com o serviço de transferência de aborto SDO (código de aborto: 0609 0030h).
Não é permitido alterar o bit 0 para 29 enquanto o PDO existir e for válido (bit 31 = 0b). Dispositivos CANopen que
suportam a habilitação (bit 31 = 0b) e desabilitação (bit 31 = 1b) de um RPDO somente devem responder com o serviço
de transferência de abortar SDO (código de abortamento: 0609 0030h ou 0800 000h) na tentativa de alterar os valores
de bit 0 a 30 bits.
Se o dispositivo CANopen tiver implementado um ou mais perfis de dispositivo, o conjunto de conexão predefinido
genérico deve ser aplicado (consulte a Tabela 67).
Tabela 67: Conjunto de conexão predefinido genérico para RPDO
Valor padrão do índice
1400h CAN-ID: 200h + Node-ID

quadro: 0b
reservado: específico do fabricante
válido: perfil ou específico do fabricante

29 bits: 0b
válido: perfil ou específico do fabricante

quadro: 0b

quadro: 0b

14:04h CAN-ID: específico do perfil ou do fabricante (consulte a cláusula 7.3.5)

para quadro: específico do perfil ou do fabricante
15FFh reservado: específico do fabricante
Se o dispositivo CANopen tiver implementado um perfil de aplicação, o conjunto de conexão pré-definido específico
desse perfil de aplicação deve ser aplicado.
O subíndice 02h define o caráter de recepção do RPDO (ver Tabela 68). Uma tentativa de alterar o valor do tipo de
transmissão para qualquer valor não suportado deve ser respondida com o serviço de transferência de aborto SDO (código
de aborto: 0609 0030h).
Tabela 68: Descrição do tipo de transmissão RPDO
Descrição
Valor
síncrono
00h
:::::
:::::
síncrono
F0h
reservado
F1h
:::::
:::::
reservado
FDh
orientado a eventos (específico do fabricante)

FEh
orientado a eventos (perfil de dispositivo e perfil de aplicativo específico)

FF
• Síncrono significa que o dispositivo CANopen deve acionar os dados recebidos com o
recepção do próximo SYNC (veja a Figura 68).
• Orientado a eventos significa que o PDO pode ser recebido a qualquer momento. O dispositivo CANopen
atualizará os dados imediatamente.
•
Figura 68: Sincronização e atuação do barramento
O subíndice 03h contém o tempo de inibição. O valor é definido como múltiplo de 100 µs. O valor 0 deve desabilitar o
tempo de inibição. Não é permitido alterar o valor enquanto o PDO existir (o bit 31 do sub-índice 01h é definido como 0b).
O RPDO pode utilizar o tempo de implementação específico.
O sub-índice 04h está reservado. Não deve ser implementado; neste caso, o acesso de leitura ou escrita leva ao serviço
de transferência de aborto SDO (código de aborto: 0609 0011h).

O subíndice 05h contém o temporizador de eventos. O valor é definido como múltiplo de 1 ms. O valor 0 deve desabilitar o
temporizador de eventos. O RPDO pode utilizar o tempo para monitoramento de prazos. O monitoramento de deadline é ativado
na próxima recepção de um RPDO após a configuração do event-timer. Um tempo limite resulta em uma indicação para o aplicativo
local.
O subíndice 06h contém o valor inicial SYNC. Isso não é usado por RPDOs. Não deve ser implementado; neste caso, o acesso de
leitura ou escrita levará ao serviço de transferência de abortamento SDO (código de abortamento: 0609 0011h).
Índice 1400h às 15FFh
Nome Parâmetro de comunicação RPDO
Tipo de dados Registro de parâmetro de comunicação PDO
Obrigatório para cada RPDO suportado
Sub-índice 00h
Acesso const
Mapeamento PDO Não
Valor padrão Não
Sub-índice 01h
Descrição COB-ID usado por RPDO
Acesso rw;
Mapeamento PDO Não
Valor padrão ver definição de valor

Sub-índice 02h
Descrição tipo de transmissão
Acesso rw;
const, se o tipo de transmissão não for alterável
Mapeamento PDO Não
Valor padrão
Perfil ou fabricante específico
Sub-índice 03h
Descrição inibir o tempo
Acesso rw;
const, se o tempo de inibição não for alterável
Mapeamento PDO Não
Valor padrão Perfil ou fabricante específico
Sub-índice 04h
Descrição entrada de compatibilidade
Acesso rw
Mapeamento PDO Não
Sub-índice 05h
Descrição temporizador de eventos
Acesso rw;
const, se o temporizador de eventos não for alterável
Mapeamento PDO Não
Valor padrão
Perfil ou fabricante específico

Sub-índice 06h
Descrição Valor inicial de SINCRONIZAÇÃO
Acesso rw
const, se o valor inicial do SYNC não for alterável
Mapeamento PDO Não
Valor padrão Perfil ou fabricante específico
7.5.2.36 Objeto 1600h a 17FFh: parâmetro de mapeamento RPDO
Este objeto contém os parâmetros de mapeamento para os PDOs que o dispositivo CANopen pode receber.
O subíndice 00h contém o número de entradas de objeto válidas no registro de mapeamento ou um valor específico
(consulte a Tabela 69), por exemplo, se o MPDO for suportado. O número de entradas de objetos válidos deve ser o
número de objetos de aplicação que devem ser recebidos com o RPDO correspondente.
Tabela 69: Valores de mapeamento RPDO
00h Mapeamento desativado
01h Sub-índice 01h válido
02h Sub-índice 01h e 02h válido
03h Sub-índice de 01h a 03h válido
::::: :::::
41h reservado
::::: :::::
FDh reservado
FEh SAM-MPDO
FFh DAM-MPDO
O subíndice de 01h a 40h contém as informações dos objetos de aplicação mapeados. O objeto descreve o conteúdo do PDO
por seu índice, subíndice e comprimento (ver Figura 69 e Figura 70).
O comprimento contém o comprimento do objeto do aplicativo em bits. Isso pode ser usado para verificar o mapeamento.
31 16 15 87 0
Índice Sub-índice Comprimento
MSB LSB
Figura 69: Estrutura do mapeamento RPDO
Uma tentativa de alterar o valor de uma entrada de objeto para qualquer valor que não seja suportado deve ser respondida
com o serviço de transferência de aborto SDO. A causa de um valor sem suporte pode ser o mapeamento (índice e
subíndice) de um objeto de aplicativo não existente, um comprimento incorreto para o objeto de aplicativo mapeado ou
um comprimento incorreto para o PDO. O índice e o subíndice podem

fazer referência a um tipo de dados simples (consulte a Tabela 44) para o chamado mapeamento fictício. Isso pode ser usado se nenhum
objeto de aplicativo apropriado estiver disponível e para preencher o comprimento do RPDO para ajustar o comprimento ao TPDO
correspondente.
O seguinte procedimento deve ser usado para remapeamento, que pode ocorrer durante o estado NMT Pré-operacional e durante o
estado NMT Operacional, se suportado:
1. Destrua o RPDO configurando o bit válido para 1b do subíndice 01h do parâmetro de comunicação RPDO correspondente.
2. Desative o mapeamento configurando o subíndice 00h para 00h.
3. Modifique o mapeamento alterando os valores dos subíndices correspondentes.
4. Habilite o mapeamento configurando o subíndice 00h para o número de objetos mapeados.
5. Crie o RPDO configurando o bit válido para 0b do sub-índice 01h do parâmetro de comunicação RPDO correspondente.
Se durante a etapa 3 o dispositivo CANopen detectar que o índice e sub-índice do objeto mapeado não existe ou o objeto não pode ser
mapeado, o dispositivo CANopen deverá responder com o serviço de transferência de aborto SDO (código de aborto: 0602 0000h ou
0604 0041h).
Se durante a etapa 4 o dispositivo CANopen detectar que o mapeamento RPDO não é válido ou não é possível, o dispositivo CANopen
deverá responder com o serviço de transferência de abortar SDO (código de abortamento: 0602 0000h
ou 0604 0042h).
Se o dispositivo CANopen receber um PDO que tenha mais bytes de dados do que o número de bytes de dados mapeados (comprimento),
o dispositivo CANopen deverá usar os primeiros bytes de dados até o comprimento e poderá iniciar o serviço de gravação EMCY, se
suportado .
Se um dispositivo CANopen receber um PDO com menos bytes de dados do que o número de bytes de dados mapeados (comprimento), o
dispositivo CANopen deverá iniciar o serviço de gravação EMCY, se suportado, com o código de erro 8210h.
RPDO Dicionário de objetos
Objeto A Objeto G Objeto E Índice Sub Conteúdo do objeto
16:00h 00h 03h
16:00h 01h 2000h 01h 08h
16:00h 02h 2003h 03h 10h
16:00h 03h 2003h 01h 08h
2000h 00h 02h
2000h 01h Objeto A
2000h 02h Objeto B
2001h 00h Objeto C
2002h 00h Objeto D
2003h 00h 03h
2003h 01h Objeto E
2003h 02h Objeto F
2003h 03h Objeto G
Figura 70: Princípio do mapeamento RPDO
Índice 1600h às 17FFh
Nome Parâmetro de mapeamento RPDO
Tipo de dados Registro de parâmetro de mapeamento PDO
Obrigatório para cada PDO suportado

Sub-índice 00h
Descrição número de objetos de aplicativo mapeados no PDO
Acesso rw;
const, se o mapeamento não for alterável
Mapeamento PDO Não
Valor padrão
Sub-índice 01h
Descrição 1º objeto de aplicação
Acesso rw;
const, se a entrada de mapeamento não for alterável
Mapeamento PDO Não
Sub-índice 02h às 40h
Descrição 2º objeto de aplicativo para 64º objeto de aplicativo
Acesso rw;
const, se a entrada de mapeamento não for alterável
Mapeamento PDO Não
7.5.2.37 Objeto 1800h a 19FFh: parâmetro de comunicação TPDO
Este objeto contém os parâmetros de comunicação para os PDOs que o dispositivo CANopen é capaz de transmitir.
O subíndice 00h contém o número de entradas de objeto válidas no registro. Seu valor é de no mínimo 02h. Se o tempo de inibição
for suportado o valor é 03h e se o temporizador de evento for suportado o valor é 05h.
O subíndice 01h contém o COB-ID do TPDO (ver Figura 71 e Tabela 70).

31 30 29 28 11 10 0

quadro RTR válido
ID CAN de 29 bits
MSB LSB
Figura 71: Estrutura do TPDO COB-ID
Tabela 70: Descrição do TPDO COB-ID
válido 0b PDO existe / é válido
1b PDO não existe / não é válido
RTR 0b RTR permitido neste PDO
1b nenhum RTR permitido neste PDO
O bit válido (bit 31) permite selecionar quais TPDOs serão utilizados no estado NMT Operacional.
Pode haver PDOs totalmente configurados (por exemplo, por padrão), mas não usados e, portanto, definidos como
"não válidos" (excluídos). O recurso é necessário para dispositivos CANopen que suportem mais de 4 TPDOs, pois
cada dispositivo CANopen possui apenas CAN-IDs padrão para os primeiros quatro TPDOs no conjunto de conexão
predefinido genérico. Dispositivos CANopen que suportam apenas o tipo de frame base CAN ou não suportam RTRs,
uma tentativa de definir o bit 29 (frame) para 1b ou bit 30 (RTR) para 0b
é respondido com o serviço de transferência de aborto SDO (código de aborto: 0609 0030h). Não é permitido alterar o
bit de 0 para 29 enquanto o PDO existir e for válido (bit 31 = 0b). Dispositivos CANopen que suportam a habilitação (bit
31 = 0b) e desabilitação (bit 31 = 1b) de um TPDO somente devem responder com o serviço de transferência de
abortar SDO (código de abortamento: 0609 0030h ou 0800 000h) na tentativa de alterar os valores de bit 0 a 30 bits.
Se o dispositivo CANopen tiver implementado um ou mais perfis de dispositivo, o conjunto de conexão predefinido
genérico deve ser aplicado (consulte a Tabela 67).
Tabela 71: Conjunto de conexões predefinidas genéricas para TPDO

quadro: 0b
RTR: específico do perfil ou do fabricante

quadro: 0b

quadro: 0b


quadro: 0b
1804h CAN-ID: específico do perfil ou do fabricante (consulte a cláusula 7.3.5)

para quadro: específico do perfil ou do fabricante
19FFh RTR: específico do perfil ou do fabricante
Se o dispositivo CANopen tiver implementado um perfil de aplicação, o conjunto de conexão pré-definido específico
desse perfil de aplicação deve ser aplicado.
O subíndice 02h define o caráter de transmissão do TPDO (ver Tabela 72). Uma tentativa de alterar o valor do tipo de
transmissão para qualquer valor não suportado deve ser respondida com o serviço de transferência de aborto SDO (código
de aborto: 0609 0030h).
Tabela 72: Descrição do tipo de transmissão TPDO
Descrição
Valor
síncrono (acíclico)
00h
síncrono (cíclico a cada sincronização)

01h
síncrono (cíclico a cada 2º SYNC)

02h

03h

04h
:::::
:::::

F0h
reservado
F1h
:::::
:::::
reservado
FB
Somente RTR (síncrono)

FC
Somente RTR (orientado a eventos)

FDh
orientado a eventos (específico do fabricante)

FEh
orientado a eventos (perfil de dispositivo e perfil de aplicativo específico)

FF
• Síncrono significa que o PDO é transmitido após o SYNC. O dispositivo CANopen iniciará a amostragem dos dados
com a recepção do SYNC (ver Figura 72). Caso seja acíclico o evento interno do dispositivo CANopen é dado e
com o próximo SYNC a amostragem é iniciada e o PDO é transmitido posteriormente. Caso seja cíclico a
amostragem é iniciada com a recepção de cada SYNC, cada 2º SYNC, cada 3º SYNC,
e assim dependendo do valor dado e o PDO é transmitido posteriormente.

• Somente RTR significa que o PDO não é transmitido normalmente, deve ser solicitado via RTR.
Caso seja síncrono o dispositivo CANopen iniciará a amostragem com a recepção de cada SYNC e então armazenará
o PDO (ver Figura 72). Caso seja acionado por eventos, o dispositivo CANopen iniciará a amostragem com a recepção
do RTR e transmitirá o PDO imediatamente.
• Acionado por evento significa que o PDO pode ser transmitido a qualquer momento com base na ocorrência de um evento
interno do dispositivo CANopen. A definição do evento não se enquadra no escopo desta especificação e pode ser
especificada em perfis de dispositivos e perfis de aplicativos.
•
Figura 72: Sincronização e amostragem do barramento
O subíndice 03h contém o tempo de inibição. O tempo é o intervalo mínimo para transmissão PDO se o tipo de transmissão for
definido como FEh e FFh. O valor é definido como múltiplo de 100 µs. O valor 0 deve desabilitar o tempo de inibição. O valor não
deve ser alterado enquanto o PDO existir (o bit 31 do subíndice 01h é definido como 0b).
O sub-índice 04h está reservado. Não deve ser implementado; neste caso, o acesso de leitura ou escrita leva ao serviço de
transferência de aborto SDO (código de aborto: 0609 0011h).
O subíndice 05h contém o temporizador de eventos. O tempo é o intervalo máximo para transmissão PDO se o tipo de transmissão
for definido como FEh e FFh. O valor é definido como múltiplo de 1 ms. O valor 0 deve desabilitar o temporizador de eventos.
O subíndice 06h contém o valor inicial SYNC. O valor inicial SYNC de 0 deve indicar que o contador da mensagem SYNC não
deve ser processado para este PDO. O valor de início SYNC de 1 a 240 deve indicar que o contador da mensagem SYNC deve
ser processado para este PDO. Caso o contador da mensagem SYNC não esteja habilitado (ver 7.5.2.22) o subíndice 06h deve
ser ignorado. A mensagem SYNC cujo valor do contador é igual ao valor inicial SYNC deve ser considerada como a primeira
mensagem SYNC recebida. O valor não deve ser alterado enquanto o PDO existir (o bit 31 do subíndice 01h é definido como 0b).
NOTA se o dispositivo CANopen detectar na chave para o estado operacional NMT que o valor do contador SYNC recebido é
maior que o valor inicial do SYNC, então o dispositivo CANopen terá que esperar um ciclo completo até que o contador SYNC
correto seja recebido.
Índice 18h00 às 19h00
Nome Parâmetro de comunicação TPDO
Tipo de dados Registro de parâmetro de comunicação PDO
Obrigatório para cada TPDO suportado

Sub-índice 00h
Acesso const
Mapeamento PDO Não
Sub-índice 01h
Descrição COB-ID usado pelo TPDO
Acesso rw;
Mapeamento PDO Não
Valor padrão ver definição de valor
Sub-índice 02h
Descrição tipo de transmissão
Acesso rw;
const, se o tipo de transmissão não for alterável
Mapeamento PDO Não
Valor padrão
Sub-índice 03h
Descrição inibir o tempo
Acesso rw;
const, se o tempo de inibição não for alterável
Mapeamento PDO Não

Sub-índice 04h
Descrição reservado
Acesso rw
Mapeamento PDO Não
Sub-índice 05h
Descrição temporizador de evento
Acesso rw;
const, se o temporizador de eventos não for alterável
Mapeamento PDO Não
Valor padrão
Sub-índice 06h
Descrição Valor inicial de SINCRONIZAÇÃO
Acesso rw;
const, se o valor inicial do SYNC não for alterável
Mapeamento PDO Não
7.5.2.38 Objeto 1A00h a 1BFFh: parâmetro de mapeamento TPDO
Este objeto contém o mapeamento dos PDOs que o dispositivo pode transmitir.
O subíndice 00h contém o número de entradas de objeto válidas no registro de mapeamento ou um valor específico (consulte a
Tabela 73), por exemplo, se o MPDO for suportado. O número de entradas de objetos válidos deve ser o número de objetos de
aplicação que devem ser transmitidos com o TPDO correspondente.
Tabela 73: Valores de mapeamento TPDO
00h Mapeamento desativado
01h Sub-índice 01h válido
02h Sub-índice 01h e 02h válido

::::: :::::
41h reservado
::::: :::::
FDh reservado
FEh SAM-MPDO
FFh DAM-MPDO
O subíndice de 01h a 40h contém as informações dos objetos de aplicação mapeados. O objeto descreve o conteúdo do
PDO por seu índice, subíndice e comprimento (ver Figura 73 e Figura 74).
O comprimento contém o comprimento do objeto do aplicativo em bits. Isso pode ser usado para verificar o mapeamento.
31 16 15 87 0
Índice Sub-índice Comprimento
MSB LSB
Figura 73: Estrutura do mapeamento TPDO
Uma tentativa de alterar o valor de uma entrada de objeto para qualquer valor que não seja suportado deve ser
respondida com o serviço de transferência de aborto SDO. A causa de um valor sem suporte pode ser o mapeamento
(índice e subíndice) de um objeto de aplicativo não existente, um comprimento incorreto para o objeto de aplicativo
mapeado ou um comprimento incorreto para o PDO.
O seguinte procedimento deve ser usado para remapeamento, que pode ocorrer durante o estado NMT Pré-operacional
e durante o estado NMT Operacional, se suportado:
1. Destrua o TPDO configurando o bit válido para 1b do subíndice 01h do parâmetro de comunicação TPDO
correspondente.
2. Desative o mapeamento configurando o subíndice 00h para 00h.
3. Modifique o mapeamento alterando os valores dos subíndices correspondentes.
4. Habilite o mapeamento configurando o subíndice 00h para o número de objetos mapeados.
5. Crie o TPDO configurando o bit válido para 0b do sub-índice 01h do parâmetro de comunicação TPDO
correspondente.
Se durante a etapa 3 o dispositivo CANopen detectar que o índice e sub-índice do objeto mapeado não existe ou o
objeto não pode ser mapeado, o dispositivo CANopen deverá responder com o serviço de transferência de aborto SDO
(código de aborto: 0602 0000h ou 0604 0041h).
Se durante a etapa 4 o dispositivo CANopen detectar que o mapeamento RPDO não é válido ou não é possível, o
dispositivo CANopen deverá responder com o serviço de transferência de abortar SDO (código de abortamento: 0602 0000h
ou 0604 0042h).

Dicionário de objetos
Índice Sub Conteúdo do objeto
1A00h 00h 03h
1A00h 01h 2000h 01h 08h TPDO
1A00h 02h 2003h 03h 10h Objeto A Objeto G Objeto E
1A00h 03h 2003h 01h 08h
2000h 00h 02h
2000h 01h Objeto A
2000h 02h Objeto B
2001h 00h Objeto C
2002h 00h Objeto D
2003h 00h 03h
2003h 01h Objeto E
2003h 02h Objeto F
2003h 03h Objeto G
Figura 74: Princípio do mapeamento TPDO
Índice 1A00h a 1BFFh
Nome Mapeamento TPDO
Tipo de dados Registro de parâmetro de mapeamento PDO
Obrigatório para cada PDO suportado
Sub-índice 00h
Descrição número de objetos de aplicativo mapeados no TPDO
Acesso rw;
const, se o mapeamento PDO não for alterável
Mapeamento PDO Não

Sub-índice 01h
Descrição 1º objeto de aplicação
Acesso rw;
const, se a entrada de mapeamento PDO não for alterável
Mapeamento PDO Não
Sub-índice 02h às 40h
Descrição 2º objeto de aplicativo para 64º objeto de aplicativo
Acesso rw;
const, se a entrada de mapeamento PDO não for alterável
Mapeamento PDO Não
7.5.2.39 Objeto 1FA0h a 1FCFh: Lista de varredura de objetos
O produtor de um SAM-MPDO utiliza a lista de scanners de objetos para configurar quais objetos devem ser transmitidos.
Cada entrada de objeto descreve um objeto que pode ser enviado via MPDO. É possível descrever sub-índices consecutivos
definindo o tamanho do bloco de parâmetros para o número de sub-índices que devem seguir.
As entradas de objetos que não estão configuradas devem ter o valor 0.
31 24 23 16 15 87 0
Tamanho do bloco Índice Sub-índice
MSB LSB
Figura 75: Entrada de objeto da lista do scanner de objetos
Índice 1FA0h a 1FCFh
Nome Lista de scanner de objetos
Categoria Opcional


Sub-índice 00h
Acesso const
Mapeamento PDO Não
Sub-índice 01h
Descrição Digitalizar 1
Acesso rw;
ro ou const, se a entrada Scan não for alterável
Mapeamento PDO Não
Descrição Digitalizar 2 para Digitalizar 254
Acesso rw;
ro ou const, se a entrada Scan não for alterável
Mapeamento PDO Não
7.5.2.40 Objeto 1FD0h a 1FFFh: Lista de despacho de objetos
O consumidor de um SAM-MPDO usa a lista de despacho de objetos como referência cruzada entre o objeto remoto do produtor e
o dicionário de objetos local.
63 56 55 40 39 32 31 16 15 8 7 0
Subíndice Subíndice ID do nó
Tamanho do bloco Índice local Índice do remetente
local do remetente do remetente
MSB LSB
Figura 76: Entrada de objeto da lista de despacho de objetos
Cada entrada de objeto descreve como os dados de um MPDO recebido são transferidos para o dicionário de objetos local.
Se o campo sinalizador for 0 e o ID do nó produtor, o Índice do produtor e o subprodutor

index se ajusta à entrada do objeto e, em seguida, os dados devem ser gravados no objeto local endereçado pelos valores local index e
local sub-index dessa entrada de objeto.
O parâmetro tamanho do bloco permite a descrição de subíndices consecutivos. Exemplo: se o sub-índice 1-9 do emissor deve ser
mapeado para o sub-índice 11-19 do receptor, este intervalo é definido por
Subíndice do remetente = 1
Subíndice Local = 11
Tamanho do bloco =9
As entradas de objetos que não estão configuradas devem ter o valor 0.
Índice 1FD0h a 1FFFh
Nome Lista de despacho de objetos
Categoria Opcional
Sub-índice 00h
Descrição Maior suporte de subíndice
Acesso const
Mapeamento PDO Não
Valor padrão
Sub-índice 01h
Descrição Despacho 1
Acesso rw;
ro ou const, se a entrada de expedição não for alterável
Mapeamento PDO Não

Descrição Despachar 2 para Despachar 254
Acesso rw;
ro ou const, se a entrada de expedição não for alterável
Mapeamento PDO Não

Anexo A (informativo)
Recomendações de implementação
Ao implementar os protocolos, as seguintes regras devem ser obedecidas para garantir a interoperabilidade.
Essas regras tratam dos seguintes aspectos de implementação:
COBs inválidos
Um COB é inválido se tiver um COB-ID usado pelos protocolos especificados, mas contiver valores de parâmetro inválidos de acordo
com a especificação do protocolo. Isso só pode ser causado por erros nas camadas inferiores ou erros de implementação. COBs
inválidos devem ser tratados localmente de uma forma específica de implementação que não se enquadre no escopo desta especificação.
No que diz respeito ao protocolo, um COB inválido deve ser ignorado.
Tempo limite
Como os COBs podem ser ignorados, a resposta de um serviço confirmado pode nunca chegar. Para resolver isso
situação, uma implementação pode, após um determinado período de tempo, indicar isso ao usuário do serviço (time-out). Um tempo
limite não é uma confirmação desse serviço. Um tempo limite indica que o serviço ainda não foi concluído. O aplicativo pode lidar com
essa situação. Os valores de tempo limite são considerados específicos da implementação e não se enquadram no escopo desta
especificação. No entanto, é recomendável que uma implementação forneça recursos para ajustar esses valores de tempo limite aos
requisitos do aplicativo.
Tipo de transmissão PDO 0, 254, 255
Os PDOs de transmissão com estes tipos de transmissão podem ser enviados imediatamente para transmissão tipo 254 e 255 ou com o
primeiro Sync para transmissão tipo 0 após entrar no estado operacional, se não especificado de forma diferente nos perfis
correspondentes.
Visão geral de objetos de dicionário de objetos para comunicação
Tabela 74: Objetos padrão
Índice Nome do objeto Tipo de dados Acc.2 M/O
1000h Tipo de dispositivo VAR NÃO ASSINADO32 ro M
1001h Registro de erro VAR NÃO ASSINADO8 ro M
1002h Registro de status do fabricante VAR NÃO ASSINADO32 ro O
1003h campo de erro pré-definido ARRAY NÃO ASSINADO32 ro O
1004h reservado por motivos de compatibilidade
1005h VAR COB-ID SYNC NÃO ASSINADO32 rw O
1006h Período do ciclo de comunicação VAR NÃO ASSINADO32 rw O
1007h Comprimento da janela síncrona VAR NÃO ASSINADO32 rw O
1008h Nome do dispositivo do fabricante do VAR VIS-STRING const O
1009h Versão de hardware do fabricante VAR VIS-STRING const O
100Ah Versão do software do fabricante do VAR VIS-STRING const O
100Bh reservado por motivos de compatibilidade
100 canais ERA tempo de guarda NÃO ASSINADO 16 rw O
100 Dh Fator de tempo de vida do VAR NÃO ASSINADO8 rw O
2 O tipo de acesso listado aqui pode variar para determinados subíndices. Consulte a especificação detalhada do objeto.

100 Eh reservado por motivos de compatibilidade
100Fh reservado por motivos de compatibilidade
1010h parâmetros de armazenamento ARRAY NÃO ASSINADO32 rw O
1011h ARRAY restaura os parâmetros padrão NÃO ASSINADO32 rw O
1012h ERA HORA DE COB-ID NÃO ASSINADO32 rw O
1013h Carimbo de hora de alta resolução VAR NÃO ASSINADO32 rw O
1014h VAR COB-ID EMCY NÃO ASSINADO32 rw O
1015h VAR Tempo de Inibição EMCY NÃO ASSINADO 16 rw O
1016h ARRAY Tempo de pulsação do consumidor NÃO ASSINADO32 rw O
1017h Tempo de pulsação do produtor WAS NÃO ASSINADO 16 rw O
1018h RECORD Objeto de Identidade IDENTIDADE (23h) ro M
1019h VAR Valor de estouro do contador síncrono NÃO ASSINADO8 rw O
Configuração do dispositivo
1020h ARRAY Verifique a configuração NÃO ASSINADO32 rw O
Armazenamento EDS
1021h ERA Grande EDS DOMÍNIO rw O
1022h Formato de armazenamento VAR NÃO ASSINADO8 rw O
Comando e prompt do SO
1023h Comando RECORD OS COMMANDPAR (25h) rw O
1024h Modo de comando VAR OS NÃO ASSINADO8 Onde O
Interface do depurador do SO RECORD 1025h DEBUG DO SO (24h) rw O
1026h prompt do SO ARRAY NÃO ASSINADO8 rw O
Dispositivos modulares
1027h Lista de Módulos ARRAY NÃO ASSINADO 16 ro M/O***
Comportamento de emergência e erro
1028h ARRAY Consumidor de emergência NÃO ASSINADO32 rw O
1029h ARRAY Comportamento de erro NÃO ASSINADO8 rw O
102Ah reservado
::::: ::::: ::::: ::::: ::::: :::::
11FFh reservado
Parâmetro SDO do servidor
1200h RECORD 1º parâmetro do servidor SDO SDO PARAM (22h) ro O
1201h RECORD 2º parâmetro do servidor SDO SDO PARAM (22h) rw M/O**
::::: ::::: ::::: ::::: ::::: :::::
127Fh RECORD 128º parâmetro do servidor SDO SDO PARAM (22h) rw M/O**
Parâmetro SDO do cliente
1280h RECORD 1º parâmetro do cliente SDO SDO PARAM (22h) rw M/O**

1281h RECORD 2º parâmetro do cliente SDO SDO PARAM (22h) rw M/O**
::::: ::::: ::::: ::::: ::::: :::::
12FFh RECORD 128º parâmetro do cliente SDO SDO PARAM (22h) rw M/O**
13:00h reservado
::::: ::::: ::::: ::::: ::::: :::::
13FFh reservado
Parâmetro de comunicação RPDO
1400h RECORD 1º parâmetro de comunicação RPDO PDO COMMPAR (20h) rw M/O*
1401h RECORD 2º parâmetro de comunicação RPDO COMPARAR DOP (20h) M/O*
::::: ::::: ::::: ::::: ::::: :::::
15FFh RECORD 512º parâmetro de comunicação RPDO PDO COMMPAR (20h) rw M/O*
Parâmetro de mapeamento RPDO
1600h RECORD 1º parâmetro de mapeamento RPDO MAPEAMENTO DE DOP (21h) rw M/O*
1601h RECORD 2º parâmetro de mapeamento RPDO MAPEAMENTO DE DOP (21h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
17FFh RECORD 512º parâmetro de mapeamento RPDO MAPEAMENTO DE DOP (21h) rw M/O*
Parâmetro de comunicação TPDO
1800h RECORD 1º parâmetro de comunicação TPDO COMPARAR DOP (20h) rw M/O*
1801h RECORD 2º parâmetro de comunicação TPDO COMPARAR DOP (20h) rw M/O*
::::: ::::: ::::: ::::: ::::: ::::
19FFh RECORD 512º parâmetro de comunicação TPDO PDO COMMPAR (20h) rw M/O*
Parâmetro de mapeamento TPDO
1A00h RECORD 1º parâmetro de mapeamento TPDO MAPEAMENTO DE DOP (21h) rw M/O*
1A01h RECORD 2º parâmetro de mapeamento TPDO MAPEAMENTO DE DOP (21h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
1BFFh RECORD 512º parâmetro de mapeamento TPDO MAPEAMENTO DE DOP (21h) rw M/O*
Multiplex PDO
1FA0h ARRAY Lista de scanners de objetos NÃO ASSINADO32 rw O
::::: ::::: ::::: ::::: ::::: :::::
1FCFh ARRAY Lista de scanners de objetos NÃO ASSINADO32 rw O
1FD0h ARRAY Lista de despacho de objetos NÃO ASSINADO 64 rw O
::::: ::::: ::::: ::::: ::::: :::::
1FFFh ARRAY Lista de despacho de objetos NÃO ASSINADO 64 rw O
* Se um dispositivo CANopen suporta PDOs, o parâmetro de comunicação PDO correspondente e as entradas de objeto de mapeamento
PDO no dicionário de objetos são obrigatórias. Estes podem ser ro.
** Se um dispositivo CANopen suportar SDOs, os parâmetros SDO correspondentes no dicionário de objetos são obrigatórios.
***
veja a definição do objeto.

CiA 301
Versão 4.2.0

comunicação
A corrigir 1
11 de agosto de 2010

Página 68, Figura 35:
Adicione a seguinte definição na legenda da figura (diretamente após o desenho):
L: Código de comprimento de dados do quadro de dados CAN relacionado
Página 72, Figura 38:
Adicione a legenda da figura no terceiro marcador após “Fabricante-“:
ou perfil
Página 77, Figura 39, Figura 40; página 78, Figura 41, Figura, 42, Figura 43:
Adicione a seguinte definição na legenda da figura (diretamente após o desenho):
ID do nó:
0: todos os dispositivos devem realizar a transição recomendada 1 a
127: somente o dispositivo com este node-ID deve realizar a transição recomendada
Página 84, 7.3.2.2.1:
Adicione ao segundo marcador "Redefinir aplicativo" entre a primeira e a segunda frase o seguinte:
As configurações de ID de nó e taxa de bits são definidas para seus valores de inicialização.
Página 91, Tabela 44:
Adicione as seguintes linhas após “Index 0023h”:
0024h DEFSTRUCT OS registro de depuração
0025h Registro de comando DEFSTRUCT OS
Substitua o “0024h – 003Fh” por:
0026h – 003Fh
Página 96, Figura 52; página 97, Figura 53:
Remova o valor MSB “32” por:
31
Página 97, 7.5.3.4:
Adicione a NOTA no primeiro marcador após “01h”:
seu FEh
Página 103, 7.5.2.13; página 106, 7.5.2.14:
Substitua “código de aborto: 0800 002xh” por:
código de aborto: 0800 0020h, 0609 0030h ou 0800 0000h
Página 126, 7.5.2.32:
Adicione na tabela ENTRY DESCRIPTION para o sub-índice 01h na linha Default value após 00h:
ou perfil específico

Página 121, 7.5.2.29; página 123, 75.2.30:
Substitua na tabela ENTRY DESCRIPTION para o sub-índice 00h na linha de valor padrão “No” por:
Específico do fabricante
Página 133, 7.5.2.35:
Substitua na tabela ENTRY DESCRIPTION para o sub-índice 00h na linha de valor padrão “No” por:
Página 140, 7.5.2.37:
Adicione na tabela ENTRY DESCRIPTION para o sub-índice 00h a linha Default value:
Valor padrão Perfil específico ou fabricante

CiA 301
Versão 4.2.0

comunicação
A corrigir 2
21 de fevereiro de 2011

Altere o título da segunda coluna de “Comentários” para:
Descrição
Altere na 4ª linha e na segunda coluna a palavra “FLOAT” para:
REAL32
Altere na 6ª linha e na segunda coluna a palavra “FLOAT” para:
REAL32
Página 89, 7.4.4:
Altere a palavra “FLOAT” para:
REAL32
2 © CiA 2011– Todos os direitos reservados

CiA 301
Versão 4.2.0

comunicação
A corrigir 3
15 de julho de 2011

Camada de aplicação CANopen e perfil de comunicação – Corrigenda 3
Adicione os seguintes códigos de erro de emergência:
8F01h Erro de salva-vidas ou erro de pulsação causado por node-ID 1 para

para
8F7Fh Erro de salva-vidas ou erro de pulsação causado por node-ID 7F
Página 71, 7.2.7.1:
Substitua na lista numerada na primeira entrada (“0.”) “Após inicialização” por:
Após a INICIALIZAÇÃO do estado NMT
Apague na lista numerada na primeira entrada (“0.”) “se nenhum erro for detectado. Nenhuma mensagem de erro é enviada”
Página 83, 7.3.2.1:
Adicione a seguinte NOTA após a Figura 48:
NOTA Uma transição de estado NMT também é acionada localmente dependendo da configuração do objeto de comportamento de
erro (para detalhes veja 7.5.2.32).
Página 85, 7.3.2.2.4:
Adicione após o primeiro parágrafo o seguinte parágrafo:
O dispositivo que transita para o estado NMT Stopped não deve transmitir um protocolo de transferência de aborto SDO.
Adicione à NOTA após “1003h”:
(isso é possível apenas no estado NMT pré-operacional ou no estado NMT operacional)
Página 95, 7.5.1:
Adicione após a tabela ENTRY DESCRIPTION:
Um parâmetro com atributo de acesso “wo” não deve ser mapeado em TPDOs; um parâmetro com atributo de acesso “ro” não deve ser
mapeado em RPDOs.
Página 98, 7.5. 2.4:
Substitua o valor padrão do subíndice 00h na tabela ENTRY DESCRIPTION por:
Não
Página 116, 7.5.2.24:
Substitua no terceiro marcador “configurações são” por:
as configurações são
Página 117, 7.5.2.25:
Substitua na Tabela OBJETO DESCRIÇÃO o atributo Tipo de dados por:
NÃO ASSINADO8
Substitua na tabela ENTRY DESCRIPTION o atributo Value range por:
Consulte a Tabela 60
Página 118, 7.5.2.26:

Substitua na Tabela DESCRIÇÃO DA ENTRADA o atributo Intervalo de valores para o subíndice 01h e 03h por:
Página 120, 7.5.2.28:
Substitua na Tabela DESCRIÇÃO DA ENTRADA o atributo Intervalo de valores para o subíndice 01h e 03h por:
Página 126, 7.5.2.32:
Substitua na tabela ENTRY DESCRIPTION a última subtabela por:
Sub-índice 02h a 7Eh

Descrição Erro específico do perfil 1 a 125
Acesso rw;
Mapeamento PDO Não
Valor padrão Específico do perfil

Descrição Erro específico do fabricante 1 a 127
Acesso rw;
Mapeamento PDO Não

CIA 301 - CANopen (PT)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CIA 301 - CANopen (PT)

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Especificação disponível ao público

Camada de aplicação CANopen e perfil de

© CAN em Automação (CiA) e. V.

Camada de aplicação CANopen e perfil de comunicação

01-11-1994 Publicação da versão 1.0 como proposta padrão preliminar

01-01-1995 Publicação da versão 1.1 como proposta padrão preliminar

22-09-1995 Publicação da versão 2.0 como rascunho da proposta padrão

1996-10-30 Publicação da versão 3.0 como rascunho da norma

16-06-1999 Publicação da versão 4.0 como padrão de rascunho

01-06-2000 Publicação da versão 4.0.1 como rascunho da norma

13-02-2002 Publicação da versão 4.0.2 como rascunho da norma

15-08-2006 Publicação da versão 4.1 como proposta padrão preliminar

07-12-2007 Publicação da versão 4.2 como proposta padrão preliminar

21-02-2011 Publicação da versão 4.2.0 como especificação pública

Informações gerais sobre licenciamento e patentes

2 © CiA 2011 – Todos os direitos reservados

Camada de aplicação CANopen e perfil de comunicação

1 Alcance................................................. .................................................. .......................................... 12

4 Modelagem ........................................................ .................................................. ....................................... 16

4.2.2 Camada de aplicação CANopen ............................................. .................................................. 17

4.4 Sequências do protocolo de comunicação ............................................. ......................................... 19

5 Camada física ........................................................ .................................................. .............................. 22

5.2 Interface dependente do meio ............................................. .................................................. ... 22

6.2 Tipo de estrutura CAN ............................................. .................................................. ....................... 24

© CiA 2011 – Todos os direitos reservados 3

Camada de aplicação CANopen e perfil de comunicação

7.2 Objetos de comunicação .............................................. .................................................. .......... 31

7.2.2 Objeto de dados de processo (PDO)......................................... .................................................. .... 31

7.2.2.4.3 Serviço de leitura do PDO.............................. .................................................. .... 34

7.2.2.5 Protocolo PDO ............................................. .................................................. .............. 34

7.2.2.5.2 Leitura do protocolo PDO .................................................. ............................................. 35

7.2.3.2.1 Modo de endereço de destino (DAM) ............................................. .......................... 35

7.2.3.3.1 Em geral................................................. .................................................. .............. 36

7.2.3.4 Protocolo MPDO ............................................. .................................................. ......... 36

7.2.4.2.3 Início do download do SDO do serviço ........................................ ................................... 39

7.2.4.2.4 Segmento de download de SDO de serviço ........................................ .............................. 40

4 © CiA 2011 – Todos os direitos reservados

Camada de aplicação CANopen e perfil de comunicação

7.2.4.2.8 Download do bloco SDO do serviço ........................................ ....................................... 43

7.2.4.2.9 Início do download do bloco SDO do serviço ....................... .............................. 43

7.2.4.2.10 Sub-bloco de download do bloco SDO de serviço ...................................... ....................... 44

7.2.4.2.11 Fim do download do bloco SDO do serviço ........................................ .............................. 44

7.2.4.2.12 Carregamento de bloco SDO de serviço ........................................ ....................................... 45

7.2.4.2.13 Inicialização do upload do bloco SDO do serviço................................. .............................. 45

7.2.4.2.14 Sub-bloco de upload do bloco SDO de serviço................................... .......................... 46

7.2.4.2.15 Fim do upload do bloco SDO do serviço ......................... ................................... 47

7.2.4.3 Protocolos SDO............................................. .................................................. ........... 48

7.2.4.3.2 Download do protocolo SDO ............................................. ....................................... 48

7.2.4.3.3 Início do download do protocolo SDO ............................................. ....................... 49

7.2.4.3.4 Segmento de download do protocolo SDO ............................................. ......................... 50

7.2.4.3.9 Início do download do bloco SDO do protocolo ............................................. ................... 53

7.2.4.3.10 Sub-bloco de download do bloco SDO do protocolo ....................... ....................... 55

7.2.4.3.11 Fim do download do bloco do protocolo SDO ........................................ ......................... 56

7.2.4.3.12 Carregamento de bloco de protocolo SDO ........................................ ....................................... 57

7.2.4.3.13 Inicialização do upload do bloco SDO do protocolo ........................................ ......................... 58

7.2.4.3.14 Sub-bloco de upload de bloco de protocolo SDO ..................................... .............................. 59

7.2.4.3.15 Fim do upload do bloco SDO do protocolo ....................... ......................... 59

7.2.5 Objeto de sincronização (SYNC) ............................................. .......................................... 62

7.2.5.2 Serviços de SINCRONIZAÇÃO............................................. .................................................. ......... 62

7.2.5.2.1 Em geral................................................. .................................................. .............. 62

7.2.5.2.2 Gravação de SINCRONIZAÇÃO de Serviço ............................................. .................................................. 62

7.2.5.3 Protocolo SYNC ............................................. .................................................. ......... 63