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