* cradek waits for jmkasunich to test threading...
is it broken?
well I ... changed it
I decline to say whether it is or was broken
earlier, jmkasunich thought it "could use some improvement"
after using it more on my (very fast) lathe, I agreed
the problem just didn't show on my small (slower, but very high accel) lathe
I had the same problem with my very fast plasma cutter till you guys fixed it :)
different problem, but same thing - sometimes things only show up on a particular kind of machine.
my new bike http://i47.photobucket.com/albums/f163/johnplctech/GW1500.jpg
cool, you finally got one
yep, been a busy day today
took all afternoon to get all the paper work, inspection etc done
I often wish for a backrest on mine (cruiser style) but it would look silly
but you have a full sofa there - I bet it's very comfortable.
it is nice but I think there is a better one out there
I'm surprised it has pegs and not footboards
kinda glad cause there ain't much room to get your feet down
I bet that gets worse mileage than my everyday car
passenger has floorboards
should get 45 -50 mpg
ha, yeah right
you let me know :-)
depends on how you drive
you let me know :-)
I'll check it real good.
I'm off, bbl!
I get 17 mpg on my Z71 4 wheel drive extended cab truck
fenn_ is now known as fenn
cradek: "not moving when spindle goes backwards" is a behavior that I recall you demonstrating a year (or was it two) ago
it was two
the CNC workshop when we were over in the other building, behind the punchpress
you had just gotten threading working, and you did a demo where you killed the spindle in mid-G33
it stopped, you turned the chuck forward by hand, the tool followed, you turned it back, no movement, turned it forward again, no movement until you got the original stopping point, then further turning moved the tool
(doesn't mean it's not a bug,... just not new)
that's not the same thing
that's backing up along the trajectory
guess I don' t understand then
this is going forward along the trajectory like usual, except the spindle is counting the other way
imagine left-hand tapping, you must start in M4, not M3
are we talking about tapping or threadcutting?
I was thinking threadcutting, you can do LH by feeding away from the headstock in M3
yes, or M4, feed toward, tool upside-down
but this case is broken
that code is in the TP, right?
maybe I didn't explain the bug well enough
yes it's a TP bug
the code assumes that spindle position will be incrementing, not decrementing
just tried it on my heavy machine - threading sync works *much* better
yes that's exactly it
good - thats something I've been meaning to look into - it is bad on my machine
I hope you can try it soon and let me know
I usually allow 1/2" of "air-cutting"
I got by on a recent project with .3" but it did a lot of ringing around before it synced up
my next operation is threading, but the machine is touched off already, I don't want to restart EMC to use trunk
at certain speed/feed, I think it would never sync
if you are doing 20 tpi at 500 RPM, you need to feed at 500/20 = 25 ipm
if the machine can do 30 ipm, it will take a long time to catch up
if it can do 26, it will take a really long time
I think I have enough granularity in the spindle encoder that the roughness I still see/feel is really just following
now it doesn't try to catch up - it just stays behind the same amount for the rest of the cut
how does it decide what the amount is?
whenever it matches velocity, that's the amount
so upping speed for a finish pass would be a disaster?
(that is what kept me from fixing this a long time ago)
it's well known not to do that :-)
well known by who?
I think everyone (?)
I wouldn't say that
I'm definitely open to better fixes
with version 2.2 you could turn the spindle by hand and still have each pass cut the same place
yes, I'm afraid that's definitely not the case anymore
does CSS work for G33?
I don't think I've ever tried that
I was thinking about the problem (again) the other day, and had one idea
all my ideas have involved calculating an offset and using it regardless of the actual speed
but what offset - the latest idea is that if you know the thread pitch and the axis (or traj) speed limits, you can compute the maximum possible speed to cut that thread
use that speed to compute the offset
max possible spindle speed you mean?
for example, if the axis can do 26 ipm, the fastest spindle speed for a 20 tpi thread is 520 RPM
but then if you need a very small start distance you can't get it no matter how slow you cut
the sync will always be the sluggish worst case
seems like you have to assume something about the spindle speed - but what? "it won't change much"?
another problem with the simple offset approach is that if you are running well below max speed, the tool will actually go backwards at the start, to get "on the path"
I'm sure that could be fixed, it just makes things slightly more complex
that's unacceptable but seems like it would be easy to avoid
basically we're talking about matching speed to a moving target
sure, and one with infinite accel (at least at the start)
matching position, to be more precise
old version, we don't start until the target passes us, so we have a lot of catching up to do
matching speed and position, right
new version, we stay a certain distance behind - whatever is convenient
your new approach waits till the target passes you, then matches speed and position to a secondary target that is dragging behind the original one (the offset)
unfortunately there is no guarantee that the 2nd dragging target will have the same length of string tying it to the main one on every pass
so the assumption is that when we're accelerating, the spindle speed is close to the nominal speed
I think we *do* know we're outside the work at this time
(if not, there are bigger problems with the resulting part)
that isn't the issue
you calculate the offset on every pass, and it is a function of speed
if the offset differs between passes, the cuts won't be in the same groove
you are right. I guess it is a bad solution.
I would't say "bad"
if speed is consistent, so is offset
that can solve a lot of problems for a lot of situations
just because every solution seems bad doesn't make this one not bad
but we sure need to tell people about the limitations
if somebody roughs a thread at one speed and the speeds up the spindle for a spring pass or two, they'll be surprized
I wonder if they could really do that before this change.
going back to the catching a moving target metaphor - I think the ideal is to start running before the target arrives at the starting line
sure but we don't have pre-index
where is it written that we _must_ start moving on the first index pulse
1st pulse - measure speed
2nd pulse - go!
actually, thats not right
1st pulse - start measuring speed
when you have a decent speed estimate (regardless of whether that takes 1/20th of a rev, or several full revs), compute the offset
suppose the offset is 3.2 revolutions
re-assert index-enable again
when index is detected, position is zero - we're gonna put the target at 4.0 revs
so at 0.8, start running
at 4.0, we should be matched
so there really is an offset, but it is an integral number of revs
if speed changes, it might take 5.3 revs to catch up, offset is 6.0, we hit the same groove
so you assume only that the speed doesn't change much in pretty-much-adjacent spindle revolutions
that is a much less risky assumption to make
yes - with the exception of CSS while cutting a flat spiral thread (like in a lathe chuck) it is impossible to command a speed change during a single pass
the code will be a _lot_ more complex to do that though
your current fix doesn't actually calculate the offset does it? it just remembers the offset that exists when the speeds are matched
I preferred that it didn't have to know about any spindle constraints etc.
madly, I didn't stop to think about subsequent passes
in fact I was concentrating on tapping the whole time - the more complex case
ah - that explains it
tapping is *usually* a one-pass thing
although I've heard of peck-tapping
yeah, but only usually
yes and I've been tempted to do it in the last week or two (hand taps, blind hole, lathe)
but then I came to my senses
good reversing spindle ;-)
I can't reverse my lathe (or mill)
so of course the only case I think about is singlepoint threading
jmkasunich: I wonder if I should leave this or back it out.
its in trunk, right?
put a "don't change the speed" warning in the manual, and maybe we can think of something better before release
maybe I will try cutting some threads with it.
steves_logging is now known as steve_stallings
regarding spindle sync for threading - some, probably most, commercial CNC lathes evaluate the "air cut" lead in distance versus known machine paramaters and refuse to start the cut if it is not within accel capabilities of the machine
steve_stallings is now known as steves_logging
looks like Ricardo Martinez is going to make a good contender for the "least appropriate use of image-to-gcode" prize (if there were one)
please..... tell more
user list email
he's got some profile like part of a slotted wheel, which would be much better milled with a profile cut
rather than raster
and the settings he used (and the image quality) were pretty bad for the application
(and I wanted to *say* that, but emc doesn't include any vector-to-gcode converters but it does include a raster converter...)
(quick, somebody write a vector to gcode converter that sucks so we can bundle it with emc and get another bullet item)
hey - you're the quick prototyping guy
there are several out there just drifting
not sure why img2gcode is bundled in the first place
because some guy with commit privs wrote it
Write a vector to raster converter and then use image to gcode. Why do it wrong when we can do it *very* wrong.
n/m.. found what the module was called
is there a reason we aren't building the sim packages on hardy?
good night all