Back
[08:08:24] <KGB-linuxcnc> 03John Thornton 052.7 bc08ada 06linuxcnc 10docs/src/Master_Documentation.txt Docs: fix level offset * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc08ada
[08:08:24] <KGB-linuxcnc> 03John Thornton 052.7 7b50770 06linuxcnc 10docs/src/Master_Documentation.txt 10docs/src/Submakefile 03docs/src/code/rs274.txt 10docs/src/index.tmpl Docs: add info about the rs274 stand alone interperter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b50770
[09:07:42] <mozmck> If I'm reading the code correctly, looks like if you set SHMEM_KEY under [EMCMOT] you will break your system? usrmotintf.c will use the key number you set in the INI file, but motion.c uses DEFAULT_SHMEM_KEY
[09:24:55] <jepler> quite possibly. Since a lot of other pieces are missing to allow running more than one linuxcnc instance, there's really no use case for changing the value..
[11:36:12] <automata> I tried the new RTAI 3.16.0 kernel available on linuxcnc.org for jessie. but still in a VM
[11:36:43] <automata> I could get the rtai-5 branch to compile and run
[11:37:02] <automata> will try it on a computer this week
[11:37:17] <automata> will try without a VM this week
[11:37:46] <jepler> hi automata
[11:37:48] <jepler> let us know your results!
[11:51:34] <pcw_home> Did you see that lair82's latency issues went away with a newer preempt-rt kernel?
[11:51:36] <pcw_home> (the 3.2.60 kernel is not very good on newer hardware)
[11:51:37] <pcw_home> For Preemt-RT, is there any reason not to use the latest?
[11:55:16] <automata> hi jelper
[11:55:25] <automata> *jepler
[11:56:38] <automata> I will
[11:58:43] <automata> Is there a script / list of commands to make a live CD with linuxcnc on it for wheezy which I can follow to make a simillar for jessie?
[11:59:10] <automata> that will make the testing on myraid hardware at my end much simpler
[12:05:48] <jepler> automata:
http://timeguy.com/gitweb?p=live-images.git;a=summary branch debian is what generates our wheezy cd images
[12:06:22] <jepler> I was not able to get it to generate jessie cd images with the preempt-rt kernel, and I didn't know enough to resolve the problems I encountered. they related to missing "aufs" filesystem module, I think. I don't know the status of aufs in seb_kuzminsky's rtai kernel
[12:11:43] <automata> aufs is required to deploy live systems
[12:12:16] <automata> aufs was not part of mainline kernel till after kernel version 3.8 atleast
[12:12:34] <seb_kuzminsky> the 3.16 rtai kernel has aufs
[12:13:05] <automata> so older vanilla kernels required the aifs patch , which by the way debian always put for their live systems
[12:13:15] <automata> but i think since 3.14 aufs is mainline
[12:13:24] <seb_kuzminsky> jepler: i made the liblxrt.so shlib like you wanted, seems to be working
[12:13:37] <automata> thanks seb for the confirmation
[12:13:47] <seb_kuzminsky> automata: i'm building the 3.16 rtai kernel based on the 3.16.7 debian kernel, they still ship aufs as a kernel patch
[12:14:19] <seb_kuzminsky> automata: for aufs3, i'm not sure what's in mainline
[12:14:47] <automata> http://aufs.sourceforge.net/
[12:15:11] <automata> not sure what to make of that... but since you have to put a patch, I guess it is not mainline
[12:16:18] <seb_kuzminsky> jepler:
http://paste.debian.net/342023/
[12:16:20] <automata> Thanks a bunch Seb
[12:16:28] <seb_kuzminsky> automata: sure thing
[12:16:53] <seb_kuzminsky> jepler: i'm still having some problems with sse on amd64, it's all a giant mess
[12:17:15] <seb_kuzminsky> automata: what are you hacking on?
[12:18:00] <pcw_home> looks like overlayfs is the modern replacement for aufs
[12:18:00] <automata> actually I am trying to get multi-touch screens to work with linuxcnc
[12:18:30] <automata> multi-touch support is patchy at best for 3.8 kernels
[12:19:03] <automata> so I am hoping 3.16 will improve that..
[12:20:12] <seb_kuzminsky> automata: cool
[12:20:18] <automata> I use linuxcnc for milling gold jewellery
[12:20:29] <seb_kuzminsky> ooh, neat
[12:20:33] <seb_kuzminsky> do you have pictures?
[12:21:04] <automata> sure .. i'll put some up in a few min
[12:22:32] <automata> https://www.youtube.com/watch?v=cY1noUuqPpY
[12:23:28] <skunkworks> seb_kuzminsky, how would I get the amd64 kernel
[12:24:10] <seb_kuzminsky> automata: wow, that's a cool machine!
[12:24:41] <seb_kuzminsky> skunkworks: the kernel's at 'deb
http://highlab.com/~seb/linuxcnc jessie main', but the rtai-modules deb isnt working on amd64 yet
[12:24:43] <automata> thanks
[12:25:02] <seb_kuzminsky> automata: did you retrofit it with linuxcnc?
[12:25:20] <automata> nope ... designed from scratch with linuxcnc...
[12:25:50] <automata> The GUI software talks to linuxcnc over linuxcncrsh
[12:25:52] <seb_kuzminsky> it's impressive, mechanically - lots of moving parts!
[12:26:26] <automata> thanks...
[12:27:18] <automata> The machine in that video has 6 axis... I have also made an 8 axis model
[12:27:46] <seb_kuzminsky> very cool
[12:27:49] <seb_kuzminsky> bbl
[12:28:03] <automata> that got 2 independently moving Z axes
[12:29:39] <automata> https://www.youtube.com/watch?v=o8-boS8B_1Y
[12:33:21] <skunkworks> ok - seb_kuzminsky so I can do an apt-get install ima-tab and there should be an rtai?
[12:36:15] <mozmck> I wonder why aufs is required in live systems? Looks like it was rejected for merging in the kernel, but overlayfs was merged.
https://en.wikipedia.org/wiki/Aufs
[12:37:32] <pcw_home> newer live images seem to use overlayfs
[12:37:40] <mozmck> looks like overlayfs was only merged in 3.18, so not available before that.
[12:38:06] <pcw_home> ahh so stuck with aufs for rtai
[12:38:55] <skunkworks> I am not seeing a rtai linux-imag
[12:38:55] <skunkworks> http://pastebin.com/cSYGZpyJ
[12:39:23] <skunkworks> crap - sorry - wrong source...
[12:43:36] <skunkworks> How do I use your key?
[12:44:51] <skunkworks> http://pastebin.com/huivPGkq
[12:53:20] <automata> I am trying to get the current position of the joints from EMC_TRAJ_STAT
[12:54:08] <automata> however EMC_TRAJ_STAT class has members named position and actualPosition
[12:54:22] <automata> both are of type EmcPose
[12:54:35] <automata> which means they are world space coordinates
[12:55:01] <automata> how do I get the joint coordinates (in case I am using non-trival kinematics)
[12:55:54] <automata> Joint coordinates from position and actualPosition in EMC_TRAJ_STAT
[13:24:33] <mozmck> automata: I think hal pins may be the best way for that.
[13:26:20] <automata> hmmm
[13:26:35] <automata> I'll try..
[13:27:15] <mozmck> axis.xx.joint-pos-cmd, axis.xx.joint-pos-fb
[13:27:27] <mozmck> moter-pos-cmd
[13:28:10] <automata> yup... joint-pos-cmd
[13:35:16] <mozmck> automata: it looks like you can also get the position in code from EMC_MOTION_STAT.axis[xx].output
[13:39:39] <automata> looking that up right now
[13:41:52] <mozmck> the output variable is set to pos_cmd internally which is the same as the joint-pos-cmd hal pin
[13:42:08] <automata> the variable emcStatus.motion.axis[xx].output
[13:42:24] <automata> that seems good
[13:42:54] <mozmck> that should be correct
[13:43:08] <automata> got it thanks...
[14:15:04] <seb_kuzminsky> skunkworks: curl
http://highlab.com/~seb/linuxcnc/dists/archive-signing-key.gpg | sudo apt-key add -
[14:17:36] <skunkworks> seb_kuzminsky, thanks. what installes the latency test suite? or is it in a different location?
[14:18:23] <seb_kuzminsky> it's in rtai-modules-3.16.0-9.deb
[14:18:46] <skunkworks> I thought that wasn't working
[14:18:47] <seb_kuzminsky> first you need linux-image-3.16.0-9-rtai-amd64, then reboot, then rtai-modules
[14:19:07] <skunkworks> ok - will do
[14:19:19] <seb_kuzminsky> it's just the math part that's not working, as far as i know
[14:19:23] <seb_kuzminsky> you can still run the rtai latency test
[14:21:57] <seb_kuzminsky> skunkworks: and i'm actively monkeying with that repo, so it may well be broken from time to time
[14:26:48] <skunkworks> oh
[14:27:26] <skunkworks> seb_kuzminsky,
http://pastebin.com/zaMk8HYp
[14:30:15] <seb_kuzminsky> skunkworks: i had that same problem with the user/latency test, but the kern/latency test worked for me
[14:30:20] <seb_kuzminsky> (after i fixed it)
[14:30:34] <seb_kuzminsky> since linuxcnc uses rtai in kernel mode, that's a more relevant test, anyway
[14:33:09] <skunkworks> seb_kuzminsky, oh. wasn't paying attention..
[14:33:36] <skunkworks> That works better (kern) still get the odd overrun at the start. (but you said you where getting that too...)
[14:33:49] <seb_kuzminsky> ok i'm glad it runs at least!
[14:34:04] <seb_kuzminsky> i want to get math working on amd64, then i'll look in to the overrun thing
[14:55:51] <jepler> seb_kuzminsky: thanks for that (lxrt.so)
[14:56:06] <jepler> I have this dream that uspace could dlopen lxrt.so and use rtai's userspace realtime mode
[14:56:30] <jepler> seb_kuzminsky: do you have any more details about the math problems?
[15:13:54] <mozmck> jepler: so with your tip, I changed my code to this and it works:
http://pastie.org/10616909 I add inhibit_probe_errors=1 to the loadrt line for motmod
[15:14:56] <jepler> does your change simply put all that checking under if (!inhibit_probe_errors) { ... } ?
[15:15:20] <jepler> git diff -b might show it more clearly for discussion purposes
[15:16:18] <mozmck> Yes it does, and I don't know why diff made a mess of it...
[15:16:21] <jepler> do I also understand correctly that with this change activated, "g0 z-1" crashes the probe right into the table instead of stopping?
[15:16:51] <jepler> .. but it lets you disable some other hack which meant that g38.2 z-1 without a preceding m-code would do the same thing?
[15:16:54] <mozmck> no, it should only affect a jog or home error
[15:17:03] <jepler> ok
[15:17:54] <jepler> returning to your specific situation, did you consider masking the probe input specifically when the homing state machine is not in state 0?
[15:17:59] <mozmck> http://pastie.org/10616915
[15:18:29] <jepler> thank you. A patch of that form is better for discussion, but not appropriate for applying with patch or git apply
[15:18:36] <mozmck> I had not heard of diff -b, need to look that up
[15:18:50] <jepler> basically, it ignores changes in amount of whitespace
[15:18:57] <mozmck> oh, I see.
[15:19:16] <jepler> but normally those have to be shown in a diff, because space is the same as any other character
[15:20:32] <jepler> I assume the letter b is just because they ran out of good letters
[15:22:17] <jepler> it would be nice if this optional laodrt parameter were added to the motion.9 manpage (docs/man/man9)
[15:22:18] <mozmck> I haven't really looked at the homing state machine much yet.
[15:22:21] <cradek> it seems easy to mask the probe error while homing using hal
[15:22:47] <jepler> axis.N.homing OUT BIT
[15:22:47] <jepler> TRUE if the joint is currently homing
[15:22:48] <cradek> I don't know how you avoid the error while jogging past the home switch
[15:23:08] <jepler> yes it's true that doesn't help you jog on or off the switch
[15:23:35] <jepler> there's limit override, is that exposed to hal?
[15:23:38] <mozmck> I've done it in hal, using a tristate
[15:23:50] <cradek> jepler: *home*
[15:24:07] <cradek> jepler: I take it mozmck is not homing to the limit switch
[15:24:22] <jepler> cradek: it's sure not a switch you can move past in normal operation, if it also acts like triggering the probe
[15:24:27] <cradek> are there limit switches? you could home to one and save the input for just the probe...
[15:24:31] <mozmck> So I set an output with M64 in gcode to enable the probe input, call G38.2, then M65 to disable probe input again.
[15:25:04] <cradek> yuck, you sure need another input or three
[15:25:17] <jepler> adding software is easier than adding IOs
[15:25:31] <mozmck> No limit switch, but the home switch is the same as the probe input
[15:25:36] <cradek> not if you have to fiddle with special gcodes forever
[15:26:51] <cradek> fwiw, I'm fine with a patch that makes the errors optional (but I'd prefer it come from the ini file, even though it's a bit more of a pain to write)
[15:27:28] <mozmck> I wondered about that. It was enough of a pain that I didn't write it (yet) ;-)
[15:27:58] <cradek> I was looking for an example you could use, but only found
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=123a8c91aab1ffe2fb09ae2b3ad519dac99356ca which is a per-axis thing so not a great example
[15:28:21] <cradek> but it does show all the layers you have to touch to pass the parameter into motion
[15:28:43] <mozmck> Ah - I'll look at that.
[15:29:25] <cradek> you'll probably be in initraj.cc instead of iniaxis.cc
[15:30:25] <mozmck> I thought it looked like I'd have to do something like that.
[15:30:59] <cradek> yeah :-/
[15:30:59] <mozmck> I'll do some testing with what I have first to make sure it will do everything I need.
[15:31:04] <cradek> cool
[15:33:55] <cradek> I can't find a good example
[15:33:57] <jepler> I think my interest is finding a way to mask the probe signal for the least amount of time. making it be done in hal is secondary.
[15:39:13] <mozmck> jepler: this patch doesn't mask the probe signal at all though, it just doesn't error if the probe trips while jogging or homing
[15:48:17] <jepler> OK, I accept that distinction.
[16:23:46] <skunkworks> zlog:
[16:43:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 209684f 06linuxcnc 10src/Makefile build system: let "make V=1" verbosify kernel module builds too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=209684f
[17:24:08] <linuxcnc-build> build #1573 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1573 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:24:20] <skunkworks> seb_kuzminsky: how do you install all the dependancys easilly for linuxcnc? (say - isntalling on jessie)
[17:26:04] <seb_kuzminsky> skunkworks: cd debian; ./configure -r
[17:26:14] <seb_kuzminsky> then look in debian/control, it has the list of dependencies
[17:26:34] <skunkworks> ok - I will try that when you get the math working :)
[17:26:49] <skunkworks> no pressurfe
[17:26:52] <skunkworks> pressure even
[17:27:26] <JT-Shop> skunkworks: this may help
http://gnipsel.com/files/linuxmint/mint-emc.txt
[17:27:37] <JT-Shop> my notes on installing in linuxmint
[17:27:59] <seb_kuzminsky> or you can go balls out and build the deb and install it with apt-get, that'll pull in all dependencies
[17:28:19] <skunkworks> bla bla bla apt-get bla bla...
[17:28:31] <seb_kuzminsky> moo
[17:28:35] <skunkworks> JT-Shop: thankss
[17:28:38] <skunkworks> :)
[17:29:09] <seb_kuzminsky> JT-Shop: what's setup.sh?
[17:29:46] <JT-Shop> it gets the rtai kernel and a few things
[17:30:16] <JT-Shop> and adds the grub customizer
[17:30:27] <JT-Shop> so it's easy to pick a start up kernel
[17:39:15] <seb_kuzminsky> cool
[17:47:02] <JT-Shop> I did it about 4 times so pretty polished instructions
[17:50:05] <seb_kuzminsky> i wonder how many different "how to install linuxcnc" instructions we have now
[17:50:14] <seb_kuzminsky> i think there are at least two on the wiki
[17:51:31] <JT-Shop> I'd guess you need one for each flavor of Linux
[17:52:40] <seb_kuzminsky> the differences from one debian-based distro to another should be very small, i think
[17:53:02] <seb_kuzminsky> and the trickiest part, the list of build-dependencies, is encoded in debian/control(.in)
[17:55:05] <JT-Shop> took me a few times to get all the dependencies worked out for mint
[17:55:36] <JT-Shop> I think for a machine debian with openbox would be fine
[17:58:41] <andypugh> One thing that might be clearer on the current “how to get it page” is why you would choose RTAI or RT-PREEMPT
[17:59:32] <JT-Shop> that would be a good thing to know and uspace I think is another option
[18:53:35] <mozmck> JT-Shop: uspace == RT-PREEMPT afaik
[18:56:50] <seb_kuzminsky> uspace just means the realtime threads run as userspace threads
[18:57:26] <seb_kuzminsky> if those userspace threads run under an rt-preempt kernel, they get realtime performance, if they run under a vanilla kernel (or rtai), they get regular high-latency userspace scheduling
[19:04:11] <mozmck> true, which I'm assuming would not be too useful to most people.
[19:06:44] <andypugh> It means you can run the uspace build as a sim config.
[19:06:47] <seb_kuzminsky> it's like the old "sim" build
[19:06:49] <seb_kuzminsky> yep
[19:07:20] <seb_kuzminsky> i probably run more in sim than in realtime
[19:07:32] <seb_kuzminsky> err, i mean, uspace on vanilla kernels
[20:32:02] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 6b584f2 06linuxcnc New branch with 210 commits pushed, 10380 files changed, 0318395(+), 0410855(-) since master/58ab506
[20:32:48] <andypugh> Do you think he meant to do that? It looks extreme
[20:33:41] <andypugh> Oh, a JA10. Seems he has just been working very had
[20:37:14] <seb_kuzminsky> yeah, looks like dewey rebased ja again
[20:37:52] <andypugh> So, what’s in the way of JA going mainline now?
[20:38:23] <linuxcnc-build> build #3718 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3718 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:38:23] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:38:48] <andypugh> Hey! It’s my fult twice :)
[20:38:52] <linuxcnc-build> build #3720 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3720 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:38:53] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:39:08] <linuxcnc-build> build #2928 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2928 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:39:08] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:40:27] <linuxcnc-build> build #1878 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1878 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:40:27] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:40:36] <linuxcnc-build> build #1879 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1879 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:40:36] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:40:38] <linuxcnc-build> build #2070 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2070 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:40:38] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:40:41] <linuxcnc-build> build #1389 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1389 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:40:42] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:41:07] <linuxcnc-build> build #1544 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1544 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:41:07] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:43:28] <linuxcnc-build> build #346 of 1502.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/346 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:43:28] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:43:35] <linuxcnc-build> build #346 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/346 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:43:36] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:43:45] <linuxcnc-build> build #346 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/346 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:43:45] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:43:50] <linuxcnc-build> build #346 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/346 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:43:50] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:47:29] <seb_kuzminsky> the build problem is merge conflict markers in the docs :-(
[20:53:49] <linuxcnc-build> build #1911 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1911 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[20:53:49] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[20:55:32] <linuxcnc-build> build #3732 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3732 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Kim Kirwan
[20:55:32] <linuxcnc-build> <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[21:06:55] <jepler> make: *** [../docs/src/Master_Getting_Started.pdf] Error 1
[21:07:00] <jepler> ... with the real error hidden somewhere further up
[21:13:32] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 af3df77 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt updating-linuxcnc.txt: remove merge markers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=af3df77
[21:32:58] <seb_kuzminsky> there are some merge conflict markers in halui.1 too
[22:16:08] <mozmck> heh, from command.c, "Using commands to set config parameters is "undesireable", because of the large amount of code needed for each parameter."
[22:16:27] <mozmck> unfortunately, no alternative is mentioned :-/
[22:28:05] <seb_kuzminsky> mozmck: hal maybe?
[22:29:13] <mozmck> Yeah, I did that, but cradek said (and I tend to agree) he would rather see it be an ini setting.
[22:29:57] <mozmck> Keeping settings as much in one place as we can seems like a good idea for reducing complexity.
[22:32:33] <mozmck> heh, or I could do it the way it is done for servo_period_nsec: use an INI setting to set the value and use that in an option on the loadrt line :-D
[22:33:30] <mozmck> Looks like jmk's comment is not necessarily the only way to do it - I see several other configs set using far less code.