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.

Hi Hakan,

I did some extra coding and found a problem.
It turned out i used pdos info so far and not sdos info.
I see sdos can give more detailled info of the device. This is exactly what i need to get the used datatypes to set up the 1:1 hal pins and
their names.

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.
This is stupid, this i really don't get.
We have a 4x40mm screw and we put it in a 20ft sea container, because we don't have other storage available.

I hope to get to test this this week as well as the s-curve modification.
The scurve runs fine in a simulation. But on real hardware most testers have problems with acceleration.
So i have to review that soon.

All available hal components work with s/u32 pins
There is no point in having 16bit numbers from ethercat, because to connect to subsequent components they will have to be converted to 32bit anyway by loading additional components to convert 16->32.
The LCEC component does this automatically in the XML configuration.  pdoentry

In practice, there will probably never be any memory problems, as the number of pdos and sm is quite limited.

There have also been suggestions in the forum to make all HAL pins 64bit for standardisation, as encoders have a problem with overflowing 32bit numbers.

Yes that 64-bit integer data-type is missing in hal, but I think I heard that might change for next release. Don't quote me on that though.
In the other hand, there is the flexibility to use all EtherCAT's data types (almost then) and convert data into hal data types to send and receive so in one way it is very flexible. Downside is it requires a bit of understanding from the user who may not be so interested in this, just want to use it kind of.