#linuxcnc-devel | Logs for 2013-10-02

[00:00:57] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll c76e9a9 06linuxcnc 10src/hal/drivers/mesa-hostmot2/abs_encoder.c * Spotted a copy and paste error.
[00:03:37] -!- kwallace1 has quit [Ping timeout: 246 seconds]
[00:10:06] <cradek> aha, a keyboard!
[00:11:25] <cradek> rellenberg: about toes: I wrote the current planner and I'm tickled that you are improving or replacing it. So no worries there, and I'll help you however I can.
[00:12:38] <rellenberg> Nice work! There's a lot of clever tricks in there
[00:13:36] <cradek> ah, thank you. None of us are too thrilled with its performance, but it has let thousands (?) of machines run correctly for years, so I am happy about that much.
[00:13:41] <rellenberg> I noticed there was a feature request a year or so back about an S-curve planner
[00:14:09] <cradek> yes people want jerk limiting, but without better lookahead that would pull our speeds down even more.
[00:14:22] <rellenberg> That makes sense
[00:14:31] <rellenberg> we need to get the machines moving fast enough for it to matter
[00:14:32] <cradek> my gut says vanishingly few people would actually benefit from jerk limiting
[00:14:43] <cradek> yes you're right
[00:14:46] <rellenberg> I agree, it seems like polish for most CNC's
[00:15:11] <rellenberg> It would matter more for delta robots and rapid prototypers, i suppose
[00:15:11] -!- thomaslindstr_m has quit [Remote host closed the connection]
[00:15:14] <cradek> people like to compare bullet lists, and that's a bullet that some systems have. it doesn't mean it should be a priority for us.
[00:15:36] <cradek> or the opposite: very massive machines that are capable of high acceleration
[00:15:54] <rellenberg> ahh, good point, machines that could hurt themselves
[00:16:03] <cradek> I have one that might benefit a tiny bit (I turned down the acceleration a lot on my VMC because I didn't like how much it made the floor move)
[00:16:23] <cradek> but the real-world difference in machining time that causes? negligible.
[00:16:48] <cradek> and everything will last longer with it turned down...
[00:16:55] <rellenberg> Are a lot of industrial machines running LCNC?
[00:17:38] <cradek> it's hard to know that. I know of a lot of them. hundreds or thousands though? I can't say.
[00:17:47] <cradek> way more than tens, haha
[00:18:14] -!- cevad has quit [Quit: Leaving]
[00:18:16] <cradek> we sure do have a lot of hobbyists with smallish stepper machines
[00:18:44] -!- kwallace1 [kwallace1!~kwallace@smb-13.sonnet.com] has joined #linuxcnc-devel
[00:18:56] <cradek> about your questions:
[00:19:24] <cradek> 1a, we've talked a little about chunking on the list -- motion currently takes one message at a time, and each move that gets queued is a message
[00:19:57] <cradek> with the current messaging interface: if canon knew there were 100 messages ready, it could always communicate that fact to motion and then start sending them.
[00:21:15] <cradek> but it's normal to have just one move and expect the planner to execute it - MDI is the obvious case - there are also many other cases where a running gcode program waits for the queue to empty out so certain things can sync (IO, probing, etc)
[00:21:35] <rellenberg> Ahh, that makes sense
[00:22:16] <rellenberg> I've tweaked the algorithm a bit to make it run efficiently for one new move
[00:22:19] <cradek> 1b, on some machines the servo cycle is already quite heavily loaded, in particular nontrivkins machines. a puma robot I was working on had the servo thread so full the gui stuff could hardly run.
[00:23:04] <cradek> hobbyists often use old, underpowered hardware (and quite often for more than the obvious reason: old hardware tends to have the best realtime performance)
[00:23:31] -!- davec_ has quit [Quit: Leaving]
[00:23:35] <rellenberg> So old single-core machines that lack the muscle to do a lot of computations
[00:23:44] <cradek> 2- no. 3- I don't know 4- see all the above, ha
[00:24:18] <cradek> even new ones. the intel d525 was the go-to for people wanting to buy new hardware for linuxcnc use -- that is what was in this puma robot I'm thinking of. it was an atom board, not super fast.
[00:25:08] <cradek> and today people are getting more and more interested in VERY low powered machines like raspberry pi. the 3d printer crowd has started this trend and it's contagious.
[00:26:01] <cradek> these machines can't run our standard opengl UI for crap, and so these users are sometimes reverting to our very old (late 90s era) UIs.
[00:26:26] <cradek> just some things to think about
[00:26:56] <cradek> you could certainly add SOME processing to the servo thread and be fine. but if you want to double its typical run time I'd be very worried.
[00:27:18] <rellenberg> That's definitely good to know
[00:27:47] <rellenberg> In the motion code, I saw that the trajectory planner and servo can theoretically run at different rates, yes?
[00:28:05] <cradek> yes, and in the very old days people had to do that for iterative-solving kins
[00:28:26] <rellenberg> right, before closed-form solvers
[00:28:29] <cradek> there is a cubic interpolator layer in there
[00:28:39] <rellenberg> so we could afford to coarsen the output of TP a little
[00:28:43] <cradek> it is almost always no-op for our users today
[00:29:36] <cradek> yes and no - for spindle synchronized motion like tapping, you can't coarsen it because you add delay
[00:29:49] <cradek> for a wood router - you bet you could
[00:30:56] <cradek> when I added rigid tapping is when it became the custom to set servo and traj cycles the same
[00:32:08] <rellenberg> Ok, that makes sense
[00:34:20] <rellenberg> The reason it has to go in the motion module now is because the last few queue'd moves have to be replanned slightly
[00:34:20] <cradek> ok I've talked enough. now how can I help? questions?
[00:35:03] <cradek> by last do you mean oldest or newest?
[00:35:15] <rellenberg> the newest, sorry
[00:36:08] <rellenberg> so a new move gets stuck on the end of the queue, which means what used to be the last move doesn't need to end with zero final velocity
[00:37:00] <cradek> ah I see - each move is "last" in turn. am I correct that any moves can become the last if motion is aborted - you may have to continue to process many moves in order to get stopped while staying on the path - a thing we currently don't have to do
[00:37:32] <rellenberg> yeah, an unplanned stop gets messier
[00:38:10] <rellenberg> But as we had mentioned in that email thread, we don't need a new plan in that case
[00:38:12] <cradek> well it sounds like in the worst case, you'll end up running all the queue, which always gives you a safe stop
[00:38:21] <rellenberg> yes
[00:38:35] <rellenberg> and each step backwards is also safe
[00:39:01] <rellenberg> the limiting factor is the delta-V in each move (since we can't slow down or speed up during a blend)
[00:39:03] <cradek> I'm with you
[00:39:10] -!- FinboySlick has quit [Quit: Leaving.]
[00:39:36] <cradek> that worries me. in many programs (well today) everything is constantly a blend
[00:39:55] -!- tmcw has quit [Ping timeout: 248 seconds]
[00:40:01] <rellenberg> yeah, that's the limiting case
[00:40:15] <rellenberg> I tried to run the math to do acceleration during blends, but that optimization is way messier
[00:40:54] <rellenberg> There is one answer; we could force the blend to be no more than a fraction of the total length
[00:41:05] <rellenberg> say if a blend can't be more than 1/3 of a move
[00:41:17] <rellenberg> then we'll always have at least 1/3 of the move to accelerate
[00:41:24] <cradek> it seems like this will lead to a lot of jerking
[00:42:01] <cradek> you'll have +j and -j for every move that makes up part of the accel
[00:42:01] <rellenberg> yeah, it would stutter as it hit each blend
[00:43:01] <cradek> I am not sure how that would work on a real machine but I suspect it would affect part finish and - uh - sound "weird" if nothing else
[00:43:42] <cradek> if you have limited jerk it would be a lot less violent, but that's a huge ball of wax
[00:44:09] <cradek> it's surprising how much harder the math gets when you add that constraint...
[00:44:34] <rellenberg> limited jerk? yeah it looks like a real pain
[00:44:38] <rellenberg> 7 cases? fuuuuuu
[00:45:50] <cradek> did you see that ja3-jerklimit branch with yishin's work?
[00:46:20] <rellenberg> I looked through the araisrobot repository a week or so ago
[00:46:25] <cradek> I think he was close to having jerk limiting work right
[00:46:42] <cradek> but with no new lookahead ... like we said before
[00:47:11] <cradek> I isolated his planner changes and put them in ja3-jerklimit in git.linuxcnc.org
[00:47:25] <rellenberg> ahh, cool, I'll have to look through that branch
[00:47:31] <cradek> but how close that is to araisrobot today I have no idea
[00:47:53] <rellenberg> Are there any obvious problems with that branch?
[00:48:01] <rellenberg> i.e. could i build and run it on my machine?
[00:48:26] <cradek> yes - it badly violates at least the jerk and accel constraints
[00:48:33] <cradek> in some cases
[00:49:06] <cradek> it doesn't handle spindle-sync and maybe doesn't handle aborts - I don't remember
[00:49:10] <cradek> it was very much a work in progress
[00:49:21] <rellenberg> I noticed there were graphs showing the accel violation on the feature req. page
[00:49:28] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[00:49:35] -!- gonzo_ has quit [Read error: Connection reset by peer]
[00:49:55] <cradek> http://en.araisrobo.com/linuxcnc/g64-max-blending
[00:51:31] <rellenberg> How did those graphs get plotted btw? is there debug output from the motion module?
[00:52:01] <cradek> aha, http://thread.gmane.org/gmane.linux.distributions.emc.devel/6364
[00:52:12] <cradek> I believe this thread is the last he and I interacted
[00:52:30] <cradek> those plots are from halscope, which lets you plot any signal available in HAL
[00:52:53] <cradek> it works a lot like an o'scope, so you can set it up to trigger on a position or accel, and plot for a while
[00:53:19] <cradek> it is a very wonderful thing
[00:53:36] <rellenberg> that's slick! I'll definitely put that to use
[00:55:00] <cradek> in that thread I suggested some cases he should validate - you might like to read that too, even though your cases will be less bad without the 7 states
[00:55:45] <rellenberg> Definitely, I'll have a look over those
[00:56:57] <cradek> also be aware of the sim/lathe sample config, which has simulated spindle encoder feedback. you can test tapping and threading with it.
[00:57:15] <cradek> oops it's sim/axis/lathe now
[00:57:27] <rellenberg> awesome, that will be very helpful
[00:58:51] <cradek> do you have hardware running linuxcnc already?
[00:59:11] <rellenberg> yes, a sherline CNC mill
[00:59:23] <rellenberg> it's not much, but it's using a probotix board and steppers
[00:59:24] <cradek> ah, cool, I like their stuff.
[01:00:11] <rellenberg> it's a nice little machine. I got mine as a trashpick
[01:00:18] <rellenberg> it does surprisingly well within its bounds
[01:00:23] <cradek> I have a sherline lathe with little dc servo motors on it
[01:00:56] <Tom_itx> cradek, what size servos did you use on it?
[01:01:01] <Tom_itx> i've got their little mill
[01:01:04] <Tom_itx> with steppers
[01:01:04] <cradek> and the first lathe to cut a thread with linuxcnc was a sherline in my basement
[01:01:40] <cradek> Tom_itx: http://timeguy.com/cradek-files/cnc/lathe/DSCN6295.JPG
[01:01:48] <cradek> these little pittmans
[01:01:50] <Tom_itx> probably not something i'd update any time soon
[01:02:28] <cradek> a few pictures here: http://timeguy.com/cradek/cnc/lathe
[01:02:29] <Tom_itx> it would be fun to try and set up a servo system though
[01:02:49] <cradek> this doesn't see much use anymore but it worked/works nicely
[01:03:08] <rellenberg> a good testbed if nothing else
[01:03:21] <cradek> rellenberg: my little vmc running linuxcnc/touchy: http://timeguy.com/cradek-files/emc/jr.jpg
[01:03:43] <cradek> heh "little" - I had to raise the ceiling
[01:04:04] <Tom_itx> that's a nice size
[01:04:10] <Tom_itx> that kind is it?
[01:04:17] <Tom_itx> what*
[01:04:40] <rellenberg> wow, toolchanger and everything
[01:04:48] <Tom_itx> my friend had to do the same thing wiht his first Fadal in his garage
[01:04:59] <Tom_itx> cat 40?
[01:05:14] <cradek> it's a mori-seiki MV Jr
[01:05:30] <Tom_itx> aww that's a nice machine
[01:05:34] <cradek> it has direct drive minertia motors so it's fast
[01:05:35] <Tom_itx> they're rugged
[01:05:47] <cradek> yeah and all linear rails. it's awesome
[01:05:48] -!- syyl-- has quit [Ping timeout: 256 seconds]
[01:06:37] <cradek> so I have done all sizes, heh, the biggest machine I've helped with is at MPM
[01:06:45] <Tom_itx> what do you make with it?
[01:06:56] <Tom_itx> oh you helped them retro some?
[01:07:03] <cradek> oh I fix stuff around the house... y'know
[01:07:07] <Tom_itx> yep
[01:07:27] <cradek> yeah I've helped on quite a few projects there
[01:07:45] <Tom_itx> are you nearby?
[01:08:08] <Tom_itx> that's my home town
[01:08:28] <cradek> 3-400 miles
[01:08:41] <cradek> so, yeah, sorta
[01:09:39] <cradek> tool changes etc: http://www.youtube.com/watch?v=eWitrmtqZ7I tapping: http://www.youtube.com/watch?v=9HLKXeWqTF0
[01:09:42] <Tom_itx> i think kimk was from nebraska and he's been there a while now
[01:09:50] <cradek> yes he was from omaha
[01:10:05] <Tom_itx> my original home town :)
[01:11:05] <cradek> rellenberg: what part of the world are you in?
[01:11:25] <rellenberg> Philadelphia
[01:11:42] <Tom_itx> i just wish i had room for a VMC
[01:12:03] <cradek> ah, too far to invite you over for a beer
[01:12:07] <skunkworks> rellenberg: Welcome aboard!
[01:12:20] <skunkworks> isn't matt around there?
[01:12:31] <cradek> he's in maryland I think?
[01:12:32] <rellenberg> too bad, I'm limited by motorcycle range
[01:15:02] aude_ is now known as aude
[01:15:24] <rellenberg> thanks anyway!
[01:15:36] <cradek> well come anytime, but motorcycle means you get coffee, not beer, haha
[01:16:04] <cradek> like grandmas say, I like both equally
[01:16:06] <rellenberg> lol, yeah, good point
[01:16:12] <rellenberg> at the same time?
[01:16:23] <cradek> eww
[01:16:41] <cradek> coffee and whiskey, you bet. not sure about coffee and beer.
[01:17:15] <rellenberg> lol, yeah, depends on the beer, though
[01:17:27] <rellenberg> porter perhaps
[01:19:14] <skunkworks> rellenberg: I think there are alot of big iron running linuxcnc. http://www.youtube.com/watch?v=39q6kvrSBSk
[01:21:06] -!- c-bob|afk has quit [Ping timeout: 264 seconds]
[01:21:39] <rellenberg> that's a good size machine
[01:21:57] <cradek> squeeeeeeeeeeeee
[01:22:01] -!- jfire has quit [Ping timeout: 246 seconds]
[01:22:02] <skunkworks> :)
[01:22:02] <rellenberg> can't discount the big guys
[01:22:45] <cradek> love how bold it is running that tap in there
[01:23:00] <rellenberg> unfortunately I've gotta run, got a meeting tonight. it was good to meet you guys, and thanks for all the help!
[01:23:09] <rellenberg> I'll be on periodically, hopefully with good news
[01:23:31] <cradek> terrific
[01:23:35] <cradek> yell anytime I can help
[01:23:42] <cradek> it was good to finally meet you
[01:24:06] <rellenberg> will do, I'm looking forward to developing with you
[01:24:08] <rellenberg> ttyl
[01:24:28] -!- rellenberg has quit [Quit: Page closed]
[01:27:31] -!- jfire1 has quit [Ping timeout: 245 seconds]
[09:08:33] -!- logger[psha] [logger[psha]!~loggerpsh@] has joined #linuxcnc-devel
[09:20:28] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[09:37:02] -!- voxadam has quit [Ping timeout: 240 seconds]
[09:41:12] -!- mhaberler has quit [Quit: mhaberler]
[09:54:58] voxadam_ is now known as voxadam
[09:57:50] -!- stsydow has quit [Remote host closed the connection]
[10:10:48] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[10:13:46] -!- skunkworks has quit [Remote host closed the connection]
[10:14:28] -!- b_b has quit [Changing host]
[10:15:29] -!- jmasseo has quit [Ping timeout: 240 seconds]
[10:18:21] -!- Poincare has quit [Quit: changing servers]
[10:27:06] -!- stsydow has quit [Ping timeout: 264 seconds]
[11:26:39] -!- jthornton_ [jthornton_!~john@] has joined #linuxcnc-devel
[11:26:41] -!- jthornton has quit [Read error: Connection reset by peer]
[11:28:26] jthornton_ is now known as jthornton
[11:28:51] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:01:20] <skunkworks> I can see that could be a problem if you can't accelerate during a blend.. (if the segments end up being mostly blends)
[12:33:35] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[13:03:21] -!- EngEC has quit [Ping timeout: 250 seconds]
[13:03:53] <skunkworks> I had a dream last night that rellenberg called me and wanted to talk about lookahead. I was trying to explain to him that I didn't understand what he was talking about.. Must have been the pizza
[13:17:29] <cradek> haha
[13:17:35] <cradek> I have no idea here have some pizza
[13:21:43] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[13:30:00] -!- stsydow has quit [Quit: Leaving]
[13:40:15] -!- md-2 has quit [Remote host closed the connection]
[13:46:34] JT-Shop-2 is now known as JT-Shop
[13:56:53] -!- EngEc has quit [Quit: Page closed]
[14:01:07] <cradek> oh no stuart nooooooo
[14:03:37] -!- ravenlock has quit [Ping timeout: 246 seconds]
[14:05:42] <skunkworks> what is he thinking!
[14:06:11] <cradek> rather what is he failing to remember
[14:06:26] <cradek> haven't we gone through this in recent memory?
[14:07:14] <skunkworks> that is the great thing about the internets-- you can always search history
[14:07:41] <cradek> I have lots of evidence that not everyone knows this :-)
[14:14:33] -!- jfire has quit [Quit: Leaving.]
[14:17:37] -!- kwallace [kwallace!~kwallace@smb-184.sonnet.com] has joined #linuxcnc-devel
[14:32:11] -!- jthornton has quit [Ping timeout: 260 seconds]
[14:32:42] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[14:34:45] -!- Vq has quit [Ping timeout: 248 seconds]
[14:36:26] -!- jthornton [jthornton!~john@] has joined #linuxcnc-devel
[14:36:27] -!- JT-Shop [JT-Shop!~John@] has joined #linuxcnc-devel
[14:42:55] -!- thomaslindstr_m has quit [Remote host closed the connection]
[14:44:30] -!- Simooon has quit [Quit: Leaving]
[14:48:33] -!- jef79m has quit [Ping timeout: 268 seconds]
[14:48:38] -!- Valen has quit [Quit: Leaving.]
[14:51:10] Vq_ is now known as Vq
[14:57:36] -!- kwallace2 [kwallace2!~kwallace@smb-223.sonnet.com] has joined #linuxcnc-devel
[15:00:12] -!- kwallace has quit [Ping timeout: 260 seconds]
[15:13:48] -!- Laremere has quit [Ping timeout: 240 seconds]
[15:32:35] <skunkworks> so close with the 8168
[15:32:36] <skunkworks> http://www.mail-archive.com/rtnet-users@lists.sourceforge.net/msg03371.html
[15:32:55] <skunkworks> that is what I get - but don't understand what the changing 1 into 2 means...
[15:34:27] <skunkworks> and why you would be changing the r8169 driver and not the rt_r8169
[15:39:58] -!- Thetawaves_ has quit [Client Quit]
[15:43:13] -!- micges [micges!~micges@dhd61.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:49:36] <jepler> skunkworks: I looked at the post and the linked code and I don't understand what change he means
[15:49:57] <skunkworks> ok - I think I am going to have to get on the mailing list and ask
[15:51:59] -!- syyl- has quit [Ping timeout: 260 seconds]
[15:53:19] <mhaberler> cradek: re jwp, ja3 and Seb's mail - sorry, this is too much of a moving target, so I will stop for now until this is rebased on master. I do have the jwp code working on top of ja3, and beginnings of commanded jogs.
[15:53:27] Cylly is now known as Loetmichel
[15:54:59] <mhaberler> IMO it is woth considering folding teleop into coord, I dont see the upside
[15:55:02] <cradek> your work on top of ja3 will apply just fine on top of ja4
[15:55:30] <cradek> I don't know what you mean by folding
[15:56:16] <jepler> cradek: (mhaberler worked by merging master plus jwp into ja3, saying rebase was the worse choice. So if he works more on top of his wip branch, he'll have to merge ja3 into ja4 which we don't want)
[15:57:04] <cradek> oh right you don't want that merge
[15:57:35] -!- thomaslindstr_m has quit [Remote host closed the connection]
[15:58:07] <mhaberler> other than that, there were no surprises except a few new bugs
[15:58:11] <cradek> I think we don't want most of jwp (the new kind of jogging using hal pins) so starting with that branch is probably the wrong approach
[15:58:55] <cradek> and the new configs and panels that allow the new kind of jogging
[15:59:46] <cradek> I suggest thinking about what parts you really will want for master eventually, and don't merge all the other things
[16:00:04] <jepler> which entails necessarily working by rebase (or from scratch)
[16:00:30] <cradek> yes or a few strategic cherry picks
[16:00:52] asheppard is now known as sheppard
[16:02:20] <mhaberler> well it would be super helpful to come to a conclusion before prodding me into work
[16:02:58] <cradek> that's a weird accusation
[16:04:03] <cradek> I'm trying to help you end up with something that can be easily used on top of seb's work of cleaning up many years of history on ja3 without another big history-cleanup type problem
[16:05:15] <mhaberler> so what are we discussing here, the nature of the patch or where it's going?
[16:05:25] <cradek> merging a bunch of unwanted stuff (and I thought we both agreed it was unwanted, the other day) is the wrong approach, and I never suggested it, and I never prodded you
[16:05:58] <mhaberler> I took away something rather different
[16:06:16] <mhaberler> we agreed that integrating wheel and command jog makes sense
[16:06:21] <cradek> if I was unclear I apologize
[16:06:35] <mhaberler> well yes you were
[16:06:54] <cradek> yes, so the jogs while paused can work as expected, instead of in a new way requiring a new panel etc
[16:07:32] <mhaberler> you certainly are aware this entails UI changes too
[16:08:05] <jepler> yes, it was commented on in the meeting that this would entail UIs changing their ideas of when the jog functionality was available
[16:08:11] <jepler> a UI that doesn't take the time to do this won't be able to jog in the new conditions
[16:08:27] <jepler> this is clearly better than having *this set* of jog UI which you use sometimes, and *that set* you use at other times
[16:08:50] <mhaberler> what the guys where rather clear about, and what you dont seem to like: this is something working _now_, independently of other folks fixing their UI's task and whatnot
[16:08:58] <cradek> yes that was my objection to your existing approach since day 1
[16:09:45] <jepler> just changing when axis disables the UI elements for jogging is trivial compared to everything else
[16:09:56] <mhaberler> well first, the core part of the patch - the pause FSM - will be identical whether there are hal pins or not, the only thing which changes is how commanded pos is aquired
[16:10:03] <cradek> I don't care about that, since they can use it as-is for as long as they like. our new goal is to make something suitable for merging into master, which means it does not have the separate type of jog
[16:10:21] <cradek> what is FSM?
[16:10:26] <mhaberler> finite state machine
[16:10:48] <cradek> then cherry-pick the thing that does that part
[16:11:06] <cradek> leave out everything else that we would have to remove later anyway
[16:15:14] <cradek> it looks like you want most of http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commitdiff;h=778b620606052ed6efc881b6f0710860842cc98d
[16:15:43] <cradek> then you will remove the hal-dependent stuff (maybe use rebase -i to squash in that removal) and continue
[16:17:02] <mhaberler> I do not like how you proclaim 'our new goals' - make it a goal decision item for the IRC meeting, discuss it on the list beforehand like you want from everybody else. We have decided to not make decisions on IRC.
[16:17:41] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has parted #linuxcnc-devel
[16:18:03] <cradek> now you just want to argue and I decline. bbl.
[16:18:28] -!- tugge_ has quit [Read error: No route to host]
[16:19:19] -!- mhaberler has quit [Quit: mhaberler]
[16:42:06] -!- micges has quit [Ping timeout: 245 seconds]
[16:52:25] -!- kanzure_ has quit [Client Quit]
[16:52:53] -!- micges [micges!~micges@dhd61.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[17:02:27] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[17:14:10] -!- sumpfralle has quit [Read error: Operation timed out]
[17:18:23] -!- Gigs- has quit [Read error: Connection reset by peer]
[17:31:22] -!- Connor has quit [Read error: Connection reset by peer]
[17:33:22] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:42:08] -!- md-2 has quit [Remote host closed the connection]
[17:56:34] -!- eFuchs has quit [Quit: ping timeout]
[17:58:09] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:01:16] -!- Laremere has quit [Ping timeout: 245 seconds]
[18:18:49] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:20:23] -!- maximilian_h [maximilian_h!~bonsai@f051196216.adsl.alicedsl.de] has joined #linuxcnc-devel
[18:23:25] -!- maximilian_h has quit [Client Quit]
[18:31:18] -!- vladimirek has quit [Ping timeout: 264 seconds]
[18:32:42] -!- vladimirek [vladimirek!~vladimire@] has joined #linuxcnc-devel
[18:47:40] -!- KimK has quit [Quit: Leaving]
[18:54:06] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[19:22:00] -!- sirdancealot has quit [Ping timeout: 252 seconds]
[19:24:02] -!- vladimirek has quit [Remote host closed the connection]
[19:29:02] -!- krusty_ar has quit [Ping timeout: 240 seconds]
[19:31:28] -!- Brandonian has quit [Read error: Connection reset by peer]
[19:34:48] -!- jfire has quit [Quit: Leaving.]
[19:38:11] -!- freeform [freeform!~fsr@] has joined #linuxcnc-devel
[19:58:09] -!- skunkworks has quit [Quit: Leaving]
[19:59:09] -!- adb [adb!~IonMoldom@2a02:1205:5017:a2f0:baac:6fff:fe67:305f] has joined #linuxcnc-devel
[19:59:31] -!- micges has quit [Read error: Connection reset by peer]
[20:01:54] -!- motioncontrol has quit [Quit: Sto andando via]
[20:22:24] -!- micges [micges!~micges@dhd61.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:22:57] -!- afiber__ has quit [Quit: Konversation terminated!]
[20:24:58] -!- flippyhead has quit [Quit: flippyhead]
[20:32:51] -!- gimps_ has quit []
[20:38:29] -!- freeform has quit [Ping timeout: 240 seconds]
[21:02:43] -!- DJ9DJ has quit [Quit: bye]
[21:05:47] -!- chillly has quit [Quit: Leaving]
[21:08:34] -!- FinboySlick has quit [Quit: Leaving.]
[21:20:32] -!- flippyhead has quit [Quit: flippyhead]
[21:24:07] -!- micges_ [micges_!~micges@] has joined #linuxcnc-devel
[21:27:57] -!- micges has quit [Ping timeout: 252 seconds]
[21:37:11] -!- gonzo_ has quit [Read error: Connection reset by peer]
[21:37:36] -!- skorasaurus has quit [Quit: Elvis has left the building.]
[21:39:46] -!- micges_ has quit [Quit: Leaving]
[21:45:35] -!- odogono has quit [Quit: odogono]
[21:55:27] -!- rob_h has quit [Ping timeout: 252 seconds]
[22:11:37] -!- Einar has quit [Quit: Leaving]
[22:28:08] -!- Brandonian has quit [Quit: Brandonian]
[22:35:26] -!- thomaslindstr_m has quit [Remote host closed the connection]
[22:50:20] -!- tmcw has quit [Remote host closed the connection]
[22:50:28] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[22:55:02] -!- tmcw has quit [Ping timeout: 240 seconds]
[22:58:20] -!- adb has quit [Ping timeout: 245 seconds]
[23:02:27] -!- flippyhead has quit [Quit: flippyhead]
[23:05:30] -!- gonzo__ has quit [Ping timeout: 264 seconds]
[23:25:37] -!- flippyhead has quit [Quit: flippyhead]
[23:27:36] -!- thomaslindstr_m has quit [Remote host closed the connection]
[23:27:40] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:35:23] -!- krusty_ar has quit [Ping timeout: 260 seconds]
[23:37:45] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll 8d4dcc5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/abs_encoder.c * Tweaks to Fanuc. Also no longer require a name (no dummy name for patch bits)
[23:50:51] -!- asdfasd has quit [Ping timeout: 248 seconds]
[23:53:50] -!- krusty_ar has quit [Ping timeout: 240 seconds]
[23:59:23] -!- krusty_ar_ has quit [Quit: No Ping reply in 180 seconds.]