Back
[00:00:57] <cradek> goodnight!
[00:01:55] <seb_kuzminsky> ok goodnight :-)
[00:02:15] <seb_kuzminsky> heh then it says "verifying download...checksum matches OK"
[00:02:21] <seb_kuzminsky> not great
[00:02:25] <seb_kuzminsky> it matches OK
[00:03:26] <seb_kuzminsky> oh, i think it was operator error on my end
[00:03:27] <memfrob> *sum -c says the same thing (md5sum, etc)
[00:04:01] <seb_kuzminsky> apparently using an iso in libvirt changes the ownership of the file to libvirt-qemu.libvirt-qemu
[00:04:05] <seb_kuzminsky> that's some wtf right there
[00:04:47] <seb_kuzminsky> ok, the old and the new files match, so i think the rename worked
[00:04:55] <memfrob> hey seb_kuzminsky can you post the github link again to that deb builder git repo so i can build debs outside of debian?
[00:05:09] <seb_kuzminsky> oh sure, just a sec
[00:05:53] <seb_kuzminsky> here it is:
https://github.com/SebKuzminsky/linux-rtai-build
[00:06:16] <memfrob> thank you!
[00:06:36] <memfrob> that only builds rtai userspace (/usr/realtime) or kernel too?
[00:06:37] <seb_kuzminsky> that clones a bunch of other git repos, including the debianized kernel sources, and builds debs from them
[00:06:48] <memfrob> ah its both, i see
[00:07:01] <seb_kuzminsky> the tricky bit will be to update the kernel source git repo with the new kernel version & rtai patch
[00:07:20] <seb_kuzminsky> that's here:
https://github.com/SebKuzminsky/linux-rtai-debian
[00:07:30] <seb_kuzminsky> it's both and then some
[00:07:35] <memfrob> yes id like to build 3.16 debs because the only system so far ive tested it on, it kinda sucks with.
[00:07:44] <seb_kuzminsky> bummer
[00:07:46] <memfrob> i dont know if thats wide-spread or just me
[00:07:58] <memfrob> im also using hardware not similar at all to the rest of the linuxcnc community
[00:08:31] <memfrob> nor RTAI community.. nor 99% of the linux community come to think of it. who uses linux and pays $500 on a GPU
[00:10:09] <seb_kuzminsky> heh
[02:20:04] <memfrob> seb_kuzminsky: im looking at your makefile for linux-rtai-build, almost as big as kernel.org's
[02:20:29] <memfrob> this is gunna take awhile to read and modify heh
[07:02:06] <skunkworks> 2.7 is that close?
[09:09:53] <seb_kuzminsky> memfrob: the top-level makefile isn't that important, the hard-ish part is going to be the kernel debianization
[09:11:02] <seb_kuzminsky> you'll have to find the debianization of the nearest kernel version (from the debian kernel folks)
[09:11:10] <seb_kuzminsky> the link to their svn is in the top-level readme
[09:11:52] <seb_kuzminsky> then look at the 3.4.55-rtai branch of my kernel debianization repo and see which of those commit you need to cherry-pick or reimplement in your 3.16-rtai branch
[09:12:11] <seb_kuzminsky> then change a couple of variables in the top-level makefile to use your new branch
[09:12:25] <skunkworks> easy peezie
[09:13:13] <seb_kuzminsky> skunkworks: i'm not sure how close 2.7 is... but it's closer now that we have the install cd
[09:13:25] <skunkworks> neat
[09:13:53] <seb_kuzminsky> i'm going to update the Getting Started docs with "fresh install" instructions using the live cd, then i'm waiting to merge dgarr's hallib branch, then i'll make a 2.7.0~pre3 release
[09:14:05] <seb_kuzminsky> i'm hoping that will get wider testing than ~pre2 did
[09:14:14] <seb_kuzminsky> it'll have dgarr's moveoff comp
[09:15:04] <skunkworks> nice
[09:15:09] <seb_kuzminsky> then depending on how it goes with testing & bug reports we'll be well prepared to move ahead with the 2.7 branch
[09:15:32] <seb_kuzminsky> I'm very happy with the feature set in the 2.7 branch, and i'd like to have a much shorter release cycle than 2.6 did
[09:18:34] <skunkworks> I have not played with the moveoff comp yet. The only big scary thing that I see on the man page is the issue if you say hit the estop during the offset. you have to make darn sure the enabling takes into account the offset.
[09:21:35] <skunkworks> (the examples might handle this gracefully - I don't know)
[10:13:31] <skunkworks> hmm playing with it a little bit. Doesn't make sense - if the offset is removed (by estop) wouldn't the backplot jump to the new encoder position?
[10:13:45] <skunkworks> which would be harmless
[15:19:12] <memfrob> seb_kuzminsky: make-kpkg handles that for me
[15:31:40] <seb_kuzminsky> memfrob: make-kpkg does make debs, but it makes them differently than the debianization of the kernel that builds the official debian.org and ubuntu.com kernel debs
[15:32:43] <seb_kuzminsky> i dont remember all the differences off the top of my head, but back when i worked on this 6 months ago i remember deciding that the offical way was preferable to the kernel-package (make-kpkg) way
[15:38:17] <mozmck> for the ubuntu kernels, there is a git repository and all the debianization is done already.
[15:44:27] <seb_kuzminsky> mozmck: yep, similar for the debian.org kernel, though they use svn
[15:44:43] <seb_kuzminsky> there's a link to their public repo in the readme of the package builder that memfrob is looking at
[15:44:43] <mozmck> I see. I haven't looked at theirs.
[15:44:56] <mozmck> make-kpkg?
[15:45:02] <seb_kuzminsky> no
[15:45:18] <seb_kuzminsky> https://github.com/SebKuzminsky/linux-rtai-build
[15:46:21] <seb_kuzminsky> so what i did for the 3.4.55-rtai kernel we're shipping on wheezy and precise was to find the commit in their repo that most closely corresponded to the kernel version i was targetting, branch from that point and smack it until it built
[15:46:45] <seb_kuzminsky> and the result is here:
https://github.com/SebKuzminsky/linux-rtai-debian
[15:48:53] <Tom_itx> heh such technical terms...
[15:50:26] <seb_kuzminsky> it was a delicate, precise kind of smacking
[15:52:27] <mozmck> ah, I see.
[18:57:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0c29415 06linuxcnc 03docs/src/getting-started/Getting-LinuxCNC.txt 10docs/src/getting-started/Getting-Started-with-LinuxCNC.contents.txt 04docs/src/getting-started/Getting_LinuxCNC.txt docs: rename english Getting-Started document for consistency * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0c29415
[18:57:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 294b471 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: new link to the live/install cd * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=294b471
[19:02:23] <andypugh> seb_kuzminsky: If you are doc-wrangling, there are lots of HAL components that are not mentioned in:
http://www.linuxcnc.org/docs/html/hal/components.html
[19:06:47] <andypugh> This footnote is wrong too, I believe:
http://www.linuxcnc.org/docs/html/hal/rtcomps.html#_footnote_1 (just needs deleting)
[19:07:16] <seb_kuzminsky> i've been mostly focusing on getting the install & upgrade docs moved from the wiki to the "real" docs
[19:08:13] <seb_kuzminsky> wow, that hal/components.html page should probably just be removed
[19:08:26] <seb_kuzminsky> we autogenerate the front page to include all that stuff
[19:09:02] <andypugh> No problem, I just thought it was worth mentioning. If I took the time to learn asciidoc I could make the changes myself. Most of the HAL component omissions are the ones I have added and only done a manpage for, rather than look for other places in the docs they should be mentioned
[19:09:43] <seb_kuzminsky> i think it's kind of wrong that we have multiple docs for several of our things
[19:11:04] <seb_kuzminsky> if you look at docs/src/hal/rtcomps.txt and search for the text in that footnote, you'll see the asciidoc formatting is pretty easy to read
[19:11:17] <andypugh> I can’t decide if it makes it more or less likely that people will find what they want. That page of HAL components is liable to make people think that what they want isn’t there.
[19:11:55] <andypugh> Can be remove bldc_hall for 2.7? It has been very much superceeded for a long time now
[19:12:20] <seb_kuzminsky> a good thing about hal/components.html is that it kinda sorts the components and tells you briefly what they're for
[19:12:34] <seb_kuzminsky> if you think bldc_hal should be removed, i respect your opinion
[19:12:48] <seb_kuzminsky> has it been superceeded by bldc?
[19:12:52] <andypugh> Yes
[19:13:14] <andypugh> It does a small subset of the things that bldc does
[19:13:18] <seb_kuzminsky> i see
[19:13:29] <seb_kuzminsky> typically removal is done in two stages
[19:13:45] <seb_kuzminsky> stage 1: note in all the docs that the thing is going away, and release that
[19:13:54] <seb_kuzminsky> stage 2: remove the thing in a later releasee
[19:14:18] <seb_kuzminsky> that way folks who use is have time to switch at their leisure
[19:14:53] <seb_kuzminsky> i've got to go, bbl
[19:15:59] <andypugh> The bldc_hall manpage has been saying “will be removed” for at least one major release, possibly two:
http://www.linuxcnc.org/docs/html/man/man9/bldc_hall3.9.html
[19:51:27] <KimK> Speaking of hal, I would be interested in suggested methods and tutorials for examining and debugging classicladder. I'm getting back to a project I set aside long ago, and I am beginning to think that classicladder (sometimes whole OS) can be made to crash with bad .clp files. (Corrupt format? simply too large? bad CL setup params? generic memory errors? I don't know.)
[19:52:27] <KimK> So I was wondering what it might take to do memory debugging on CL, and do format verification on the .clp files, and whatever else sounds like it might be good.
[19:54:16] <KimK> Suggestions and advice appreciated. Thanks in advance. I'll be nearby, getting something to eat.
[19:58:06] <mozmck> As far as doc locations, manpages are really only good for more advanced linux users I would say.
[19:58:37] <PCW> Speaking of bugs, found a fun bug in the axis calibrate pane, not sure exactly how I did it but managed to splatter the ini file name throughout the ini file
[19:58:39] <PCW> (appended to various parameters)
[20:00:47] <PCW> ("save to file" did a bit more than I wanted)
[20:57:55] <dgarr> seb_kuzminsky: i will merge v2_hallib to 2.7 soon (hallib with HALLIB_PATH and LIB: for explicit naming without search) thanks for your suggestion on path,this is a good compromise
[20:59:05] <dgarr> and i will have some updates for moveoff in a few days after testing on hardware with PID loops, with an xzc machine, and a new use-case to support offsets always as well as onpause
[21:10:50] <seb_kuzminsky> andypugh: oh, that's great! in that case yes, please to remove it
[21:11:47] <seb_kuzminsky> and add a note to the "Updating your config" part of the "Updating LinuxCNC" document advising users to switch to the bldc component
[21:24:13] <seb_kuzminsky> PCW: that's freaky
[21:24:18] <seb_kuzminsky> is it reproducible?
[22:15:29] <KGB-linuxcnc> 03Dewey Garrett 052.7 8b44ccf 06linuxcnc 10(37 files in 10 dirs) hallib: support for system-wide halfiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b44ccf
[22:16:37] <seb_kuzminsky> thanks dgarr !
[22:45:40] <seb_kuzminsky> wow, this guy seriously misunderstands what linuxcnc is capable of:
http://blog.cnccookbook.com/2014/12/16/10-features-pros-hobby-cnc-controllers-dont/
[22:47:09] <seb_kuzminsky> no branching in gcode? no rigid tapping? no home-to-index? backlash compensation? buggy tool compensation?
[22:50:08] <skunkworks> he was a mach guy.. but does have a tormach lathe now.
[22:50:33] <skunkworks> but yes - a good percentage of those things linuxcnc can do perfectly..
[22:52:32] <cradek> > I will say that while Mach3 on my mill has had a number of bugs off and on, LinuxCNC on my Tormach Lathe has been solid so far. The Tormach guys really gave it a wringing out.
[22:52:32] <skunkworks> and dripfeeding is an advantage... just odd.
[22:52:46] <cradek> now that's just really obnoxious
[22:53:55] <seb_kuzminsky> i'm crafting a very polite and factual comment...
[22:54:17] <cradek> he should have made it clear the article was about his uninformed feelings, not about facts
[22:54:40] <cradek> I think this is hard, therefore linuxcnc must not do it, never mind googling it
[22:55:14] <cradek> he's right about the lathe roughing cycle
[22:55:33] <cradek> but linuxcnc has homed to index for 20 years for fuck's sake
[22:55:36] <skunkworks> that would be an awesome addition.. I know someone started working on it...
[22:55:47] <cradek> yeah I'd love to have it
[22:56:00] <skunkworks> I can't remember who though
[22:56:13] <skunkworks> he seemed to be pretty far along
[22:56:55] <cradek> http://xkcd.com/386/
[22:59:05] <skunkworks> bpuk
[23:00:50] <seb_kuzminsky> wow, i hadn't noticed skunkworks' rigid peck tapping video before
[23:00:53] <seb_kuzminsky> https://www.youtube.com/watch?v=jAcFeVlftrw
[23:00:57] <seb_kuzminsky> neat
[23:01:24] <skunkworks> and that is only because I was holding a 1/2 tap in a drill chuck..
[23:01:29] <skunkworks> lazy bastard
[23:03:05] <skunkworks> http://comments.gmane.org/gmane.linux.distributions.emc.user/39104
[23:03:29] <skunkworks> http://www.bpuk.org/linuxcnc/
[23:05:03] <skunkworks> cool
[23:05:05] <skunkworks> http://www.bpuk.org/linuxcnc/g71_finish_allowances.png
[23:15:37] <KimK> I just looked at the guy's 10-point article. On #10 (drip feeding), that's been unnecessary for a long time, but his point about trying to insure correct gcode (from a central source?) is valid, and reminds me of a feature I'd like to see.
[23:15:37] <KimK> When enabled (in the ini file?) linuxcnc (what, axis? not sure.) would load from a local git repo (fed from the "programming office"). If the operator wanted to make changes in the gcode for whatever reason (programmers assumptions were in error, had to use a different vice/tool/fixture, whatever) the operator *can* make changes in the gcode, but he must git commit and say what he did and why.
[23:17:41] <KimK> There would have to be a "save changes" button, of course, the operator doesn't need to know how git works.
[23:19:18] <KimK> Just an idea.
[23:39:53] <seb_kuzminsky> ok, i posted it, it's awaiting moderation
[23:49:24] <KimK> Hi Seb, I'll keep the article open, I'll look forward to seeing your comments. I assume you're delivering more of your "...delicate, precise kind of smacking..."?
[23:49:59] <KimK> Or maybe that's just for kernel building?
