jmkasunich_ is now known as jmkasunich
fenn_ is now known as fenn
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: I think all line-arc and arc-line cases are finally right.
that leaves arc-arc (which I think is actually easier, but that may be because I haven't tried it yet)
just - you know - combine the arc-line and line-arc routines
but like, take out the line parts
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix wrong move on double-G40
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: arc-arc case done
*cheering from the cheap seats
[19:35:08] <cradek> http://timeguy.com/cradek-files/emc/concave.png
note the tangent arcs! (the hard case)
how strange. I'd think that would be the easier case
thanks for doing this though - it makes my head hurt :)
there are two equally-good-seeming solutions
I thought arc-arc would be the hardest case, but it's much simpler than arc-line/line-arc
do you nave more or less generalized offsetting code in there now as part of this?
what is this word "generalized"?
seriously, I'm not sure what you're asking
I'm thinking about longer look-ahead
each case has its own geometric solution
ahh, nope, it just looks ahead one move
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
well jepler has written some of that. it's not clear to me that it belongs in a machine control
in theory, it's useful
it's extremely useful in a cam package
actually, it probably is in practice as well
cradek: I am betting that your code will detect "gouges" in a lot of bad cam output when it encounters short segments
jepler: probably so. currently, it doesn't complain. Maybe it should stay that way.
heck, look at the length of the segments from ttt in biarc mod
it currently craps out on something ttt/biarc generates
if it's a concave area and those segments are shorter than the radius, you'll report gouging
a CAM package could easily generate tiny segments that would disappear from an offset path
those reversals in one of the early screenshots would go away with 2-segment lookahead
jepler: depends how concave (I think)
so I guess there are good reasons to have more than one segment lookahead in the code
SWPadnos: but suddenly the number of geometric cases blossoms
tws - there would need to be some kind of loop detection in the code - look for loops and trim them out
that may be the general answer, but I'm not sure
tws - what the heck was that?
ah - yes
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
while (in emc's case) your mill stops moving
to prevent any gouging that's true, but to prevent gouging on N segments you only need to look at those N
I'd love to have the code. I'm just not sure it belongs in emc.
yeah, I dunno either
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
it's true in a lot of cases the loops could be small
the fix would require changes to the IO / task controllers, and maybe GUIs as well - unless NML has some help for it
the scenario is that RT is still running, but userspace (or the kernel even) are crashed
so the motion controller runs out of segments, and stops while waiting for more commands
with the spindle doing 30000 RPM in MDF
= heat = fire if not noticed soon
you don't have to crash anything to run out of segments...
assuming that the program eventually moves away from the work and stops the spindle, when would there be an "indefinite pause" in motion?
1/2 second isn't a big deal (necessarily) - "until manually stopped" is
are you asking when nonrealtime code might pause? if so the answer is anytime
very long pauses are unlikely, but so is the situation you describe
I'm not trying to be an ass, but if it's a problem, it's an architectural problem
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)
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
we could maybe have a nonrealtime heartbeat of some kind if it's a problem we want to guard against
that was the solution I thought of
actually, I just thought a "better" one
heartbeat from the gui I guess if gui response is the important issue
yeah, that's the road I ended up going down, but there are problems with remote UI (or IO) modules
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
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
"machine stopped" meaning not moving, as opposed to "machine off"
but beware the pause button and feed override and ...
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
sure, but that's still N^2
hmmm - sequential sort is nlog(n) isn't it?
and you still need to analyze the whole program at once
SWPadnos: sure there are plenty of NlogN sorts
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
I thought that one was Nlog(N)
hmmm - nope - N*(N+1)/2
Chris... the next request will be a param to limit gouges to some amount Gxx P0.005
with the gouge protection I'm considering, that would not be hard.
(if we're talking about the gouge that comes from an overly short segment)
cool... really comes into the cam relm.... decisions on how accurate each dimension has to be
it's "examine the whole program and guess where the part is, and check for gouges all over" that I'm trying to poopoo.
(as not belonging in emc) - it's great for cam
well, allowing 1 segment of gouge-prevention is light years ahead of 0
so, uh, bravo
yeah it will make a LOT of programs work right
very nice indeed... good work
especially programs generated for nominal tool size that need a little tweak
(this is the only usage of cutter comp I saw used in a recent visit to a large shop)
lots of machines were showing diameter -0.010 on the screen
and CAM is fast enough these days that smaller shops don't even need the tool "regrind comp"
just re-POST the file for the measured tool
(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)
I bet that's good enough in a lot of cases. no need to excuse anything.
no, it's an excuse with this guy ;)
but it does work
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.
SWPadnos: made it safe back?