skunkworks: about that cnczone thread about cutter compensation: I agree with everything everyone said on all sides of the argument! that's uncommon.
jmkasunich: I appreciate any insight to improving the threading target stuff
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
the last post.. Didn't you add stuff to set tool lengths? did that apply? (for dynamic tool lenght setting)
oh - are you talking about the "unwinding" at the end of a tapping cycle, or something else?
you cannot write to the tool table, but you can set length/diameter of a "transient" tool with g43.1/g41.1/g42.1
ok - that is what I was remembering
SWPadnos: no, the slight pushing up/down (I forget) on the workpiece while the tap backs out
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)
the encoder on the Mazak is something like 360PPR, right>
yes I think it's 360
FF1 or FF0 :)
or FF-1 ;)
yes pretty much (FF1)
similar/same synchronization code?
as the lathe threading stuff
ok. some kind of "speed bobble" would likely lift/push the part
I don't think that's it
heh - you know the code, I just look for (sometimes nonexistent) patterns :)
there is error in the position "loop". that's fine, but it switches sign when you reverse the tap
I think that's the best way to explain the problem but I'm only going by gut, I haven't really tested it.
oh - it doesn't wait for another index at the bottom, does it?
no, that would be very bad :-)
so it's still "geared" to the spindle
only backwards at some point :)
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
I am picturing this procedure:
chuck up some acme rod and set up a DTI with a finger that fits in it
"tap" with the rod and note the movement of the dial when reversing
(difference between upward position and downward position)
place this number in the ini and compensate somehow
sounds good. Make it so. ;)
I think we will find significant position difference when we do this test
that's what made the holes a bit rough
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
yes it might change with spindle speed.
You guys where actually looking at spindle current or something on the mazak to see how much more drag there was.
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
a 1/4NPT tap should slow down faster than a 1/4-20 also
skunkworks: yes there was significant drag when retracting.
yeah - I'm imagining that the problem may be related to when the tapping cycle reverse vs. when the spindle actually starts going backwards
SWPadnos: I don't think that's a problem; position is tracked during that transition
I think we will find it's a static error that appears after reversal and stays there
right - the programmed depth is reached and the spindle is commanded to reverse. some time later, the spindle stops forward motion
but, I am anxious to test instead of speculate
SWPadnos: yes it tracks during all that mess
only a couple of weeks left :)
crap.. I have to sign up - don't I.
so it detects spindle stop/reverse and uses that as the reversal point for the programmed cycle?
heh - me too
skunkworks: hey, pay for mine while you're at it
ok. I'm guessing that some error there would provide a constant offset for the entire ackout move :)
SWPadnos: I think it would just break otherwise - you can't assume a particular reversal speed
just read back
sure, you need to track
I agree that the rigid tapping thang is completely different than the lathe thang
although the beginning of a RT will have the same accel issue
right - once we fix it on lathe we can port that fix to RT
won't change the backout drag tho
it's pretty much the same code
yes I think the backout drag is a different problem completely
the lathe thing is one of those that I want a pencil to talk about
I added it to the discussion topic list - feel free to add notes to that
I'll have my lathe there to play with.
I considered making a separate "bugs to think about" section
(but it accels so fast it doesn't care)
we can fix that (the accel) with an ini edit
I really need to stop "avoiding"
I've been procrastinating on these shelves all day
cause I'm getting closer and closer to the "glue 12 pieces together at once" step
but doing those would let you avoid something else, so where's the benefit?
and I'm afraid I will run out of hands or clamps or both
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.
cool (the latter task anyway)
yep that sounds fun
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.
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
sometiing must be clogged up
jmkasunich: manual choke?
primer bulb that doesn't seem to do anything
little bulb primer?
heh, listening to Jimmy Buffet: "We are the people our parents warned us about"
maybe if it warms up a bit I'll look at that tomorrow
this has to be the coolest May I can remenber
which is strange after April had those 80-degree days
it will probably be 100 in June, and 60 in July
yeah - "the year of the sinewave"
I'm looking at that Mits manual linked in the CNCZone cutter comp thread
they say: (gotta type
it, so it'll take a sec)
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
so it seems they aren't doing more than one or possibly two segment lookahead
BOSS has lots of rules about 3 moves here and there too
I remember Ray saying soemthing about 3 and 5 blocks - may have been a different version of the Mits manual
I think our single step will work fine with concave comp due to the queueing we already have
sure - it's the infinite lookahead problem I'm thinking of
(even aside from the stuff jepler was working on, to see if you might gouge something other than the segment being run)
yeah that's a whole other ball of mud
ball of worms?
can of mud?
can of worm-filled mudballs
bag of worm castings
is the idea to eventually give cutter comp infinite lookahead?
that's not something I'm planning
(if that's what you're asking)
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
it would be great if it could look ahead several moves. it's hard...
yes we worked on it separately, and came up with different trade-offs
not sure which approach is better in the long run. mine is certainly closer to working in emc.
IMO infinite look-ahead is the CAM's job
but looking ahead a few lines can help you in corners
[03:52:52] <cradek> http://timeguy.com/cradek-files/emc/inside-offset.png
(see the little crossings in the corners?)
I plan that my code will detect a gouge in this case
even if the second move is an arc?
it just seems like more work to figure out where the arc is
whether you will intersect it
sorry I still don't follow
oh concave corners at arc-arc, arc-line, line-arc?
I have all that working
[03:56:36] <cradek> http://timeguy.com/cradek-files/emc/t3.png
the center one is the nominal path
all of those arcs are bigger than the offset distance
if not, it would gouge; I think that error is already detected
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
Just got a shot of xfce running emc and such. It's at http://imagebin.ca/view/MZwAVT5Q.html