scottlaird
commented
6 months ago FWIW, most of the LCNC drivers only export data from the hardware, and don't generate a lot of synthetic pins like velocity. Not to say that it couldn't be done, but so far we've been pretty minimal that way.
Looking at the EL5001 as a sample encoder, the docs have a brief mention of calculating velocity, but the hardware won't do it directly (https://download.beckhoff.com/download/Document/io/ethercat-terminals/el500xen.pdf#page=132). They do recommend running the encoder in distributed-clock mode if you're going to calculate velocity, but I'm not sure what's involved in that at the moment.
I'd be happy to merge generic velocity support in github.com/linuxcnc-ethercat/linuxcnc-ethercat, but I don't have a test encoder and I don't do rigid tapping, or really have any good way to validate that the encoder changes are working today.
I may try to pick up a spare EL7047 and a Beckhoff stepper w/ encoder, just to round out my test environment. That probably won't help here, though, because it looks like the EL7047 tracks velocity on its own and doesn't use any of the code in lcec_class_enc.c, which is where velocity should probably live. Hmm. The EL5* devices don't use lcec_class_enc, either, I wonder if that's just a code-age issue, or if the generic encoder code should be more widely used.
The LinuxCNC encoder drivers have a velocity output pin. (typically both rpm and rps for convenience)
This is useful for velocity-feedback applications, for example with spindles.
A reason to do this inside the driver rather than with an external ddt is that there is a large step-change in position output on index-reset, which appear to cause problems under some circumstances. See: https://forum.linuxcnc.org/38-general-linuxcnc-questions/45882-rigid-tapping-and-pid-control#243134
Velocity calculation inside the driver can easily compensate for index-reset, whereas compensating externally is troublesome (and is something that it is easy to overlook the necessity for)