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