Back
[00:47:27] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[03:11:36] <fenn_> fenn_ is now known as fenn
[16:50:10] <CIA-23> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: I think all line-arc and arc-line cases are finally right.
[16:50:28] <SWPadnos> yay!
[16:50:49] <cradek> that leaves arc-arc (which I think is actually easier, but that may be because I haven't tried it yet)
[16:53:15] <SWPadnos> just - you know - combine the arc-line and line-arc routines
[16:53:24] <SWPadnos> but like, take out the line parts
[16:53:34] <cradek> ummm
[16:54:36] <skunkworks> heh
[17:11:14] <CIA-23> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix wrong move on double-G40
[19:33:40] <CIA-22> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: arc-arc case done
[19:34:42] <skunkworks> *cheering from the cheap seats
[19:35:08] <cradek> http://timeguy.com/cradek-files/emc/concave.png
[19:35:48] <cradek> note the tangent arcs! (the hard case)
[19:36:15] <SWPadnos> how strange. I'd think that would be the easier case
[19:36:33] <SWPadnos> thanks for doing this though - it makes my head hurt :)
[19:36:33] <cradek> there are two equally-good-seeming solutions
[19:36:40] <cradek> :-)
[19:37:12] <cradek> I thought arc-arc would be the hardest case, but it's much simpler than arc-line/line-arc
[19:37:28] <SWPadnos> do you nave more or less generalized offsetting code in there now as part of this?
[19:37:41] <cradek> what is this word "generalized"?
[19:37:44] <SWPadnos> heh
[19:37:52] <cradek> seriously, I'm not sure what you're asking
[19:38:00] <SWPadnos> I'm thinking about longer look-ahead
[19:38:04] <cradek> each case has its own geometric solution
[19:38:23] <cradek> ahh, nope, it just looks ahead one move
[19:38:44] <SWPadnos> if we added 500-segment lookahead one day, would it be "alomst reasonable" to use the same code on later segments, to see about gouges
[19:38:46] <SWPadnos> ok
[19:39:10] <cradek> well jepler has written some of that. it's not clear to me that it belongs in a machine control
[19:39:24] <SWPadnos> in theory, it's useful
[19:39:41] <cradek> it's extremely useful in a cam package
[19:39:48] <SWPadnos> actually, it probably is in practice as well
[19:39:52] <jepler> cradek: I am betting that your code will detect "gouges" in a lot of bad cam output when it encounters short segments
[19:40:20] <cradek> jepler: probably so. currently, it doesn't complain. Maybe it should stay that way.
[19:41:31] <jepler> heck, look at the length of the segments from ttt in biarc mod
[19:41:46] <jepler> (arcs)
[19:41:54] <cradek> it currently craps out on something ttt/biarc generates
[19:42:02] <jepler> if it's a concave area and those segments are shorter than the radius, you'll report gouging
[19:42:07] <jepler> right?
[19:42:12] <SWPadnos> a CAM package could easily generate tiny segments that would disappear from an offset path
[19:42:46] <SWPadnos> those reversals in one of the early screenshots would go away with 2-segment lookahead
[19:42:48] <cradek> jepler: depends how concave (I think)
[19:43:04] <SWPadnos> so I guess there are good reasons to have more than one segment lookahead in the code
[19:43:22] <cradek> SWPadnos: but suddenly the number of geometric cases blossoms
[19:44:05] <SWPadnos> tws - there would need to be some kind of loop detection in the code - look for loops and trim them out
[19:44:12] <SWPadnos> that may be the general answer, but I'm not sure
[19:44:24] <SWPadnos> tws - what the heck was that?
[19:44:35] <SWPadnos> ah - yes
[19:44:39] <cradek> yes that's the general answer. but it means you have to store up possibly the whole program and do N^2 analysis on it
[19:45:01] <cradek> while (in emc's case) your mill stops moving
[19:45:21] <SWPadnos> to prevent any gouging that's true, but to prevent gouging on N segments you only need to look at those N
[19:45:22] <cradek> I'd love to have the code. I'm just not sure it belongs in emc.
[19:45:30] <SWPadnos> yeah, I dunno either
[19:46:16] <SWPadnos> on another topic: when jymmmm and I were talking about a charge pump circuit, he came up with an interesting case that isn't covered by the present code
[19:46:17] <cradek> it's true in a lot of cases the loops could be small
[19:46:51] <SWPadnos> the fix would require changes to the IO / task controllers, and maybe GUIs as well - unless NML has some help for it
[19:47:11] <SWPadnos> the scenario is that RT is still running, but userspace (or the kernel even) are crashed
[19:47:31] <SWPadnos> so the motion controller runs out of segments, and stops while waiting for more commands
[19:47:41] <SWPadnos> with the spindle doing 30000 RPM in MDF
[19:47:50] <SWPadnos> = heat = fire if not noticed soon
[19:48:47] <cradek> you don't have to crash anything to run out of segments...
[19:49:27] <SWPadnos> assuming that the program eventually moves away from the work and stops the spindle, when would there be an "indefinite pause" in motion?
[19:49:55] <SWPadnos> 1/2 second isn't a big deal (necessarily) - "until manually stopped" is
[19:50:34] <cradek> are you asking when nonrealtime code might pause? if so the answer is anytime
[19:50:52] <cradek> very long pauses are unlikely, but so is the situation you describe
[19:51:20] <cradek> I'm not trying to be an ass, but if it's a problem, it's an architectural problem
[19:51:44] <SWPadnos> I agree it's an unlikely event, but I have had a kernel crash (couldn't ping the machine), with RT still running nively (better than when the kernel was alive)
[19:52:14] <SWPadnos> and jymmm has had problems where the UI looks like it's OK - mouse moves and whatnot, but F1 does nothing. ctrl-alt-backspace was needed to get X back
[19:52:17] <cradek> we could maybe have a nonrealtime heartbeat of some kind if it's a problem we want to guard against
[19:52:27] <SWPadnos> that was the solution I thought of
[19:52:35] <SWPadnos> actually, I just thought a "better" one
[19:52:39] <SWPadnos> ~of
[19:52:43] <cradek> heartbeat from the gui I guess if gui response is the important issue
[19:53:21] <SWPadnos> yeah, that's the road I ended up going down, but there are problems with remote UI (or IO) modules
[19:54:08] <SWPadnos> another solution is to make a realtime component that monitors motion commands and shuts down the machine if too much time elapses without any movement
[19:54:16] <cradek> basic problem (if it is one) is that guis are nonrealtime. if you want to guard against this particular case (spindle running while machine is stopped) you could do that in RT using basic HAL stuff
[19:54:25] <SWPadnos> yep
[19:54:46] <SWPadnos> "machine stopped" meaning not moving, as opposed to "machine off"
[19:54:53] <cradek> yes
[19:55:01] <cradek> but beware the pause button and feed override and ...
[19:55:02] <fenn> gouge detection doesnt have to compare every segmet against every other one - you can do a bounding box and only compare against segments in that box
[19:55:07] <SWPadnos> heh
[19:55:52] <cradek> sure, but that's still N^2
[19:56:02] <SWPadnos> hmmm - sequential sort is nlog(n) isn't it?
[19:56:09] <cradek> and you still need to analyze the whole program at once
[19:56:48] <cradek> SWPadnos: sure there are plenty of NlogN sorts
[19:57:25] <SWPadnos> each segment only needs to be compared to later ones (N+2 and on - it's known that N+1 intersects), and any that intersect are gouge points
[19:57:41] <SWPadnos> I thought that one was Nlog(N)
[19:58:01] <SWPadnos> hmmm - nope - N*(N+1)/2
[19:58:58] <LawrenceG> Chris... the next request will be a param to limit gouges to some amount Gxx P0.005
[19:59:13] <SWPadnos> NEXT! :)
[19:59:24] <cradek> with the gouge protection I'm considering, that would not be hard.
[20:00:20] <cradek> (if we're talking about the gouge that comes from an overly short segment)
[20:00:43] <LawrenceG> cool... really comes into the cam relm.... decisions on how accurate each dimension has to be
[20:00:55] <cradek> it's "examine the whole program and guess where the part is, and check for gouges all over" that I'm trying to poopoo.
[20:01:21] <cradek> (as not belonging in emc) - it's great for cam
[20:01:40] <fenn> well, allowing 1 segment of gouge-prevention is light years ahead of 0
[20:01:57] <fenn> so, uh, bravo
[20:02:00] <cradek> yeah it will make a LOT of programs work right
[20:02:01] <cradek> thanks
[20:02:23] <LawrenceG> very nice indeed... good work
[20:02:34] <cradek> especially programs generated for nominal tool size that need a little tweak
[20:02:40] <cradek> generated/written
[20:03:03] <cradek> (this is the only usage of cutter comp I saw used in a recent visit to a large shop)
[20:03:37] <cradek> lots of machines were showing diameter -0.010 on the screen
[20:03:46] <SWPadnos> and CAM is fast enough these days that smaller shops don't even need the tool "regrind comp"
[20:03:59] <SWPadnos> just re-POST the file for the measured tool
[20:04:52] <SWPadnos> (that's the lame-ass excuse given to me by a friend who can't do cutter comp with DeskCNC, but the CAM runs in seconds)
[20:05:25] <cradek> I bet that's good enough in a lot of cases. no need to excuse anything.
[20:05:50] <SWPadnos> no, it's an excuse with this guy ;)
[20:05:51] <cradek> heh
[20:05:51] <SWPadnos> but it does work
[20:28:01] <skunkworks> with our old ass equipment - that is all we could do.. Re-ouput gcode with correct offset. It will be fun to play with it.
[20:31:12] <alex_joni> hi all
[20:31:50] <alex_joni> SWPadnos: made it safe back?
