Back
[00:03:28] <mshaver> ah
[00:03:31] <cradek> the next move being a line is pretty foolproof - you just move to the new end of it
[00:03:31] <cradek> but an arc requires serious monkeying to get right
[00:03:31] <rayh> looking
[00:03:31] <petev> cradek, but need to make a correction for rel coord mode
[00:03:31] <cradek> petev: I think that's handled fine, but of course could be wrong without testing
[00:03:31] <mshaver> arc_rad must be > than tool_rad I guess
[00:03:31] <cradek> petev: did you run your tests mentioned in that email yet?
[00:03:31] <rayh> The behavior of the exit move is different in emc2 than it was in bdi.
[00:03:31] <petev> no, it's still work time for me here in CA
[00:03:31] <cradek> mshaver: yes that too
[00:03:31] <cradek> petev: oh ok :-)
[00:03:31] <rayh> You mean to start an exit arc tangent to the point where the two arcs join.
[00:03:31] <cradek> mshaver: well now that I think about it, I don't know - if it's too small, you maybe don't fully exit the work, but you do get back to the programmed path
[00:03:31] <rayh> What I see on your post is caused by to large an r value.
[00:03:31] <cradek> rayh: if you turn off comp you can see the Rs on entry and exit match
[00:03:31] <rayh> The proper r is 1/4 the tool diameter subtracted from the r without comp.
[00:03:31] <cradek> that's a bug you're working around then
[00:03:31] <cradek> you should not have to change Rs when you use comp
[00:03:31] <rayh> I guess you could say it that way. The bdi run aparently did correct for this without intervention.
[00:03:31] <rayh> Let me run that again and get back.
[00:03:31] <cradek> ok please take a picture if you can
[00:03:31] <mshaver> how could path_r be too big?
[00:03:31] <cradek> mshaver: R format hides the real problem, which is that the beginning point is not where you expect, so the arc is mangled (because the center is not adjusted accordingly)
[00:03:31] <cradek> if you use IJ format, it will error with "endpoints at different radii" as soon as you try to use comp
[00:03:31] <mshaver> oh, ok R format
[00:03:31] <mshaver> yep, diff rad to endpoints, that was what I was thinking about
[00:03:31] <cradek> yeah when I change line 7 to i-.5 j0, it gives that error as soon as I try to use comp
[00:03:31] <cradek> so we'll need special handling for the first move after comp is turned off, just like the first move after turning it on is special
[00:03:31] <mshaver> it's the same case in the opposite direction
[00:03:31] <cradek> yep
[00:03:31] <cradek> any volunteers? :-)
[00:03:31] <petev> cradek, on the lead out, it may be more important to keep the initial trajectory and have a discontinuity to the next move
[00:03:31] <petev> if so, you could use the same code, viewing the move in reverse like matt suggests
[00:03:31] <cradek> petev: I agree
[00:03:31] <cradek> petev: this picture of ray's will end up being symmetrical
[00:03:31] <cradek> here's a better picture:
http://timeguy.com/cradek-files/emc/bad-exit.png
[00:03:31] <cradek> (bigger tool makes it worse)
[00:09:19] <cradek> bbl, dinner
[00:19:04] <rayh> Nope. I was wrong. My use of variables in the gcode masks the fact that the ending move is not tangent.
[00:20:47] <rayh> bbiab
[00:50:29] <mshaver> A different question: To generate function call graphs I need gcc to output some debugging files which it will do if I add -dr to the gcc command line. I've changed my Makefile to add -dr to CFLAGS CXXFLAGS and EXTRA_CFLAGS, but there are still some files being compiled without this option. Where else do I need to add this?
[00:50:59] <mshaver> back shortly - eating
[00:51:04] <jepler> mshaver: which file(s)
[00:51:21] <mshaver> i thought someone would ask that...
[00:51:54] <mshaver> it's mostly the xxx.mod.c files, let me make a list...
[00:52:09] <jepler> ah -- that's deep kernel makefile voodoo
[00:52:25] <jepler> let me suggest that you would have more control (but lose information about driver files) if you try --enable-simulator
[00:52:48] <jepler> it's quite possible that the kernel build system simply ignores your compiler flags for .mod.c files, which are files generated by kbuild
[00:53:04] <mshaver> kvming to the dev machine - i'll look at that option
[00:53:19] <mshaver> are all the flags in the top Makefile?
[00:53:41] <jepler> mshaver: in some of the Submakefiles there are additional flags that apply only to a few files
[00:53:58] <jepler> $(call TOOBJSDEPS, $(TCLSRCS)) : EXTRAFLAGS = $(ULFLAGS) $(TCL_CFLAGS)
[00:54:12] <jepler> for instance, all the files that are named in the variable TCLSRCS are compiled with TCL_CFLAGS in addition to the regular flags
[00:55:09] <jepler> (that's from emc/usr_intf/Submakefile)
[00:55:17] <mshaver> let me read those first, make a list & get back to you in an hour or so (food calls)
[00:55:23] <jepler> OK
[02:43:34] <a-l-p-h-a> a-l-p-h-a is now known as kill-9
[02:46:10] <kill-9> kill-9 is now known as a-l-p-h-a
[15:51:29] <rayh> After yesterday's comp work, I'm prepared to offer a suggestion about the leadout for arcs.
[16:06:51] <SWPadnos> rayh, is your suggestion different from what Chris did? ;)
[16:07:45] <SWPadnos> nevermind. I guess there wasn't a change to lead-out
[16:11:38] <cradek> http://pastebin.ca/raw/387717
[16:11:44] <cradek> ^^ another wrong exit case
[16:12:11] <SWPadnos> out of curiosity, has a combined daimeter + length comp move been tested?
[16:12:18] <SWPadnos> like a helix entry
[16:12:25] <cradek> yes helix works
[16:12:41] <cradek> the second regression test does that
[16:12:59] <SWPadnos> ok - helix combined with initiation of length offset was the main thing
[16:13:20] <cradek> oh I didn't try tool length offset
[16:13:36] <cradek> that's not actually in the interpreter - it's at the canon level
[16:13:52] <SWPadnos> strange that length is canon but diameter is interp
[16:14:22] <SWPadnos> petev and I discussed that a bit - there are radius comp functions in canon, but they're stubs
[16:14:24] <cradek> fwiw:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/tests/ccomp/mill-g90g91g92/test.ngc?rev=1.2
[16:14:36] <cradek> (single-helix entry)
[16:14:48] <SWPadnos> ok
[16:17:59] <rayh> Since as Pete pointed out, a single arc move into diameter comp is not an accepted ability of ngc --
[16:18:15] <SWPadnos> it is now ;)
[16:18:19] <rayh> I'm prepared to say that we write the spec and do it whatever way we choose.
[16:18:36] <SWPadnos> there have been several of those lately, I think
[16:18:43] <rayh> Sure.
[16:18:55] <SWPadnos> though I can't remember the specifics of the other concerns at the moment
[16:19:07] <cradek> rayh: I'm pretty convinced that all entries work right now, including single arc -- now I wonder what to do about exits, which aren't really mentioned in the ngc spec
[16:19:38] <rayh> Right. I favor making the arc out work like the arc in.
[16:19:56] <cradek> I agree
[16:19:58] <rayh> set an end point that will be tool center
[16:20:01] <cradek> your nice test case should show symmetry
[16:20:29] <rayh> Sorry I was confused by the variables case I wrote in 95.
[16:20:41] <cradek> np
[16:21:03] <rayh> I woke up remembering a conversation I had with Tom about that.
[16:21:20] <cradek> oops brb
[16:22:30] <SWPadnos> ooops is a bad leading word
[16:26:06] <SWPLinux> weird - that last test case didn't even turn off comp
[16:29:05] <rayh> I didn't see that with the pasted code.
[16:29:20] <SWPLinux> hmmm
[16:29:25] <rayh> I do see a big gouge on the lead in.
[16:29:37] <SWPLinux> oh - maybe I should update ;)
[16:29:43] <rayh> if this is an outside mill
[16:30:19] <rayh> and that is the side of the 0 tool circle.
[16:31:00] <rayh> let me try that on bdi and see what it does there.
[16:32:57] <SWPLinux> the plot changes if you add an X word on the exit move
[16:33:11] <SWPLinux> even if it's X2 (where it's supposed to be already)
[16:33:37] <SWPLinux> I noticed that the code has an X tool offset, but no Y - I wonder if this is related to that
[16:36:50] <cradek> SWPLinux: yes that's the bug (that X doesn't end up being 2)
[16:37:12] <SWPLinux> it works if you change the G40 line to G40 G1 X2 Y3
[16:37:24] <cradek> the initial "gouge" isn't a gouge - it's just a bad way to enter - it's a nice entry just considering the first arc
[16:37:32] <SWPLinux> actually, I should say it's different with the X2 in there vs. without
[16:38:13] <cradek> yes I agree
[16:38:22] <cradek> it shouldn't be different (it should go to x2)
[16:39:23] <SWPLinux> I guess my point is that X is already 2, so the existence of the X word is the key - X is already 2 when that line executes
[16:39:54] <cradek> yes I think we're saying the same thing
[16:39:56] <SWPLinux> ok
[16:39:59] <SWPLinux> :)
[16:40:06] <cradek> that's the bug I wanted you to see when I pasted the program
[16:40:14] <SWPLinux> ok - I saw it
[16:40:41] <SWPLinux> I was more surprised that the X word "corrected" it than the fact it's wrong sometimes
[16:41:16] <cradek> exiting needs a lot of thought
[16:41:36] <cradek> even with your added X word to work around that bug, you'll see that it doesn't exit tangentially with an arc (like it enters)
[16:41:38] <SWPLinux> it "shouldn't" (not that I'm disagreeing with you on the reality of the situation)
[16:42:08] <SWPLinux> I don't think a tangential exit is as important, but I'm almost surely missing something
[16:42:24] <cradek> yes, it's probably not as important
[16:43:02] <SWPLinux> but it is annoying that a problem that's symmetric to an already solved one is still there
[16:43:15] <cradek> SMOP
[16:43:40] <SWPLinux> SMOUTCAIITAMOP
[16:43:50] <cradek> eh?
[16:43:56] <jepler> did matt say what program he used to generate the include file statistics and graphs?
[16:44:01] <SWPLinux> "simple matter of understanding the code as it is, then a matter of programming'
[16:44:17] <cradek> jepler: the initial email may have said something like that
[16:44:21] <SWPLinux> I think he did
[16:44:31] <SWPLinux> he also sent a tar with the scripts
[16:45:15] <jepler> ah found it
[16:45:17] <SWPadnos> ora link to it anyway
[16:53:41] <jepler> mostly by getting rid of broad includes from emc.hh where possible, I've somewhat reduced the number of inclusions in much of the system:
http://pastebin.ca/387758
[16:57:17] <jepler> http://emergent.unpy.net/files/sandbox/include_graphs/index-by-size.html
[16:59:25] <jepler> and rcs.hh, I should say
[16:59:49] <SWPadnos> it still compiles, right? ;)
[17:00:24] <jepler> yes
[17:00:33] <jepler> haven't actually run it yet though :-P
[17:00:37] <SWPadnos> heh
[17:01:22] <jepler> it does run
[17:01:59] <SWPadnos> I'm just looking at the iosh graphs
[17:02:07] <SWPadnos> was timer included for semaphore stuff or something?
[17:02:45] <jepler> timer is used when waiting for an nml request to be completed
[17:02:52] <jepler> esleep() and etime()
[17:03:00] <cradek> http://timeguy.com/cradek-files/emc/semi.ngc
[17:03:00] <cradek> http://timeguy.com/cradek-files/emc/semi.png
[17:03:14] <cradek> better demo of the problem (red is uncomped path)
[17:03:53] <cradek> the tool should end up at the same endpoint (the upper red line)
[17:04:05] <cradek> but notice that if it did, it would gouge the work if it went there in a straight line
[17:04:42] <SWPadnos> ok - you need a magic arc in there
[17:04:57] <cradek> yes the exit move needs the same magic arcs comped moves get
[17:05:44] <SWPadnos> right. that move mught not gouge, but if it had a lower X ordinate it would (G1 X0.5 Y1 or something)
[17:07:33] <rayh> the lead in gouge from cradek's first paste is there in BDI as well
[17:07:35] <cradek> yeah, it might miss, I'm not sure
[17:08:07] <rayh> took a while cause I don't have bdi on my net.
[17:08:26] <cradek> rayh: that's not a gouge since that move is later in the program - my bad program distracted from the real thing I was trying to show
[17:08:37] <cradek> this later program "semi" shows it much better
[17:09:54] <rayh> okay let me see.
[17:10:25] <SWPLinux> I don't think it's possible to calculate the needed arc for the exit
[17:10:25] <cradek> red is the programmed path, tool is at the correct endpoint, white is the comp program, you can see it doesn't end at the endpoint
[17:10:49] <cradek> oh??
[17:10:54] <SWPLinux> the arc is based on past moves (an unknown amount in the past), not future moves like lead-in
[17:11:38] <rayh> um, this is an inside pocket?
[17:11:54] <cradek> no, cutting ccw around the red
[17:11:56] <SWPLinux> no - outside
[17:12:18] <rayh> so the white is the comp tool path.
[17:12:23] <cradek> SWPLinux: I don't follow - it just has to go around the "last" corner
[17:12:26] <cradek> rayh: yes
[17:12:46] <SWPLinux> hmmm
[17:12:57] <SWPLinux> ok - previous move to exit move. maybe
[17:14:09] <cradek> not even that - you have current tool point, current programmed point, desired next direction
[17:14:34] <SWPLinux> here's my test case:
http://www.cncgear.com/Files/semi2.png
[17:14:59] <SWPLinux> as you can see, I only added X0.5 to the exit move
[17:15:07] <cradek> yes
[17:15:29] <cradek> move the g40 under it, and you can see the necessary arc (endpoint will be wrong of course)
[17:15:32] <SWPLinux> you need to know the previous tangent to get the correct arc
[17:15:43] <cradek> yes, and you have that
[17:15:44] <SWPLinux> not just the current point
[17:15:46] <SWPLinux> ok
[17:16:08] <cradek> the tool has stopped tangent to the previous move and touching its end
[17:16:29] <cradek> those two points give you the tangent direction (they are perp to it)
[17:16:58] <cradek> that's how all of comp works
[17:17:31] <SWPLinux> ok, so you have actual and programmed positions to get tangent from
[17:17:35] <cradek> yes
[17:18:01] <cradek> I could still be wrong, but I think that's enough to turn the corner and go to the desired point
[17:18:09] <cradek> it will take TWO arcs, just like entry lines
[17:18:50] <SWPadnos> two arcs or two moves?
[17:19:06] <cradek> two extra arcs and then a line
[17:19:08] <SWPadnos> the first obviously needs to be an arc, but I don't see a second arc for a linear exit
[17:19:14] <SWPadnos> hmm. why the second?
[17:19:41] <cradek> just for tangency
[17:19:56] <cradek> otherwise you'll get a corner between the two moves
[17:20:11] <SWPadnos> hmm
[17:20:18] <SWPadnos> indeed
[17:21:14] <cradek> well, maybe not, line entry doesn't do that
[17:21:21] <cradek> * cradek furrows
[17:21:38] <SWPadnos> join the club :)
[17:22:26] <cradek> http://timeguy.com/cradek-files/emc/semi-exit.png
[17:22:37] <cradek> imagine the cyan move is the exit
[17:22:55] <cradek> the exit move would generate that corner arc too
[17:23:12] <cradek> currently, it would not, and gouge off the corner
[17:24:14] <cradek> imagine a circle around that upper right programmed point
[17:24:33] <cradek> the cyan line is fixed on the programmed endpoing (x1.5 y0) and you lean it against the circle
[17:24:41] <cradek> that is the arc you want
[17:24:52] <cradek> (circle rad = tool rad)
[17:25:00] <SWPadnos> yep
[17:25:30] <SWPadnos> the arc must be tangent to a line through that point at some point, so only one arc should be necessary
[17:25:32] <cradek> now what if the exit is an arc!?
[17:25:42] <cradek> yes I agree now
[17:25:51] <SWPadnos> then it gets the same treatment as a lead-in? (only backwards)
[17:25:59] <SWPadnos> :)
[17:26:12] <cradek> no quite - it has to go around the corner first
[17:26:15] <cradek> not
[17:26:42] <cradek> that case seems pretty hard to me
[17:27:03] <rayh> Why should we not consider this a part program error?
[17:27:42] <SWPadnos> actually, this test case has a simplification in it. the tool happens to be offset along the upper edge of the part. if it were a different shape (like a triangle on top of the semicircle), you'd have no way of preventing a gouge
[17:27:56] <cradek> because the programmed path is right (if you have a .00001 diameter tool it would cut it perfectly without comp), but when you use comp with a larger tool, the part gets gouged
[17:28:11] <SWPadnos> that's where you'd have to know arbitrarily far back to know the part shape
[17:28:24] <rayh> there is at least that much gouging comp slop.
[17:28:25] <cradek> you can only not gouge the last move
[17:28:46] <cradek> comp only ever knows one corner, NOT the part shape
[17:29:07] <SWPadnos> right
[17:29:31] <rayh> am i seeing this move right. tool comes along white from the top, goes around, along the top then away and down.
[17:29:59] <cradek> yes
[17:30:17] <cradek> but, it was actually plotted the other way - the cyan line was programmed as an entry move
[17:30:29] <cradek> I wanted us to imagine it backward, so we can see what the exit move should look like
[17:30:50] <cradek> currently, if this was programmed cw like we're imagining, it would gouge off the top right corner
[17:31:03] <cradek> because the upper right arc wouldn't be generated
[17:31:57] <rayh> when do you turn off comp?
[17:32:11] <cradek> upper right corner of the semicircle
[17:32:16] <SWPadnos> just before the cyan move, in the thought experiment
[17:32:19] <cradek> at least that's the way we're imagining it
[17:32:50] <rayh> okay. Why doesn't the part writer push that line beyond the part.
[17:32:59] <rayh> all of the folk I know do that.
[17:33:23] <cradek> I agree it's fairly easy to work around this problem in comp
[17:33:41] <rayh> I'm not certain that it is a problem.
[17:34:15] <rayh> It's always possible to run a tool through the work in a place that wasn't intended.
[17:34:20] <cradek> I think it is a real bug that may not matter much in the real world
[17:34:58] <rayh> but this exit move is yours to do right. it isn't autogenerated.
[17:35:27] <cradek> yes currently this program (clockwise) would not generate that top right arc, and it would cut the corner off the part
[17:36:10] <rayh> um but what tells the machine where the end point is?
[17:36:11] <cradek> (if the exit move is more straight down, it would cut a lot off)
[17:36:32] <SWPadnos> rayh, you're asking the same questions I did 20 minutes ago :) (only with different words)
[17:37:02] <rayh> and I can't see how this is in any way related to an error in comp.
[17:37:09] <rayh> It is an error in programming.
[17:37:11] <SWPadnos> it's both though
[17:37:15] <rayh> part programming
[17:37:30] <SWPadnos> comp can't prevent you from screwing up your part, but it can go around corners instead of cutting them off
[17:37:32] <cradek> I'm off to lunch
[17:37:38] <SWPadnos> see you cradek
[17:37:43] <rayh> Not after it's been turned off.
[17:37:57] <rayh> It doesn't know there was a corner there.
[17:38:15] <SWPadnos> as chris explained it to me, the comp code does have the actual tool position and the programmed position
[17:38:26] <SWPadnos> from that, it can get the vector it was on (tangent)
[17:38:44] <rayh> the part program author has to know
[17:38:55] <SWPadnos> if the next move is a cusp, then it can put in an arc (just as it does during compensated moves)
[17:39:03] <SWPadnos> then move to the programmed point
[17:39:05] <rayh> Sure comp knows the vector but that vector is pure x at the point when it's turned off.
[17:39:40] <SWPadnos> right, so an arc like those around the corner of a box may protect the part, and is reasonable for the comp code to put in
[17:39:49] <rayh> If the author went around that corner a second time and then turned comp off it would work properly.
[17:39:53] <SWPadnos> it may not protect the part, but it's all that can be done
[17:40:00] <SWPadnos> yes
[17:40:14] <rayh> Nothing in NGC knows "box"
[17:40:24] <SWPadnos> to put on a sarcastic hat, if the programmer used a compensated path, we wouldn't need comp at all ...
[17:40:41] <rayh> I think we are thinking cad here not gcode
[17:40:54] <SWPadnos> NGC doesn't know about boxes, but the comp code does know about corners
[17:41:02] <SWPadnos> otherwise it wouldn't be able to add arcs around them
[17:41:06] <rayh> i like that sarcastic hat except for reground endmills.
[17:41:11] <SWPadnos> heh
[17:41:31] <SWPadnos> jus trerun the post - it only takes a couple of minutes these days ...
[17:41:53] <SWPadnos> (that's actually the answer one person I know uses, and it works for him)
[17:41:56] <rayh> But it does not know about the corner right under it unless we tell it there is a corner there.
[17:42:17] <SWPadnos> it does, because it knows the tangent of the previous move and the vector of the exit move
[17:42:26] <rayh> only true, run post, if the machine operator also knows how to do that.
[17:42:32] <SWPadnos> if they're not the same direction, an arc can be inserted
[17:42:37] <SWPadnos> yes :)
[17:42:40] <rayh> None of the operators I know are able to do that.
[17:42:50] <rayh> so second and third shifts are sol.
[17:42:53] <SWPadnos> this guy does, since he designs the parts as well (in SolidWorks)
[17:42:55] <SWPadnos> rigth
[17:43:15] <SWPadnos> I think he's a bonehead on that score, but he has a machine that works and makes him money
[17:43:27] <SWPadnos> it's only used fr prototyping, so it's not important for him
[17:43:36] <SWPadnos> (that's a major digression though)
[17:43:36] <rayh> You bet but we'd better not forget about the thousands who can't.
[17:44:28] <SWPadnos> of course
[17:44:32] <SWPadnos> not
[17:45:49] <SWPadnos> anyway - I think we have a handle on what can be done when turning off comp (and it's not everythng, for sure)
[17:46:02] <SWPadnos> but not necessarily for arc exits ...
[17:47:46] <SWPadnos> heh - we can define an "exit move" as one that moves away from the part ;)
[17:48:30] <rayh> that's a good plan
[17:48:55] <SWPadnos> which is probably how smart part programmers do it anyway
[17:52:25] <rayh> I'll tell you what I want is for comp to go away when emc errors and quits or when I press abort.
[17:52:54] <SWPadnos> is that in the spec or does that represent one of those evil spec changes?
[17:54:18] <rayh> I don't really know.
[18:07:25] <rayh> am I seeing that g0 turns off comp?
[18:08:22] <SWPadnos> dunno. are G0 moves supposed to be compensated? (silly question I know, but still)
[18:09:26] <rayh> ditto for me.
[18:13:37] <SWPadnos> ok - it appears that G0 should be compensated
[18:24:21] <skunkworks> should you be telling people how much you have bugeted for a retrofit? ;)
[18:24:41] <skunkworks> budgeted
[18:25:04] <alex_joni> what kind of people?
[18:25:33] <skunkworks> emc-users group.. ;)
[18:25:39] <alex_joni> _sure_
[18:25:40] <alex_joni> :P
[18:25:46] <alex_joni> * alex_joni is kidding
[18:25:52] <alex_joni> only if you feel like it
[18:28:08] <rayh> I've got an image that realizes our recent thought experiment.
[18:28:20] <rayh> I've lost the link to the image pastebin.
[18:28:55] <SWPadnos> www.imagebin.org ?
[18:29:12] <rayh> ah .org
[18:30:43] <SWPadnos> hmm. that post makes me want to get on the stick with that HNC I'm in lilne for :)
[18:31:18] <SWPadnos> $500 lathe, $1500 computer/IO cards, $500 drivers (maybe), and $25k in profit ;)
[18:31:50] <rayh> drool drool...
[18:32:11] <skunkworks> I can do it for 29,995 ;)
[18:32:17] <SWPadnos> that is of course only if the HNC is like a "toolroom lathe" - I'venever gotten all the lathe types sxtraight :)
[18:32:36] <SWPadnos> +' ', -x
[18:32:38] <rayh> http://imagebin.org/7562
[18:33:45] <SWPadnos> yep - that looks like the right concept
[18:34:16] <SWPadnos> oh - minus $1500 in shipping (but that would be their probaem anyway) :)
[18:34:46] <rayh> I added the last corner in there. Not the real corner but located at the same place.
[18:34:51] <SWPadnos> right
[18:35:23] <rayh> that leadout is 45 degrees
[18:35:53] <SWPadnos> it is for the uncompensated path
[18:36:20] <rayh> yep.
[18:37:16] <SWPadnos> a straight move from the compensated point would be <45 degrees, and the correct move is even less (measured from the path to the +X direction, counterclockwise)
[18:38:43] <rayh> correct?
[18:38:51] <SWPadnos> heh
[18:38:55] <SWPadnos> yes, of course it's correct! ;)
[18:40:36] <rayh> I guess I don't quite understand what you meant by "correct move."
[18:41:05] <SWPadnos> the line to the endpoint after the comp arc you put in
[18:41:16] <SWPadnos> so the rightmost diagonal in that image
[18:41:32] <rayh> ah right.
[18:41:46] <SWPadnos> I guess I had the sign wrong though
[18:41:58] <SWPadnos> from +X, it's >45 and even more
[18:42:03] <SWPadnos> not <45 and even less
[18:42:22] <rayh> True.
[18:43:07] <rayh> You'd see a knee in that line if I extended the last arc much more than .1
[18:43:41] <SWPadnos> the arc is found from center / tangent / tangent
[18:43:58] <SWPadnos> though I'm not sure exactly how to do that :)
[18:44:28] <SWPadnos> hmm. no, center, point, tangent (through point, not a known angle)
[18:44:40] <rayh> But my point is that unless you add the line that forms that corner, the interpreter does not know that there is even one there.
[18:45:17] <SWPadnos> yes it does, but it's the corner between the last compensated move and the exit, not the corner between the semicircle and the last compensated move
[18:45:55] <SWPadnos> so the corner the interp knows about is the 45 degree one, not the 90 degree one
[18:46:53] <rayh> I guess I'm confusing path v corner.
[18:47:15] <SWPadnos> hmm -one sec, let me annotate your image
[18:53:14] <SWPadnos> gah - I can't remember how to draw in PhotoPaint
[18:53:39] <rayh> um can't help you there. i use gimp.
[18:53:45] <SWPadnos> heh
[18:53:54] <rayh> and it's the little pencil icon.
[18:53:58] <SWPadnos> I know you can make dashed lines, I just can't find the damned line style controls
[18:54:25] <rayh> oh that
[18:58:24] <rayh> I'm getting old here -- waiting for anna tation.
[18:58:29] <SWPadnos> heh
[18:59:26] <SWPadnos> ok, from the upper right corner of the compensated half-pie to the end point of the exit move (X4Y1)
[19:00:13] <SWPadnos> that line is not colinear with the path tangent at the compensated top line endpoint (X3,Y2)
[19:00:30] <SWPadnos> that is the known cusp for the exit move
[19:00:44] <SWPadnos> screw the annotations ;)
[19:03:06] <rayh> I can see that the black line at the end of the last arc due to comp is not tangent to the x4y1 but why would it be.
[19:03:30] <rayh> should, could,
[19:05:19] <SWPadnos> hmm. I think the easiest explanation is that if you run the reverse program, you get a certain path (with a lead-in arc). I think the idea is to get the same path (in reverse of course) when doing an exit
[19:05:47] <rayh> Um I don't see that at all.
[19:06:31] <alex_joni> * alex_joni has an interesting problem
[19:07:01] <rayh> I mean that's a nice way to think but why impose that upon the emc?
[19:07:31] <rayh> what is the nature of alex_joni's interesting problem?
[19:07:41] <alex_joni> wonder if someone is interested to talk about speeds & TRAJ & joints for a while
[19:07:48] <alex_joni> (sidestepping from the comp issues at hand)
[19:08:25] <rayh> I'd be interested in the discussion. Might not have much to contribute.
[19:08:41] <alex_joni> ok.. so here's the issue
[19:08:49] <SWPadnos> sure - that's good for me
[19:09:03] <alex_joni> imagine a puma.. you have joints to jog (those will move based on the individual AXIS_* constraints
[19:09:12] <alex_joni> (or should at least)
[19:09:19] <alex_joni> right?
[19:09:28] <SWPadnos> yep
[19:09:35] <alex_joni> ok, now we switch to world view
[19:09:42] <SWPadnos> or at least "understood" :)
[19:09:57] <alex_joni> the jogging for XYZ will be in some other units (mm vs. deg for example)
[19:10:06] <alex_joni> but it should be at other speeds
[19:10:16] <alex_joni> 1 mm in world is way less than 1 deg in joint
[19:10:35] <rayh> That would really depend upon pose.
[19:10:35] <alex_joni> so I think the [TRAJ] MAX_VEL & co limit that
[19:10:40] <SWPadnos> unless the arm is at its closest extension
[19:10:58] <alex_joni> genericly speaking
[19:11:20] <alex_joni> how about jogging ABC in world?
[19:11:34] <alex_joni> there is no-one doing any limit on that now
[19:11:33] <SWPadnos> generically, the required angular celocity will be less, then equal, then more than the desired linear velocity
[19:11:52] <alex_joni> SWPadnos: what I really meant is that it's seldom the same
[19:11:59] <SWPadnos> sure
[19:12:25] <alex_joni> so.. what we really need.. is a max_vel for XYT, a max_vel for ABC in world view
[19:12:32] <alex_joni> and then the max_vel's for the joints
[19:12:42] <alex_joni> (along with max_accel, and what else)
[19:13:45] <rayh> isn't a puma a collection of stacked rotaries (all angular)
[19:13:52] <alex_joni> rayh: right
[19:14:54] <rayh> I think I see what you are saying for rotaries on a conventional mill.
[19:15:30] <alex_joni> rotaries on a convetional mill are the joints with 1:1 mapping
[19:15:41] <alex_joni> so the limiting is at the joints, but that works for ABC too
[19:15:52] <alex_joni> for a puma moving axis A will result in some wild joint moves
[19:16:34] <SWPadnos> in theory, you should be able to set the TRAJ limits at +INF and still have moves that the machine can perform
[19:16:43] <alex_joni> SWPadnos: in theory
[19:16:55] <rayh> sure. I had that case with a SCARA. A very small x move required a nearly full rotation of the elbow.
[19:18:36] <SWPadnos> I guess there should be a linear max (already there), and an angular_max{vel,accel} as well
[19:18:53] <alex_joni> SWPadnos: right, that's what I was thinking too
[19:19:00] <SWPadnos> I think the angular limit should be per axis (ABC), but the linear should be on the vector sum of XYZ
[19:19:11] <SWPadnos> btu I'm not adamant about that
[19:21:53] <cradek> I see a nice job for ray on the users list!
[19:22:02] <SWPadnos> heh
[19:24:31] <cradek> * cradek grumbles bitterly about DST
[19:28:47] <alex_joni> DST?
[19:28:48] <rayh> Thanks Chris. I'll expect a formal recommendation on letterhead.
[19:29:02] <alex_joni> * alex_joni can send one
[19:29:12] <rayh> There you go.
[19:29:51] <rayh> IMO this would be better suited to Matt since he's already got one part way running.
[19:41:47] <alex_joni> is there some docs on 'mdi' ?
[19:43:12] <SWPadnos> page 3 of rs274ngc_3.pdf (page 11 of the pdf, 3 as labeled)
[19:43:28] <SWPadnos> or are you thikning of user instructions?
[19:44:17] <alex_joni> I'm thinking the python scrip called 'mdi'
[19:44:21] <alex_joni> not the mode called MDI
[19:44:51] <SWPadnos> oh :)
[19:45:12] <cradek> the operation of the 'mdi' program can be understood by using the auxiliary program 'cat'
[19:45:26] <alex_joni> cradek: you need to pass the nml file too
[19:45:34] <alex_joni> but I figured it out by reading the source
[19:46:38] <cradek> I think it's mostly a programming example of extensibility - documentation may not be necessary/appropriate
[19:56:17] <SWPadnos> jepler, should the else clause in the scale checking code be scale = 1. ?
[19:56:27] <SWPadnos> (like the inch case)
[19:58:13] <jepler> SWPadnos: I don't think it makes a difference
[19:58:54] <jepler> scale is multiplied with a value that is certain to be a float, so it doesn't matter if it's an integer or a float
[20:02:09] <SWPadnos> ok
[20:32:38] <rayh> SWPadnos: Did you want me to modify the comp plot and add text?
[20:32:51] <SWPadnos> nope - not if you understand it :)
[20:33:54] <rayh> I think I do.
[20:34:12] <jepler> cradek: thanks for pointing out that I did the wrong thing when in continuous mode
[20:34:42] <cradek> anytime
[20:34:55] <cradek> I'm excited to try this on the mill
[21:55:15] <cradek> SWPadnos:
http://timeguy.com/cradek-files/emc/lathe-singlearc-entry.png
[21:55:52] <SWPadnos> the big arc?
[21:56:02] <cradek> yes that's the compensated path
[21:56:10] <cradek> it doesn't seem quite right to me
[21:57:10] <SWPadnos> hmmm - I guess I'd have to agree ;)
[21:57:50] <SWPadnos> I'll have to look at that after dinner
[21:58:11] <SWPadnos> I don't understand what I'm looking at right now
[21:58:27] <cradek> oh I just wanted to show you a funny picture - I should be able to find the problem
[21:59:09] <SWPadnos> it is funny, but I can only go "heh - um" instead of "hahahahahah" because I'm thinking about food ;)
[21:59:35] <cradek> too late, I fixed it :-)
[21:59:57] <SWPadnos> damn!
[22:00:49] <SWPadnos> incidentally, I was thinking about two of the feature additions recently discussed - spindle-at-speed input and auto tool length detection
[22:01:07] <rayh> That's what you get for thinking.
[22:01:21] <SWPadnos> the at-speed input should be pretty easy, though givingthe user the ability to change what it means isn't as easy
[22:01:24] <SWPadnos> heh
[22:01:57] <cradek> I figure for a first shot, it could be done with comparators in hal
[22:02:15] <rayh> Does at speed need to have more than one definition.
[22:02:34] <cradek> quite likely
[22:02:42] <cradek> there has to be a window that's good enough, for instance
[22:03:01] <SWPadnos> I was only thinking about the pins(s) for motion - everything else is "machine logic"
[22:03:03] <rayh> Most professional drives have an at speed dry contact.
[22:03:10] <SWPadnos> ie, it's more of a spindle-fault input
[22:03:32] <SWPadnos> which a machine integrator can use to stop motion when the spindle is getting up to speed
[22:03:48] <SWPadnos> (not fault, since it wouldn't abort / estop)
[22:04:38] <SWPadnos> I think such an input would fix 90% of the issue with spindle speed control
[22:04:41] <rayh> I was planning on using adptive feedrate for feedhold until spindle reaches speed.
[22:04:58] <SWPadnos> that can be disabled in G-code, so it's not reliable
[22:05:01] <rayh> But if there is a binary pin for the same thing that would be great.
[22:05:03] <SWPadnos> that's the only reason to not use feedhold
[22:05:14] <SWPadnos> (which can also be disabled)
[22:06:08] <cradek> I know feedhold is disabled during synchronized moves - can you also disable it in gcode?
[22:06:17] <SWPadnos> dunno
[22:06:36] <cradek> (assuming so) why would we not want to let the user disable this kind of feedhold too?
[22:07:14] <SWPadnos> but hooking "spindle broke" to feedhold during a sync move would be bad ^2, I think (or it would make no difference, since the spindle stopping would effectively be feedhold anyway)
[22:08:06] <cradek> parse error
[22:08:09] <SWPadnos> heh
[22:08:16] <cradek> ?REDO FROM START
[22:08:26] <SWPadnos> hmmm
[22:08:46] <SWPadnos> ok - wuring a sync move, the spindle already controls motion
[22:09:00] <SWPadnos> during, that was
[22:09:05] <cradek> ok
[22:09:22] <SWPadnos> so I guess "spindle-hold" would have no effect
[22:09:34] <cradek> well it shouldn't
[22:10:42] <cradek> I'm trying to understand why feedhold is not already exactly what we want
[22:10:44] <SWPadnos> but a spindle-error (like how I keep changing the name? ;) ) pin may be useful even on sync moves
[22:10:51] <SWPadnos> it may be
[22:11:03] <cradek> maybe synced moves are a red herring
[22:11:11] <SWPadnos> I thought it could be disabled in g-code though, by a means other than sync motion
[22:11:20] <cradek> yes
[22:11:32] <cradek> why would you want to disallow that?
[22:11:46] <SWPadnos> dunno
[22:12:11] <SWPadnos> hmmm. maybe the problem is that FH isn't in the kramer spec?
[22:12:16] <cradek> afaic, you have to make a convincing case for why to take control away from the user, before it's the right thing to do
[22:12:17] <SWPadnos> (I don't see it yet anyway)
[22:12:30] <roltek> swpandos what's your web site
[22:12:31] <SWPadnos> sure
[22:12:34] <cradek> it may not be - but there is feed override override
[22:12:38] <SWPadnos> roltek, which one? ;)
[22:12:51] <roltek> i think cnc gear
[22:13:19] <SWPadnos> yep:
http://www.cncgear.com, but it sucks
[22:13:29] <SWPadnos> it hs no content, for the most part
[22:13:32] <roltek> thank you
[22:13:46] <SWPadnos> sure
[22:14:20] <roltek> what other 1 do you have
[22:14:46] <SWPadnos> well, just a personal page and my company page, also basically empty
[22:15:09] <SWPadnos> got photos of a trip to Poland and not much else ;)
[22:16:41] <roltek> were you guys talking about feed hold in threading
[22:16:41] <SWPadnos> ok - it looks like the rs274ngc spec has no mention of feedhold
[22:17:37] <cradek> roltek: yes but it was a red herring
[22:19:09] <roltek> you can not use feed hold in threading or it will screw up thread
[22:19:27] <SWPadnos> right - that's a separate issue from spindle monitoring
[22:19:43] <roltek> it has to stop after the block when it comes out of the part
[22:19:55] <SWPadnos> feedhold is disabled during all spindle synchronized moves as it is (I think cradek said)
[22:19:58] <SWPadnos> yep
[22:20:16] <cradek> yes, feedhold, adaptive feed, feed override, etc
[22:20:23] <cradek> we have so darn many of them
[22:20:52] <SWPadnos> I don't know if you've talked to pete about spindle stuff, but this stemmed from a concern about waiting for the spindle to come up to speed before moving
[22:22:09] <SWPadnos> I thought someone looked at the code for FO and decided that it could be disabled from G-code, but that may not be true
[22:23:12] <SWPadnos> as for removing decisions from the user, allowing an integrator to prevent machine motion under externally detected cases, and to prevent the user from disabling that configuration, is a good thing, IMO
[22:23:31] <SWPadnos> s/decisions/control/
[22:23:39] <cradek> void DISABLE_FEED_HOLD()
[22:23:47] <cradek> set_feed_hold_msg.mode = 0;
[22:23:47] <cradek> interp_list.append(set_feed_hold_msg);
[22:24:39] <cradek> so you want feed override override override?
[22:24:48] <SWPLinux> heh
[22:24:53] <cradek> that's getting a little silly don't you think?
[22:25:11] <cradek> (I'm actually a bit serious)
[22:25:12] <SWPLinux> I see that function is only called in one place
[22:25:35] <SWPLinux> well, we have multiple levels of "user"
[22:25:48] <SWPLinux> one is the integrator, who needs absolute power over machine configuration
[22:25:57] <SWPLinux> that includes removal of power from the operator
[22:26:12] <cradek> no, I think you're being silly
[22:26:35] <SWPLinux> so the integrator shouldn't be able to disable feed override?
[22:26:38] <cradek> the integrator should be able to disallow clockwise arcs? spindle speeds between 300 and 500?
[22:26:39] <SWPLinux> (for example)
[22:26:58] <cradek> "absolute power" is what I think is silly
[22:27:01] <jepler> cradek: s/disallow/charge $1000 extra to enable/
[22:27:12] <SWPLinux> ok - so "absolute power" over configuration, not the language
[22:27:18] <cradek> we should make reasonable and commonly-needed configurations easy
[22:27:43] <cradek> anything else, the user has "absolute power" given to them by the GPL
[22:28:02] <SWPLinux> sure, and not moving the tool while the spindle is running, and preventingthe user from interfering with that, seems like a desirable configuration
[22:28:10] <SWPLinux> err - spindle not running
[22:28:28] <SWPLinux> which is what I have to do now - sorry (wife got home, time for dinner)
[22:28:31] <SWPLinux> bbl
[22:28:34] <jepler> I think there are two separate features here: First, the control panel button marked 'feed hold'. That is what we implemented
[22:28:35] <cradek> ok bye
[22:28:53] <jepler> Second, a general integrator feature that stops motion while something else integrator-specific happens
[22:29:35] <jepler> we haven't implemented that, but it would seem to be the way to offer things like "wait for spindle-at-speed", "wait for axis to unclamp" without adding a pin for each one
[22:29:41] <cradek> so two hal pins, feedhold and feedhold-I-really-mean-it
[22:29:53] <cradek> feedhold is the disableable one
[22:31:12] <jepler> yes
[22:31:28] <jepler> (I think the implementation is to make it another multiplier in the feed calculation)
[22:31:56] <cradek> sure
[22:32:43] <cradek> ok I won't argue about that
[22:33:25] <jepler> another implementation would be to make .feedhold always enabled, and make DISABLE_FEED_HOLD set an output pin. default hal files would link them together, integrators might hook that plus spindle-at-speed logic through ladder or whatever
[22:33:24] <cradek> SWPLinux: sorry for calling you silly - I should have called your statement silly instead - err, that's not a very good apology
[22:34:36] <jepler> (by "always enabled" I mean make the value on that pin always take effect)
[22:53:12] <rayh> this "stops motion while something else integrator-specific happens" sounds a lot like the inhibit ring on many of the older Mazak/Mitts machines.
[22:54:47] <rayh> In those systems when you called for an M45 (indexer rotate) the inhibit ring was interrupted by the indexer until it completed it's move.
[22:55:49] <rayh> Newer machines have separate inhibit inputs associated with specific devices. So for example the same M45 would have an m45 inhibit release pin.
[22:56:13] <rayh> certainly the single inhibit is a lot better than nothing.
