On Sunday 15 March 2020 07:38:19 John Hasler wrote:
> Install Chrony.
No need to a/o as an hour or so ago ntp finally achieved a lock.
oot@rpi4:~# /etc/init.d/ntp status
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset:
enabled)
Active: active (running) since Sun 2020-03-15 07:52:23 EDT; 3h 23min ago
Docs: man:ntpd(8)
Process: 4066 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited,
status=0/SUCCESS)
Main PID: 4072 (ntpd)
Tasks: 2 (limit: 4033)
Memory: 1.1M
CGroup: /system.slice/ntp.service
└─4072 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 114:122
Mar 15 08:02:42 rpi4.coyote.den ntpd[4072]: 216.117.164.1 local addr
192.168.71.13 -> <null>
Mar 15 08:09:15 rpi4.coyote.den ntpd[4072]: 91.207.136.50 local addr
192.168.71.13 -> <null>
Mar 15 08:09:22 rpi4.coyote.den ntpd[4072]: 5.20.0.20 local addr 192.168.71.13
-> <null>
Mar 15 08:09:30 rpi4.coyote.den ntpd[4072]: 195.78.244.50 local addr
192.168.71.13 -> <null>
Mar 15 08:11:38 rpi4.coyote.den ntpd[4072]: 23.31.21.164 local addr
192.168.71.13 -> <null>
Mar 15 08:17:12 rpi4.coyote.den ntpd[4072]: 138.68.201.49 local addr
192.168.71.13 -> <null>
Mar 15 08:17:13 rpi4.coyote.den ntpd[4072]: 144.172.126.201 local addr
192.168.71.13 -> <null>
Mar 15 08:17:15 rpi4.coyote.den ntpd[4072]: 216.229.4.66 local addr
192.168.71.13 -> <null>
Mar 15 08:17:16 rpi4.coyote.den ntpd[4072]: 94.130.184.193 local addr
192.168.71.13 -> <null>
Mar 15 08:18:23 rpi4.coyote.den ntpd[4072]: 37.59.58.17 local addr
192.168.71.13 -> <null>
And I note that my broadcast from this machine is not shown above.
I do not know how chrony works to correct the time, but by late this
morning ntp has indeed achieved a lock. ntp locks by gently slewing the
clock rate if its within a minutes wide window. The existing raspbian
method may jump it, and this confuses LinuxCNC, makeing it think the
machine is way out of position when its checking every milisecond, and
the default method may jump the time by several milliseconds, causing
LinuxCNC to throw a false following error.
Nevertheless its a showstopper, freezing it place as quick as it can
given the decel limits at that instant, until a much slower human clears
the error and probably restarts what could be a several hour proceedure
from the top. Because changing a tool provides a handy breakpoint, and
is a by hand operation here, I generally write a job in breaks at tool
changes.
This did take longer than I thought it would take as the crash doesn't
give the fake hwclock time to store its latest time, so on the reboot
it make be several seconds out of synch. Now that I know its working,
I'll quit worrying about it.
The correct fix is of course to fix the crashing, but that fix is in the
mail yet. That faint knocking sound is me, knocking on wood that a new
$59 card fixes it. And I still have work to do rebuilding the the encoder.
That is going to need the 3rd ATS667 jbwelded to a brass base. and that
base then fitted to a curved alu bracket with a couple 0-80 screws in
slots to allow its mechanical timing to be adjusted for a good quadrature.
This is what tells LinuxCNC where in the spindles rotation it is, in this
case every 1.5 degrees, so it knows where to put the cutting tool when
its carving threads. A secondary problem is that due to factory miss-
adjustment which added several tons of engagement pressure 80 years ago,
the wear on the gear I am senseing is uneven which has resulted in teeth
that vary in magnetic width. And that eats up some timing tolerance,
hence the need for some adjustabiity. A new modern gear would be nice.
But is made out of very pure unobtainium in 2020. So we run what we brung.
:-)
Cheers & and thanks to you all, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
