I have a Robotiq 2-finger gripper, connected to a RS-485 UART adapter and a 24V power supply, and a python program that controls the gripper via serial UART commands. This works perfectly. I can open and close the gripper fine.

Refer below to the 2-finger manual from Robotiq and example blog post with a Python program:

https://blog.robotiq.com/controlling-the-robotiq-2f-gripper-with-modbus-commands-in-python
https://assets.robotiq.com/website-assets/support_documents/document/2F-85_2F-140_Instruction_Manual_e-Series_PDF_20190206.pdf

I've made some slight changes to the example program to move from Python2 to Python3 compatibility, such as print syntax.

In the example program, there are four strings of hexadecimal bytes.
The example works perfectly and my hardware works perfectly, but I'd like to understand how these byte strings are made, how they are derived from the documented Robotiq MODBUS RTU commands in the gripper manual.

Activation request: 09, 10, 03, E8, 00, 03, 06, 00, 00, 00, 00, 00, 00, 73, 30 [15 bytes]

Status request: 09, 03, 07, D0, 00, 01, 85, CF [8 bytes]

Close gripper: 09, 10 ,03, E8, 00, 03, 06, 09, 00, 00, FF, FF, FF, 42, 29 [15 bytes]

Open gripper: 09, 10, 03, E8, 00, 03, 06, 09, 00, 00, 00, FF, FF, 72, 19 [15 bytes]


Referring to the register documentation in the gripper manual:

Byte 0: Action Request / Gripper Status
Byte 1: Reserved / Reserved
Byte 2: Reserved / Fault Status
Byte 3: Position Request / Position Request Echo
Byte 4: Speed / Position
Byte 5: Force / Current
Byte 6 to 15: Reserved / Reserved

Why are the example byte arrays in the program 15 bytes, and not 16 bytes which would seem to match the documentation?

Why is the status request only 8 bytes? Which bytes go into this status request?

I assume the array is big-endian, or is it? (It can't be the other way around, because the first 6 bytes don't change at all when opening or closing the gripper.)

For example, would it be correct to say the activation request starts with 0x09 (byte 14), 0x10 (byte 13), 0x03 (byte 12) etc?
(And I'm not sure where to pad or remove the missing byte to make it match the 16 bytes documented.)

If this is correct, then these first 10 bytes are "reserved" bytes - can they be replaced with anything like 0x00 or do they have to have particular values?
I note the activation request is 0x00 at byte 7 but it's 0x09 for the open gripper and close gripper commands - so its value has some important meaning even though it's within the "reserved" (and undocumented) space? (And "reserved" Byte 1 appears to be different in the different commands?)

And are the individual bits in the bytes big-endian?

For example, the Activation request in the example code has Byte 0 as 0x30, and the Close Gripper part has Byte 0 as 0x29.

0x30 is 0011 0000, 0x29 is 0010 1001

Bit 7: Reserved
Bit 6: Reserved
Bit 5: rARD
Bit 4: rATR
Bit 3: rGTO
Bit 2: Reserved
Bit 1: Reserved
Bit 0: rACT

rARD is set (auto-release direction) is set during the close-gripper movement, but rATR (emergency auto-release) is not set, so it seems a bit weird that rARD is set.

rGTO is set during the closing gripper movement, which makes sense, and rACT is set during the close gripper movement (which I guess makes sense, although I expected it would be set during the activation request).

The activation request (byte 0 0x30) does not have rACT asserted (seems surprising) and it does have rATR and rARD both asserted, which I don't understand.

Can anyone provide some more documentation about how these control bytes are constructed, how they are derived from the register documentation?