Back
[00:52:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort e6d2216 06linuxcnc 10(6 files) add a test to reproduce the preview-strangeness reported by Zultron * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e6d2216
[01:14:41] <linuxcnc-build> build #2320 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2320 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:15:46] <linuxcnc-build> build #2320 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2320 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:17:00] <linuxcnc-build> build #4159 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4159 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:17:59] <linuxcnc-build> build #788 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/788 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:19:11] <linuxcnc-build> build #4161 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:19:33] <linuxcnc-build> build #4161 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:20:21] <linuxcnc-build> build #4161 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:20:22] <linuxcnc-build> build #788 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/788 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:21:41] <linuxcnc-build> build #1986 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1986 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:24:35] <linuxcnc-build> build #3370 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3370 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:35:48] <linuxcnc-build> build #4169 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/4169 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:35:49] <linuxcnc-build> build #4173 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4173 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[07:34:53] <jepler> The value of drive-through contributions
https://lwn.net/SubscriberLink/688560/3c94df68e5d5b56d/
[08:27:18] <skunkworks> ugh..
http://www.cnczone.com/forums/uncategorised-cam-discussion/307546-cnc-software-3.html#post1888876
[08:34:40] <archivist> do you educate people like that or leave the incorrect statement out there...
[08:37:28] <skunkworks> I have failed at explaining it atleast 3 times now
[08:38:13] <pcw_home> Mach centric blindspots? (I think he thinks LinuxCNC is step/dir at its base like Mach3)
[08:38:15] <pcw_home> his stuff about the Gecko is misleading as well (all you can do is widen the already too wide error limits)
[08:38:46] <skunkworks> right
[08:39:24] <skunkworks> and visually looking at the in position led means his machine is running great
[08:40:23] <pcw_home> Well its all he's got since at base Mach3 is open loop and at base linuxcnc was designed around closed loop
[08:41:40] <pcw_home> this does remind me, it would be nice to have 2 ferror threshold in linuxcncs, one for warning and one for stop
[08:58:58] <skunkworks> Hmm - sounds interesting.. I bet that could be done with hal?
[08:59:25] <pcw_home> Yes it could
[09:05:58] <pcw_home> I suspect in most machining situations, a machine fault from a following error is pretty
[09:06:00] <pcw_home> disastrous so that argues for quite wide limits to avoid nuisance trips
[09:06:01] <pcw_home> but a warning limit (and perhaps having the peak ferror recorded) would be good for machine
[09:06:03] <pcw_home> maintenance
[09:07:10] <archivist> that makes me think of tap breakage alarm and tool wear measuring
[09:37:07] <jepler> part of the calculus would be: how much less ruined is work / vise / table / etc after a 1mm following error vs a .01mm following error?
[09:39:34] <jepler> let alone 10mm
[10:36:45] <pcw_home> To me, there seem to be 2 purposes for following error limits (and it seems like the limit sizes should be different)
[10:36:46] <pcw_home> 1. Safety / machine fault detection
[10:36:48] <pcw_home> 2. Performance monitoring (perhaps with peak ferror recording)
[11:40:27] <mozmck> Well, I got a simple rfl to do something. It fails in a different way than the normal one...
[11:41:20] <cradek> yay?
[11:41:56] <pcw_home> failing in a different way is progress
[11:42:12] <skunkworks> have you slept?
[11:42:12] <mozmck> heh, I'm apparently missing something that needs to be cleared out.
[11:42:22] <mozmck> Yes, I slept :-)
[11:43:19] <mozmck> I may need to figure out exactly how external file o-word subs are executed.
[11:43:23] <skunkworks> I would have used a goto jump.
[11:43:33] <mozmck> There's one in there ;-)
[11:43:53] <skunkworks> ;) Just read my REM statements
[11:45:07] <pcw_home> At least you got a change, I just spent 1/2 an hour trying to fix some Xilinx RAM compile warnings, result: exact same warnings
[11:46:14] <mozmck> heh, not familiar with xilinx much (yet), but certainly familiar with going around in circles.
[11:47:36] <skunkworks> pcw_home, there is a thread on the forum about ethercat - the guy switched from a e1000e compatable nic (intel) to a realtech and it solved his issue.
[11:47:48] <pcw_home> Apparently you can infer any type of dual ported RAM you like but it always make one with 2 read and 2 write ports even if you only need 1read/1write (and complains about the unconnected output port)
[11:48:49] <pcw_home> skunkworks: the H97 MB has a E1000 compatible NIC and has no issues
[11:49:08] <skunkworks> maybe it is certain series.
[11:49:23] <pcw_home> but its a newer one ( a 211 I think)
[11:52:13] <jepler> ethercat's hardware needs are different from hm2_ethernet too
[11:52:40] <pcw_home> I think Ive heard of firmware bugs in the early E1000s
[12:17:58] <pcw_home> what specific MAC chip do you have trouble with ?
[12:17:59] <pcw_home> the DC7800 I use has a Intel 82566DM which works OK ( I Guess all Intel 1Gbe MACs show up as PRO/1000)
[12:39:34] <skunkworks> This is a 82579lm
[12:39:45] <skunkworks> (but it is also a laptop)
[12:47:40] <pcw_home> Yeah, still suspicious that is some funny power saving feature
[12:47:48] <pcw_home> that its
[12:47:58] <skunkworks> right
[13:15:38] <mozmck> So my SRFL is barfing on the first line with no G-code, because there is no state information :-/
http://pastie.org/10853722
[13:19:38] <mozmck> which means I probably can't call Interp::read without modification
[13:26:33] <mozmck> Here's what I've done so far.
https://github.com/mozmck/linuxcnc-mirror/commit/28420306f9a32ceb70669efd2bd5e0c33f9ce873?diff=split
[13:27:01] <mozmck> I was hoping to be able to do this all in task, but it looks like it won't be that easy.
[13:28:17] <mozmck> I was trying to just have Interp read the lines to update the file position, but it does too much checking while it reads.
[13:30:31] <mozmck> Any ideas on a better method?
[13:34:29] <mozmck> hmm, I could make simpleRunFromLine global, and in Interp::read() I could simply not call parse_line() if it's set - no telling what side effects that will have.
[13:39:16] <cradek> can you give me an example of what you mean by first line with no gcode?
[13:41:29] <cradek> mozmck: one early comment: I get lost in your diff because of the whitespace changes in emctaskmain - it sure was bad before, but it'd be better that if you must fix it, to do that in a separate commit that makes no functional change.
[13:42:19] <mozmck> The gcode is in the pastie link: line 8 of the Gcode is X8.845 Y0.375
[13:42:43] <cradek> ah yep, I'd expect that to be an error in SRFL
[13:42:48] <cradek> I think that is the right behavior
[13:42:51] <mozmck> Yes, I notice the whitespace is not handled well be github's diff viewer
[13:43:06] <cradek> you would need to MDI G0 or G1 first, before you SRFL that
[13:43:08] <mozmck> Meld shows it much nicer
[13:43:39] <mozmck> yes, but I was SRFL'ing (???) from line 27, so it should have just skipped over line 8
[13:43:47] <cradek> mozmck: my feedback about changing it is the same, regardless of how tools show it
[13:43:51] <cradek> oh! I misunderstood then
[13:44:14] <mozmck> I'm going to try my idea in Interp::read() - I think it might work.
[13:44:21] <cradek> if we want to make "srfling" a word I propose that we can do that :-)
[13:45:16] <mozmck> I'll try to make the whitespace a separate commit. One problem with that though, is I wrapped most of the function in an else{ } block, which means I had to change the whitespace as part of that anyhow.
[13:45:50] <skunkworks> srfl?
[13:45:50] <cradek> oh yeah, then it's unavoidable (unfortunately)
[13:46:02] <mozmck> maybe we can call it "snurfling" to make it easier to pronounce :-)
[13:46:03] <cradek> I didn't see that in the first 50 lines or so and I have up trying to understand that block
[13:46:11] <cradek> gave
[13:47:01] <mozmck> Yeah. I have an if { } at the top that adds the SRFL stuff, and an else{ } that does the standard stuff
[13:47:13] <mozmck> skunkworks: simple-run-from-line
[13:47:54] <skunkworks> ah
[13:48:15] <cradek> i.e. start at the specified line after doing nothing else first
[13:48:56] <cradek> it has so many ways to bite you, but it's possible to give an implementation that does exactly what the instructions say :-)
[13:49:54] <mozmck> It is a separate NML command, and also python srfl_auto(), so it will not be used unless you specifically use that command. You could have both in a GUI to give users a choice.
[13:50:48] <mozmck> To test I'm simply modifying axis.py line 2040 from c.auto() to c.srfl_auto()
[14:07:56] <mozmck> So I added my flag to emcglb.h and emcglb.c, and it compiles fine but I get this: ImportError: /mnt/data1/Projects/linuxcnc/linuxcnc-dev/lib/librs274.so.0: undefined symbol: simpleRunFromLine
[14:08:21] <mozmck> when loading axis and hal_manualtoolchange
[15:13:05] <mozmck> Hmm, looks like I might have it working.
[15:13:16] <skunkworks> ooh...
[15:16:05] <mozmck> pretty neat :-)
[15:28:21] <mozmck> https://github.com/mozmck/linuxcnc-mirror/commit/7b4b5f51d88054b0a157c73853900b23d7d322aa
[15:29:25] <mozmck> I'm going to be testing this more thoroughly here. Please feel free to review this (and even make suggestions! ;-) )
[15:30:18] <mozmck> I did this on the 2.7 branch because that is what I need to use for now, but I would expect it might should go on master instead when finished.
[15:39:16] <seb_kuzminsky> mozmck: i agree, it should go in master instead of 2.7
[15:39:40] <seb_kuzminsky> you're of course welcome to put it in a feature branch off 2.7, and the buildbot will test it and make debs for you
[15:39:48] <seb_kuzminsky> just dont merge it into 2.7
[15:40:29] <mozmck> ok - I build my own debs here - that's pretty trivial
[15:40:56] <mozmck> What I haven't messed with is running tests (much less writing or even understanding them!)
[15:41:29] <mozmck> How do I run the tests?
[15:41:53] <jepler> scripts/runtests, or just runtests after you . rip-environment
[15:42:06] <mozmck> thanks
[15:43:40] <jepler> by default it runs them all, which takes a fair bit of time. You can run just specific tests by giving the path(s) on the commandline
[17:08:28] <mozmck> Is there a way to delete branches on github?
[17:11:33] <jepler> git push has a "--delete" flag which deletes remote branches and tags instead of creating/updating them
[17:12:30] <jepler> you can also 'git push :branch-or-tag-to-delete'
[17:12:34] <jepler> git --help push
[17:12:49] <mozmck> ok. It would be nice if there was a way to have just a few branches in a linuxcnc fork, instead of 170+
[17:13:06] <jepler> github seriously sucks with respect to its branch management
[17:13:19] <mozmck> similar to a local clone where you only have the branches you are interested in tracked locally.
[17:13:23] <jepler> and yes, the fact that when you fork you get all the branches that the forked-from repository had at that time is one of them
[17:13:32] <jepler> this is bad design of github, not bad design of git
[17:13:57] <jepler> https://github.com/blog/1377-create-and-delete-branches
[17:13:58] <mozmck> Yes. I'm looking at gitlab, and they have a delete button by each branch
[17:14:04] <jepler> apparently there's also a delete branch on the github web ui if that's how you roll
[17:14:26] <mozmck> interesting, I didn't see that.
[17:16:01] <mozmck> Now I wonder if I can "pull" a branch from the web UI instead of pulling to the PC and pushing to github?
[17:54:12] <andypugh> Any thoughts of the zeroth spindle being controlled by motion.spindle-speed-out if num_spindles is not present as a modparam, and spindle.0.speed-out if the modparam is present? I confess I don’t especially like the kludge.
[17:56:23] <mozmck> I guess that is to keep from breaking existing configs?
[17:58:57] <andypugh> Yes
[17:59:27] <andypugh> If I roll it into JA then it isn’t an issue. We expect that to break configs.
[17:59:40] <mozmck> that's what I was about to say.
[17:59:57] <mozmck> And if JA merges into master before the next release...
[18:07:54] <JT-Shop> are you going to do a num_spindles=n like num_dio and num_aio?
[18:08:07] <JT-Shop> with default at 1 spindle
[18:08:15] <JT-Shop> just thinking out loud...
[18:11:09] <andypugh> Yes.
[18:13:47] <JT-Shop> cool
[18:39:10] <jepler> argh
[18:39:15] <jepler> please consider NOT basing this on ja
[18:39:28] <jepler> it is like blackmailing everyone: you have to accept ja to accept unrelated feature X
[18:40:08] <jepler> and it also means: to accept ja you have to accept feature X
[18:40:23] <jepler> (well depending just how you structure your work, that may or may not be true)
[18:40:54] <jepler> afk
[18:45:23] <andypugh> jepler: Am I allowed to break existing configs?
[18:45:33] <seb_kuzminsky> in master, yes
[18:46:00] * seb_kuzminsky is jepler wearing a glue-on beard
[18:47:05] <cradek> allow me to add my voice to this chorus...
[18:47:11] <seb_kuzminsky> i agree with jepler - best practice is to not put unrelated features in a single feature branch
[18:47:44] <andypugh> Multi-spindles doess feel JA-ish to me.
[18:48:07] <seb_kuzminsky> does it use some feature that JA adds, that's not present in master?
[18:48:26] <andypugh> I am not saying that either is a necessary condition for the other, but it has a similar feel.
[18:49:01] <cradek> but it seems plausible that we could choose to merge them at different times
[18:49:17] <seb_kuzminsky> that's sure a nice freedom/ability to have
[18:49:33] <andypugh> Well, it would be a lot more elegant if it could rely on the pin-renaming macro, rather than futz about with two different styles of spindle control pins.
[18:50:09] <seb_kuzminsky> is the pin-renaming macro a feature that JA adds?
[18:50:27] <andypugh> Yes.
[18:51:17] <seb_kuzminsky> in that case i suggest rebasing ja so that the pin-renaming macro is at the beginning of the branch (right on top of master), merging just that feature into master, and basing the multi-spindle work on that new master
[18:51:27] <seb_kuzminsky> there are some other things in ja that need a rebase still
[18:51:52] <seb_kuzminsky> that would serve two goals: start merging JA into master in small, manageable chunks, and keep unrelated features on separate branches
[18:52:17] <andypugh> And retrospectively invent an INI file version < 1.0 ?
[18:53:02] <seb_kuzminsky> i dont understand what you mean
[18:53:18] <seb_kuzminsky> maybe because i dont really know what the pin-renaming macro is
[18:53:20] <cradek> oh you're talking about the config autoconverter?
[18:53:25] <andypugh> Yes
[18:53:48] <cradek> you could just break configs for now - avoid falling down a deeper rabbit-hole
[18:53:58] <cradek> we break configs (in minor ways) for new major versions all the time
[18:54:05] <seb_kuzminsky> true
[18:54:17] <cradek> but if it turns out the next major version has both multipspindle and ja, we can make the autoconverter autoconvert both
[18:54:25] <andypugh> Breaking every config that uses a spindle might be a tiresome support burden.
[18:54:40] <andypugh> :-/
[18:54:43] <seb_kuzminsky> i broke every hm2 config once or twice, it wasn't that bad
[18:55:00] <seb_kuzminsky> i wrote down the simple change needed in the "Updating your config" part of our docs
[18:55:04] <andypugh> I contend that more configs have spindles than use hm2..
[18:55:13] <seb_kuzminsky> sure
[18:55:28] <seb_kuzminsky> i agree
[18:55:33] <andypugh> And the typical hm2 user is less nooby than the typical spindle user.
[18:55:35] <cradek> we can tie the branches together later if we decide to - there's no reason to do that as the first step
[18:56:15] <seb_kuzminsky> bbl
[18:56:16] <cradek> ok, that's all my opinions - in the end, the guy doing the work gets to decide how to do it
[18:56:59] <cradek> andypugh: I think it'll be a cool feature
[18:57:01] <andypugh> Also (not a great reason) all the physical machines I would be testing on run JA.
[18:57:11] <cradek> I'm off to make music, whee
[18:57:17] <cradek> bbl too
[18:57:28] <andypugh> But testing on sims probably works
[18:59:10] <andypugh> I think that my interest in multispindle is based on completion-anxiety with the lathe project, it’s pretty much at the point where it can bu used, and I get to find out if it’s a decent machine or not.
https://picasaweb.google.com/108164504656404380542/Holbrook#6289136113588913554
[20:07:15] <jepler> andypugh: I *LOVE* reading your project diaries and looking at the pictures
[20:07:25] <jepler> them that can't do, advise others on how to use git :-/
[20:12:19] <andypugh> I am way overdue for an update on the Holbrook n the blog.
[21:50:16] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 9c5f4e2 06linuxcnc 10src/emc/usr_intf/emcsh.cc emcsh.cc update emc_pos_offset command JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c5f4e2
[21:50:16] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 ed4826f 06linuxcnc 10tcl/scripts/Set_Coordinates.tcl Set_Coordinates.tcl use [TRAJ]COORDINATES JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ed4826f
[21:50:16] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 329e3a6 06linuxcnc 10(5 files in 4 dirs) emcsh.cc: use coord letters for emc_* commands JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=329e3a6
[21:50:18] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 58406e4 06linuxcnc 10src/emc/usr_intf/pncconf/build_INI.py pncconf/build_INI.py HOME_* items to [JOINT_n] JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58406e4
[21:50:22] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 aa09d22 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py elim unneeded mode change for touchoffs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aa09d22
[21:50:26] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 d9deb1d 06linuxcnc 10(5 files in 4 dirs) sim configs [DISPLAY]POSITION_OFFSET=RELATIVE JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d9deb1d
[22:16:26] <cradek> that's got to be about the prettiest retrofit ever done
[22:16:52] <cradek> I look forward to seeing what he comes up with for touchy to work with multiple wheels
[22:17:01] <cradek> two wheels on a lathe makes SO much sense
[22:17:27] <cradek> I bet most of what I do on the lathe is just turn the wheel, and two would be much better
[22:18:12] <cradek> I wonder if he'll decide the X wheel should turn "backwards" too
[22:19:49] <mozmck> backwards? opposite of travel?
[22:20:11] <cradek> usual wheel motion is clockwise makes the axis go positive
[22:20:36] <cradek> which feels backwards on a lathe X axis that has the tool in the front (maybe only if you learned on a manual)
[22:20:39] <mozmck> positive being away from the chuck or towards?
[22:20:54] <cradek> lathe positive X in gcode means greater radius/diameter
[22:21:03] <mozmck> I've only ever used a manual lathe.
[22:21:08] <cradek> (yeah positive Z is away)
[22:21:14] <Tom_itx> i would think so yes
[22:21:15] <mozmck> Oh, X is the cross-slide?
[22:21:25] <cradek> yeah, X=radius or diameter
[22:21:26] <Tom_itx> away from center +X
[22:21:26] <mozmck> I would think the long axis is X
[22:21:29] <cradek> nope
[22:21:38] <Tom_itx> toward the chuck is -Z
[22:21:39] <mozmck> wow, that seems backwards already
[22:22:12] <cradek> heh think of cylindrical coordinates on your part - Z should be along the axis of rotation
[22:22:35] <mozmck> So we should really stand the lathe up on end for it to be right ;-)
[22:22:45] <Tom_itx> there are those
[22:23:09] <cradek> yep I agree all lathes should stand on end
[22:23:12] <mozmck> true. I would really like to 'cnc a lathe.
[22:23:41] <Tom_itx> http://www.hsmworks.com/docs/cncbook/en/coordinate_system.png
[22:23:46] <mozmck> Mine would be somewhat custom for banjo work (which I have little time to do anymore)
[22:23:49] <cradek> I often wish I had a manual lathe
[22:23:58] <cradek> but for threadcutting cnc is where you want to be
[22:24:20] <mozmck> I have 3 manual lathes, and wish I could trade one for a cnc ;-)
[22:24:29] <Tom_itx> my bud cut me a 3tpi thread manually for me once
[22:24:34] <cradek> wow
[22:24:37] <Tom_itx> it was interesting to watch him to at it
[22:24:55] <cradek> I cut a left-hand metric thread manually on my sherline for a motorcycle part. in stainless. it was hellish.
[22:25:12] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/temp/thread1.jpg
[22:25:14] <cradek> no dies like that 'round here
[22:25:29] <Tom_itx> kept him on his toes for sure
[22:25:49] <cradek> that's inch bar?
[22:26:01] <Tom_itx> iirc 1.25" or maybe 1.5"
[22:26:15] <cradek> that sounds like a terrible job :-)
[22:26:33] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/temp/thread.jpg
[22:26:35] <cradek> I'm surprised the thread has less chatter than the body
[22:26:37] <Tom_itx> an attempt to fix that
[22:26:48] <mozmck> I made a backplate for my lathe chuck, but a friend down the road cut the threads. It was something like 2 5/16" x 8
[22:26:52] <cradek> furniture?
[22:26:53] <Tom_itx> yeah i wasn't concerned about the body so much
[22:26:57] <Tom_itx> yes antique
[22:27:01] <cradek> neat
[22:27:07] <Tom_itx> very heavy
[22:27:11] <mozmck> He has all kinds of high-end cnc machines, but cut that with a manual lathe and it looked great.
[22:27:38] <cradek> last threadcutting for an antique-related project I did:
http://timeguy.com/cradek-files/01432612268/ao-screws-done.jpg
[22:27:47] <cradek> a bit smaller than yours
[22:27:50] <Tom_itx> it was the lowest gear combination he had and he'd never used it
[22:27:54] <cradek> hah
[22:28:18] <Tom_itx> most all of em start around 8tpi or so
[22:28:44] <cradek> I don't machine much right now. I miss it.
[22:28:55] <Tom_itx> same here
[22:32:06] <linuxcnc-build> build #3398 of 2000.docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/3398 blamelist: Dewey Garrett <dgarrett@panix.com>
[22:33:06] <cradek> seb_kuzminsky: ^^^ dreamhost moved us to another host again, which screws up our host key cache everywhere again
[22:43:33] <linuxcnc-build> build #4174 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4174 blamelist: Dewey Garrett <dgarrett@panix.com>
[22:58:36] <seb_kuzminsky> cradek: fixed, thanks for the clue
[22:58:56] <seb_kuzminsky> linuxcnc-build: force build --branch=joints_axes14 0000.checkin
[22:58:57] <linuxcnc-build> build forced [ETA 1h22m34s]
[22:58:57] <linuxcnc-build> I'll give a shout when the build finishes
[23:05:05] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja14-abshome bee8068 06linuxcnc 10(9 files in 5 dirs) homing: HOME_ABSOLUTE_ENCODER squash all JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bee8068
