Back
[02:33:47] <cradek> skunkworks: about that cnczone thread about cutter compensation: I agree with everything everyone said on all sides of the argument! that's uncommon.
[02:34:39] <SWPadnos> heh
[02:36:33] <skunkworks> Cool :)
[02:36:52] <cradek> jmkasunich: I appreciate any insight to improving the threading target stuff
[02:37:22] <cradek> also what I am calling "time lag" that showed up with rigid tapping - that's one of the things I want to try to fix
[02:37:26] <skunkworks> the last post.. Didn't you add stuff to set tool lengths? did that apply? (for dynamic tool lenght setting)
[02:37:54] <SWPadnos> oh - are you talking about the "unwinding" at the end of a tapping cycle, or something else?
[02:38:13] <cradek> you cannot write to the tool table, but you can set length/diameter of a "transient" tool with g43.1/g41.1/g42.1
[02:38:26] <skunkworks> ok - that is what I was remembering
[02:38:47] <cradek> SWPadnos: no, the slight pushing up/down (I forget) on the workpiece while the tap backs out
[02:39:04] <SWPadnos> ah, ok
[02:39:24] <cradek> I think this will always be there because of the lag inherent in the servo cycle, but you should be able to compensate (probably a setting to fiddle)
[02:39:24] <SWPadnos> the encoder on the Mazak is something like 360PPR, right>
[02:39:26] <SWPadnos> ?
[02:39:31] <cradek> yes I think it's 360
[02:39:34] <SWPadnos> FF1 or FF0 :)
[02:39:45] <SWPadnos> or FF-1 ;)
[02:39:46] <cradek> yes pretty much (FF1)
[02:40:18] <SWPadnos> similar/same synchronization code?
[02:40:27] <cradek> sorry?
[02:40:29] <SWPadnos> as the lathe threading stuff
[02:40:34] <cradek> ah, same
[02:40:57] <SWPadnos> ok. some kind of "speed bobble" would likely lift/push the part
[02:41:07] <cradek> I don't think that's it
[02:41:09] <SWPadnos> or both
[02:41:29] <SWPadnos> heh - you know the code, I just look for (sometimes nonexistent) patterns :)
[02:41:58] <cradek> there is error in the position "loop". that's fine, but it switches sign when you reverse the tap
[02:42:44] <cradek> I think that's the best way to explain the problem but I'm only going by gut, I haven't really tested it.
[02:43:19] <SWPadnos> oh - it doesn't wait for another index at the bottom, does it?
[02:43:32] <cradek> no, that would be very bad :-)
[02:43:33] <SWPadnos> so it's still "geared" to the spindle
[02:43:58] <SWPadnos> only backwards at some point :)
[02:44:12] <cradek> yes it indexes before entering only. the count goes back to zero when it's back out of the hole and the sync move is done
[02:44:46] <cradek> I am picturing this procedure:
[02:44:57] <cradek> chuck up some acme rod and set up a DTI with a finger that fits in it
[02:45:19] <cradek> "tap" with the rod and note the movement of the dial when reversing
[02:45:29] <cradek> (difference between upward position and downward position)
[02:45:40] <cradek> place this number in the ini and compensate somehow
[02:45:51] <SWPadnos> hrmmm
[02:46:13] <skunkworks> sounds good. Make it so. ;)
[02:46:32] <cradek> I think we will find significant position difference when we do this test
[02:46:41] <cradek> that's what made the holes a bit rough
[02:46:42] <SWPadnos> other than the word "somehow" in there, I'd expect there to be issues related to spindle speed and cutting force (causes the slowdown to be faster), and maybe others
[02:47:03] <cradek> yes it might change with spindle speed.
[02:47:31] <skunkworks> You guys where actually looking at spindle current or something on the mazak to see how much more drag there was.
[02:47:31] <cradek> I don't think there will only be error at reversal time. I think it will be a static difference throughout the up/down motion
[02:47:33] <SWPadnos> a 1/4NPT tap should slow down faster than a 1/4-20 also
[02:47:42] <cradek> skunkworks: yes there was significant drag when retracting.
[02:48:06] <SWPadnos> yeah - I'm imagining that the problem may be related to when the tapping cycle reverse vs. when the spindle actually starts going backwards
[02:48:34] <SWPadnos> reverses
[02:49:12] <cradek> SWPadnos: I don't think that's a problem; position is tracked during that transition
[02:49:36] <cradek> I think we will find it's a static error that appears after reversal and stays there
[02:50:20] <SWPadnos> right - the programmed depth is reached and the spindle is commanded to reverse. some time later, the spindle stops forward motion
[02:50:34] <cradek> but, I am anxious to test instead of speculate
[02:50:39] <SWPadnos> heh
[02:50:43] <cradek> SWPadnos: yes it tracks during all that mess
[02:50:44] <SWPadnos> only a couple of weeks left :)
[02:50:56] <skunkworks> crap.. I have to sign up - don't I.
[02:51:17] <SWPadnos> so it detects spindle stop/reverse and uses that as the reversal point for the programmed cycle?
[02:51:21] <SWPadnos> heh - me too
[02:51:31] <cradek> skunkworks: hey, pay for mine while you're at it
[02:51:38] <skunkworks> :)
[02:51:39] <cradek> SWPadnos: yes
[02:52:05] <SWPadnos> ok. I'm guessing that some error there would provide a constant offset for the entire ackout move :)
[02:52:07] <cradek> SWPadnos: I think it would just break otherwise - you can't assume a particular reversal speed
[02:52:08] <SWPadnos> backout
[02:52:23] <jmkasunich> hi
[02:52:26] <cradek> hi
[02:52:34] <jmkasunich> just read back
[02:52:34] <SWPadnos> sure, you need to track
[02:52:36] <SWPadnos> hi
[02:52:44] <skunkworks> hi
[02:52:51] <jmkasunich> I agree that the rigid tapping thang is completely different than the lathe thang
[02:53:01] <cradek> yes
[02:53:22] <cradek> although the beginning of a RT will have the same accel issue
[02:53:43] <jmkasunich> right - once we fix it on lathe we can port that fix to RT
[02:53:51] <jmkasunich> won't change the backout drag tho
[02:53:56] <cradek> it's pretty much the same code
[02:54:14] <cradek> yes I think the backout drag is a different problem completely
[02:54:28] <jmkasunich> the lathe thing is one of those that I want a pencil to talk about
[02:55:02] <SWPadnos> I added it to the discussion topic list - feel free to add notes to that
[02:55:09] <cradek> I'll have my lathe there to play with.
[02:55:19] <SWPadnos> I considered making a separate "bugs to think about" section
[02:55:22] <cradek> (but it accels so fast it doesn't care)
[02:55:35] <jmkasunich> we can fix that (the accel) with an ini edit
[02:55:39] <cradek> yep
[02:57:19] <jmkasunich> I really need to stop "avoiding"
[02:57:31] <cradek> avoiding?
[02:57:39] <jmkasunich> I've been procrastinating on these shelves all day
[02:57:55] <jmkasunich> cause I'm getting closer and closer to the "glue 12 pieces together at once" step
[02:57:55] <SWPadnos> but doing those would let you avoid something else, so where's the benefit?
[02:58:10] <jmkasunich> and I'm afraid I will run out of hands or clamps or both
[02:58:53] <skunkworks> I had a very productive day. Fixed a windows ME computer so it will work with dial up and also cleaned a briggs carbarator on a go-cart and made a little boy happy.
[02:59:08] <jmkasunich> cool (the latter task anyway)
[02:59:14] <cradek> yep that sounds fun
[02:59:54] <skunkworks> reletively new motor.. THe thing had some sort of foam in the gas tank I am assuming to stop sloshing.. It was falling apart and plugging the jet.
[02:59:56] <jmkasunich> I need to get serious with the carb on my mower - it will run fine once warm, but the first start is a bitch even with starting fluid
[03:00:03] <jmkasunich> sometiing must be clogged up
[03:01:17] <cradek> jmkasunich: manual choke?
[03:01:23] <jmkasunich> no choke
[03:01:30] <jmkasunich> primer bulb that doesn't seem to do anything
[03:01:37] <cradek> ah hm
[03:01:37] <skunkworks> little bulb primer?
[03:01:40] <skunkworks> oh
[03:01:57] <jmkasunich> heh, listening to Jimmy Buffet: "We are the people our parents warned us about"
[03:02:14] <skunkworks> heh
[03:02:42] <jmkasunich> maybe if it warms up a bit I'll look at that tomorrow
[03:02:53] <jmkasunich> this has to be the coolest May I can remenber
[03:02:59] <jmkasunich> remember
[03:03:08] <fenn> brr
[03:03:26] <SWPadnos> which is strange after April had those 80-degree days
[03:03:31] <jmkasunich> yeah
[03:03:55] <jmkasunich> it will probably be 100 in June, and 60 in July
[03:04:48] <SWPadnos> yeah - "the year of the sinewave"
[03:05:25] <SWPadnos> oh interesting
[03:05:43] <SWPadnos> I'm looking at that Mits manual linked in the CNCZone cutter comp thread
[03:05:56] <SWPadnos> they say: (gotta type
[03:06:01] <SWPadnos> it, so it'll take a sec)
[03:07:25] <SWPadnos> When compensation starts, the movement commands are always executed after 3 blocks have been read continuously or, if the movement commands are not contained in 3 blocks, after a maximum of 5 blocks have been read continuously, regardless of whether the operation mode is set to continuous or single block operation
[03:07:46] <SWPadnos> so it seems they aren't doing more than one or possibly two segment lookahead
[03:08:57] <cradek> BOSS has lots of rules about 3 moves here and there too
[03:09:23] <SWPadnos> I remember Ray saying soemthing about 3 and 5 blocks - may have been a different version of the Mits manual
[03:10:14] <cradek> I think our single step will work fine with concave comp due to the queueing we already have
[03:10:36] <SWPadnos> sure - it's the infinite lookahead problem I'm thinking of
[03:11:13] <SWPadnos> (even aside from the stuff jepler was working on, to see if you might gouge something other than the segment being run)
[03:11:33] <cradek> yeah that's a whole other ball of mud
[03:11:37] <SWPadnos> big
[03:11:39] <cradek> ball of worms?
[03:12:02] <skunkworks> can of mud?
[03:12:39] <SWPadnos> can of worm-filled mudballs
[03:37:38] <fenn> bag of worm castings
[03:38:21] <fenn> is the idea to eventually give cutter comp infinite lookahead?
[03:38:31] <fenn> gouge protection
[03:38:35] <cradek> that's not something I'm planning
[03:38:44] <cradek> (if that's what you're asking)
[03:39:18] <fenn> i'm not sure what i'm asking.. i saw jepler's offset noodlings and he said they're in c++ because it might go into emc
[03:39:26] <cradek> it would be great if it could look ahead several moves. it's hard...
[03:39:41] <cradek> yes we worked on it separately, and came up with different trade-offs
[03:40:01] <cradek> not sure which approach is better in the long run. mine is certainly closer to working in emc.
[03:51:12] <jmkasunich> IMO infinite look-ahead is the CAM's job
[03:51:42] <cradek> I agree
[03:52:04] <cradek> but looking ahead a few lines can help you in corners
[03:52:52] <cradek> http://timeguy.com/cradek-files/emc/inside-offset.png
[03:53:14] <cradek> (see the little crossings in the corners?)
[03:53:15] <jmkasunich> right
[03:54:11] <cradek> I plan that my code will detect a gouge in this case
[03:54:26] <fenn> even if the second move is an arc?
[03:54:35] <cradek> fenn: ?
[03:54:58] <fenn> it just seems like more work to figure out where the arc is
[03:55:12] <fenn> whether you will intersect it
[03:55:13] <cradek> sorry I still don't follow
[03:55:31] <cradek> oh concave corners at arc-arc, arc-line, line-arc?
[03:55:39] <cradek> I have all that working
[03:56:36] <cradek> http://timeguy.com/cradek-files/emc/t3.png
[03:56:49] <cradek> the center one is the nominal path
[03:57:49] <fenn> all of those arcs are bigger than the offset distance
[03:57:57] <cradek> yes
[03:58:16] <cradek> if not, it would gouge; I think that error is already detected
[08:42:27] <CIA-32> EMC: 03alex_joni 07TRUNK * 10emc2/tcl/tkemc.tcl: apply patch by Dewey Garrett : use variables for different colours, this way users can customize the look of tkemc
[18:21:06] <rayh> Just got a shot of xfce running emc and such. It's at
http://imagebin.ca/view/MZwAVT5Q.html
