Differences

This shows you the differences between two versions of the page.

--- can_communication_with_controllers [2019/02/12 12:33] – adrien
+++ can_communication_with_controllers [2019/02/13 10:16] – [SDO CAN frame structure] adrien
@@ Line 22: / Line 22: @@
 > The QuimBox controllers implement a subset of the CANopen protocol. Namely the message layout is completely compatible and the OD concept is reused.
-===== CAN frame structure =====
+===== SDO CAN frame structure =====
-An SDO can frame is structured this way:
+An SDO can frame is structured as follow:
-^ Can id  ^  DLC  ^  ??  ^  OD idx  ^  OD subidx  ^  data  ^
+^ Can id  ^  Command byte ^  OD Idx  ^  OD subidx  ^  data  ^
-|  16 bits  |  8 bits  |  8 bits  |  16 bits  |  8 bits  |  32 bits  |
+|  16 bits  |  8 bits  |  16 bits  |  8 bits  |  32 bits  |
-e.g. A request to enter a QuimDC with can id 7 in operational mode.
-^ Can id  ^^  DLC  ^  ??  ^  OD idx  ^^  OD subidx  ^  data  ^^^^
+The can id is composed of the RX/TX identifier and the board identifier. (can id = RX/TX-id + Node-id)
-|  00  |  07  |  08  |  23  |  33  |  33  |  00  | 00  |  00  |  00  |  01  |
+> TX-id = 600
+> RX-id = 580
+Note: RX/TX from host point of view. On board the convention is opposite.
-One can test the connection with a linux based host using can-utils tools with cansend and candump.
+The command byte is either 0x23 for 32bits writing request, 0x2f for 8bits writing request or 0x40 for reading request (always 32bits response).
+One can test the connection with a linux host using can-utils tools with cansend and candump commands.
+**ex.** A request to enter a QuimDC in operational mode. (32bits write request) (Node-id = 3)
+^ Can id  ^  Command byte ^  OD idx  ^  OD subidx  ^  data  ^^^^
+|  603  |  23  |  3333  |  00  |  01  |  00  |  00  |  00  |
 <code>
-cansend 007#2333330000000001
+cansend 603#23.3333.00.01.00.00.00
 </code>
 ====== QuimDC OD ======