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

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.

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

Nobody is forced to use it. I like the 'comp' format and I do promote it. The point is that it lowers the bar for people who are not C developers to create their own components. There are a lot of components (possibly even 'cia402.comp') that would not have been created if that tool did not exist.


Note that the 'halcompile' tool will actually create a .c file from a .comp file for you, if that is what you want to work with.
linuxcnc.org/docs/html/man/man1/halcompile.1.html

Was able to build and test it. Interesting.
There is the problem with the size of normal data types.
But also with compound variables/pdos like an uint32 that is really 12 bits input and 20 bits of nothing. Can be handled separately in a hal component to create individual pins I guess, but adds to it.
The naming of the pins is horrible, but you have all the info from the drive so can be fixed.
It's easy to compare to the situation with lcec_conf that offers solutions to I think all situations.
But adds its own complexity and isn't ideal. Too many details often go wrong.
You made a start with the ethercat_twincat configurator, that looks like an appealing way forward.