O Reset state é o ponto de entrada de toda conexão FSoE (Fail Safe over EtherCAT). A conexão entra nele após o power-on, após um restart (reset connection) ou sempre que um erro de comunicação FSoE é detectado. Enquanto a conexão está nesse estado, nenhum dado de segurança do usuário é trocado — os Safety PDUs são reaproveitados para carregar o comando Reset junto com um código de erro de um único byte que informa ao peer por que a conexão foi reiniciada.
Este artigo percorre os três PDUs do Reset state definidos na ETG.5100 S (D) V1.2.0, §8.2.2.2, usando o exemplo canônico da especificação de 4 octetos de safety data. Para os layouts completos de 2/4/6/8 octetos, consulte FSoE Reset PDU: Master and Slave Structure.
Nota — o número de bytes de safety data é fixo por direção. Cada conexão FSoE tem um safety data length fixo (master→slave e slave→master), configurado de forma idêntica em ambos os nós. Os tamanhos permitidos são 1, 2, 4, 6 ou 8 octetos. O tamanho real para uma dada conexão depende do dispositivo FSoE slave e deve ser obtido na documentação do slave ou no arquivo de descrição do dispositivo (ESI/EEPROM). Os exemplos abaixo usam 4 octetos como na especificação; o layout de bytes para outros tamanhos é mostrado em FSoE Reset PDU: Master and Slave Structure.
Nota — o único byte de dados relevante é o código de erro. Em cada PDU do Reset state,
SafeData[0](octeto 1) é o único byte de safety data que carrega algum significado:
0x00— reset intencional (power-on, restart / reset connection), ou a confirmação do slave de um Reset do master.- Não zero — o código de erro de comunicação FSoE que acionou o reset (consulte Tabela 28 abaixo).
Todos os outros octetos de SafeData são não utilizados e devem ser definidos como 0. O campo Conn_Id também é não utilizado (definido como 0) — ele só é verificado após a conexão ter sido estabelecida. Os campos de CRC ainda são transmitidos e ainda devem verificar, mas são calculados a partir do reset initial state porque o número de sequência e o CRC herdado são limpos na entrada do Reset (consulte FSoE: How does CRC inheritance work? e How to compute the CRC checksum for FSoE PDUs?).
Quando o Reset state é entrada e saído?
O Reset state reinicializa a conexão FSoE após o power-on ou após um erro de comunicação. Duas coisas são reiniciadas na entrada:
- o número de sequência, e
- o CRC do último telegrama que foi usado no cálculo de CRC (ou seja, a cadeia de herança de CRC é quebrada).
As transições de estado são assimétricas, refletindo os papéis master/slave:
| Direção | Condição |
|---|---|
| Master sai de Reset | Envia um Safety Master PDU com o comando Session ao slave. |
| Slave sai de Reset | Recebe um Safety Master PDU válido com o comando Session. |
Em outras palavras, o master sai de Reset emitindo o comando Session, e o slave sai de Reset assim que aceita esse Session PDU. Enquanto ambos os lados ainda estão em Reset, eles trocam Safety PDUs carregando o comando Reset, como mostrado abaixo.
Master Reset PDU (FSoE Master → Slave)
O master envia este PDU após um restart ou após detectar um erro de comunicação FSoE. O exemplo abaixo é a Tabela 10 da ETG.5100 S (D) V1.2.0 para 4 octetos de safety data.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | error code Octet 1 — 0 for restart | 0 Octet 2 — unused | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
Pontos-chave:
- Command (octeto 0) é
Reset. - SafeData[0] (octeto 1) carrega o código de erro (bits 0–7). Um valor de
0x00significa um restart simples / reset connection; qualquer valor não zero identifica o erro de comunicação que acionou o reset (consulte a tabela abaixo). - Todos os outros octetos de SafeData são não utilizados e definidos como 0.
- CRC_0 e CRC_1 ainda são transmitidos como valores little-endian de 16 bits, mas como o número de sequência e o CRC herdado foram reiniciados na entrada, eles são calculados a partir do reset initial state — não encadeados do frame anterior.
- Conn_Id é não utilizado e definido como 0 no Reset state. O connection ID só é verificado após a conexão ter sido estabelecida.
Slave Reset PDU — confirmando um Reset do master (FSoE Slave → Master)
Quando o slave recebe um comando Reset válido do master, ele o confirma enviando um Safety Slave PDU com o comando Reset e todos os octetos de SafeData definidos como 0 — incluindo a posição do código de erro. Esta é a Tabela 11 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | 0 Octet 1 — acknowledgement | 0 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 | 0 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
A única diferença em relação ao master Reset PDU é que SafeData[0] é sempre 0 — o slave não ecoa um código de erro ao confirmar. Um código de erro zero nessa posição é exatamente o que o master usa para reconhecer a confirmação.
Slave Reset PDU — reset iniciado pelo slave (FSoE Slave → Master)
O slave pode ele mesmo iniciar um Reset, seja durante um restart (reset connection) ou no caso de um erro que detectou localmente. Nesse caso, ele envia um Safety Slave PDU estruturalmente idêntico ao master Reset PDU: o comando Reset é definido, e SafeData[0] carrega o próprio código de erro do slave (0x00 para um restart simples). Esta é a Tabela 12 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | error code Octet 1 — 0 for restart | 0 Octet 2 — unused | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
O master confirma esse Reset iniciado pelo slave não enviando outro Reset PDU, mas saindo do Reset state: ele envia um Safety Master PDU com o comando Session, que é o sinal para ambos os lados saírem do Reset.
Juntando tudo: a troca do Reset state
Os três PDUs acima formam um pequeno handshake que depende de quem iniciou o reset:
- Reset iniciado pelo master: Master envia Reset (com código de erro) → Slave confirma com Reset (SafeData = 0) → Master envia Session para sair do Reset.
- Reset iniciado pelo slave: Slave envia Reset (com código de erro) → Master envia Session para sair do Reset (esta é a confirmação do master).
Em ambos os casos, a conexão só sai do Reset state quando o master emite o comando Session; até então, cada PDU no meio carrega o comando Reset, o campo Conn_Id é 0, e o único payload com algum significado é o byte único de código de erro em SafeData[0].
Códigos de erro de comunicação FSoE (Tabela 28)
O código de erro carregado em SafeData[0] de um Reset PDU é retirado da tabela a seguir. Um valor de 0x00 significa “nenhum erro” — ou seja, um reset local ou a confirmação de um comando Reset. Os códigos 1–11 são definidos pelo padrão; 0x80–0xFF são reservados para erros de SafePara específicos do dispositivo.
| Código de erro | Descrição |
|---|---|
| 0 | Reset local ou confirmação de um comando RESET |
| 1 | Comando inesperado (INVALID_CMD) |
| 2 | Comando desconhecido (UNKNOWN_CMD) |
| 3 | Connection ID inválido (INVALID_CONNID) |
| 4 | Erro de CRC (INVALID_CRC) |
| 5 | Watchdog expirou (WD_EXPIRED) |
| 6 | FSoE Slave Address inválido (INVALID_ADDRESS) |
| 7 | Safety data inválido (INVALID_DATA) |
| 8 | Communication parameter length inválido (INVALID_COMMPARALEN) |
| 9 | Communication parameter data inválido (INVALID_COMPARA) |
| 10 | Application parameter length inválido (INVALID_USERPARALEN) |
| 11 | Application parameter data inválido (INVALID_USERPARA) |
| 0x80–0xFF | SafePara inválido (específico do dispositivo) |
Resumo
No Reset state, o FSoE Safety PDU é efetivamente um envelope de diagnóstico de um byte: o campo Command é Reset, SafeData[0] carrega o código de erro (ou 0 ao confirmar), todos os outros octetos de SafeData e o campo Conn_Id são 0, e os CRCs são recalculados a partir do reset initial state porque tanto o número de sequência quanto o CRC herdado foram limpos na entrada. A conexão sai do Reset apenas quando o master envia o comando Session — o slave nunca envia Session, ele apenas confirma Reset zerando seu SafeData.
Referências
- ETG.5100 S (D) V1.2.0, §8.2.2.2 Reset state, Tabelas 10–12 e Tabela 28.
Artigos relacionados
Visão geral e noções básicas
- What does the FSoE abbreviation actually mean? — o que significa a sigla FSoE
- FSoE frame structure explained by examples — layout geral do Safety PDU
- All the states of the FSoE state machine — os cinco estados FSoE e suas transições
- FSoE: Safety PDU command table — a lista completa de comandos FSoE
Estruturas PDU por estado
- FSoE Session PDU: Master and Slave Structure — layout do PDU para o estado Session
- FSoE Connection PDU: Master and Slave Structure — layout do PDU para o estado Connection
- FSoE Parameter PDU: Master and Slave Structure — layout do PDU para o estado Parameter
- FSoE Data PDU: Master and Slave Structure — layout do PDU para o estado Data
- FSoE Reset PDU: Master and Slave Structure — layouts de bytes para todos os tamanhos de safety data
CRC
- FSoE CRC: Which polynomial does it use? — o polinômio de 17 bits por trás do CRC FSoE
- How are the FSoE CRC tables constructed? — como as lookup tables do CRC são geradas
- FSoE: How does CRC inheritance work? — como a cadeia de CRC vincula PDUs consecutivos
- How to compute the CRC checksum for FSoE PDUs? — algoritmo de cálculo de CRC byte a byte
Códigos de erro e formato de dados
- FSoE: List of all communication error codes — todos os códigos de erro de comunicação FSoE
- FSoE: Is data transmitted little-endian or big-endian? — ordem de bytes de campos multi-byte