EtherCAT servo drives

EtherCAT ports

EtherCAT connections follow the standard Ethercat topologies:

• Port 0: IN (input) port, which has to be connected always.

• Port 1: OUT (output) port, which has to be connected to more EtherCAT sub devices in the network and/or for closed ring topologies.

EMCY service

The EMCY service is an asynchronous producer-consumer protocol on which the producer indicates that an error has been detected by sending an EMCY message. The consumer can easily know the error source that has been detected by the node at the error instant without polling the status word or the error register. 

Each produced EMCY message is reflected in register 0x1001. The EMCY message can both indicate that an error has been produced and also that an error condition has been removed (error code "no error"). Each error indicates the code of the error, and also the affected module. 

An emergency object is sent only once per error event.

The data content of the emergency message uses the following structure:

Example of EMCY

Event (Twincat captures)	Description
	Drive reports an emergency message indicating an user under-voltage detected (0x3241) in the subnode 1. Register 0x1001 = 5 indicates the active error with its corresponding bits 0 and 2 set to 1.
	Drive indicates that the error condition in the subnode 1 has been removed (errorcode = 0x0000). Register 0x1001 = 0 indicates that there are no other active errors at this moment. This EMCY message has been sent in the fault reset event.

FSoE Frame Construction Rules

This section provides implementation guidelines for constructing valid FSoE (FailSafe over EtherCAT) frames specifically for Novanta drives. While most of the rules described here are already defined in the official FSoE standard, this guide clarifies how they apply in the context of Novanta’s firmware and highlights any additional constraints or conventions relevant to our systems.

Frame structure:

• Each FSoE frame must begin with a CMD field.

• Each FSoE frame must end with a ConnID field.

• Frames may contain 1 to 8 blocks of safe data (payload), each block being word-sized (2 bytes).

  • Exception: If the frame contains only one block, it may be either 8 bits or 16 bits.

• FSoE TPDO (Safe Inputs) and RPDO (Safe Outputs) frames may differ in size.

• Each safe data block is followed by a CRC_N, where N is the block index starting from 0.

• A frame can contain up to 45 objects in total.

Safe Data (Payload) Mapping Rules

• Supported object data type sizes are 1, 8, 16, and 32 bits.

• Padding blocks may range from 1 to 16 bits.

• 16-bit and larger objects must be word-aligned (16 bit) within the payload.

• Only 32-bit objects may be split across multiple safe data blocks.

• Any padding following a split object must exactly match the remaining size of that object.

• The STO command must always be mapped to the first position in the Safe Inputs and the Safe Outputs payload.

• The SOUT command must always be mapped to the second position in the Safe Inputs and the Safe Outputs payload if SOUT disable is not set.

• If Feedback scenario is set 0, no motion-dependent safety functions are allowed.

  • Only STO, SS1-t and SOUT commands are allowed.

  • Safe Input value is allowed, but cannot be mapped to SS2 or SS1-r.

• If SOUT disable is set to 1, no SOUT-dependent safety functions are allowed.

  • SOUT command is not allowed.

  • STO activate SOUT and SS1 activate SOUT are not allowed to be enabled.

  • Safe Input cannot be mapped to SOUT.

  • Safe Input cannot be mapped to STO or SS1 if they activate SOUT.