#linuxcnc-devel Logs

Jul 14 2017

09:39 AM skunkworks: running the 30us base thread for a few days
09:45 AM KGB-linuxcnc: 03Jeff Epler 05master 15b3116 06linuxcnc Merge branch 'master' of https://github.com/rene-dev/linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=15b3116
10:20 AM linuxcnc-build: build #227 of 1540.rip-jessie-armhf is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/227 blamelist: Jeff Epler <jepler@unpythonic.net>, Rene Hopf <renehopf@mac.com>
10:24 AM mozmck: skunkworks: what hardware is that base thread of 30us on?
10:26 AM skunkworks: hp 8300 sff - i5 3rd gen
10:35 AM seb_kuzminsky: those armhf buildslaves are annoyingly unstable
10:35 AM seb_kuzminsky: collect2: error: ld terminated with signal 11 [Segmentation fault]
10:38 AM linuxcnc-build: build #5041 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5041 blamelist: Jeff Epler <jepler@unpythonic.net>, Rene Hopf <renehopf@mac.com>
10:48 AM seb_kuzminsky: i rebooted that jessie-armhf machine remotely, and it didn't boot back up :-/
10:48 AM seb_kuzminsky: so the buildbot's down until i get back home from work this evening...
11:11 AM skunkworks: don't you have a robot that will pull the plug on the whole system? then plug it back in?
11:11 AM seb_kuzminsky: a meat robot
11:13 AM skunkworks: your kids are off this summer - right? Couldn't they be trained?
11:14 AM seb_kuzminsky: hmm, good idea! use the self-replicating feature of the old robot to replace it
12:16 PM jepler: seb_kuzminsky: what are your prospects for having a solid weekend half-day, or solid evening to work on buildbot stuff for the github migration
12:16 PM jepler: cradek: ditto ^^
12:16 PM jepler: .. and do we think there's anything that won't be doable given our ability to actually sit down and work on it together at the same time?
12:17 PM jepler: .. I feel like there's actually not much, particularly if we can make do with temporarily degraded service, such as maybe the emc-commit list goes quiet
12:18 PM cradek: this weekend is better than next, sunday probably better than saturday, monday evening also would probably be ok
12:19 PM jepler: uncharacteristically, my sunday is free this weekend
12:19 PM jepler: 7/15 and 7/22 are not great for me. 7/22 I already committed to upgrading the forum's OS to the current (1 year old) Ubuntu LTS from 14.04..
12:20 PM jepler: seb_kuzminsky: would either of 7/16 or 7/17 would fly for you?
12:33 PM seb_kuzminsky: jepler: can you help me understand https://github.com/LinuxCNC/linuxcnc/pull/299?
12:33 PM jepler: seb_kuzminsky: I'll try, jas
12:34 PM seb_kuzminsky: pinterp is of type Interp, right? it uses the code in (among other places) rs274ngc_pre, including the ::open() there?
12:34 PM seb_kuzminsky: that function doesn't handle filename="" gracefully at all
12:34 PM jepler: seb_kuzminsky: yes it is
12:36 PM jepler: seb_kuzminsky: In what way does it not handle filename=""? It just returns with NCE_UNABLE_TO_OPEN_FILE right?
12:36 PM seb_kuzminsky: yeah
12:37 PM seb_kuzminsky: and then gcodemodule ignores the error and closes it, i see
12:37 PM jepler: yes
12:37 PM seb_kuzminsky: and the close is a no-op because the file handle is null
12:37 PM seb_kuzminsky: ok i get it now, thanks
12:37 PM jepler: maybe I should explore just wtf setup.use_lazy_close is
12:38 PM jepler: because that's the problem
12:38 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7 163ac5e 06linuxcnc Merge remote-tracking branch 'jepler/issue273-2.7' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=163ac5e
12:38 PM seb_kuzminsky: jepler: another day
12:38 PM jepler: thanks!
12:38 PM seb_kuzminsky: sure, thanks for fixing it
12:38 PM seb_kuzminsky: so, about buildbot time
12:39 PM seb_kuzminsky: afternoon/evening sunday the 16th could probably work
12:45 PM jepler: afk for lunch
04:51 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7 140104a 06linuxcnc 10docs/src/config/ini-config.txt docs: document [EMCMOT]COMM_TIMEOUT * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=140104a
05:18 PM KGB-linuxcnc: 03Chris Morley 05qt5vcp_master f11f2b4 06linuxcnc 344 commits pushed, 10170 files changed, 035112(+), 041302(-)
05:31 PM KGB-linuxcnc: 03Sebastian Kuzminsky 05master 65a9495 06linuxcnc 10docs/src/config/ini-config.txt 10src/emc/rs274ngc/gcodemodule.cc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=65a9495
05:31 PM KGB-linuxcnc: 03Sebastian Kuzminsky 05master 945de03 06linuxcnc 10(6 files in 3 dirs) Motion: remove unused reading of [EMCMOT]COMM_WAIT * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=945de03
05:31 PM KGB-linuxcnc: 03Sebastian Kuzminsky 05master b167ec2 06linuxcnc 10(244 files in 120 dirs) remove [EMCMOT]COMM_WAIT from all sample configs and tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b167ec2
06:03 PM andypugh: I was poking about in the Linux docs today. apparently insmod can take a —persistence argument which gives the module somehere to save state data between loads. I wonder if HAL modules could use that? It would let resolvers and absolute encoders be properly absolute.
06:07 PM seb_kuzminsky: it'd have to be implemented through rtapi, so that it worked for non-kernel-module builds of our realtime components
06:08 PM andypugh: I was really asking if anyong knew more about it than me. (I know what I read in 2 sentences of docs)
06:10 PM andypugh: I suspect it would be hard to do in rtapi unless a choice was made to give _every_ module a self-named persistence file. (or perhaps the module could somehow inform RTAPI, I suppose)
06:11 PM andypugh: I already do something on my lathe with a userspace helper, but it’s a bit flaky and I think I am actually doing it in the wrong place in HAL.
06:12 PM seb_kuzminsky: i guess the first step would be figuring out the intersection between the semantics you want, and the semantics enabled by "insmod -persistence"
06:12 PM seb_kuzminsky: did you look into dropping [TRAJ]CYCLE_TIME when update_ini processes an ini file?
06:13 PM seb_kuzminsky: and if so, can you also make it drop [EMCMOT]COMM_WAIT?
06:14 PM andypugh: Yes, I would have started about half an hour ago, were it not for the bottle of (rather nice) Malbec that has disappeared while watching the tour de france.
06:15 PM andypugh: I will do it tomorrow
06:18 PM seb_kuzminsky: no rush
06:18 PM seb_kuzminsky: i'll not touch it
06:19 PM seb_kuzminsky: i'm getting all kinds of bogged down in the [TRAJ]TRAJ_PERIOD thing
06:19 PM seb_kuzminsky: i think it's buggy and broken, but often when i've thought that about linuxcnc internals before i've turned out to be wrong :-/
06:24 PM seb_kuzminsky: in most configs, Motion is started without a traj_period_ns argument, and in that case it runs with an "interpolationRate" of 1
06:25 PM seb_kuzminsky: in some configs, Motion gets traj_period_ns == servo_period_ns, and again interpolationRate is 1
06:25 PM andypugh: seb_kuzminsky: Have you looked at Hostmot2 AC outputs?
06:26 PM seb_kuzminsky: but in a few configs it gets a traj_period_ns that differs from servo_period_ns, and then the interpolationRate is the ratio of the two
06:26 PM andypugh: That sounds unexpected.
06:28 PM seb_kuzminsky: for example by_machine/smithy/1240gecko.ini
06:29 PM seb_kuzminsky: the sim/axis/vismach configs are like that too
06:29 PM seb_kuzminsky: i'm going to have to look at it when i have more time to dig into it...
06:29 PM seb_kuzminsky: andypugh: i have not started looking at HM2 AC output yet.
06:30 PM seb_kuzminsky: i should probably do that instead of trying to clean up 10+ year old technical debt
06:30 PM andypugh: I might do it, we have a user on the forum wanting it.
06:30 PM seb_kuzminsky: i have a branch somewhere where i started it
06:31 PM andypugh: I will let you know if I start (it would be a desktop thing, I have no hardware)
06:31 PM seb_kuzminsky: i'm pretty good at starting things...
06:31 PM andypugh: Oh, so it’s not 100% trivial then?
06:31 PM seb_kuzminsky: i didn't get far enough to know if it's trivial or not
06:32 PM andypugh: I had guessed it would just be expanding GPIO to take over control of a different gtag.
06:33 PM andypugh: (do I mean “gtag” or have I borrwed that from a comeltely different project?)
06:33 PM seb_kuzminsky: it's gtag
06:34 PM pcw_mesa: I think micges found that there were bugs if the interpolation rate was not 1:1
06:34 PM pcw_mesa: but that may only have been with his limited jerk branch
06:35 PM seb_kuzminsky: i'd sure expect there to be bugs in that case
06:35 PM seb_kuzminsky: because the tp would run at a different rate than it thought
06:36 PM pcw_mesa: not sure interpolation is of much use unless you have severely limited CPU horsepower
07:04 PM pcw_mesa: (interpolation meaning trajectory period longer than servo period)
07:57 PM KGB-linuxcnc: 03Sebastian Kuzminsky 05master a5c7736 06linuxcnc 10(216 files in 113 dirs) remove [TRAJ]CYCLE_TIME, it was never read * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a5c7736
08:58 PM linuxcnc-build: build #228 of 1540.rip-jessie-armhf is complete: Failure [4failed garbage-collect git repo] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/228 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
08:58 PM linuxcnc-build: build #5042 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5042 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
08:59 PM seb_kuzminsky: the buildbot is back up
09:01 PM jepler: thank you seb_kuzminsky
09:36 PM seb_kuzminsky: sure thing
09:37 PM seb_kuzminsky: i turned the top speed of the jessie-armhf buildslave down from 1.2 GHz to 1.0 GHz, see if that makes any difference
09:37 PM seb_kuzminsky: or maybe just having it 15 F cooler in the garage makes it happer