#emc-devel | Logs for 2011-01-01

Back
[00:04:09] -!- theorbtwo has quit [Ping timeout: 240 seconds]
[00:04:13] theorb is now known as theorbtwo
[00:46:28] -!- [n0b0dy] has quit []
[00:56:15] -!- skunkworks has quit [Ping timeout: 255 seconds]
[01:00:52] MarkPictor-away is now known as MarkPictor
[01:40:58] -!- KimK [[email protected]] has parted #emc-devel
[01:59:54] -!- robh__ has quit [Ping timeout: 250 seconds]
[02:23:11] <CIA-60> EMC: 03jepler 07master * r0b113e98a162 10/src/hal/components/gearchange.comp: gearchange: support up to 32 gears
[02:23:55] <dgarr> jepler: this: def inifindall(section, item): return tuple(inifile.findall(section, item)) -- breaks on hardy with tcl8.4
[02:24:05] <dgarr> could you consider something more like the original: http://www.panix.com/~dgarrett/stuff/0001-axis-make-inifindall-compatible-with-tcl8.4-tcl8.5.patch
[02:24:26] <dgarr> and happy new year too
[02:28:39] <jepler> dgarr: argh, that's too bad
[02:29:15] <dgarr> yes :'(
[02:29:29] <jepler> dgarr: there's got to be a formulation that is both right, and works on all the platforms we care about
[02:29:54] <jepler> you probably don't care, but consider [ARGH]GRUMBLE=} and how that'll not yield a proper Tcl list
[02:30:54] -!- Connor has quit [Quit: Leaving.]
[02:32:13] <dgarr> i don't understand what you're saying
[02:32:49] <jepler> if the inifile's value has braces in it, your string-concatenation-based approach won't give a proper tcl list
[02:32:54] <jepler> you'll get {}}
[02:33:29] <jepler> % set l "{}}"
[02:33:29] <jepler> {}}
[02:33:29] <jepler> % lindex $l 0
[02:33:29] <jepler> list element in braces followed by "}" instead of space
[02:34:59] <dgarr> yeah, i probably wouldn't care about those cases, i'm open to suggestions, is everything in master supposed to work on hardy?
[02:36:06] -!- MarkPictor has quit [Remote host closed the connection]
[02:36:43] <jepler> no, I don't care much about hardy. it's anticipated that hardy will be out of (ubuntu/canonical) support by the time 2.5 is released.
[02:37:27] <jepler> on the other hand, if the fix is not hard and particularly if somebody contributes it we wouldn't turn it down
[02:37:56] <jepler> if it's a choice between correct or works-on-hardy, though, I'm reluctant to take the patch
[02:39:04] <dgarr> by "fix" -- i'm not sure what (tcl/tkinter/python/inifindall) is the appropriate thing to be fixed -- do you have an opinion?
[02:41:17] <jepler> inifindall will have to be changed, I'm just not sure how
[02:41:55] <jepler> tkinter (no matter what version of python) has the proper stuff to turn a python tuple into a tcl list
[02:42:04] <jepler> apparently older versions don't do it on "return"
[02:43:21] <jepler> but I am not at a system where I can test stuff right now to find the right thing
[02:43:26] <jepler> please ping me again if you don't see any action in a week
[02:43:38] <dgarr> ok, thanks for looking at it
[02:43:56] <dgarr> are there other things in master that are known not to work on hardy?
[02:44:45] <jepler> the documentation doesn't build (beacuse some files are edited with lyx newer than 8.04 accepts), so deb packages aren't buildable
[02:45:03] <jepler> that's the only one I remember offhand. For everything but building a package, people still tend to pop up pretty quick when these things get in
[02:45:16] <jepler> at least if it's in a part of the software they exercise
[02:50:34] <jepler> 0~bbl
[02:51:51] <dgarr> thanks
[03:15:59] -!- Vq has quit [Ping timeout: 260 seconds]
[03:17:16] -!- SWPadnos has quit [Changing host]
[03:17:16] -!- SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #emc-devel
[03:17:35] -!- rob_melb has quit [Remote host closed the connection]
[03:37:47] <jepler> dgarr: please try http://emergent.unpy.net/files/sandbox/0001-axis-fix-a-python2.5-compatiblity-issue.patch
[03:38:06] -!- Valen has quit [Quit: Leaving.]
[04:27:22] <dgarr> a result for lucid: http://www.panix.com/~dgarrett/stuff/tuple.txt
[04:27:52] <dgarr> i will try to test on hardy tomorrow and report but the lucid result seems wrong to me
[04:51:46] -!- qq- has quit [Ping timeout: 276 seconds]
[04:55:19] -!- nullie has quit [Quit: Ex-Chat]
[05:12:21] -!- LawrenceG has quit [Remote host closed the connection]
[05:12:46] -!- LawrenceG [[email protected]] has joined #emc-devel
[05:55:47] -!- toastydeath has quit [Ping timeout: 240 seconds]
[07:35:05] Connor2 is now known as Connor_CNC
[07:41:44] -!- mhaberler [[email protected]] has joined #emc-devel
[07:45:58] -!- dgarr has quit [Ping timeout: 276 seconds]
[08:52:09] -!- psha [[email protected]] has joined #emc-devel
[09:06:38] -!- psha has quit [Read error: Connection reset by peer]
[09:13:04] -!- psha [[email protected]] has joined #emc-devel
[09:19:11] -!- psha has quit [Read error: Connection reset by peer]
[09:19:38] -!- psha [[email protected]] has joined #emc-devel
[09:35:53] -!- psha has quit [Read error: Connection reset by peer]
[09:36:13] -!- psha [[email protected]] has joined #emc-devel
[09:37:44] <mhaberler> psha: happy new year!
[09:38:15] -!- psha has quit [Read error: Connection reset by peer]
[09:41:17] -!- psha [[email protected]] has joined #emc-devel
[09:42:06] -!- psha has quit [Read error: Connection reset by peer]
[09:46:38] -!- psha [[email protected]] has joined #emc-devel
[09:49:39] -!- psha has quit [Read error: Connection reset by peer]
[10:00:31] -!- psha [[email protected]] has joined #emc-devel
[10:11:08] Vq_ is now known as Vq
[11:13:33] -!- robh__ [[email protected]] has joined #emc-devel
[11:19:48] <mhaberler> psha: I dont understand what rs274_pre.cc if (_setup.line_length != 0) { (line 299) is supposed to mean
[11:19:50] <mhaberler> the g-code is parsed twice?
[11:20:54] <psha> why twice
[11:21:00] <psha> it's parsed once
[11:21:05] <mhaberler> no
[11:21:06] <psha> empty lines are not parsed at all
[11:21:47] <psha> hm, incorrect
[11:21:53] <psha> it's parsed once and not executed if empty
[11:22:06] <mhaberler> during task plan open, it goes through the whole ngc file
[11:22:08] <mhaberler> then while executing an M6, it calls emcTaskPlanCommand(m6)
[11:22:24] <mhaberler> which again calls the interpreter
[11:23:56] <psha> going trought whole file is needed to ensure that it's correct
[11:27:48] -!- Valen has quit [Quit: Leaving.]
[11:31:19] <psha> don't see where is emcTaskPlanCommand(m6)
[11:31:34] <psha> emctaskmain.cc:543
[11:31:35] <psha> ?
[11:31:37] <mhaberler> turn debugging on
[11:32:37] <mhaberler> I need to run this under gdb to see where it's coming from
[11:33:48] <psha> heh, trace code calls ;)
[11:35:02] <psha> rcs_print("emcTaskPlanCommand(%s) called. (line_number=%d)\n",
[11:35:06] <psha> this message?
[11:35:14] <mhaberler> yes
[11:36:10] <psha> from emctaskmain.
[11:37:41] <psha> it's rescheduling interp i think
[11:38:00] <mhaberler> what does rescheduling mean?
[11:38:52] <psha> see what's happening
[11:39:04] <psha> emctaskmain reads file and sends commands to interp
[11:39:12] <psha> for some commands it get FINISH status
[11:39:29] <psha> then it waits for sync with interp and then continue to send commands
[11:44:25] <mhaberler> I must say I'm fairly confused who does what here and in which order
[11:52:36] <psha> it's not obvious at first but pretty isolated in readahead_* functions
[11:58:25] <mhaberler> ok, now lets assume M6 calls an osub which I defined in the inifile
[11:59:38] <mhaberler> I have that in place. in Interp::convert_m; I detect that in the right place (where I'd like to call the oword sub)
[12:00:02] <mhaberler> how do I disttniguish there it's the syntax check vs the real thing?
[12:00:37] <mhaberler> I shouldnt call the sub during the check I guess..
[12:02:06] <mhaberler> oh I see, its just queued there
[12:04:57] <mhaberler> I would need to parse the M6_COMMAND during setup so the sub is defined, and call it at the right place
[12:05:15] <psha> probably
[12:20:50] <mhaberler> One thing I'm positive: the command in rs274ngc_pre.cc line 224 is bogus. During program run its called with command == NULL , MDImode is inited to 0, so line 224 is BS
[12:30:37] -!- qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[12:55:50] <mhaberler> psha: where would you do the M6_COMMAND parse - in rs274ngc_pre.cc or in emctaskmain.cc?
[12:59:54] -!- qq- has quit [Ping timeout: 246 seconds]
[13:01:10] <psha> M6_COMMAND = O-name
[13:01:22] <psha> so parse is not needed
[13:02:18] <mhaberler> ok.. I'll beleive you
[13:02:25] -!- qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[13:04:42] <mhaberler> I had thought I'll put a gcode line there, not just an O-name
[13:05:14] <mhaberler> but ok, fine
[13:16:21] -!- JT-Shop has quit [Remote host closed the connection]
[13:19:03] <psha> heh, if you may do TC with one G0 command - then it's ok :)
[13:19:13] <psha> but M1xx commands may be used too
[13:19:15] -!- JT-Shop [[email protected]] has joined #emc-devel
[13:19:30] -!- awallin has quit [Quit: No Ping reply in 180 seconds.]
[13:19:34] <mhaberler> oh. Ah.
[13:19:55] -!- awallin [[email protected]] has joined #emc-devel
[13:20:00] <mhaberler> The M1xx has the whol call infrastructure setup..
[13:20:08] <psha> i think that it's no harm to allow only fixed format O-calls
[13:20:24] <psha> if you want M1xx - place it inside O-call
[13:21:26] <mhaberler> no the idea would be to use a special M1xx directly
[13:21:28] <mhaberler> if you want an ocall from there that works now
[13:21:58] <mhaberler> or does M1XX go through halui? need to check..
[13:24:18] <mhaberler> oh, darn, thats halui
[13:24:19] <psha> then allow arbitrary G-command
[13:24:52] <mhaberler> its actually easier than directly calling a sub
[13:25:39] <psha> hm, don't get it
[13:25:56] <psha> my point: allow only sub name in M6_COMMAND config var
[13:26:13] <mhaberler> well, all i need to do is read() and execute() if its g-code
[13:26:15] <psha> then cook O #tool-number #pocket-number
[13:26:18] <psha> other approach
[13:26:24] <mhaberler> exactly
[13:26:33] <psha> allow any G-code
[13:26:42] <psha> in form like one MDI action
[13:27:06] <psha> M6_COMMAND O call ${tool-number} ${pocket-number}
[13:27:13] <psha> or M101 ${tool-number} ...
[13:27:14] <mhaberler> yessir
[13:27:21] <mhaberler> recte
[13:27:31] <psha> later is a bit harder - you have to parse G-code by hand
[13:27:46] <mhaberler> ?
[13:27:47] <psha> and then feed it into interp
[13:28:00] <psha> parsing is not needed - just substitute
[13:28:10] <mhaberler> cant that crappy interp recurse?
[13:28:48] <psha> recurse? dunno
[13:28:52] <mhaberler> your tool-number and pocket-number come from where? _stup?
[13:28:57] <mhaberler> _setup?
[13:29:04] <psha> yes, where M6 command is issued
[13:29:13] <mhaberler> ok
[13:29:31] <psha> am i correct that M6 T2 P3 is to take tool 2 from pocket 3?
[13:29:38] <psha> or P is not used in m6?
[13:29:52] <mhaberler> not that I'm aware of. let me see
[13:29:57] <psha> btw halui is not involved in M1xx commands
[13:30:06] <psha> not important though
[13:30:16] <psha> at least tool-number is taken from T letter
[13:30:46] <mhaberler> ah
[13:30:48] <mhaberler> M6 - no params
[13:30:50] <mhaberler> tool number from T
[13:30:52] <mhaberler> pocket number is magic - iocontrol sucks it out of the tool table and rewrites that..
[13:30:59] <mhaberler> on random tc, that is
[13:31:52] <psha> so iocontrol takes pocket number from tooltable and issues M6_COMMAND with correct parameters
[13:32:16] <mhaberler> no, iocontrol would go under that scenario
[13:32:28] <mhaberler> replaced by oword sub
[13:32:38] <psha> and how you'll get pocket number?
[13:32:55] <mhaberler> this is a very good question
[13:33:19] <mhaberler> remember me bitiching about state in 27 corners of emc..
[13:33:50] <mhaberler> I think that has to move to task or rs274 and just drive the world
[13:33:58] <psha> heh, if you have over 9k state params it's only way to store it ;)
[13:38:41] <mhaberler> ok, the M6_command is parsed ok in Interp::convert_m properly, reads sub and all
[13:38:43] <mhaberler> now onto next step, how to call this animal..
[13:39:01] <mhaberler> and from where
[13:39:24] <mhaberler> option 1: emctaskmain where EMC_TOOL_LOAD is issued
[13:41:22] <mhaberler> actually, magically it's called in the right place..
[13:45:05] <psha> emctaskmain is proper place
[13:45:09] <psha> only proper one
[13:45:52] <psha> otherwise you have pass info there or hack into synch
[13:46:31] <psha> be back later
[13:46:32] <mhaberler> yes, its parsed and called ok but called from the wrong place
[13:46:37] <mhaberler> cu!
[13:46:40] -!- psha has quit [Quit: leaving]
[14:25:45] -!- dgarr [[email protected]] has joined #emc-devel
[14:36:11] -!- fatpandas has quit [Ping timeout: 240 seconds]
[14:52:17] <alex_joni> mhaberler: hi
[14:52:24] <mhaberler> hi alex!
[14:52:29] <alex_joni> I didn't quite follow closely on your toolchange changes
[14:52:36] <alex_joni> are you clear now how it used to work?
[14:53:02] <alex_joni> I mean T and M6 ?
[14:53:06] <mhaberler> semi. Could you look at me question on -devel mailing list ? from today
[14:53:18] <mhaberler> the prepare is fuzzy
[14:53:21] <alex_joni> I see 2
[14:53:24] <alex_joni> questions ..
[14:53:35] <mhaberler> the first one
[14:53:42] <alex_joni> ok, then let me try to explain how it's supposed to work first, and then we'll look at the email
[14:54:00] <alex_joni> T5 by itself will make emc2 prepare the tool 5
[14:54:01] <mhaberler> it is a very specific question and will take less of your time
[14:54:07] <mhaberler> I know all that
[14:54:09] <alex_joni> ok
[14:54:45] <alex_joni> I just read it.. you are incorrect
[14:54:54] <mhaberler> so what's correct then
[14:55:14] <alex_joni> tool-prepare (output from iocontrol) tells the toolchanger (or ladder or whatever in HAL) that it should fetch a certain tool number
[14:55:23] <alex_joni> fetch means start preparing it (not actually changing the tool)
[14:55:41] <alex_joni> I think the best example is samco's machine
[14:55:45] <mhaberler> yes. I asked about the -prepared
[14:56:47] <alex_joni> http://www.youtube.com/watch?v=KplU8hkI0AQ
[14:56:59] <alex_joni> ok.. so prepare tells the toolchanger to do it's thing
[14:57:03] <mhaberler> the question is: does tool-prepared mean: 'toolchanger started to rattle' or does it mean 'toolchanger in position'?
[14:57:16] <SWPadnos> it means "the tool has been changed"
[14:57:18] <alex_joni> in position
[14:57:22] <alex_joni> SWPadnos: nope
[14:57:26] <mhaberler> No
[14:57:28] <alex_joni> that's tool-changed
[14:57:29] <SWPadnos> err, right
[14:57:31] <SWPadnos> more coffee :)
[14:57:41] <alex_joni> tool-prepared means the toolchanger stopped to rattle
[14:57:51] <alex_joni> and it is in a position where the tool could be changed
[14:58:03] <mhaberler> so how does it have any chance to run in parallel with G-code?
[14:58:06] <alex_joni> (that doesn't mean the spindle is in position, or that the tool can be changed)
[14:58:09] <alex_joni> well it runs
[14:58:11] <mhaberler> sure
[14:58:21] <alex_joni> iocontrol just sets the tool-prepare, and then carries on
[14:58:28] <alex_joni> emc2 doesn't wait on tool-prepared
[14:58:34] <mhaberler> yes it does
[14:58:38] <alex_joni> the only time the tool-prepared is checked if there's a M6
[14:58:41] <alex_joni> no it doesn't
[14:58:50] <mhaberler> ok, let me try again.
[14:59:02] <alex_joni> lets imagine a simple program
[14:59:06] <alex_joni> T1 M6
[14:59:08] <alex_joni> T5
[14:59:12] <alex_joni> G1 X100
[14:59:13] <alex_joni> Y200
[14:59:15] <alex_joni> Z300
[14:59:17] <alex_joni> M6
[14:59:28] <alex_joni> ^ that's it
[14:59:43] <alex_joni> the first line will block (no other g-code will be executed)
[14:59:51] <alex_joni> so iocontrol will issue tool-prepare
[14:59:55] <mhaberler> Iam missing something here.
[15:00:05] <alex_joni> it will wait until tool-prepared is high, then issue tool-change
[15:00:14] <alex_joni> and then wait for tool-changed
[15:00:20] <alex_joni> (forget the implementation for a bit)
[15:00:31] <alex_joni> next is T5
[15:00:42] <alex_joni> iocontrol sets tool number 5, and tool-prepare
[15:00:58] <alex_joni> then (while the toolchanger fetches tool #5) emc2 will go on with g-code
[15:01:06] <alex_joni> and do the G1 X100, Y200, Z300
[15:01:23] <alex_joni> when it gets to M6 iocontrol checks to see if tool-prepared is done
[15:01:29] <alex_joni> if it's not done it waits for it
[15:01:30] <mhaberler> yes, that's all the ideal scenario.
[15:01:35] <alex_joni> that's how it works
[15:01:48] <mhaberler> let me check wether -prepared low hangs iocontrol again.
[15:01:58] <alex_joni> it's not ideal, because it makes some assumptions
[15:02:10] <alex_joni> (about the toolchanger for once)
[15:02:53] -!- fatpandas has quit [Ping timeout: 265 seconds]
[15:02:55] -!- robh__ has quit [Ping timeout: 276 seconds]
[15:05:36] <mhaberler> well, sorry. break the tool-prepare loop and issue a Tx. EMC hangs.
[15:06:40] <mhaberler> to be exact: doesnt hang, but no further execution of commands, just queued.
[15:06:53] <alex_joni> what kind of commands are there?
[15:07:02] <mhaberler> g0x100
[15:07:09] <alex_joni> hmm.. then it's broken
[15:07:16] <mhaberler> that's my point.
[15:07:21] <alex_joni> I know this used to run, and in 2.4 it surely does
[15:08:27] <mhaberler> very easy to reproduce:
[15:08:29] <mhaberler> axis.sim, full debug, in core_sim.hal comment out this line:
[15:08:30] <mhaberler> #net tool-prep-loop iocontrol.0.tool-prepare iocontrol.0.tool-prepared
[15:08:32] <mhaberler> then do a t1
[15:08:33] <SWPadnos> um, wait
[15:08:33] <mhaberler> and then a g0x100 for example
[15:08:41] <alex_joni> mhaberler: but not in MDI
[15:08:42] <SWPadnos> what do you mean by "break the tool-prepare loop"?
[15:08:45] -!- Valen has quit [Quit: Leaving.]
[15:09:07] <alex_joni> in MDI there is no parallel thingie
[15:09:10] <mhaberler> put a comment sign before the net tool-prep-loop statement
[15:09:12] <alex_joni> because of other problems
[15:09:29] <mhaberler> parallel to what?
[15:09:51] <alex_joni> I mean that: in MDI it waits for a tool-prepared before issuing other commands
[15:09:59] <alex_joni> you need to test this by loading a program
[15:10:15] <mhaberler> I dont understand what difference that should make, but ok
[15:10:33] <alex_joni> the problem with MDI is that if you do T4, then M6 in the next line it sometimes would skip the prepared phase, which was a big problem
[15:10:44] <mhaberler> aha, no acks.
[15:10:48] <alex_joni> right
[15:11:00] <mhaberler> program hangs just alike.
[15:11:02] <alex_joni> which is waaaay worse than having to wait for each line in MDI
[15:11:16] <alex_joni> well, last time I tried it .. it worked :D
[15:11:20] <alex_joni> but it was a while ago
[15:11:32] <mhaberler> I queueus NML commands, but no execution.
[15:12:58] <mhaberler> set iocontrol.0.tool-prepared to 1 in HAL manual, queue executes.
[15:13:58] <alex_joni> that's not right
[15:14:27] <mhaberler> Ok, I commit my current branch, go back to master and retry. Are you using sim?
[15:15:18] <alex_joni> not using anything atm
[15:15:26] <alex_joni> having issues regenerating a HDD :D
[15:15:34] <mhaberler> uh..
[15:16:23] <mhaberler> SWPadnos: any chance you can reproduce what I described?
[15:16:35] <SWPadnos> not that the moment
[15:16:55] <SWPadnos> I've still got ~900 emails to go through :)
[15:17:24] <alex_joni> 163 bad sectors in the first 500MB :( doesn't look promising
[15:19:03] <SWPadnos> ouch
[15:19:10] <mhaberler> it's not just queuing, Axis hangs for seconds changing modes.
[15:21:42] <mhaberler> alex_joni: oh, I misunderstood you saying 'that's not right' to mean I'm talking BS, on second read it looks like you meant 'that iocontrol behavious isnt right'
[15:21:53] <alex_joni> mhaberler: yes, that's what I mean
[15:22:04] <alex_joni> there is a bug if iocontrol/emc2 behaves like that
[15:22:05] <mhaberler> ;-)
[15:22:19] <alex_joni> (not 100% sure it's in iocontrol, could be in task too)
[15:22:48] <alex_joni> gotta take care of this HDD first though.. and it's only 170h to go :(
[15:25:05] <mhaberler> well, before we do anything about it we should decide what we want, and what that -prepare/-prepared thing is supposed to mean. The other thing is interlocking this with tool-change if needed. tool-change means 'I hope you finally are able to change tools' but it has no clue wether the prepare action completed.
[15:25:56] <mhaberler> IF prepare is supposed to run in parallel with gcode execution, and come together at -change time.
[15:25:58] <alex_joni> mhaberler: tool-change shouldn't be issued before tool-prepared isn't done
[15:26:14] <SWPadnos> ?
[15:26:35] <alex_joni> I mean tool-change should always wait for a finished prepared
[15:26:37] <mhaberler> ok, than this whole 'run in parallel' is not possible AFAICT
[15:26:39] <SWPadnos> !
[15:26:42] <SWPadnos> :)
[15:26:45] <alex_joni> why not?
[15:26:57] <alex_joni> tool-prepare is issued, then other commands are executed
[15:27:05] <SWPadnos> G-code can run while the tool changer is moving, in the current design
[15:27:12] <mhaberler> in the design
[15:27:18] <alex_joni> SWPadnos: right, that's what I said
[15:27:25] <SWPadnos> G-code can't run while the tool is being changed (which makes sense)
[15:27:31] <mhaberler> yes
[15:27:49] <SWPadnos> this used to work, as Alex has said. I'll check it on a more or less pristine system here when I get a chance
[15:28:30] <mhaberler> what you mean by 'used to work' : gcode continued to execute after just -prepare was set?
[15:28:40] <alex_joni> mhaberler: right
[15:28:59] <mhaberler> ah. let me look what the code says
[15:31:27] <mhaberler> It says:
[15:31:29] <mhaberler> if (*iocontrol_data->tool_prepare && *iocontrol_data->tool_prepared) {
[15:31:30] <mhaberler> emcioStatus.tool.pocketPrepped = *(iocontrol_data->tool_prep_pocket); //check if tool has been prepared
[15:31:32] <mhaberler> *(iocontrol_data->tool_prepare) = 0;
[15:31:33] <mhaberler> emcioStatus.status = RCS_DONE; // we finally finished to do tool-changing, signal task with RCS_DONE
[15:31:35] <mhaberler> I read this as: thanks, I got the pocket number. It *looks* right wrt what I said. I just dont know why a Tx alone hangs the queue.
[15:31:41] -!- wagnerf has quit [Remote host closed the connection]
[15:34:51] <alex_joni> maybe task has been changed to hang while RCS_EXEC ?
[15:35:19] <mhaberler> well, I guess it should
[15:35:24] <alex_joni> maybe changed to WAIT_DONE instead of WAIT_RECEIVED ?
[15:35:29] <alex_joni> no, it shouldn't I think
[15:35:41] <alex_joni> it sends the tool-prepare command to iocontrol
[15:35:52] <alex_joni> iocontrol starts working on it, and returns RCS_EXEC
[15:36:04] <alex_joni> task sees that, but can still send commands to motion
[15:36:22] <alex_joni> if there's a M6 (command to iocontrol) it won't get sent until the tool-prepare is done
[15:36:34] <mhaberler> what's WAIT_DONE instead of WAIT_RECEIVED ?
[15:38:28] -!- psha [[email protected]] has joined #emc-devel
[15:38:56] <alex_joni> mhaberler: the NML way of acking sent messages
[15:39:03] <alex_joni> but I think that's not it
[15:39:15] <alex_joni> something else must be wrong (looking at gitweb)
[15:41:56] <mhaberler> bb in 15mins
[15:53:23] -!- logger[psha] [logger[psha][email protected]] has joined #emc-devel
[15:53:27] <psha> logger[psha]: test
[15:53:36] <psha> http://psha.org.ru/irc/%23emc-devel/2011-01-01.html
[15:54:10] <psha> here is another link http://psha.org.ru/irc/%23emc-devel/2011-01-01.html#15:53:36 and something after it
[15:54:56] <psha> now logs has links :)
[15:55:03] <SWPadnos> psha, is that logger a process running on psha.org.ru?
[15:55:16] <mhaberler> psha: nice log.
[15:55:23] <SWPadnos> yeah, I like the look of it :)
[15:55:24] <psha> SWPadnos: yes
[15:55:27] <SWPadnos> bummer
[15:56:01] <mhaberler> and we all didnt thnk of it -/
[15:56:05] <archivist> psha, http://validator.w3.org/check?uri=http%3A%2F%2Fpsha.org.ru%2Firc%2F%2523emc-devel%2F2011-01-01.html%2315%3A53%3A36&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.1
[15:56:45] <psha> archivist: woa :)
[15:56:48] <psha> gona fix
[15:57:06] <archivist> I still have a few on mine to fix :)
[15:57:13] <psha> SWPadnos: http://psha.org.ru/cgit/psha/logbot/
[15:57:20] <psha> it's one borrowed from github
[15:57:23] <psha> with small fixes
[15:57:28] <SWPadnos> ok, cool
[15:57:44] <psha> primary - for 'bookmark' feature
[15:58:13] <psha> i've already mentioned - maybe it's better to upload logs to dreamhost instead of running bot there?
[15:58:16] <SWPadnos> I was thinking of replacing logger-emc and logger-devel with something running at my place, but then it needs to sync to linuxcnc.org from time to time
[15:58:24] <SWPadnos> yeah
[15:58:36] <psha> that one has feature to upload logs via ftp
[15:58:49] <psha> but i've not looked at it
[15:59:15] <SWPadnos> one idea was to have the current log always at the same URL, and upload the logs to their "permanent" location at the end of the day or every hour or something
[16:00:01] <SWPadnos> the URL for the current log can be redirected to another server pretty easily
[16:00:16] <SWPadnos> I think
[16:01:35] <psha> archivist: solved by one

tag :)
[16:04:53] <archivist> your

in the above line is not shown on the page
[16:05:18] <psha> i've added it in 12-31
[16:05:22] <archivist> hehe mine breaks on that too
[16:05:23] <psha> 01-01 is changing rapidly
[16:05:36] <psha> it's static html generated in place
[16:05:54] <psha> http://validator.w3.org/check?uri=http://psha.org.ru/irc/%2523emc-devel/2010-12-31.html&charset=(detect+automatically)&doctype=Inline&group=0&user-agent=W3C_Validator/1.1
[16:06:39] <SWPadnos> ah, so if you change the encoding to UTF-8, you'll have an error-free page
[16:06:57] <SWPadnos> in the header though, which is maybe not so simple
[16:07:09] <psha> warning free )
[16:07:32] <SWPadnos> yeah, that too!
[16:07:45] <psha> still have to escape issues
[16:10:17] <archivist> thats an htmlentities problem
[16:10:30] <psha> i don't know if i've to bother with it
[16:11:52] <mhaberler> alex_joni: still around or searching for a good disk ;-?
[16:16:51] <mhaberler> psha: off the web topic:.. ;-)
[16:16:53] <mhaberler> I have the M6_COMMAND and T_COMMAND executed from emctaskmain
[16:16:54] <mhaberler> unfortunately... emctaskmain IS executing the queue and the result of the M6_COMMAND/T_COMMAND execute is queued at the end of said list :-(
[16:18:23] -!- logger[psha] [logger[psha][email protected]] has joined #emc-devel
[16:18:34] <psha> test <with >tag
[16:19:01] <psha> another
[16:19:06] <mhaberler> I'm losing you
[16:19:19] <mhaberler> hold on, I'll push my snapshot to my repo
[16:19:51] <psha> test
[16:19:58] <psha> another
[16:20:03] <psha> oops
[16:21:19] <psha> test
[16:21:20] <psha> test
[16:21:20] <psha> test
[16:21:30] <mhaberler> we hear you load and clear
[16:21:47] -!- awallin has quit [Remote host closed the connection]
[16:22:12] -!- logger[psha] [logger[psha][email protected]] has joined #emc-devel
[16:22:14] <psha> test
[16:22:15] <psha> test
[16:22:29] <mhaberler> signal strength +27dB
[16:23:44] <mhaberler> psha: daditdahdit, dah-dah-dit-dah?
[16:23:46] <mhaberler> http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/toolchange-osub
[16:33:51] <psha> archivist: i think i've solved most of errors
[16:35:40] <psha> <div></div>
[16:37:08] <psha> tomorrow log will be fine i hope :)
[16:37:13] <mhaberler> psha; if I get this right it would mean inserting an EMC_TASK_PLAN_EXECUTE msg with msg->command set to M6/T_COMMAND, right?
[16:37:16] <psha> all entities are encoded, added div
[16:37:31] <psha> mhaberler: yes
[16:37:50] <mhaberler> the remaining problem.. where to insert how..
[16:39:46] <psha> bbl
[16:40:24] <mhaberler> boooo
[16:43:28] -!- awallin [[email protected]] has joined #emc-devel
[16:44:55] -!- awallin has quit [Remote host closed the connection]
[16:45:13] -!- awallin [[email protected]] has joined #emc-devel
[16:45:33] <jepler> dgarr: .merge() converts its arguments to a tcl list. as far as I know it's not documented. I used it wrong, though.
[16:47:11] -!- nullie has quit [Ping timeout: 255 seconds]
[16:48:35] <CIA-60> EMC: 03jepler 07master * r10164302e1db 10/tcl/bin/halshow.tcl: halshow: remove debug output
[16:48:43] <mhaberler> thanks..
[16:48:54] <jepler> mhaberler: welcome
[16:49:09] <jepler> I removed the line instead of commenting, so you'll get a conflict when you merge or rebase. but I assume you know how to deal with that
[16:49:26] <mhaberler> yes, thanks - this is a throwaway branch
[16:49:32] <jepler> dgarr: maybe this corrects my use of merge? http://emergent.unpy.net/files/sandbox/0001-axis-fix-a-python2.5-compatiblity-issue-v2.patch
[16:52:16] <jepler> mhaberler: did you look at your diffs? your editor is making wild whitespace changes again.
[16:52:19] <jepler> - // when we have M6 do the actual toolchange
[16:52:22] <jepler> + // when we have M6 do the actual toolchange
[16:52:37] <mhaberler> I know, I explicitely reformatted some code so I could read it
[16:52:39] <jepler> it looks like the "T6" o-code is being executed for T61 as well
[16:52:51] <mhaberler> this aint there yet..
[16:53:00] <mhaberler> right call from wrong place
[16:53:28] <jepler> mhaberler: OK, I won't scrutinize it in such detail yet, then
[16:53:34] <jepler> bbl
[16:53:55] <mhaberler> sorry.. can I bug with a single question ..
[16:54:33] <mhaberler> what this T/m6_command thing is really a macro replace in the running q
[16:55:27] <mhaberler> I can append, I'm at odds how to to insert (actually replace) and re-run the current nml command
[16:55:41] <mhaberler> I think that's really it
[17:08:31] <mhaberler> pls disrregard, I think I have it : int LinkedList::store_after_current_node()
[17:14:27] -!- nullie has quit [Quit: Ex-Chat]
[17:37:30] -!- qq- has quit [Ping timeout: 255 seconds]
[17:49:34] -!- qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[18:17:45] -!- acemi has quit [Quit: WeeChat 0.3.2]
[18:21:08] <dgarr> jepler: the v2.patch works for me -- i tested on lucid/simulator and both lucid/rtai and hardy/rtai --thanks very much.
[18:21:53] <dgarr> Maybe since the merge() is an undocumented feature, the code could suffer a brief mention to help future students of axis.py?
[18:53:13] -!- isssy has quit [Client Quit]
[18:54:46] -!- geo01005 has quit [Ping timeout: 250 seconds]
[19:11:52] -!- uwe_ has quit [Ping timeout: 276 seconds]
[19:14:08] -!- ries [[email protected]] has joined #emc-devel
[19:15:41] -!- Guest998 has quit [Client Quit]
[19:29:59] -!- steves_logging has quit []
[19:37:49] <jepler> hm, apparently the removal of .merge() is mulled for python2.7. :( http://bugs.python.org/issue5136
[19:42:54] <jepler> that would leave a circumlocution lke .tk.eval("list", *items)
[19:46:16] -!- motioncontrol has quit [Quit: Sto andando via]
[19:51:09] -!- pjm has quit [Ping timeout: 255 seconds]
[20:02:43] -!- SteveStallings [[email protected]] has joined #emc-devel
[20:03:13] -!- ries has quit [Ping timeout: 276 seconds]
[20:05:10] SteveStallings is now known as steves_logging
[20:05:42] -!- bootnecklad has quit [Read error: Connection reset by peer]
[20:09:01] <dgarr> File "/home/git/emc/bin/axis", line 2448, in inifindall return root_window.tk.eval("list",*items)
[20:09:01] <dgarr> TypeError: eval() takes exactly 1 argument (2 given)
[20:14:00] -!- skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-412.dsl.airstreamcomm.net] has joined #emc-devel
[20:21:24] <jepler> yeah that's not the right incantation
[20:21:43] <jepler> oh, I must have meant tk.call
[20:22:27] * jepler tries to decide whether to care
[20:23:09] <jepler> reportedly there won't be another python 2.x after 2.7, and for a python3 port this line would be the least of my worries
[20:27:11] -!- mhaberler has quit [Ping timeout: 272 seconds]
[20:28:57] <dgarr> tested: return root_window.tk.call("list",*items) -- worked on lucid, did not work on hardy
[20:31:40] <jepler> ugh
[20:31:42] <jepler> ok
[20:31:51] <jepler> there was a .merge variant that did work, though?
[20:31:54] <jepler> the -v2.patch
[20:33:07] <dgarr> the -v2 patch with merge() worked for me on lucid and hardy
[20:34:10] -!- seb_kuzminsky [[email protected]] has joined #emc-devel
[20:34:17] <jepler> hi seb!
[20:34:26] <CIA-60> EMC: 03jepler 07master * r6d2a1d01ed98 10/src/emc/usr_intf/axis/scripts/axis.py: axis: fix a python2.5 compatiblity issue
[20:34:48] <seb_kuzminsky> hi jeff
[20:35:02] <seb_kuzminsky> how's 2011 so far?
[20:35:45] <jepler> not bad
[20:35:49] <jepler> a bit on the cold side
[20:36:31] <seb_kuzminsky> we got our first real snow of the season a couple days ago - i like it
[20:37:11] <jepler> we have a tiny bit here
[20:38:12] <seb_kuzminsky> can you code-review a short axis patch? http://pastebin.ca/2036034
[20:39:01] <seb_kuzminsky> i suck at tcl
[20:39:14] <skunkworks> we had 40 deg weather here the last few days - got rid of a good amount of our 24" snow
[20:39:16] <seb_kuzminsky> that patch says it's 1 of 4, but it stands alone (the other 3 are unrelated
[20:39:28] <seb_kuzminsky> hi skunkworks :-)
[20:39:36] <skunkworks> Hi :)
[20:39:57] <jepler> seb_kuzminsky: looking..
[20:39:58] <dgarr> jepler: thanks -- i just updated for the patch and tested on lucid and hardy -- both ok
[20:40:19] <jepler> seb_kuzminsky: if your window manager can't do that for you, throw it out and get a different one
[20:40:34] <seb_kuzminsky> hm
[20:41:52] <seb_kuzminsky> i'm running stock lucid wiwth gnome on this computer, and it doesn't remember axis window geometry by default
[20:42:16] <jepler> I don't doubt that; metacity is a seriously crappy window manager
[20:42:44] <jepler> http://mid.gmane.org/[email protected]
[20:43:39] <seb_kuzminsky> ok maybe i should do that instead
[20:43:56] -!- psha has quit [Quit: Lost terminal]
[20:44:57] <jepler> dgarr: thanks for testing all those broken patches
[20:45:06] <dgarr> np
[20:48:20] * jepler wonders about the meaning behind the date in every git patch, Mon Sep 17 00:00:00 2001
[20:49:59] -!- rwijbenga has quit [Ping timeout: 272 seconds]
[20:52:30] -!- qq- has quit [Ping timeout: 240 seconds]
[20:53:13] -!- qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[21:01:36] <seb_kuzminsky> some of our .ini files have a proper [FILTER] section that references image-to-gcode and python, should i propagate that section to all the other .inis?
[21:18:03] <seb_kuzminsky> or rather, is there a reason not to? I've got a patch against master that does it, any reason not to commit it?
[21:25:26] <alex_joni> seb_kuzminsky: the only reason I see is overcomplicating sample configs
[21:25:35] <alex_joni> you can't have all configs contain all possible nice things
[21:25:45] <alex_joni> people will be completely lost when looking at them :)
[21:26:24] <seb_kuzminsky> yeah that's probably true
[21:26:58] <seb_kuzminsky> on the other hand, people might also become lost if they hear about things like image-to-gcode, and it doesnt work on their config
[21:29:39] <seb_kuzminsky> maybe i should try to identify which configs are used as a basis for a working machine config (like hm2-servo/*.ini and hm2-stepper/*.ini), and give them [FILTER]
[21:30:19] <seb_kuzminsky> and identify the inis which are more used as examples/tutorials/guides, and leave those as simple as possible?
[21:30:31] <JT-Shop> you might check if gedit is the editor too
[21:30:57] <seb_kuzminsky> JT-Shop: do you think it should be?
[21:31:24] <JT-Shop> it seems to be the easiest to use
[21:31:57] <JT-Shop> a few have/had some strange one that was not intuitive at all (I could not figure out how to edit with it)
[21:32:15] -!- mhaberler [[email protected]] has joined #emc-devel
[21:33:17] <JT-Shop> I think all the configs should have a [FILTER] section even if it is blank
[21:33:25] <seb_kuzminsky> some configs use vim
[21:33:53] * JT-Shop just had the deer in the headlights look when I saw vim
[21:34:01] <seb_kuzminsky> hah
[21:34:52] <seb_kuzminsky> an empty [FILTER] section seems like a bad idea to me - it's another thing for the deer-in-headlights user to look at, but it doesnt accomplish anything that improves their ux
[21:35:09] <seb_kuzminsky> i'd prefer a "best-of-breed" filter shared by all "useful" configs, i think
[21:35:15] <JT-Shop> could have a note in there stating what goes there
[21:35:16] <skunkworks> edlin!
[21:35:33] <JT-Shop> I think I could use edlin
[21:35:38] <seb_kuzminsky> it'd be nice if the .ini file could #include other ini files, then we could #include /etc/emc2/filter.ini, etc
[21:36:33] <JT-Shop> Vim is a text editor originally released by Bram Moolenaar in 1991 for the Amiga computer
[21:36:57] <JT-Shop> I never had an Amiga computer so I guess that is why I was lost when vim popped up
[21:37:32] <seb_kuzminsky> vim is a clone of vi, which was the first "visual" editor for unix, back in the way back when
[21:37:48] <dgarr> teco rules
[21:37:59] <seb_kuzminsky> i think most folks who grew up in unix are at least somewhat comfortable in vi
[21:38:02] <skunkworks> I had a c128 - never got into amiga - went to ibm clones
[21:38:34] <JT-Shop> I think most folks didn't grow up in unix :)
[21:38:40] <seb_kuzminsky> yes :-)
[21:42:31] <seb_kuzminsky> think of all those poor children
[21:42:36] <seb_kuzminsky> no unix when they grew up
[21:42:50] <seb_kuzminsky> i gave my kids a unix box for newtonmas this year :-)
[21:46:10] <archivist> vi was a revelation after ed on dos
[21:47:40] <skunkworks> http://groups.yahoo.com/group/mach1mach2cnc/message/124283
[21:49:12] <seb_kuzminsky> wow that guy sounds frustrated
[21:49:17] <JT-Shop> yea
[21:50:01] <skunkworks> steve b. put in his 2cents - but still seems to be using emc for turning :)
[21:52:55] <archivist> I see steve b knocks the smooth stepper too
[21:53:25] -!- ries [[email protected]] has joined #emc-devel
[21:57:00] <archivist> and is he right about tapered threads, if so that does need a fix
[21:57:42] <JT-Shop> what about tapered threads?
[21:58:19] <archivist> iirc the pitch is wrong on a tapered
[21:58:42] <JT-Shop> ah ok
[21:58:44] <archivist> trying to remember his groan on the list
[22:01:49] <jmkasunich> emc's thread pitch isn't wrong
[22:01:55] <jmkasunich> it just expects you to do that math
[22:02:23] <jmkasunich> steve b thinks when you specify pitch it should always be measured along Z
[22:02:36] <jmkasunich> emc measures it along the (possibly tapered) thread line
[22:02:44] <skunkworks> right
[22:02:59] <jmkasunich> emc2 method allows you to cut a face thread (think 3-jaw chuck scroll)
[22:03:05] <skunkworks> makes it more flexable - just not standerd the way it sounds
[22:03:11] <jmkasunich> the other method doesn't, since the pitch along Z is zero in that case
[22:03:15] <skunkworks> *standard
[22:03:48] <JT-Shop> so a simple subroutine is all you need to cut pipe threads all day long without a headache
[22:03:50] <skunkworks> jmkasunich: rigid tapped in the air... Have not gotten back to it though
[22:04:03] <JT-Shop> cool
[22:04:10] <JT-Shop> some wood next?
[22:05:56] -!- toastyde1th has quit [Read error: Connection reset by peer]
[22:06:09] <skunkworks> yes
[22:06:34] <JT-Shop> I made a 1/4-16 thread the other day on the Hardinge :/
[22:07:10] <archivist> I too expect a tapered thread to be simple and not need to do math, having the ability is a plus but dont make the simple difficult
[22:08:06] <JT-Shop> like having the option of using the Z as the pitch line?
[22:09:27] <archivist> well thats what the docs actually says Drive Line
[22:09:27] <archivist> A line through the initial X position parallel to the Z.
[22:11:29] <archivist> at the moment I cannot see how the docs tell you to do a tapered thread
[22:11:48] <jmkasunich> when doing the "normal" case the simple way makes one or more abnormal cases impossible, I vote for making all cases a bit more complex
[22:13:21] <jmkasunich> on an unrelated note, is there an award for procrastination>
[22:13:23] <jmkasunich> ?
[22:13:34] <jmkasunich> I just bored a hole, 28mm dia by 26mm deep
[22:13:49] <jmkasunich> no big deal, took about an hour and a half (tight diameter tolerance)
[22:14:02] <jmkasunich> the part has been chucked in the lathe awating this hole since June
[22:14:07] <seb_kuzminsky> hah
[22:14:56] <jmkasunich> I now need to cut a keyway in that hole
[22:15:03] <jmkasunich> which will probably be done in June
[22:18:07] <skunkworks> :)
[22:19:10] <seb_kuzminsky> see you later guys
[22:19:11] -!- seb_kuzminsky has quit [Quit: Client exiting]
[22:23:50] <JT-Shop> see you later seb
[22:24:58] <JT-Shop> archivist: you have to use G33 and program each pass to do a tapered thread AFAIK
[22:25:59] <archivist> yes but it would be simple probably to add a tapered mode to G76
[22:26:18] <archivist> which would be the right thing todo imo
[22:26:38] <JT-Shop> and imho too but I don't know how :)
[22:27:17] <archivist> I went as a user straight to the g76 docs to see how to do it
[22:27:50] <archivist> g33 did not cross my mind till I investigated and searched
[22:29:47] <JT-Shop> I guess I'll write a subroutine to do tapered threads...
[22:30:00] <JT-Shop> have you seen the other subroutines on the forum?
[22:30:49] <archivist> I tend to write my own and in this case its easier to do on the mill on a rotary
[22:31:33] <archivist> I bet a lot of users would prefer G76 to be fixed/improved
[22:32:28] <JT-Shop> I bet all the "users" would perfer G76.1 for tapered threads
[22:33:13] <archivist> 76.1 for an x difference 76.2 for an angle
[22:34:02] bootnecklad is now known as boot|illbebackla
[22:34:12] boot|illbebackla is now known as boot|illbeback
[22:34:37] <archivist> stuff I have done in the past is a specified angle
[22:36:21] <archivist> and by mid year I may have a need, but the job is probably too big for the cnc lathe, last time I did it on the southbend
[22:37:54] <JT-Shop> just looking in my Machinery Handbook and it shows the taper to be 1 in 16 measured on the diameter
[22:38:04] <JT-Shop> for pipe thread
[22:42:41] <archivist> is npt same taper as bsp
[22:43:30] <JT-Shop> oh wow the Machinery Handbook has a CNC section :)
[22:44:18] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[22:45:13] <JT-Shop> let me see if bsp is in the book
[22:45:31] <archivist> 1 in 16 on diameter for bsp anyway
[22:46:45] <JT-Shop> the tpi is different
[22:48:18] <JT-Shop> says " pressure tight joints are based on Whitworth thread form"
[22:49:48] <archivist> I made a boiler washout plug for the site where I drive the engine, and it looks like another is needed soon, they need to be a good seal
[22:50:24] <andypugh> BSP lives on as the metric pipe standard
[22:50:46] -!- L84Supper has quit [Ping timeout: 276 seconds]
[22:51:14] <archivist> we clean the threads with a taper tap and wind in the plug a bit more, making a bigger plug where needed
[22:51:48] <andypugh> I have the table here, i you need a specific spec
[22:52:29] <archivist> we were considering a addition to G76
[22:53:31] -!- Fox_Muldr has quit [Ping timeout: 276 seconds]
[22:53:43] <JT-Shop> I assume you can do multi start threads with G76 by just offsetting the start point?
[22:53:50] <andypugh> Yes
[22:54:18] <andypugh> I have done single-start threads with multiple cuts that way.
[22:54:42] <JT-Shop> to make a acme type of thread?
[22:55:08] <jepler> andypugh: *egg on face* I just found your last gearchange.comp in my spam trap yesterday (that you had presumably sent to me the day I asked for it). but now it's in master branch.
[22:55:12] <andypugh> A 3.5mm pitch thread. Conventional form, but no way mu lathe could handle that cut-length.
[22:56:09] <andypugh> It was Cradek's suggestion, nibble it away as a series of smaller triangles.
[22:56:32] <JT-Shop> ah ok
[22:57:38] <andypugh> The point is, offsetting the start point has exactly the expected effect.
[23:00:12] <JT-Shop> so if you had room you could knurl something with the G76
[23:01:06] <archivist> I wish I had taken pics of some knurling I did on the mill
[23:01:24] <JT-Shop> with a rotary axis?
[23:01:32] <archivist> basicly was a hack on my helical gear
[23:01:38] <archivist> yes
[23:02:27] <archivist> took ages but looked nice
[23:02:42] * JT-Shop wonders if you can use the E and L to make a tapered thread???
[23:02:47] <JT-Shop> in G76
[23:03:13] <andypugh> I guess if they met in the middle...
[23:05:05] <JT-Shop> guess not after reading a bit
[23:06:27] -!- robh__ [[email protected]] has joined #emc-devel
[23:06:31] <JT-Shop> andypugh: the new clutch is much better in the F40
[23:06:32] <archivist> it relates to K and thats not what we want
[23:06:41] <JT-Shop> yea :(
[23:07:08] <andypugh> Excellent.
[23:07:15] <JT-Shop> I didn't realize how bad the 54 year old clutch was
[23:07:32] <JT-Shop> or pressure plate really
[23:08:39] <JT-Shop> archivist: seems like if there is some taper code in G76 having a full taper would be possible
[23:08:53] <JT-Shop> but what do I know
[23:09:28] <archivist> JT-Shop, if I can make time I will try and look at the source
[23:10:27] <archivist> I have toys to measure the resultant taper to make sure its right :)
[23:11:13] <andypugh> I assume you can easily do it the long-winded way with a G33 loop.
[23:12:30] <archivist> yes but for standard tapered threads for pipes and fittings G67.x would be more sensible imo
[23:12:37] <archivist> 76
[23:13:23] <archivist> keep steve B happy and me
[23:13:58] <skunkworks> :)
[23:14:01] <JT-Shop> I hate it when it takes me 6 months to figure out the code for a 5 minute job
[23:14:06] <andypugh> I guess there is an argument for G76 using pitch, and G33 using feed-per-rev
[23:14:28] <archivist> exactly
[23:14:31] <JT-Shop> G33 is just one pass
[23:14:55] <archivist> and that too
[23:15:34] <JT-Shop> the taper is 1 in 16 for both sides of the pond...
[23:16:16] <archivist> there is another taper which is the oil rig pipe thread
[23:17:04] boot|illbeback is now known as bootnecklad
[23:21:57] <andypugh> When Michael H talks of "Discussion of G-code as tool change" in the mailing list, does he refer to discussion I have missed, or is he referring to my suggestion?
[23:22:01] <JT-Shop> for drill pipe or production tubing?
[23:23:03] <archivist> drill pipe
[23:24:06] <JT-Shop> yea, that is normally a hydrill thread
[23:24:27] <JT-Shop> a two step jobby that makes it hard to cross thread
[23:24:52] <JT-Shop> maybe spelled hydril
[23:25:11] <JT-Shop> been a while since I worked on drilling rigs
[23:25:41] <archivist> and steeper taper to stop jamming to tight iirc
[23:26:33] <archivist> Im remember seeing it in a thread book I copied (and cant find atm)
[23:27:50] <JT-Shop> it's almost like a two step acme thread with a taper on both
[23:28:43] -!- motioncontrol has quit [Client Quit]
[23:30:11] -!- awallin has quit [Ping timeout: 240 seconds]
[23:34:55] <JT-Shop> http://hyd175.originbeta.com/_pdf/premiumConnectionsBrochures/9402-d.pdf
[23:36:44] <andypugh> Interestingly complex field, it seems. http://oiltechcn.com/productscategory.php?id=118
[23:39:29] <archivist> hehe I dont think they are G76 candidates anyway
[23:42:55] <JT-Shop> no
[23:43:28] <JT-Shop> you should see how they friction weld the ends on the drill pipe!
[23:44:13] <archivist> I have seen friction welds on youtube
[23:44:53] <archivist> hmm there was a lovely friction weld accident report somewhere
[23:45:56] <archivist> large lumps and machine falling over due to the inertia
[23:46:23] * JT-Shop wanders inside...