Back
[00:08:55] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[00:08:57] -!- zlog [zlog!~zlog@ip68-102-196-26.ks.ok.cox.net] has joined #linuxcnc-devel
[00:31:13] -!- skorasaurus has quit [Ping timeout: 258 seconds]
[00:54:32] <jepler> PCW: OK, I must not have noticed the error LED here
[00:54:47] <jepler> PCW: is there a different location I can use for scratch that would work around the error?
[00:56:30] <PCW> no I screwed up the parser decoding of space 4? so write to the scratch area overlaps the timer area
[00:59:14] <jepler> someplace in space 0 (hostmot2 address space) maybe?
[00:59:33] <PCW> The VHDL and CPU parser source is fixed in V16 (in 5i25.zip or 7I80.zip)
[01:00:04] <jepler> now that we know this I'm not sure we can/should merge it to 2.7, if everybody with an ethernet card has to get a new firmware that's bad
[01:01:07] <PCW> its not really harmful currently (other than the LED)
[01:05:20] -!- andypugh has quit [Quit: andypugh]
[01:05:23] <PCW> I'll make new bitfiles this week sometime
[01:05:25] <PCW> V16 firmware also has support for reception of broadcast ping and UDP packets
[01:05:26] <PCW> but needs the netmask written to the EEPROM for use with the EEPROM IP address
[01:05:28] <PCW> (the ROM IP address has a fixed 255.255.255.0 netmask)
[01:07:09] <jepler> for instance, knowing that we don't really use TRAM, I could use space 0 addresses 0x7bf8 and 0x7bfc instead
[01:07:33] <jepler> but if documenting that for versions <16 the error LED will light even if there's no error is OK, I suppose
[01:08:16] <PCW> I ran into this because I added WDtimeout to the things that can light the error LED
[01:11:47] <PCW> I probably should have added a couple scratch registers to HM2 a long time ago (thet are useful for general sanity checking at startup)
[01:13:18] <PCW> you have 256x 32 bit scratch registers in the IDROM but that might be bad on the second startup :-)
[01:15:47] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[01:18:27] <seb_kuzminsky> PCW: can you make the fix in the "v0.8" firmwares that we auto-build and push out to users in debian packages? or has the day for that old version come and gone?
[01:19:25] <PCW> yeah its just 3 or so changed files
[01:20:39] <PCW> the actual bugfix only needs an updated etherhm2.vhd ROM
[01:23:01] <PCW> the Error LED on WD bite needs the updated hostmot2.vhd and TopEthernet16Hostmotm2.vhd
[01:23:59] <PCW> I plan to add this (error LED illuminated on WD bite) to most top level files eventually
[01:28:35] <PCW> Next step is stored procedures so a broadcast read request can read all devices process data ( and sync DPLLs ~simultaneously )
[01:29:07] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[01:29:25] <jepler> it sounds cool, not sure we'll achieve support for it in linuxcnc soon
[01:29:34] <jepler> maybe you have other software and customers that will benefit though
[01:30:05] <PCW> Yeah this is long term
[01:31:56] <PCW> there are still some oddments with eth-packet-loss that should be addressed (or at least documented) before its merged
[01:33:44] <jepler> the main thing still on my mind is testing and then documenting what happens with encoders and index latch
[01:36:15] <PCW> Yeah dealing with possible write failures is interesting...
[01:36:17] <PCW> The issues I see are sserial problems and strange packet timeout behavior on one system
[01:39:01] <jepler> my plan is to make a virtual encoder in an avr
[01:39:37] <jepler> it'll at least do quadrature A/B/Z and maybe emulate a homing switch too, probably take a velocity command over non-realtime usb
[01:42:11] <PCW> practically speaking I would expect packet errors to be very rare
[01:42:54] <PCW> but certainly should not case a fatal error as they do before eth-packet-loss
[01:49:41] -!- skunksleep has quit [Ping timeout: 240 seconds]
[01:51:42] <jepler> oh ugh there's a different error case than the one I was fixated on, wrt index
[01:52:33] <jepler> if the read that first sees index-latch cleared is the one that goes missing, linuxcnc risks setting index-latch in the following force-write and not registering that index was seen
[01:53:15] <seb_kuzminsky> http://imgur.com/B59CvVb
[01:53:58] <jepler> seb_kuzminsky: pretty much
[01:55:36] <seb_kuzminsky> i'm looking more closely at how the interp_list evolves during startup and during abort, and it's making my skin crawl
[01:56:07] <seb_kuzminsky> we enqueue all this useful-seeming initialization, then discard it beacuse of a handful of surplus aborts durning startup...
[01:56:38] <jepler> so besides us advising that it's a bad idea and put all modal settings at the top of your part program, ...
[01:56:52] <jepler> ... the interpreter startup code also just doesn't work as documented when the NML starts flying?
[01:57:09] <seb_kuzminsky> i'm not sure yet
[02:14:33] <PCW> if you only set the latch on index if it reads clear and keep writing it true until it reads true does that help?
[02:14:35] <PCW> There's a race condition where you could lose the index detect (but that race condition has always been there)
[02:19:29] <PCW> on homing is seems like you avoid the race condition by the time between the home switch (arming latch on index)
[02:19:31] <PCW> and the actual index occurrence
[02:23:27] <PCW> on things like rigid tapping where the arming is asynchronous is seems like you could miss the index but that just means you wait for the next one
[02:25:08] <PCW> or maybe I'm not thinking this through because its dinner time
[02:25:15] <PCW> bbl dinner
[02:26:40] -!- skorasaurus has quit [Ping timeout: 260 seconds]
[02:38:58] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:03:03] -!- skunksleep has quit [Ping timeout: 250 seconds]
[03:04:04] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:13:33] -!- skunksleep has quit [Ping timeout: 276 seconds]
[03:14:10] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:28:23] -!- skunksleep has quit [Ping timeout: 244 seconds]
[03:29:13] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:29:43] <seb_kuzminsky> yes, i'm convinced now that our startup is just totally racy and broken
[03:30:34] <seb_kuzminsky> take a look at Task's main()
[03:30:49] <seb_kuzminsky> run-from-line, if you will, starting here:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctaskmain.cc#L3281
[03:31:33] <seb_kuzminsky> emctask_startup() instanciates Interp, which runs Interp::init():
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/rs274ngc_pre.cc#L802
[03:32:36] <seb_kuzminsky> as you can see, Interp::init() calls INIT_CANON() and SET_G5X_OFFSET() and SET_G92_OFFSET(), which all enqueue NML commands on interp_list.
[03:33:06] <seb_kuzminsky> it also optionally runs [RS274NGC]STARTUP_CODE from the ini file, which will enqueue even more stuff on interp_list
[03:33:23] <seb_kuzminsky> (we're getting close to the root cause of #49 now)
[03:34:53] <seb_kuzminsky> after emctask_startup() returns to Task's main(), which right away enters Estop by calling this:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctask.cc#L291
[03:35:46] <seb_kuzminsky> entering estop causes an Abort, which clears the interp_list:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctask.cc#L176
[03:36:03] <seb_kuzminsky> it's enough to drive a man to drink
[03:38:56] <mozmck> issue #49 is not very clear to me. the image micges posted is gone
[03:39:37] <mozmck> It sure does sound like things are a bit haywire in there though!
[04:13:55] -!- ve7it has quit [Remote host closed the connection]
[06:07:02] -!- beawesomeinstead has quit [Read error: Connection reset by peer]
[06:20:29] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:20:41] -!- rob_h [rob_h!~R@2a02:c7f:5618:7700:455f:48cb:c14a:7ed6] has joined #linuxcnc-devel
[06:21:06] -!- teepee has quit [Ping timeout: 244 seconds]
[06:21:06] teepee_ is now known as teepee
[07:06:24] -!- ivansanchez has quit [Remote host closed the connection]
[07:44:01] -!- Miner_48er has quit [Quit: Leaving]
[08:08:00] -!- skunksleep has quit [Ping timeout: 276 seconds]
[08:33:27] -!- Einherjer [Einherjer!~einherjer@69.64.40.177] has joined #linuxcnc-devel
[08:36:36] -!- Mathnerd314 has quit [Ping timeout: 276 seconds]
[09:12:10] -!- rob_h has quit [Ping timeout: 258 seconds]
[09:19:11] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:24:48] -!- b_b has quit [Changing host]
[09:38:06] -!- kalxas has quit [Quit: Goodbye]
[09:43:04] -!- skunksleep has quit [Ping timeout: 264 seconds]
[09:53:56] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[10:03:23] -!- Daerist has quit [Quit: Leaving]
[10:07:53] -!- txp has quit [Read error: Connection reset by peer]
[10:25:01] -!- skunksleep has quit [Ping timeout: 240 seconds]
[10:25:48] -!- skunkworks__ has quit [Ping timeout: 276 seconds]
[10:26:10] -!- kalxas has quit [Changing host]
[10:45:18] -!- wtsmer has quit [Ping timeout: 276 seconds]
[11:30:05] -!- kalxas has quit [Quit: Goodbye]
[11:36:17] -!- rob_h [rob_h!~R@2a02:c7f:5618:7700:9455:f659:60b4:fe33] has joined #linuxcnc-devel
[11:56:42] -!- rob_h has quit [Ping timeout: 272 seconds]
[12:12:25] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:45:37] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[12:49:05] -!- emc has quit [Quit: Leaving]
[12:52:55] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:00:52] <skunkworks> zlog
[13:00:53] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-06-07.html
[13:08:00] <jepler> seb_kuzminsky: sigh but thanks for that detection work
[13:16:28] amnesic is now known as amnesic_away
[13:24:40] <pcw_home> jepler: what about this modest proposal for index:
[13:24:41] <pcw_home> change the hardware so that when latch on index is enabled,
[13:24:43] <pcw_home> a readable bit toggles every time index is detected (and count latched)
[13:25:32] <jepler> I think that would work better but I'd want to think about it further before committing to something like that
[13:26:21] <pcw_home> it has the side benefit that you get encoder sanity checking as a bonus
[13:27:17] <jepler> if you have latch and toggle, I wonder if you need the enable anymore
[13:27:41] <pcw_home> nope its permanently enabled at startup
[13:29:09] <jepler> hm but you have latch register for both index and probe (and linuxcnc doesn't use the latter for its probe gcodes)
[13:29:39] <pcw_home> This can be tested with current firmware (just check the latch register for changes to detect index)
[13:29:41] <pcw_home> that has the minor problem that 65536 counts/rev encoders would fail
[13:30:02] <jepler> tempting to say linuxcnc can just look which (one) bit toggled, but you could have a probe touch and an index all in the same ms
[13:30:16] <jepler> pcw_home: or if you go just past index and then reverse, regardless of counts/rev
[13:30:49] <pcw_home> yeah you can do both but you lose the sanity checking when probing
[13:31:30] <pcw_home> Right, a toggle is better
[13:32:17] <pcw_home> (you are not going to be homing and probing at the same time)
[13:32:41] <jepler> no
[13:32:52] <mozmck> I use the Z home switch for probing...
[13:33:01] <jepler> but if each index pulse is latching all the time (no enable bit) you have the potential for confusion
[13:33:59] <pcw_home> you still have the index-enable but its just in the driver
[13:34:01] <jepler> seems like you could sacrifice CCR bits 0..2 to define some new modes
[13:37:51] -!- b_b has quit [Remote host closed the connection]
[13:38:59] <jepler> you'd have to worry much much more about bounce in the probe/index signal
[13:39:33] <jepler> if two rising probe edges are seen in one servo cycle, does the hypothetical new status bit toggle twice?
[13:39:46] <jepler> afk for some coffee
[13:39:57] <pcw_home> yes
[13:41:16] <pcw_home> if there were more readable bits, a index count would be good
[13:50:13] <pcw_home> maybe a mode bit that changes the register readback bits that are just used at
[13:50:14] <pcw_home> setup to a set of bits more useful when running
[13:55:46] -!- tobias47n9e__ has quit [Ping timeout: 272 seconds]
[13:56:24] -!- ktchk [ktchk!~eddie6929@n219079180191.netvigator.com] has joined #linuxcnc-devel
[13:57:34] <skunkworks> Z ball screw out of the matsuura
[13:58:32] <skunkworks> Looks like it has the same slack over the whole distance. We can add about .002 shim between the nuts
[13:59:18] <mozmck> just heat it up a little ;-)
[14:00:41] <pcw_home> that's good, better worn ball nut/balls than ballscrew
[14:01:33] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[14:13:03] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[14:19:25] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:24:00] -!- ve7it has quit [Remote host closed the connection]
[14:24:53] <cradek> skunkworks__: balls not worn or crunched up? was the oiler working?
[14:25:27] -!- ktchk has quit [Ping timeout: 260 seconds]
[14:28:18] <skunkworks> oiler seems to have been working. It looks and feels nice
[14:28:31] <skunkworks> it doesn't feel crunchy
[14:28:46] <skunkworks> cradek, didn't you re-ball something?
[14:29:33] <cradek> seems like I've done several, but the only one I specifically remember is the hnc's Z
[14:30:11] <cradek> I still have a bunch of baby food jars with balls marked .1853 .1855 .1857 or somesuch
[14:30:22] <skunkworks> heh
[14:31:25] <cradek> the balls in it were matte instead of shiny, and at least a few were crunched. it was pretty bad.
[14:32:10] <cradek> iirc it has two races but no shim adjustment between them
[14:42:59] -!- johtso has quit [Ping timeout: 258 seconds]
[14:47:15] -!- ktchk [ktchk!~eddie6929@n219079227192.netvigator.com] has joined #linuxcnc-devel
[14:53:36] <cradek> "These are available very cheaply, so I made one."
[14:53:42] <cradek> I enjoy andy's blog a lot
[14:55:47] <skunkworks> iirc it has two races but no shim adjustment between them
[14:55:50] <skunkworks> heh
[14:55:56] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7655.JPG
[14:56:07] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7656.JPG
[14:56:14] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7657.JPG
[14:56:22] <skunkworks> http://electronicsam.com/images/matsuura/DSC_7658.JPG
[14:56:50] <cradek> seeing that reminds me that I reballed Y on Jr too
[14:56:55] amnesic_away is now known as amnesic
[14:57:18] <cradek> it looks just like that
[14:58:54] <cradek> wait did you find it with the anti-rotation bit unscrewed like that?
[14:59:20] <skunkworks> no
[14:59:35] <skunkworks> dad was adding shims between the nuts to see what it felt like
[14:59:37] <cradek> heh, because that would have explained the problem...
[15:00:26] <skunkworks> he could certainly pop one of the tubes out and take a look at the balls.
[15:01:09] <cradek> I think I only replaced the big ones, left the small ones alone
[15:02:20] <skunkworks> 2 different sizes? alternated?
[15:02:33] <cradek> yeah
[15:02:40] <skunkworks> neat
[15:02:48] <cradek> I think I've seen that in all screws I've had apart
[15:03:06] <skunkworks> can't say I have had one apart yet..
[15:03:40] <skunkworks> the x and y both have a little backlash - less than .001 I think.
[15:03:48] <skunkworks> y being the best
[15:04:00] <cradek> doing that nut I learned that with gage blocks I can tell .2499 from .2500 from .2501
[15:04:36] <skunkworks> by using a .2499 as a spacer?
[15:04:45] <archivist> you need a better bench mic :)
[15:05:12] <cradek> right, make up a .2499 stack between two other blocks and the .2500 ball won't go in without popping it all apart
[15:05:25] <cradek> for the .2500 stack the ball goes in and sticks, for the .2501 stack it falls right through
[15:06:11] <cradek> it was really neat to see
[15:06:24] <archivist> I dont trust my 1" gauge blocks because they all measure different
[15:06:49] <cradek> heh I guess you should never have more than one of them
[15:07:27] <archivist> I could do with at least one calibrating
[15:08:24] <skunkworks> 'all my gauge blocks are perfect - but they are not 1-2-3, they are .998,1.998,2.998.'
[15:08:31] <skunkworks> ;)
[15:11:12] <archivist> I was not at a proper temperature when I was playing the other day
http://www.archivist.info/cnc/bench_micrometer/
[15:11:23] <archivist> results at the bottom
[15:33:55] <cradek> huh, didn't know glass was used for that
[15:34:30] <cradek> I suppose it polishes nicely and doesn't rust. is the expansion coefficient good?
[15:35:58] <jepler> I suppose you guys all saw the video where the task is measuring the thickness of a sharpie mark
https://www.youtube.com/watch?v=46DBNUfhATo (the video's too long at 11 minutes, but it's neat what you can measure with appropriate tools)
[15:36:10] <cradek> yes!
[15:45:27] <archivist> cradek, I dont know if it is some special glass
[15:49:49] <cradek> I know that the coefficient can definitely be controlled (they figured it out long ago for the making of fused bifocals) but I don't know if it's big or small compared to metals
[15:52:15] <jepler> https://en.wikipedia.org/wiki/Thermal_expansion#Thermal_expansion_coefficients_for_various_materials
[15:53:09] <jepler> quartz is 10x better than borosilicate glass, invar is between those two. stainless is 3-5x borosilicate.
[15:53:21] <cradek> and don't use frozen mercury
[15:56:57] <archivist> hehe
[15:57:02] <seb_kuzminsky> jepler: seriously, 11 minutes? who's got that kind of attention span?
[15:57:08] <archivist> me
[15:58:06] <cradek> heh now I'm wondering if you could make a material with an unusually large CE to make rings that fit in both summer and winter
[15:58:16] <archivist> easier to watch him do it than replicate :)
[16:01:16] <archivist> besides my comparators dont have completely flat anvils like his, I think mine are designed not to wring the same
[16:11:07] <archivist> just found a catalogue covering that glass block, it is fused quartz
[16:21:13] -!- ktchk [ktchk!~eddie6929@n219079227192.netvigator.com] has parted #linuxcnc-devel
[16:21:16] <skunkworks> cradek, how did you decide you had the right size balls?
[16:21:31] <skunkworks> *rim shot*
[16:22:54] <cradek> skunkworks: I loaded up different sizes and measured the backlash. I was not successful at predicting the right size. a small change in size leads to a surprisingly large change in backlash.
[16:24:18] <skunkworks> how did you measure backlash? was it still in the machine?
[16:24:29] <cradek> yes I was able to do them both in place
[16:24:38] <skunkworks> ah
[16:26:05] <cradek> with a dual-nutter I bet you could screw them together (with a torque wrench?) and measure the offset of the anti-rotation bit's slot
[16:26:24] <cradek> I bet with a few ball sizes that would give you a very good plot of the relationship
[16:26:38] <cradek> (it's not linear of course)
[16:28:06] <cradek> so seems like you could determine exactly what ball size gives unpreloaded zero backlash
[16:28:14] <cradek> but then I don't know how you know what preload to add
[16:28:24] <cradek> "a bit"
[16:32:11] <skunkworks> Hmm - that might work. calculate how many lbs of preload you want - translate that to rotational torque. measure the total nut rotation at that ft-lbs - calculate shim thickness
[16:32:51] <cradek> that does sound pretty direct
[16:33:32] <skunkworks> then the question is how many lbs of preload. the internet says 7 to 10% of total ballscrew load. which I don't know either
[16:33:55] <skunkworks> a few hundred pounds seems like a good guess ;)
[16:37:56] <archivist> but... being the Z screw, doesnt gravity fix it for you
[16:38:18] <cradek> it's counterweighted
[17:06:54] <skunkworks> heh - 2.54 threads per inch... duh
[17:07:07] <skunkworks> I had to do the math for that..
[17:12:01] <seb_kuzminsky> http://static1.squarespace.com/static/528bbffae4b0b66670e447b3/t/56456c6fe4b0557e6c24a8eb/1447390320112/
[17:12:06] <seb_kuzminsky> you can do it skunkworks !
[17:20:49] amnesic is now known as amnesic_away
[17:23:31] <skunkworks> hmm - if I did that right - I get 12 in-lb of torque to get 200 lbs of preload.
[17:24:18] <skunkworks> that seems low
[17:25:57] <skunkworks> (that is 100% efficency - worse case)
[17:34:55] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[17:42:57] -!- ivansanchez has quit []
[17:50:20] -!- kalxas has quit [Quit: Goodbye]
[18:03:43] <cradek> skunkworks: you need to wedge a bathroom scale between the nuts to sanity-check your numbers
[18:04:46] <cradek> I agree 1 ft lb seems too low. with 1lb at a foot, it seems like you could have your finger in there and not even squish it too uncomfortably
[18:05:00] <cradek> not at all like a 200lb person standing on it
[18:08:22] -!- skunkworks__ has quit [Ping timeout: 250 seconds]
[18:09:34] <cradek> skunkworks:
http://i1.kym-cdn.com/photos/images/newsfeed/000/234/765/b7e.jpg
[18:57:17] -!- md-2 has quit [Quit: Leaving...]
[19:10:48] <jepler> hm google fails if you search for: that dog with that tie picture
[19:10:54] <jepler> it has dogs with ties but not *that* dog
[19:29:36] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[19:33:46] <cradek> wow, he didn't have the direction signal hooked up to his step/dir rotary axis
[19:33:58] <cradek> I don't understand how that caused the reported problem, but whatever
[19:34:44] <PCW> I dont think I would have guessed that
[19:35:02] -!- kalxas has quit [Read error: No route to host]
[19:35:04] <cradek> that's an understatement
[19:35:31] <PCW> slightly bothersome the Tormach has their thread order bolluxed up
[19:35:41] <cradek> do you think it crept because there was dithering or something?
[19:35:47] <cradek> yeah, that's not good
[19:37:28] <PCW> i think it crept because .005 degrees/max_error/125 degrees/sec is much smaller than the timebase difference between the servo thread and PCI clock
[19:38:05] <PCW> .0005 degrees-max_error I mean
[19:40:21] <PCW> Thats only a +- 4 PPM frequency adjust range
[19:42:49] <PCW> .0005 _inches_ on a 2 IPS machine is fine, thats a +-250 PPM range
[20:05:54] -!- skunkworks__ [skunkworks__!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:10:05] <skunkworks__> .001 seems to loose .0015 seems too tight
[20:11:48] <PCW> that seems a bit backwards
[20:27:35] <skunkworks__> ?
[20:36:20] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[20:46:11] <PCW> oh the spacer, not the backlash
[20:54:46] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[21:04:25] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[21:06:06] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[21:06:30] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[21:08:00] -!- skunkworks has quit [Ping timeout: 276 seconds]
[21:09:06] <skunkworks__> yes - the spacer
[21:10:59] -!- kalxas has quit [Changing host]
[21:17:41] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[21:19:06] -!- teepee has quit [Ping timeout: 272 seconds]
[21:19:06] teepee_ is now known as teepee
[21:40:00] <skunkworks__> dad is going to try .001
[22:15:19] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:18:06] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:21:28] -!- skorasaurus has quit [Ping timeout: 252 seconds]
[22:46:19] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[22:47:25] -!- teepee has quit [Ping timeout: 244 seconds]
[22:47:26] teepee_ is now known as teepee
[22:52:33] -!- GJdan has quit [Ping timeout: 250 seconds]
[22:56:20] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[23:01:07] -!- andypugh has quit [Quit: andypugh]
[23:55:15] <seb_kuzminsky> what happens when you try to fix a bug in Task:
http://i.imgur.com/JwKnRJ6.gif
[23:55:36] <cradek> haha
