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.

Andy wants to replace 32 bit  pins with 64 bit pins in 2.10. Some people don't agree with this as it could result in unexpected consequenses (me included). for example I can see it breaking the Ethercat driver.

Re memory storage, its really defined by the CPU byte and register size so there is not any benefit in storing 8 bits. eg. the CPU will load 64 bits at a time into its registers so 8, 16, 32 or 64 bits will all probably take the same amount of storage on a 64 bit system.

I got 64-bits float implemented in the EtherCAT driver when I asked for it, lcec and lcec_conf. Quickly and not a big problem.
64-bits integers are needed for EtherCAT. When there is a push to move to 64-bit integers in linuxcnc,
we should jump on that opportunity.
"Don't know the consequences" is the worst reason ever, one finds out the consequences and then decide.
Turn "unexpected consequences" to "expected consequences" and work on them.
I can myself see how that can be done and if I can think of one solution there is always more ways to solve it.
And its not like we are reducing the capabilities like going from 32-bit to 16-bit, well that I would have been against,
but we are expanding capabilities.
Is memory size an issue? Well someone need to find out the storage needed for 32-bit integers and double that. Is that an issue?
It was possible to introduce joints, that must have been a much larger surgical operation than just changing the size of a data type.
Besides, floats used to be 32-bit, was changed in 2.6(?) to 64-bits and we survived.

EtherCAT has some other data types, like time and day, strings, arrays of bytes and ints. Some are handled like arrays; date and strings aren't.
 

I've calmed down now and want to try the ecad.so module.
I searched around a bit after your code, but don't know how to pull code for ecad, or how to build it.
Can you provide some instruction?
Also, do I need your version of lcec and lcec_conf? Seems old, it didn't recognize float-ieee haltype.
And you have Ethercat master code, do I need that or can I use the distributed apt packaged one?

Hi Hakan,

At the moment it's here.
But i can not help you with questions at the moment as i have not reviewed the code for a while now.
The ethercat-master is also there. It has different source code to store the xml in memory.
However i think it will run.

I just conversed the cia402.comp to c code .
I really don't get the dev's why they stay using .comp code, and even worse:  promoting it to use.