#linuxcnc-devel | Logs for 2018-08-09
Back
[10:45:22] -!- logs has joined #linuxcnc-devel
[10:45:27] -!- hm2-buildmaster has joined #linuxcnc-devel
[10:48:43] -!- hm2-buildmaster_ has joined #linuxcnc-devel
[10:48:50] -!- linuxcnc-build_ has joined #linuxcnc-devel
[10:49:02] -!- seb_kuzminsky has joined #linuxcnc-devel
[10:49:02] -!- mode/#linuxcnc-devel [+v seb_kuzminsky] by ChanServ
[10:49:37] -!- linuxcnc-build has quit [Ping timeout: 248 seconds]
[10:49:39] -!- KGB-wlo has joined #linuxcnc-devel
[10:49:52] -!- hm2-buildmaster has quit [Ping timeout: 256 seconds]
[10:51:44] -!- micges has joined #linuxcnc-devel
[10:55:08] -!- bungle2 has joined #linuxcnc-devel
[10:56:18] -!- bungle2 has quit [Remote host closed the connection]
[11:10:51] -!- cradek_ has quit [Changing host]
[11:10:52] -!- cradek_ has joined #linuxcnc-devel
[11:10:52] -!- mode/#linuxcnc-devel [+v cradek_] by ChanServ
[11:10:59] cradek_ is now known as cradek
[11:11:57] cradek is now known as cradek_
[11:12:46] cradek_ is now known as cradek
[11:12:47] <cradek> sorry
[11:23:05] -!- micges has quit [Ping timeout: 240 seconds]
[11:32:10] -!- C0c0dril020 has joined #linuxcnc-devel
[11:33:22] -!- C0c0dril020 has quit [Remote host closed the connection]
[11:48:00] -!- micges has joined #linuxcnc-devel
[12:05:57] <hazzy-lab> skunkworks: I think rene-dev is waiting on this PR to continue working on the tool table: https://github.com
[12:08:53] -!- ori0 has joined #linuxcnc-devel
[12:09:43] -!- ori0 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[12:14:18] -!- micges has quit [Quit: Wychodzi]
[12:23:51] <seb_kuzminsky> #415 looks like it's not ready
[12:33:56] <hazzy-lab> seb_kuzminsky: I don't think it is. I meant I think he is waiting to get that sorted before continuing on with the tool table improvements
[12:34:22] <seb_kuzminsky> ok cool, we're seeing the same thing
[12:34:48] <seb_kuzminsky> it's sometimes confusing as a maintainer when there are open PRs that are not ready to pull, so thanks for the sanity check
[12:35:09] <seb_kuzminsky> (and i'm sure guilty of making PRs like that in other projects)
[12:39:30] <hazzy-lab> yes, that PR is a little confusing! almost more of an issue ..
[12:44:51] -!- KimK has quit [Ping timeout: 240 seconds]
[12:44:59] -!- TehNut11 has joined #linuxcnc-devel
[12:45:44] -!- KimK has joined #linuxcnc-devel
[12:46:56] -!- TehNut11 has quit [Remote host closed the connection]
[12:54:16] -!- ve7it has joined #linuxcnc-devel
[13:27:12] -!- Roguish_ has joined #linuxcnc-devel
[13:29:51] -!- Roguish has quit [Ping timeout: 240 seconds]
[13:36:23] -!- acuzio13 has joined #linuxcnc-devel
[13:36:41] -!- acuzio13 has quit [K-Lined]
[13:38:53] -!- SakiiR has joined #linuxcnc-devel
[13:44:44] -!- SakiiR has quit [Ping timeout: 260 seconds]
[13:46:10] -!- selroc has joined #linuxcnc-devel
[13:56:40] -!- arooni29 has joined #linuxcnc-devel
[14:02:57] -!- arooni29 has quit [Ping timeout: 240 seconds]
[14:03:25] -!- selroc has quit [Quit: Leaving]
[14:29:43] -!- grotius has joined #linuxcnc-devel
[14:32:30] -!- grotius has quit [Client Quit]
[14:37:52] -!- Xxx has joined #linuxcnc-devel
[14:38:30] -!- Xxx has quit [Client Quit]
[14:40:11] -!- Syncopix15 has joined #linuxcnc-devel
[14:41:46] -!- Syncopix15 has quit [K-Lined]
[14:43:19] -!- skunkworks has quit [Quit: leaving]
[14:44:25] -!- skunkworks has joined #linuxcnc-devel
[15:26:36] <rene_dev_> 18:24 <rene_dev_> it works, but isnt complete
[15:26:36] <rene_dev_> 18:25 <rene_dev_> some things like t remap dont work properly
[15:26:36] <rene_dev_> 18:25 <rene_dev_> and I discovered more bugs, that are also present in master...
[15:27:37] -!- cwre has joined #linuxcnc-devel
[15:28:42] -!- cwre has quit [Remote host closed the connection]
[15:30:03] <seb_kuzminsky> rene_dev_: thanks for being careful and diligent
[15:30:41] -!- c-log has quit [Ping timeout: 248 seconds]
[15:33:11] -!- c-log has joined #linuxcnc-devel
[15:35:02] -!- myth0d7 has joined #linuxcnc-devel
[15:39:51] -!- myth0d7 has quit [Ping timeout: 240 seconds]
[15:47:45] -!- jthornton has quit [Read error: Connection reset by peer]
[15:47:47] -!- JT-Shop has quit [Read error: Connection reset by peer]
[15:50:46] -!- Iciloo21 has joined #linuxcnc-devel
[15:51:29] -!- Iciloo21 has quit [Remote host closed the connection]
[15:51:41] Tom_L is now known as Tom_shop
[15:51:52] Tom_shop is now known as Tom_itx
[15:52:02] Tom_itx is now known as Tom_L
[15:55:42] -!- Tom_itx has joined #linuxcnc-devel
[15:55:42] -!- Tom_itx has quit [Changing host]
[15:55:42] -!- Tom_itx has joined #linuxcnc-devel
[15:56:37] Tom_itx is now known as Log
[15:58:14] -!- c-log has quit [Remote host closed the connection]
[15:58:19] Log is now known as C-Log
[15:58:20] -!- jthornton has joined #linuxcnc-devel
[15:58:43] -!- JT-Shop has joined #linuxcnc-devel
[16:00:15] -!- C-Log has quit [Client Quit]
[16:00:38] -!- c-log has joined #linuxcnc-devel
[16:01:03] c-log is now known as Guest85094
[16:03:36] -!- Guest85094 has quit [Remote host closed the connection]
[16:05:51] -!- Tom_itx has joined #linuxcnc-devel
[16:05:52] -!- Tom_itx has quit [Changing host]
[16:05:52] -!- Tom_itx has joined #linuxcnc-devel
[16:07:07] <rene_dev_> but the pockets in remaps do work, and pepole are using that bit.
[16:07:21] Tom_itx is now known as c-log
[16:08:02] -!- c-log has quit [Client Quit]
[16:08:16] -!- c-log has joined #linuxcnc-devel
[16:08:16] -!- c-log has quit [Changing host]
[16:08:16] -!- c-log has joined #linuxcnc-devel
[16:08:21] -!- Tom_itx has joined #linuxcnc-devel
[16:08:22] -!- Tom_itx has quit [Changing host]
[16:08:22] -!- Tom_itx has joined #linuxcnc-devel
[16:08:30] -!- Tom_itx has quit [Client Quit]
[16:08:51] <rene_dev_> one bug I already fixed, and is merged in master
[16:09:11] <rene_dev_> I discoverd it while writing tests for the pockets
[16:10:44] <seb_kuzminsky> the #5400 fix?
[16:32:32] <rene_dev_> yes
[16:32:42] <rene_dev_> there is possibly more like that
[16:33:06] <rene_dev_> I dont understand why not all parameters are named
[16:33:13] <rene_dev_> numbers are hard to remember, or read
[16:33:27] <seb_kuzminsky> named parameters are fairly recent
[16:33:39] <seb_kuzminsky> numbered parameters are "standard" g-code
[16:34:06] <rene_dev_> hmmm, not really.
[16:35:16] <seb_kuzminsky> numbered parameters can also be used with indirection, though i don't know if people do that a lot
[16:35:33] <rene_dev_> indirection?
[16:35:41] <rene_dev_> I find them really hard to read in gcode.
[16:37:08] <seb_kuzminsky> me too
[16:38:03] <rene_dev_> I was working with some local made controller, fixing a machine today
[16:38:27] <rene_dev_> and I must say I like the way they handle toolchange
[16:38:49] <rene_dev_> you just create a file m6.cnc, and it does whats in there on m6. thats all.
[16:38:58] <rene_dev_> why isnt it that simple in linuxcnc?
[16:39:10] <seb_kuzminsky> indirection like this:
[16:39:11] <seb_kuzminsky> READ => #1 = 2
[16:39:11] <seb_kuzminsky> READ => #2 = 10
[16:39:11] <seb_kuzminsky> READ => g0 x##1 6 N..... STRAIGHT_TRAVERSE(10.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[16:39:38] <rene_dev_> uff, why would someone do that :O
[16:39:49] <seb_kuzminsky> i don't know! :-)
[16:40:11] <seb_kuzminsky> just pointing out something you can do with numeric parameters that you can't do with named parameters
[16:40:23] <seb_kuzminsky> "though i don't know if people do that a lot" :-)
[16:41:05] <seb_kuzminsky> anyway, yeah I'm not at all about to claim linuxcnc does everything best, or that the way things are now is the way things should be in the awesome future
[16:41:21] <seb_kuzminsky> it's just how far we've all pushed it forward since the beginning, so far
[16:43:32] <rene_dev_> yeah :D
[16:43:54] <rene_dev_> to me it just looks like remaps are just waaay to complicated
[16:44:13] <rene_dev_> there should only ever be one simple way of doing things like this
[16:44:38] <seb_kuzminsky> sigh, yeah
[16:46:16] -!- micges has joined #linuxcnc-devel
[16:47:58] -!- tktech8 has joined #linuxcnc-devel
[16:48:11] -!- tktech8 has quit [K-Lined]
[16:58:11] -!- Techman26 has joined #linuxcnc-devel
[16:58:42] -!- bitch17 has joined #linuxcnc-devel
[16:59:11] -!- bitch17 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[16:59:42] -!- Techman26 has quit [Remote host closed the connection]
[17:22:10] -!- jthornton has quit [Quit: Leaving]
[17:24:56] -!- jthornton has joined #linuxcnc-devel
[17:26:23] <hazzy-lab> seb_kuzminsky: I have never been able to get indirection to work, and I have spent a LOT of time trying
[17:26:37] <hazzy-lab> I think it may only work with sub calls
[17:26:51] -!- noah12 has joined #linuxcnc-devel
[17:27:01] -!- noah12 has quit [Killed (Unit193 (Spam is not permitted on freenode.))]
[17:27:27] -!- memoryno- has joined #linuxcnc-devel
[17:27:41] -!- diz8 has joined #linuxcnc-devel
[17:27:43] -!- memoryno- has quit [Killed (Unit193 (Spam is not permitted on freenode.))]
[17:28:06] -!- diz8 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[17:28:27] <hazzy-lab> hmm, maybe I did not have the right syntax, I was tried things like #[#1 * #2]
[17:32:14] <cradek> READ => #1=2
[17:32:14] <cradek> READ => #2=3
[17:32:14] <cradek> READ => #6=3.14
[17:32:14] <cradek> READ => g0 x#[#1*#2]
[17:32:14] <cradek> 6 N..... STRAIGHT_TRAVERSE(3.1400, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[17:32:41] <cradek> (?)
[17:35:49] -!- jthornton has quit [Remote host closed the connection]
[17:36:04] <hazzy-lab> cradek: for example, I want to get the z offset of the current work coord system, so I tried this:
[17:36:04] <hazzy-lab> (debug, #[5203 + [20 * #5220]])
[17:36:25] <hazzy-lab> But it does not seems to work when entered into the axis MDI input
[17:39:05] -!- jthornton has joined #linuxcnc-devel
[17:41:03] <cradek> I think debug has limitations, because it does its own substitution, and it doesn't know how to do the evaluations
[17:41:34] <hazzy-lab> cradek: it works when I run rs274 in the terminal!
[17:41:39] <hazzy-lab> hurray!
[17:41:57] <cradek> #1=#[#5203+[20*#5220]]
[17:41:59] <hazzy-lab> I should not have jumped to conclusions that it was not working
[17:42:00] <cradek> (debug,#1)
[17:42:12] <cradek> you could do these two things in mdi to get the result you want
[17:42:44] <cradek> er I spelled it wrong
[17:42:46] <cradek> you get the idea
[17:43:25] <hazzy-lab> yes, that works in MDI!
[17:43:26] <cradek> you were not wrong, (debug) in mdi violates some very reasonable expectations
[17:46:39] -!- jthornton has quit [Remote host closed the connection]
[17:48:40] -!- jthornton has joined #linuxcnc-devel
[17:50:19] <hazzy-lab> cradek: you can not imagine how exiting it is to be able to use indirection!
[17:50:38] <hazzy-lab> rene_dev_: A practical application of indirection in a probing routine: http://dpaste.com
[17:50:53] <hazzy-lab> that saves a LOT of typing ...
[17:51:13] <cradek> it gives you array workalikes etc, too
[17:51:48] <hazzy-lab> yes, that is true!
[17:51:51] <cradek> (wish we had G53 G38.x)
[17:52:04] * hazzy-lab does too
[17:52:15] <hazzy-lab> I think that is better than adding parameters ...
[17:52:36] <hazzy-lab> but I think seb already started adding parameters for ABS probed pos
[18:07:37] <seb_kuzminsky> https://github.com
[18:08:11] <seb_kuzminsky> it doesn't add g53 g38.n, but it does make it so g38.n stores the probed location in both the currently active work coordinate system and in the g53 coordinate system
[18:08:18] <seb_kuzminsky> (in different sets of numbered parameters)
[18:09:03] <seb_kuzminsky> http://buildbot.linuxcnc.org
[18:09:21] <seb_kuzminsky> g53 in #5081-#5089
[18:16:19] -!- CMorley has quit [Quit: Leaving.]
[18:16:49] <seb_kuzminsky> like rene_dev_ and i were just talking about above, sort of, doing this the way i think users would want is harder than it seems like it should be
[18:17:54] <seb_kuzminsky> Motion determines the probe location, and linuxcnc makes it available to "the user" in Interpreter parameters and in the Status buffer
[18:17:54] <rene_dev_> would be cool if you could also add named parameters... would make probing macros SO much easier to read
[18:18:14] <hazzy-lab> seb_kuzminsky: just a thought. Since Fanuc uses the same parameters for the ABS probed pos as LCNC currently used for the REL probed pos, might it be better to make it possible to use G53 with G30.x, rather than adding additional parameters?
[18:18:18] <hazzy-lab> Than all that would be needed to make a Fanuc probing routine compatible with LCNC would be to add a G53 before the probe
[18:18:18] <hazzy-lab> I know we are not trying to be consistent with any commercial controller, but it seems like it might be a cleaner solution overall
[18:18:26] <seb_kuzminsky> the status buffer has a raw copy of the probe location from Motion, which is in G53 (because all of Motion is in G53 and knows nothing about work coordinates)
[18:18:35] <rene_dev_> I came across this same issue years ago, and no one replied on the ML :D
[18:18:58] <seb_kuzminsky> the interp parameters (before my branch) have the work coord offsets of the g53 position from motion
[18:19:43] <seb_kuzminsky> so copying the g53 coords into new interp params is easy, but getting the work coord positions into the status buffer has to happen in a totally different place (from inside interp)
[18:20:28] <seb_kuzminsky> hazzy-lab: thanks, i didn't know that about fanuc
[18:20:44] <seb_kuzminsky> (though i think you meant "G38.n" instead of "G30.n"?)
[18:21:35] <hazzy-lab> seb_kuzminsky: I think it is fine it the status buffer only reports probed pos in G53 coords, it is easy to convert from G53 to a work coord, but not so much the other way around
[18:21:36] <seb_kuzminsky> changing the meaning of existing parameters is awkward, because it breaks existing g-code
[18:21:51] <hazzy-lab> seb_kuzminsky: Yes, i meant G38 :)
[18:21:52] <cradek> neither conversion is easy or obvious
[18:22:01] <seb_kuzminsky> cradek: because of rotation?
[18:22:04] <cradek> and units
[18:22:11] <seb_kuzminsky> oh, right
[18:22:14] <cradek> and tool offset and g92 offset and g5x offset
[18:22:43] <hazzy-lab> seb_kuzminsky: it would not bread existing code, because the parameters would have the same meaning they do now, unless G53 was sued with G38
[18:22:45] <seb_kuzminsky> right, it'd be much better to do it once and do it right, inside linuxcnc, and users can just use those precomputed values
[18:22:50] <hazzy-lab> break*
[18:22:55] <cradek> I think (THINK) the one you currently get is the one you can use right away in a motion command without being surprised
[18:23:51] <seb_kuzminsky> cradek: i just looked at this, the Status buffer has the numbers directly from motion, but the interp params have the converted-to-work-coords numbers
[18:24:05] <hazzy-lab> cradek: yes, but who would use a probed pos for a motion command?? Probe pos are almost always used for setting a work coord offset
[18:24:13] <cradek> that seems plausible
[18:25:08] <cradek> hazzy-lab: that's where G10 L20 works nicely
[18:25:18] <hazzy-lab> no
[18:25:19] <seb_kuzminsky> hazzy-lab: i see what you're saying, use "G53 G38.n" if you want G53 coords everywhere, or keep using "G38.n" without G53 to maintain the current behavior of work coordinates in Interp parameters
[18:26:14] <cradek> G38.2 Z-...; G0 [#5220+1]; G10 L20 Z1
[18:26:16] <hazzy-lab> because G10 L20 sets the current location to the values specified, what you want to do is set the work coord offsets
[18:26:48] <hazzy-lab> cradek: but then probing holes and slots that is not so trivial ..
[18:27:32] <cradek> my probe routine ends up with the probe in the center of the hole when done, and then G10 L20 X0 Y0 sets the coordinate system to the hole
[18:27:42] <hazzy-lab> as setting the work offset becomes a "causes motion" type command and you have to be careful you don't crash the probe
[18:27:44] <cradek> I don't see why nobody likes what it does now
[18:28:10] <cradek> huh?
[18:28:34] <seb_kuzminsky> cradek: is your hole probe sub posted somewhere?
[18:28:53] <seb_kuzminsky> is it the probe-hole.ngc in our nc_files?
[18:28:54] <cradek> it's just like all of them...
[18:28:58] <cradek> probably?
[18:29:06] <Tom_L> cause we copied yours :D
[18:29:12] <seb_kuzminsky> obviously not everyone knows your technique
[18:29:32] <hazzy-lab> cradek: for example, you are in a narrow slot and want to set zero to one side of the slot
[18:29:37] <cradek> yeah that looks like mine :-)
[18:30:03] <seb_kuzminsky> it was added by jthornton in 2008
[18:30:48] <seb_kuzminsky> and then rewritten by you in 2010 :-)
[18:32:39] <cradek> g38.2 x...; g0 x[#5xxx-.01]; g10 l20 x-.01
[18:33:41] <cradek> you always want to pull off at least a little I think?
[18:35:05] <hazzy-lab> with indirection this becomes almost a non issue :)
[18:35:06] <hazzy-lab> G38.2 Z-.75; G0 G10 L2 P#5220 Z[#5063 + #[5203 + [20 * #5220]]]
[18:35:38] <cradek> (G0 G10 is invalid)
[18:35:56] <hazzy-lab> oops, how did that G0 sneak in there?
[18:35:56] <hazzy-lab> lol
[18:36:13] <cradek> I think I see what you mean
[18:36:30] <cradek> how do you write "pull off a little bit" then?
[18:37:03] <hazzy-lab> G90 G38.2 Z-.75; G0 Z.1; G10 L2 P#5220 Z[#5063 + #[5203 + [20 * #5220]]]
[18:37:07] <hazzy-lab> better?
[18:37:13] <hazzy-lab> make use of that G0 :D
[18:37:24] <cradek> what would you G0?
[18:37:37] <hazzy-lab> or G1 ...
[18:37:46] <cradek> to what endpoint?
[18:37:51] <hazzy-lab> but you can pull off fast
[18:37:59] <hazzy-lab> .1 up in Z
[18:38:27] <cradek> in a narrow slot how would you just barely pull off the surface?
[18:38:44] <cradek> remember you don't know how far you overtravelled
[18:38:48] <hazzy-lab> What I do is store the initial probe pos and go back there
[18:38:48] <cradek> depends on your probing speed
[18:38:53] <hazzy-lab> then you know you are safe
[18:38:55] <cradek> ah that makes sense
[18:38:55] <Tom_L> you took your probe routines offline ehh?
[18:39:26] <cradek> Tom_L: my whole personal blog is gone, at least for now, going pro with the watch repair
[18:39:34] <Tom_L> saw that
[18:39:39] <Tom_L> looks good btw
[18:39:47] <cradek> thank you
[18:39:49] <seb_kuzminsky> you need an unprofessional website too
[18:40:07] <cradek> works on computers and tablets and phones, felt like a huge accomplishment
[18:40:33] <cradek> seb_kuzminsky: I need more hours in each day too
[18:40:40] <seb_kuzminsky> :-)
[18:41:12] <Tom_L> there are 48 hrs in a day, they're just shorter
[18:41:23] <seb_kuzminsky> mars has 24.5 hrs/day
[18:41:33] <Tom_L> long commute
[18:41:56] <Tom_L> you don't mind if i re'post em if i find em here do ya?
[18:42:09] <cradek> of course not
[18:42:15] <Tom_L> i swear i had em on my server somewhere
[18:42:16] <cradek> archive.org should have everything
[18:42:26] <cradek> apparently they were up for over a decade
[18:43:27] -!- mattcode has joined #linuxcnc-devel
[18:43:49] <Tom_L> ah hah..
[18:44:58] <cradek> on my vmc I use them as touchy macros, and you can fill in "1" for "set coord system 1 here" or leave it blank for just probe and pull off
[18:44:59] -!- mattcode has quit [Remote host closed the connection]
[18:45:16] <Tom_L> http://tom-itx.no-ip.biz:81
[18:47:59] <seb_kuzminsky> sooo, hazzy-lab, no need for me to finish that abs-probe branch? you got what you need from cradek?
[18:48:35] <cradek> adding more #vars to probing if you feel like it makes perfect sense
[18:48:47] <cradek> if there's room in the numbers, even better
[18:49:12] <cradek> I always envisioned supporting g53 g38.2 (reusing the #vars) but your way is fine too
[18:49:17] * cradek shrugs
[18:49:20] -!- raspimate_ has joined #linuxcnc-devel
[18:49:21] <seb_kuzminsky> yeah we haven't run out of numbers yet
[18:49:30] -!- raspimate_ has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[18:49:36] <hazzy-lab> seb_kuzminsky: I guess so. The problem is the same (not having ABS probed pos), but the use of indirection makes it much easy to work around
[18:50:56] <hazzy-lab> seb_kuzminsky: thanks for mentioning indirection earlier! That is what induced me to give it another go
[18:51:10] <seb_kuzminsky> yay!
[18:51:48] <hazzy-lab> I actually had it, but the (debug, ) messages were wrong, which thru me off
[18:52:22] <seb_kuzminsky> yeah, it's pretty crazy that the rules for parameter expansion are different in "real gcode" vs in (debug)
[18:52:47] <cradek> wellllll
[18:53:04] <cradek> the obvious solution is to just execute the code, but that's also an obvious problem
[18:53:26] <cradek> because most things you (debug,...) aren't gcode
[18:54:11] <cradek> so I don't know what particular hack is best because neither printing as-is or running it as gcode and printing that are right
[18:54:13] <seb_kuzminsky> i think most things i (debug) are parameters
[18:54:39] <cradek> (debug, the radius is #1)
[18:55:04] <seb_kuzminsky> can parameter expansion cause motion, or cause interpreter state to change in any way? not that i can think of
[18:55:33] <cradek> I don't think so either
[18:56:26] <seb_kuzminsky> but i see your point that pulling parts out of a (debug) argument string and running them through the interpreter seems a bit sketchy
[18:56:51] <cradek> but you can't just blindly expand # can you? (debug, the radius is #1 and doesn't this stuff afterward cause a bunch of syntax errors now?)
[18:56:58] <seb_kuzminsky> even if you just run the string through the parameter-expansion function
[18:57:11] * hazzy-lab needs to start using the rs274 command line tool more, it is really very convenient
[18:57:13] <seb_kuzminsky> yeah, you'd have to parse it enough to know what the parameter is
[18:57:24] <cradek> I'm truly not sure, but I'm uneasy about it
[18:59:30] -!- CMorley has joined #linuxcnc-devel
[19:12:40] -!- drot5 has joined #linuxcnc-devel
[19:13:07] -!- drot5 has quit [Read error: Connection reset by peer]
[19:43:26] -!- Iota8 has joined #linuxcnc-devel
[19:43:29] -!- Iota8 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[19:51:11] -!- IntPtr13 has joined #linuxcnc-devel
[19:51:21] -!- IntPtr13 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[20:18:14] -!- kl42008 has joined #linuxcnc-devel
[20:19:27] -!- kl42008 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[20:26:52] -!- johtso has joined #linuxcnc-devel
[20:27:58] -!- johtso has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[21:31:48] -!- captain4226 has joined #linuxcnc-devel
[21:38:08] -!- captain4226 has quit [Ping timeout: 256 seconds]
[22:04:06] -!- Raito_Bezarius23 has joined #linuxcnc-devel
[22:10:12] -!- Raito_Bezarius23 has quit [Ping timeout: 244 seconds]
[22:10:30] -!- Some_Person13 has joined #linuxcnc-devel
[22:10:46] -!- Some_Person13 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[22:20:24] -!- Guest62181 has joined #linuxcnc-devel
[22:26:13] -!- Guest62181 has quit [Ping timeout: 244 seconds]
[22:38:04] -!- barlas18 has joined #linuxcnc-devel
[22:38:17] -!- barlas18 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[22:57:54] -!- Menche28 has joined #linuxcnc-devel
[22:58:17] -!- Menche28 has quit [Remote host closed the connection]
[23:07:33] -!- Guest42469 has joined #linuxcnc-devel
[23:07:39] -!- Guest42469 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
[23:17:06] -!- Roguish_ has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[23:18:47] -!- hazzy-lab has quit [Read error: Connection reset by peer]
[23:20:38] -!- hazzy-lab has joined #linuxcnc-devel
[23:25:15] -!- c-log has quit [Remote host closed the connection]
[23:25:36] -!- c-log has joined #linuxcnc-devel
[23:25:37] -!- c-log has quit [Changing host]
[23:25:37] -!- c-log has joined #linuxcnc-devel
[23:58:57] -!- Gentle has joined #linuxcnc-devel
[23:59:14] -!- Gentle has quit [Killed (Sigyn (Spam is off topic on freenode.))]