#emc-devel | Logs for 2007-07-19

[13:25:49] <jepler> cradek: any more fallout from the merge of nineaxis?
[13:41:19] <steves_logging> steves_logging is now known as steve_stallings
[13:42:43] <steve_stallings> .. just more interest in finding solutions for more complex situations like velocity compensation for rotary and compensation for stretched wire (EDM, foam) machines
[13:47:56] <steve_stallings> rotary velocity is computable if you know the center of rotation, so why not make it easier to find the center of rotation
[13:48:59] <steve_stallings> we could define a new type of "offset" setting G code that would allow the program to move to a known place with respect to the center of rotation, and then specify the actual location with paramaters
[13:50:02] <steve_stallings> thereafter velocity comensation could take in to account actual cutting velocity produced by rotary motion until such time as the comp was cancelled
[13:50:54] <jepler> cradek: here's one -- it looks like old .var files don't work if they don't specify the UVW coordinates of each coordinate system
[13:51:02] <jepler> emc/task/emctask.cc 312: interp_error: Required parameter missing
[13:52:39] <jepler> steve_stallings: that seems like a tough problem to solve for general machines..
[13:53:28] <cradek> jepler: yes, that's mostly why I sent that mail warning about var files
[13:53:39] <jepler> cradek: oh you did?
[13:53:39] <jepler> silly me
[13:53:59] <cradek> well I probably hid that important information in paragraph 17
[13:54:07] <jepler> it would be nice if emc was more forgiving about the .var file
[13:54:08] <cradek> you know how I like to hear myself type
[13:54:27] <skunkworks> click - click - clickity click.
[13:55:02] <steve_stallings> the rotary solution is not machine dependent so long as ABC rotate about XYZ as defined in normal manner
[13:56:01] <steve_stallings> machine geometry does not need to be known, only distance from imaginary center of rotation and the tool tip, and that is specified by the programmer using the offset G code
[13:56:14] <cradek> steve_stallings: I can see the easy solution if there's one rotary, but I'm not seeing it for three because I don't see where the "center" is anymore
[13:56:53] <cradek> oh maybe I see what you mean
[13:57:12] <steve_stallings> do we allow more than one rotary axis to move at a time?
[13:57:15] <cradek> throw TLO into the mess and it gets evil fast
[13:57:23] <cradek> oh sure, all 9 axes are coordinated
[13:58:46] <cradek> I understand that people who do 5 axis machining use inverse time mode exclusively - maybe the XYZA configuration is really the only important one to worry about
[13:59:01] <steve_stallings> oops, I missed the obvious, if a rotary motion moves the cutter head instead of the workpiece, then the motion affects more than one linear axis
[13:59:48] <cradek> I suspect people with XYZA machines often just index with A, so this doesn't matter
[14:00:22] <steve_stallings> I think handling XYZA, XYZB, and XYZC, each allowing only a single rotary axis that moves the workpiece, would be a worthwhile improvement
[14:01:14] <steve_stallings> XYZA setups are used for lots of things more complex than indexing, like cutting cams, spiral groves, etc.
[14:01:14] <cradek> do you have a current project/application/customer where this is a problem or is it just ugly that it's the way it is?
[14:01:59] <cradek> sure I'm not saying that it's only for indexing, just that I think it's probably most common
[14:02:02] <steve_stallings> who me, I don't actually cut anything.... 8-)
[14:02:11] <cradek> ah :-)
[14:02:33] <cradek> I am not trying to be difficult, I just wondered because I don't recall any users asking about this
[14:03:12] <steve_stallings> people must be trying combined motion moves, else we would not have heard about the issues
[14:03:38] <cradek> I don't follow
[14:03:44] <cradek> (what issues?)
[14:04:02] <cradek> it works as defined in ngc, and it only came up because I explained how it works on the list again
[14:04:58] <skunkworks> I want to be able to do this type of machining some day. http://www.youtube.com/watch?v=EdWWvnrFA9k
[14:05:12] <steve_stallings> does the current planner properly handle a combined move with a very short linear move and a 180 degree rotary without overspeeding the rotary?
[14:05:26] <cradek> steve_stallings: yes that stuff is 100% right
[14:06:35] <steve_stallings> guessing at method.... evaluate time to make XYZ move and time to make rotary moves, then scale to match slower of the two?
[14:06:58] <cradek> yes something like that
[14:07:46] <cradek> those combined moves used to be terribly buggy but I fixed them all in early '06
[14:07:59] <cradek> (before 2.0.0)
[14:08:11] <steve_stallings> OK, I am still remember old problems that cause rotary to attempt impossibly fast motion when linear was short move
[14:08:19] <cradek> yep I remember that too
[14:08:29] <skunkworks> cradek worked his magic. :)
[14:08:36] <cradek> and there were problems with acceleration being too slow (because it was in degrees or something)
[14:08:50] <cradek> rotaries in old EMC1 really worked pretty badly
[14:09:33] <cradek> but now you can g0 x.001 a90 b180 c270 and get a perfectly sane move
[14:09:57] <cradek> but now you can g0 x.001 y.002 z.003 a90 b180 c270 u1 v2 w3 and get a perfectly sane move
[14:10:04] <cradek> haha
[14:10:16] <steve_stallings> great, sorry for the confusion
[14:11:09] <cradek> nah, no problem
[14:11:25] <cradek> maybe you just haven't used emc much lately
[14:11:36] <steve_stallings> so, if you add an F(eedrate) parameter to the above moves, what is it based on?
[14:12:51] <steve_stallings> my EMC usage is pretty much limited to jogging, need more time, need more time...
[14:13:27] <cradek> steve_stallings: http://article.gmane.org/gmane.linux.distributions.emc.user/2434
[14:13:40] <cradek> ^^ I described the F word behavior here
[14:15:08] <cradek> in both of the above moves F is in linear units per minute along the cartesian XYZ move, but it's probably going to be limited by C's motion
[14:15:47] <cradek> (if you were a g1 and you were cutting, you'd probably want to be using inverse time mode)
[14:16:41] <steve_stallings> so the max axis velocity of the rotary axis will slow a linear move if the linear feedrate would exceed the max velocity of the rotary axis, but otherwise the influence of rotary motion on the tool tip speed is ignored
[14:17:05] <cradek> yes
[14:17:49] <cradek> that's what NGC says to do, fwiw
[14:18:16] <steve_stallings> so controlling cutting tip speed during rotary motion is still something that must be controlled by inverse time or fudged linear feed rates
[14:18:34] <cradek> yes
[14:18:43] <cradek> well, not exactly
[14:18:53] <cradek> rotary ONLY motion has degrees/minute feed
[14:19:22] <cradek> but for combined moves, yeah inverse time mode is your friend
[14:19:39] <cradek> the fudging would be no fun - very finicky for combining short linear with long rotary moves
[14:19:43] <steve_stallings> OK, so my idea still has merit, but there is less of a need for it than I thought
[14:20:17] <cradek> yeah I would like for it to work better
[14:20:25] <skunkworks> Does the ngc pdf have a good explaination how inverse time works?
[14:20:32] <skunkworks> * skunkworks has never used it.
[14:20:33] <cradek> skunkworks: yes
[14:20:36] <skunkworks> Thanks
[14:20:56] <cradek> skunkworks: the idea is you tell it how long the move should take, whatever the move happens to do
[14:21:06] <steve_stallings> now ask if any affordable CAM system provides computations for inverse time mode
[14:21:37] <cradek> what is an affordable CAM system? I've never heard of this
[14:23:04] <skunkworks> ah - that is easy.
[14:23:29] <cradek> actually I bet there is CAM between hobby and pro grade, that just barely handles greater than 3D...
[14:24:16] <cradek> steve_stallings: have you done any 5 axis cam/cutting?
[14:24:35] <skunkworks> cnczone would be a place to look.. They pretty much have a forum for all the cam software.
[14:26:40] <cradek> the two lower dollar cam packages I've heard about are synergy and bobcad, and I've not used either but I've heard reports for both ranging from "ok" to "terrible"
[14:26:42] <steve_stallings> no, only watched a machine
[14:27:04] <steve_stallings> I have the rotary axis option for Vector, but it is pretty limited
[14:27:07] <cradek> steve_stallings: me too, and talked to the programmer a bit
[14:27:22] <cradek> steve_stallings: (... and pined for a machine like that)
[14:27:44] <steve_stallings> configuration must be A as trunion on table, and B as tilting head
[14:28:09] <steve_stallings> even then things are handled as imaginary planes, not full 3D
[14:28:09] <cradek> that's not particularly common is it?
[14:29:00] <cradek> the machines I've seen (in person and youtube) had the head doing both rotaries, or the table doing both
[14:29:06] <steve_stallings> I would guess that A on table, B on head is one of the top three configurations
[14:29:13] <cradek> ah ok
[14:29:14] <steve_stallings> RAB uses it for his Taig
[14:29:33] <steve_stallings> and I have seen it on retrofitted knee mills
[14:30:29] <cradek> since I'll probably never spend money on modern CAM, maybe I should suck it up and learn APT
[14:30:40] <steve_stallings> ah, I just realized that my offset scheme can work with the cutting head in motion, the offset just becomes the distance from the tool tip to the pivot point
[14:31:04] <steve_stallings> now planning the moves is still mucho complex in that mode
[14:31:48] <steve_stallings> I really hope RAB does eventually move his toolkit into a plugin for Rhino
[14:31:57] <cradek> the lathe CSS requires that the absolute homed 0 position of the X axis (without TLO) is the center of rotation of the work. seems like a similar requirement/simplification could be made with your scheme, but I don't quite see it
[14:32:53] <cradek> with XYZA I can sort of see it, you'd home Y and Z so they give the tooltip at the center of A's rotation
[14:33:07] <cradek> but for 5 axis I'm lost
[14:34:01] <steve_stallings> OK, for XYZA first, homing to center of A rotation is not practical due to interference, so you home a known distance away and provide an offset to the imaginary center
[14:34:26] <cradek> well you can set 0 anywhere, even if you can't move there, homing is flexible
[14:34:48] <cradek> so I think that's not a problem
[14:35:15] <steve_stallings> and I don't like the use of the term home, as I prefer a co-ordinate system shift, semantics I guess
[14:35:16] <cradek> or looking at it another way, the offset you are talking about is just the homing parameter
[14:36:08] <cradek> well homing an axis means a certain thing: setting 0 at a certain place in the axis's motion - I agree anything else is semantics
[14:36:33] <cradek> brb, work
[14:36:44] <steve_stallings> normally velocity is the square root of the sum of the squares of X, Y, and Z velocity
[14:37:42] <steve_stallings> if we add a fourth term as the velocity of the tool tip caused by the rotation we get an approximation that should be usable, though not mathematically prefect
[14:39:32] <steve_stallings> the fourth term would be based on the distance of the tool tip from the center of rotation as computed using the imaginary center and any Y or Z motion (assuming A axis imaginary center)
[16:43:35] <skunkworks> skunkworks is now known as whoami
[16:44:23] <whoami> whoami is now known as skunkworks