Back
[00:03:06] -!- nofxx has quit [Ping timeout: 250 seconds]
[00:03:46] -!- nofxx has quit [Changing host]
[00:09:58] -!- md-2 has quit [Remote host closed the connection]
[00:11:40] -!- patrickarlt has quit [Ping timeout: 246 seconds]
[00:23:57] -!- rob_h has quit [Ping timeout: 255 seconds]
[00:26:35] -!- arrowbook [arrowbook!~qicruser@223.104.2.250] has joined #linuxcnc-devel
[00:41:03] -!- andypugh has quit [Quit: andypugh]
[00:54:19] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[01:04:12] -!- asdfasd has quit [Ping timeout: 250 seconds]
[01:04:36] -!- HSD has quit [Ping timeout: 264 seconds]
[01:12:17] -!- JT-MOBILE has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
[01:20:48] amnesic is now known as amnesic_away
[01:21:41] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[01:21:45] amnesic_away is now known as amnesic
[01:28:53] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[01:31:50] amnesic is now known as amnesic_away
[01:32:01] <skunkworks> mozmck:
[01:32:06] <skunkworks> I think what's happening is that NCD is combining segments together if there is no M67, but it can't do that if there is. If you make Q 0.0, the effect disappears (in that you see the blip regardless).
[01:32:07] <skunkworks> It's the age-old problem of telling the motion side that the program is done, or that we've hit a queue buster and to assume that the last segment will be exact stop. Since there isn't a clean way to do this now, the workaround is to have a lead-out move of some sort (for example, a rapid down to the work and back up after the cut). If the last segment is not cutting, then the little blip...
[01:32:09] <skunkworks> ...won't affect the part.
[01:35:59] <jepler> of course you can also determine whether it's dark or not with this watch
http://www.bloomberg.com/news/articles/2015-09-17/vacheron-constantin-unveils-the-most-complicated-watch-ever-made
[01:58:26] <cradek> not nearly as easily
[01:58:59] <mozmck> skunkworks: I'm not sure...
[02:04:32] <mozmck> If M67 is supposed to be a non-queue buster, then it should be a non-queue buster at any point. Didn't you say it did not have the blip in 2.6? Wasn't NCD in 2.6 as well?
[02:06:09] <mozmck> I don't think I can do a rapid up after a cut - but I'll have to look at it a bit more.
[02:17:33] -!- theorbtwo has quit [Ping timeout: 250 seconds]
[02:18:46] -!- zeeshan-mobile has quit [Remote host closed the connection]
[02:32:50] -!- patrickarlt has quit [Quit: Leaving...]
[02:45:07] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[02:56:32] -!- Roguish has quit [Quit: ChatZilla 0.9.92 [Firefox 40.0.3/20150826023504]]
[02:57:01] -!- arekm has quit [Changing host]
[03:08:22] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[03:12:50] -!- AR_ has quit [Ping timeout: 240 seconds]
[03:18:07] <skunksleep> mozmck: I don't think it is the m67. It is not knowing that it is the last segment
[03:18:33] <mozmck> not sure what you mean?
[03:18:46] <mozmck> I can take the M67 out and there is no dip in velocity
[03:19:30] <mozmck> I also changed some of the codes to M62/M63 and it does the same thing.
[03:21:14] <mozmck> I just tried adding another move of .001" after the last move after the last Mxx code, and the velocity dip vanishes. If I make that last move longer - like .5" then the dip is still there.
[03:22:26] -!- skunksleep has quit [Ping timeout: 250 seconds]
[03:22:45] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:23:31] <skunksleep> I looked into that before, and I'm not sure there's a good answer. We effectively need a way to tell motion to do an exact stop at the end of the queue. One way might be a special motion command that says that we're done sending moves for now (i.e. queue buster or end-of-program). Then, we could override the stop condition of the last move (make it exact stop), and re-run the optimization to remove the blip. Th
[03:23:46] -!- shurshur has quit [Ping timeout: 240 seconds]
[03:24:47] <mozmck> This is with NCD turned off now - hmm, interesting - if I turn NCD back on ( Q0.001 ), the dip is back even with the extra .001 move
[03:25:47] <mozmck> I don't understand why motion would not know to do an exact stop at the end of the queue?
[03:26:46] <mozmck> And why would inserting a non queue-buster command make any difference if that is the problem?
[03:27:57] <skunksleep> I don't think I understand it either. Are you doing a g0 .001 move?
[03:28:12] <mozmck> No, it was still a g1
[03:28:38] <skunksleep> I think you want a g0 move
[03:28:58] <mozmck> The thing is, I have an M5 already which is a queue buster.
[03:29:34] <skunksleep> (But it is late and things are fuzzy)
[03:30:05] <mozmck> ja, richtig
[03:34:58] -!- md-2 has quit [Ping timeout: 240 seconds]
[03:35:21] -!- nofxx has quit [Ping timeout: 265 seconds]
[03:36:03] <skunksleep> The dip is back with the extra move because the ncd combines it into one segment again
[03:36:05] -!- nofxx has quit [Changing host]
[03:37:00] <mozmck> Ok, so why does the dip happen at all? If I remove the M code the dip goes away, or if it is far enough away from the end of the line.
[03:37:11] <skunksleep> So I think ether add the extra g1 move with no ncd or use a g0 with
[03:39:04] <skunksleep> I don't know?
[03:39:54] <mozmck> The G0 with a .001 move makes the dip much smaller and down at the end of decel
[03:45:29] <mozmck> It does not work to put the G0 move after the M5 either.
[03:46:42] <skunksleep> What is m5 used for?
[03:46:50] <mozmck> I can just see telling our customers - "If you don't want it to burp before the end of each cut, just put a bogus G0 move of .001" before the M5!"
[03:46:59] <mozmck> turning the torch off
[03:47:48] <skunksleep> Isn't there going to be rapids between each cut?
[03:47:58] <mozmck> Only after the torch is off!
[03:48:26] <mozmck> But putting a rapid after turning the torch off does not help
[03:51:03] <skunksleep> You don't have issues with m3/5? I thought that was iocontrol and not realtime
[03:51:38] <skunksleep> Maybe I am wrong
[03:52:58] <mozmck> When you turn the torch on motion.motion-inhibit is asserted until the torch actually fires, and on torch off it happens after the last segment of a cut.
[03:53:27] <mozmck> So it doesn't need to be realtime
[03:54:21] -!- sumpfralle has quit [Quit: Leaving.]
[03:54:43] <skunksleep> Ah . would using digital I/o help? Instead of spindle on/off?
[03:55:06] <mozmck> They are queue busters, so motion waits for those commands to execute before starting motion again.
[03:55:09] <skunksleep> Synced I/o
[03:55:35] <mozmck> I don't see why it would - they don't need to be synced - in fact that would probably be bad.
[03:56:34] <mozmck> For torch on, we hold motion until we have a valid arc, then we move from pierce height down ~ .060" to cut height to pierce through the metal and then start X/Y motion
[03:57:46] <mozmck> For thicker metal there may also be a pierce delay.
[04:01:45] <skunksleep> Remap m6 to add a g0 move?...
[04:01:57] <skunksleep> Before
[04:02:14] <skunksleep> sorry. Grasping
[04:03:33] <skunksleep> M5 I mean
[04:05:05] <mozmck> heh! don't know about that! I better quit for tonight - thanks for thinking about it with me.
[04:07:50] <skunksleep> No problem
[04:13:00] -!- zeeshan has quit [Ping timeout: 255 seconds]
[04:22:07] -!- ve7it has quit [Remote host closed the connection]
[04:24:53] -!- furrywolf has quit [Ping timeout: 246 seconds]
[04:54:12] -!- bkboggy has quit [Quit: Leaving]
[05:06:06] -!- micges_ has quit [Ping timeout: 240 seconds]
[05:06:33] -!- micges_ [micges_!~micges@abpj235.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[05:23:09] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[05:31:46] -!- tchaddad has quit []
[05:36:46] -!- md-2 has quit [Ping timeout: 240 seconds]
[05:45:19] -!- linuxcnc-build has quit [Ping timeout: 244 seconds]
[05:45:48] -!- arrowbook has quit [Read error: Connection reset by peer]
[05:45:50] -!- hm2-buildmaster_ has quit [Ping timeout: 260 seconds]
[05:46:36] -!- seb_kuzminsky has quit [Ping timeout: 272 seconds]
[05:46:53] -!- seb_kuzminsky [seb_kuzminsky!~seb@75-166-183-14.hlrn.qwest.net] has joined #linuxcnc-devel
[05:55:31] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@75-166-183-14.hlrn.qwest.net] has joined #linuxcnc-devel
[06:07:10] -!- skunksleep has quit [Ping timeout: 240 seconds]
[06:08:17] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-183-14.hlrn.qwest.net] has joined #linuxcnc-devel
[06:16:27] -!- arrowbook [arrowbook!~qicruser@223.104.2.250] has joined #linuxcnc-devel
[06:19:54] -!- arrowbook has quit [Read error: Connection reset by peer]
[06:24:23] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[07:30:45] -!- Daerist has quit [Ping timeout: 246 seconds]
[08:00:33] -!- b_b has quit [Changing host]
[08:15:48] -!- anth0ny_ has quit [Quit: anth0ny_]
[08:16:41] -!- arrowbook [arrowbook!~qicruser@223.104.2.250] has joined #linuxcnc-devel
[08:16:58] -!- rob_h [rob_h!~robh@90.220.156.125] has joined #linuxcnc-devel
[08:23:31] -!- arrowbook has quit [Read error: Connection reset by peer]
[08:29:30] -!- anth0ny_ has quit [Client Quit]
[08:55:19] -!- Daerist has quit [Quit: Page closed]
[09:15:17] -!- nofxx has quit [Ping timeout: 250 seconds]
[09:39:42] -!- moorbo has quit [Ping timeout: 255 seconds]
[09:44:32] Deejay is now known as DJ9DJ
[09:44:50] DJ9DJ is now known as Deejay
[09:48:48] micges_ is now known as micges
[09:51:16] -!- maurris has quit [Ping timeout: 246 seconds]
[09:54:22] hendrik is now known as nhnb
[09:54:47] nhnb is now known as nhb
[09:55:02] nhb is now known as nhnb_
[09:55:11] nhnb_ is now known as hendrik_
[09:55:20] hendrik_ is now known as hendrik__
[09:55:27] hendrik__ is now known as hendrik
[10:15:30] -!- skunksleep has quit [Ping timeout: 240 seconds]
[10:27:09] -!- persina has quit [Ping timeout: 246 seconds]
[10:47:46] -!- skunkworks has quit [Ping timeout: 240 seconds]
[10:59:26] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[11:19:57] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:23:53] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[11:32:42] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:36:45] -!- linuxcnc-build has quit [Ping timeout: 256 seconds]
[11:39:12] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[11:39:29] -!- SEL [SEL!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[11:44:07] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-183-14.hlrn.qwest.net] has joined #linuxcnc-devel
[11:45:53] -!- dan2k3k4 has quit [Ping timeout: 246 seconds]
[12:00:21] <skunkworks> and it looks like you cannot remap M5? how much work is that I wonder.
[12:03:10] -!- skunkworks_ has quit [Ping timeout: 240 seconds]
[12:10:03] -!- lair82 has quit [Ping timeout: 246 seconds]
[12:12:47] -!- dan2k3k4k5 has quit [Quit: Leaving]
[12:18:51] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[12:20:24] <skunkworks> I see it disapear if you add a small g0 move before the m5. the move could be really small .0001
[12:22:47] <skunkworks> I could see (maybe - I have not used remap..) check mm/metric (or maybe you wouldn't have to as the move either way could be really small) check rel/abs - switch to rel - move small amount - m5 - switch back to previous rel/abs
[12:32:58] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:33:07] <skunkworks_> http://imgur.com/30rgU3T
[12:34:20] <skunkworks> interesting observation.. why does program line dip to zero in the middle?
[12:35:57] <skunkworks> Hmm - skips over non moves?
[12:36:03] <skunkworks> maybe I never noticed that
[12:36:53] <micges> skip over non moves
[12:37:19] <skunkworks> must have never noticed that :)
[12:38:30] <micges> it's not visible in axis gui, but if you create progress bar it's visible
[12:44:12] <skunkworks_> this is the minimum x.0000001
[12:44:26] <skunkworks_> any less than that and it must get filtered out
[12:44:30] <skunkworks_> Inch
[12:45:04] <micges> skunkworks_: what problem with m5 does mozmck have?
[12:46:54] <skunkworks_> if you don't add an extra g0 move at the end of the segments before the m5 - you get a dip in velocity
[12:47:53] <micges> new tp?
[12:50:17] <skunkworks_> http://pasteboard.co/zzTUBUc.png
[12:50:22] <skunkworks_> compared to mine above.
[12:51:10] <skunkworks_> yes - if you read back - rob had emailed me with an explaination. something to do with no knowing if a segment is the last segment or such. I don't understand it very well
[12:52:11] <micges> can you try adding g4 p0.01 between g1 and m5?
[12:53:51] <skunkworks> nope
[12:54:16] <skunkworks> (I mean - it didn't help_ M5 should have the same effect as G4 in that situation
[12:54:53] <micges> I see
[12:55:44] <skunkworks> I think what is happening is the tp is falling back to parabolic blending for the last segment because it doesn't know what is coming next.
[12:56:00] <skunkworks> My thought anyway
[13:01:03] -!- moorbo has quit [Ping timeout: 250 seconds]
[13:11:42] -!- arrowbook [arrowbook!~qicruser@60.210.192.91] has joined #linuxcnc-devel
[13:16:22] -!- skunkworks_ has quit [Ping timeout: 244 seconds]
[13:27:50] -!- md-2 has quit [Quit: Leaving...]
[13:33:43] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:46:02] -!- os1r1s has quit [Ping timeout: 260 seconds]
[13:48:11] <mozmck> skunkworks: so Rob actually emailed you back with that?
[13:49:27] <mozmck> micges: here is my bug report:
https://sourceforge.net/p/emc/bugs/437/
[13:49:41] <micges> thanks
[13:50:31] <skunkworks> yes
[13:50:45] <mozmck> I verified last night that M62/M63 have the same behavior
[13:51:24] <skunkworks> It isn't the M62/M63 it has to do with the last segment. as I understand it.
[13:52:40] <mozmck> Well, it is a combination, because there is no glitch if there is no M62/63/67 before the last segment
[13:52:42] <skunkworks_> mozmck: maybe a work around?
[13:52:44] <skunkworks_> http://pastie.org/10429136
[13:53:15] <skunkworks> I didn't actually try re-mapping M5 but according to the documents it isn't possible
[13:53:24] <skunkworks> (I am using m55)
[13:53:51] <mozmck> skunkworks: I thought of that - and I guess a nasty hack like that might work if we get really desperate.
[13:54:31] <mozmck> The interesting thing is that a larger move does not help the problem
[13:55:28] <micges> mozmck: what does M67 E0 Q20 do?
[13:57:15] <mozmck> It sets an analog hal pin which a custom HAL component reads and uses to control variables in our THC
[13:58:21] <skunkworks> mozmck> Well, it is a combination, because there is no glitch if there is no M62/63/67 before the last segment
[13:59:03] -!- Valen has quit [Remote host closed the connection]
[13:59:05] <skunkworks> that is because adding M62/3/7 trumps the ncd. (it can't combine the segments)
[13:59:49] <skunkworks> IF you removed the M62/3/7 and set Q0 in g64 - you would see the same thing
[14:01:46] <skunkworks> (just trying to explain it for myself also)
[14:04:10] <mozmck> Whatever the reason, it sounds like a bug to me. It will also affect people using M62/M63 for laser control.
[14:04:32] <pcw_home> wonder if its a terrible idea to apply things like M67 as tags in commanded position stream
[14:05:08] -!- zeeshan [zeeshan!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[14:06:08] <mozmck> pcw_home: you mean internally?
[14:07:15] <pcw_home> a bad idea but you could do something like this in HAL
[14:08:59] <pcw_home> but I guess the current issue is that m67 is a queue buster but should not really have any side effects
[14:10:55] <pcw_home> is this just a bug with M67 and NCD?
[14:15:22] <skunkworks> this is what rob replied
[14:15:23] <skunkworks> I think what's happening is that NCD is combining segments together if there is no M67, but it can't do that if there is. If you make Q 0.0, the effect disappears (in that you see the blip regardless).
[14:15:23] <skunkworks> It's the age-old problem of telling the motion side that the program is done, or that we've hit a queue buster and to assume that the last segment will be exact stop. Since there isn't a clean way to do this now, the workaround is to have a lead-out move of some sort (for example, a rapid down to the work and back up after the cut). If the last segment is not cutting, then the little blip won't affect the part.
[14:16:21] <skunkworks> I asked him about what to do in the future and he posted
[14:16:24] <skunkworks> I looked into that before, and I'm not sure there's a good answer. We effectively need a way to tell motion to do an exact stop at the end of the queue. One way might be a special motion command that says that we're done sending moves for now (i.e. queue buster or end-of-program). Then, we could override the stop condition of the last move (make it exact stop), and re-run the optimization to remove the blip. The PIT
[14:16:25] <skunkworks> A part is making sure that all the queue buster commands actually trigger this command, and implementing all the NML plumbing to pass it along.
[14:18:49] <pcw_home> thats sort of what i was getting at, the M67 could be made to work
[14:18:51] <pcw_home> even with NCD if the M67 was deferred to the interpolator
[14:20:21] <pcw_home> maybe m88 X 3.45
[14:22:28] -!- b_b has quit [Remote host closed the connection]
[14:23:49] <skunkworks> I see - your telling it where you want it to trigger
[14:35:42] <mozmck> what is M88?
[14:39:32] <skunkworks> I think he is just giving an example of a new M code. (where you tell it where you want the dio to switch)
[14:39:41] <skunkworks> or aio
[14:43:40] <mozmck> That's what M62/63/67 are supposed to do
[14:44:33] <skunkworks> mozmck, what effect does that dip have on the part?
[14:45:32] <mozmck> If it's bad enough, it creates a divot
[14:48:06] <mozmck> We can do without the M67 much of the time it looks like for now as a workaround. If there is a way to do it with another M code that would work too.
[14:49:03] <skunkworks> mozmck, sorry I never notice that in testing..
[14:49:56] <mozmck> heh, not your fault - thanks for helping!
[14:57:20] -!- furrywolf has quit [Ping timeout: 246 seconds]
[15:10:08] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[15:18:04] -!- anth0ny_ has quit [Quit: anth0ny_]
[15:34:16] -!- b_b has quit [Changing host]
[15:44:20] firephoto is now known as firephoto_
[15:46:26] firephoto_ is now known as _firephoto
[15:50:19] _firephoto is now known as firephoto
[15:54:44] -!- tocka has quit [Ping timeout: 246 seconds]
[16:01:01] -!- SEL has quit [Quit: Leaving]
[16:16:24] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[16:26:47] <kwallace> An example of 1914 technology:
http://ninanet.net/watches/others13/Mediums/mpatekpw.html
[16:31:44] <malcom2073> Every once in a while I hear someone say "I wish I could travel back in time, I'd be so smart compared to them!". People have been freaking amazing forever, just the venue has changed
[16:33:04] <cradek> the tips of the escape wheel teeth and the wolfs-tooth winding wheels are neat
[16:33:47] <cradek> the escape wheel is strangely unfinshed, otherwise
[16:33:58] <cradek> replacement maybe
[16:59:14] -!- md-2 has quit [Remote host closed the connection]
[17:08:22] -!- per_sonne has quit [Quit: Be back later ...]
[17:10:39] -!- chris_99 has quit [Ping timeout: 240 seconds]
[17:12:28] -!- lair82 has quit [Quit: Page closed]
[17:22:58] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[17:32:35] -!- furrywolf has quit [Ping timeout: 264 seconds]
[17:44:30] -!- Komzzpa has quit [Ping timeout: 260 seconds]
[17:49:32] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[17:58:17] -!- SEL [SEL!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[18:05:37] -!- ink has quit [Disconnected by services]
[18:22:56] -!- kh0d has quit [Quit: Textual IRC Client: www.textualapp.com]
[18:26:26] <mozmck> Why would you want a text editor written in Javascript that reports to Google?
https://github.com/atom/metrics
[18:27:13] <pcw_home> because all of your base belongs to google
[18:30:33] -!- etvsteva [etvsteva!uid110233@gateway/web/irccloud.com/x-ventcenlpopkzbbz] has joined #linuxcnc-devel
[18:47:52] <jepler> cradek: can linuxcnc do "floppy homing" without wiring up some sort of fake home switch input?
[18:48:16] <cradek> no way I know of
[18:49:23] <skunkworks> floppy homing?
[18:50:22] <mozmck> Does rob ellenburg have a github repo?
[18:50:53] <jepler> skunkworks: where you just bash into the end-stop of the travel on purpose
[18:51:00] <jepler> works great for finding track 0 on a floppy disk
[18:51:44] <skunkworks> ah - ok. funny
[18:52:01] <skunkworks> mozmck,
https://github.com/robEllenberg/linuxcnc-mirror
[18:52:37] <mozmck> Can't you just set your HOME_VEL to 0, jog to stop and click to home the axis?
[18:52:53] <jepler> sure I could do it manually
[18:53:21] <skunkworks> I was thinking some sort of hal timer that just waited a few minutes then tripped all the home pins.
[18:53:31] <skunkworks> (while homing)
[18:53:39] <mozmck> crash detector
[18:54:07] <mozmck> thanks for the link skunkworks - I was not finding it using the search on github.
[18:54:18] <skunkworks> or however long it takes the longest axis to go from one end to the other...
[18:54:33] <skunkworks> cradek had the same issue recently
[18:57:38] <skunkworks> Google finds it though ;)
[18:58:12] <mozmck> I guess I should use that instead. Seems like the github search is not great.
[18:58:22] <cradek> that's very polite of you
[18:58:22] <PCW> some simple servo systems home detecting the motor stall
[18:58:34] <PCW> home by
[19:03:47] <skunkworks> https://www.youtube.com/watch?v=Z2gBYIqDuYY
[19:08:23] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[19:11:37] <PCW> thats neat
[19:13:44] <Tom_itx> yep, i'm watching the pulley one that came up after it
[19:13:53] <Tom_itx> timing pulley
[19:17:58] -!- moorbo_ has quit [Remote host closed the connection]
[19:21:00] -!- _BJFreeman has quit [Client Quit]
[19:26:43] -!- b_b has quit [Remote host closed the connection]
[19:34:30] <jepler> I ordered one of those sub-$100 "300mW" laser engravers and it came today. It does produce a discernable line on thin cardboard at 512mm/min and a dark line at 64mm/min. Once I get tired of using the GRBL controller I'll desolder it (boo, it's not socketed like it I had hoped) and hook it up to linuxcnc via a mesa card.
[19:35:52] <jepler> it uses what look like linear motion assemblies ripped out of 3.5" drives which is the reason for the speculation about homing
[19:36:30] <jepler> https://goo.gl/photos/vc227yv9drXZaUsT7
[19:36:37] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-59-160.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[19:39:57] <jepler> cradek quickly spotted how shoddy the heatsink attachment is -- contact between the laser diode assembly and the heatsink is on one line and two points (setscrews that when loose let you adjust the laser focus)
[19:40:46] -!- Contract_Pilot has quit [Ping timeout: 244 seconds]
[19:53:34] <skunkworks> how do you like grbl?
[19:54:39] <skunkworks> wow - that really is disk drive assemblies
[19:54:43] -!- patrickarlt has quit [Remote host closed the connection]
[19:56:06] <skunkworks> mount the laser on your other machine.
[19:58:58] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:02:14] -!- skunkworks_ has quit [Ping timeout: 272 seconds]
[20:08:49] <jepler> skunksleep: eh I haven't done anything "real" with it yet
[20:09:59] <jepler> it supports g0, g1, x, y, z, g4p, m3, and m5 so all that is good
[20:11:42] -!- patricka_ has quit [Remote host closed the connection]
[20:12:11] <jepler> cradek: is truetype-tracer-4.0 current?
[20:16:03] <cradek> the linuxcnc repo has 4.1-2
[20:16:07] <jepler> ah hm
[20:18:13] <cradek> git://timeguy.com/truetype-tracer.git
[20:21:59] <jepler> hm not quick to make that use grbl-style gcode. no arithmetic in it.
[20:22:49] <cradek> is there arithmetic? I thought the splines would be the problem.
[20:23:01] <jepler> yes, scaling
[20:23:03] <jepler> /G00 X [1330*#3+#5] Y [2816*#3+#6] (moveto)
[20:23:12] <cradek> huh
[20:23:48] <cradek> good reason to write the gcode2gcode you've always wanted to write
[20:23:57] <jepler> ugh
[20:24:16] <cradek> you could hack sai in 5 minutes to do it adequately
[20:25:02] -!- gyeates has quit [Ping timeout: 240 seconds]
[20:30:05] <jepler> yeah
[20:39:17] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[20:44:46] -!- FinboySlick has quit [Quit: Leaving.]
[20:54:24] -!- valeech has quit [Quit: valeech]
[21:03:42] -!- Deejay has quit [Quit: bye]
[21:07:45] -!- anomynous has quit [Ping timeout: 255 seconds]
[21:10:26] -!- skunksleep has quit [Ping timeout: 246 seconds]
[21:11:04] <jepler> it took more than 5, and I used gcodemodule and not sai
[21:13:46] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:18:33] -!- zeeshan has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/ - 64bit Windows version by http://kvirc.d00p.de/]
[21:21:32] -!- zeeshan [zeeshan!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[21:24:59] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:26:26] -!- SEL has quit [Quit: Leaving]
[21:35:46] zeeshan is now known as zeewolf
[21:36:05] MacGalempsy is now known as mac_wolf
[21:36:26] XXCoder is now known as XXWolf
[21:37:27] ssi is now known as wolfwolfeye
[21:39:35] JT-MOBILE is now known as JT-Wolf
[21:50:45] -!- per_sonne has quit [Ping timeout: 240 seconds]
[21:58:01] -!- patrickarlt has quit [Remote host closed the connection]
[22:04:21] -!- micges_ [micges_!~micges@dch93.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:07:26] -!- micges has quit [Ping timeout: 240 seconds]
[22:13:46] -!- TheZealous has quit [Ping timeout: 260 seconds]
[22:32:09] -!- arrowbook has quit [Ping timeout: 265 seconds]
[22:43:32] -!- gyeates has quit [Ping timeout: 246 seconds]
[22:49:25] micges_ is now known as micges
[22:56:59] Tom_itx is now known as Tom_wolf
[22:59:52] -!- mhaberler has quit [Quit: mhaberler]
[23:02:03] Tom_wolf is now known as Tom_itx
[23:05:07] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[23:05:38] -!- chris_99 has quit [Quit: Leaving]
[23:12:06] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[23:52:27] -!- per_sonne has quit [Ping timeout: 255 seconds]
[23:58:53] -!- Akex_ has quit [Quit: Connection closed for inactivity]
