Back
[01:07:20] <jmkasunich> jepler: just getting started
[01:11:11] <jmkasunich> should I find it odd that offs-0.0.5,tar when unpacked gives me files named offs-0.1<whatever>? I was kind of expecting offs-0.0.5<whatever>
[01:37:19] <jepler> jmkasunich: it's likely that I screwed up the tarballs
[01:37:26] <jepler> jmkasunich: those are version numbers I made up on the fly, though
[01:38:23] <jmkasunich> I have your version running (had to get valgrind and to a little fiddling), now I'm working on putting my path in
[01:39:19] <jepler> jmkasunich: it would also have been possible to remove the references to valgrind entirely
[01:39:37] <jmkasunich> I figured as much, but getting the valgrind package was easier
[01:39:59] <jepler> jmkasunich: did you run it before you started modifying the path? If the bottom part of the generated code had only one box instead of a bunch of nested boxes, it has the broken closed path code
[01:40:45] <jmkasunich> bottom left or bottom right?
[01:41:14] <jepler> bottom right
[01:41:19] <jmkasunich> I did run it unmodified, but that screen is gone - I've since run a partly modified version, with about half the paths removed
[01:41:29] <jmkasunich> I don't have any boxes, I think thats the part I removed
[01:41:40] <jmkasunich> I think I only kept the left side
[01:42:14] <jmkasunich> and now I have even less
[01:42:38] <jepler> if you have the wrong files, it won't affect the one where your path is
[01:43:10] <jmkasunich> how do I tell it I have a closed path?
[01:43:41] <jepler> move back to the starting point with a line or arc, then c.close()
[01:43:49] <jmkasunich> ok
[01:44:00] <jmkasunich> right now I'm figuring out arcs
[01:44:16] <jmkasunich> and I added a couple struct pt to save typing
[01:44:45] <jmkasunich> since my coordinates are 4 digits after the decimal point, and your primitives need both start and end pts - don't want to type things twice
[01:45:09] <jepler> yeah that is a bit of an annoyance
[01:45:11] <jmkasunich> start.x = 0.6;
[01:45:11] <jmkasunich> start.y = 0.6;
[01:45:11] <jmkasunich> end.x = 0.7445;
[01:45:11] <jmkasunich> end.y = 0.2000;
[01:45:11] <jmkasunich> c.feed(line(start, end));
[01:45:12] <jmkasunich> start = end;
[01:45:14] <jmkasunich> end.x = 2.0;
[01:45:16] <jmkasunich> end.y = 0.0;
[01:45:18] <jmkasunich> c.feed(line(start, end));
[01:45:38] <jepler> did you follow the different ways to declare an arc? 2d.hh around line 50
[01:45:45] <jmkasunich> yeah
[01:46:03] <jepler> start, end, center or start, end, radius are probably the most natural for you
[01:46:10] <jmkasunich> yep
[01:46:16] <jmkasunich> I'll probably be using the first one
[01:46:25] <jmkasunich> (of those 2)
[01:47:59] <jmkasunich> for the 'bool' args, I just pass 1 or 0, right?
[01:50:00] <jmkasunich> and we have an arc!
[01:51:56] <jmkasunich> end.x = 1.1434; end.y = 0.4582;
[01:51:56] <jmkasunich> ctr.x = 0.7445; ctr.y = 0.6380;
[01:51:56] <jmkasunich> c.feed(arc(start, end, ctr, 1));
[01:51:56] <jmkasunich> start = end;
[01:51:58] <jmkasunich> oops
[01:52:03] <jmkasunich> never mind that...
[01:52:12] <jmkasunich> jepler: demo_comp.cc:25: error: ‘struct dummy’ has no member named ‘close’
[01:52:23] <jmkasunich> does that mean I have the version that doesn't do closed loops
[01:52:40] <jmkasunich> or just that I need to add a dummy close
[01:52:55] <jepler> could be either one
[01:53:11] <jmkasunich> added the dummy, no error
[01:53:29] <jmkasunich> and it looks like it might be doing the closed shape right
[01:53:52] <jmkasunich> hard to tell, since I still have a blend of your path and the beginning of mine
[01:57:23] <jmkasunich> what is a thick cyan line in the axis preview? I have one and I can't figure out where it is coming from
[01:57:50] <jmkasunich> duh, its the selected line
[01:57:59] <SWPadnos> heh
[01:58:10] <jmkasunich> but oddly, after loading the program, a non-existant line is selected
[01:58:44] <SWPadnos> a line that doesn't exist in the editor or a line that doesn't exist in the preview?
[01:59:01] <SWPadnos> err - g-code listing, not editor
[01:59:12] <jepler> hm -- that should probably disappear after reload
[01:59:20] <jmkasunich> a cyan line appears in the preview (3d window), when I click on it, it disappears
[01:59:45] <jmkasunich> it doesn't seem to be repeating now that I've clicked in other places - no big deal, I'm just easily confused
[02:00:45] <jmkasunich> I think I've found a pathalogical case that breaks your program (not my path, but a combination of part mine part yours) screenshot in a sec
[02:02:15] <jmkasunich> http://jmkasunich.com/pics/offs-1.png
[02:02:36] <jmkasunich> the line off by itself is the reference path
[02:02:49] <jmkasunich> large arc, then tighter radius arc, then a line off to the right
[02:08:54] <cradek> now may not be the time, but jmkasunich: if your program does not move Z or change feed while cutter comp is on, you could also try using the concave_ccomp branch for this
[02:09:31] <jmkasunich> cradek: I will need the loop removal stuff - some of my segments are short enough that they will disappear
[02:09:36] <cradek> but, the case you show in offs-1 would probably not give you what you want
[02:09:37] <jmkasunich> I think I need >1 lookahead
[02:09:46] <cradek> ok I understand
[02:09:56] <jmkasunich> the line shooting off to the right is not part of my profile
[02:10:00] <jmkasunich> its leftovers from jeffs
[02:10:11] <SWPadnos> I can't get the first G3 to execute - I get the dreaded "radius to start and end are different blah blah"
[02:13:13] <jepler> jmkasunich: looking...
[02:13:24] <jepler> jmkasunich: that's curious
[02:14:39] <jepler> no doubt it's a bug :-P
[02:14:43] <jmkasunich> heh
[02:14:52] <jmkasunich> really sharp outside corner
[02:14:55] <SWPadnos> odd. when I MDI the arc, it doesn't work
[02:15:02] <SWPadnos> when I run it in a program, it's fine
[02:15:02] <jmkasunich> which arc?
[02:15:10] <SWPadnos> line 5 in your screenshot ;)
[02:15:26] <jmkasunich> you MDI the preceeding line, right?
[02:15:40] <SWPadnos> yes, all the preceeding lines
[02:15:49] <SWPadnos> though I didn't do G20
[02:16:16] <jepler> jmkasunich: is that crazy line at the point where the path closes, or is it elsewhere?
[02:16:27] <SWPadnos> also of interest is that when I make a program with the first 7 lines of your code, the last line (the one left over from jepler's stuff) doesn't execute when I hit run
[02:16:46] <jmkasunich> elsewhere
[02:17:08] <jmkasunich> the close point is where you see the short rapids connecting the individual paths
[02:17:15] <jmkasunich> and the flow is counterclockwise
[02:17:49] <jepler> I bet it's a bug in the arc-from-endpoints-and-radius code
[02:17:52] <jmkasunich> line going down and right, then big arc, smaller arc, then line to way off right
[02:18:07] <jmkasunich> from way-off-right, it goes to way-off-up, then down to start
[02:18:22] <jepler> too bad my brain is fried
[02:18:23] <cradek> my calculator says that arc is fine
[02:18:34] <cradek> SWPadnos: ^
[02:18:42] <SWPadnos> the radius differed in the fourth decimal place
[02:19:00] <jmkasunich> when I added more of my path (going straight up from the highlighted arc), the weirdness in the generated paths moved up
[02:19:20] <jmkasunich> to the point where the path once again heads for way-off-right
[02:19:21] <SWPadnos> hmmm - no. start radius = 0.4380, end = 0.4371
[02:19:55] <cradek> are you in g91?
[02:20:17] <cradek> I see there's no g90 in the program - probably should be
[02:20:47] <SWPadnos> no, its in G90
[02:22:09] <cradek> the end radius is .43800100, I did it twice
[02:22:31] <cradek> did you type in the program by hand?
[02:23:02] <jepler> jmkasunich: if you can save copies of demo_comp.cc which misbehave in interesting ways, it would be helpful to me
[02:23:13] <SWPLinux> cradek: yes, I typed the MDI and program by hand
[02:23:15] <jmkasunich> I saved the one that goes with that screenshot
[02:23:20] <jepler> great
[02:23:30] <cradek> SWPLinux: well surely you just messed it up then?
[02:23:35] <SWPLinux> http://pastebin.ca/976333
[02:23:37] <SWPLinux> the program
[02:24:13] <jmkasunich> jepler:
http://jmkasunich.com/pics/demo_comp_offs1.cc
[02:24:37] <SWPLinux> gah. I can't copy from the axis history
[02:24:54] <SWPLinux> the program as typed runs fine, except it doesn't execute the final line
[02:25:37] <cradek> doesn't go to X6?
[02:26:04] <SWPLinux> http://pastebin.ca/976338
[02:26:07] <SWPLinux> MDI history
[02:26:37] <SWPLinux> no, that last line isn't executed. I went to X6 in MDI and it worked fine, so it's not a limit thing
[02:26:55] <SWPLinux> this is on sim, so who knows ...
[02:27:01] <cradek> ouch. wonder if it's a problem with the % instead of M2
[02:27:09] <SWPLinux> one sec, I'll check
[02:27:22] <cradek> also turn on task-issue and see if it gets sent to motion
[02:27:28] <jmkasunich> I'm running sim, FWIW
[02:27:40] <SWPLinux> ok, it is executed with M2
[02:27:50] <SWPLinux> should M30 also end the program?
[02:27:56] <cradek> yes
[02:28:22] <SWPLinux> ok, works that way too
[02:30:04] <SWPLinux> the line isn't issued at all when % are used
[02:30:17] <jepler> well now I've thoroughly screwed up my working copy of offs
[02:30:26] <jmkasunich> oops
[02:30:26] <SWPLinux> offs
[02:30:28] <cradek> SWPLinux: please file a bug report against interp with your findings
[02:30:29] <SWPLinux> :)
[02:30:57] <jepler> hooray for version control :-P
[02:31:30] <SWPLinux> ok. odd though
[02:31:48] <SWPLinux> I added another move after that one - G0Z0.9, and both moves execute
[02:31:50] <jepler> jmkasunich: I'm sorry if my software is too buggy for your purposes at this time
[02:31:57] <jmkasunich> its not
[02:32:07] <jmkasunich> I'm about to post a screenshot of my path
[02:33:01] <jmkasunich> http://jmkasunich.com/pics/offs-2.png
[02:33:24] <jmkasunich> it didn't like that wild turn off to the far right, but its perfectly happy with my actual path
[02:33:36] <cradek> wow, that's neat
[02:33:47] <jepler> you'd better fix those G0s down into the material
[02:33:57] <jepler> * jepler tries no less than three times to rotate the preview
[02:34:01] <jepler> offs
[02:34:02] <cradek> haha
[02:34:03] <jmkasunich> yeah, it needs some touchup
[02:34:14] <cradek> it rapids down and then toward the center :-)
[02:34:27] <jmkasunich> it will be used to bring the port in this casting to the proper shape (ball end mill)
http://jmkasunich.com/pics/block-end-faced-2007.jpg
[02:35:04] <jmkasunich> jepler: I can post this demo_comp.cc, then you can rotate it
[02:35:07] <cradek> I sure like the AXIS preview for writing/checking gcode
[02:35:39] <jepler> I'd like to have the .cc .. the .ngc would probably be more useful to others
[02:35:40] <jmkasunich> http://jmkasunich.com/pics/demo_comp_offs2.cc
[02:36:10] <jmkasunich> where does it write the ngc? or does it just pipe it into axis-remote?
[02:36:18] <jmkasunich> duh, never mind
[02:36:25] <SWPLinux> does anyone know how one is supposed to get from linuxcnc.org to the SF bug reporting page?
[02:36:56] <SWPLinux> I used the search and found a link, but I'd think it would be more obvious than that
[02:37:12] <cradek> click up in the location entry field and type sf.net/projects/emc?
[02:37:29] <jmkasunich> http://jmkasunich.com/pics/demo_comp_offs2.ngc
[02:37:42] <SWPLinux> well, I could also go to my SF user page and click through from there, but still ...
[02:39:59] <jmkasunich> the next step is to hack up jeffs code so I can offset each level down and to the left
[02:40:28] <jmkasunich> the lower and left straight edges of all levels will be lined up, and the tapering will take place along the rest of the outline
[02:42:03] <jmkasunich> and the taper isn't going to be uniform....
[02:42:14] <jmkasunich> very usefull tool jepler, thanks
[02:42:28] <jmkasunich> dog is whining, gotta walk him now
[02:43:19] <jepler> jmkasunich: have fun
[02:43:20] <jepler> see you later
[02:43:24] <jepler> * jepler is about ready to head to bed
[04:00:05] <jmkasunich> * jmkasunich lusts after tooling
[04:00:50] <jmkasunich> http://cgi.ebay.com/ER20-full-set-12-pcs-ER-20-high-precision-collet-set_W0QQitemZ200205925150QQihZ010QQcategoryZ45018QQtcZphotoQQcmdZViewItem
[04:01:09] <jmkasunich> http://cgi.ebay.com/ER20-STRAIGHT-SHANK-COLLET-CHUCK-TOOL-HOLDER-ER-20_W0QQitemZ200127288987QQihZ010QQcategoryZ45018QQtcZphotoQQcmdZViewItem
[04:06:10] <SWPLinux> what?
[04:06:52] <SWPLinux> damn. that didn't work
[04:07:35] <cradek> isn't 3/4 too big for your shoptask?
[04:07:54] <jmkasunich> 3/4 is the size of the tormach quick-change shanks
[04:08:06] <jmkasunich> tormach sells an ER-20 holder, but they want $81 for it
[04:08:19] <jmkasunich> this doesn't have the stop ring, but I can make that
[04:08:35] <cradek> http://www.cdcotools.com/item.php?itemid=428
[04:08:36] <jmkasunich> just over half the price
[04:08:38] <cradek> cheaper but ER16
[04:09:09] <jmkasunich> 4" long shank I'd have to cut down
[04:09:34] <cradek> I easily cut the shank on my boring head
[04:09:41] <jmkasunich> not hardened?
[04:09:48] <cradek> if so, not much
[04:09:59] <cradek> it looked ground
[04:10:16] <jmkasunich> have you dealt with cdco?
[04:10:19] <cradek> it's hard to guess what you'll get when you order this cheap stuff
[04:10:30] <cradek> yes I got some stuff from them.
[04:10:34] <cradek> maybe even twice, not sure
[04:11:26] <jmkasunich> the ER-20 is nice cause it goes up to 1/2"
[04:11:42] <cradek> yeah 1/2 is a nice size
[04:11:50] <jmkasunich> that ebay seller has ER-16 too, holders are the same price, collet sets about $15 less
[04:11:56] <jmkasunich> for that difference, I'd rather have 20
[04:12:04] <jmkasunich> no way I want both
[04:12:11] <cradek> do you ever use 3/4 mills or is that way too big?
[04:12:25] <jmkasunich> I probably could, as long as I was smart about feeds and speed
[04:13:17] <jmkasunich> I'm gonna talk to the friend I've been doing this work for - he's an ebay fiend, and has a paypal account - I may ask him if he'll buy me a set of collets and 2 chucks to pay for the job
[04:13:29] <jmkasunich> that would be a steal for him, and a nice addition to my tooling
[04:13:32] <cradek> that sounds slick
[04:14:02] <cradek> you'll never use most of the collets...
[04:14:08] <cradek> or at least I don't use mine
[04:14:17] <jmkasunich> the two chucks are just what is needed for the next operation - one for the ball end mill (3/16" shank) and one for the drill (0.281)
[04:14:23] <cradek> I mostly use the 1/8, 1/4, 3/8, 1"
[04:14:42] <jmkasunich> you don't drill much, or you have enough Z to deal with drills in chucks
[04:14:53] <jmkasunich> drills in collets work nicer if you have limited Z
[04:15:17] <cradek> I usually move the knee :-/
[04:15:30] <cradek> you think these will really clamp on everything?
[04:15:39] <jmkasunich> ER is a wide range collet
[04:16:30] <jmkasunich> http://i11.ebayimg.com/04/i/08/6d/f4/3a_3.JPG
[04:16:31] <cradek> it would be nice that you could always add a few more chucks
[04:16:41] <jmkasunich> note that it is slit from both top and bottom
[04:16:45] <cradek> I know, mine are ER40
[04:16:57] <jmkasunich> thats what lets them compress down
[04:17:08] <cradek> but gripping intermediate sizes seems iffy - maybe I just need to tighten it up and not worry.
[04:18:03] <cradek> I will try them next time for drilling.
[04:18:30] <cradek> (doubt my ER40 chuck is much shorter than the albrecht though)
[04:18:49] <jmkasunich> ER-20 is
[04:18:58] <cradek> yeah those look nice and short.
[04:19:07] <cradek> hopefully the shank is fairly hollow too.
[04:19:14] <jmkasunich> and ER20 with an endmill, and another ER-20 choked up on a drill, not too different
[04:19:17] <jmkasunich> shanks are hollow
[04:20:14] <cradek> I like that these you found take regular wrenches
[04:20:46] <cradek> I'd rather the small one had a full hex so you could use a closed wrench though
[04:21:21] <cradek> I'd definitely go get the right two wrenches (I hate crescents, they always make me bleed and ruin things)
[04:21:36] <jmkasunich> heh
[04:21:45] <cradek> not in that order
[04:21:49] <jmkasunich> damn, it got late again
[04:21:52] <cradek> ruin something, then bleed very shortly afterward
[04:22:16] <cradek> here too. goodnight...
[04:22:23] <jmkasunich> goodnight
[11:55:57] <jepler> ah shit that bug SWPadnos discovered is another segment combining bug, isn't it
[13:02:53] <SWPadnos> jepler: hmmm. could be.
[13:03:27] <SWPadnos> if G1->G0 gets combined differently than G3->G1 or G1->G1
[13:04:21] <SWPadnos> in both cases, there's a sharp corner - either from the last arc endpoint to the long G1, or from the XY G1 to the Z G1 or G0
[13:28:14] <cradek> jepler: yes surely
[13:28:42] <cradek> jepler: % doesn't call STOP_OR_END_OR_WHATEVER_IT_IS_PROGRAM(), it just stops sending the segments
[13:29:04] <cradek> not sure how to fix it except to make a FLUSH canon call
[13:29:44] <SWPadnos> are there undesired effects from calling STOP_OR_END_OR_WHATEVER_IT_IS_PROGRAM() for % ?
[13:30:03] <skunkworks_> * skunkworks_ wonders how you make a flushing sound on irc
[13:30:05] <cradek> would have to check that.
[13:30:20] <SWPadnos> I know it's supposed to be the same as M2, but there were possibly some esoteric differences
[13:30:48] <SWPadnos> (not that there are *supposed* to be esoteric differences, but there may be)
[13:31:14] <cradek> there are lots of differences between % and M2/M30
[13:31:27] <SWPadnos> M30 is palette change isn't it?
[13:31:29] <cradek> I see that we already have STOP() which could be called and does what we want
[13:31:44] <cradek> yes, stop + palette change
[13:32:19] <SWPadnos> are you saying that there are supposed to be lots of differences between % and M2, or just that there are? :)
[13:32:47] <cradek> there are supposed to be
[13:32:51] <cradek> M2 does lots of things
[13:32:52] <SWPadnos> ok
[13:34:01] <skunkworks_> m30 - switch paper tape drive and pallet.
[13:34:05] <skunkworks_> ;)
[13:34:23] <SWPadnos> ok, I guess M2 is the end of program command, and % signals that there's no more input
[13:34:48] <SWPadnos> but I'm not sure I see what the differences between them should be
[13:35:05] <SWPadnos> (and it's not clear to me by reading the rs274ngc manual)
[13:36:22] <jepler> SWPadnos: % doesn't do any of the things that M2 does, besides stopping reading
[13:36:29] <cradek> M2 turns off the spindle, switches to G54, unapplies G92, switches to your default units, switches to G90, etc etc
[13:41:18] <alex_joni> cradek: I think there was some FLUSH canon call
[13:41:25] <alex_joni> I remember needing it for something else..
[13:42:01] <alex_joni> void FINISH() {
[13:42:01] <alex_joni> flush_segments();
[13:42:01] <alex_joni> }
[13:42:35] <alex_joni> from canon.hh:
[13:42:36] <alex_joni> * last segment to be output, if it has been held to do segment merging */
[13:42:36] <alex_joni> extern void FINISH(void);
[13:42:57] <alex_joni> hmm.. lost a line of comment there
[13:43:18] <alex_joni> /* to be called by emcTaskPlanExecute when done interpreting. This causes the
[13:43:21] <alex_joni> * last segment to be output, if it has been held to do segment merging */
[13:43:24] <alex_joni> extern void FINISH(void);
[13:44:36] <cradek> ok, that's much easier then
[13:44:52] <cradek> I added STOP() to all the canons, I'll call FINISH() instead
[13:45:04] <jepler> cradek: are you fixing this? thanks.
[13:45:43] <cradek> yes, welcome
[13:53:10] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (gcodemodule.cc interp_read.cc): fix #1937281: last move discarded if it's a G1 and the file ends with %
[13:53:10] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emccanon.cc: fix #1937281: last move discarded if it's a G1 and the file ends with %
[13:53:18] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: fix #1937281: last move discarded if it's a G1 and the file ends with %
[13:53:19] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/src/emc/canterp/canterp.cc: fix #1937281: last move discarded if it's a G1 and the file ends with %
[13:54:19] <alex_joni> cradek: cool ;)
[13:54:43] <alex_joni> cradek: ran any interpreter tests from the testsuite?
[13:55:59] <alex_joni> hmm.. flowsnake ends in %, but has an M5 before it
[13:57:40] <SWPadnos> cool!
[13:58:09] <SWPadnos> so - I just got off the phone with my friend who works for my previous company
[13:58:35] <SWPadnos> he said they've finally gotten fed up enough with Mach that they'd like me to come in and help them get EMC2 running :)
[14:02:35] <cradek> none of the tests change
[14:02:53] <jepler> that's good as long as none of them use percents
[14:02:54] <cradek> (hmm, I'm surprised flowsnake didn't then)
[14:03:02] <jepler> does it have m2 before %?
[14:03:28] <cradek> no...
[14:03:42] <SWPadnos> hmmm - I didn't try too many variations of final moves last night
[14:04:05] <cradek> oh, I didn't make saicanon print anything when FINISH() is called
[14:04:07] <cradek> duh
[14:06:55] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: #1937281: sai should print FINISH, and fix the corresponding test
[14:07:03] <CIA-30> EMC: 03cradek 07TRUNK * 10emc2/tests/interp/flowsnake/expected: #1937281: sai should print FINISH, and fix the corresponding test
[14:07:49] <cradek> I suppose nobody has noticed this because the last line of a real gcode program is almost always going to be a rapid
[14:08:16] <SWPadnos> yeah, of some sort
[14:08:42] <SWPadnos> G28/G30 are also possible, but those are rapids too :)
[14:08:56] <cradek> yep
[14:09:43] <micges> I've noticed this about 1 year ago when I wrote gcode generator... workaround is (MSG, ...) line before % and I leave that :)
[14:10:03] <jepler> bugs don't get fixed when they're not mentioned
[14:10:30] <cradek> but, often they get fixed fast when a good bug report is filed
[14:11:23] <micges> recently I manage to find bugs... earlier I knew too little
[14:12:05] <micges> I'm still learning
[14:14:33] <micges> bbl
[15:39:08] <alex_joni> bbl
[23:23:33] <jmkasunich> shiny new collets and chucks should arrive Thur or Fri
[23:23:42] <jmkasunich> getting paid in tooling is something I could get used to ;-)
