resolved-- Regarding the data reading offset issue of the ether cat IO module

When I was testing this signal input, I found that when I turned on LED0, the corresponding IO PIN was lit up at pin number 16. Similarly, the output position was also the same. In summary, the data I currently receive has been shifted by 16 bits. Additionally, I have attached my XML and the test results from Beckhoff (they are all OK). Could someone kind-hearted please tell me why?



Changed to a different model of the product. This model does not fit the IGHmaster.

why not use the native driver
<slave idx="3" type="EL2809"/>

Are you Chinese? If yes, add me on QQ: 304394405

RODW, as you said, is correct. In the EL2809 module, I used it like this, and at the same time, testing the "general" driver and adding hal manually was also without any problems. However, problems arise when using this "Sdot" module. I received the data related to this module. Each piece of data corresponding to the PDO will be shifted by 16 bit.

I don't know why, but we can try to find out why.

Can you replace the lines that creates all the input pins and out pins with "complexentry", there are several examples above in the file.
Do you still get the shift?

Sorry, due to my personal technical reasons, the detailed explanation of this issue will be very verbose.
In fact, I have made a detailed list of pins. Derived from idx00~31, the test results are the same. Additionally, I also tested other models of modules, and the xml used was almost exactly the same, but the test results were fine. Meanwhile, I received a message in other communities: Someone used the module of the same brand (with a different model), and the test results were fine.
I have recently conducted more module tests made in China and discovered some patterns. I will release the results later.
The current apparent result is that for the module I mentioned above, Linuxcnc can only read 16-bit data originated from ethercat PDO. Even for a data range of 32 bits.
Here are some examples: Please look at the picture
For this kind of problem, I plan to conduct network data packet analysis later. Later, I will provide detailed network data results. Thank you all.

Thank you for your kind help. I have already conducted a joint investigation with OFF in the group. At present, there is no good solution for the time being.

Have you tried in TwinCAT? Does it work there? If not, the device is faulty.

Currently, I have switched to the Codesys platform, and everything is functioning normally. It is similar to TwinCAT.

Can you please confirm that you do not see the 16-bit shift in Codesys.

Can you also please confirm that you see/don't see the 16-bit shift in linuxcnc using <complexentry>

Please show the output when you in linuxcnc enter test-values for the bit-outs pins. Do all  32 pins individually.

Change the line <pdoEntry idx="7010" subIdx="01" bitLen="32" halPin="bit-out" halType="bit"/> to <pdoEntry idx="7010" subIdx="01" bitLen="32" halPin="bit-out" halType="u32"/> and redo the bit output test. Do one bit at the time. All 1,2,4,8,16, 32, 64,128, and so on up to the 31th bit.

Show the input and output for all these tests in a way that one clearly can see and correlate the linuxcnc input and the drive output.

Can you please show the output of "ethercat -p 1 -m 1 pdos" Modify the p and m field values as needed to get the output from the tested unit.

Can you please provide a screenshot from Codesys of the definition of the output variable. To include at least pdo index, pdo entry index, subindex, datatype and datatype length.