CANOpen SDO: Unexpected data frame value

Hi;

I have an SBLM2360T controlling a custom BLDC motor and have built a CAN Bus upon which are two Arduino boards & Seeed CAN Bus shields.
I am able to write a command to the bus successfully and get a response, but the data frame value is not what is expected. 
I am sending the SDO command 0x2101 sub01, "Read Actual Motor Command", which I am changing with Roborun+. I am getting back most of what is expected: Header is 0x580 + node_id, Index is 0x2101, Sub Index is 0x01, and the data is the motor command, which I can see change as I change the motor command. 
However, the Byte0 value of the payload, the data frame is 0x43, which is 01000011 in bits. I expected 0x48 back because bits 0 and 1 are unused and bits 3 and 4 should be set to "10" to indicate that 2 of the 4 data bytes are unused since the value is an S16 according to page 34 of the CAN Networking Manual V2.0 dated July 8, 2019.
I've verified the data frame with a logic analyzer (image attached). 
I'd appreciate any corrections or guidance. Thanks so very much.

Hi Athanasios, 

Thanks again for your time and assistance. I see that the expectation of 0x48 is indeed incorrect due to the S32 data type. Bits 2 & 3 should indeed be off to indicate 0 data bytes without data.
I was surprised by bits 0 & 1 being on. I found the CANOpen Standard at www.esacademy.com/assets/docs/CANopenAPI.pdf and page 9 documents the values of the status byte for the CANOpen Task. Since these bits are "not necessary for basic operation", is it safe to mask them for comparing the data frame value in the code? For example, I would expect 0x40 to be returned because I don't know what bits 0 and 1 might be so I could take the return value, 0x43 and AND it with 0xFFFC to get 0x40 for comparisons.
Or, it is necessary to pay attention to bits 0 and 1 in byte 0?
Thanks again for your assistance,
pdp

Actually, there seems to be a conflict in the documentation.
The CANBus Networking Manual (V2.0 July 8, 2019) page 34 indicates that the data type for 0x2101 "Read Actual Motor Command" is type S16 and the command value is "M".
However, the Advanced Digital Motor Controller User Manual (V2.0, July 8, 2019) page 228 indicates that the command "M" "Read Motor Command Applied" is type Signed 32.
I've dug further into the CANOpen Standard (fascinating reading) to see if I could find something to explain why bits 0 and 1 would be set in the data frame, but haven't found an explanation.
So, I'm still a bit confused why 0x43 is valid and have been filtering out bits 0-1 from the response data frame values in my tests to get the value 0x40 (assuming S32 data type).

Hi Athanasios;

Many thanks again for your time and assistance. I promise, my friend, that the copy I had stated the type is S16 even through the version and date of the document are the same. I've downloaded a new copy of the CAN Networking Manual which has the correct S32 value for the 0x2101 query.
Thank you for the pointer to the information on the "e" and "s" bits in Byte 0.
I am greatly comforted that I have a full understanding of information I'm receiving. 
Now if I could only get a runtime command to actually move the motor. Working on that ;-)

pdp