#linuxcnc-devel Logs

Jan 05 2020

06:59 AM ubuntu is now known as Guest70713
11:06 AM pcw_home: skunkworks: not much info there since the DPLL is still locked, maybe trigger on DPLL error > 900 usec or so which would indicate loss of lock
11:06 AM * pcw_home considers how to provide a DPLL locked signal...
11:39 AM skunkworks: still don't know if this is some sort of noise..
11:39 AM skunkworks: I can't make it happen consistantly
11:40 AM pcw_home: I suspect you would need to trigger on DPLL lock loss to capture the fault
11:41 AM pcw_home: (and use a much longer low pass filer time constant)
11:41 AM skunkworks: so - run with no stepper timer - and trigger when the DPLL error starts oscolating?
11:42 AM skunkworks: pcw_home: like what? .01? .001?
11:51 AM pcw_home: .0001?
11:52 AM pcw_home: should filter out the cycle/cycle variations
12:45 PM skunkworks: And now I cannot get it to do ot
12:45 PM skunkworks: it
01:01 PM skunkworks: it is amazing how much better it sound with the timer enabled..
01:09 PM pcw_home: The RPI4s Ethernet jitter looks pretty terrible
01:11 PM pcw_home: Does the RPI4 Ethernet have and IRQ coalescing option?
01:18 PM skunkworks: pcw_home: http://electronicsam.com/images/greenmachine/2020-01-05-190622_1920x1080_scrot.png
01:20 PM skunkworks: cought it - but - does that shed any light?
01:22 PM pcw_home: Yes it does, the servo thread base frequency is shifting...
01:25 PM skunkworks: well - that sucks..
01:25 PM pcw_home: the low-pass is a bit slow to see it clearly but your can see it clearly in the baseline of the prevsub signal
01:26 PM pcw_home: see thet step in the middle...
01:26 PM skunkworks: yes
01:26 PM skunkworks: so - does that mean the pi's processor frequency is changing?
01:29 PM pcw_home: Not sure how the interrupt timing is done, I know the servo thread frequency shifts slowly on X86 in response to NTP adjustments (without CPU frequency changes)
01:30 PM skunkworks: I don't think this has ntp on it...
01:30 PM pcw_home: I the first 1/2 of the plot, the low pass looks like it was recovering from a previous shift
01:31 PM skunkworks: yes - that is what I figured
01:31 PM pcw_home: (that is its drifting but there is no baseline shift in the prevsub number)
01:32 PM pcw_home: which suggests its time constant is now too long to monitor the actual servo thread period shifts
01:33 PM skunkworks: no - it looks like it is running NTP
01:34 PM pcw_home: what is the scale of the prevsub number (what are the numbers you are subtracting)
01:36 PM skunkworks: It is showing 2" with a 2 offset on the scope
01:37 PM pcw_home: I guess another way to ask this is what is lowpass.1.out?
01:37 PM skunkworks: (the distace the stepgen moves every servo cycle)
01:37 PM skunkworks: it is subtracting the previous postion from the next
01:38 PM skunkworks: lowpass lowpassing the prevsub.0.out
01:38 PM skunkworks: does that make sense?
01:39 PM pcw_home: OK so that's a sudden ~2% servo thread frequency shift
01:40 PM skunkworks: is there a log of when the time is adjusted?
01:40 PM * skunkworks googles
01:40 PM pcw_home: Probably somewhere...
01:59 PM pcw_home: Mint 19 seems to use timesyncd instead of ntpd
02:09 PM pcw_home: looks like you would want the '-x' ntpd option (dont allow step corrections, only slew corrections)
02:30 PM skunkworks: I think I broke ntp....
02:33 PM skunkworks: might be a good test..
02:34 PM skunkworks: yes - I think this was using tymesyncd too
03:09 PM skunkworks: pcw_home: when I start and stop the ntp service - and force a time sync with ntp - I can get the scope to trigger - but it is just a spike.
03:10 PM skunkworks: I wonder if timesyncd might be a problem...
03:10 PM skunkworks: small spike
03:14 PM pcw_home: Yuck, looks like timesyncd doesn't even have any option to disable stepping the time, thank you systemd
03:17 PM skunkworks: My thought is that the internal rpi clock sucks.. SO - when the time gets adjusted it is huge.
03:20 PM skunkworks: pcw_home: Just playing - I have had a correction of .1s
03:20 PM skunkworks: just playing here over the last 1/2 hour or so
03:20 PM skunkworks: no oscolation yet
03:49 PM skunkworks: I will have to see if I can play with timesyncd on the other image - see if I can manually update it
03:52 PM pcw_home: when there was an issue with X86 and the default DPLL time constant was lowered, you usually saw problems with bad internet connectivity so large corrections needed to be made
03:54 PM skunkworks: that would make sense.. My parents have really crappy dsl..
03:55 PM skunkworks: and it happens here
03:55 PM Tom_L: skunkworks, you put tool to metal with the pi4 yet or just testing?
03:57 PM skunkworks: mostly testing
03:57 PM skunkworks: I have cut some small things..
03:57 PM Tom_L: not a 24/7 production machine yet ehh?
03:59 PM Tom_L: btw, since you're familiar with big iron... an op at my kids work split the frame on a DMG mori a couple weeks ago doing some sort of tool change he wasn't supposed to...
03:59 PM Tom_L: and a 17k probe..
04:08 PM skunkworks: ouch
04:09 PM Tom_L: i think he may be lookin for work...
04:10 PM Tom_L: it was in a workcell of 4 so they're down one now
04:14 PM skunkworks: pcw_home: I think... That is the problem? http://electronicsam.com/images/greenmachine/2020-01-05-160010_1920x1080_scrot.png
04:17 PM pcw_home: Yeah that looks like a more that 100 usec period shift (>5% of your 2 ms servo thread)
04:19 PM pcw_home: I'm not exactly sure of the DPLL capture range but certainly less than +-5%
04:27 PM pcw_home: might be fixable by installing /enabling ntpd and disabling timesyncd ( apparently timesyncd is _very_ dumb, just the minimum required for TOD )
05:03 PM skunkworks: pcw_home: yes - I installed ntp on the one image and it 'seemed' to work better
05:04 PM skunkworks: I could manually update the time but I don't know if it was working automatically
05:35 PM pcw_home: did you try a much smaller DPLL time constant? (not that you should change more than one thing at a time...)
05:57 PM skunkworks: pcw_home: no - I tried higher because I didn't really know what it did/
05:57 PM skunkworks: but if ntp fixes it - it might not be a problem anymore. I will do more testing
05:57 PM pcw_home: lower makes it track faster
05:58 PM pcw_home: Yeah if ntp fixes it thats better (though you might want to use the -x option)
07:00 PM skunkworks: pcw_home: http://electronicsam.com/images/greenmachine/2020-01-05-185032_3840x2160_scrot.png
07:00 PM skunkworks: got home - booted it up and saw the time was way off...
07:00 PM skunkworks: this is the one with ntp kinda installed
07:08 PM skunkworks: I think I have it using ntp natively now
09:09 PM skunkworks: it doesn't seem like the ntpd is working correctly.
09:25 PM Tom_itx is now known as Tom_L