Back
[04:35:29] <cradek> jmkasunich: yes that's the one
[04:35:32] <cradek> how did you guess
[04:35:53] <cradek> http://timeguy.com/cradek-files/emc/spindle-encoder.jpg
[04:35:57] <cradek> but it is done now, yay
[04:38:55] <cradek> goodnight
[04:55:20] <jmkasunich> yay
[04:55:34] <jmkasunich> fan stilts!
[13:28:31] <CIA-5> EMC: 03jepler 07master * rb2fec617aeb8 10/src/hal/components/lowpass.comp: this should be noted
[13:28:34] <CIA-5> EMC: 03jepler 07master * r3b94922457e1 10/src/hal/components/ (limit2.comp limit3.comp lowpass.comp): new 'load' pin immediately copies input to output
[13:30:27] <alex_joni> morning jeff
[13:46:48] <jepler> hi alex_joni
[13:49:57] <cradek_> cradek_ is now known as cradek
[16:22:16] <cradek> does anyone remember why we made the chooser comes up with all the trees open? it's kind of unweildy
[16:23:48] <SWPadnos> "out of sight, out of mind"?
[16:24:13] <SWPadnos> it should probably come up with any user configs expanded, but samples not
[16:25:35] <skunkworks_> I thought that is what it does.. iirc. it opens up all configs when you first run emc - then after you select one and it copies to your home directory - then that is the only one expanded. But I could be wrong..
[16:26:03] <cradek> you could be right for installed - I'm currently rip
[16:26:13] <cradek> if it's just rip that does it, no big deal
[16:29:27] <jepler> if {$nonsample_count} {
[16:29:28] <jepler> catch { $tree closetree /usr/share/doc/emc2/examples/sample-configs }
[16:29:28] <jepler> }
[16:29:38] <jepler> the path to close is hardcoded, it looks like
[16:30:19] <jepler> if {[string compare $dir "/usr/share/doc/emc2/examples/sample-configs"] == 0} {
[16:30:22] <jepler> return [msgcat::mc "Sample Configurations"]
[16:31:13] <cradek> so it should work for installed? (is that path right?)
[16:33:09] <mozmck_work> I think that is what it does for installed iirc
[16:43:57] <mozmck_work> I would like to build packages of master occasionally to put in experimental or somewhere for folks who want/need some feature/bugfix etc. or just want to test the latest without having to compile it.
[16:46:08] <cradek> especially after Feb 1 when we start stabilizing, that'd be very useful
[16:46:14] <mozmck_work> kinda like a nightly build that's not nightly :) any thoughts? bad idea?
[16:46:27] <SWPadnos> sounds good to me
[16:46:33] <cradek> that reminds me, I wonder if micges will merge tlo-all
[16:46:43] <cradek> ... in the next few days
[16:47:04] <SWPadnos> once we get to that point (and if there are no objections), I'll set up an account for you so you can directly FTP packages to the linuxcnc.org site
[16:47:23] <mozmck_work> good. I would probably also make builds for 9.10 in hopes to be getting ready for 10.04
[16:48:00] <SWPadnos> I think we're hoping to make a 10.04-based LiveCD not too long after 10.04 is released
[16:48:07] <SWPadnos> (which is April 29)
[16:48:42] <mozmck_work> yeah, my thought is to get beta releases of 10.04 and start working on it before it's released.
[16:49:13] <cradek> I'm not so sure about making it easy for average joes to install non-final packages over their 2.3 though
[16:49:38] <mozmck_work> I've got the lucid kernel git tree, and I'll start playing with patching it for rtai soon.
[16:49:42] <cradek> two reasons: they might mess up their working 2.3 machines, and they might make it difficult or impossible to upgrade to the final 2.4 package
[16:49:55] <cradek> (since we'll be playing with packaging to get it right)
[16:50:43] <mozmck_work> hmm, could be. most nightly builds warn that it is experimental and may break stuff :)
[16:50:53] <SWPadnos> I don't imagine having a repository for "nightly" builds, so it would be a manual download/install process
[16:51:09] <SWPadnos> which should keep it out of the hands of "average joes"
[16:51:13] <mozmck_work> that was my thought.
[16:52:15] <mozmck_work> you would have to do it on purpose, but it would be easier for a lot of folks than setting up to compile.
[16:52:34] <cradek> I disagree that it would keep it out of the hands of average joes
[16:52:39] <cradek> I don't mean to call anyone names
[16:53:10] <cradek> I am worried that people will disrupt their upgrade path by installing packages that don't come from the usual apt repositories
[16:53:18] <SWPadnos> ah
[16:53:36] <cradek> I've seen this repeatedly ("I installed a kernel from /experimental by clicking on the package, now my SDS2 doesn't update right and I have to compile something? what?")
[16:54:06] <SWPadnos> I guess a wiki page that tells people where to get the packages, and also how to uninstall them, would be appropriate
[16:55:41] <mozmck_work> hmm, this wouldn't be the kernels - just emc2, and I wouldn't think that would disrupt things.
[16:56:23] <mozmck_work> just uninstall and reinstall emc2 from synaptic...
[16:56:25] <SWPadnos> you'd need kernels at first, since we won't have any 9.10 kernels for you to compile the EMC2 packages against
[16:57:15] <mozmck_work> the "nightly" builds I'm thinking would just be for LTS ubuntu.
[16:57:37] <SWPadnos> ok, so they wouldn't start until the hypothetical 10.04-based CD release
[16:57:55] <mozmck_work> I've got a 9.10 kernel, and I'll probably update that soon. you put it on experimental for me!
[16:58:00] <SWPadnos> heh
[16:58:11] <SWPadnos> well that's not an LTS now, is it? :)
[16:58:13] <mozmck_work> that's kind of what I was thinking, or maybe for 8.04 before then
[16:58:50] <cradek> well I'm torn. Part of the reason for experimental packages is to get the packaging, including the upgrade path stuff, right... That means we'll have some bad packages. That means we'll probably end up helping people clean up at least some kind of mess when this happens. Maybe it's unavoidable.
[17:02:57] <mozmck_work> I don't know either. something to think about anyhow.
[17:04:02] <cradek> if we are just careful to get our version numbers monotonic, maybe it's fine. I think we figured out how to do that (with ~ was it?)
[17:04:24] <SWPadnos> yep
[17:04:30] <SWPadnos> ~prexxx
[17:04:48] <seb_kuzminsky> in a debian version number, ~ sorts last
[17:05:04] <SWPadnos> if you use the date in YYMMDD order, they should be good
[17:05:10] <SWPadnos> ~preYYMMDD
[17:06:10] <seb_kuzminsky> ~preYYYYMMDD?
[17:06:29] <mozmck_work> I see, so each version is newer than the last.
[17:06:35] <SWPadnos> nah, we're in 10 already, so there shouldn't be any Y2.01k issues :)
[17:07:03] <jepler> hi all, just tuning in for a second here
[17:07:13] <SWPadnos> it's like the ZIP code problem - developers on the west coast don't realize that there are zeroes in frond for some of us :)
[17:07:21] <jepler> after we have a tag we can also use the git-describe output to name the packages
[17:07:22] <SWPadnos> front
[17:07:22] <mozmck_work> the changelog will get big after a while. what do they normally do about that?
[17:08:15] <jepler> if we have the tag v2.4-pre then git-describe can say things like: v2.4-pre-9-g186c9cf
[17:08:34] <jepler> "9" will increase in the future, and gHHHHHH tells us the actual ref it was built from
[17:08:57] <jepler> just turn the -pre to ~pre and you've got a version that's guaranteed "before" 2.4.0
[17:09:01] <jepler> * jepler disappears again
[17:09:45] <seb_kuzminsky> i think someone (maybe me) should teach the buildbot to build .debs and put them in a "bleeding-edge" repo somewhere, rather then doing it manually now and then
[17:11:52] <cradek> wow, thanks for volunteering to do that! :-)
[17:12:24] <mozmck_work> that would work too :)
[17:13:45] <seb_kuzminsky> heh, "git describe --tags master" says "cvs-import-760-g3b94922"
[17:14:02] <jepler> that means we're 760 commits past the CVS import, I think
[17:14:09] <cradek> yep
[17:14:15] <seb_kuzminsky> and there's been no tags since the cvs import
[17:14:42] <seb_kuzminsky> i think the debian tools get the version number for the package from the top of the debian/changelog, is there a way to override that?
[17:15:46] <seb_kuzminsky> it'd be nice not to have to prepend a dummy entry to the changelog, or rewrite the top of the changelog...
[17:17:07] <jepler> In one of my other projects, a script rewrites debian/changelog:
http://git.unpy.net/view?p=cropgui.git;a=blob;f=debian/git;hb=master
[17:17:19] <mozmck_work> I don't know, that's why I asked about the size of the changelog over time.
[17:17:23] <jepler> I can just run debian/git and I get a package
[17:17:39] <jepler> but that debian/changelog never gets committed
[17:18:10] <seb_kuzminsky> does it make the debian/changelog from the git log?
[17:18:25] <jepler> no, it just says to read the git log
[17:18:46] <jepler> (which obviously a non-git user won't have simple access to ..)
[17:18:47] <cradek> jthornton: sometime could you document WRAPPED_ROTARY on master? I'm looking for the email that says how it works...
[17:18:48] <seb_kuzminsky> i see
[17:19:12] <jepler> I suppose you can parse the $(git describe) to get the base tag, then git log --oneline $TAG.. to generate changelog entries
[17:19:43] <cradek> I think it would be neat to put the oneliners in the real changelog for the daily packages
[17:19:59] <cradek> for the release we'll still have a handwritten/edited changelog entry of course
[17:20:48] <seb_kuzminsky> one-liners from the git log for everything since the most recent tag sounds good
[17:27:43] <jepler> my script, revised to add the short log to the debian changelog:
http://pastebin.ca/1765367
[17:28:33] <jepler> and here's a debian/changelog it wrote:
http://pastebin.ca/1765369
[17:30:06] <seb_kuzminsky> looks good
[17:32:18] <seb_kuzminsky> oops, it doesnt parse the cvs-import tag because it contains a -
[17:32:30] <seb_kuzminsky> hardy's git doesnt understand --dirty
[17:32:37] <jepler> doh, you're right
[17:32:49] <jepler> you can drop that; it only matters if you want to build from a dirty tree
[17:33:55] <seb_kuzminsky> also, cvs-import sorts before our current version string 1:2.4.0~pre, so dch doesnt like it
[17:34:13] <seb_kuzminsky> anyone mind if i tag the current master as 2.4.0~pre?
[17:34:18] <jepler> yes
[17:35:01] <cradek> I suggest you wait for at least the feature freeze before doing that
[17:35:03] <jepler> let's wait at least until after the branch
[17:35:19] <cradek> micges: do you plan to merge tlo-all before the feature freeze?
[17:35:30] <micges> yes
[17:35:36] <cradek> yay
[17:36:22] <micges> cradek: did you test any more tlo_all branch?
[17:36:42] <cradek> yes I tested some after I did that merge - but not since then
[17:36:57] <cradek> we should try another merge - I bet it will be easier this time
[17:37:37] <micges> ok
[17:37:59] <cradek> or maybe you should just merge it into master now?
[17:38:13] <cradek> that's the best way to get it tested I think
[17:39:44] <micges> can I do this now or you have any shedule for today?
[17:41:13] <cradek> I guess do it now unless someone objects?
[17:41:18] <cradek> what does everyone think?
[17:41:35] <cradek> NB this changes the tool table format
[17:43:34] <jepler> I don't have any objections
[17:43:47] <jepler> as long as the code is right :)
[17:52:26] <seb_kuzminsky> bbl, out of batteries
[17:53:04] <alex_joni> cradek: sounds good to me too
[17:53:10] <micges> one simple conflict with polar code
[17:53:23] <cradek> micges: let me know if you need help
[17:53:26] <alex_joni> ja3 seems too early for 2.4, guess that'll be postponed just another time :/
[17:53:39] <cradek> alex_joni: we've said that a few times haven't we
[17:53:55] <micges> unfortunately :/
[17:53:56] <alex_joni> cradek: yeah
[17:54:11] <alex_joni> well.. getting it right isn't trivial (or it would have been done long ago)
[17:54:23] <alex_joni> but the work on it is waaaay more than it was before 2.3 ;)
[17:54:45] <alex_joni> so, it's getting there (and at least with git it's easier to keep track of changes)
[17:55:11] <alex_joni> I think getting it in order and merge to master after the 2.4 branch will be a good goal
[17:58:57] <jepler> I don't want it merged until we're pretty sure the end of the road is in sight. We shouldn't merge it after 2.4 is branched just as a way to force our attention on it..
[19:00:20] <cradek> seb_kuzminsky: jepler: I'm making an enco order. Do you guys need anything for this weekend?
[19:09:26] <seb_kuzminsky> flame thrower
[19:10:16] <cradek> I looked - they don't have them
[19:21:22] <cradek> so, nothing then? :-P
[19:26:26] <seb_kuzminsky> nothing for me thanks :-)
[20:06:10] <CIA-5> EMC: 03seb 07master * r61325cbad756 10/debian/update-dch-from-git: Add a helper script to update the debian changelog from the git log
[20:07:00] <seb_kuzminsky> if we dont re-tag the tree now, i think we'll run into trouble later
[20:07:31] <seb_kuzminsky> currently i'm starting with the debian version number from the top of the changelog (1:2.4.0~pre) and appending the "git describe" output
[20:07:43] <seb_kuzminsky> which is cvs-import-760-blahblah
[20:08:25] <seb_kuzminsky> so the debian version is "1:2.4.0~pre+cvs-import-760-blah"
[20:08:54] <seb_kuzminsky> if we later tag the tree "2.4.0~pre", and i change the script to ignore the current version number from the debian/changelog, then the new debian version number will be something like:
[20:09:06] <seb_kuzminsky> 2.4.0~pre+770-blah
[20:09:34] <seb_kuzminsky> which i think sorts wrong against ...~pre-cvs...
[20:11:40] <seb_kuzminsky> yes, ...~pre-cvs is greater than ...~pre-770, according to "dpkg --compare-versions"
[20:12:02] <mozmck_work> huh, I thought numbers came first
[20:12:22] <SWPadnos> yes, so pre is > (later than) 770
[20:12:32] <seb_kuzminsky> what's the argument against tagging master as 2.4.0~pre right now? It seems like that should happen at the same time the version in the changelog is updated
[20:12:34] <mozmck_work> oh, duh
[20:12:53] <SWPadnos> maybe this change should be reverted, and re-applied in a week when the tag will change
[20:13:20] <SWPadnos> then again, maybe it could be changed now, since RIP emc2 from TRUNK is saying it's 2.4 pre
[20:23:26] <mozmck_work> SWPadnos: Firefox 3.0.17? antique!
[20:23:49] <SWPadnos> beater Jaunty machine
[20:24:05] <mozmck_work> :)
[20:25:01] <seb_kuzminsky> jaunty ate my disk :-(
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346691
[20:35:29] <jepler> seb_kuzminsky: ow
[20:39:52] <SWPadnos> wow cool. Altium is very nearly usable under Wine
[20:39:59] <SWPadnos> even in 3D mode
[20:40:14] <cradek> seb_kuzminsky: ext3 or ext4?
[20:40:40] <seb_kuzminsky> e3, but i think it's bug in the block driver, not the filesystem
[20:40:57] <seb_kuzminsky> i wonder why the hardy buildbot didnt fetch any of the tags...
[20:45:53] <seb_kuzminsky> it sure is uncomfortable typing on frostbitten fingertips :-(
[20:46:22] <seb_kuzminsky> had to put on chains at the top of loveland pass last night, i was only outside for maybe 5 minutes :-(
[20:46:44] <dgarr> maybe i'm doing something wrong, but it seems (AXIS,hide) etc is not working (git-master)
[20:46:46] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-remove-extra-def-for-comment-that-masks-original-def.patch
[20:46:58] <cradek> ouch, no permanent damage I hope!
[20:47:22] <seb_kuzminsky> i hope so too!
[20:49:06] <micges> what temp was there?
[20:49:21] <seb_kuzminsky> not sure
[20:50:01] <micges> here was -25 C at the morning
[20:50:07] <seb_kuzminsky> brr
[20:50:21] <SWPadnos> that's so strange, because it's (down to) 50 degrees here
[20:50:29] <cradek> above freezing here today - the snow has been melting for days
[20:50:44] <SWPadnos> it's been raining - we're supposed to get up to 2 inches today - which is a little odd for this time of year
[20:51:08] <SWPadnos> though it should get cold just in time to freeze the wings on my flight
[20:51:37] <mozmck_work> we've gotten cooler again here - about 55 degrees. it was in the 70s last week
[20:51:55] <SWPadnos> yeah, but that's Texas
[20:51:57] <SWPadnos> :)
[20:52:11] <SWPadnos> it was funny to see that the temperature here was the same as Dallas today
[20:52:20] <mozmck_work> :) it was in the 20s for a couple of weeks a few weeks ago
[20:52:34] <mozmck_work> yeah, and you're in Maine aren't you?
[20:52:37] <SWPadnos> Vermont
[20:52:42] <SWPadnos> you can't get there from here
[20:53:00] <mozmck_work> heh, one of those states way up there anyhow :)
[20:53:04] <SWPadnos> yep
[20:53:27] <SWPadnos> I'll be in Dallas at least once in early February. I think we're shooting the NBA Slam Dunk competition
[20:53:40] <mozmck_work> we saw 9 degrees here for the first time in years.
[20:54:14] <SWPadnos> it was almost cold enough for me to wear a coat when I was there early this month
[20:54:55] <mozmck_work> :) I wear one any time it's under 75
[21:31:58] <CIA-5> EMC: 03micges 07master * re252184275a6 10/src/emc/ (5 files in 4 dirs): Make interpreter and canon handle nine axis tool length offset
[21:31:58] <CIA-5> EMC: 03micges 07master * r0a057c0818d4 10/src/emc/rs274ngc/ (interp_convert.cc interp_internal.cc): Change TLO gcode from G43.1 In Kn to G43.1 Xn ... Wn to allow changing all axes
[21:31:58] <CIA-5> EMC: 03micges 07master * r59e57c0dfe0a 10/src/emc/rs274ngc/ (5 files): In interpreter use EmcPose to hold TLO values instead of single variables
[21:32:00] <CIA-5> EMC: 03micges 07master * rad1e85bafb89 10/src/emc/ (4 files in 4 dirs): TLO in emccanon internally use EmcPose structure
[21:32:03] <CIA-5> EMC: 03micges 07master * ra3637d6db6dc 10/src/emc/rs274ngc/gcodemodule.cc: This is clearly wrong
[21:32:06] <CIA-5> EMC: 03micges 07master * r3c7d40b90609 10/src/emc/rs274ngc/interp_convert.cc: Use whole EmcPose struct copy
[21:32:11] <CIA-5> EMC: 03micges 07master * r3a1d64a4b3c9 10/src/emc/ (12 files in 6 dirs): Remove code for supporting TLO_IS_ALONG_W option
[21:32:14] <CIA-5> EMC: 03micges 07master * rb37bd232ec63 10/src/emc/ (17 files in 7 dirs): Store TLO internally in CANON_TOOL_TABLE as EmcPose
[21:32:17] <CIA-5> EMC: 03micges 07master * rc2ec26d7bbf5 10/configs/common/emc.nml: Increase buffer size to hold larger status structure
[21:32:20] <CIA-5> EMC: 03micges 07master * r7e7ac9fa6448 10/src/emc/ (8 files in 3 dirs): Extend task and motion to handle nine axis TLO
[21:32:31] <CIA-5> EMC: 03micges 07master * rc1e8f5dd2237 10/src/emc/usr_intf/xemc.cc: Fix xemc gui
[21:32:33] <CIA-5> EMC: 03micges 07master * ra9f7db4d0c56 10/src/emc/iotask/ioControl.cc: Saving tool table in a new unified format
[21:32:36] <CIA-5> EMC: 03micges 07master * r4957b5848eb0 10/src/emc/rs274ngc/interp_convert.cc: In G10 L1 allow to enter all tlo at once
[21:32:41] <CIA-5> EMC: 03micges 07master * rf2e541a14596 10/src/emc/iotask/ioControl.cc: Reading new type tool table
[21:32:44] <CIA-5> EMC: 03micges 07master * r258b29ff1838 10/tests/ (3 files in 3 dirs): Update tests due to USE_TOOL_LENGTH_OFFSET change
[21:32:47] <CIA-5> EMC: 03micges 07master * rf70fb5746492 10/configs/ (40 files in 36 dirs): Covert all mill configs tool tables to new format
[21:32:50] <CIA-5> EMC: 03micges 07master * r6b3b22264cae 10/src/emc/iotask/ioControl.cc: Ignore invalid lines in tool table
[21:32:57] <CIA-5> EMC: 03micges 07master * ra4e20fe667ba 10/src/emc/rs274ngc/ (interp_check.cc interp_convert.cc): Allow to set tool front and back angle in G10 L1 by I(front) and J(back) words
[21:33:00] <CIA-5> EMC: 03micges 07master * ra007f0b2cd65 10/src/emc/iotask/ioControl.cc: Remember to compile first
[21:33:03] <CIA-5> EMC: 03micges 07master * r68b0acac510b 10/src/emc/iotask/ioControl.cc: This header is required on 9.04 system
[21:33:10] <CIA-5> EMC: 03micges 07master * ref577dd55506 10/src/emc/iotask/ioControl.cc: Ignore tool table lines with invalid fields
[21:33:13] <CIA-5> EMC: 03micges 07master * r17e245eeb3b5 10/ (110 files in 56 dirs): Merge branch 'master' into tlo_all_axes
[21:33:16] <CIA-5> EMC: 03micges 07master * r3fb35ff737ca 10/configs/ (4 files in 4 dirs): Convert lathe tool tables to new format
[21:33:21] <CIA-5> EMC: 03micges 07master * rf2c74845369c 10/ (4 files in 4 dirs): Update python code and Axis to use new tool table format
[21:33:26] <CIA-5> EMC: 03micges 07master * r63426a55566a 10/lib/python/rs274/glcanon.py: Fix Axis to load programs with G43 and G43.1
[21:33:29] <CIA-5> EMC: 03micges 07master * r7fad832d4d06 10/lib/python/rs274/glcanon.py: oops this line was added by accident
[21:33:32] <CIA-5> EMC: 03micges 07master * r7287daaff59a 10/src/emc/rs274ngc/interp_internal.cc: Changing G43.1 to use axis words caused sometimes to be interpreted like motion gcode, this patch fix this
[21:33:41] <CIA-5> EMC: 03micges 07master * r048c096fe5ef 10/lib/python/rs274/glcanon.py: Add y tlo to Axis canon calculations
[21:33:44] <CIA-5> EMC: 03micges 07master * r3abb398cd5fe 10/src/ (4 files in 2 dirs): adapt tooledit.tcl for unified tool format
[21:33:49] <CIA-5> EMC: 03micges 07master * rca3d29a79620 10/ (configs/sim/sim_mm.tbl src/emc/usr_intf/axis/scripts/axis.py): Allow all axes tool length offset to be set from touch off window
[21:33:56] <CIA-5> EMC: 03micges 07master * rc536dd8b721c 10/configs/sim/sim_mm.tbl: Fix accident modification of tool table
[21:33:59] <CIA-5> EMC: 03micges 07master * r0d7845915848 10/src/emc/usr_intf/axis/scripts/axis.py: Remove not needed tests from touch off window
[21:34:02] <CIA-5> EMC: 03micges 07master * r857ee6a2982d 10/src/emc/usr_intf/halui.cc: Make all tlo values available in halui
[21:34:07] <CIA-5> EMC: 03micges 07master * rd1b1bf79a12f 10/lib/python/rs274/interpret.py: Remove last trace of tlo_along_w from Axis GUI
[21:34:10] <CIA-5> EMC: 03micges 07master * rccf5d7874a18 10/ (111 files in 42 dirs): Merge commit 'origin/master' into tlo_all_axes
[21:34:15] <CIA-5> EMC: 03micges 07master * raa7ee8b5350b 10/ (86 files in 53 dirs): Merge branch 'tlo_all_axes'
[21:34:29] <skunkworks_> wow!
[21:34:57] <cradek> yay
[21:35:23] <cradek> wow we're going to have a lot of cool new stuff in 2.4.
[21:35:45] <micges> yup
[21:36:38] <mozmck_work> so what is tlo?
[21:37:02] <skunkworks_> tool length offset
[21:37:18] <mozmck_work> I see.
[21:37:47] <alex_joni> * alex_joni is happy with TLO all axes
[21:37:54] <alex_joni> especially UVW
[21:37:59] <skunkworks_> for robots?
[21:38:07] <alex_joni> yup ;)
[21:38:23] <alex_joni> although my offsets are probably a bit big :D
[21:38:27] <cradek> and two turret lathes (Z,W)
[21:38:30] <skunkworks_> now - who is going to do cutter comp in all axis? ;)
[21:38:49] <cradek> 2.5d in uv,vw,wu planes would not be too hard at all
[21:38:59] <alex_joni> used a welding torch which is about 650mm long
[21:39:09] <cradek> with rotaries moving it's a very different problem
[21:40:40] <micges> I've machine with torch at 0,0 and drill at 80,90 (mm) , switching offset works fine from about 1 month
[21:41:02] <cradek> micges: is that random toolchanger or regular?
[21:41:17] <micges> regular
[21:41:29] <jthornton> cradek: did you find the email for WRAPPED_ROTARY?
[21:41:31] <micges> brb
[21:52:54] <seb_kuzminsky> cradek, micges: i've been messing with the buildbot (to add automated .deb builds) and i'm going to keep at it, but i'll try not to interfere with your debugging
[21:52:54] <cradek> jthornton: sort of. I found the argument
http://thread.gmane.org/gmane.linux.distributions.emc.user/16539/focus=16626
[21:53:47] <cradek> micges: you should announce this merge on emc-devel and/or emc-users and explain the tool table changes that are needed.
[21:54:38] <micges> sure do
[21:57:02] <seb_kuzminsky> ugh, running git log through dch on 760 commits takes forever...
[21:57:05] <seb_kuzminsky> * seb_kuzminsky wanders off
[21:59:06] <SWPadnos> there's got to be a pretty-printing git log option
[22:00:26] <cradek> --pretty=
[22:11:36] <seb_kuzminsky> i'm using --pretty=oneline
[22:12:49] <SWPadnos> I'm betting there's a way of getting the changes from one arbitrary revision to another - there shouldn't be a need to iterate over all the revisions (if that's what you're doing)
[22:54:12] <jthornton> After Grepping for WRAPPED_ROTARY I have determined that it is an [AXIS] setting in the ini file but that is about all I can figure out atm.
[22:56:59] <SWPadnos> with wrapped rotaries, the sign of the position determines the direction of rotation, and the position wraps around from 360->0 degrees
[22:57:26] <SWPadnos> so starting at 0, if you move to +180, the move will be in the positive direction, and will go to the 180 degree position
[22:57:52] <SWPadnos> starting at 0, if you move to -180, the ending position will be the same, but the direction of motion will be "bcakwards"
[22:58:35] <SWPadnos> similarly, from 0 going to +1 will move one degree forward, but moving to -1 will go 359 degrees backwards, and will end up at the same place (1)
[22:58:48] <aystarik> how about 90? is -90 the same?
[22:58:52] <SWPadnos> no
[22:59:00] <SWPadnos> well, yes, the ending position will be 90
[22:59:12] <aystarik> or 270?
[22:59:20] <SWPadnos> but one move will be 90 degrees forward and the other will be 270 backward
[22:59:26] <SWPadnos> (+90 vs. -90)
[23:00:12] <SWPadnos> in wrapped rotary mode, the absolute value of the position determines the endpoint of the move, so +90 and -90 move to the same orientation
[23:00:23] <SWPadnos> but they will go in opposite directions
[23:00:47] <SWPadnos> I don't know what happens if you're at 90 and move to +90 - that could result in no motion or in a full revolution
[23:00:53] <SWPadnos> but I don't know which one actually happens
[23:01:00] <aystarik> so, there is no way program for one mode may work in another?
[23:01:16] <SWPadnos> it's not likely to
[23:07:12] <jt-plasma> SWPadnos: thanks
[23:07:18] <SWPadnos> sure
[23:07:27] <SWPadnos> (I just hope I got it all correct :) )
[23:14:20] <SWPadnos> huh. now here's a strange piece of C code:
[23:14:41] <SWPadnos> int nrofdevices = 0, i, i1, i2, unknownint;
[23:14:57] <SWPadnos> that's inside a function
[23:15:20] <SWPadnos> and as far as I can tell, it will always result in nrofdevices being set to unknownint
[23:15:37] <jepler> no, I think you're mistaken.
[23:15:42] <jepler> int i=1, j=2;
[23:15:59] <SWPadnos> offs
[23:16:23] <SWPadnos> time to do some accounting or something. I clearly don't know anything about programming any more
[23:18:07] <jepler> in fact that's due to the precedence of = and , rather than due to declarations being different than statements
[23:19:01] <jepler> http://pastebin.ca/1765853
[23:22:40] <SWPadnos> yeah. it's just embarrassing that I didn't recognize some simple declarations
[23:22:57] <SWPadnos> like I've written 1000 times myself (though with much more descriptive variable names)
