Back
[01:40:22] <cradek> did something happen to sampler? the limit3.0 test fails with no output.
[01:53:38] <cradek> cool, max5gui
[02:18:08] <jepler> cradek: I dunno, let me look into it
[02:18:49] <jepler> cradek: trunk? rt?
[02:18:55] <cradek> trunk sim
[02:19:56] <jepler> Failed:
[02:19:57] <jepler> ./limit3.0
[02:19:59] <jepler> same here
[02:20:16] <jepler> blocks: dlopen: /home/jepler/emc2.cvs/rtlib/blocks.so: cannot open shared object file: No such file or directory
[02:21:00] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/tests/limit3.0/test.hal: blocks is dead
[02:21:05] <jepler> fixed!
[02:21:07] <cradek> oh, I missed an error, sorry
[02:21:11] <cradek> duh
[02:21:14] <jepler> heh
[02:21:19] <jepler> "it doesn't work. I don't know what the error is"
[02:21:31] <jepler> a guy I know was bitching about something similar earlier
[02:21:57] <cradek> dang
[02:22:05] <cradek> I saw result (0 length) but didn't look at stderr
[02:22:12] <cradek> I will cry now
[02:22:15] <jepler> hah
[02:22:28] <jepler> in return you must fix this bug in offs
[02:22:40] <cradek> then I will complain that stderr is unnaturally redirected to a file
[02:22:50] <cradek> that will make me feel better
[02:22:55] <jepler> yes I'm sure
[02:27:57] <jepler> cradek: at that problem spot there are actually two primitives that are about to become zero-length, it looks like. One's the arc you spotted, the other's the line
[02:28:29] <cradek> hmm
[02:47:37] <jepler> looking at all the resulting contours (including the ones with the wrong winding numbers), I see one problem: there are some intersections not being found (the single arc shouldn't be able to intersect anything else):
http://emergent.unpy.net/index.cgi-files/sandbox/offs-unfound-intersections.png
[02:49:20] <cradek> I don't understand that image at all
[02:49:31] <SWPadnos> phew - it's not just me
[02:49:37] <jepler> heh
[02:49:48] <SWPadnos> I keep trying to zoom out
[02:49:49] <jepler> the path has been offset so much that it's unrecognizable.
[02:50:51] <jepler> after that step, another step is supposed to find all the self-intersections, turning them into separate contours.
[02:51:06] <jepler> then according to a winding rule, usually only certain contours are output
[02:51:10] <jepler> but in this case, I've shown all the contours
[02:51:31] <jepler> because the highlighted arc intersects another primitive part of a path, my self-intersection-detect-and-fix code is wrong
[02:52:07] <jepler> I think I have a general idea why, too (something I thought I could put off until I had islands specified in the input)
[02:52:32] <jepler> when there are self-intersecting paths then my winding rule may give the wrong results and lead to the bug in the last screenshot last night
[02:52:36] <SWPadnos> how hard is it to change the direction the path is "wound"?
[02:53:59] <jepler> you mean whether you specify an enclosed area by going cw or ccw? just a sign change somewhere
[02:54:12] <jepler> otherwise I'm as unsure what your question means as you are unsure what the image shows
[02:54:57] <SWPadnos> I was thinking that going along the path the other way could give different results, due to the order in which intersections are encountered
[02:55:19] <jepler> oh
[02:55:24] <jepler> yeah possibly
[02:57:46] <jepler> 'night guys
[02:58:17] <cradek> goodnight
[02:58:37] <SWPadnos> awwa you
[02:58:40] <SWPadnos> uh
[02:58:41] <SWPadnos> see
[02:58:52] <SWPadnos> maybe it's time for me too
[03:09:48] <SWPadnos> hmmm. I wonder if it's "easy" to remove loops by checking to see if the endpoints of an offset line are on the same side of the "centerline" between the two segments
[03:10:03] <SWPadnos> ie, consider a lne between the center of the original line and the center of the offset line
[03:11:04] <SWPadnos> if the start points of both segments are on the same side of that center line, then the offset line is valid (not a backtrack)
[03:11:34] <SWPadnos> if the start points are not on the same side of the centerline, then the poffset path is a loop, and should be removed
[03:11:36] <SWPadnos> -p
[11:51:51] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: allow display of rapids in preview to be disabled
[11:51:51] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: allow display of rapids in preview to be disabled
[12:09:18] <cradek> that sounds neat
[12:32:14] <fenn_> fenn_ is now known as fenn
[12:57:34] <fenn> jepler: i dont think it makes sense to offset a self-intersecting path.. can't you just remove any self-interscting loops in the path before doing any offsetting?
[12:58:17] <SWPadnos> the original path wasn't self-intersecting, it's the calculated offset path that is
[12:58:44] <SWPadnos> so I think it's a matter of detecting that, which it does correctly most of the time
[13:43:07] <SWPadnos> huh - interesting:
http://www.osadl.org/Single-View.111+M5f4c5c0c4a3.0.html
[14:13:20] <rayh> The only issue I see is whether the whole system or software PLC honors read, logic, and then write principal that a PLC is based on.
[14:15:04] <SWPadnos> that was my concern as well
[14:15:19] <SWPadnos> it seems to say that things will change "immediately", which is the opposite of a PLC
[14:17:43] <rayh> IMO it just looks like what a PLC does.
[14:18:21] <SWPadnos> it seems more likea C-style HAL than a PLC :)
[14:24:02] <rayh> Does look that way.
[14:59:47] <jepler> fenn: yes, it is the offset path which becomes self-intersecting. the code has to resolve all those self-intersections.
[15:00:41] <jepler> when a single contour becomes self-intersecting, the solution is to break it into two simple contours. That's the case I wrote so far. The second case is that contours A and B intersect; I didn't write that yet, because I thought it couldn't occur if you didn't start with multiple contours.
[15:04:24] <rayh> Some thoughts re PLC and linux.
http://i.cmpnet.com/ddj/images/article/2007/rtl_pdf/rkaiser01.pdf
[15:14:17] <jepler> iC looks neat; somebody should adapt it so you can write .comps with its features
[15:19:00] <rayh> That thought scares me more than the current way that HAL handles logic.
[15:29:55] <rayh> I should correct that last thought. Scares me more than the way that HAL can be programmed to handle logic.
[15:30:43] <SWPadnos> I wouldn't use it as a PLC, someone emailed me that link this morning, and I thought it looked intriguing
[15:31:01] <SWPadnos> some of what it has would be great for HAL though, if it could work within the kernel code
[15:31:15] <SWPadnos> things like callbacks for parameter changes
[17:23:29] <skunkworks> cvs seems to be down?
[17:24:53] <skunkworks> hmm trace route only gets to the router.
[17:25:01] <skunkworks> It was working this morning.
[17:27:25] <skunkworks> oh - maybe it is raining there.. ;)
[17:50:42] <micge1> micge1 is now known as micges
