Back
[00:17:48] <cradek> http://timeguy.com/cradek-files/emc/dscn6185.mov
[00:17:52] <cradek> http://timeguy.com/cradek-files/emc/dscn6186.jpg
[00:18:08] <cradek> thread cutting on the fred proctor's lathe
[00:18:12] <cradek> s/the//
[00:19:03] <cradek> sort of - the sound doesn't stay synchronized in mplayer, but who cares
[00:35:07] <skunkworks> very good work.
[00:35:56] <skunkworks> how fast where you able to get the spindle to go with the encoder you where using?
[00:37:08] <skunkworks> this is reading the encoder through the parrallel port I assume?
[00:37:58] <jmkasunich> he was running about 130 RPM
[00:38:12] <jmkasunich> limit is probaly 250 or so
[00:38:31] <jmkasunich> more if he lowers base-period (he had it set to 50uS)
[00:43:41] <skunkworks> nice
[00:44:02] <jmkasunich> thats a very high count encoder, 1024 slots, 4096 counts per rev
[00:44:18] <jmkasunich> with a lower encoder it could go faster
[00:44:39] <skunkworks> nice. I am excited.
[00:47:38] <CIA-4> 03jmkasunich 07HEAD * 10emc2/src/emc/kinematics/ (tc.h tp.c): commented out unused traj thread, minor comment change, turned a magic number into a #define
[00:47:38] <CIA-4> 03jmkasunich 07HEAD * 10emc2/src/emc/motion/motion.c: commented out unused traj thread, minor comment change, turned a magic number into a #define
[00:47:51] <skunkworks> jmkasunich: - my first attempt with a hand sharpened carbide.
http://www.electronicsam.com/images/KandT/PICT0804.JPG
[00:48:20] <jmkasunich> not bad
[00:48:33] <skunkworks> Might just break down and buy some. Also cradek showed me where to increase the pad sizes in eagle. very easy when you know where to look ;)
[00:51:57] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED
[00:52:24] <tomp> pretty small to hand sharpen. no Thomas Deckel cutter grinder? I have trouble with drills that size!
[00:55:10] <jepler_> cradek: nice thread, bad white balance. still waiting on the video...
[00:55:32] <jepler_> f**king windows machine is refusing to play it
[00:55:53] <tomp> drills being easier than cutters.. what accounts for stock left on left of circles? head square? board flat? depth enuf?
[00:56:43] <skunkworks> I had some broken carbide drills. (1/8 inch shank) in one dremel I put the carbide shank and the other I put a diamond grinding wheel. ran both of them to get the carbide to a point. then ground the point in half and cut relief all the way around. (it is a encraving type cutter)
[00:59:23] <skunkworks> logger_aj: bookmark
[00:59:23] <skunkworks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-04-24#T00-59-23
[00:59:39] <tomp> ok, single point, maybe single fluke is better for this, make angle across bottom, split & relieve ( 'point' is at edge now )
[01:00:59] <skunkworks> like this
http://www.antaresinc.net/FactCutterGeometry.html
[01:01:19] <skunkworks> is how I did it
[01:01:46] <skunkworks> "conical"
[01:01:46] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[01:03:21] <tomp> right, i was thinkin more like the 'border cutter' in same page, But the bottom angle is relief for ... the bottom
[01:05:01] <skunkworks> I see. but when you are trying to cut a .015" slot I don't see how that would work
[01:05:22] <tomp> .015 dia blank :-)
[01:05:49] <jmkasunich> conical is a lot stronger
[01:06:11] <jmkasunich> since your only cutting a few thou deep, no need to have a "long" shank that is 0.015
[01:06:40] <tomp> right, the blank dia is X but the end dia is.015 ( that was a joke )
[01:06:47] <jmkasunich> s/shank/cutting edge/
[01:07:37] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[01:07:50] <tomp> and you cant cut on center, it doesnt happen, just spins , all cutting is off center a leetle bit. mushing happens at center
[01:08:24] <tomp> thats why drill points and cutter are center relievd
[01:09:39] <tomp> nice looking board tho. wish I could do such on my 3in1.
[01:10:05] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[01:10:47] <skunkworks> The board pales in comparison to what I have seen. (cradek) but it is workable.
[01:10:51] <skunkworks> thanks
[01:11:47] <tomp> jmk: how important is iounmap() ? I didnt find the src yet but it doesnt seem to be used by all drivers. does it de-malloc()?
[01:12:18] <skunkworks> this is the plan
http://thinktink.com/stack/volumes/voli/store/mechmill.htm
[01:12:18] <tomp> i'm right at ;last func in 8255 driver...
[01:12:18] <jmkasunich> I have no idea what you are talking about
[01:13:39] <tomp> sorry, the exit of some drivers call iounmap is some drivers. it infers i need to do some housekeeping. it is not universally used.
[01:13:41] <jmkasunich> I don't think any of the drivers to iomap or iounmap
[01:14:00] <tomp> ok, i was just looking at several, thanks.
[01:14:16] <jmkasunich> well if you just looked and you say the do use it, you must be right
[01:14:47] <jmkasunich> do they call iomap in their init code?
[01:16:01] <CIA-4> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build PASSED
[01:17:01] <tomp> good point, they use unmap buit not map ( silly devs! ). (silly me for using code as model ;-) hal_motenc.c
[01:17:17] <jmkasunich> peteV did that one
[01:17:38] <jmkasunich> for all I know using unmap is the "proper" way, but I didn't use it in any that I wrote
[01:17:55] <tomp> he can outcode me anyday, no complaints, I thought it was necc.
[01:18:03] <jmkasunich> peteV needed to do some PCI stuff, maybe that does an iomap
[01:18:09] <jmkasunich> anyway, I'd leave it out
[01:18:30] <tomp> thanks, that kinda code I'm good at ;-)
[01:19:46] <tomp> skunkworks: that new tip geometry looks like a brazed in carbide flat ( spade drill like ) tho theysay its done in the solid
[01:20:29] <skunkworks> saw that.
[01:20:42] <skunkworks> page is a little spastic :)
[01:20:58] <skunkworks> I have heard good things about them though
[01:22:41] <skunkworks> I think they are saying the compitision is the brazed tip.
[01:23:01] <skunkworks> competition
[01:23:54] <tomp> i think they do braze it in, but have ground flukes above ( like they start with a ball nose 2 fluke cutter, split, insert, braze & grind )
[01:24:00] <CIA-4> 03jepler 07HEAD * 10emc2/src/emc/motion/motion.c: Remove unused code (it was recently made '#if 0')
[01:24:19] <jmkasunich> jepler?
[01:26:06] <tomp> bye all
[01:26:33] <jmkasunich> jepler: that code will most likely be used in the future, leave it in there so we don't have to invent it from scratch (or go back 12 revisions to find it)
[01:28:44] <jepler_> revert it if you feel strongly about it. At work I run into code that was '#if 0'd 8 years ago, as though any minute now it would be pressed back into service. I guess you could say it's a pet peeve.
[01:29:29] <jmkasunich> well if you want to go on an if 0 hunt, there are much older ones in there to look at
[01:29:44] <jmkasunich> but please, if its in the motion control code, talk to me first
[01:30:30] <jmkasunich> cradek just told me about DEAN
[01:30:37] <jmkasunich> maybe I should use ifdef JMK?
[01:30:42] <cradek> hahaha
[01:30:49] <cradek> 'try defining JMK and see what happens'
[01:30:56] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED
[01:31:37] <jmkasunich> there are three kinds of ifdefs in the code I've worked on
[01:31:41] <cradek> jepler_: he was ranting about you to me, but I told him I agreed with you on this one
[01:31:58] <jepler_> jepler_ is now known as jepler
[01:31:59] <jmkasunich> 1) ones that are left over from testing and should get deleted
[01:32:35] <jmkasunich> 2) stuff that I had to disable when I converted emc1 into emc2, because I couldn't figure out what the hell they were all about
[01:32:55] <jmkasunich> 3) stuff that is needed for something on the TODO list but isn't ready now
[01:33:05] <jmkasunich> the ones you just deleted are type 3
[01:33:32] <jmkasunich> I really do want to get the tp and kins code out of the servo thread, and the traj thread is where they go
[01:33:40] <cradek> jepler: if you want a hunt that I'd really appreciate, take that "Last change:" crap out of all the files, it's constantly screwing up my diffs
[01:34:01] <jmkasunich> heh
[01:34:12] <jepler> cradek: some rcs/cvs using folk love those things
[01:34:42] <jmkasunich> we had a debate at the last fest about the use of the $log$ directive
[01:34:47] <cradek> jepler: they're insane
[01:34:51] <jmkasunich> you think last change is bad....
[01:34:55] <cradek> jmkasunich: they're more insane by an order of magnitude
[01:35:40] <jmkasunich> emcmot.c (the file that eventually became motion.c, control.c and command.c) used to have at least a couple hundred lines of history at the beginning
[01:35:57] <cradek> that's insane
[01:36:05] <cradek> does anyone want to know what I think about this? haha
[01:36:39] <jepler> a "couple hundred lines"? That's about the upper bound on the ideal size of a source file.
[01:36:47] <jmkasunich> lol
[01:37:02] <jmkasunich> you never looked at emcmot.c from emc1 did you?
[01:37:07] <jmkasunich> it was 5000+
[01:37:28] <SWPadnos> the nml case statement is 500 lines
[01:37:37] <SWPadnos> (or was that 500 cases? ;) )
[01:37:47] <cradek> I did, and some idiot fixed bugs and ran indent on it at the same time, and I had to find the changes and put them into the 5000+ line COPY called emcsegmot.c
[01:37:55] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[01:38:03] <jmkasunich> fred proctor is an emacs wiz, he like huge files because he can fly around in one file in emacs easier than he can navigate between a lot of little ones
[01:38:30] <jepler> Looks like the biggest source file in soul_crusher.exe is 18641 lines
[01:38:38] <SWPadnos> did you see the "learning curves" image giacus pointed to yesterday? :)
[01:38:43] <jmkasunich> wth is soul crusher
[01:38:45] <jmkasunich> yes
[01:38:45] <jepler> jmkasunich: if he can't navigate among files he's not an emacs wiz
[01:39:01] <jepler> jmkasunich: It's an affectionate name for the app I work on during the day
[01:39:16] <jmkasunich> I didn't say he couldn't, just that it was faster to navigate within one file (for him at least)
[01:39:30] <jepler> SWPadnos: The one with the spiral? that's a hoot.
[01:39:48] <SWPadnos> yeah
[01:39:55] <SWPadnos> I liked the vi one as well ;)
[01:40:18] <cradek> jepler: did you ever see the video? mplayer plays it
[01:40:28] <jmkasunich> it must be a sign of age or something, I no longer like editors that use lots of keyboard shortcuts
[01:40:34] <jepler> cradek: no, I'm still at a windows machine
[01:40:36] <jmkasunich> cause I can't remember them
[01:40:49] <cradek> please let's not talk about editors
[01:40:49] <jepler> SWPadnos: I don't agree with the vi one; I'm still learning new motions
[01:41:10] <jmkasunich> cradek: good idea
[01:41:13] <jepler> cradek: If your editor was worth the bits it's printed on, it could just hide the CVS $Log$
[01:41:23] <jepler> and make the 50000-line files appear to be 100 500-line files if that's what you wanted
[01:41:28] <jepler> bbl
[01:42:12] <cradek> it's diff/patch/cvs up -j that make me think those $$ things suck; I don't mind seeing them, but they get in the way and don't have enough utility to justify it
[01:43:13] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[01:47:12] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[01:50:29] <jmkasunich> * jmkasunich adds some more #if 0 to motion.c and control.c ;-)
[01:51:05] <CIA-4> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build PASSED
[01:53:24] <Jymmm> how come compile farm is doing things over and over and over again?
[01:53:43] <jmkasunich> five different systems each build the software after a change
[01:53:47] <jmkasunich> to make sure it works on all five
[01:54:03] <Jymmm> five different bdi-live's ?
[01:54:10] <jmkasunich> no
[01:54:22] <Jymmm> I saw all those a few hours ago
[01:54:28] <jmkasunich> BDI-2.18, BDI-TNG, BDI-Live, BDI-4.20 and Ubuntu
[01:54:41] <jmkasunich> that was a few hours ago, after someone committed a change
[01:54:44] <Jymmm> Yeah, a few hours ago I saw all those
[01:54:50] <Jymmm> oh, ok.
[01:54:56] <jmkasunich> jepler committed another change just now, so it does it again
[01:55:05] <Jymmm> automagically?
[01:55:10] <jmkasunich> yep
[01:55:21] <Jymmm> k, didnt know that
[01:55:32] <jmkasunich> the idea is that if somebody commits a change that breaks something, we find out soon
[01:55:48] <jmkasunich> we've had the compile farm for a couple years
[01:55:49] <Jymmm> lol, ok, that works =)
[01:55:57] <jmkasunich> but until recently the results went to a webpage only
[01:56:12] <jmkasunich> and most people didn't bother checking the page to see if they broke something
[01:56:32] <Jymmm> makes sense
[02:15:57] <SWPadnos> ok. see you guys later. I may be able to connect tomorrow night, but it'll more likely be Thursday.
[02:16:06] <jmkasunich> ok, have a safe trip
[02:16:09] <SWPadnos> thanks
[02:16:14] <Jymmm> c ya SWPadnos
[02:16:30] <SWPadnos> drive on up to Las Vegas - we can have dinner ;)
[02:16:55] <Jymmm> SWPadnos at the BunnyRanch.com ?
[02:17:16] <SWPadnos> heh
[02:17:20] <SWPadnos> the Tillerman
[02:17:25] <SWPadnos> http://www.tillerman.com/
[02:18:02] <Jymmm> SWPadnos: Man, you know ever place don't ya? =)
[02:18:40] <SWPadnos> food is important to me ;)
[02:18:49] <SWPadnos> good food even more so
[02:19:05] <SWPadnos> anyway. see you guys later
[02:19:12] <jepler> cradek: I got to see the thread-cutting demo. very cool.
[02:20:16] <Jymmm> I just saw the pics... cool idea!
[02:21:23] <jepler> more than a cool idea .. working code in emc2
[02:23:12] <skunkworks> I am excited :)
[02:23:20] <skunkworks> even more.
[02:30:14] <cradek> another pic coming up in a minute
[02:34:39] <cradek> http://timeguy.com/cradek-files/emc/nut-test.jpg
[02:35:28] <skunkworks> Nice :)
[02:35:43] <cradek> jmk said it wasn't right until a nut screws on
[02:36:33] <cradek> the first thread was 1/4-16 which is wrong in a lot of ways :-)
[02:37:23] <cradek> jmkasunich:
http://timeguy.com/cradek-files/emc/nut-test.jpg
[02:38:04] <jmkasunich> is the fit nice? (not wobbly)
[02:38:19] <cradek> yes
[02:38:24] <jmkasunich> cool
[02:38:39] <cradek> I didn't do the math - I just stopped when it looked right and tested the fit
[02:39:03] <jmkasunich> got it right the first time by eye?
[02:39:09] <cradek> I changed the base period to 20 and cut this about three times as fast as the first one
[02:39:17] <cradek> no, it fit on the third test
[02:39:25] <jmkasunich> still not bad
[02:39:32] <jmkasunich> how deep did you go each time
[02:39:38] <cradek> I just paused the program while the tool was retracted, turned off the spindle, and tested the fit
[02:39:50] <cradek> .0005 each pass
[02:40:03] <cradek> I think it could do .001 or even .0015 with the tailstock
[02:40:52] <jmkasunich> infinite loops in realtime code are not good
[02:41:08] <cradek> what are you screwing up?
[02:41:09] <jmkasunich> (thats why I left and rejoined the channel)
[02:41:14] <cradek> err, working on?
[02:41:15] <jmkasunich> homing to index pulse
[02:41:27] <cradek> cool, we need that
[02:42:14] <CIA-4> 03cradek 07HEAD * 10emc2/nc_files/threading.ngc: for 1/4-20
[02:44:07] <CIA-4> 03cradek 07HEAD * 10emc2/configs/nist-lathe/ (.cvsignore inch.ini nist-lathe.hal): new configuration for fred proctor's lathe with threadcutting
[02:45:03] <jmkasunich> I wonder if _all_ the configs should be part of the samples directory?
[02:45:47] <cradek> depends on the purpose of the samples.
[02:46:06] <CIA-4> 03cradek 07HEAD * 10emc2/src/Makefile: new configuration for fred proctor's lathe with threadcutting
[02:46:46] <cradek> seems they have two purposes: running out of the box, and providing an example of varied configurations
[02:47:43] <cradek> * cradek hands jmk a copy of qemu
[02:48:41] <jmkasunich> crapski, did it again
[02:49:35] <cradek> jmkasunich: use qemu?
[02:49:51] <jmkasunich> with realtime?
[02:50:23] <jmkasunich> I think I was just being stupid
[02:50:47] <jmkasunich> fixed the bug in the editor, did a build and tried it, but didn't save the file, so the build didn't get the fix
[02:52:34] <jmkasunich> rebooting a qemu probalby takes just as long as rebooting a regular box anyway
[02:52:48] <jmkasunich> here goes!
[02:53:17] <jmkasunich> no crash!
[02:54:30] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[02:58:04] <skunkworks> cradek: are you using a 60deg cutter from think and tinker?
[02:58:09] <cradek> yes
[02:58:36] <cradek> get the 10-pack, you'll need them :-)
[02:58:45] <skunkworks> :)
[02:58:47] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[02:59:00] <skunkworks> how many have you broken so far?
[03:00:35] <cradek> uhh I dunno
[03:00:52] <cradek> actually usually jepler breaks them
[03:01:01] <skunkworks> :)
[03:02:22] <jepler> G0Z-6
[03:02:28] <jepler> "oops, that was supposed to be G0Z#6"
[03:02:40] <jepler> "I guess I should have looked at the preview plot before I ran it"
[03:03:56] <skunkworks> I had a piece of aluminum that I put on my keychain for a while. did an z move instead of a x move by mistake. imbedded a centering drill into it. looked cool.
[03:04:33] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[03:05:19] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[03:05:40] <skunkworks> it actually sheared the 3/4 aluminum shaft off.
[03:06:23] <skunkworks> wonder if I still have that somewhere
[03:06:33] <skunkworks> was my good luck charm
[03:06:42] <skunkworks> Oh well - time for bed
[03:06:49] <skunkworks> take it easy
[03:11:19] <CIA-4> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build PASSED
[03:14:17] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[03:16:49] <cradek> EOW: end of weekend
[03:17:32] <jmkasunich> bummer ain't it
[03:18:02] <cradek> at least I accomplished some things
[03:18:15] <jmkasunich> wish I had accomplished more
[03:18:26] <cradek> that's always the way it is
[03:18:53] <cradek> I wonder if I shouldn't have posted the link to the video to the users list
[03:19:30] <jmkasunich> tradeoff: signs of progress vs. people who expected to mass produce bolts tomorrow
[03:19:49] <cradek> I mean because of the bandwidth
[03:19:49] <jmkasunich> and immediately start pestering you for details and help
[03:20:01] <jmkasunich> your website
[03:20:19] <cradek> oh well
[03:20:38] <jmkasunich> shame SWP is gone, I bet he wouldn't even notice the bandwidth
[03:20:41] <cradek> it's a small price to pay for drumming up some excitement among the users
[03:21:08] <cradek> I bet it'll be fine.
[03:21:29] <jmkasunich> probably
[03:24:57] <cradek> I haven't heard from Jon E lately - I wonder if he gave up on getting his spindle encoder working
[03:25:36] <jmkasunich> who knows
[03:26:32] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[03:26:51] <jmkasunich> shame the compile farm isn't smart enough to skip compiles when all you changed is a config
[03:27:20] <cradek> it doesn't have anything better to do...
[03:28:14] <jmkasunich> I'm really having a hard time wrapping my mind around this homing stuff
[03:28:30] <jmkasunich> there are various offsets that need to be added here, subtracted there, etc
[03:29:45] <cradek> yuck, sounds fiddly
[03:30:08] <jmkasunich> the main problem is that I tried to break out the differnet functional blocks
[03:30:24] <jmkasunich> so following errors are detected pretty early, while processing inputs
[03:30:29] <jmkasunich> homing is quite a bit latre
[03:30:32] <jmkasunich> later
[03:30:55] <fenn> so no more commit logs? just build tests?
[03:30:58] <fenn> from cia
[03:31:13] <fenn> er, oh it just takes a while
[03:31:19] <cradek> there are commit logs too, but they're long forgotten by the time the builds finish
[03:31:20] <jmkasunich> so when the index pulse resets the encoder, the ferror logic trips, even tho later on the homing logic is gonna correct for it
[03:31:49] <jmkasunich> the fastest build is the ubuntu, which is on this box (and not running right now, since I rebooted earlier)
[03:31:56] <jmkasunich> the rest take 10-30 mins
[03:32:15] <jmkasunich> anyway back to homing....
[03:32:38] <jmkasunich> I really don't want to have to put special code in the input processing to deal with the encoder reset
[03:32:42] <jmkasunich> but I guess I have to
[03:32:52] <jmkasunich> thats why I didn't originally do homing this way
[03:33:16] <fenn> you could have it as part of the "encoder" module
[03:33:42] <jmkasunich> how
[03:34:07] <fenn> only for software encodres
[03:34:19] <jmkasunich> how
[03:34:40] <fenn> what i'm getting at is the "stanard canonical interface" has to have the home offset
[03:34:52] <jmkasunich> for one thing, the only reason for this whole excercise is so that all encoders act the same
[03:35:19] <fenn> right
[03:35:30] <jmkasunich> there are only two possibilities
[03:35:59] <jmkasunich> either the signal from the encoder to the motion controller makes a step change when you hit the index, or it doesn't
[03:36:25] <jmkasunich> if it does, I have to avoid a following error
[03:36:37] <jmkasunich> if it doesn't, then its impossible to home on index
[03:36:50] <fenn> i think motion needs a index_offset pin maybe?
[03:36:57] <fenn> erf thats icky nevermind
[03:37:21] <fenn> does homing work at all in hal?
[03:37:28] <fenn> or is it all higher level stuff?
[03:37:35] <jmkasunich> signals pass thru hal
[03:37:42] <jmkasunich> but the homing logic is in the motion controller
[03:37:49] <jmkasunich> homing to switches works fine
[03:39:29] <fenn> i think you need an extra signal with the encoder offset
[03:39:41] <fenn> encoder.0.home_offset or something
[03:39:42] <jmkasunich> 1) icky
[03:40:10] <jmkasunich> 2) it doesn't matter whether the encoder signal to emc changes from <wherever> to zero, or from <wherever> to <home_offset>
[03:40:14] <jmkasunich> its still a step change
[03:40:43] <fenn> wouldnt it be treated just like a g54 inside emc?
[03:41:02] <jmkasunich> what I'm working on is way below G54
[03:41:09] <fenn> absolute position in encoder counts wouldnt need to change
[03:41:16] <jmkasunich> the motion controller never sees G54 offsets
[03:41:35] <jmkasunich> what you are describing is more-or-less the way it works today
[03:41:51] <jmkasunich> except there is no icky encoder-offset signal going to the encoder
[03:42:00] <jmkasunich> the encoder position never changes
[03:42:05] <fenn> no the encoder_offset comes _from_ the encoder
[03:42:32] <jmkasunich> an offset is subtracted from the feedback and added to the command, so the internal postions are correct even if the encoder isn't
[03:42:33] <fenn> index and homing go in one side, offset comes out the other
[03:42:56] <jmkasunich> what exactly is the meaning of the offset signal?
[03:43:02] <jmkasunich> when does it change?
[03:43:10] <fenn> the number of encoder pulses from the index pulse
[03:43:29] <jmkasunich> that means nothing to me
[03:43:51] <fenn> pretend you interrupt on INDEX and set home_offset to zero
[03:44:39] <jmkasunich> I don't understand what you are saying
[03:44:44] <fenn> during the homing routine
[03:44:57] <jmkasunich> there is one value coming out of the encoder that changes as the encoder turns
[03:45:20] <jmkasunich> is this new value that comes out a constant except when you hit the index, or does it also change as the encoder turns?
[03:45:26] <fenn> hardware encoder counters have a home_offset register dont they?
[03:45:42] <jmkasunich> hardware encoder counters are not all the same
[03:45:59] <jmkasunich> there are two aspects to this problem:
[03:46:04] <jmkasunich> 1) define the encoder interface
[03:46:15] <jmkasunich> 2) make sure all encoder counters can implement it
[03:46:26] <jmkasunich> don't worry about 2 until you manage to communicate 1 to me
[03:46:40] <jmkasunich> because so far you haven't come close
[03:46:45] <fenn> heh
[03:47:09] <fenn> ok forget setting home_offset to zero
[03:47:46] <fenn> when homing, wait for the index pulse and store the current encoder count in some register/signal
[03:48:05] <fenn> that way you dont have to touch that register except when doing homing
[03:48:24] <jmkasunich> is that register part of the encoder driver or part of the motion controller?
[03:48:26] <fenn> then to get absolute position, subtract the home_offset from the raw encoder count
[03:48:52] <fenn> it will have to be flexible to allow for both types of encoder counter hardware
[03:49:01] <jmkasunich> is that register part of the encoder driver or part of the motion controller?
[03:49:20] <fenn> you could do it in hal encoder module or you could get the value from hardware
[03:49:31] <jmkasunich> so part of the encoder driver
[03:49:43] <jmkasunich> ?
[03:49:54] <fenn> i dont know how much is implemented in hardware
[03:50:02] <jmkasunich> arrrrg
[03:50:04] <fenn> like jon e's stuff i thought actually had a home_offset register
[03:50:09] <fenn> in the fpga
[03:50:16] <jmkasunich> I don't give a flying fsck what is implemented in the hardware
[03:50:41] <jmkasunich> "encoder driver" = the thing that HAL sees as an encoder
[03:50:56] <jmkasunich> it doesn't matter whether its all software, or hardware with a driver
[03:51:11] <fenn> can you always do homing in software? is it fast enough to catch index and not miss any counts between when index trips and hal notices?
[03:51:24] <jmkasunich> wrong question
[03:51:48] <jmkasunich> you can always do homing in software IF you run the final phase of homing slow enough
[03:52:04] <jmkasunich> "slow enough" = less than one count per servo period
[03:52:09] <fenn> "how slow can you go"
[03:52:29] <fenn> * fenn dances
[03:53:18] <jmkasunich> a year ago I implemented homing entirely inside the motion controller, no funky extra offset signals between the motion controller and the encoder driver
[03:53:33] <jmkasunich> but it has that limitation - max speed = one count per servo period
[03:53:51] <jmkasunich> hardware counters (and even the software based counter) can go much faster
[03:54:04] <jmkasunich> so I want to re-do homing to make that work
[03:54:04] <fenn> so you'd rather run it in a fast thread in hal?
[03:54:20] <jmkasunich> no, I want to take advantage of hardware latches
[03:54:42] <jmkasunich> the software encoder counter _acts like_ it has a hardware latch
[03:54:57] <jmkasunich> the latching and counting code runs in a fast thread, but that is irrelevant to emc
[03:55:18] <jmkasunich> doesn't matter, hardware latch or latch code in a fast thread, its just an encoder driver either way
[03:55:59] <fenn> ok so hal "encoder" component can have extra stuff hanging off the hardware end that you wouldnt find in a hardware encoder counter driver
[03:56:19] <jmkasunich> I have no idea what you are talking about
[03:56:26] <fenn> sorry, long day
[03:56:39] <jmkasunich> there is a software based HAL encoder counter component
[03:56:51] <jmkasunich> it has three HAL pins on the "outside", A, B, Z
[03:57:17] <jmkasunich> and a couple HAL pins on the "inside", position and index-enable
[03:57:23] <fenn> ok
[03:57:33] <jmkasunich> there are also drivers for hardware based encoder counters
[03:57:38] <jmkasunich> right now they're a mess
[03:58:00] <jmkasunich> but when fixed, each one of them will have no HAL pins on the outside, they have real hardware connections for the encoder
[03:58:14] <fenn> index-enable simply resets position to zero on index, right?
[03:58:19] <jmkasunich> on the inside, they will have exactly the same pins that the software counter does
[03:58:28] <jmkasunich> yes, exactly
[03:58:50] <jmkasunich> its bidirectional - emc sets it to 1 to tell the encoder driver "reset to zero on next index"
[03:59:11] <fenn> ooo
[03:59:15] <jmkasunich> and when the index arrives, the driver sets the pin to zero to tell EMC "index arrived, counter was reset"
[04:00:18] <fenn> are there a lot of bidirectional pins in hal?
[04:00:23] <jmkasunich> no
[04:00:29] <jmkasunich> right now I think that is the only one
[04:00:30] <fenn> just parport and.. ?
[04:00:35] <fenn> is parport bidir?
[04:00:39] <jmkasunich> no
[04:00:56] <jmkasunich> at loadrt time you specify whether you want the data port (8 bits) to be in or out
[04:01:02] <fenn> the hal user interface could be simplified if there werent any bidirectional pins
[04:01:30] <jmkasunich> there are some things (like index-enable) that are much nicer with bidirectional pins
[04:01:44] <fenn> what's wrong with on-index?
[04:01:45] <jmkasunich> anything that involves handshaking really
[04:02:10] <jmkasunich> you mean one pin going each way?
[04:02:10] <fenn> i wouldnt expect index-enable to go low on index
[04:02:13] <fenn> yes
[04:02:22] <jmkasunich> ok, follow me here.....
[04:02:36] <jmkasunich> index-enable goes true, telling the encoder "reset on next index"
[04:02:40] <jmkasunich> index arrives
[04:02:57] <fenn> ah your thread might miss it
[04:02:57] <jmkasunich> encoder's "got-index" goes true, telling emc "got one"
[04:03:11] <jmkasunich> it would _have_ to be latched
[04:03:27] <jmkasunich> if its latched, how do you reset the latch?
[04:03:58] <jmkasunich> emc would have to say "I see that you got a latch, so I'm gonna take index-enable false to tell you I saw "got-index"
[04:04:08] <jmkasunich> then then encoder would set got-index low
[04:04:25] <jmkasunich> and finally emc could set index-enable high again if it wants to latch on the next input
[04:05:16] <jmkasunich> its really just a matter of two wire handshaking vs. one wire handshaking
[04:05:38] <jmkasunich> if getting rid of bidirectional signals was really important, we could go to two wire
[04:05:46] <jmkasunich> just more things to hook up
[04:06:10] <jmkasunich> there is another application of bidirectional signals thats not so easy to replace
[04:06:28] <jmkasunich> "open collector" type signals
[04:06:52] <jmkasunich> imagine several modules, any of which might detect a fault condition that requires shutting all of them down
[04:07:14] <fenn> cant you do that with a mux?
[04:07:34] <jmkasunich> if each has a unidirectional fault output, all of those outputs need to go to a big OR gate, so a fault on any one will set the master fault signal, which then goes to all the modules
[04:08:00] <jmkasunich> but with bidirectional signals, everybody reads the signal, and anybody can set it TRUE (faulted)
[04:08:04] <jmkasunich> one signal, done
[04:08:11] <fenn> ok
[04:08:32] <fenn> * fenn wishes writing code didnt take so long
[04:08:47] <jmkasunich> what are you writing?
[04:09:08] <fenn> i'm not, too many projects already
[04:09:14] <jmkasunich> oh
[04:09:22] <fenn> was thinking "oh i wish there were a good hal gui"
[04:09:28] <jmkasunich> oh
[04:09:33] <jmkasunich> so do I
[04:10:12] <fenn> the mazak sample config is hard to decipher if you dont already know what everything does (and maybe even then)
[04:11:01] <jmkasunich> I tried to put a lot of comments in the hal file, but sometimes a picture (wiring diagram or schematic) is worth 1000 words or more
[04:11:17] <jmkasunich> same with ladder logic
[04:11:23] <fenn> the stuff going into classicladder is hard to follow
[04:11:39] <jmkasunich> you really need to see the ladder
[04:11:56] <jmkasunich> unfortunatley the .clp file format is pretty obscure
[04:12:11] <jmkasunich> its not binary, but it might as well be as far as readability goes
[04:12:35] <jmkasunich> someday I'd like to attack the cl gui
[04:12:52] <fenn> could you explain (again) why a non-rt hal would be too hard?
[04:12:55] <jmkasunich> for one thing, add a command that saves ascii art ladders
[04:13:05] <jmkasunich> no
[04:13:18] <fenn> aside from its potential for abuse, it would be good to be able to run all these things without needing an rt environment
[04:13:36] <jmkasunich> a hal that runs without a RT kernel is on my to-do list
[04:13:50] <fenn> oh cool
[04:14:00] <jmkasunich> but it involves some complex shit that I just haven't had time to focus on
[04:14:09] <jmkasunich> I probably need to go into hermit mode to do that
[04:14:44] <jmkasunich> I need to go into hermit mode right now if I expect to get anything done, its already past midnight
[04:14:52] <fenn> heh ok
[04:15:03] <fenn> i'll work on the hexapod some more
[04:17:15] <Jymmm> fenn work on mine too while you're at it
[05:42:39] <CIA-4> 03jmkasunich 07HEAD * 10emc2/src/hal/components/sim_encoder.c: fix stupid off-by-one error
[05:42:56] <CIA-4> 03jmkasunich 07HEAD * 10emc2/configs/sim/ (servo_sim.hal servo_sim.ini): Homing to an index pulse now works for the software based encoder (which uses the canonical encoder interface). Other encoder drivers need to be modified to use the same interface
[05:42:58] <CIA-4> 03jmkasunich 07HEAD * 10emc2/src/emc/motion/ (control.c mot_priv.h motion.c motion.h): Homing to an index pulse now works for the software based encoder (which uses the canonical encoder interface). Other encoder drivers need to be modified to use the same interface
[05:45:27] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED
[05:53:39] <CIA-4> 03jmkasunich 07v2_0_branch * 10emc2/src/hal/components/sim_encoder.c: fix stupid off-by-one error
[05:56:31] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[05:57:42] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10v2_0_branch/: build PASSED
[06:00:43] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[06:07:08] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10v2_0_branch/: build PASSED
[06:08:55] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[06:11:37] <CIA-4> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build PASSED
[06:15:39] <CIA-4> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10v2_0_branch/: build PASSED
[06:30:32] <CIA-4> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10v2_0_branch/: build PASSED
[06:37:12] <CIA-4> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10v2_0_branch/: build PASSED
[08:56:29] <Bo^Dick> does anyone know how to build a 3-bit synchronous counter that can count in both directions?
[11:50:06] <jepler> here's the first link google gave me>
http://www.eelab.usyd.edu.au/digital_tutorial/part2/counter07.html
[11:50:58] <jepler> (I searched for 'up-down counter')
[11:55:53] <jepler> also, I haven't read the datasheet or investigated price/availability, but there are 4-bit up-down counters in DIPs:
http://focus.ti.com/docs/prod/folders/print/cd74hc193.html
[12:05:13] <Jymmm> Jymmm has changed the topic to: "Welcome to the Enhanced Machine Control forum - Support and development of a linux based CNC control. | Home: linuxcnc.org | Regular Developers' meetings Sundays 14:00-18:00 GMT | wiki up @
http://wiki.linuxcnc.org | EMC usage map:
http://www.frappr.com/emctheenhancedmachinecontroller || Live Eagle Nest Cam
http://www.infotecbusinesssystems.com/wildlife/
[12:18:39] <Jymmm> mornin rayh
[12:19:55] <rayh> hey Jymmm
[12:23:37] <Jymmm> so whats happening in your neck of the woods?
[12:33:07] <Bo^Dick> jepler: thx
[12:33:57] <Bo^Dick> this counter was a little bit better than mine since all gates updated in the same instant
[12:40:53] <Jymmm> whats the difference between acetal and nylon?
[12:42:20] <Jymmm> (besides the price)
[12:46:47] <approx> acetal is easy to machine
[12:47:00] <approx> i think it is also more rigid
[12:49:15] <Bo^Dick> what's the difference between "pulse triggered" and "edge triggered" flip-flops?
[12:50:28] <Jymmm> The term pulse-triggered means that data are entered into the flip-flop on the rising edge of the clock pulse, but the output does not reflect the input state until the falling edge of the clock pulse.
[12:51:58] <Bo^Dick> aaah. this explains why my counter didn't react properly when i used a 50% duty cycle clock pulse. the little sucker was pulse triggered!
[12:53:29] <Jymmm> http://www.eelab.usyd.edu.au/digital_tutorial/part2/flip-flop03.html
[14:18:08] <SkunkWorks> logger_aj: bookmark
[14:18:08] <SkunkWorks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-04-24#T14-18-08
[14:56:18] <websys> Ray - are you out there?
[16:46:12] <tomp> hello all
[16:46:23] <bill20r3> Hello.
[16:46:40] <tomp> RayH you around?
[16:57:13] <Lerneaen_Hydra> cradek: In the mailing list you wrote about the new lathe capabilities, what type of rotational encoder is required to get a good thread from a single point cutter tool (the type used in your images)?
[16:57:40] <Lerneaen_Hydra> cradek: Also, was that video from your mill running as a lathe (material in spindle, tool fixed to table)?
[17:00:37] <Lerneaen_Hydra> cradek: Err.. now that I look at that video again I can see that it was in a real lathe (must have been a picture someone showed earlier when you ran the mill as a lathe).
[17:35:49] <giacus> hello
[17:43:49] <giacus`> mm
[17:44:43] <giacus`> * giacus` thanks k4ts xp pc for crashing :/
[17:45:00] <giacus`> giacus: hello
[17:58:57] <giacus`> giacus` is now known as giacus
[18:03:51] <cradek> yes I set up my mill as a lathe earlier, but the results were not very good; this is a real lathe
[18:04:18] <cradek> you need an encoder on the spindle that gives position output and an index pulse.
[18:05:09] <giacus> hi cradek , nice, I was looking at image url in the ML
[18:05:57] <giacus> I've to install some codec for the video ..
[18:05:59] <cradek> thanks giacus
[18:06:10] <giacus> good job
[18:06:19] <cradek> I think the video is not a good format, but it's all I can get with my camera
[18:07:51] <giacus> the format could ok, I don't have codecs installed on my laptop instead .. installing mplayer now
[18:08:05] <cradek> mplayer does play it
[18:08:12] <giacus> xine ?
[18:08:16] <cradek> but the sound is not well synchronized
[18:08:21] <cradek> I don't have xine
[18:08:21] <giacus> oh, ok
[18:08:43] <giacus> right now I tried xine ut doesn't have codecs for that
[18:09:00] <giacus> best thing seems be to switch to mplayer ;)
[18:14:01] <sed_> anyone know a place to find 20TPI lead screws, I cant belive how hard they are to find in sizes 1/2" and up.
[18:14:38] <cradek> are you sure you want such a fine thread?
[18:19:56] <giacus> cradek: cool video too, and the lathe work fast :P
[18:20:05] <sed_> cradek just to convert a lathe to .050 on the cross slide
[18:20:22] <cradek> giacus: I cut the next thread (1/4-20) about three times as fast
[18:20:29] <giacus> cool
[18:21:20] <cradek> sed_: are you replacing 16tpi screws? I've never used one of those but I bet they're a huge pain
[18:21:27] <sed_> I need a 9/16 or 5/8 20TPI screw..
[18:21:41] <rayh> chris, have you ever tried to make a second cd for ubuntu with the rt kernel and emc on it?
[18:21:43] <sed_> I am replacing a 10TPI
[18:22:10] <cradek> rayh: you mean a cd of the whole emc2 repository? no but I don't think it's hard
[18:23:01] <rayh> Right. I've got a fellow who can't get web to his machine but wants emc2.
[18:23:30] <cradek> I had planned on doing this so we can hand it out at the workshop - will he be there?
[18:24:07] <cradek> alternatively, I guess he could take his machine to the web
[18:25:32] <cradek> I think the procedure would simply be 'apt-cdrom add' and then 'apt-get install emc2'
[18:27:39] <rayh> No, he is in Oregon.
[18:28:13] <rayh> The box is attached to the mill.
[18:28:36] <cradek> I understand
[18:28:51] <rayh> Qwest, his isp says that if he tries to hook up a linux box they will castrate him.
[18:29:18] <rayh> I've got a clean ubuntu install here I can try it on.
[18:29:33] <rayh> I just pick up all of your emc2 directory?
[18:29:48] <cradek> you have a CD burner?
[18:30:07] <cradek> I'm trying to find information on the web about how to do this
[18:30:47] <jepler> rayh: wow, I've never heard of that, at least not in modern times. No competitive DSL provider?
[18:31:28] <cradek> they obviously have no competition in the area if they talk to a customer like that.
[18:31:32] <jepler> this qwest help document even says how to change your DNS server on Linux.
http://my.qwest.net/nav4/help/your_acct/dns_service.html
[18:31:35] <rayh> Yes I've got a cd burner.
[18:32:04] <cradek> rayh: I doubt you can reasonably download the whole repository; it's probably over 150MB
[18:32:10] <rayh> Okay. Let me send that link. Thanks.
[18:32:35] <rayh> Oh. I was thinking of your breezy deb stuff.
[18:32:53] <cradek> sounds like his first mistake was talking to his isp about it. whoever was on level 1 tech support that day was probably an idiot
[18:33:07] <jepler> cradek: the repository contains stuff like old package versions?
[18:33:13] <cradek> jepler: yes
[18:33:44] <cradek> so you can downgrade for instance with apt-get install emc2=TESTING-2006-03-12
[18:34:33] <cradek> google doesn't want to tell me the structure needed on the cd
[18:36:33] <cradek> I think I'd first try putting packages-i386.db and dists/ in the cd root
[18:36:36] <jepler> surely the structure is the same as the apt repository
[18:37:06] <cradek> well that was pretty much all guesswork too, it's not well documented
[18:37:25] <cradek> the whole repository is currently 200MB
[18:37:37] <rayh> Okay.
[18:37:52] <cradek> we would NOT have to put all of it on the cd but I have to regenerate the signed indexes if anything is left out.
[18:38:59] <rayh> Might be easier for me to just make a directory on the cd and ask him to run the commands needed to make it a local repository.
[18:39:42] <cradek> you could put just the appropriate debs on the CD, and he could install them with dpkg, but it won't be as nice
[18:40:13] <cradek> after we make our release (soon I hope) I'll work on these CDs.
[18:40:23] <rayh> I've done the local file repository several times and it does allow for apt_get.
[18:40:48] <cradek> ok, I haven't done that
[18:41:42] <rayh> The apt handbook has a section that tells how.
[18:42:13] <jepler> cradek:
https://wiki.ubuntu.com/PackageCDs?highlight=%28apt-cdrom%29 ?
[18:42:28] <alex_joni_away> alex_joni_away is now known as alex_joni
[18:42:44] <rayh> Hi alex.
[18:42:57] <alex_joni> hi ray
[18:43:00] <alex_joni> brb
[18:43:16] <cradek> jepler: but source??
[18:43:45] <cradek> the apt-cdrom manpage seems to say it's flexible and figures out what's on the cd somehow
[18:44:03] <rayh> oh. That's even easier, thanks Jeff.
[18:44:36] <jepler> cradek: there's a dpkg-scansources
[18:44:37] <rayh> the scan packages command builds a package.gz file that is readable by apt.
[18:48:22] <alex_joni> hello guys
[18:48:26] <alex_joni> * alex_joni just got home..
[18:58:02] <rayh> darn 253 meg in /var/cache/apt Not bad for a dialup.
[19:00:24] <giacus> rayh: 1 tera would be nice :P
[19:01:22] <giacus> is it a 56K dialup connection ?
[19:02:14] <rayh> It's 2.2k on a good day.
[19:02:20] <giacus> gulp
[19:02:35] <giacus> cellphone should be nice
[19:03:03] <giacus> if there's a edge or umts bridge there around
[19:03:47] <giacus> my cousin was having the same issue
[19:03:47] <rayh> Last guy here with one got 1/3 bar.
[19:04:13] <giacus> he tried a sat onnection and sayd was veri limited sufrin the web
[19:04:19] <giacus> surfing*
[19:04:48] <giacus> also a bit faster only in downloa, upload is alway via line phone :(
[19:04:49] <rayh> Yep I've heard that and I vnc quite a bit so 1 second turn around would be hell with typing.
[19:07:14] <giacus> xvncviewer have a -bg option to switch to low colours mode
[19:07:37] <giacus> but yes, I also had lot of issues with anna using vnc
[19:07:52] <giacus> with 256 dsl bandwith
[19:09:25] <giacus> ssh was working pretty well
[19:11:15] <giacus> what I never understood are the various 'web accellerators'
[19:11:42] <giacus> if are cache-based only, I can't see any real advantages as they sayd
[19:11:49] <giacus> 6X 8X
[19:11:54] <alex_joni> no, most do compression too
[19:12:11] <Lerneaen_Hydra> they don't work too well, some try to disable things like QoS to get a 10% speed boost at the expense of poor prioritizing
[19:12:34] <giacus> alex_joni: it should be done by the ISP ?
[19:12:49] <giacus> the compression
[19:12:59] <alex_joni> giacus: some install a proxy..
[19:16:30] <lilo> [Global Notice] Hi all. Just a reminder. Google's Summer of Code (
http://code.google.com/soc/ ) is coming up again, and the mentoring organizations have pretty much all been selected. Coder applications start on May 1.
[19:17:13] <giacus> rayh: btw, I'also registering that speed for deb mirrors are turning around a bit
[19:17:31] <giacus> I always check with apt-spy for fast mirrors ..
[19:17:38] <rayh> Okay.
[19:17:41] <lilo> [Global Notice] Soc has moved to SlashNet this year, but it seemed to be a good idea to have an unofficial, local channel here on freenode for mentoring groups and participants.... so we've set up ##googlesummer .... if you're involved, or hoping to be involved, with Soc 2006, please stop by. As always, be nice, be chilled, and have a great evening! :)
[19:18:58] <Lerneaen_Hydra> speed going up or down? and what speed?
[19:20:27] <giacus> weird, sometime I found the mirrors near (.it) to me are very slow
[19:20:45] <giacus> when a swiss mirror result 2x faster
[19:20:56] <Lerneaen_Hydra> cradek: how many holes/turn on the encoder, and would it be possible to take an encoder and rig a fork with it (led and phototransistor), and then attach that to the parport input (using 1 input pin, with 1 pulse being 1/x th turn, with X holes)
[19:21:26] <alex_joni> Lerneaen_Hydra: you need a index pulse for threading too
[19:21:41] <alex_joni> so you need one slot with only one hole / turn
[19:21:54] <cradek> Lerneaen_Hydra: for a small lathe it seems like about 400 pulses per revolution is right for software counting, but you should do the math yourself depending on your machine and what you want to do
[19:21:57] <alex_joni> in addition to the 2-500 pulses/turn
[19:22:10] <cradek> Lerneaen_Hydra: the issue is that you can not have more than one count per base period
[19:22:47] <cradek> I don't know why someone would bother trying to make a pseudo-encoder when encoders are not expensive and work so well
[19:22:49] <Lerneaen_Hydra> as long as you have a relatively low RPM though it should work...
[19:22:58] <Lerneaen_Hydra> are they available for cheap?
[19:23:30] <Lerneaen_Hydra> those encoders are optical too though, right?
[19:23:36] <cradek> the new encoder I bought was $65 which doesn't seem very cheap to me, but I'm sure you could find used for cheaper
[19:23:36] <giacus> US digital are cheap for what I know
[19:24:22] <alex_joni> cradek: you can get very cheap (<10$) 200 cpr mechanical encoders
[19:24:43] <cradek> 200 count = 800 pulse? that would be fine
[19:24:51] <cradek> with index?
[19:25:05] <Lerneaen_Hydra> why do you need an index?
[19:25:17] <cradek> so the multiple passes start at the same place
[19:25:33] <alex_joni> cradek: think those aren't with index.. but they are good for other purposes
[19:25:45] <Lerneaen_Hydra> oh, does emc stop counting when it's done with the thread cycle?
[19:26:07] <cradek> with software counting I wouldn't want to trust it to always keep up
[19:26:25] <cradek> since a higher spindle speed, like you use for regular turning, will make it lose count
[19:27:26] <Lerneaen_Hydra> does emc currently compensate for an uneven spindle speed?
[19:27:51] <Lerneaen_Hydra> uneven over only a few turns, becuase of a belt-drive for instance
[19:27:52] <cradek> yes very well
[19:28:27] <cradek> you can start a thread cycle with the spindle stopped and turn it by hand and the axis tracks as if they were geared together mechanically
[19:28:44] <Lerneaen_Hydra> are the settings for thread turning well integrated into the .ini files? (in the head version of course)
[19:28:51] <Lerneaen_Hydra> that must look quite neat
[19:29:01] <cradek> the configuration is done in hal
[19:29:21] <cradek> yes it's very fun to play with
[19:30:20] <Lerneaen_Hydra> will the settings be ported to the .ini's by the time it's reached.. uh.. middle semi-beta state, except with the debian name.. stability?
[19:30:47] <cradek> I don't understand what you mean
[19:32:46] <Lerneaen_Hydra> at the moment you said that settings for the thread currint were done in hal, which seems slightly cumbersome compared to changing values in an .ini file such as pulses/turn and so on. will things like that be moved to an .ini file by that time that lathe specific code has reached a stable state?
[19:32:57] <jepler> why?
[19:33:11] <cradek> the only configuration necessary is connection of your spindle encoder to the appropriate hal pins, along with your encoder scale
[19:33:49] <cradek> you could use a substitution to allow specification of the scale in the ini, but I don't see the point really, this is hardware abstraction, exactly what hal is for
[19:34:03] <jepler> it will always be hal that configures the pins
[19:34:17] <cradek> right, that's its purpose
[19:34:27] <jepler> and if you want you can use the 'setp ... [SECTION]KEY' format to set the encoder scale
[19:34:36] <Lerneaen_Hydra> what I was thinking of was how the common end-user will configure settings like that, inputting values like that into the halcmd seems cumbersome
[19:34:51] <jepler> that's a basic feature of halcmd, and it doesn't have to be specifically enabled when a new parameter is added
[19:35:44] <cradek> unlike step/dir which is fairly standard, encoder hookups will be different, and the integrator will have to understand what he's doing a little, otherwise he should buy a turnkey system of some kind (for instance maybe sherline will do this).
[19:36:15] <Lerneaen_Hydra> oh, ok. so it's easy for an end-user to configure the settings to get it to work? (same difficulty as maybe changing which output/input pins go where and the stepper scale and so on)
[19:36:26] <cradek> yes, same
[19:54:07] <giacus> what the max freq. HAL encoder can work ?
[19:54:23] <giacus> few khz ?
[19:55:15] <giacus> around 10 maybe ?
[19:57:46] <Lerneaen_Hydra> I beleive it depends on your base period
[19:57:58] <Lerneaen_Hydra> if HAL encoder is that I think it is
[19:58:03] <giacus> yes, I read the description..
[19:58:31] <jepler> giacus: If the signal is perfectly clean, then emc will handle one "edge" per BASE_PERIOD
[19:59:06] <jepler> e.g., edges at 50kHz if your BASE_PERIOD is 20 microseconds
[19:59:52] <giacus> it should be fast compared to a standard uC ?
[20:01:32] <giacus> time ago I was evalutating to use HAL encoder component for some application
[20:02:33] <giacus> can't recall at all, but alex_joni sayd do not expect a very fast result
[20:02:55] <giacus> I wonder the limit what depend on
[20:03:01] <jepler> it depends what else the microcontroller will do. My guess was that in the absence of interrupts, a 16MHz AVR could poll a quadrature signal and increment/decrement an internal counter at at least 500kHz.
[20:03:11] <giacus> if only on base period / cpu
[20:03:23] <giacus> what's the brake
[20:03:24] <jepler> but what do you want to do with the quadrature signal after yo ucount it?
[20:03:35] <giacus> yeah
[20:04:08] <giacus> using the encoder compent in a real work for a fast machine
[20:04:30] <giacus> where's the brake ? or what it depend on ?
[20:04:41] <giacus> I know the base period
[20:04:46] <jepler> I don't understand what you mean about "the brake"?
[20:05:28] <giacus> for what I know, HAL encoder component is slow for a real work
[20:05:33] <giacus> is that true ?
[20:05:46] <giacus> also with a faster cpu and lowest period
[20:06:16] <jepler> brb
[20:06:17] <jepler> work
[20:06:26] <giacus> haha
[20:06:27] <giacus> ok
[20:06:52] <giacus> let's try to remake the question:
[20:07:20] <giacus> who tried the encoder component in emc2 with a very fast machine ?
[20:07:30] <giacus> using servo system drivers
[20:07:35] <alex_joni> giacus: a very fast machine can have low encoder counts
[20:07:41] <alex_joni> if you don't need much precision
[20:07:57] <alex_joni> and you can have a very slow machine with very high encoder counts, for umeter work
[20:08:21] <giacus> yeah.. I also know abou step multiplier, I bought geckos
[20:10:07] <giacus> i'm not much familiar with electronics and digitals components
[20:10:44] <giacus> but I know in a standalone system there's a digital counter circuit do that
[20:11:08] <giacus> speed also depend on IC freq.
[20:11:50] <alex_joni> LS7266 & the like
[20:11:59] <alex_joni> modern IC's like that go up to a few MHz counting rate
[20:12:03] <giacus> I also know HAL components are virtual components
[20:12:07] <alex_joni> something parport will never acheive
[20:12:16] <giacus> theyr speed depend on base period, cpu etc
[20:12:47] <Lerneaen_Hydra> what is the maximum frequency for the parport?
[20:13:29] <alex_joni> Lerneaen_Hydra: depends on the CPU
[20:13:43] <alex_joni> but usually around 50-80 kHz
[20:13:44] <Lerneaen_Hydra> is there no hardware limitation for just the parport?
[20:14:06] <alex_joni> the parport is connected to ISA, and an read/write takes about 1 usec
[20:14:07] <Lerneaen_Hydra> wasn't it limited to something like 2.1mbit/s
[20:14:14] <alex_joni> that's throughput
[20:14:29] <Lerneaen_Hydra> shouldn't 1/throughput give you pulses/time?
[20:14:37] <alex_joni> yes and no..
[20:14:54] <Lerneaen_Hydra> yes and no?
[20:15:08] <alex_joni> some ports have high throughput but very bad latency
[20:15:20] <Lerneaen_Hydra> oh, ok
[20:15:25] <Lerneaen_Hydra> then I get what ypu're getting at
[20:15:33] <alex_joni> for example USB
[20:15:54] <alex_joni> high data transfer rate, very bad latency
[20:16:01] <alex_joni> because it works with packets
[20:16:11] <alex_joni> and you have large packets with a small packet rate
[20:16:13] <Lerneaen_Hydra> yes, which one can see when comparing the max throughput (480mbits/s) and the one that one sees in reality (200mbit/s)
[20:16:24] <Lerneaen_Hydra> (or something like 200)
[20:16:36] <alex_joni> and you need only 1 packet to change a state (or check a state)
[20:17:03] <Lerneaen_Hydra> ok
[20:17:45] <alex_joni> so it doesn't really make any sense to compare rate with throughput.. at least when compared with emc and what you need
[20:20:02] <Lerneaen_Hydra> ok
[20:21:24] <giacus> alex_joni: do you remember the video I sent time ago abou the small droid I'm building ?
[20:21:47] <giacus> someone did a nice hack on head gearbox :
http://xoomer.virgilio.it/pa_go_pa/Pagine/dagli%20amici/filmati/Video%201X-1.avi
[20:22:05] <giacus> very fast ! seems human
[20:22:07] <alex_joni> nice
[20:23:13] <giacus> it could have some problem with the camera .. we'll test it when the droid will be completed
[20:23:48] <fenn> um, what's different about it?
[20:24:06] <jepler> giacus: One possibility is to build a quadrature divide-by-4 (or more) from common components and still use emc's encoder component to read the divided quadrature signal. Last week cradek and I talked about such an approach, before he knew for sure the details of the lathe spindle encoder.
[20:24:22] <giacus> about 6 seconds to turn the head from left to right
[20:24:44] <giacus> take a look to the video instead, after ..
[20:25:36] <giacus> I've to upload my video, but I cant, right now I'm away from house
[20:25:43] <giacus> the mine is very slow ..
[20:26:09] <giacus> jepler: nice, I hope to find the time to try it later
[20:26:19] <giacus> i'm interisting on it
[20:26:26] <giacus> interested
[20:30:24] <giacus> http://img83.imageshack.us/img83/5444/img000912ll.jpg
[20:31:16] <jepler> giacus: the basic concept is that if you hook a quadrature signal to an up/down counter as "clock" and "direction", the output signal changes in the same direction but at 1/4 the rate. To convert binary 00 .. 01 .. 10 .. 11 output to quadrature, a single extra gate (I think it was XOR) is needed. So selecting the 1s and 2s output you get quadrature-divided-by-4. Selecting the 2s and 4s output you get quadrature-divided-by-8. This is untested,
[20:32:28] <giacus> jepler: thanks, excellent explanation :)
[20:32:52] <giacus> I'll try to play with it a bit when I'll came back to home
[20:36:14] <jepler> giacus: if you have success (or failure) let me know
[20:36:25] <giacus> sure, thanks
[20:44:41] <Lerneaen_Hydra> jepler: I don't recall at the moment, but does axis show g0 and g1 in the preview pane as differently colored lines?
[20:44:53] <cradek> yes
[20:45:45] <Lerneaen_Hydra> g'night all
[20:45:50] <jepler> yes. it also shows g2/g3 differently.
[20:45:57] <jepler> in the backplot,
[20:46:00] <jepler> not the preview plot
[20:46:03] <Lerneaen_Hydra> ok, I don't recall seeing that
[20:46:07] <Lerneaen_Hydra> backplot?
[20:46:14] <jepler> http://axis.unpy.net/files/about/axis12-colors.png
[20:46:27] <jepler> preview = what you get when you load the file
[20:46:34] <jepler> backplot = what you get when the machine moves
[20:46:41] <jepler> goodnight
[20:46:59] <Lerneaen_Hydra> oh, is there any way to change that config, so that the preview lines are also colored? (maybe a more pale version)
[20:47:14] <giacus> night Lerneaen_Hydra
[20:47:38] <jepler> Lerneaen_Hydra: In the preview plot the g0 lines are dotted green . .they're already fairly different
[20:47:54] <jepler> in axis 1.3 you'll be able to configure the color of all the lines in the plot
[20:47:57] <Lerneaen_Hydra> oh, ok. that's the main thing I was thinking of
[20:48:04] <Lerneaen_Hydra> ooh, I'll be looking forwards to that :D
[20:48:33] <Lerneaen_Hydra> g'night
[21:53:48] <alex_joni> g'night all
[21:54:53] <giacus> G night alex
[21:59:59] <giacus> * giacus goes to bed too
[22:00:01] <giacus> bye
[22:46:04] <dmessier> allo all..
[22:47:16] <dmessier> can GAIM be used for IRC and MSN and YAHOO mesanger???
[22:48:03] <dmessier> GAIM
[22:56:54] <Jymmm> gaim.sf.net
[22:57:55] <Jymmm> dmessier
http://gaim.sourceforge.net/about.php
[22:59:00] <dmessier> im just thinkin of hacking ALL the m$ crap off the kids machines
[22:59:28] <Jymmm> dmessier why? are they sending nude webcam stuff?
[22:59:56] <dmessier> i loaded puppy EMC2 on the laptop... but set a screwy keyboard.. and cnt find the pound key
[23:00:21] <Jymmm> is puppy live?
[23:00:30] <dmessier> si
[23:00:51] <Jymmm> I dont think I have enough ram in the laptop for it
[23:00:51] <dmessier> havent fed it yet though
[23:01:09] <dmessier> i fed it to the p3
[23:01:42] <Jymmm> p3 yeah, but this is a celron
[23:01:52] <dmessier> do you have a cool test program i can show it off with??
[23:02:10] <dmessier> has axis
[23:02:29] <dmessier> and remembers settings... ; )
[23:07:29] <Jymmm> "cool test program" ?
[23:09:20] <dmessier> some thing showing off loops and logic to acompish wonders and miracle in few lines of code
[23:10:25] <Jymmm> I'm sorry, you lost me... are you talking gcode? graphics? scripting? programming?
[23:24:49] <dmessier> g codes and more
[23:25:14] <dmessier> EMC2
[23:25:51] <Jymmm> Ah, no... just a BDI install (and not the latest either)
[23:28:12] <jepler> dmessier: Here's one that uses the new "O-codes":
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Oword#Sample_1_One_side_of_a_ball_in_cage
[23:28:23] <jepler> it makes an interesting shape to look at in axis
[23:28:32] <jepler> and it's short enough to type in
[23:30:09] <Jymmm> ballacge size of box in in or mm ?
[23:30:25] <Jymmm> looks like inches
[23:31:20] <jepler> i don't see a g20/g21 in there so who knows what you'll get
[23:31:56] <Jymmm> I see cutter radius as .0625
[23:33:09] <jepler> I mean, the result is undefined -- it depends on your configuration what you'll get.
[23:33:43] <jepler> I agree it's probably intended to be in inches
[23:34:38] <Jymmm> what if I used a 1/8" cutter instead of 1/16", would it screw up?
[23:35:46] <Jymmm> oh, I only have a 1./4" ball anyway... nm
[23:36:51] <jepler> I didn't write that code, so I can't say for sure. But I think it's intended to be flexible -- if you want something in a different size, or with a different cutter radius, just change the numbers at the top. The actual movements will change accordingly.
[23:37:17] <Jymmm> Do I have to flip the stock 6 times?
[23:38:00] <jepler> it'll be a challenge to do all the sides
[23:38:33] <Jymmm> becasue the ball will bounce around?
[23:39:14] <jepler> I imagine so
[23:39:18] <jepler> at some point it'll just roll off the mill
[23:39:51] <Jymmm> I thought the idea was the ball will never be small enough to come out of the cage
[23:40:59] <skunkworks> the ball is the same size as the outside of the cage. so it doesn't come out.
[23:43:03] <skunkworks> you would have to play with the sizes to see what happens. The 1/8 cutter I was using needed to be a little longer than it was - and the box should have been a little bigger.
[23:43:14] <skunkworks> and yes it was in inches.
[23:46:42] <skunkworks> jepler: did you ever look at the infinate loop issue with axis?
[23:49:50] <skunkworks> milling the last 2 sides would reqire some extra support to hold the cage and ball togather.
[23:49:54] <skunkworks> is this thing on?
[23:50:32] <skunkworks> :)
[23:51:07] <jepler> skunkworks: there's no general solution, so I've skipped implementing any solution.
[23:53:16] <skunkworks> jepler: killing axis works :)
[23:58:37] <jepler> well yes but I mean there's no way within axis to recover from an apparently nonterminating g-code
