Back
[14:09:52] <bpuk> you know those moments where you look at your old code and want to slap old you silly...
[14:11:10] <bpuk> I'm finding a lot of those today
[14:12:10] <Tom_L> write it once and never look back =)
[14:13:13] <bpuk> big refactor ;) I'm looking at the arc-intersection code I wrote 4 years ago. It works. I'm just a bit confused as to why
[14:14:03] <bpuk> more to the point, it only works for certain, very specific, arcs.
[14:14:36] <cradek> uh-oh
[14:15:29] <bpuk> which is to say, only arcs that are monotonic in x and z. so any type1 works
[14:19:19] <bpuk> and now I see how I've done it. yeah, that's getting rewritten
[14:49:17] <skunkworks> andypugh, did you see
http://electronicsam.com/images/KandT/testing/Screenshot-23.png
[14:49:46] <andypugh> I hadn’t
[14:49:50] <andypugh> Looks OK
[14:50:02] <skunkworks> darn close
[14:50:02] <andypugh> (largely)
[14:50:05] <skunkworks> :)
[14:50:16] <andypugh> Try this:
[14:51:38] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap c3c5010 06linuxcnc 10configs/sim/axis/g71/python/remap.py 10nc_files/lathe_pawn_G71.ngc G71 Roughing: Better algorithm to allocate pockets * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3c5010
[14:52:13] <andypugh> Currently I am working on the stock-to-leave part
[14:53:04] <andypugh> I figured out how to define the pockets last night when not-sleeping, and had to spend all day at work wanting to try it :-)
[14:53:39] <skunkworks> wow - that looks really good
[14:53:43] <skunkworks> Great work!
[14:55:42] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-24.png
[14:56:04] <bpuk> looks good :D
[15:02:41] <andypugh> We need to try it on the most evil profiles possible to excercise it, now.
[15:03:47] <cradek> you might consider something like the interp/crazy-paths test
[15:04:05] <cradek> it has a bunch of randomly-generated paths to test cutter comp
[15:04:35] <cradek> I simply loaded them into AXIS and looked at them to see if they worked right, and then enshrined that eyeballing by making a runtest
[15:04:53] <cradek> but I recommend randomly generating some profiles
[15:05:13] <cradek> if you load them in AXIS you can very easily see if they get fully cut out and not gouged
[15:05:24] <bpuk> think I'm ready to give up tonight. phone won't stop rining
[15:05:35] <andypugh> Currently we have no gouging detection.
[15:06:10] <cradek> specifically I meant you can see if a rapid cuts through the profile when going from one pocket to another
[15:06:24] <cradek> like we saw in some of your early tests
[15:06:33] <andypugh> Yes, that’s an easier thing to code gainst.
[15:08:10] <andypugh> I have added a tag to every line segment saying which pocket it belongs to, and increment that every time it changes from increasing to decreasing diameter. Then every cut picks up a pocket number from the curve that it starts at.
[15:08:24] <andypugh> (I am quite pleased by that idea)
[15:08:25] <cradek> ooh
[15:08:50] <andypugh> It would be fun to give it a fractal
[15:14:09] <jepler> hmm we have a gcode called "flowsnake" but it is a koch snowflake. the "flowsnake" is another interesting recursive/fractal shape...
https://en.wikipedia.org/wiki/Gosper_curve
[15:14:29] <bpuk> crazy question time. redoing the ray-line, ray-arc intersections. could they ever be not parallel to x or z? I'm trying to think of a case where they wouldn't
[15:17:58] <cradek> what is they?
[15:19:09] <bpuk> both andys and my code work out where to stop cutting by pointing a ray at the profile, whatever it first hits is where it stops. if G71 it's parallel to X, if G72 it's parallel to Z
[15:19:33] <bpuk> there is a really cheap method that we've both used, or an expensive one that works for any angle of ray
[15:19:47] <cradek> ok you mean the ray
[15:20:11] <cradek> if you wanted gouging protection, you'd use other angles of ray (the back angle of the tool)
[15:20:14] <bpuk> yup (just reread what I wrote the first time)
[15:20:44] <cradek> ... I think
[15:21:51] <bpuk> ooh - that's a neat way of doing the anti-gouge
[15:22:32] <andypugh> Cheap: for a line/curve (x1, y1, x2, y2) it intersects a cut at x if (x > x1) != (x > x2)
[15:23:01] <cradek> I haven't thought it through, but picturing something like a square groove, I can imagine running the same profile twice, with a left pointing tool and a right pointing tool, to cut both sides of it
[15:23:34] <cradek> say each tool can get to half of the crotch and one wall
[15:23:42] <andypugh> Yes, that should be possible with a tool-change, perfect gouge detection and the same profile run two ways.
[15:24:30] <cradek> hm you'd want one of them to cut the other direction, but whatever
[15:24:34] <andypugh> Though, actually, standard G71 doesn’t allow that. Because the first line of the profile is the “feed line”
[15:25:03] <bpuk> Expensive: t=(f(x1-xo) + g(y1-yo) +- sqrt(r1^2(f^2+g^2)-[f(y0-y1)-g(x0-g1)]^2)/((f^2 + g^2) and solve as a quadratic equation
[15:25:04] <andypugh> I really dislike that part of the normal implementation
[15:25:21] <cradek> even ignoring left/right, consider a 60 degree rougher and a 30 degree finisher
[15:26:01] <andypugh> bpuk: What are f and g?
[15:26:19] <bpuk> parametric terms
[15:26:40] <andypugh> <quizzical look>
[15:26:46] <jepler> to a first approximation, you shouldn't worry about calling sqrt() a handful of times for each line of gcode
[15:27:23] <bpuk> I haven't tried implementing that one yet - but they're what you're trying to find (x = x0 + ft)
[15:27:41] <bpuk> theres a couple of other methods, but they start throwing in arctan2
[15:27:49] <andypugh> Running in Python the current implementation take no apparent time.
[15:28:18] <andypugh> arctan2 is available, and I am using it in a few places
[15:28:41] <bpuk> I'm trying to think of the people running lcnc on a beagleboard ;)
[15:29:16] <cradek> we have readahead for this reason among others
[15:29:21] <cradek> really, don't worry about it
[15:29:30] <andypugh> I am testing for line-circle intersection and rejecting solutions not in the box of the arc (my arcs are <= 90 degrees)
[15:29:31] <jepler> write it right first, then optimize later
[15:30:09] <bpuk> what happens if you throw a >90 degree arc at it?
[15:30:28] <andypugh> Yes, a generic vector/vector and arc/vector intersection function is likely to be the right way, especially for gouge detection.
[15:30:41] <bpuk> ok cradek + jepler. I'll detect parallel rays and use the cheap method for those, and do an expensive one as a fallback
[15:30:46] <jepler> looks like the implementation I wrote at $DAY_JOB uses sqrt, 2×atan2, and a pile of arithmetic (but it has the added "fun" of operating on ellipses)
[15:30:57] <andypugh> bpuk: The code that builds the profile data splits the arcs at the cardinal points.
[15:31:13] <bpuk> giving you a bounding box
[15:31:26] <bpuk> aaaaah
[15:31:43] <bpuk> you _literally_ split the arc :D
[15:31:53] <jepler> it's easier than fusing the atom
[15:32:36] <andypugh> Sort-of. You actually get multiple separate arcs. It’s a way to make the cheap interesction algorithm reliable.
[15:33:23] <andypugh> Yes, a 270 degree arc becomes 3 (or 4, depending on start point) arcs.
[15:33:25] <bpuk> since you'll never get two intersection points on a < 90 arc
[15:33:38] <bpuk> given a parallel ray
[15:34:01] <andypugh> Yes. That’s the caveat. It’s no help for an angled ray.
[15:35:45] <andypugh> We can skip the subdivision if we have a generic intersection-spotter
[15:35:53] <bpuk> ok, I'll refactor the cheap methods using a unit vector as the angle input. and add in another todo for the expensive method
[15:36:05] <bpuk> mostly wanted to get rid of some of the more delicate code
[15:36:51] <bpuk> ray-line should still be pretty cheap for an angled line, so I'll try and keep that in
[15:37:53] <andypugh> gouge-detection is a bit more complicated, the line-to-test has a start and a direction.
[15:38:24] <andypugh> No point testing for gouging in the -X direction from the tool tip. Gouging there is the _point_
[15:38:56] <bpuk> except for inside tight arcs?
[15:39:34] <andypugh> We let tool comp handle that one, I think?
[15:40:04] <bpuk> test when we get to that point?
[15:43:16] <andypugh> Yes, I think so
[15:45:25] <bpuk> also realised most of the C code can be hugely cleaned up by offsetting the profile using a for loop once, instead of trying to add allowances to every call
[15:46:34] <andypugh> I have decided to do both. But that’s a Type11 thing. X is offset in the profile, once. Z gets offset different ways for start and end cuts.
[15:47:11] <bpuk> yeah, type 2 is a bit of a different beast
[15:47:40] <bpuk> you're almost better leaving the centre points of arcs the same and changing rads
[15:48:05] <andypugh> That’s actually hard
[15:48:26] <bpuk> or... since you're only doing arcs in quadrants, offsetting normal to the centrepoint of the arc
[15:48:32] <andypugh> (slightly) as intersecting lines need to move
[15:51:12] <bpuk> have you tried any profiles that aren't in the 'standard quadrant' yet?
[15:51:46] <bpuk> i.e. ID turning, or backtool lathe
[15:59:23] <andypugh> Not yet
[15:59:45] <andypugh> Well, I tried the G71test2 file, that’s boring
[16:00:10] <bpuk> not sure what I did with G71test{3..12}
[16:00:29] <bpuk> but I'm trying to work out a lot of the old logic, and I can only think it's needed for ID/backtool
[16:01:28] <bpuk> since it's based on whether startx > endx
[16:07:00] <andypugh> Is it negative-j for internal profiles?
[16:09:26] <bpuk> arc definition? err...
[16:12:16] <andypugh> No, the x offset
[16:12:51] <andypugh> Incidentally, does your code allow you to use the L-offset?
[16:13:15] <bpuk> internal profiles would be top to bottom, right to left. so any offset would be negative
[16:13:51] <bpuk> overthickness? yeah - but the current definition would be broken for type2
[16:14:22] <andypugh> Have you tested a non-integer L word? Something is complaining.
[16:15:20] <cradek> jepler: (LOGOPEN,file.txt) ... (LOG,#5061 gets expanded here) ... (LOGCLOSE)
[16:15:51] <bpuk> Hmm. L is defined as an integer is interp_read.cc
[16:16:10] <andypugh> Yeah, that’s a nuisiance
[16:16:19] <cradek> with a little care, you could sure change it
[16:16:32] <cradek> keep an integer check where appropriate
[16:16:50] <andypugh> We probably can use U and W, except if we expand to UW arcs. (and my code already supports UW arcs for G71, even if LinuxCNC doesn’t)
[16:16:54] <bpuk> yup, I changed N (and will change back). theres a bunch of places that need it as an int.... and nvm, cradek has pointed it out
[16:18:55] <andypugh> Is E spare?
[16:19:08] <cradek> there are no unused letters
[16:19:42] <andypugh> I mean in the G71 context
[16:19:57] <andypugh> (though it might be an int too)
[16:20:10] <bpuk> The letters I picked originally were when I was trying to get as close to possible to fanuc syntax
[16:20:21] <cradek> E- - Specifies the distance along ...
[16:20:22] <bpuk> if we don't need to get to fanuc syntax *shrug*
[16:20:59] <andypugh> E isn’t too out of place for a roughing allowance then?
[16:21:13] <bpuk> The original letters used were P, Q, D, R, U, W, I, K, F, S, T
[16:21:17] <cradek> fine with me...
[16:21:29] <bpuk> U, W I switched to J, L.
[16:21:37] <cradek> that sounds smart
[16:21:38] <bpuk> but other than those, it's fair game I think
[16:21:45] <andypugh> I would _quite_ like to have X and Z in the G71 line to define the feed line, rather than bodge it with ignoring the first line of the profile.
[16:21:52] <cradek> S?
[16:21:58] <bpuk> spindle speed
[16:22:24] <cradek> that does something different when on a G71 line?
[16:22:45] <bpuk> it defines the spindle speed during the profile (strictly, it overrides the speed)
[16:22:54] <andypugh> No, exactly the same, but it’s allowed to be ther
[16:22:55] <bpuk> andypugh: the origin point when you start is also used
[16:23:17] <bpuk> "Only one feedrate, spindle rpm, and tool is valid for G71. You either get the values that were in effect before the G71 was called, or you may specify one or more of these using the F, S, or T words on the G71 itself. Any use of F, S, or T inside the profile is ignored."
[16:23:17] <andypugh> Yes, but all G-codes have an implicit start point
[16:26:10] <bpuk> true - but the G71 start point does a lot of work
[16:26:22] <andypugh> cradek: You might have an opinion on this: The first line of the G71 block is used to define the feed line, and the mode (G0, G1) is used to determine whether the machine rapids or feeds to the start of each pass. That annnoys me.
[16:27:18] <andypugh> I think G0 X20 Z0 // G71 X2 P Q D R U is more consistent with other G-codes
[16:27:18] <bpuk> also - the number of blocks on the first line is special - if both x and z are defined, it's type2, if only one is defined, it's type1
[16:28:06] <cradek> I sympathize with hating magic implicit stuff like that
[16:28:24] <cradek> but I'm not informed enough to say whether bucking the established trend would be wise
[16:28:31] <cradek> I trust you guys
[16:29:07] <bpuk> it's magic - but the alternative is to define the start point of the profile in the G71 call? and in the G70 that follows?
[16:30:29] <bpuk> and even worse, it's magic that is hard to post-process out of a CAM generated file (playing devil's advocate here)
[16:32:26] <bpuk> if we're going to break that 'tradition' I'd take it further, and require the profile loop to be closed - have the last block return to the start point (which must be explicitly defined using both X and Z). Have type1/2 selection as a different G71 letter
[16:32:57] <cradek> fwiw, also remember you have g71.1 g71.2 etc available
[16:34:24] <bpuk> the alternative is: once type2 is working properly, remove type1 altogether - the only advantage to type1 is it's marginally faster and avoids recutting
[16:43:32] <andypugh> Does any CAM use G71?
[16:43:47] <andypugh> I would imagine that it would be an either-or situation?
[16:44:46] <bpuk> apparently, based on some of the private flame-mails I got last time I brought this topic up, a lot do
[16:45:02] <bpuk> I've never come across a cam package that does
[16:45:47] <andypugh> We can be pretty certain that _none_ of the LinuxCNC / EMC2 lathe post-processors will.
[16:45:57] <bpuk> heh. that's true :D
[16:46:13] <andypugh> And if you are using the wrong PP, that’s your fault.
[16:47:22] <bpuk> now that the americans should have recovered from excessive turkey consumption - the first profile block being in the profile/being part of the G71 command/being a complete closed loop might be a mailing list question
[16:48:07] <andypugh> Aye, ‘appen as you’re right
[16:49:09] <bpuk> I'm still thinking in terms of the profile block being used to define other profiles - which may be tainting my judgement
[16:49:28] <bpuk> (like that _really_ neat eccentric turning demo you did)
[16:50:05] <cradek> I kinda recommend against polling the crowd. it rarely helps a spec develop but it leads to lots of heartache and noise. none of them know more than you guys.
[16:51:40] <bpuk> problem is: we both have a preferred option, in both cases it's not the same as the 'existing' spec. and we disagree on what that option is
[16:52:16] <bpuk> but at least we agree the existing spec is stupid ;)
[16:52:19] <cradek> having 10 more would help? also, one of them will probably be angry for some reason.
[16:52:32] <cradek> sorry, I'm being ungenerous
[16:52:37] <bpuk> one angry? Oh, to have your faith in humans :D
[16:56:20] <bpuk> whoo! random segfault
[17:07:47] <bpuk> have I mentioned the o-code stuff is a bit delicate
[17:09:15] <bpuk> and the comments are just as helpful as mine
[17:11:55] <bpuk> TESTME!!!
[17:12:05] <bpuk> and it doesn't do what it claims in the comment
[17:26:49] <andypugh> I _think_ O-words were put in by Ken Lerman. (Can anyone confirm or deny?) He’s still active on the list.
[17:28:04] <cradek> yes ken did all the initial work
[17:28:24] <cradek> it's been made worse, er I mean others have added to it, since then
[17:28:31] <cradek> including me, heh
[17:28:54] <cradek> ken may or may not feel like he still knows it
[17:29:40] <bpuk> it's not the KL stuff that's scaring me
[17:29:50] <bpuk> I've mostly understood that by going back to 2.5
[17:30:12] <bpuk> admittedly some of his comments in 2.5 are a bit... err... interesting
[17:30:18] <bpuk> but we've all done those right? :P
[17:30:43] <cradek> I usually leave comments out - less to maintain that way
[17:30:57] <bpuk> the main problem is the comments describe the code - not the intent
[17:31:12] <cradek> no - usually they describe how the code used to be
[17:31:17] <bpuk> ok, fair
[17:31:22] <bpuk> but still not the intent
[17:31:28] <bpuk> and it's the intent that is confusing
[17:31:37] <cradek> some are useful and describe the intent! the rest you should ignore I guess
[17:31:48] <cradek> (I think you're totally right about what a good comment does)
[17:31:50] <bpuk> so I'm resorting to throwing logDebug() _everywhere_
[17:32:13] <bpuk> oh, all my comments describe what the code does, not what I mean it to do
[17:32:25] <bpuk> since, heck, only _I'm_ going to touch this, right? :P
[17:32:29] <cradek> the interp is fairly debuggable, just attach to the running task
[17:32:42] <bpuk> I really need to learn to use gdb :P
[17:33:14] <cradek> yeah, totally worth your time
[17:33:17] <bpuk> sorry, I learned to debug a) without a debugger b) with MS VC++
[17:33:22] <bpuk> the latter is easy
[17:33:32] <andypugh> I just today found pdb for Python.
[17:33:33] <bpuk> the former involves throwing a lot of debug statements in
[17:34:29] <bpuk> zlog
[17:34:50] <cradek> I guess he hasn't fixed it yet...
[17:35:00] <bpuk> 24 hour again?
[17:35:02] <andypugh> Now, by putting bp() in my code, I can get it to stop and then I can see the variable values etc, and the context of the code. It’s not as easy as the visual ones in )for example) VBA, but it’s at least helpful.
[17:35:22] -!-
logger[psha] was kicked from #linuxcnc-devel by ChanServ!ChanServ@services. [User is banned from this channel]
[17:35:30] <bpuk> I really hate to admit it - but microsoft did a really nice job with the VS debugger
[17:35:44] <bpuk> if I don't have the source, I'll use IDA
[17:35:52] <andypugh> It’s odd, I am sure that he logs the other list too. And no spam there.
[17:36:00] <cradek> weird
[17:36:02] <bpuk> but that doesn't work on linux, so it's learn another debugger
[17:36:04] <cradek> I made it 3 days this time
[17:36:10] <mozmck> bpuk: have you used eclipse? It has a visual interface to gdb which is pretty nice.
[17:36:37] <bpuk> I've been using anjuta
[17:37:01] <bpuk> my past experiences with eclipse haven't been good - but they were a long time ago (5+ years)
[17:37:07] <andypugh> I use eclipse, but I have never figured out how to make it work with gdb and LinuxCNC. Partly because Eclipse wants the name of the executable…
[17:37:40] <mozmck> I have not done any debugging in linuxcnc with eclipse yet, but others have, and eclipse is very nice for traversing code.
[17:38:47] <bpuk> the level of debugging I'm doing is: ok, it's skipping, that's good. it's reached endprofile, it should stop skipping. WHY IS IS STILL SKIPPING! RAGE!
[17:39:45] <bpuk> (strictly, I'd expect it to return the callframe to the saved one on completion of endprofile, that's not happening)
[17:41:39] <bpuk> (and when the code isn't doing what I expect, I talk to the room. If I get an answer, whoo! if not, I'll keep muttering)
[18:19:14] <cradek> that's exactly what I do
[18:19:37] <cradek> if someone can help, yay! otherwise, they have to share in the suffering.
[20:12:01] <andypugh> You know, I could think of good arguements for the “quadrant” of G71 to be exolicitly set by the L-word (in the same way as it is used to modify G10)
[20:16:19] <andypugh> Currently I can make out-to-in work properly, or in-to-out. But so far not both.
