Cannot use ethercat terminals sending more than 1 byte.

Right, *facepalm* you asked me to ignore that error.
lcec.so and lcec_conf are generated just fine. However i receive the same error as with my own attempt: "lcec: dlopen: /usr/lib/linuxcnc/modules/lcec.so: undefined symbol: lcec_ax5200_init"

I could try commenting all other drivers in the lcec_conf.c an .h as db1981 pointed out
EDIT: tried this with the EL2004(1byte), El3202(8byte) and El1002(1byte), and received 9 bytes. the error persists :-/

I was able to get correct amount of byte in the stack 2004, 2014, 1002, by making the el2014 a generic type writing full mapping in the xml file - following this guide
I could control digital out correctly, but some of the diagnostic data from the el2014 did not work such as the "open load" signal

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?