Back
[00:06:04] <jmkasunich> hi guys
[00:08:05] <jepler> lhi jmkasunich
[00:08:28] <jepler> s/l//
[00:08:32] <jmkasunich> just the guy I wanted to talk to
[00:08:36] <jepler> hi
[00:08:46] <jmkasunich> yesterday you said make would deal with changes to configure or configure.in
[00:08:50] <jmkasunich> what about changes to config.h?
[00:08:56] <jepler> yes, it should
[00:09:10] <jmkasunich> changes to the makefile?
[00:09:28] <jepler> usually
[00:09:39] <jmkasunich> (I'm just tossing things out there - I want to make sure that skipping configure for an incremental build is safe)
[00:10:16] <jepler> make only knows about things in this invocation, so if it knows that target 't' has prerequisites 'p' and 'q' on this run, all it does is compare the timestamp of 't' to 'p' and 'q'
[00:10:41] <jmkasunich> skipping configure should really speed it up - it won't just skip the config step, it will skip building a bunch of stuff that depends on things that configure touches
[00:10:52] <jepler> so if the change to the makefile changed the rule to make t by adding the prerequisite q, then it will be caught
[00:11:02] <jepler> if it removed a prerequisite 'r' it won't be
[00:11:17] <jepler> if it didn't change a prerequisite, but just changed the rule to make 't', it won't be
[00:11:35] <SWPadnos> in a sense, everything should depend on the makefile
[00:12:54] <jepler> yes, but in practice you can't get GNU make to work that way
[00:13:34] <SWPadnos> I was just thinking of ways to try, but I'm sure others who know a lot more about gnu make have thought about it as well
[00:14:07] <jmkasunich> * jmkasunich ponders doing a find on the tree, searching for files that match Makefile or Submakefile, and are newer than "last_complete"
[00:14:19] <jepler> systems that have been designed more recently than 'make' actually store information about the rules and prerequisites used on earlier runs to fix this very problem
[00:15:23] <jepler> jmkasunich: and in that case doing a full build?
[00:15:37] <SWPadnos> I suppose you could have a rule that checks for a copy of makefile, and 1) creates it if not found (and does a full rebuild) or 2) does a full rebuild if the copy and the makefile don't match
[00:15:43] <jmkasunich> jepler: yes
[00:16:02] <jmkasunich> find -name *akefile -newer last_complete
[00:16:30] <SWPadnos> find -name "{Sub,M}akefile" -newer last_complete
[00:16:45] <jepler> jmkasunich: I think that will catch all these cases you're concerned about, yet not be a common enough event to remove the advantages of usually building incrementally
[00:16:47] <SWPadnos> oops
[00:16:50] <SWPadnos> find -name "{Subm,M}akefile" -newer last_complete
[00:16:59] <jepler> -name "*akefile*" to get Makefile.inc.in too
[00:17:20] <jmkasunich> jepler: thats the goal - a few unneccessary complete builds isn't a major issue
[00:17:22] <SWPadnos> Makefile.inc.in should already trigger a lot of stuff, shouldn't it?
[00:17:33] <jepler> SWPadnos: a lot, but not everything
[00:17:41] <jmkasunich> making someone wait 12+ hours to see if their makefile change fixes a broken build is
[00:18:11] <SWPadnos> I'd think that any *.in would trigger a reconfigure / make cycle
[00:18:41] <SWPadnos> and for the farm, a reconfigure / make clean / make (or more properly, make clean / reconfigure / make)
[00:19:02] <jmkasunich> the farm does config, then make clean, then make
[00:19:20] <SWPadnos> hmm - that's an interesting but probably unimportant point. technically you should make clean before the update
[00:19:28] <jmkasunich> since the make clean may be modified by configure
[00:19:40] <SWPadnos> right, but the files will be from the old make
[00:19:50] <SWPadnos> so if a destination dir changes, the old files will be left
[00:19:55] <jmkasunich> you are right - it should be "configure, make, make clean
[00:20:02] <jmkasunich> but that would force every build to be complete
[00:20:14] <SWPadnos> yep
[00:20:31] <jmkasunich> pick yer poision
[00:20:43] <jmkasunich> I can't spell poison
[00:20:49] <SWPadnos> how about sequencing the VMs with some VMWare control script? ;)
[00:20:53] <SWPadnos> that's a good thing
[00:20:58] <jmkasunich> you volunteering?
[00:21:05] <jepler> you could install ccache and see if that gives you enough improvement to make incremental builds moot
[00:21:13] <SWPadnos> err - well, not really
[00:21:23] <jmkasunich> jepler: what does ccache do?
[00:21:50] <SWPadnos> * SWPadnos is doing accounting in the hope of passing off corporate tax stuff to the CPA before leaving for Florida this Friday
[00:22:08] <jepler> jmkasunich: after the preprocess step, it compares the preprocessed source code plus the compiler options to a cache, and if there's a match it uses the object file from the earlier compile as the result, instead of invoking the next stage of the compiler
[00:22:26] <jepler> "ccache is a compiler cache. It acts as a caching pre-processor to C/C++ compilers, using the -E compiler switch and a hash to detect when a compilation can be satisfied from cache. This often results in a 5 to 10 times speedup in common compilations." --
http://ccache.samba.org/
[00:22:53] <jmkasunich> how is this differnet from make?
[00:23:00] <jepler> "Why bother with a compiler cache? If you ever run "make clean; make" then you can probably benefit from ccache. It is very common for developers to do a clean build of a project for a whole host of reasons, and this throws away all the information from your previous compiles."
[00:23:22] <jmkasunich> ah
[00:23:41] <jmkasunich> all the bennys of make clean with half the pain (so to speak)
[00:23:43] <jepler> ccache is easy to set up: install the package, then put /usr/lib/ccache at the start of PATH, before /usr/bin
[00:24:07] <jmkasunich> it only speeds up one part of the process tho
[00:24:22] <jepler> yes, it doesn't speed up configure (or not by much), and it doesn't speed up "depends"
[00:24:23] <jmkasunich> running comp on all the .comp files, for example, would still happen
[00:24:26] <jepler> yes
[00:26:31] <jepler> I have ccache installed on my systems, I'm working on getting you an estimate of the speedup it provides on emc2
[00:26:55] <jepler> I believe it was about a 50% speed-up excluding the ./configure step
[00:27:14] <jepler> not the 5x they say on the ccache page
[00:27:24] <jepler> (with C++ programs that 5x figure may be very accurate)
[00:27:47] <jmkasunich> SWPadnos is probably right about the VM sequencing being the way to go
[00:27:59] <jmkasunich> a full build on one VM is something like 4 minutes
[00:28:13] <jmkasunich> a full build on all at the same time can run over an hour
[00:28:19] <jmkasunich> I think I had one that ran 2 hours
[00:28:22] <jepler> yuck
[00:28:45] <jmkasunich> it didn't help that I was running a 20uS realtime thread at the time
[00:28:48] <SWPadnos> though it's not ideal, you could also stop the sequence after the first failure
[00:29:07] <jmkasunich> actually, that would be bad
[00:29:14] <jmkasunich> if one fails, its usefull to know if the others work
[00:29:20] <SWPadnos> yeah - saves power but doesn't give as much diagnostic info
[00:30:05] <jmkasunich> I assume that responsible devs test on their own box before committing, so the goal here is to test a number of different systems looking for differnet results
[00:30:13] <jepler> with ccache: 1:19 real, 0:58 user, 0:18 sys
[00:32:35] <jepler> without ccache: 1:58 real, 1:36 user, 0:19 sys
[00:32:36] <jepler> not a huge savings
[00:32:54] <jmkasunich> 2007-02-19 03:25:12 build: emc2head : start complete build
[00:32:54] <jmkasunich> 2007-02-19 04:23:56 build: emc2head : succeeded
[00:32:59] <jmkasunich> that is on the host
[00:33:11] <jepler> configure: 5 seconds
[00:33:44] <jepler> dinnertime here
[00:33:50] <jepler> jmkasunich: good luck picking your poison
[00:34:15] <jmkasunich> I might just pick "no changes"
[00:34:39] <jmkasunich> if I do anything in the near term, it will be the "find -newer last_complete" thing
[00:35:01] <jmkasunich> although the incrementals seem to be helping quite a bit
[00:35:17] <jmkasunich> two-three mins per build
[00:35:33] <SWPadnos> another option is to always do incrementals, but do a full if there's an error
[00:35:45] <jmkasunich> they're fast enough that one has a chance to get finished or at least make good progress before another one bogs things down
[00:35:51] <jmkasunich> SWPadnos: thought about that - not pretty though
[00:35:53] <SWPadnos> not that all "incrementals when they should have been fulls" would create a failure
[00:36:05] <jmkasunich> somebody changes a single file, breaks it
[00:36:24] <jmkasunich> they see the error message, commit a fix, and wait and wait and wait for the result
[00:36:30] <SWPadnos> yeah
[00:36:44] <SWPadnos> I guess I'd still do the "wait 5 minutes" thing
[00:36:56] <SWPadnos> (ie, never build twice in less than X time)
[00:37:26] <SWPadnos> hmm - actually, that may be good, and reasonably easy to write an algorithm for
[00:37:32] <jmkasunich> ?
[00:37:43] <SWPadnos> an update happens, so a partial make is done
[00:38:21] <SWPadnos> if that results in an error, then at the next cvs check (every 5 minutes, right?), if there have been no commits, then do a full build
[00:38:28] <SWPadnos> if there have been commits, then do another partial
[00:38:39] <jmkasunich> nah, too many full builds
[00:38:41] <SWPadnos> so you only get partial builds until activity "stops"
[00:38:58] <SWPadnos> but if a partial succeeds, then there would be no full ..
[00:39:12] <jmkasunich> oh, I misunderstood
[00:39:15] <SWPadnos> I think that happened with Eric Johnsons commits - they were across at least two build cycles
[00:39:29] <jmkasunich> probably
[00:39:30] <SWPadnos> the first failed because it didn't have all the needed changes
[00:40:09] <SWPadnos> so, each time CVS is checked (again, I'm assuming this is every 5 or 10 minutes):
[00:40:10] <jmkasunich> a way to beat that is "when you see a commit, wait 5 mins, check again"
[00:40:19] <jmkasunich> when 5 mins goes by without a commit, do the build
[00:40:26] <jmkasunich> (still do incremental by default)
[00:40:36] <SWPadnos> 1) if no changes *and* the last build was a filaed partial, do a full
[00:41:16] <SWPadnos> well, that may wait for a lot of stacked changes, which may make it hard to tell what broke things (for instance, in the run-up to a release, when 6 people are banging away simultaneously :) )
[00:41:22] <jmkasunich> if no changes in the last 5? or no changes since the checkout that resulted in the failed partial?
[00:41:30] <SWPadnos> 2) if no changes and the last build was a full, then do nothing
[00:41:40] <SWPadnos> 3) if changes and the last was a partial, then do a partial
[00:42:17] <SWPadnos> those should be identical, since the partial would have been done earlier if any changes had happened before this "period"
[00:42:51] <SWPadnos> basically that scheme does partial builds until there have been no changes for a while, and the partial build failed
[00:42:55] <jmkasunich> the way I see it, there are only three reasons to do a full build
[00:43:17] <SWPadnos> err -nevermind that - I worded it wrong
[00:43:23] <jmkasunich> 1) just because - every once in a while we need to make sure make clean;make works - I do it if its been more than 12 hours
[00:43:42] <jmkasunich> 2) because a partial missed something and as a result failed - do the full to recover
[00:44:02] <jmkasunich> 3) because configure, makefiles, or some other part of the build system itself was changed
[00:44:08] <jmkasunich> 2 is rare
[00:44:15] <jmkasunich> but it seems to be the case you are addressing
[00:44:26] <SWPadnos> that could be :)
[00:45:11] <jmkasunich> I'm tempted to deal with 1 by forcing a full build at 7am or something
[00:45:37] <jmkasunich> a time when I'm not using my computer
[00:45:53] <SWPadnos> I'd do that "if there have been changes in the last 12 hours", unless you don't care about the machine taking a while to do the builds at 7 AM :)
[00:45:59] <SWPadnos> err - 24 hours
[00:46:08] <jmkasunich> 3 is where the makefile dependencies on configure.in, plus the "find -newer" come into play
[00:47:31] <jmkasunich> I'd probably make the 7am rule be: if the last entry in the history file is anything but "complete build succeded", do a complete build"
[00:47:47] <SWPadnos> yeah - that seems pretty easy
[00:48:09] <jmkasunich> so if there has been no activity at all, there would be no build
[00:48:31] <jmkasunich> that would replace the 12 hour rule, and greately speed up the first commit of the day
[00:48:45] <SWPadnos> actually, it would do full builds for as long as there was an error
[00:48:52] <jmkasunich> true
[00:49:06] <jmkasunich> but if we go for days with errors, maybe we need the farm nagging us on the commit list
[00:49:06] <SWPadnos> not that there have been many build failures that have lasted 24 hours
[00:49:12] <SWPadnos> yep
[00:49:12] <jmkasunich> (it would only be once a day)
[00:50:46] <jmkasunich> I'm looking at the logs for the biggest gaps in activity
[00:50:55] <jmkasunich> thats the ideal time to do a full build
[00:51:13] <SWPadnos> take your average bedtime and add an hour to be safe ;)
[00:51:27] <jmkasunich> yeah
[00:51:36] <jmkasunich> that would be 3am or so
[00:51:46] <SWPadnos> sounds sane
[00:51:47] <jmkasunich> 6am is safer for me, but alex might be up by then
[00:52:04] <SWPadnos> He'd better be - 3AM is noon for him
[00:52:37] <jmkasunich> I dunno how much emc work he does in the morning tho
[00:52:47] <SWPadnos> heh
[00:54:52] <jmkasunich> looks like 0800 utc is the best time
[00:55:11] <jmkasunich> I took the history_log file (date/time/result), used cut to grab just the time, and sorted
[00:55:22] <jmkasunich> only one entry in that hour
[00:55:31] <SWPadnos> cool
[00:56:17] <jmkasunich> heh, more cut and a bit of uniq, and I have a histogram of sorts
[00:59:00] <jmkasunich> 0800-1100 UTC totaled 6 builds
[00:59:08] <jmkasunich> 2000UTC had 31
[00:59:59] <jmkasunich> 0800 utc is 3am here I think, 1100 is 6am
[01:00:37] <SWPadnos> yep
[01:01:56] <jmkasunich> so, the things I'd like to do (when I get my round tuit) are: drop the configure from incremental builds, force full build if *akefile is newer than last_complete, and force a full build at 4am if the last entry in history is other then complete success
[01:02:25] <jmkasunich> and drop the "full build if its been more than 12 hours"
[01:03:47] <SWPadnos> sounds good to me
[01:06:14] <jmkasunich> hey, you done anything with the 5i20?
[01:06:50] <SWPadnos> nope
[01:06:53] <SWPadnos> :(
[01:07:20] <SWPadnos> I haven't even gotten around to installing ISE on any of my machines
[01:07:28] <jmkasunich> I have ise installed
[01:07:48] <jmkasunich> have a drive and motor hooked to 5i20 pins, software step/dir so far
[01:08:04] <jmkasunich> been exchanging a few mails the last few days with pete wallace about stepgen
[01:08:19] <jmkasunich> I wish I could magically get up the VHDL learning curve
[01:08:28] <SWPadnos> I still haven't decided on how I'm going to run Altium - in VMWare or on a real Windows install
[01:08:33] <SWPadnos> yeah - that's a tough one
[01:08:35] <jmkasunich> I guess that is just gonna take some old fashioned work tho
[01:08:47] <SWPadnos> I'm taking a couple of classes (one in VHDL, the other in Verilog) at ESC this year
[01:09:03] <SWPadnos> half-day affairs, so they may actually have some meat
[01:09:24] <jmkasunich> I need a good book, and I need to just dive in and start trying to do something
[01:09:44] <SWPadnos> I think it's mostly learning the basic syntax (not too hard from the looks of it), and the libraries (harder, since that's a memorization thing)
[01:09:59] <SWPadnos> I searched a little for books on the subject. they're expensive and not often in stores
[01:10:06] <jmkasunich> right
[01:10:17] <SWPadnos> available online, but that kind of thing is much better browsed first
[01:10:25] <jmkasunich> and its not the kind of book you wnat to buy without leafing thru first
[01:10:25] <SWPadnos> I should check the university library / bookstore
[01:10:32] <SWPadnos> yes
[01:11:16] <jmkasunich> thats a good idea... never though about college bookstore
[01:11:53] <SWPadnos> of course, it's expesnive as hell there, but you could always get the names there and then check amazon or BN
[01:11:58] <jmkasunich> true
[01:12:19] <jmkasunich> heh, the CWRU bookstore accepts BN giftcards (which I happen to have)
[01:12:20] <SWPadnos> then again, you could ask Pete W if he has any pointers :)
[01:12:30] <SWPadnos> (suggested boks)
[01:12:32] <SWPadnos> books
[01:13:10] <jepler> I'm a "learn by doing" guy, so I learned verilog without a book .. just a few online tutorials
[01:13:38] <SWPadnos> the syntax looks pretty straightforward
[01:13:46] <SWPadnos> it's the "standard libraries" that get you
[01:13:54] <SWPadnos> or me anyway
[01:14:15] <jepler> yeah, I am sure there's a lot of library stuff that I was completely unaware of
[01:14:25] <jepler> might have given me better or shorter code if I had
[01:14:31] <jmkasunich> this is incredibly lame - a bookstore website without a search function
[01:14:36] <jepler> though the pluto firmware is quite small in LOC
[01:14:41] <SWPadnos> and little things like "what is the full set of possible pin type specifications" or similar
[01:14:48] <jepler> <200 lines
[01:15:10] <jepler> (verilog seems to be much less verbose than vhdl)
[01:16:40] <SWPadnos> http://blogs.warwick.ac.uk/images/steverumsby/2006/01/30/dilbert20060121046729.jpg
[01:17:41] <jmkasunich> argh - thunderbird
[01:22:55] <jmkasunich> bastards - this is email - there should be no such fscking thing as "text style"
[01:23:09] <SWPadnos> heh
[01:23:23] <SWPadnos> you can drag and drop images as well
[01:23:50] <jmkasunich> on the work box I managed to tell it to stop doing that crap
[01:24:02] <jmkasunich> but I can't figure out how to do that here
[01:24:13] <jmkasunich> the compose window keeps doing evil shit
[01:24:18] <SWPadnos> I think there's an option for composer to default to a plain text editor
[01:24:34] <jmkasunich> I certainly hope so - trick is finding it
[01:25:05] <jmkasunich> ah, google is my friend
[01:25:11] <jmkasunich> http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Using_Plain_Text
[01:25:51] <SWPadnos> heh
[01:28:41] <jmkasunich> you should _not_ have to google the web and then do 12 things inorder to turn the default install into a real mail agent
[01:28:59] <jmkasunich> * jmkasunich is in curmudgen mode
[01:29:05] <SWPadnos> it is a real mail agent. you can tell it to send plaintext mail by default
[01:29:14] <SWPadnos> and it's pretty easy in Mozilla
[01:29:24] <SWPadnos> (not sure if they hid it better for TBird though)
[01:29:44] <jmkasunich> that webpage has a number of steps that you have to go thru to make it use text
[01:30:07] <jmkasunich> _all_ the defaults are set to "AOL mode"
[01:30:49] <jmkasunich> * jmkasunich stops griping and replies to pete W
[02:41:26] <cradek> what do you guys think about me backporting the angled in/out for g76? my thinking is that it's not going to break anything else
[02:43:33] <jmkasunich> seems reasonable to me
[02:54:51] <cradek> yuck, it's changes in several files - I forgot
[02:54:59] <cradek> maybe I'll finish it later
[02:55:50] <jmkasunich> ;-)
[02:56:21] <jmkasunich> I'm trying to wikify my experiences with software stepping lately
[03:08:59] <cradek> that's cool
[03:13:21] <cradek> it builds - it must be right
[03:18:10] <jmkasunich> of course
[03:18:28] <cradek> crap, I don't think it's right
[03:18:45] <cradek> (in either tree)
[03:19:17] <jmkasunich> well, I guess its good that you noticed now
[03:26:21] <cradek> http://timeguy.com/cradek-files/emc/g76taper.png
[03:27:05] <jmkasunich> thats good, right?
[03:27:13] <cradek> looks innocent enough, doesn't it
[03:27:16] <cradek> I think it's wrong
[03:27:40] <jmkasunich> 29 degree infeed is backwards?
[03:27:51] <jmkasunich> no, never mind
[03:28:03] <cradek> the sync happens out on the safe line, then it goes in/over/across/out
[03:28:36] <jmkasunich> the in move is gonna take variable time
[03:28:38] <cradek> the problem (or I think it's a problem) is the later moves are longer
[03:28:44] <cradek> right
[03:29:03] <cradek> I think those "in" have to be the same length
[03:29:25] <cradek> you said "time" but you really mean spindle rotation
[03:29:29] <jmkasunich> the straight in ones? they don't have to be the same length, they should be unsynced
[03:29:50] <jmkasunich> stop and sync at the first bend
[03:29:51] <cradek> no, they are currently synced
[03:30:02] <jmkasunich> well thats wrong ;-)
[03:30:03] <cradek> no, because it's inside the material
[03:30:10] <cradek> (for the later moves)
[03:30:28] <jmkasunich> oh
[03:30:43] <jmkasunich> then they need split into two pieces
[03:30:49] <jmkasunich> 2nd piece always same length
[03:31:14] <cradek> or move "back" for all but the last move
[03:31:25] <jmkasunich> back?
[03:31:36] <cradek> yeah as I see it there are two options:
[03:31:48] <jmkasunich> you mean start the entire path farther out?
[03:31:53] <cradek> move back a variable amount (outside the drive/safe line) and sync there
[03:32:06] <cradek> or move forward a variable amount and sync there
[03:32:27] <jmkasunich> I guess the former is safer
[03:32:48] <jmkasunich> question: why is there a straight in portion at all
[03:32:49] <cradek> yeah you should be able to have the drive line barely outside the material and have no ill consequences
[03:34:01] <jmkasunich> the final pass should be able to do its rapid back on the drive line, just outside the material, then sync and immediately begin angling in
[03:34:09] <jmkasunich> earlier passes could move the entire pattern out
[03:34:36] <jmkasunich> in fact, the pass-to-pass advance on X can be done during the rapid back
[03:34:37] <cradek> think about cutting up next to something
[03:35:03] <cradek> you'd have to have the drive line perilously close in X in order to get near something in Z
[03:35:17] <jmkasunich> because the angled part would be short?
[03:35:54] <cradek> the angled part should stop (in Z) as soon as you're out of the material
[03:36:17] <cradek> there should be no more Z motion than absolutely necessary
[03:36:38] <jmkasunich> then the pic has multiple issues
[03:37:01] <jmkasunich> right now the corners between the angle and the vertical define the 29 degree slope
[03:37:09] <jmkasunich> you're saying that should be vertical
[03:37:29] <cradek> I don't follow
[03:37:43] <jmkasunich> is this supposed to be the entry or exit?
[03:37:47] <cradek> the first pass here is the rightmost
[03:37:48] <cradek> this is entry
[03:38:32] <jmkasunich> when the first pass changes from vertical to angled, is the cutter in metal or air?
[03:38:58] <cradek> let me draw the material too
[03:39:02] <jmkasunich> thanks
[03:42:34] <cradek> http://timeguy.com/cradek-files/emc/g76taper.png
[03:43:15] <jmkasunich> upper and right vertical lines are material and lower is the drive line?
[03:43:50] <cradek> top horizontal is the material edge, bottom horizontal is drive line
[03:43:57] <jmkasunich> ok
[03:43:59] <cradek> right vertical is nothing
[03:44:04] <jmkasunich> could be a shoulder
[03:44:12] <cradek> ok right
[03:44:18] <cradek> that's the end of the drive line
[03:44:24] <jmkasunich> ok
[03:44:39] <jmkasunich> is it a coincidence that the last pass begins its angle on the material surface?
[03:45:00] <cradek> no, not a coincidence
[03:45:03] <jmkasunich> ok
[03:45:55] <jmkasunich> so, both bends (vertical to angle, and angle to horizontal) need to be reached at the same spindle orientation for each pass
[03:46:08] <cradek> yes
[03:46:18] <cradek> so the verticals have to be the same length
[03:46:21] <jmkasunich> that means you can't start the vertical moves at the same orientation
[03:46:28] <cradek> that's where we started :-)
[03:46:39] <cradek> true that's another solution
[03:46:56] <jmkasunich> but non-trivial to say the least
[03:47:10] <cradek> yeah, there's no support for that further down
[03:47:27] <jmkasunich> so, in this case, the drive line is quite far outside the part
[03:47:55] <jmkasunich> in any case, the drive line cannot be right next to the part, because the first move has its first corner well outside the material
[03:48:01] <jmkasunich> and the drive line needs to be at or below that level
[03:48:53] <cradek> yes I guess it has to be at least a full thread depth away from the part
[03:49:31] <jmkasunich> it only makes the timing worse, but let me digress for a sec
[03:49:58] <jmkasunich> before I was talking about the corners describing a 29 degree angle, after you said something about minimziing Z excursions
[03:50:19] <jmkasunich> you could reduce Z if you started all of the vertical moves at the Z coord of the first one
[03:50:27] <jmkasunich> the last one, sorry
[03:50:46] <cradek> true
[03:50:48] <jmkasunich> go in along the last move, until you intersect the angled part of the current move, then follow the current move
[03:51:02] <cradek> except the lengths are going to vary again
[03:51:04] <jmkasunich> but that aggravates the non-uniform length thing
[03:51:12] <cradek> yep
[03:51:17] <jmkasunich> s/again/worse/
[03:52:05] <jmkasunich> in real life, both corners are gonna get blended
[03:52:44] <jmkasunich> so you need to either 1) approach the vertical to angle corner at the same speed in each pass, or 2) start from a standstill at the vertical to angled corner
[03:52:56] <jmkasunich> so they are consistent from pass to pass
[03:53:20] <cradek> I don't follow what you mean by "speed" in 1
[03:53:41] <cradek> there is no "time" here, only spindle rotation
[03:53:58] <jmkasunich> for purposes of discussion, lets assume spindle speed is constant
[03:54:15] <jmkasunich> you have finite accel rates on Z, so there must be some rounding
[03:54:27] <cradek> yes it will round
[03:54:40] <jmkasunich> assume the drive line is even with the first corner of the first pass
[03:54:57] <jmkasunich> that pass will begin with the tool standing still waiting for an index pulse
[03:55:11] <jmkasunich> the index arrives, and the tool accels along the angle
[03:55:27] <jmkasunich> no rounding of that corner
[03:55:56] <jmkasunich> unless the last pass _also_ begins at the corner, it will be moving straight in when it hits the corner, and it will round the corner
[03:56:00] <jmkasunich> paths not the same...
[03:56:43] <cradek> with the current scheme, all the passes are going to be the same shape
[03:56:47] <jmkasunich> if the drive line is very far out (compared to the distance it takes the tool to accel) then every corner will be rounded the same, because the X vel when it hits the corner is the same
[03:56:55] <cradek> they'll all be a little rounded, but pretty equally
[03:57:08] <jmkasunich> right, because the drive line is well outside the first corner
[03:57:24] <cradek> no, stop a second
[03:57:25] <jmkasunich> does anything force that, or cound the programmer put the drive line right at the first corner
[03:57:44] <jmkasunich> ^s
[03:58:00] <cradek> if I fix this so all the verticals are the same length, which is how I think is the easiest fix, your problem is a nonproblem, right?
[03:58:13] <jmkasunich> yes
[03:58:15] <cradek> because all the passes, after sync, will be the same lengths and shapes
[03:58:42] <jmkasunich> there can be other problems if the verticals are zero length - dunno if the G76 syntax allows the drive line to be that close or not
[03:59:01] <jmkasunich> does G76 spec the X of the final drive line, or the initial one?
[03:59:08] <cradek> the error checking is not good yet
[03:59:35] <cradek> say the question again, I don't understand
[03:59:58] <jmkasunich> what parameter of G76 says where the drive line is?
[04:00:13] <jmkasunich> maybe drive line is the wrong term here
[04:00:17] <cradek> the drive line is the "old" xyz to the xyz specified in the g76
[04:00:28] <jmkasunich> is drive line fixed, or does it move in on each pass?
[04:00:34] <cradek> drive line is fixed
[04:00:37] <cradek> passes are offset from it
[04:00:48] <jmkasunich> ok, thats the problem, I'm using the wrong terminology
[04:00:58] <cradek> oh ok
[04:01:01] <jmkasunich> what do you call the rapid from left to right?
[04:01:12] <jmkasunich> in the pic, its on the drive line for every pass
[04:01:21] <cradek> yes
[04:01:21] <jmkasunich> but it is _not_ the drive line, that was my mistake
[04:01:39] <cradek> yes that is the drive line
[04:02:15] <jmkasunich> you said: "if I fix this so all the verticals are the same length, which is how I think is the easiest fix, your problem is a nonproblem, righ"
[04:02:34] <jmkasunich> how can the verticals be the same length if the return pass is always on a fixed drive line?
[04:02:40] <jmkasunich> split them into two parts?
[04:02:50] <cradek> yes, before starting a pass, it will have to go in or out a variable amount, then sync
[04:03:09] <cradek> yes, there would be two verticals per pass
[04:03:17] <jmkasunich> ok
[04:03:18] <cradek> I don't know exactly what they should be yet
[04:03:23] <jmkasunich> another misunderstanding
[04:03:33] <cradek> 'out' is surely safer
[04:04:11] <jmkasunich> doesn't make sense to go out at this end of the thread
[04:04:31] <jmkasunich> (maybe the first pass, if you start off in and need to come out)
[04:04:45] <cradek> it seems goofy to go out, but I think that's the easy fix
[04:05:02] <jmkasunich> for subsequent passes, the rapid back should bring you to the proper X to start the fixed length vertical move
[04:05:29] <jmkasunich> (I see no reason the rapid back needs to be perfectly parallel to the spindle)
[04:05:35] <cradek> sure it could save a move that way
[04:06:02] <jmkasunich> in fact - the vertical should be one fixed length move
[04:06:04] <cradek> (I don't care too much about that though)
[04:06:23] <cradek> yes the verticals have to be the same length
[04:07:15] <jmkasunich> the vertical move should always be the same as the distance between the drive line and the material surface, and the pre-sync rapid should take you to the proper X, whatever that is
[04:07:35] <jmkasunich> that means most passes will be rapiding back _behind_ the drive line
[04:07:42] <jmkasunich> but I don't see any harm in that
[04:07:52] <cradek> yeah, all but the last
[04:09:02] <cradek> obviously I need to work on this in trunk a bit more
[04:09:32] <cradek> or I could go to bed, and you could fix it
[04:09:36] <jmkasunich> heh
[04:09:38] <jmkasunich> or not
[04:09:48] <jmkasunich> I'm still writing my wiki page
[04:09:50] <cradek> *sigh*
[04:10:02] <jmkasunich> go to bed, fix it tomorrow
[04:10:39] <cradek> yeah, that's my plan
[04:10:49] <cradek> I won't check this in on 2.1 branch yet
[04:10:58] <cradek> it's ready though, I found all the changes
[04:11:01] <jmkasunich> good plan
[21:22:50] <cradek_> cradek_ is now known as cradek
