Back
[00:06:25] -!-
rob_h has quit [Ping timeout: 256 seconds]
[00:12:08] -!-
mhaberler has quit [Quit: mhaberler]
[00:36:30] -!-
Valen has quit [Quit: Leaving.]
[00:40:33] -!-
sumpfralle has quit [Ping timeout: 244 seconds]
[00:44:37] -!-
syyl_ has quit [Quit: Leaving]
[00:55:29] -!-
JT-Shop has quit [Read error: Connection timed out]
[00:56:45] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[01:57:09] -!-
ve7it has quit [Remote host closed the connection]
[02:28:23] -!-
factor has quit [Quit: Leaving]
[02:29:24] -!-
demacus_ has quit [Read error: Operation timed out]
[02:32:17] -!-
Keknom has quit [Read error: Connection reset by peer]
[02:46:49] -!-
kb8wmc [kb8wmc!~chatzilla@nat.mtp.cmsinter.net] has joined #linuxcnc-devel
[02:55:27] -!-
adb has quit [Ping timeout: 245 seconds]
[03:04:43] -!-
adb [adb!~adb@178-211-226-40.dhcp.voenergies.net] has joined #linuxcnc-devel
[03:09:47] -!-
_1SheYode has quit [Ping timeout: 252 seconds]
[03:12:58] -!-
norias has quit [Ping timeout: 244 seconds]
[03:33:07] -!-
norias has quit [Ping timeout: 244 seconds]
[03:39:04] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[03:41:55] -!-
atom1 has quit [Quit: Leaving]
[04:00:10] -!-
toastydeath has quit [Read error: Connection reset by peer]
[04:19:53] -!-
Valen has quit [Quit: Leaving.]
[04:44:38] -!-
Keknom has quit [Ping timeout: 252 seconds]
[05:04:20] -!-
Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:11:58] -!-
mhaberler has quit [Quit: mhaberler]
[05:16:24] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[05:16:54] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[05:48:47] -!-
mhaberler has quit [Quit: mhaberler]
[05:54:33] -!-
toastydeath has quit [Read error: Connection timed out]
[06:01:43] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[06:26:41] -!-
Keknom1 has quit [Quit: Leaving.]
[06:52:22] -!-
maximilian_h [maximilian_h!~bonsai@80.30.33.89] has joined #linuxcnc-devel
[06:52:22] -!-
maximilian_h has quit [Client Quit]
[07:02:41] -!-
capricorn_1 has quit [Quit: Konversation terminated!]
[07:30:08] -!-
mk0 has quit [Ping timeout: 256 seconds]
[07:34:43] -!-
toastydeath has quit [Read error: Connection timed out]
[07:37:05] -!-
bassogigas has quit [Ping timeout: 260 seconds]
[07:40:42] -!-
freespace has quit [Read error: Operation timed out]
[07:45:18] -!-
rob_h [rob_h!~rob_h@027b8b48.bb.sky.com] has joined #linuxcnc-devel
[07:52:11] -!-
jd896 has quit [Remote host closed the connection]
[08:07:45] -!-
GeorgeH has quit [Quit: Leaving]
[08:46:32] -!-
jthornton has quit [Read error: Connection reset by peer]
[08:46:33] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[08:46:46] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[08:47:07] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[08:58:43] -!-
jd896_fabshop has quit [Remote host closed the connection]
[09:20:51] -!-
Valen has quit [Quit: Leaving.]
[09:26:12] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:52:11] -!-
pjm__ has quit [Read error: Connection reset by peer]
[10:02:02] -!-
toastydeath has quit [Ping timeout: 246 seconds]
[10:03:05] -!-
robin_sz has quit [Ping timeout: 246 seconds]
[10:03:33] -!-
micges [micges!~micges@egk250.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[10:04:05] -!-
Gast796 has quit [Client Quit]
[10:21:17] -!-
robin_sz has quit [Ping timeout: 246 seconds]
[10:45:38] -!-
robin_sz has quit [Read error: No route to host]
[11:13:36] <CIA-123> 03jthornton 07v2.5_branch * r0803b3b5d57b 10/docs/src/gcode/o-code.txt: Docs: improve do while example to provide feedback when ran.
[11:22:11] -!-
RussianKid has quit [Quit: Leaving.]
[11:25:35] -!-
RussianKid has quit [Read error: Connection reset by peer]
[11:27:48] -!-
RussianKid has quit [Remote host closed the connection]
[11:42:46] -!-
rob_h has quit [Read error: Connection reset by peer]
[11:42:55] -!-
rob_h [rob_h!~rob_h@027b8b48.bb.sky.com] has joined #linuxcnc-devel
[11:47:46] -!-
mhaberler has quit [Quit: mhaberler]
[11:58:55] -!-
rob_h has quit [Quit: Leaving]
[12:12:56] -!-
robin_sz has quit [Ping timeout: 246 seconds]
[12:19:32] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[12:32:35] cylly2 is now known as
Loetmichel
[14:20:45] -!-
adb has quit [Ping timeout: 260 seconds]
[14:27:54] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[14:29:10] -!-
psha[work] has quit [Quit: Lost terminal]
[14:41:23] -!-
BenceKovi [BenceKovi!~BenceKovi@C2B0E429.dialup.pool.telekom.hu] has joined #linuxcnc-devel
[14:49:44] -!-
BenceKovi has quit [Ping timeout: 246 seconds]
[14:58:34] -!-
Valen has quit [Quit: Leaving.]
[15:07:40] -!-
mk0 has quit [Read error: Connection reset by peer]
[15:09:42] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[15:16:15] -!-
micges has quit [Quit: Leaving]
[15:40:59] -!-
BenceKovi [BenceKovi!~BenceKovi@152.66.24.32] has joined #linuxcnc-devel
[15:52:02] -!-
jd896_fabshop has quit [Remote host closed the connection]
[16:02:56] -!-
rakija has quit [Quit: Leaving]
[16:23:53] -!-
kb8wmc has quit [Ping timeout: 246 seconds]
[17:16:48] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[17:16:54] -!-
skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[17:27:58] -!-
KimK has quit [Ping timeout: 245 seconds]
[17:34:03] -!-
KimK [KimK!~Kim__@209.248.147.2.nw.nuvox.net] has joined #linuxcnc-devel
[17:36:13] -!-
IchGuckLive [IchGuckLive!~chatzilla@95-89-236-191-dynip.superkabel.de] has joined #linuxcnc-devel
[17:36:15] -!-
vladimirek has quit [Remote host closed the connection]
[17:36:41] <IchGuckLive> THanks jeppler for the anwering the issue with branch and master
[17:37:27] <IchGuckLive> jepler: are ypou astronoic interest
[17:45:03] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[17:49:26] -!-
adb [adb!~adb@178-211-226-40.dhcp.voenergies.net] has joined #linuxcnc-devel
[17:59:32] -!-
Rogge [Rogge!~IceChat77@mail.tormach.com] has joined #linuxcnc-devel
[18:15:03] -!-
mhaberler_ [mhaberler_!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[18:15:52] <mhaberler_> andyough: I fear the HAL scheme to convey #5220 wont fly
[18:16:25] -!-
mhaberler has quit [Ping timeout: 260 seconds]
[18:16:25] mhaberler_ is now known as
mhaberler
[18:18:07] <Rogge> mhaberler: I briefly thought that the G5x command was a queue buster, and that the scheme would work because the interpreter wouldn
[18:18:16] <Rogge> t read past the G5x command.
[18:18:24] <Rogge> But I was wrong :(
[18:18:27] <mhaberler> no, it never hits motion
[18:18:58] <Rogge> I've been working on displaying F, S words, and G94/95/96/97 status, and I keep running into the same problem.
[18:19:10] <Rogge> The last F or S word read before a tool change is the one thats
[18:19:11] <cradek> what's the goal?
[18:19:14] <Rogge> displayed.
[18:19:17] <mhaberler> but in theory there is value in conveying g92,g
[18:19:21] <mhaberler> oops
[18:19:33] <mhaberler> cradek: read 'Work coordinates' thread on users
[18:19:49] <cradek> I did but didn't understand the goal
[18:20:06] <Rogge> I didn't understand why he wanted to display offsets either...
[18:20:09] <cradek> the dro has this stuff already
[18:20:35] <andypugh> mhaberler: Which version?
[18:20:38] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 12.0/20120423130206]]
[18:20:39] <mhaberler> in principle I see value in passing g92,g5x,tool offsets down the pipe from interp to canon to motin because its a required step for late binding (but these are other reasons than stated in the threed)
[18:21:35] <andypugh> cradek: Yes, good point, it's all in the DRO tab isn't it?
[18:21:49] <mhaberler> andy - what do you mean? your idea of passing #5220 via HAL will convey the readahead time value, not the exec time value
[18:21:49] <andypugh> Perhaps somebody should mention that.
[18:21:51] <cradek> well that's why I'm asking what the goal is
[18:22:01] <mhaberler> ;)
[18:22:37] -!-
norias has quit [Client Quit]
[18:22:41] <andypugh> MDI_COMMANDS only work with the interpreter idle, and my understanding is that that is when he wants to see the valiues.
[18:22:55] <mhaberler> yes, that is severly restricted
[18:23:17] <andypugh> I thought he wanted to see the values when touching off.
[18:23:49] <andypugh> I do wish that folk would tell us their problem, not ask for details about their half-assed solution though.
[18:23:59] <cradek> you and me both
[18:24:18] <cradek> the dro tab does show the active system and all active offsets
[18:24:31] <Rogge> How about the active g codes string? That
[18:24:44] <Rogge> s looking at commands in interpreter time
[18:24:55] <Rogge> but should be reporting them in machine time, no?
[18:25:05] <cradek> yes that's not useful during an auto run
[18:25:14] <cradek> it's kind of useful during mdi though
[18:25:58] <Rogge> It would be nice to have during auto run for folks without true feedback from the spindle (S word display, that is...)
[18:26:24] <cradek> I don't understand what it has to do with spindle feedback - can you elaborate
[18:26:44] <Rogge> Sure - Let's say I'm running code and I want to know how fast the spindle is turning.
[18:26:49] <alex4nder> hey
[18:26:52] <mhaberler> actually, let me correct that 'in principle I see value..'. In the VPT discussion we emerged with only tooloffset and diameter etc for late binding/passed down the pipe
[18:26:58] <Rogge> Of course if I wrote the code, I should know (if I remember what I programmed
[18:27:22] <Rogge> If I've got an encoder, I just display the actual speed (motion.spindle-speed or such)
[18:27:24] <cradek> the active gcode could only tell you the commanded S word
[18:27:34] <mhaberler> where do you want to know it? in Gcode? hal has it
[18:27:34] <cradek> you could just as easily show the spindle command in hal
[18:27:36] <Rogge> Which would be great
[18:27:43] <cradek> so I still don't understand what you want
[18:27:46] <Rogge> True....
[18:27:55] <Rogge> The spindle velocity command could be shown fom hal
[18:27:59] -!-
sumpfralle has quit [Ping timeout: 244 seconds]
[18:28:03] <cradek> sure
[18:28:05] <Rogge> But then it's zero when the spindles not running
[18:28:17] <mhaberler> whats wrong with that?
[18:28:30] <Rogge> So let's say I want to know what the spindle will run at if I issue an M3...
[18:29:00] <mhaberler> In gcode or hal?
[18:29:04] <Rogge> g code.
[18:29:16] <Rogge> mdi
[18:29:24] <mhaberler> you can get the hal pin back into gcode with m66
[18:29:42] <Rogge> ?
[18:29:54] <Rogge> the hal pin will be 0 on m5
[18:30:13] <mhaberler> link the hal pin you want to observe to motion.analog-input-xx and look at M6X
[18:30:14] <alex4nder> ok, who is taking patches for axis these days?
[18:30:39] <mhaberler> alex4nder: I think your jog-fix is in
[18:31:15] <mhaberler> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=9dd36f96d9de7b398993ae37dda95546b8113b11
[18:31:39] <mhaberler> filing the bug worked wonders, toldya;)
[18:31:53] <Rogge> It seems like a bug to me that the active g codes string will read S0, but writing an M3 at the MDI line will start the spindle at the last commanded spindle speed.
[18:32:16] <cradek> oh is that what you're talking about
[18:32:46] <mhaberler> hm, we might have a volunteer her to clean up spindle handling...
[18:32:46] <Rogge> In principle, I'd just like a way to display the current S command.
[18:32:53] -!-
micges [micges!~micges@egk250.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:33:15] <Rogge> I've submitted a couple of patches recently, but not gotten any comment on them....
[18:33:20] <cradek> I agree that sounds like a bug, but I had no clue that's what you meant
[18:33:23] <alex4nder> mhaberler: it's too bad it got fixed like that.
[18:33:49] <cradek> Rogge: that sucks. where are they?
[18:34:16] <Rogge> One changes the display width of the active g codes string in axis so that the S word is visible
[18:34:25] <mhaberler> you mean jog? I did look at the commit details, whats wrong with them?
[18:34:32] <Rogge> It's always been there, just hidden because the string was too long for the box
[18:34:52] <Rogge> The other was a change in the way settings[2] is stuffed (spindle s command)
[18:34:53] <cradek> aha
[18:35:08] <Rogge> That second one I jsut emailed to the dev list, not on the source forge tracker.
[18:35:15] <Rogge> It was pretty long winded though....
[18:35:36] <cradek> ok I do see that one on the list
[18:37:01] <Rogge> I've only had a few weeks of looking at the code here, while teaching myself python, so I'm not too confident in the changes I'm suggesting :)
[18:37:12] <mhaberler> that emccanon patch looks 'more correct' to me
[18:37:36] <Rogge> I was a little freaked out that the G96 patch I submitted a month or so ago got accepted so quickly!
[18:37:41] <JT-Shop> it would be great to have 3 lines on the current codes and lose one from history instead of going wider
[18:38:13] <Rogge> I tried that, but the S value is the only one on the third line.
[18:38:24] <cradek> I'll push it shortly
[18:38:34] <Rogge> cradek: THanks!
[18:39:13] <Rogge> As long as we're talking changes, any thoughts on different tool change call outs for lathe?
[18:39:26] <alex4nder> mhaberler: what branch is that commit on?
[18:39:27] <Rogge> I'd work on that development if I thought people would be receptive to it.
[18:39:38] <mhaberler> v2.5_branch
[18:39:43] <cradek> the only change I'm making is to add a summary line and word-wrap the commit message
[18:40:13] <alex4nder> mhaberler: yah.. so it's not on master, doesn't reference my bug report, and my bug report is still open. ;)
[18:40:14] <Rogge> ah
[18:40:18] <alex4nder> and it's not on master
[18:40:24] <alex4nder> (again)
[18:40:35] <mhaberler> ok, that will be rolled forward shortly, or you can do it yourself
[18:41:04] <alex4nder> I already fixed the problem in my own tree. ;)
[18:41:04] <cradek> I'm merging up
[18:41:44] <mhaberler> great
[18:42:33] <CIA-123> 03cradek 07v2.4_branch * rb6b2c6343a70 10/src/emc/task/emccanon.cc: Fix incorrect spindle speed command in active codes
[18:42:41] <CIA-123> 03cradek 07v2.5_branch * r51fcd96e33d3 10/src/emc/task/emccanon.cc: Merge branch 'v2.4_branch' into v2.5_branch
[18:42:46] <CIA-123> 03cradek 07master * r48f284781632 10/ (3 files in 3 dirs): Merge branch 'v2.5_branch'
[18:44:47] <Rogge> A while back there was some discussion on tool change commands and wear offsets in lathe on the developer's list.
[18:45:20] <Rogge> My proposal was to do away with M6/G43 in lathe, to match the Fanuc standard.
[18:45:36] <Rogge> I'm working on a g code remap to do what I want (thanks for that work, Michael!)
[18:45:57] <Rogge> But I'd be happier making the changes in the source if people were interested in the development.
[18:45:57] <cradek> I suppose some day we'll probably want a lathe-specific interpreter for mostly this reason
[18:46:16] <Rogge> You don't think it could be done via a flag in the INI?
[18:46:21] <Rogge> Same interpreter>
[18:46:50] <cradek> well sure it could
[18:47:02] <cradek> and same for the next lathe change and the one after that
[18:48:18] <cradek> well if you want to add fields (wear offsets) to the tool table it's a whole other mess
[18:48:37] <Rogge> With lathe, you could easily hijack u/w offsets in the tool table.
[18:48:53] -!-
vladimirek has quit [Remote host closed the connection]
[18:49:30] <cradek> no, because a lathe can certainly have a w axis (think tailstock or second turret)
[18:49:38] <Rogge> hmmm....
[18:49:53] <cradek> I'm positive some folks already use it that way
[18:50:44] <cradek> and why would you want to make wear offsets lathe-only
[18:51:17] <Rogge> Well, in lathe you can apply the wear offset from one tool to the geometry offset for another one.
[18:52:18] <Rogge> So in mill it's easy to tweak the geometry offset
[18:53:29] <Rogge> But in lathe you really need two separate fields.
[18:53:51] <cradek> I wonder if you should sketch up a little proposal that says how it should all work when you're done
[18:54:23] <Rogge> I sent somthing similar to the dev list
[18:54:25] <cradek> I feel like you shouldn't just start coding here - it's too big and invasive to do without some kind of plan (that mhaberler and others can look at)
[18:54:35] <Rogge> I'm 100% with you there!!
[18:55:30] <Rogge> Plus I understand mhaberler has interpreter changes planned in the coming months
[18:55:59] <mhaberler> uhum, we were discussing at the thought experiment level
[18:56:22] <Rogge> Ah...
[18:56:54] <cradek> ok I can see how Txxxx could work - we'd have to figure out how/where to store the secondary offsets, and how the user manipulates them
[18:57:23] <cradek> changing Txxxx to do what TxxM6G43 does is not particularly hard
[18:58:14] <mhaberler> Rogge: can you post a link to that email?
[18:58:30] <cradek> it's one of three he's sent, not hard to find
[18:58:42] <Rogge> I'm working on doing it in remapping the T code now... but I'd prefer to make these changes in the interpreter.
[18:59:00] <Rogge> I've been watching for a while, only started yapping recently!
[19:01:02] -!-
uw has quit [Quit: Ex-Chat]
[19:01:04] <mhaberler> yeah, remapping is a nice way to try a change before committing it to c
[19:01:24] <mhaberler> which tells me the Python integration wasnt radical enough ;)
[19:01:24] <Rogge> https://sourceforge.net/mailarchive/forum.php?thread_name=CAN1%2BYZVXzgwFzcxCgj%2BnGQpwpSXr7%2Bvwa38biw2nAexYm29w2g%40mail.gmail.com&forum_name=emc-developers
[19:03:16] <Rogge> cradek: I'll come up with more specific plans in the next few days.
[19:03:26] <Rogge> Changing the tool table does sound like a can of worms
[19:03:33] <mhaberler> re T01xx : due to the parse you wont retain the leading zero, it's going into t_number (int)
[19:03:52] <Rogge> Yep - noticed that one already...
[19:03:57] <mhaberler> aja
[19:04:13] <cradek> yes dependence on leading zero is going to be a problem
[19:04:26] <mhaberler> another word maybe to select the register
[19:04:48] <cradek> max tool number of 99 is also a new restriction with this system
[19:05:27] <Rogge> The standard (according to Peter Smit) is that T1 and T01 both change tools to T1, apply geom offsets to tool 1
[19:05:50] <Rogge> T101 and T0101 change to tool 1, apply both geo and wera offsets for tool one.
[19:06:08] <cradek> oh then maybe it doesn't matter
[19:06:09] <mhaberler> well in a remap handler you can access the original string so you could still fish it out there
[19:06:30] <cradek> you just use T/100 and T%100
[19:07:06] <cradek> ... and struggle to write the documentation that explains that
[19:07:27] <Rogge> nice to see people concerned with the documentation!
[19:10:55] <cradek> so I think you're saying that if T>100 you change to tool T/100 and apply offsets T/100 + T%100; otherwise change to tool T and apply offset T
[19:11:20] <Rogge> correct.
[19:11:37] -!-
Loetmichel has quit [Ping timeout: 265 seconds]
[19:11:38] <mhaberler> I assume wear registers are keyed to tools (aka tool attributes) or are they bona-fide objects?
[19:12:39] <Rogge> They are conventionally used with the matching tool (e.g. T0606), but do not have to be used with the matching tool.
[19:14:28] cylly2 is now known as
Loetmichel
[19:15:43] <andypugh> I would prefer to see the whole tool-table as it exists scrapped, and replaced with a database of arbitrary size. Then you could have mutliple tools in the same pocket (gang tooling) or multiple pockets with the same tool (err, actually, that makes no sense :-)
[19:15:46] <Rogge> I'll post a link to my old HAAS screen....
[19:16:52] <andypugh> Rogge: You can apply the "wrong" offsets currently with the H word. I don't see any real advantage (for me) of having two different ways to work the tool table on my single machine. (which is a combo lathemill)
[19:17:18] <Rogge> http://static.inky.ws/image/2140/image.jpg
[19:17:35] <Rogge> http://static.inky.ws/image/2141/image.jpg
[19:19:28] <Rogge> andypugh: the wear offset being applied seperately from the geometry offset allows you to hit tight tolerances on a part that has two different diameters with two different tolerances.
[19:19:42] <mhaberler> I hate to suggest this but you might be able to cludge the wear offset into a pseudo tool.
[19:20:26] <Rogge> With my remap scheme I'm going to kludge the wear offset into the u and w fields.
[19:20:44] <mhaberler> actually I'm just weaseling around redoing the tooltable code in the current interp structure;)
[19:20:47] <Rogge> But as cradek suggests, that won't work for a change to the interpreter
[19:23:29] <Rogge> If we want to be picky, there should also be a wear value for the lathe tool radius.
[19:23:46] <Rogge> I suspect that value is used on 0.01% of controls.
[19:24:36] <andypugh> The idea is that the geometric offset is never changed for any one holder/tip, but that you tweak the wear offset on the basis of part inspection?
[19:25:05] <Rogge> andypugh: yes. Also, you can use two different wear values on the same tool during the same part.
[19:25:34] <andypugh> Rogge: You would also want a radius wear eccentricuty value, to allow for uneven changes in radius...
[19:25:53] <Rogge> So if I've got two diameters, diameter1 is 3.000 -0 +.002, and diameter 2 is 2.000 -.002 +0, I can hit both tolerances.
[19:26:18] <andypugh> Ah, OK, you just explained the question I was going to ask.
[19:26:44] <Rogge> andypugh: I agree that the radius wear is a bit much, but it is a Fanuc/Haas/etc. standard.
[19:27:17] <Rogge> AFAIK, the M6/G43 is only used for lathe by LCNC and one other PC based control
[19:27:55] <andypugh> And reminded me of the machinist who simply set all positions to mid-tolerance and ruined a part I designed on the last op. (I had a 0.01 toperance on a flexure web thickness, and a 1mm tolerance on the position of the adjacent slot which created it)
[19:28:15] <mhaberler> cradek: do you see a fundamental issue with moving tool offsetting to motion in the current setup (not vpt) besides machine limit checks?
[19:29:47] <mhaberler> I'm not talking 'table I/O', just offsetting
[19:30:11] <Rogge> mhaberler: changes to Txxxx wouldn't require that, right? Why the suggestion?
[19:30:47] <mhaberler> has nothing to do with Rogge's idea; it's about cleaning up tt handling
[19:31:03] <Rogge> ah.
[19:32:04] <mhaberler> I'm considering stopping weaseling, the vpt stuff is far out
[19:32:20] <Rogge> mhaberler: what is vpt?
[19:32:30] <mhaberler> a design idea
[19:33:10] <Rogge> involving your recent ideas about flagging a 'dirty' queue?
[19:33:56] <mhaberler> http://psha.org.ru/irc/%23emc-devel/2012-04-24.html
[19:33:57] <mhaberler> http://psha.org.ru/irc/%23emc-devel/2012-04-26.html
[19:33:58] <mhaberler> http://psha.org.ru/irc/%23emc-devel/2012-04-27.html
[19:34:13] <Rogge> thanks
[19:34:51] <mhaberler> no, make tool offsets and CRC late bound, in/around motion; and make motion work off parsed ngc blocks
[19:35:36] <mhaberler> the tainted state stuff is necessarily part of it since interp will be sliced into read() and execute() parts
[19:37:48] <mhaberler> (actually the tainted state stuff revealed the queue isnt the issue, it is state references)
[19:43:43] <Rogge> must run and finish some work.
[19:44:01] <Rogge> Thank you for considering some of these things!
[19:44:37] <Rogge> I'll work up a more specific idea of changes related to Txxxx handling in the interpreter in the coming week.
[19:45:35] -!-
Rogge has quit [Quit: Take my advice. I don't use it anyway]
[19:56:31] -!-
psha has quit [Quit: Lost terminal]
[20:00:44] -!-
_abc_ has quit [Quit: leaving]
[20:09:28] <CIA-123> 03micges 07hm2-refactor * rc9c074bda021 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: hostmot2: cleanup main source file, remove unused heade file, no functional changes
[20:09:28] <CIA-123> 03micges 07hm2-refactor * r2aa07c31273f 10/src/hal/drivers/mesa-hostmot2/pins.c: Print proper value when error
[20:09:30] <CIA-123> 03micges 07hm2-refactor * r49cbb6279e46 10/src/ (5 files in 2 dirs): Extract module descriptors management into sepearate file
[20:09:40] <CIA-123> 03micges 07hm2-refactor * rb8b5a85e6e2e 10/src/hal/drivers/mesa-hostmot2/ (hostmot2.c hostmot2.h led.c led.h modules.c modules.h): modularity skeleton added to hostmot2 driver
[20:09:40] <CIA-123> 03micges 07hm2-refactor * r55833bc472b1 10/src/hal/drivers/mesa-hostmot2/ (led.c led.h modules.h): rename variables names to better match reality
[20:09:50] <CIA-123> 03micges 07hm2-refactor * r68921c2404e6 10/ (122 files in 38 dirs): Merge branch 'master' into hm2-refactor
[20:11:15] <micges> andypugh: take a look at this branch
[20:11:28] <andypugh> Hmm, looks interesting.
[20:11:39] <andypugh> Adding a third interface?
[20:12:19] <micges> no
[20:12:34] <micges> maybe if I got enough time
[20:12:52] -!-
bedah has quit [Quit: bye]
[20:13:44] <micges> this branch is base for improving stepgens and encoders
[20:14:00] <andypugh> Ah, OK.
[20:15:37] <andypugh> You started with LED because it is the most trivial?
[20:18:18] <micges> yes
[20:19:16] <andypugh> I am confused that I only see some of those patches in git.linuxcnc
[20:19:57] <andypugh> Ah, no, wait, I needed to look further into the past
[20:21:50] <andypugh> I see UART being fun with your structure, as that gets run twice as the RX and TX functions have different GTAGs
[20:38:04] -!-
skunkworks__ has quit [Ping timeout: 244 seconds]
[20:41:12] -!-
syyl_ws has quit [Quit: Verlassend]
[20:45:22] -!-
i_tarzan has quit [Ping timeout: 260 seconds]
[20:49:15] -!-
djdelorie has quit [Quit: Leaving]
[20:54:21] <micges> yes your last modules will be tricky
[20:55:35] -!-
DJ9DJ has quit [Quit: bye]
[21:02:30] -!-
mhaberler has quit [Quit: mhaberler]
[21:11:49] -!-
theorbtwo has quit [Ping timeout: 248 seconds]
[21:11:52] theorb is now known as
theorbtwo
[21:12:23] -!-
rob_h [rob_h!~rob_h@027b8b48.bb.sky.com] has joined #linuxcnc-devel
[21:19:49] <andypugh> I guess there is nothing stopping them "opting out" of the bits of the rationalisation that are inappropriate.
[21:40:46] -!-
jd896 has quit [Read error: Connection reset by peer]
[21:43:12] -!-
pfred1 has quit [Quit: Lost terminal]
[21:59:18] -!-
BenceKovi has quit [Read error: Connection reset by peer]
[22:17:10] -!-
Guthur has quit [Remote host closed the connection]
[22:24:19] -!-
tronwizard has quit []
[22:40:26] -!-
dimas has quit [Ping timeout: 252 seconds]
[22:41:42] -!-
jd896 has quit [Remote host closed the connection]
[22:44:00] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:20:24] -!-
micges has quit [Quit: Leaving]
[23:20:49] -!-
Keknom has quit [Client Quit]
[23:22:28] -!-
frallzor has quit []
[23:35:34] -!-
rob_h has quit [Ping timeout: 245 seconds]
[23:48:50] -!-
norias has quit [Ping timeout: 244 seconds]
