The issue tracker is not a support forum

The LinuxCNC issue tracker is to report bugs in the software.
If you have a question about how to use the software, use one of the other methods detailed on our community support page: http://linuxcnc.org/community/

(delete this section before submitting your bug report)

Here are the steps I follow to reproduce the issue:

1. use a configuration with muxed encoders and deskew option (encoder version >3)
2. use a 5I25 or 6I25 with 33 MHz clock
3. set deskew to 100 ns

This is what I expected to happen:

deskew rounded to 90 ns (3 clocks at 33.33333 MHz)

This is what happened instead:

The deskew number is truncated rather than rounded, this is not terribly bad except
that the deskew number calculation is redone any time the encoder is written (say when homing)
and the successive truncations change the deskew value each time until it becomes 0
This can lead to runaways/ crazy behaviour. There are really two bugs here:
1. Truncation rather than rounding in skew calculation
2. re-calculating/ re-writing the skew (and encoder sample frequency) on any encoder write

It worked properly before this:

(If the behavior changed after making a particular change in hardware or
software, describe the change you think is responsible. E.g., “after upgrading
from LinuxCNC 2.7.3 to 2.7.4”)
Not sure, probably always there

Information about my hardware and software:

* I am using this Linux distribution and version (often, shown by lsb_release -a):
* I am using this kernel version (shown by uname -a):
* I am running …
* [ ] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
* [ ] A binary I built myself
* [ ] A binary version from some other source besides linuxcnc.org
* I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):
* I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):
* I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card):