#linuxcnc-devel Logs
Jan 08 2020
#linuxcnc-devel Calendar
05:01 PM jepler: boots and has icons
05:06 PM jepler: and the sd extender works on the pi with a different card so it must be marginal+marginal=failure
05:10 PM skunkworks: Yay!
05:13 PM skunkworks: I have played with so much stuff - but I think that the G2 (fake kms) open gl desktop driver...
05:13 PM skunkworks: works better
05:15 PM skunkworks: And just installing NTP - nothing else seems to just works.. (used ntpd and actually does update time)
05:17 PM skunkworks: *uses
05:18 PM jepler: I put my fork of pi-gen here and made an issue with a checklist .. feel free to suggest more things via comment. https://github.com/jepler/pi-gen/issues/1
05:22 PM jepler: later on we can transfer it or fork it into the linuxcnc organization
05:25 PM skunkworks: sounds great!
05:30 PM skunkworks: jepler: did you get the keyboard setup correct?
05:31 PM skunkworks: by default it is uk and it is a pain trying to find things like | and # ;)
05:35 PM andypugh: That pleases me, having struggled with the opposite problem so much.
05:36 PM skunkworks: heh :)
05:37 PM skunkworks: heh :)
05:37 PM andypugh: Though sometimes, when using ssh oo Linux from my Mac, or in VMs, I have had to resort to finding a # to copy and paste.
05:39 PM andypugh: UK Mac keyboard doesn’t have one. Makes coding harder than necessary. It’s right-option-3 in OSX, but that isn’t properly transferred always.
05:41 PM skunkworks: wow - this makes sense now - I was wondering why I am getting distance spikes every 1 ms - of 2.5" or 1.5" (should be 2)
05:41 PM skunkworks: It is the time getting adjusted over x time..
05:41 PM skunkworks: then after a while it stops
05:42 PM skunkworks: pcw_mesa: ^
05:42 PM skunkworks: pcw_mesa: ^
05:48 PM pcw_mesa: With no DPLL?
05:49 PM skunkworks: with dpll
05:49 PM pcw_mesa: Not sure how that can happen unless you have lost lock
05:50 PM skunkworks: umm - good question..
05:51 PM pcw_mesa: not much can change in the DPLL sample time in 1 or 10 ms
05:56 PM pcw_mesa: you can get worse jitter in 2 cases:
05:56 PM pcw_mesa: 1. Lost DPLL lock
05:56 PM pcw_mesa: 2. Not enough pre-sample margin (may need to be 100 or 200 usec on a drifty machine like the RPI4)
05:57 PM skunkworks: I have -200
05:58 PM skunkworks: so when I do a manual time update - The phase0error-us swings just a little bit - and I get postion spikes every ms or so
05:58 PM skunkworks: for a while
05:58 PM skunkworks: getting a screen shot
05:59 PM skunkworks: no problems though - running it quite a few hours
06:04 PM skunkworks: http://electronicsam.com/images/greenmachine/2020-01-08-174748_1920x1080_scrot.png
06:04 PM skunkworks: internet was slow
06:05 PM pcw_mesa: you should get similar errors (+-25% of velocity * servo thread period) in all stepgens so say 3 IPS would result in 1.5 mills of noise
06:05 PM skunkworks: why would that be every ms if my thread is 2ms?
06:07 PM skunkworks: am I thinking wrong?
06:07 PM skunkworks: why is there a spike every ms - if my thread is 2ms.. I think I am reading the graph right..
06:08 PM pcw_mesa: looks like a spike every second or so
06:09 PM skunkworks: duh
06:09 PM skunkworks: sorry
06:09 PM skunkworks: so what is causing that?
06:10 PM skunkworks: it isn't affecting anyting
06:10 PM skunkworks: that I can tell
06:10 PM pcw_mesa: but you dont see similar spikes on the stepgen velocity when in motion?
06:11 PM pcw_mesa: that's an enormous velocity spike
06:13 PM skunkworks: stepgen velocity fb?
06:15 PM skunkworks: stepgen velocity fb?
06:15 PM skunkworks: sorory too many keyboards
06:16 PM skunkworks: I don't see any spikes in velocity feedback...
06:16 PM skunkworks: of stepgen 1
06:16 PM skunkworks: *stepgen 0
06:17 PM pcw_mesa: math problem?
06:17 PM skunkworks: every second or so?
06:17 PM skunkworks: weird
06:19 PM pcw_mesa: so no DPLL loss of lock, no DPLL baseline shift over 200 usec
06:19 PM pcw_mesa: what is your following error setting and axis velocity?
06:20 PM pcw_mesa: I would thin a 25% sample time error would cause a following error
06:22 PM skunkworks: following error never went above .00005
06:22 PM skunkworks: "
06:22 PM skunkworks: I will have to look at it more
06:42 PM pcw_mesa: are you using ddt?
06:54 PM pcw_mesa: if I look a a 1 MHz stepgen with DDT I get about 100 PPM (+-100 ns) timing accuracy
07:01 PM skunkworks: no - it was strictly subtracting the previous positon from the current one
07:01 PM pcw_mesa: ddt should do the same
07:01 PM pcw_mesa: (well except that is scale by the nominal servo thread period)
07:01 PM skunkworks: well - darn. It couldn't think of a componant that did that...
07:01 PM skunkworks: oh
07:01 PM pcw_mesa: so if I DDT stepgen position I get frequency
07:06 PM skunkworks: it is just taking the fb postion of the stepgen. The fuction is run between the mesa read and write..
07:07 PM jepler: andypugh : 1 tb/mo of bandwidth so no worries for the first 500 downloads or so
07:08 PM jepler: but .. I think it's waaaayyyyy short of "shold be publicized beyond IRC"
07:08 PM skunkworks: oops..
07:08 PM skunkworks: ;)
07:08 PM jepler: hahaha
07:08 PM skunkworks: just kidding.
07:08 PM jepler: I know that TV ads are inexpensive in your market but it was really inadvisable
07:14 PM andypugh: OK, it just was looking like a possible answer to a thread on the forum. But I won’t.
07:14 PM andypugh: Maybe time to delete: http://www.linuxcnc.org/dists/buster/2.8-uspace/ ?
07:14 PM andypugh: (or replace..)
07:14 PM jepler: is that something I did?
07:14 PM andypugh: No, something I did
07:14 PM jepler: ah
07:14 PM jepler: I don't know how they compare, didn't know you had done it
07:14 PM * jepler stepping on all the toes
07:22 PM skunkworks: andypugh: I agree - going with the flexibleness of linuxcnc - using axis words make it so you cannot use it in other planes
07:23 PM andypugh: Ben Potter had a go, and managed to make it fit. (I even chose $ for spindle number to make more room)
07:24 PM andypugh: But I am aware that many people have submitted an G71 over the years and none have made it in to the code.
07:36 PM Tom_L: https://www.cnccookbook.com/g71-rough-turning-cycle-fanuc-cnc-gcode/
07:36 PM Tom_L: fwiw
07:41 PM andypugh: Yes, Fanuc (mis) use U and W.
07:42 PM andypugh: I already coded (and documentd) https://github.com/LinuxCNC/linuxcnc/blob/andypugh/g71type2remap/docs/src/gcode/g-code.txt#g71-lathe-roughing-cycle-turning
08:47 PM skunkworks: pcw_mesa: adjtime(2) to slew (gradually change) the time. Slewing the time means to change the virtual frequency of the software clock to make the clock go faster or slower until the requested correction is achieved. Slewing the clock for a larger amount of time may require some time, too. For example standard Linux adjusts the time with a rate of 0.5ms per second.
08:48 PM skunkworks: if the stepgen moves 2 inches in 2ms - .5ms adjustment would be +/-.5 inches that I am seeing.
08:50 PM jepler: so you think it's literally ".5ms once per second"
08:50 PM skunkworks: yes - I think that is what I am seeing
08:51 PM skunkworks: but why would that not effect the motion?
08:51 PM skunkworks: http://electronicsam.com/images/greenmachine/2020-01-08-174748_1920x1080_scrot.png
08:51 PM skunkworks: that is .5 inches ever second
08:52 PM skunkworks: spike
08:52 PM jepler: what is prevsub.0.out?
08:52 PM jepler: (position - old position)?
08:52 PM skunkworks: yes
08:53 PM skunkworks: it is the example in the halcompile documents for ddt without the / fperiod.
08:53 PM jepler: 500 milli inches different than expected? That's huge
08:54 PM skunkworks: Yes - the actual following error of actual motion is < .00005"
08:54 PM skunkworks: (I have an extra stepgen free-running that moves 2 inches every servo cycle)
08:55 PM jepler: oh so this stepgen is not being checked for ferror by linuxcnc?
08:55 PM skunkworks: right
08:55 PM jepler: 2 inches in 2ms is 57mph?
08:55 PM jepler: I guess what's a half inch here or there when you're going highway speeds
08:55 PM skunkworks: could be.. It was just to figure out if the servo period was changing without linuxcnc knowing
08:56 PM jepler: it's a good test, because you are using a clock you trust to measure one you don't :)
08:56 PM skunkworks: right - peters idea
08:56 PM skunkworks: it is what pointed us to the time sync
08:57 PM jepler: 60in/min * 500us is .0005in so it does seem like your "actual following error" should be bigger than .00005
08:58 PM jepler: though .. the dpll may still be sampling at the "right time", and so it spreads that .0005 error over time and you see .00005
08:58 PM jepler: except .. you measure how different it is when you get the other stepgen position back, that also happens by the same dpll
08:59 PM skunkworks: right - it is all a bit muddy to me.
08:59 PM skunkworks: it is amazing how much better it runs with dpll...
09:00 PM skunkworks: smooooooth
09:01 PM jepler: CLOCK_MONOTONIC -- Clock that cannot be set and represents monotonic time since some unspecified starting point.
09:01 PM jepler: This clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock)
09:01 PM jepler: but is affected by the incremental adjustments performed by adjtime(3) and NTP.
09:02 PM jepler: seems like you or pcw read this much already at least
09:03 PM jepler: all timekeeping in linuxcnc uspace is supposed to be based on this clock and I don't THINK we ever saw behavior like this on x86 PCs in the past, but systemd-timesyncd was DEFINITELY not installed, and dunno about ntp. I would have assumed there was ntp, though!
09:03 PM skunkworks: I mean - so far it is running great with ntpd vs timesyncd.. And maybe this problem has always been there - just never noticed. and with the pid type step control - it isn't as effected by 1 error every second
09:04 PM jepler: https://bugzilla.kernel.org/show_bug.cgi?id=198137
09:06 PM jepler: to me it would not actually be a surprise if there were something different about timekeeping on pi/arm vs x86 just due to x86 being so much older (and, honestly, weirder -- time from tsc? apic? pit? lapic? cmos rtc?)
09:06 PM jepler: but they've had more time to make it almost seem to work:)
09:09 PM skunkworks: heh
09:10 PM skunkworks: when it is running good (normal?) these are the kind of following errors.. http://electronicsam.com/images/greenmachine/IMG_20191229_145305.jpg
09:10 PM skunkworks: (the minmax halmeters)
09:10 PM jepler: at what kinds of speeds?
09:11 PM skunkworks: umm - let me check
09:12 PM skunkworks: 3.333in/sec
09:12 PM skunkworks: 200ipm
09:13 PM skunkworks: https://www.youtube.com/watch?v=feZU_gNnZNE
09:14 PM jepler: 3e-5in being .. less than 1 step so who cares, probably
09:14 PM skunkworks: right - awesome for this machine
09:15 PM skunkworks: I would be happy with .0005 :)
09:15 PM jepler: but it is .45% of the distance traveled in 2ms
09:17 PM skunkworks: Just burned your image.
09:18 PM skunkworks: I like that I can just change the config.txt and things from my laptop... (put my configs on it too)
09:18 PM skunkworks: cool way to do it
09:18 PM jepler: yeah that part is relatively convenient
09:18 PM jepler: I was hoping to make it even easier by putting the card at the end of an extension cord but that didn't work out
09:18 PM jepler: https://www.adafruit.com/product/3688
09:18 PM jepler: would be great except for how it doesn't even boot this particular SD card
09:19 PM skunkworks: yeck.. That is really common with 3d printers...
09:19 PM skunkworks: (microsd extentions)
09:20 PM skunkworks: what is the config-rt.txt do?
09:20 PM skunkworks: don't remember seeing that on the images I have played with
09:21 PM jepler: yeah that's new/local to my image
09:21 PM jepler: config.txt includes config-rt.txt
09:21 PM jepler: it might not be necessary
09:22 PM jepler: and not sure what happens if you delete it but still reference it from config.txt. you can find out if you want :)
09:23 PM skunkworks: :)
09:26 PM jepler: is this the OpenGL option to choose? "G2 GL (Fake KMS)" "OpenGL desktop driver with fake KMS"
09:27 PM skunkworks: that is what I have been using
09:27 PM skunkworks: some time in the past - it seemed if you wiggled an opengl window over another opengl window - you got all kinds of latency
09:28 PM skunkworks: with G1
09:28 PM skunkworks: I don't know if that is still true
09:29 PM jepler: Are "predictable network interface names" important? I think jt's guide mentioned it
09:30 PM skunkworks: I don't remember anything about that.
09:31 PM jepler: jt's guide has: net.ifnames=0
09:31 PM jepler: which is "predictable"
09:31 PM jepler: though I am at defaults, and eth0 is called eth0..
09:35 PM skunkworks: huh - all I do is add the static ip to dhcpcd.conf for mesa..
09:35 PM jepler: it may be more important for earlier pis which had the network on usb? Not sure at this point
09:35 PM skunkworks: did you do something to this image with realtime?
09:35 PM skunkworks: different from the first one?
09:35 PM skunkworks: It seems a bit better.
09:35 PM jepler: not intentionally
09:35 PM skunkworks: ok - might just be the luck of the dray
09:36 PM skunkworks: draw
09:37 PM skunkworks: jepler: looking good - thank you!
09:38 PM jepler: I think this image is sooo big it needs an 8GB card minimum.
09:38 PM jepler: it unzips to 6.xxx or so?
09:42 PM skunkworks: yes - almost exactly 7gb
09:43 PM jepler: verified that installing ntp does cause systemd-timesyncd to be stopped by "disable-with-time-daemon.conf"
09:43 PM jepler: # don't run timesyncd if we have another NTP daemon installed
09:43 PM jepler: ConditionFileIsExecutable=!/usr/sbin/ntpd
09:43 PM skunkworks: jepler: what is the password for linuxcnc?
09:43 PM jepler: tux
09:44 PM skunkworks: ah - you probably said that
09:44 PM jepler: I might have
09:45 PM skunkworks: It is odd running linuxcnc on 4k...
09:45 PM jepler: I haven't gone beyond 2560x1440 yet
09:46 PM jepler: but boy do I like that better than 1920x1080
09:47 PM jepler: time to call it a night. thanks as always for testing skunkworks
09:48 PM skunkworks: is internet working for you?
09:48 PM skunkworks: ok - night
09:48 PM jepler: didn't try?
09:49 PM jepler: one of the symptoms that was brought up in the threads / bug reports about the broken icons was ssl certificates being busted. if that's what you're seeing, maybe it's not fixed
09:49 PM jepler: but on mine, curl https://example.com/ does work
09:51 PM jepler: and I can ssh in after enabling it via raspi-config
09:52 PM skunkworks: I think it started working.. No clue. I will keep an eye on it
09:52 PM jepler: I'm using wired for internet, not for a mesa card (yet)
09:55 PM skunkworks: what!?
09:56 PM skunkworks: you have the new fangled serial interface...
09:56 PM skunkworks: spi
09:56 PM skunkworks: I an put this as a bug report - but so far every install I have done - the first time you run linuxcnc you get
09:57 PM skunkworks: iptables: Bad rule (does a matching rule exist in that chain?).
09:57 PM skunkworks: after that - it launces without that error
09:57 PM jepler: is it harmless or does it stop linuxcnc?
09:57 PM skunkworks: seems harmless so far.
09:57 PM jepler: just once per install, or just once per boot?
09:57 PM skunkworks: once per boot
09:58 PM skunkworks: just on the rpi..
09:58 PM skunkworks: not seen it on 'normal' computers
09:59 PM skunkworks: the rpi4 does run pretty nice...
10:01 PM jepler: // now add a jump to our chain at the start of the OUTPUT chain if it isn't in the chain already
10:01 PM jepler: int res = shell("/sbin/iptables -C OUTPUT -j " CHAIN " || /sbin/iptables -I OUTPUT 1 -j " CHAIN);
10:01 PM jepler: this causes the message to be printed because the 'first part' fails, but goes on to do the second part
10:03 PM skunkworks: I thought you were quiting for the night.. Sorry
10:03 PM jepler: possible fix: + int res = shell("/sbin/iptables -C OUTPUT -j " CHAIN " 2>/dev/null || /sbin/iptables -I OUTPUT 1 -j " CHAIN);
10:04 PM jepler: I am honest
10:27 PM fjungclaus1 is now known as fjungclaus