Encoders and frequency data (EL5101 especially)

We have a bug in the LinuxCNC-Ethercat Github project pointing out that we're using the wrong constant for calculating the frequency pin for EL5101s.  Changing it is fairly easy, and verifying that other Beckhoff encoders have correct constants isn't too hard, but the issue is that this will break users who are currently using the EL5101's frequency output, if they're depending on the current, incorrect values.

So, I have a few questions:

1. How many people actually care about frequency output from encoders (instead of position)?
2. How should we handle breaking changes like this, where the current behavior is wrong?  Leave the data alone?  Export a second pin with the correct data (the ever-popular env-1-frequency-new pin, presumably?).  Just fix it? 
3. How do I determine if this sort of change is a pure metrics change, or if it'll result in incorrect (and possibly expensive or even unsafe) movement?  

In any case, I should probably add a "breaking changes" doc to the repo for things like this, which may require users to change things in their config to get correct results.

 

My thoughts would be to add a second pin and leave the existing.  If anyone does have a working setup, then it would not break and still work.  Nothing worse than a change that makes you have to figure out what happened.  With the second pin could do a simple explanation and therefore someone can adjust to the second pin but still have a working system with the first pin intact.  Also, that liability issue you bring up in #3 is why I would not change and simply add a pin.

Maybe someone else will chime in with a different view, just my idea after the first read...  Man you are awesome to find this issue...  As always, super thanks for your work!!!

I'm kind of leaning towards keeping the bad constant, but using it as the default initializer for a new `frequency-scale` pin. So, by default it'll keep working like it has, but doing `setp lcec.0.enc1.enc-frequency-scale 0.01` will "fix" it.

I'm not all that happy with this, either, but it may be the least-bad option.