Lcnc & Ethercat data types, Ethercat automated hal pin setup.

Hi all,

I was wondering why lcnc don't have the data types U8, U16, S8, S16 to use with ethercat lcec?
To me it looks like the lcec is some times loading S32 types (bigger data types) when it could load a U8.
The result is in-effiecient memory management. Don't get me wrong if this is not the case.

This issue came to light when i made a few tests to automate the ethercat hal pin setup for lcnc.
After automated hal pin setup worked i added new hal data types into the lcnc source code : U8, U16, S8, S16

Now the ethercat data types can be used 1:1 with lcnc.
For example a ethercat U16 is loaded into a hal pin off type U16 and
not as a U32 as before. This saves us the memory size of a U16 i guess?

Mention the automated hal pin names and the new data types:


In above picture, a component called ecad.so is loaded in hal. (lcec replacement)
The component name: ecad.so

When the component start's up, it load's c++ code that has a automated hal pin setup under the hood,
looking what kind off data types are used etc.
Setting up the hal pins :  hal pin setup

And at runtime update the hal pins every cycle :
Update hal pins: hal_pin_update

So far above situation works quite well.

In the ecad.so component we don't need any .xml config file anymore.
As the component just throws out all hal pins from the ethercat bus by itself.

What i didn't code yet, is time dc synchronisation. I tested a stepper config in axis, and steppers run just
as fast as using the linuxcnc-ethercat config. However i am on a really bad desktop pc.
Axis stepper config, driving one stepper motor: axis config
 

halType is limited to the data type that are in hal: bit, float, s32, u32.
Whatever comes from ethercat will be shoe-horned into one of those.

What I see many times is the difficulty the get the xml file right both in relation to the ethercat device and in relation to the hal code.
Unfortunately, halshow et al aren't available until linuxcnc is started and it doesn't start until the xml is right.

I hope to get to test this this week as well as the s-curve modification. Waiting for a test system.

It isn't bad with a xml file as such. There can be the same pdo in several places, and one need to pick the right one.
I doubt an automatic system can handle all situations.
For prototyping and creating a config, a graphics tool is really nice. But for production I don't mind a static config.
It isn't supposed to change. If it does something is wrong.