jmkasunich, you there?
he's out for a few hours - has obligations this evening
I'm looking at the ini/* stuff and motion/usrmotintf.cc
some are using rcs_print_error and some rtapi_print and some places the libnml just uses fprintf
what the hell is the standard?
none of these code runs RT as far as I can tell
usrmotintf may have been meant for RT (or at least is interfaced to the RT motion controller) ??
well the name implies it's the user part and that's what it appears to be
names are often deceiving in this realm ...
but you're probably right
so how about just fprintf?
less deps on no-standard stuff
dunno. I'd have to look it over, which I haven't yet
rtapi_print has several redirection / debug level features, I think
usrmotintf is the only one using that
hmmm - iosh uses it, as does milltask (I'm not sure why that's even built these days)
I don't think it's important enough to change in usrmotintf.cc at this point
no, all that code is going to go away
the print code is in the exception class
but I have to make sure it does the right thing
printing shouldn't be there, formatting to a string should be
why, it has a Print() method
the caller should be able to decide where the output goes
you call it to print the exception
he does, take a FILE *
I think the library will be more generally usable if it makes no assumptions about where the error text goes
consider someone putting it in a dialog box, for example
how is taking a FILE * making an assumption?
you want it to go to a string?
consider someone putting it in a dialog box, for example
that's my preference
well, I would make a type cast operator for that
the caller can rtapi_print or MSG_BOX or whatever they want
why dup the print code all over the place
type cast to cstr or whatever
because it's not necessarily duplicated
yes, it is
there will be code to print a string in 20 files
no, it's not. a UI would be very justified in putting up an error dialog, and that's not a file of any sort
just add one more method to the class to type cast and you can get a string
you're not getting my point
all the current code calls print
the GUI can type cast and get a string
no dup code
having an Output method that takes a FILE* is great
but the print method should still use the EMC standard, whatever that is
as long as there's a way of *not* outputting and getting a string back instead
there are several standards, depending on where/how the code executes
(and I'm sure non-standard uses as well)
all of this is user space code
anyhow, INI from the GUIs is totally foobar
no, the UIs use the ini file just like all the other code
yeah, but that breaks with remote access
so it's not really right
they should be using NML link or whatever
it can, but it depends on the UI - a fully remote UI obviously couldn't do that
yep - something else would be great
it could if the comm link was complete
anyhow, the code can't be any worse than it was, with un-asked for prints all over
rtapi is also supposed to work for userland - it's ULAPI
which may be incomplete
seems high time to me to have a serious architecture review and set some goals
even the simplest task becomes a pain
I'd like to spend some time on very high level considerations, then get some goals from that, then do a new branch for implementation / experimentation
I don't think it makes sense to branch right away, since we don't have any well-defined goals yet
the more I look at what's there , there are two somewhat defined interfaces
(lots of scattered goals, but no good set)
the NML stuff to the UIs and the usrmotinf
I think everything in bewteen is up for grabs
well, I'm thinking at other levels. such as unit handling, remote operation (and what needs to be reomte-able), how the I/O, motion, and user subsystems need to interact, etc
you're thinking really big
I'm thinking just get a clean base to build on
I'd like to consider what to build towards before making that base
it may affect the arrangement of the clean base
does anybody even use a remote UI now?
the NML to motion has been gone a long time
and it seems like everything works better with X for the UI stuff
Eric Johnson (I think) just made a telnet-based remote UI
emcrsh, I think
so he has a local UI server that answers the telnet port?
there's definitely interest in remote UIs, partly because you can't use any really good hardware if you want good RT performance, so people want to use little headless embedded systems to run the machine, and a "normal" fast computer for display
yes, there's a server that runs on the machine controller
I think it's in CVS now, but I could be wrong about that
hmmm - no, I guess it probably isn't
yep - I see it now
I just looked at it, its a local UI server
it listens on telnet port
so it's not remoting over NML
no, it's not NML
so I don't think remote NML is used at all
that's why I say it's best to look at the capabilities you want to eventually have, and make the clean base from those
it can be used by anything that sits on top of emcsh, I believe
I don't think anybody even knows how to setup the NML config to remote it anymore ;-)
I have run tkemc remotely via NML
also a remote DRO application
was it better than with X?
yes and no
I run the whole EMC with X and all the GUI stuff works great
if your vision is a product that runs natively on windows, for example, NML is what you want
one main difference is that the apps actually ran on the remote machine, not the controller
if your vision is a machine that does not have X client libraries on it, NML is what you want
I can do that too, but not on any 64-bit SMP machine with accelerated 3D
I don't really want any of my control running on a machine with a bunch of other user SW
especially a doze box
the UI can come and go, the machine keeps running
yes, but you lose all control
no, you can reconnect whenever you want
if your doze box just crashed, and then your cutter breaks, your in trouble
if anything goes wrong while the GUI is down, what do you do?
you run for the estop button
the real hardware estop
which is what you should reach for anyway
yes, of course
in any case, remote UI via NML is usable now, it's just generally unused
I think it's hard to seupt and it doesn't really work
I think remote UI via something lighter weight than X or VNC is a necessary feature
you have to dup the configs and g-code
and param changes can't be seen...
yes, it's not perfect
yes - remote HAL (viewing and I/O) is a separate issue
not HAL, I mean interp
have you ever heard the phrase "Perfect Is the Enemy of the Good"?
we have Good
or Good Enough
that's why I'd like to start with very high level targets, then boil them down to lower level goals
HAL shouldn't need to be changed after the machine is setup
HAL may need to run on multiple conputers for some machines
for some value of "need"
and assuming you call a microcontroller a computer ;)
well I don't think NML is going to be an answer for distributed HAL
again, that's why I think you have to start with "what do we want to be capable of" rather than "is NML good enough"
steves_logging is now known as steve_stallings
hi other Steve
how's the weather down there
you guys have been heavy at the software structure lately...
thoughts? opinions? ...
we just got our last snow of the season, hopefully, about 3" but it will be melted in a day or two
if the 3 feet on the ground melt by April, I'll be surprised
I need to make a trip sort of up your way, Nashua is a few miles short I guess
when will you be there?
(it's about 190 miles from here)
no firm schedule, eBay purchase pickup
I'll be in Manchester next weekend (15th-18th), which is only ~20 miles away
OK, you can pick it up and bring to CNC Workshop 8-) !!!!
no problem, just send me a vehicle ;)
actually your minivan will work fine, it is a benchtop reflow oven about 4' long
it would work fine, if I could get it inspected again :(
it hasn't felt right after the accident, and the repair shop said that it wouldn't be inspectable without some fairly major bodywork
(sharp edges, don'tcha know)
[01:52:21] <steve_stallings> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140079228826
oops, didn't know about the accident
heh -happened about a week after the workshop last year
and the inspection is about to run out now (end of this month)
well, if it isn't filled with lead, it could be light enough ;)
hot air, not lead
oh right - you said IR reflow, didn't you
or reflow anyway
what do you think it weight? that base looks pretty beefy
yea, we only use thru hole when forced to
of course :)
seller said two people could load it no problem, guessing less than 300 lbs
out of curiosity, how much of a price difference do you see for SMT vs. TH (for roughly equivalent boards)
price of what?
last I knew, it was around 6 cents/SMT part, or ~2c/pin for TH
special handling being extra (for connectors that have to be held to a certain height or whatever)
labor to assemble? cheaper for thru hole in small quantity because of the setup charges on SMT, typically SMT is not economical in less than 200 piece runs
I have a local customer that I'm trying to convince to change a board to SMT. the thing has several hundred parts, and they use a few hundred units a year
if SMT has anything other than typical chip R/C or standard IC packages, forget it and put them on by hand
I'm convinced that the assembly costs would make it worthwhile, and the SMT chips are less expensive these days as well (in general)
the only problem (as usual) is connectors
not to mention many thru hole ICs are getting hard to find
yeah, that's true too
so, do mixed assy, use thru hole connectors with SMT, all my products are that way
yep - that's the plan
if I can get them to commit to the engineering charges :)
I pay about 6 cents/SMT part out here, never any setup fee, and a one time NRE for programming which is usually waived
ok - that's about what I remembered
manual work is expensive, 6 cents a pin for through hole
lucky you, local guys here want $20 for each feeder that they have to load
wow, that's rediculous
I can recommend a couple of places to visit in Manchester, if you want more reasonable assembly houses :)
we run low volumn and do it in house
though they're more geared toward higher volume (not mass volume, but definitely a few hundred/month is the target)
we can run as few as a dozen boards because we have full control and no other jobs waiting for the equipment
yep. though it seems some of the main gains are in quantity purchasing, not as much assembly
on the other hand the gear we have would not be able to run hundreds a day, too slow
well, when you're selling that much stuff, you can afford better gear
true, maybe someday....
well Mariss is buying his third high speed pick-n-place
yeah. he's doing something like 3-5k drives/month
plus 2 or 3 G100s :)
hey Ray, I looked through the manuals I have collected and the only one that mentions loading offsets from G code is the Bridgeport Boss
it uses T01/0.345 to load a Z tool length offset into tool #1, no provision for radius load from G code
the Smid book has no mention of loading tool table from G code either, but it sure seems like a handy feature to have
SWPLinux: I don't want to be pushy but I wonder if you were able to test comp any
I'm trying now, with Patrick's file
trying to get it to work, which my suggestion doesn't :(
ok, I don't know who patrick is, but that's ok
he sent the problem to the user list today
I responded ioncorrectly later today
now I'm trying to figure out how to actually fix the problem
I'll look too
you have the message, I assume
he wants to cut the outside right?
I believe so
that's easy :-)
that's the assumption I'm under anyway
ok - once I align the straight lead-in, it works great
interesting semi-bug with AXIS preview
the first line in my file is a toolchange (using sim-axis config)
so it moves to some very high Z at X=Y=0
that move isn't shown, because the preview ignores toolchanges (I assume)
so it shows up as a white line from the origin to the next endpoint
that's a hard "bug" to fix, so I prefer to define it as not-a-bug
I'm ok with that
yeah - it's a semi-bug because there's no real solution IMO
[02:22:01] <cradek> http://timeguy.com/cradek-files/emc/patrick.png
cradek: how much do you want to bet the limits are right on that move?
cradek: the one after the move to the tool change position
you mean vel/acc constraints?
they're right afaik
oh -- great then
don't let that stop you from checking
* jepler gets called away
at a glance, it looks right
SWPLinux: undocumented? but maybe-useful helical entry: http://timeguy.com/cradek-files/emc/patrick.ngc
hmm, I don't think arc entry (first move an arc) works - I wonder if it ever did
I used a linear entry in my Patrick modifications
from X0.9375 Y0.5 or something
I think everyone does it that way
I should look at Ray's article
try a tangent arc entry
(on cutter comp)
I bet you $1 he uses a line
for an arc entry, the arc is suposed to end tangent to the first actual line you awnt, not the compensated line, right?
gimme the dollar. in one example, now extinct, I used variables and an arc.
you mean the arc endpoint you program?
Chris buys Ray a coffee!
(or 1/3 of a Starbucks coffee)
I'll buy anyone a coffee anytime
1/3 is more than I can stand.
An arc into a diameter offset.
I can't seem to make a tangent arc work
anyone want to see my gcode?
[02:52:45] <cradek> http://timeguy.com/cradek-files/emc/tangentarc-noworky.ngc
oh right - G3 is counterclockwise, isn't it
hmmm - another possibly-a-bug-in-AXiS
lemme make sure thouh
I think IJ format arc entry (first move arc) is broken
the center of the arc isn't moved, so I don't see how it can work
it looks like in both the linear and arc entry moves, you need to get to the correct compensated point before turning on compensation
I don't understand that
ok - you'd think that you could just move "somewhere on the left side" of the desired shape then turn on compensation, move to the first point (compensated, so you don't have to figure anything out), and go
no, because you can't make a concave corner
but you can't - you have to figure out how to arrive on the compensated path
and if you approach from the other side, you'll actually gouge (even though it probably isn't an error)
you don't gouge the programmed shape
we desperately need paper for this
consider Patrick's shape - a square from (1,1) to (2.0)
err - to (2,2)
let's assume that we start below the box (Y<1)
using a 1/4" cutter, to reduce typing :)
you have to start at X > .75 for a line entry
if you start at X>0.875, you'll actually gouge the part
no you won't
just a little, and more the firther right you start
(yeah .875, sorry)
it goes around the corner
makes an arc around it
only if there's a corner in the compensated path
sure (I thought we were talking about the box)
if you want to comp for a while to the left of an infinite line, you have to enter with an arc
right, so G1X0.9Y0.5
In the old days, I'd imagine an outside corner above the internal arc to be cut. Round that while adding comp and then z down and cut.
SWPLinux: it will make a line and two arcs -- the second arc will go right around the corner
it will not gouge the square
I get an error trying to run that code
[03:10:28] <SWPLinux> http://pastebin.ca/385825
I used T2/D2 because that's the size cutter patrick used in his example (in sim-axis)
I get an error on line 7
you meant X1.9 on line 4
if the first move is to X0.9375 (D/2), it works
no I didn't. that would give me a 3-sided box, I think
ok I don't know what you mean
I may not either
anything less than X = 1-D/2 will not work
if you change 0.9 to 0.9375, it works fine
yes .9375 gives you a straight entry
ok - X1 does work fine (but I could swear it didn't at least once)
X2 looks right too
now use an arc :-/
R format arc doesn't work for me either (I changed -noworky's arc to R0.5)
This needs to be better documented, with figures. There are eight
nos that's weird - I get an error "R i j k words all missing for arc", when there's clearly an R on the line
the error is on the next line
(you took out an important g1)
yes I did
well, left it out anyway
ok, the arc entry works for me with R, bu tI get "radius not the same ..." for IJ
the R that would make it exactly tangent, or a bigger one?
well, that depends
R9999 is going to work, it's R.5 in my test program that sould be tangent
[03:20:18] <SWPLinux> http://pastebin.ca/385835
same code, but with an arc that would be exactly tangent to the part outline (not the compensated outline)
ok, that case works
you should be able to change it to G3, right?
that's the one I wrote (the case I think is broken)
yes, that appears to work
no, I think it's the wrong arc
it gouges the part
it looks right to me
ok - on closer inspection it is a little off
gotta run. catch you tomorrow
see you later
the equivalent IJ would be I-.5 J0 right?
yes, I think so
if you do that, you get an inappropriate error
maybe I did that wrong
yes - that's the error I have been getting whenever I try IJ arc entries
I think it's not right
once comp is on, arcs are right, but this first arc is wrong
why are there separate functions for comp on the first move?
I think I can plainly see Interp::arc_data_comp_ijk is wrong because it doesn't move the center
petev: it's special - it transitions between non-comped and comped
I guess I'm missing something
petev: this takes some study - please jump in if you like
is this for the point when it's turned on, or for the first move of the tool?
the first move after turning it on
so what kind of transition is supposed to happen?
if you're on an arc and you want to turn on in the middle of a run, the result won't be an arc
do you have the manual on your machine? I think there are diagrams of some of the moves around page 162
seems like comp should be turned on when the tool is loaded
it depends. you don't need comp when moving to a feature to mill, but you do before you start cutting
and you don't want to gouge the part on the way there
right, but sounds like this odd case is turning it on during a cut, which doesn't seem like a valid thing to do
the entry is complex - the machine can't guess it for you
petev: do you know how to use comp in gcode?
there should be an initial entry move without comp, no?
it must be turned on during a "cutting move", such as a G1/G2/G3
you move somewhere close by, then turn on compensation, then move in near the work (this move gets compensated by the end), then it remains on while you cut
seems like there are two cases for comp
line to arc and arc to arc
and line to line
and line to line
the line to line has two cases of its own
petev: we're talking about entries
a specific case of entry even
just want to make sure we're on the same page for what's expected
I'd like for us (me and swp) to be able to continue that without helping you learn about comp right now
if you have a look at the manual like swp said, you can see the one we're talking about
fine, I beleive I understand it fine, I just wanted to bring up some points that may have been overlooked
I think the diagram I want isn't in the manual
petev: go ahead. it's possible that it's easier than previously thought, but I'm skeptical :)
ok, so for an arc entry
allow us to interrupt from time to time with other findings though :)
if you are not on the compensated path
incidentall, where the hell is ERM defined?
and you want to end up on the compensated path at the end of the move
SWPLinux: interp_internal.hh (get an editor that supports tags)
the resultant move is not an arc if you want to end up tangent to the next line
do you guys agree with that?
I was looking there, but didn't notice it
there's an arc that'll go through your current point and be tangent to the path
the trick is to find it
many of them in fact
ok, but in that case you are changing the inital trajectory angle too
yes that's the point of an entry move
is that acceptable?
think of the line case - of course the line changes direction
I never use comp like that on the BP
it's on before the tool comes into the cut
it might be a case most people don't use
EMC needs to prevent the tool from gouging if people do want to do this
(I think this has been wrong forever in emc)
even if it is "dangerous"
there's nothing dangerous about it
is all the code for this in interp_convert.cc?
no, some in interp_arc
dangerous for the user to get "real close" to the work before changing comp modes
see Interp::arc_data_comp_ijk for the simplest view of this bug
luckily, that's at the top of the file :)
the center is calculated
and there's the "radius differs..." return value
beginning radius is calculated
endpoint is moved
no, endpoint is moved later, maybe I'm missing something
end is moved back in convert_arc_comp1
and the center is never moved
so you've destroyed the arc
the move==30 and move=20 should be changed to G_3 and G_2
well, that code is clearly wrong. radius2 is calculated from the endpoint (like a normal arc), then the tool radius is added/subtracted, and the comparison to arc_radius is done immediately
of course that will be wrong, because the center hasn't moved yet (which is what you just said)
you'd have to move the center before you call that
so who "gets" to fix it?
heh - I've been thinking of what the desired operation actually is, and I'm not sure I know
didn't Jon Elson have a paper on compensation? (the one that some of the diagrams in the user manual came from)
or was that from Ray
do you agree there's one correct arc?
for an arc lead in?
yes for arc entry
no, if you want to let the initial trajectory change, there are many
if we can define what correct means, then yes, I suspect there's exactly one correct arc
many that would end up tangent to the next line
petev: the endpoint is fixed, and two tangents I think?
2 endpoints and one tangent are fixed
no, two endpoints, one tangent
if the initial trajectory is not fixed, I only see one line to end up on
that's one arc
no, I think it's many
you don't end up on a line, you end up at a point with a certain tangency
the question is where is the second endpoint?
oh - that's probably the problem with the R word version
one sec - I've got to think in pictures for a bit
I might sleep on it
thanks for helping
if you want the arc to end right at that point, then I think there is only one
I think I see the problem with R words
but there are more than would end up on the line before that point
yes, though they wouldn't be tangent (I think)
but the entry arc would hit the line before the point
yes because tangent to a line and through one point is not enough constraints
well, I suppose there are any number that would, but the radius would be unrelated to the programmed radius or the compensated radius
yes that's right
and that's the problem with R (and possibly IJK)
you don't have the same arc length for the programmed circle and the compensated circle
wait - the final position of the tool is right already, it's along the final radius of the original arc (arc rad reduced by tool rad)
yes - the arc length and/or center point are off
oh you realized that, sorry then
np - I don't know what I'm talking about yet ;)
why does arc length matter?
SWPadnos, did you mean in degrees?
if you don't adjust for the arc length (included angle), then the radius will be wrong (I think)
oh, more specifically included angle
the arc degrees of the lead in will not match the original arc
right - they're proportional for circular arcs
well the radius will change
diff radius and diff degrees
yes, and different center point
and different endpoint (of course)
we have the endpoint
we have a tangent at that endpoint
we have the start point
do we actually have the tangent at the endpoint?
I think tangent at the endpoint is the tangent of the original arc
if it's arc to line
is it assumed to be parallel to the tangent of the programmed arc, but offset (toward the center) by the comp radius?
ok, parallel to the original, but offset
offset toward the center of the original arc, yes (I think)
yes, or away, depending on the arc and the comp side
the error is smaller with a larger radius entry arc
this may be an atan2 precision thing or something silly like that
well if you enlarge R you won't gouge (but you're not doing tangent entry either)
yes I think I am
no, it's way off
I changed that last program to move to X2Y0, and do an entry G3R1X1Y1
[04:13:23] <cradek> http://timeguy.com/cradek-files/emc/wayoff.png
this is your original program with R0.5 which should be tangent
yes - that's a larger error than I get when doing the G3 from X2Y0 with an R1 arc
which should also be tangent
sure it will be worse with a smaller arc
I don't know that there's an arc that can satisfy the constraints
ok, been looking at what other controls seem to allow, and they don't allow cutter comp to be turned on in this case
here's one from Haas
[04:18:08] <petev> http://www.cncmagazine.com/Answers/Offsets.htm
well that's sure one possible fix
SWPadnos, there is an arc that will work, start point, end point, and tangency = one arc
I would never turn it on like this
maybe roltek is around
he was in the user channel
well it is part of ngc that is historically supported. disabling it means breaking programs.
so my preference would be to fix it if it's possible
I'm not sure what second best is, leaving it a little wrong, or disabling it
you could make a small linear move to the compensated path
but that's ugly
gouging is unlikely to be the second best
I suppose that's true.
the resulting arc is not tangent, but does hit the correct point
(as you know)
you mean currently? yes
well if you use R. IJ doesn't work at all
right - it's the bogus radius check
it nicely detects the bogus arc parameters for us
assume the center of the cutter is distance x from the desired finished surface, and cutter diameter is d.
isn't the required R equal to x - d/2 ??
I think the problem definition is a start point, and a point on a tangent line, now find the circle arc
I don't think so, but that would make sense at first blush
if the center were kept constant, then the cutter would need to be moved D/2 "in" toward center for the resulting arc to have radius x-d/2
that is of course another option (similar to a suggestion from petev) - do a linear move toward the arc center of distance D/2, then do a smaller arc
well we know the center point lies on the perpendicular to the tangent point
not the resulting center point
oh right - tangent
I'm off for the night guys, I hope one of you can fix it
I'm sure you do ;)
good night :)
so now we need a point on that line that is equidistant from the start and end point
seems like the equation for that shouldn't be that hard
we need that line as well, of course (it isn't a given from the G-code)
which, the perpendicular or the tangent?
the tangent is parallel to the next line segment
and offset by the comp
yes - I haven't seen exactly how it's done though
and I can't remember any old geometry equations for circles ;)
I'm on wikipedia right now ;)
I was thinking the hard way, creating a line that passes through the tool center and is parallel to the next line segment
then, the center of the arc lies on the junction of that line and the perpendicular to the tangent point.
only if you change the tangent point to account for the changed radius
which isn't what we want to do :)
you don't know the next line segment
it may be a valid cheat to move toward the programmed center by D/2, then do an arc to the compensated endpoint (also moved in/out by D/2) with an adjusted radius
toward/away from the center, depending
you could still determine the tangent from the end of the un-comp arc I guess
yes that's how it has to work
[04:46:55] <petev> http://mathworld.wolfram.com/search/
one of them has to be what we want
the goal isn't to be tangent to the next segment anyway
you may have a corner to go around (which will cause the next segment to generate arc + segment)
but the arcs will have a common tangent where the first ends and second starts
a lead in arc to a corner would be stupid
but the point is that the next segmet is irrelevant and unknown
yes, but if the lead in arc ended on a corner, the trajectory would not be smooth
seems like a case that shouldn't be allowed
yes it would
a compensated corner is an arc, which works well
no, I'm saying the programmed lead in arc ends on a corner
so the initial tool path has a discontinuity
that's exactly the case we're ttrying to fix, and it "almost works" :)
there is no slope defined at that point
sure, but the comp path will be tangent arc-arc
that is stupid programming
there's a line parallel to the tangent of the original programmed arc
petev: the corner is irrelevant. all entry arcs are wrong.
if we fix the entry arc, even the program you think is stupid will have a smooth path
I would make it illegal to turn cutter comp on using an arc myself
cradek, I'm not sure that's true
good night again
[04:54:48] <SWPLinux> http://www.cncgear.com/Files/Screenshot-comptest.ngc%20-%20Axis.ngc
is a nice example of an almost correct arc entry
[04:55:07] <SWPLinux> http://www.cncgear.com/Files/Screenshot-comptest.ngc%20-%20Axis.png
is a nice example of an almost correct arc entry
that didnt' work either
one second while I learn to type
[04:55:51] <SWPLinux> http://www.cncgear.com/Files/Screenshot-comptest.ngc%20-%20AXIS.png
is a nice example of an almost correct arc entry
what was the original lead in move?
the program is two times around a square from (1,1) to (2,2) once with comp and once without
the arc below the cutter (cylinder)
a larger radius has smaller "overshoot"
line 7 in the code pane is the entry move
does the original lead in arc (no-comp) touch the corner of the quare
yes, it goes to (1,1)
G3 X1 Y1 R0.2
(from X1,2 Y0.8)
what's the cutter size?
0.125 (0.0625 radius)
do you want the g-code? I ran it on a stock sim-axis config
duh, it was right there in the status bar
oh - didn't notice :)
seems like a legal move
without comp, it would be fine
I mean it seems like it should work with comp
it's not like you start too close or anything
I also tried with an r0.5 arc and r1.0, and it gets less wrong as the arc radius increases
if the code does what the description says, then it's definitely wrong
they talk about pivoting an arc on the endpoint, which will clearly not result in the end being tangent to the original arc
err - the resulting tangent not parallel to the tangent of the original arc ...
yes, that is totally wrong if they don't change the radius of the arc
your pic does look like a pivoted arc
more degrees of same radius
they do, but they make it original +- tool radius
they change the radius, but not by the right amount
a circle of the original radius will gouge
a circle of (original - tool R) will (a) overshoot (like in the picture) or (b) not intersect the start point unless the center is moved
the radius is between the original and original +- R radius
and they don't do that
[05:13:02] <petev> http://mathworld.wolfram.com/CircleTangentLine.html
this is getting closer
irrelavant, but cool: http://mathworld.wolfram.com/MongesProblem.html
ok, I think I have the geometry for the solution
the center point is along the perpendicular to the tangent
and is located a distance from the tangent equal to the distance between the start and end points
I think ;-)
I'm not sure there's an equilateral triangle with the two endpoints plus a point on the perpendicular
it's two sides equal, not 3
whatever that is
I need to draw pics
but the point is probably the intersection of the perpendicular to the line connecting the start and end points
yes, perpendicular to midpoint
if the distance to the center is the same as the distance between points, then the triangle is equilateral ;)
I'm not describing it right
two sides of the triangle will be the same
ok - I think I see what you're saying though - the intersection of the perp. to the tangent and the perp. to the start->end line
and the perpendicular to the midpoint of the other will intersect the tangent at the center
that should be the center
I mean perp to the tangent
now we need equations
I guess the first step is to figure out the tangent line
and tangent point
I bet there is a simple equation for this when we figure it out
yeah. there may be shortcuts later
but we can't assume anything about the arc - it could be 359 degrees or 30 degrees
if this never worked, I wonder why it really needs fixing?
if fanuc and haas don't do it, why would EMC need to ?
because it's supposed to work
but it's been broken from day one
it's in the spec, and in some texts
I'm not positive of that
so it's not like something that did work doesn't now
it may be exactly that
we need a mathematicion ;-)
large parts of EMC were rewritten for emc2
I don't think this part, but I could be wrong
I'd call my mother but (a) she's likely asleep and (b) I don't really want to
I got a B.Sc in mathematical sciences... but I know nothing in reality.
plus she sucks at geometry
they hand out those like candy...
alpha, can you help?
what are we trying to figure out? [serious now]
we have two points
ask her a question about Gaussian integration or the calculus of variations, and she'll never shut up though
one on a tangent line
and we want the circle
[05:29:02] <SWPLinux> http://www.cncgear.com/Files/Screenshot-comptest.ngc%20-%20AXIS.png
is a nice example of an almost correct arc entry
see the overshoot in the arc below the cutter?
that shouldn't be there :)
give me a sec
times up ;-)
this is for cutter comp entry moves
do you have the slope of the line you are trying to join up with (be tangent to)?
in this case, I did a quarter circle that would have ended on the first line in a square
it's probably calculable - it's on a circle with known radius and centerpoint (and endpoint)
pete said earlier that you had two points, one on a tangent
[05:32:11] <a-l-p-h-a> http://126.96.36.199/a.png
but we want to be tangent to a point on a line parallel with that one, a distance R (cutter radius) away, along the perpendicular at the original endpoint
the top of the red is what we don't want?
do you actually have two known points, or is one of them just "somewhere on the arc"?
ok, so call initial position x0, y0
the original start point and the end point adjusted by the comp
a-l-p-h-a: yes, more or less
target position (for the tool center, after comp) x1, y1
and slope at that point dx1, dy1
but this as simple of quadrants...
you want one way to lead into another curve, without the overshoot.
see src/emc/rs274ngc/interp_arc.cc for much goodness (or not)
are all those things known?
more or less
and you are trying to figure the arc that gets you from x0y0 to x1y1 and leaves you heading along dx1dy1
this wine is sooo good.
slope needs to be determined from original arc
Sav<something> blanc... beautiful white wine.
we know start point, original endpoint, center, and tool radius
the bottle is in the fridge, so I can't remember.
me either - I hate wine
Magnotta Sauvignon Blanc 2005.
ok, so you have x0, y0 initially
you don't know x1y1 or dx1dy1
but can be determined
no, but we should be able to calculate them
figuring them out isnt that tough tho
uh, you know dx1dy1... as you know the secondary arc.
so thats the first step
yeah, we were assuming we could handle that part
but maybe not ;-)
given dx1 dy1, the perpendicular is easy
actually, we can get the perpendicular easier than dx1,dy1, since we have the centerpoint
swap dx and dy and maybe change a sign (I think, checking)
we essentially want to have one arc lead into the "primary" arc... without any overshoot. we just need to figure out where to set the lead in arc's centre point is + radius.
perp. line is along x1y1(original) -> center line
true, which is good
right - that's the bug
yes, we have two points on the perp to tangent
now, if you assume R (of your blend arc), you can write a formula for the center point of the blend arc
the centerpoint will be the point on the perpendicular line that's equidistant from x0y0 and x1y1
there is only one R that works
and R is that distance
and using that, write a formuls for the distance from the center of the blend arc (given that R) to the start point
"this is left as an exercise for the reader" ;)
we don't know the center or R
I'm talking algebra here, R is still an unknown variable
ok, multiple eqs
but you will have xc=f(r), and yc=f(r)
and then you can put those into an equation for the discance from xcyx to x0y0
set the result of that equation to R
and see if anything good comes out
hopefully it will be nothing worse than quadratics after you reduce things
but I'm too tired to do the alegbra - the 3am yesterday hit me hard
I'm sure there will be some trig as well, but let's see
close to 1 now, gotta hit the sack
well, 20 till 1 anyway
I had a thought while I was waiting for the dog to pee ;-)
you know x1, y1, and x0, y0
its trivial to calculate the point halfway between them
x1,y1 of the original arc, not the compensated arc
yeah, we talked about that
then take perp and find intersect
x1y1 are the compensated are
two lines, both known
we still couldn't handle the math ;-)
ok, then we don't have that until we fillde with the centerline (the perpendicular)
we have the perp to tangent
SWPLinux: I'm not talking about correcting the original target position to the new target position
that's part of the problem
if we have the end position
did you see the screenshot I had?
then we take the coord from start to end
bisect and find perp
I'm not sure the end position is perfectly correct at this point
then find the intersection of the two perp
in the current code
when I zoom in a lot, it looks like there's a bit of extra arc from the compensated corner
SWPadnos, the end point should be on the perp to tangent a distance of the tool comp
oh, you mean in the axis plot
yes, I know that - the current doesn't seem to get that right either
agreed, that one is messed up
got a formula for the compensated point (if you didn't already have that)
xc, yc = original arc center
rc = original arc radius
rt = tool radius
x0, y0 = current tool pos
x1, y1 = target position on original arc
x2, y2 = target position for tool center after correction
x2 = xc + (x1-xc)*(rt+rc)/(rc)
y2 = yc + (y1-yc)*(rt+rc)/(rc)
now the blend
* jmkasunich noodles some more
ok, with appropriate sign conversions for left/right comp, G2/G3, etc
yeah, I was assuming that the tool is outside the original arc
if inside, it becomes xc + (x1-xc)*(rc-rt)/(rc)
either way, once we have point 2, we forget about inside and outside and point 1
also dependent on G2/G3 though (the tests are there)
now we want to get from x0 to x2 and be tangent when we arrive
xm,ym = midpoint of line between x0y0 and x2y2, which is ((x0+x2)/2, (y0+y2)/2)
that's accomplished by forcing the centerpoint to be on the line from x1y1 to xcyc
or from x2y2 to xcyc - same line
yep, should be
steve_stallings is now known as steves_logging
the distance from x0, y0 to xc2, yc2 has to be equal to the distance from x2,y2 to xc2, yc2
xc2, yc2 being the center of the comp arc
seems easier to write the equations for those two
[06:09:45] <SWPLinux> http://mathworld.wolfram.com/Line-LineIntersection.html
ok, I think this is it
it does work
XC2 = (X0^2 + X2^2) / (2*X2 - 2*X0)
same for YC2
wanna show your work? (pastebin maybe)
haha, I wrote it with a pen
let me try and type into a file
digital camera ;)
[06:14:42] <SWPLinux> http://www.cncgear.com/Files/comp-arcs.png
the red circle is constructed with the found centerpoint and what would be x0y0
I suppose I could add some labels
the blue 90 degree arc isn't tangent to the red circle
or don't we care?
that would have been the original arc
so we don't care
ok, I'm off in left field
I thought we has an arc that we were trying to blend to, starting from some point not on that arc
IOW, rc is the arc that goes around the corner of the part - the one we are trying to merge with
you are saying rc is the pre-compensated merge move?
shit - I just wasted an hour of sleeping time solving the wrong problem
almost solving that is...
this crap really needs drawings - annotated ones
[06:20:32] <SWPLinux> http://www.cncgear.com/Files/comp-arc2.png
so the next move is completely irrelevant?
the next move after the entry? yes
that may be a bad thing, but that's the way the spec is (or the "Way It's Always Been" or something)
well it depends on the intial path not having slope discontinuites
but that's not a bad thing
right - the comp code will give appropriate errors if future moves are a problem
iow, the original programmer is responsible for making sure the next edge of the part (original toolpath) is tangent to the end of this move
this original move
so, is it solved, or is the pic just showing us what the problem is?
the pic should be rotated some arbitrary angle btw, other wise it seems simpler than it is
the pic shows the solution, actually (in graphical form, not mathematical)
I know thgat
good pic though
"solved" means reduced to formulas that a computer can execute efficiently
I think - I haven't tested for other than aligned quarter circles
well, defining the problem correctly is a good first step, and proving that the approach we're trying to generate equations for will actually provide the solution we want isa good thing as well
right, the drawing is very good
(plus this can be used in the docs :) )
I was just trying to decide if I should continue doing alegbra, or go do sleep
I'd go do sleep if I were you
goodnight yet again
then point names are even what we were using
ok - good night again :)
yeah - I did that on purpose
oh, good job
I'll edit them to be more human readable (like xc2,yc2)
and I got rid of the angle symbols
maybe draw the perp to tang line
that's the vertical line
so it's clear XC, YC and the other points are on the line
or do you want the name
yes, the vertical line
I wish I knew how to make a point some distance along a line (in kig)
hmmm - that diagram may not be right. I need to check it in the morning
well, after I get up in the morning that is
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-08.txt
[15:51:30] <cradek> http://timeguy.com/cradek-files/emc/arcentry.png
I think we were all making it too hard
cradek: that's always good news
center 1 -2499.5
the radius gets pretty big as you start near the target...
yuck, now I have to get the error checks right
and the R case...
one thing I noticed last night is that when I zoomed in very close, it appeared as though the endpoint wasn't correct either
I think the endpoint was right, but since it was not tangent, the next corner generated an extra arc
the endpoint calculation is very simple - move by tool_radius in the direction from end to center of the arc
I'm checking this in so you can see it
(R format not fixed yet)
ok - thanks
every geometry fix is about 5 lines of code, but it's always so hard to come up with the right 5 lines
holy crap, I just saw jmk's derivation
if his final equations work, they're probably a lot simpler and faster to evaluate
I'm insufficiently caffeinated to check his work :)
hmm, I quit reading halfway through, I'll go look again
the final formulas are just algebraics
no trig at all
oh - there are some sqrts in there, that's the limit of complexity I think
one thing that bothers me (artistically, not necessarily technically) is that there are separate functions for R and IJK arcs. Since either can be used to get the center point, this makes little sense for the meat of the calculations (with a suitable wrapper around each to provide the correct set of error returns)
I think arc_data_comp_* is supposed to be the part that needs to be separate - the rest is in _convert
I'm not sure I ever got through to _convert ;)
[16:45:53] <cradek> http://timeguy.com/cradek-files/emc/swp-tangent-entry.png
now your original program with tangent entry is beautiful
that's the linear entry?
I just changed back to G2 like you had it originally
are you going to tell him you fixed it? ;)
the arc is still the entry move
jmk - sender of a couple of follow-up emails ;)
[16:48:51] <cradek> http://timeguy.com/cradek-files/emc/interesting-consequence.png
I think this is right. We allow the initial direction to change, and it sure does
darnit, if I had known jmk was working hard on it, I would have waited
yeah - distributed development == duplicated effort sometimes
what's the diameter of tool 3 in those images?
I'm not sure - I tried lots of diameters
we should construct a file that tests all cases and stick it in the testsuite/ dir (or somewhere else)
all cases? sure :-)
heh - it should only be ~300000 lines ;)
I was trying to test something not axis-aligned but I haven't succeeded yet
harder to calculate the points by hand
hmmm. you can't actually make one file to test all cases, because the first time you emable compensation may be different from subsequent times (in the same file)
I don't think that's likely
me either, but it's a valid regression test concern
the first move per comp is the special one, not the first one in the program
in theory ;)
oh maybe I didn't understand your point
one point that came up briefly in the discussions with petev was regression tests
I mentioned that we have some for HAL, but not really for the interp or other parts of emc
(that I know of)
sai might be able to help
also, loading tort2.ngc and saying "it looks right in the AXIS preview" isn't a good tes
also, halsampler ans halstreamer can actually be used for shorter programs
well that's a decent test, just hard to automate
since motion should be expected to provide the same points
you can automate it, but the test vectors are humongous
maybe something's still not right with the new arc
you could build a regression test using sai and test vectors with expected output
when I read the description of how the entry move is calculated, I think it was a wrong method
I'd have to read it again to figure out why (again)
the long one above _comp_ijk (or whatever)
or maybe the R comp function. lemme check
yes it says the radius doesn't change
right - the method is wrong, I don't know if the code is doing what the description says though
the radius does change, but they talk about pivoting the resulting arc about the endopint and such - it just seemed incorrect
also, how many full arcs do you need? :)
err - full turns, that is
yeah that's a little silly
oh wow, look at the calc of gamma in convert_arc_comp1
it seems algebra may be a better way
yay that fixes it
ok - see you
hm, incremental jog "1mm" on the "A" axis doesn't make much sense...
[18:40:25] <cradek> http://timeguy.com/cradek-files/emc/onearc-entry-fixed.png
Htat looks right - cool
cradek, that looks good
did u get a chance to check lead out yet?
hope I got all the error cases right
I just sent an email on that
but haven't had time to test yet
petev: no I haven't looked at it
kramer's description of how it works doesn't seem correct
did you find it didn't work, or did you find that the ngc manual was missing info on it?
ok I should read your message again
a line lead-out should be obvious because it just goes to that coordinate
he indicates a lead out is a normal move executed from the current tool position
arc is going to be just as hairy as this one we just fixed
ie no special calcs to get back on path
I outlined 3 cases that I saw on lead out
read the email I just sent out
one minor point - arc lead-ins are basically required for pocketing
not single arc
SWPadnos: not really you can turn on comp with a line above the part
and are commonly generated by CAM software (though they generally do compensation anyway)
I just spoke to a friend with much experience on modern comercial controls
SWPadnos: (this is nicer)
true - there are other techniques
not allow cutter comp to be turned on with an arc move
right - that was my point - there is a use for them (even if "required" is too strong a word)
so - EMC2 will be better than the other controls - so what's new? ;)
petev: interesting - it seems nice to have the ability
yes, but not really necessary
I looked at some CAM packs too
comp isn't really necessary either
and all allowed linear lead in
desirable and necessary are matters of opinion
well that's much more desirable than having to make a linear move
there are also two main ways comp is used
when manual programming the comp is usually the full radius/diameter
I have a friend who considers home switches "nice, but not necessary"
SWPadnos: hey that's me
with cam, it's usually the diff between the actuall cutter and the program
ook - two friends ;)
which is usually a small number and can be negative
petev: emc supports that too
jsut saying, these are corner cases that need to work
please test them
and the single arc lead in is hariy as is
petev>"not allow cutter comp to be turned on with an arc move" O
I'd have to violently disagree with that.
Had a long arg with roltek this morning about this.
rayh: it has always been allowed, but it was wrong
rayh, a careful read of kramers doc indicates a single arc lead in was never supported
cradek, read kramer again
petev: no, I agree with you
it was not supported like we are testing
I've been doing an arc lead in with emc for many more years than any other person around here.
petev: "allowed ... in emc"
this may be an enhancement, but who cares about that if it works?
And that is with the emc.
rayh, you can use an arc lead in, but the lead in has to be two moves according to kramer
for the "simple method" it must be a linear move
that's what kramer says
that's my reading too
and that would work with the way the code was
* rayh goes looking for the doc I wrote using variables for a single arc lead in.
now the one-arc case, which has always been accepted by emc, is right too
it may also be a bugfix for something that was introduced in the massive changes from EMC (old, PD) to EMC2 (via many BDIs, etc)
rayh, the problem with single arc is suttle and may not be noticed with large radius
I wish you guys hadn't thrown out that doc.
was it in the dropbox?
Hell I was milling a 1.25 circle with a 1 inch cutter.
[18:51:50] <petev> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_38a.html
and a .25 circle with a .125 cutter.
gonna take a while to download the old docs directory and extract the stuff.
[18:56:32] <cradek> http://timeguy.com/cradek-files/emc/comp311-onearc.png
this is the example from kramer with the (now-unnecessary) initial lines removed
this is the single arc entry that was wrong before
(but it was accepted, as long as you used R format)
well emc had no way to know which was lead in vs actual path
so it would have to accept
The arc was the lead in.
how does EMC know that?
the doc calls for 2 lead in moves
I am pleased that we seem to think it works properly now.
so it can't flag an error
but the new lead in mode is elegant
now we need to check lead out
petev: I'm anxious to hear the results of your tests - I agree some of those might be wrong
why is lead out a problem.
according to kramers description, it does not sound like whats wanted
I have not tested that actual behavior yet
rayh: just that an arc as the first move after turning off comp might be wrong
what is it we want?
and relative coordinate mode a line may be wrong too
g40 ends diameter comp
the cutter should get back on the non-comp path
arc away and issue g40
regardless of abs or rel and lead out type if arcs are to be supported
Or are we building an entirely different way to start up tool diameter comp
rayh, but you have to be able to turn it on/of and go from left to right
you can't lose the path in the process
from left to right?
G41 vs G42
ngc doesn't allow you to switch sides without coming out of comp
But that is your decision as a machinist.
but the path should remain correct
I don't know what you mean by remain correct.
the comp should always be correct from the original path
g40 places current tool tip at current location.
I don't understand what you mean by original path.
the programmed path
I write the path i need.
yes, it's not clear G40 will get back onto the programmed path under all modes
You mean you are using tool comp as a +- from some pre programmed tool comp
well that could be if cam were used
but not relavent to this
When I turn off diameter comp my path has ended with comp.
the next move goes from the location of the tool when I turned it off.
and where should the cutter center go on the next move?
I don't see how there was some preconcieved path that extended beyond that.
why, the programmed path continues
It should go exactly where you tell it to go.
and turning comp off should get the cutter back on it
ok, example case
cutter comp is on
in abs coord mode
and arc lead out is issued
that arc from the comp off pos will not end in the correct place
what does EMC do?
if you just issued g40 there is no arc lead out. comp is done.
the next move is an arc
It is not.
why not? let's say that's what's in the program
hold up a second guys - you're talking past each other
Unless you write an arc for the next move
And that arc is without comp.
may be a transition from one contour to another
but the arc should end where it's supposed to
that arc will be a transition from a compensated path to a non-compensated path, so it needs similar scrutiny as an entry move does
the lead-in / tail-out moves from many CAM programs are arcs (though they're probably doing compensated paths already), especially when cutting a pocket
well, at least a couple of CAM programs - I haven't used many :)
the progs I looked at could generate linear to support comp
it was an option
when using cam, the comp is usually the diff between programmed cutter size and actual
and can be negative for sharpened cutters
linear isn't useful on a pocket though, because there will always be gouging (I think)
no, linear works fine
you would have to make the entry move on a non-cutting plane
then plunge and cut
(possibly in the same move)
on my BP I would get on the comp path when Z wasn't even near the word
on a G0 move
right - then descend and cut
I never even considered using an arc lean in
G17 G41 D2 G3 F3 X[#1002/2] Y0 R[#1002/4] (offset arc to start)
is the line of code I tested and used in the using variable chapter of the old users manual.
#1002 is the current tool diameter?
* rayh looks
Is there a handy place I can post the pdf?
if it's under 200k, then linuxcnc.org is good
upload with the wiki
what's the name, it may be there already
It was a chapter in emc's user manual.
I'll do some testing with BDI and emc2 and see what happens with this sort of code.
wow that took long enough.
There is a difference in the way that bdi and emc2 handle diameter offsets with an arc move.
booting BDI? ;)
goes something like this,
dig through stack of cd's
or hard disks ... :)
what's the difference(s) in cutter comp?
The radius of the comp arc must be the radius of a zero sized tool + 1/4 cutter diameter.
In the older systems.
that sounds like a pain in the patootie
That's why I used variables back then.
With emc2, the interpreter doesn't complain using that same formula.
but the path is totally wierd.
A full arc to the rxx+ is realized.
odd that it doesn't complain - a radius of D/4 should cause gouging (radius too small error)
* alex_joni is back home
followed by a small reverse arc back to the uncompensated radius.
Then around the circle and a proper (as I defined it) arc out
is that emc2 as of a couple of hours ago, or emc2 as of early this morning?
so no the changes are not in there.
ok - update and see if it's more as you expect
chris found a typo (among other things), and it seems to do what we want now
though I'd still expect a "radius too small" error for an R=D/4 arc
I still find it fascinating that comp doesn't work (yesterday) but that the interpreter doesn't complain and that somewhere in the system an arc move is invented to adjust wrong locations.
well, the interesting thing with the tests I did yesterday was that the endpoint may not have been quite right, and the arc around the first corner was more than 90 degrees
the entry was gouging, so there was a little bit of extra corner to go around
yep. for the (1,1)-(2,2) box, I did an arc entry from (1.5,0.5) with G3 X1 Y1 R0.5
that does a quarter arc (ish) of entry, then goes around the corner of the box with an arc (as comp should), then continued on
Oh an outside cut.
I've only been testing cutting to the inside of a circular pocket.
I haven't done any testing of compensated arcs, just arc entries to compensated lines
(or linear entries to compensated lines)
ok - it'll be good to see if your cases are fixed
The linear entries to the outside are fairly easy.
As you noticed I gave myself lots of slop.
I haven't noticed a thing :)
It would even run with a 1.0000 endmill
what is shcom.cc
is this stuff in the doc you uploaded to the wiki?
guess I should go look, 'eh.
hmm. there haven't been any changes to that recently, I think
it's part of the emcrsh stuff, I believe
I didn't upload. It requires revisions.
The current stuff makes a pinched arc into the inside circle that is not tangent with a zero sized tool. No interpreter complaint
With a tool it complains concave corner with cutter radius.
can you pastebin the gcode?
Got an interesting message "Bug in tool radius comp."
yeah I checked a new "impossible" case
haha, ray is known for getting those :)
[23:00:47] <rayh> http://www.pastebin.ca/386867
honest doctor I haven't a clue how I got that bug!
it's exactly a semicircle - I bet there's a problem with that
probably something to do with the math.
I was using a 0.100 tool
it's PI, I tell you!
actually, there are some M_PI_2l consts in there - there could be something weird with that
when I convert to IJ format on line 4, it works
so it's a bug in R handling
and as we all predicted, the exit arc is pretty bogus
not so at all. it is exactly what I asked it to do.
half a circle back to the starting point.
why do you say bogus?
it's not tangent
note the small cusp at the exit
also, it goes much further away from the programmed path than a tool radius
I have not tried running using ij
it should start a tool radius away and smoothly transition to on-path
like the entry arc (converted to IJ to avoid the bug)
? did you add an uncompensated circle to check that?
yes I ran it with D1 changed to D0
hay ray whats the t1 for
roltek: it's a typo, but it doesn't matter
good night all
[23:09:01] <cradek> http://timeguy.com/cradek-files/emc/bad-exit.png
does that change when you fix the T1 typo?
(shouldn't - just throwing out wild ideas)
no there's a y1 above it
right - it's the tool prep that I though could have a (bug) effect
SWPadnos: I'm trying to understand the difference between arc_data_r and arc_data_comp_r
there's a semicircle special case in arc_data_r
sorry - I'm being co-opted into helping prepare dinner :)
fixed it, I think
Running test: ./mill-g90g91g92
Running test: ./mill-line-arc-entry
Runtest: 2 tests run, 2 successful, 0 failed + 0 expected
and this makes me happy
having the tests or passing them? ;)
rayh: please cvs up and retest - I think I fixed the "bug in comp" case you found
and thanks for being an excellent tester
was there another wrong thing I should look at?
what program outputs "Runtest: 2 tests run, 2 successful, 0 failed + 0 expected" come from?
an incorrect concave corner warning?
mshaver: the new regression tests that use the sai
* rayh reads back.
Hi roltek. I haven't a clue.
"the new regression tests that use the sai"?
did you fix the sai bug reading the tool table?
err which bug?
must have been an m6 in an earlier version.
nope a typo should be y1 although not needed.
it wasn't handling the new tool table format with extra columns for lathe stuff
mshaver: the regression test infrastructure just checks the current output against the expected (hand checked) output - and the sai works nicely to test interp output
mshaver: ah, no that hasn't been fixed, just using a mill format table so far
mshaver: until today there were just hal tests, but now there are a few interp tests (mostly exercising cutter comp)
if anyone has some gcode that exercises a lot of comp corner cases (haha, pun intended) let's make another test
also, saicannon.cc has something commented out in GET_EXTERNAL_PARAMETER_FILE_NAME (I think) because of that var that was being stepped on in driver.cc
jepler uncommented something about the var file
I saw a checkin for that
you're probably using the default sim.var
ok, i'll fix the tool table thing, hopefully tonight
Hey the zero diameter tool with comp looks lots better.
rayh: zero diameter?
wow. That is great.
mshaver: cool, thank you
I run zero diameter to define the part size first
then a tool so I see how the comp is behaving.
Are the regression tests in emc2/tests? cvs upping now...
The lead away is different from BDI still but lead in is right on.
rayh: interesting - I would expect the exit move to be the same
I'd get the right lead out by subtracting some cousin of tool diameter from the r.
oh ok, I can see how that would help massage it into working
with IJ format, it will probably actually error
(but I haven't tried that yet)
make up my mind.
don't sweat that exit until someone "declares" it fixed
whoa! I never knew you could do that EOF thing to drive an interactive program from a script!
mshaver: nasty isn't it!? :-)
That opens up a lot of possibilities...
mshaver: ideally one of these days sai would have a bunch of options via getopt() of the commandline
mshaver: to run the tests, first ". scripts/emc-environment" and then "runtests" or "runtests some/test/dir"
I was going to do that, normally I write things as filters, but that menu ui was already in driver.cc
it's from Kramer originally
I think I'll adapt the include graph stuff to work in this tests thing you've got going on here
I'm still of the opinion that when you shut of diameter comp you get no change to the geometry of the subsequent move.
rayh: try the first move after turning it off being an arc in IJ format
I'll try to make a picture of what I saw
oh wait, I did: http://timeguy.com/cradek-files/emc/bad-exit.png
this is from straight above
"current position" must change instantly when comp is turned off?
the exit arc (inner top) should mirror the entrance (inner bottom)
mshaver: no, the next move (if it's an arc) has to adjust its center and radius, like the entry move does now