English is currently available.
CAN & CANopen DISCUSSION
I connected a CANopen servo drive (node ID 5) to a USB-CAN adapter at 250 kbit/s. At power-up I see one frame with ID 0x705 and data 00, and then every second a frame 0x705 with data 7F. The manual says the position is in TPDO1, but no such frame ever appears, although I can read the object dictionary with an SDO tool.
What state is the drive in, and what do I have to send so that it starts transmitting process data? How are these CAN IDs derived from the node ID?
The drive is telling you its state. 0x700 + node ID is the NMT error control identifier. The single frame with data 00 is the boot-up message, and the periodic frame is the heartbeat, whose data byte is the NMT state: 0x7F is pre-operational, 0x05 is operational and 0x04 is stopped.
In pre-operational a node answers SDOs, which is why your configuration tool works, but it does not send or accept PDOs. Process data flows only in the operational state, and a node does not go there on its own unless it has been configured to start automatically. An NMT master has to command it.
The NMT command is a two-byte frame with CAN ID 0x000: the first byte is the command and the second is the target node ID, where 0 addresses all nodes. The commands are 0x01 start (go operational), 0x02 stop, 0x80 enter pre-operational, 0x81 reset node and 0x82 reset communication.
So send ID 0x000 with data 01 05. The heartbeat should change to 05, and TPDO1 should appear according to its transmission type: on a change of the mapped data, cyclically on an event timer, or in response to SYNC frames (ID 0x080) if it is configured as a synchronous PDO. If nothing appears after the start command, check the transmission type and event timer in object 0x1800.
The identifiers come from the predefined connection set: a function code plus the node ID (1 to 127). The defaults are NMT 0x000, SYNC 0x080, emergency 0x080 + node, TPDO1 0x180 + node, RPDO1 0x200 + node, TPDO2 0x280, RPDO2 0x300, TPDO3 0x380, RPDO3 0x400, TPDO4 0x480, RPDO4 0x500, SDO response from the node 0x580 + node, SDO request to the node 0x600 + node, and heartbeat 0x700 + node.
For node 5, the position in TPDO1 will arrive with ID 0x185, SDO requests go to 0x605 and the answers come from 0x585. Because lower IDs win arbitration, this layout also gives NMT, SYNC and emergency messages priority over PDOs, and PDOs priority over SDOs.
The difference between the two data services: an SDO is a confirmed request/response access to one object dictionary entry, addressed by a 16-bit index and an 8-bit subindex. It is used for configuration and is comparatively slow, since an expedited transfer carries at most 4 data bytes per exchange. A PDO is an unconfirmed frame of up to 8 data bytes with no protocol overhead; both sides know from the PDO mapping which objects are packed into which bytes.
The mapping lives in the dictionary: communication parameters for TPDOs start at 0x1800 and their mapping at 0x1A00; for RPDOs at 0x1400 and 0x1600. Read 0x1A00 on your drive to see what TPDO1 contains before decoding the bytes. Multi-byte values are little-endian.
For a drive, reaching operational is only the network part. Motion drives follow the CiA 402 device profile, which has its own state machine on top, controlled through the controlword (object 0x6040) and reported in the statusword (0x6041). The usual enable sequence writes 0x0006 (shutdown), 0x0007 (switch on) and 0x000F (enable operation) to the controlword, checking the statusword after each step. Until that is done the drive reports its position but does not accept motion commands.
If the drive is in a fault state it also sends an emergency frame, on 0x085 for node 5, with an error code that the manual decodes.
