#linuxcnc-devel Logs

Aug 20 2022

03:26 AM pere: hi
06:25 AM linuxcnc-build: build #2034 of 4041.deb-buster-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/2034 blamelist: Sebastian Kuzminsky <seb@highlab.com>
07:27 AM linuxcnc-build: build #1927 of 4042.deb-buster-rtpreempt-rpi4 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4042.deb-buster-rtpreempt-rpi4/builds/1927 blamelist: Sebastian Kuzminsky <seb@highlab.com>
08:33 AM jepler[m]1: the inifile stuff is all pretty horrifying
08:38 AM jepler[m]1: too bad it works
08:40 AM Tom_L: everyone gets lucky at least once
08:59 AM jepler[m]1: *** /home/jepler/src/linuxcnc/tests/interp/m98m99/12-M99-endless-main-program: XPASS: Passed, but was expected to fail
09:03 AM jepler[m]1: anybody else see this test unexpectedly pass locally? I see the XFAIL was added recently but I can't figure out which PR it was connected to, my git-fu is failing me
09:20 AM pere: jepler[m]1: no PR, just me noticing it was failing on the buildbots, but not locally nor on github, if I remember correctly.
09:20 AM jepler[m]1: ok
09:21 AM pere: was unable to figure out where the race condition was.
09:21 AM jepler[m]1: all the testing of an actual linuxcnc session seems soooo fragile, unfortunately
09:21 AM pere: yes. I made a few of them stop using 'sleep', which improved some of the unstable ones.
09:49 AM pere: jepler[m]1: did you see my question from 05:56CET?
09:51 AM pere: seb_kuzminsky: anything I can do to help with the deb packaging?
09:52 AM pere: Do we care about building on windows? src/libnml/rcs/rcs_print.cc give the impression with a comment about sscanf().
10:50 AM pere: we are down to 30 open pull requests. very motivating to see. :)
10:50 AM pere: and the oldest is two year newer than a few weeks ago. :)
10:54 AM Tom_L: yay
11:00 AM pere: now if someone who understood the code could update #479 to the latest master...
11:00 AM Tom_L: any hope of getting an armf iso build?
11:01 AM pere: Tom_L: did not look at it. suspect it is a simple --arch armhf or similar
11:01 AM Tom_L: or img... whatever they call them
11:02 AM Tom_L: about 3 levels above my paygrade :)
11:02 AM pere: here is a nickel. now it is on your level. :P
11:03 AM Tom_L: i did take a peek at your iso build and changed a couple things for my local copy
11:04 AM Tom_L: you make it sound too easy
11:08 AM pere: I do not try to make it sound easy. I try to make it sound underpaid. :)
11:33 AM pere: is there a hal pin for the G33 K value while G33 is active? I came across code trying to read it as 'pitch', but is missing the value.
11:37 AM Tom_L: K - distance per revolution
11:38 AM Tom_L: .050" in Z per rev would be a 20 tpi thread
11:39 AM Tom_L: (i'm an inch person btw) :)
11:41 AM pere: correct.
11:41 AM Tom_L: i don't think it's a pin
11:41 AM Tom_L: not that i'm aware of
11:42 AM pere: A test in <URL: https://github.com/LinuxCNC/linuxcnc/pull/479 > read out the value with a pin, and I fail to find the pin.
11:43 AM Tom_L: spindle.M.revs IN FLOAT
11:43 AM Tom_L: For correct operation of spindle synchronized moves, this signal must be hooked to the position pin of the spindle encoder.
11:44 AM Tom_L: ?
11:45 AM Tom_L: there are several spindle.M.speed-xx pins
11:46 AM Tom_L: found in motion.9
11:48 AM Tom_L: ahh, when the move would exceed the axis limits due to inertia
11:50 AM Tom_L: might be a tough one since you don't know the spindle mass
11:52 AM pere: I do not understand how anyone could get the test to work in pill request #479.
12:04 PM Tom_L: best would be an educated guess
01:30 PM CaptHindsight[m]: preempt_rt latency for the 6.x kernel is even lower than 5.x, on Ryzen it's under 2uS for 25us base and 1mS servo thread
01:58 PM * CaptHindsight[m] uploaded an image: (38KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/tzxSUAvQEdOqAPgfosOPORqt/ntu-20Aug2022-34724.png >
02:54 PM pere: jepler[m]1: what are your thoughts on -Werror?
03:50 PM jepler[m]1: CaptHindsight: wow that's excellent!
03:51 PM jepler[m]1: pere: in circuitpython we've done it but we only deal with one compiler at a time (well, three I guess now since we have riscv and extensa in addition to arm). satisfying multiple compilers is much harder, and of course it's a pain for contributors. All the same, that's the only way to keep the number of diagnostics from growing, if you ever get the count to zero.
03:52 PM CaptHindsight[m]: I'd like a Ryzen with 1-2 cores fully isolated from the others cache
03:52 PM CaptHindsight[m]: just for RT threads
03:54 PM jepler[m]1: CaptHindsight: while you're testing .. what if you ./configure --with-realtime=uspace? Configure should eventually state "checking for realtime API(s) to use... uspace+lxrt" and after sudo make setuid you should get a note that it's using LXRT for realtime
03:55 PM jepler[m]1: you would want to 'make clean' to clear out old files before changing between linuxcnc's traditional rtai mode (using kernel modules) and this mode ..
03:55 PM jepler[m]1: jepler@debian-rtai:~/src/linuxcnc/src$ halrun
03:55 PM jepler[m]1: halcmd: loadrt abs
03:55 PM jepler[m]1: Note: Using LXRT realtime
03:56 PM CaptHindsight[m]: he just left for the weekend so maybe next week
03:57 PM jepler[m]1: ah ok
03:57 PM CaptHindsight[m]: on his todo list is also look for which apps hit latency besides firefox streaming a youtube
09:09 PM pere: jepler[m]1: I rebased and tested your #1278 and it got rid of all warnings for me.