Back
[00:23:40] <jepler> hm, esc-to-cancel-loading is broken in one obvious way, but after that it's still broken :(
[00:38:22] <jepler> maybe I'm half-mistaken
[00:38:47] <jepler> esc-to-cancel-loading doesn't work if you're starting emc on an infinite-loop program, but works if you load it after startup
[00:42:02] <cradek> that sounds odd
[00:42:19] <jepler> it is
[00:43:01] <jepler> I *think* it starts loading too early, and when the stat buffer is first read or the X axis button is first mapped, it takes the focus away from the progressbar, which is the thing that has the Escape binding
[00:43:29] <cradek> yuck, that startup stuff sucks
[03:02:09] <jepler> argh
[03:02:30] <jepler> I didn't intend to remove any pins, but I applied a patch that did it (removed the oddly-named motion.motion-inpos)
[03:02:35] <jepler> and by commenting out those lines, no less
[03:02:42] <jepler> I guess I didn't review the patch I was applying carefully enough
[03:02:45] <jepler> argh
[05:23:24] <CIA-2> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/pncconf/ (pncconf.py pncconf.glade): work to get the pintype editbox display the right name and dispaly the right signal names- next to get signal names to change when GPIO switches from input to output
[05:30:29] <fenn_> fenn_ is now known as fenn
[11:03:12] <alex_joni> cradek: I built some emc2-2.3.0-beta2 packages for dapper
[11:03:44] <alex_joni> I copied them to the proper place, but you need to work your magic on them (some extra packages, bwidget & co, and repo changes)
[12:53:37] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/user_comps/hal_input.py: revert to rev 1.16 to fix regression (SF#2569072)
[12:54:07] <CIA-2> EMC: 03jepler 07v2_3_branch * 10emc2/src/hal/user_comps/hal_input.py: revert to rev 1.16 to fix regression (SF#2569072)
[13:07:25] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: SF#2712817: location of sample-configs with --prefix=/usr/local
[15:03:41] <cradek> jepler: did you try to contact Brad McLean about hal_input?
[15:04:09] <cradek> if you must just revert his change, you should revert the docs too - but it would be better to ask him to fix whatever is wrong.
[16:29:02] <cfrank> Hi Everyone. I have seen emc2 controllong 5-axis machines on youtube.
[16:29:08] <cfrank> http://www.youtube.com/watch?v=7WCrqqoZkPg
[16:29:32] <cfrank> Where do I find configs to do that?
[16:30:01] <seb_kuzminsky> hi cfrank
[16:30:10] <seb_kuzminsky> the configs are all part of the CVS repo
[16:30:14] <seb_kuzminsky> the 5-axis stuff is here:
[16:30:16] <seb_kuzminsky> http://cvs.linuxcnc.org/cvs/emc2/configs/5axis/
[16:30:25] <seb_kuzminsky> if you have a CVS checkout it's in there too
[16:30:46] <cfrank> Thanks seb_kuzminsky. I will check it out.
[16:30:52] <seb_kuzminsky> if you have installed the 2.3beta deb, the configs are in /usr/share/doc/emc2
[16:31:23] <cfrank> Even better. I have.
[16:49:55] <cradek> oh hey, that's my machine - I forgot about that video.
[16:55:05] <cradek> this is a great demonstration:
http://www.youtube.com/watch?v=DjPCEpZybXs&feature=related
[16:55:38] <SWPLinux> argh. flash is dead on my laptop
[16:55:43] <SWPLinux> stupid flash
[17:03:24] <BJT-Work> I like this comment "NICE! but how do you control 5 motors at once? and how do you set up emc, i saw 9 axis config in the set up but i think it was only for simulation?"
[18:38:23] <cradek> jepler: does 2c3fc905e7646577188cecdb5248dd811b5bd662 also belong on the 2.3 branch?
[18:39:26] <BJT-Work> * BJT-Work gets out his secret decoder ring to see what that says
[18:40:41] <jepler> cradek: yes
[18:40:56] <jepler> BJT-Work:
http://git.unpy.net/view?p=emc2.git;a=commit;h=2c3fc905e7646577188cecdb5248dd811b5bd662
[18:40:58] <cradek> strange - when I search for it in gitweb, it doesn't show me that change
[18:41:31] <cradek> odd that I can search by committer in gitweb but not gitk
[18:42:37] <cradek> jepler: how did you locate that in gitweb?
[18:43:27] <jepler> cradek: I used 'git log' to find it, then scanned the shortlog for the commit message
[18:44:30] <cradek> ....
[18:47:36] <BJT-Work> strange that decoded to "the butler did it in the conservatory with the candlestick" if I use my x-ray glasses
[18:48:41] <cfrank> cradek: Thanks for the update. Nice! I was looking to build an XYZBC machine. I read that the BC tables result in less room than a multi axis head.
[18:49:01] <cradek> jepler: is there any smarter way to handle the situation where we have a branch that is stabilizing, and a bugfix change needs to go on it and the trunk both? I can see where maybe git could notice that it's the same change.
[18:50:17] <cfrank> I was hoping to have B axis on the Z column and the C rotary table on the base. Taix mill is too small for a gomble
[18:50:42] <cradek> yeah, that's what I built too
[18:51:01] <cradek> it helps a lot if the center of B rotation is near where a typical tool tip will be
[18:51:16] <cradek> otherwise you use up huge amounts of X travel when B moves
[18:52:20] <jepler> cradek: this is what git-cherry is about
[18:52:40] <cfrank> I see. Could you cut metal on it?
[18:52:55] <cradek> on mine? very marginally
[18:53:00] <jepler> cradek: or, rather, git-cherry-pick
[18:53:20] <cradek> depends on the metal I suppose
[18:53:52] <jepler> git-cherry to find things on another tree that you don't have; git-cherry-pick to apply one of them to your tree
[18:54:08] <cfrank> I cut aluminum mostly. I was hoping to keep things very compact for stiffness.
[18:59:53] <jepler> cradek: so for instance, 'git-cherry -v v2_3_branch master | grep '^+' finds changes on master that are not in v2_3_branch, including 2c3fc. Apply it by checking out v2_3_branch and 'git-cherry-pick 2c3fc'
[19:00:28] <cradek> interesting, thanks
[19:36:44] <seb_kuzminsky> * seb_kuzminsky blinks
[19:36:49] <seb_kuzminsky> is cradek using git?!
[19:36:57] <seb_kuzminsky> maybe there is a god ;-)
[19:37:29] <alex_joni> seb_kuzminsky: did you get the config from yesterday?
[19:37:36] <seb_kuzminsky> no
[19:37:39] <seb_kuzminsky> did you send it to me?
[19:37:42] <alex_joni> 22:53 < alex_joni> hmm.. now I have a config for seb, but he's not here :)
[19:37:42] <alex_joni> 22:53 < alex_joni>
http://pastebin.com/m2573b842
[19:38:01] <seb_kuzminsky> thanks
[19:38:11] <cradek> seb_kuzminsky: I'm pretty sure there's not...
[19:38:34] <seb_kuzminsky> right, if there were, it'd be telling you to use bzr ;-)
[19:39:30] <cradek> I think we need to switch to something - I'm trying to figure out which one I think is least intolerable
[19:39:40] <seb_kuzminsky> cool
[19:39:46] <cradek> so far I think git has shown the best import of our old data
[19:40:06] <seb_kuzminsky> what did you not like about the bzr import?
[19:40:52] <cradek> the only one I've seen is the one on launchpad which discards all the existing forks
[19:40:57] <seb_kuzminsky> alex_joni: is it strange that the default acceleration (line 138) is 100, but the axis 0 max accel (line 158) is only 80?
[19:41:22] <seb_kuzminsky> cradek: the lp folks deliberately convert just one branch... there are other tools that purport to convert them all
[19:42:07] <cradek> ok thanks, I might dig into that
[19:42:57] <alex_joni> seb_kuzminsky: strange, yes.. but it shouldn't be an error
[19:43:04] <alex_joni> it should clamp to max accel
[19:44:58] <seb_kuzminsky> cradek: i had intended to try cvsps-import, which claims to convert a whole CVS repo to BZR, but it needs local read access to the repo
[19:45:01] <seb_kuzminsky> https://launchpad.net/bzr-cvsps-import
[19:45:32] <seb_kuzminsky> alex_joni: i'll give that config a whirl and see if i can reproduce the problem
[19:46:31] <alex_joni> seb_kuzminsky: great
[20:01:59] <cradek> seb_kuzminsky: strange, because cvsps doesn't need that
[20:05:55] <cradek> seb_kuzminsky: (but of course we have it if we need it)
[20:19:55] <jepler> I tried bzr cvsps-import on a small project of my own (400 changesets by cvsps's count) and it does seem to have given a tree structure with every branch reflected
[20:20:15] <jepler> but each branch has its own .bzr directory
[20:23:23] <jepler> http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
[20:23:27] <seb_kuzminsky> jepler: each branch *should* have its own .bzr directory, but not every .bzr directory needs to contain a repo
[20:24:51] <seb_kuzminsky> i usually use "shared repos", where a top-level dir has a .bzr with all the repo info in it, then one dir per checked-out branch, each of which contains its own (tiny) .bzr dir with just the checkout info
[20:26:08] <seb_kuzminsky> jepler: "Darcs makes the simple things tough, the difficult things near impossible, and the impossible merely really slow."
[20:28:37] <jepler> seb_kuzminsky: I've got a bzr branch called BRANCH_STABLE and one called HEAD. How do I get information about the difference between them. For instance, how do I find the last common version they shared in history?
[20:28:50] <cradek> interesting
http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation#Filerenames
[20:29:02] <seb_kuzminsky> the easiest is probably "bzr vis"
[20:30:16] <seb_kuzminsky> cradek: yes, one common complaint against git (at least last time i checked) was that it doesnt treat rename as a first-order operation, it tries to do post-facto rename detection and then gets itself confused...
[20:31:42] <jepler> bzr vis --help
[20:31:43] <jepler> bzr: ERROR: unknown command "vis"
[20:32:02] <seb_kuzminsky> jepler: it's in the bzr-gtk plugin
[20:37:54] <jepler> Oh, I was looking for something that worked on the terminal
[20:49:52] <seb_kuzminsky> jepler: say you want to find what's new in HEAD since last time there was a merge between HEAD and BRANCH_STABLE
[20:50:11] <seb_kuzminsky> cd BRANCH_STABLE
[20:50:22] <jepler> ok
[20:50:23] <seb_kuzminsky> bzr diff -r ancestor:../HEAD
[20:50:38] <seb_kuzminsky> i think that's it
[20:51:05] <seb_kuzminsky> that's from the "bzr help revisionspec" info
[20:52:07] <seb_kuzminsky> or log instead of diff, etc
[20:52:14] <jepler> bzr log -r ancestor:../HEAD..
[20:52:21] <seb_kuzminsky> yeah
[20:52:24] <jepler> ok I think that's it but it's a bit odd
[20:52:33] <seb_kuzminsky> how so?
[20:53:58] <jepler> it's just not like git
[20:54:45] <jepler> particularly having ".." mean "parent directory" and "since" in the same word was a bit odd
[20:59:58] <jepler> cradek: I think renames should be like abortions. legal, safe, and rare.
[21:00:33] <jepler> god help us from the well-meaning developer who shows up one day and renames the whole source tree because he can
[21:01:06] <cradek> so true
[21:01:22] <seb_kuzminsky> jepler: here's another way to find the most recent ancestor between two branches, if that's what you're after:
[21:01:33] <jepler> in fact I'm sure we've had a few who would have done that and were only stopped because our system was CVS
[21:01:34] <seb_kuzminsky> bzr find-merge-base HEAD BRANCH_STABLE
[21:02:04] <jepler> (how come nobody has implemented a dvcs that also lets each developer run 'indent' with his favorite arguments and still gets merges right? Now *THAT* would be awesome)
[21:02:59] <seb_kuzminsky> that spits out a revid, which is the globally-unique revision identifier, mapping that to a revno is branch-dependent and requires (i think) "bzr log -r revid:$REVID"
[21:04:27] <seb_kuzminsky> revids are almost as gross as git revision identifiers :-(
[21:04:40] <seb_kuzminsky> good thing you almost never have to look at them in bzr :-)
[21:09:50] <jepler> in no system could I commit a globally unique tree identifier to memory, or give it over the telephone. but I don't do those tasks very often either
[21:10:24] <seb_kuzminsky> in bzr it's enough to say something like "trunk revno 1234"
[21:10:43] <seb_kuzminsky> that's unambiguous, human-readable, and globally unique
[21:11:33] <jepler> but when I branch, it's not trunk anymore
[21:11:38] <jepler> it becomes "my branch revno 1"
[21:11:41] <seb_kuzminsky> yes
[21:12:03] <jepler> and "your branch revno maybe some other number"
[21:12:33] <seb_kuzminsky> i see what you're saying, and i agree
[21:12:37] <seb_kuzminsky> but i think that's fine
[21:12:51] <seb_kuzminsky> we all need to agree on some master line, like our current trunk
[21:13:06] <seb_kuzminsky> we'll all have clones of that tree on our local development machines
[21:13:25] <seb_kuzminsky> we make local branches by forking from the local copy of upstream
[21:13:28] <seb_kuzminsky> hack in the local branch
[21:13:36] <seb_kuzminsky> commit straight to the upstream trunk
[21:14:00] <seb_kuzminsky> everyone can agree on revnos in the trunk mainline, and can easily diff against it, etc
[21:14:09] <jepler> that brings me to another question
[21:14:26] <seb_kuzminsky> the bzr oracle is: ONLINE
[21:14:34] <jepler> git has git-shell which is a restricted shell that only allows git to send and receive "packs"
[21:14:56] <jepler> it lets you give developers permission to push to a central system without giving them full shell access
[21:14:59] <jepler> is there a bzr equivalent?
[21:15:09] <seb_kuzminsky> hmm
[21:15:47] <jepler> http://ww2.samhart.com/node/47
[21:15:54] <seb_kuzminsky> there's got to be something like it, that's how launchpad works
[21:16:05] <seb_kuzminsky> but i dont know exactly how they do it
[21:17:10] <jepler> is it one of the secret things they keep, er, secret while saying how open source they are?
[21:17:20] <jepler> they sure are interested in making you use their service, what with the integration of lp:
[21:26:27] <jepler> (maybe you can use sftp and "scponly" (
http://www.sublimation.org/scponly/wiki/index.php/Main_Page) to do this
[21:26:55] <seb_kuzminsky> jepler: that looks promising
[21:27:06] <jepler> bzr
http://fedoraproject.org/wiki/Infrastructure/VersionControl/ArchitectureDraft
[21:27:09] <jepler> er
[21:27:12] <jepler> s/bzr//
[21:35:04] <seb_kuzminsky> i think my least favourite thing about bzr is the confusion of storage formats (repo dbs)
[21:56:09] <aystarik> hi
[21:56:42] <seb_kuzminsky> hello there
[21:57:34] <aystarik> is there a way to find the direction of the path? and rotate a "cutter", so that it faces it?
[21:58:52] <SWPLinux> it may be possible to look at the differences (axis.#.motor-pos-cmd-axis.#.motor-pos-fb) to see the instantaneous direction
[21:59:03] <SWPLinux> you'll need an atan2 or something in there as well
[21:59:11] <SWPLinux> but that will be very noisy
[21:59:28] <seb_kuzminsky> or use ddt on .motor-pos-fb
[22:00:05] <SWPLinux> cmd - you want to know before the motion takes place I Think
[22:01:17] <SWPLinux> if you do the subtraction I suggested just after motion.do-motion-calcs (or whatever it's called), you'll get the difference between the new command and the current position, which is hopefully closer to the direction it will move
[22:01:40] <cradek> when this has been discussed before, we've noticed the best solution is to write C directions in the gcode
[22:02:33] <aystarik> ddt(cmd) didn't work or too noisy?
[22:02:54] <cradek> what about corners? or alignment when starting a cut?
[22:03:09] <SWPLinux> ddt will always give you an answer after the fact, since it's looking at (now - before)
[22:03:18] <SWPLinux> versus (soon - now)
[22:03:43] <cradek> might want to search the mailing list archive - I forget all the different things that were discussed
[22:04:08] <SWPLinux> yeah, there are a lot of complications, and using C or some other "unused" axis is much more likely to work well
[22:04:12] <aystarik> I've already tried, but can't find anything related...
[22:05:26] <cradek> jepler: ick, fedora think they need a chroot for bzr
[22:06:00] <aystarik> with C axis -- then you need a custom converter from whatever input you use...
[22:06:25] <cradek> yes you need to change whatever creates the gcode
[22:06:47] <cradek> fortunately the math is very easy
[22:07:19] <aystarik> yes, if you have source :)
[22:08:05] <aystarik> and I guess it is not possible to use G02/G03 any longer?
[22:08:16] <cradek> sure, why not?
[22:09:09] <cradek> in EMC2 you can interpolate C over an arc
[22:09:27] <cradek> so you will get an exact circle with an exact tangent cutter
[22:09:46] <aystarik> oh, so _any_ axis will be interpolated, not only Z?
[22:09:58] <cradek> yes
[22:10:31] <cradek> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sub:G2,-G3:-Arc
[22:10:40] <SWPLinux> XYZ are used to determine the feed rate, C will just be matched to the time needed to do the XYZ move
[22:10:48] <cradek> "If a line of code makes an arc and includes rotational axis motion, the rotational axes turn at a constant rate so that the rotational motion starts and finishes when the XYZ motion starts and finishes."
[22:10:58] <SWPLinux> so using C is better in that the XY feed rates will not be affected
[22:12:54] <aystarik> thanks all :)
[22:13:24] <SWPLinux> you're welcome
[22:13:30] <cradek> welcome, hope you get it going
[22:13:56] <aystarik> still need to convince mechanics about it :)
[22:14:05] <seb_kuzminsky> the bzr guys recommend bzr+https for "authenticated commit without shell access"
[22:15:30] <SWPLinux> so I was talking to this guy about a nice little embedded PC, and I asked him if LinuxBIOS worked on it
[22:15:44] <SWPLinux> of course, he had never heard of it :)
[22:16:50] <alex_joni> they changed the name
[22:17:01] <SWPLinux> yeah, OpenBIOS or OpenBoot or something
[22:17:04] <alex_joni> it's coreboot now
[22:17:09] <SWPLinux> ah, coreboot
[22:17:16] <alex_joni> http://www.coreboot.org/Welcome_to_coreboot
[22:17:17] <alex_joni> daft name
[22:17:19] <SWPLinux> well, he'll find it if he searcheds for LinuxBIOS too :)
[22:17:50] <alex_joni> well.. I'm off to bed
[22:17:54] <SWPLinux> night
[22:18:01] <cradek> bye
[22:18:02] <alex_joni> cradek: did you see my message about dapper packages?
[22:19:05] <alex_joni> (2.3.0-beta2 packages to be exact)
[22:19:15] <cradek> ummmmm
[22:19:46] <alex_joni> no pressure, just wanted to let you know I uploaded them
[22:20:01] <cradek> ok, did you create some new directory for 2.3 then?
[22:20:12] <alex_joni> yes
[22:20:24] <alex_joni> but you need to add some symlinks (I saw for 2.2 ..)
[22:20:40] <alex_joni> was afraid I'd get those wrong (especially since you rsync it)
[22:20:54] <alex_joni> I added 2.3 and 2.3-sim
[22:21:23] <alex_joni> anyways.. off to bed now
[22:21:26] <alex_joni> good night all
[22:21:36] <alex_joni> seb_kuzminsky: let me know if you discover anything with that config
[22:22:05] <cradek> alex_joni: I'll see if I can figure it out
[22:23:19] <alex_joni> well.. you did for 2.2 ;)
[22:23:28] <alex_joni> so I'm sure you'll figure it out again..
[22:23:38] <cradek> syncing now...
[22:31:54] <cradek> alex_joni: done, I think
[22:32:05] <cradek> bbl
[22:38:19] <seb_kuzminsky> here's the somewhat sparse documentation on how to set up authenticated push over bzr+https, while allowing anonymous read-only access:
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
[23:49:24] <cradek> I have to say, git-shell is pretty appealing compared to that