Back
[10:54:16] <JT-Dev> is the expected behavior of G76 to end at the end of the drive line and not at the start of the drive line?
[11:25:24] <alex_joni> well.. what do the docs say?
[11:40:48] <JT-Dev> nothing I think
[11:42:16] <JT-Dev> I guess that I was surprised that the end position was not at the start of the drive line
[11:42:59] <JT-Dev> especially for an internal thread
[12:32:27] <JT-Dev> I get this error loading g76.ngc with lathe sim
http://imagebin.ca/view/cPpuzL.html
[12:39:26] <SWPadnos> what are your tool sizes?
[12:54:32] <JT-Dev> the stock sim I don't know
[12:54:54] <JT-Dev> I think I tried to reduce it yesterday to 0.001 and still got the error
[12:55:15] <SWPadnos> ok
[12:55:22] <SWPadnos> 2.3.x or 2.4pre?
[12:55:28] <JT-Dev> 2.3.5
[12:55:33] <SWPadnos> (not that I'll really be able to help, just curious :) )
[12:55:35] <SWPadnos> ok
[12:56:04] <JT-Dev> I wanna think I tried it out in the shop to on 2.4pre
[12:57:15] <JT-Dev> I think the sample file is wrong after some change a while back to comp perhaps
[12:57:42] <SWPadnos> could be
[12:57:48] <JT-Dev> hi ho hi ho it's off to work I go
[12:59:29] <SWPadnos> hm. well line 26 has no motion, so I guess it's impossible for that to be > the tool radius
[13:06:19] <cradek> g0z1x-1
[13:06:19] <cradek> g41
[13:06:19] <cradek> g0z1
[13:06:35] <cradek> obviously the entry move is zero length
[13:06:45] <cradek> so it won't work unless you have a zero radius tool
[13:07:03] <SWPadnos> right
[13:08:10] <cradek> ok now I see that's pretty much the same thing you said
[13:08:19] <cradek> (weird sample program)
[13:08:42] <SWPadnos> heh
[13:09:15] <SWPadnos> looking at the commit log, I think it's safe to say that whatever it is, it's your fault :)
[13:09:46] <cradek> I can neither confirm nor deny that
[13:09:50] <SWPadnos> heh
[13:10:09] <SWPadnos> oh right, it's possible the the software changed such that the demo stopped working. darnit
[13:11:29] <cradek> I don't see how that entry move could have ever been right
[13:12:10] <SWPadnos> yeah. I stopped looking when I couldn't find out how to get gitweb to show me the equivalent of cvswebs "annotate" view
[13:13:50] <SWPadnos> oh, ok. it was the last commit that added the tool offset
[13:14:16] <cradek> yeah, too bad about gitweb
[19:57:25] <micges> good evening all
[19:57:33] <micges> cradek: around?
[19:58:21] <alex_joni> asquare
[20:07:25] <micges> I'm heavly testing master on real environment and I've got at least 3 bugs
[20:07:47] <micges> didn't tested them on 2.4 yet
[20:11:21] <alex_joni> what bugs?
[20:13:37] <micges> 1. another cases of SF #2808858 bug
[20:14:49] <micges> 2. emc don't stop at g0->g1 point
[20:15:27] <alex_joni> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,25/id,2322/limit,6/limitstart,6/lang,en/#2470
[20:16:08] <micges> 3. in gcode 'm4\g1\m5\G4 P0.01' spindle isn't enabled during G1
[20:16:43] <micges> but in gcode 'm4\g1\G4 P0.01\M5' it's correct
[20:33:40] <micges> http://imagebin.ca/view/NoIr5GO5.html
[20:37:18] <awallin> micges: is that deviation more than the P0.1 you programmed?
[20:38:14] <cradek> micges: explain
[20:39:21] <cradek> what are we supposed to see here?
[20:42:25] <micges> according to defiition we should see g0 stopped at it's end and then g1 move
[20:42:53] <cradek> according to what?
[20:43:09] <cradek> emc has never done that unless g61 is programmed
[20:45:06] <micges> awalin: deviation is at about 0.3
[20:45:40] <micges> cradek: are you sure?
[20:45:59] <cradek> yes
[20:46:01] <cradek> positive
[20:46:27] <cradek> you could get an exact stop there IF you turned on the spindle, because it would check (and maybe wait for) spindle-at-speed before doing the cutting move
[20:46:47] <cradek> but other than that, emc has never differentiated between rapids and feeds for blending decisions
[20:48:38] <micges> ok maybe it wasn't so obvious to me
[20:56:12] <micges> good night all