Cannot use ethercat terminals sending more than 1 byte.

So i just found this pull request of the linuxcnc-ethercat by Scott Laird. He also wrote drivers for the el3004(actually he was smart and created el30x4) and el3202.
The only difference between his 30x4 and my 3004 is a pdo entry called sync_error with subindex 0x0e and an extra gap. Which i cannot see where he found. I looked again the cstruct, in the device xml and in Twincat, there is no entry like that. Nevertheless i now get the correct amount of bytes with the stack 2004, 3004, 1002, with everything seemingly working fine.
Any ideas where this entry comes from?

I will experiment with adding this entry to other device drivers

Hi Stormhold,

Now we now a little more.

That's a clever tryout. The generic.c is a compact file with ~300 lines of code.
I studied the generic.c a little bit.

I think setting up the hal pin's can be done easyer and more direct at first sight. Maybe after more studing the file i can come
to another conclusion why it's done this way.
If you follow the symbol under the cursor for "lcec_pin_newf" you will get into lcnc_main.c function lcec_pin_newf, from there
the lcec_pin_newfv will go to another function wich in the end will do a "hal_pin_new".

Setting up the s32 is quite confusing. Does this work or does this nothing at line 64. It would be nice if there is code in that case.
If it misses the hal pin setup, we could miss data.

The nice thing is i can edit and test generic driver myself.

Is the uint8_t, used for bitoffset, bitlenght some thing to worry about? Or is this fail safe?

I believe i have found the solution. I had misunderstood the define: LCEC_ELXXXX_PDOS in the drivers .h files.
I thought it was a number determined by the total number of ec_pdo_entry_info_t
However it is actually determined by the number of times the LCEC_PDO_INIT is called. I now have every driver except the el3202 working.

I tried writing a generic type description of the el3202, but have been unable to make it work, and now i cant even get el3202 to work in Twincat. Can use of incorrect generic type compromise the devices somehow?