Advanced Search

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.
 

My project is slowly progressing. I've put together a few things using examples and AI. The interface starts, but I'm stuck in the ESTOP. The statuses in HALSHOW aren't changing either. So there seems to be no connection to the board, even though pinging 10.10.10.10 is successful. Is there a way I can test the communication?         

Thanks,
yes, theoretically this also works with large servos, but this also requires large power amplifiers.
it is better to run something like this separately on real servo drivers.

it must run on the same computer as linuxcnc, to find the python libs.

BUT, it's only a proof of concept, do not use it for production systems