Back
[00:00:19] <alex_joni> some
[00:00:27] <robin_sz> good :)
[00:00:40] <robin_sz> Ive been baking things today
[00:01:09] <alex_joni> in your powder oven?
[00:01:28] <robin_sz> indeed so
[00:01:41] <robin_sz> and mostly they come out looking great :)
[00:01:47] <alex_joni> nice
[00:01:55] <robin_sz> heres something ...
[00:02:07] <robin_sz> the color of the powder coat in the box
[00:02:20] <robin_sz> is almost entirely unrelated to the color of the finished article
[00:02:23] <alex_joni> is not the same one after baking
[00:02:27] <alex_joni> yup
[00:02:33] <robin_sz> amazing ...
[00:02:41] <robin_sz> ok, so reds are red, and greys are grey ..
[00:02:51] <robin_sz> but its changes quite a lot more than I expected
[00:03:09] <paul_c> everything turns black ?
[00:03:37] <robin_sz> certainly they seem to go darker usually, yes
[00:04:07] <robin_sz> it is without doubt, the way to finish metal though
[00:06:06] <robin_sz> so what other news?
[00:10:06] <alex_joni> wow, 857 packages ;)
[00:15:25] <paul_c> yes - need to split most of the dev package out without breaking the deps.
[00:16:05] <robin_sz> sigh .. I wish I had time to play with emc again
[00:16:47] <robin_sz> the ide of CNC'ing a pressbrake with emc is sounding fun though
[00:17:18] <robin_sz> I can get a Amada RG3520 for $trivial I think
[00:17:26] <robin_sz> thats a 35 tonne, 2m press
[00:17:46] <robin_sz> with a manual backguage they go for about 3k5
[00:17:49] <paul_c> alex_joni: As soon as you're done with the check.list, I can build another CD
[00:18:00] <robin_sz> with a 2 axis CNC, they go for $oodles
[00:18:11] <robin_sz> like, ... 11k or more
[00:18:26] <alex_joni> paul_c: I'm all over it...
[00:18:31] <alex_joni> but it's not that easy ;)
[00:19:24] <robin_sz> the only downside is that it will involve lots of deep hackery in emc ... or hijacking of messages
[00:31:45] <alex_joni> anybody can tell me a getch() substitute?
[00:32:35] <robin_sz> alcohol?
[00:33:41] <alex_joni> not really
[00:33:49] <alex_joni> alcohol is not the way
[00:33:53] <paul_c> what are you trying to do ?
[00:34:10] <robin_sz> hes trying to code something, Im trying to get drunk
[00:34:20] <alex_joni> getchar() is ok for me
[00:34:34] <alex_joni> I decided I can't autotest the version stuff
[00:34:46] <alex_joni> so I'll put myself to decide if the version is ok or not
[00:34:57] <alex_joni> Y/N choices
[00:35:22] <cradek> so you mean in a shell script?
[00:35:33] <paul_c> Make the assumption that the version nubers are OK
[00:35:50] <alex_joni> so only name checking?
[00:37:24] <paul_c> That'll do.
[00:52:43] <CIA-4> 03paul_c 07pc_2_6_test * 10emc2/ (36 files in 7 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
[00:52:49] <CIA-4> 03paul_c 07pc_2_6_test * 10emc2/src/ (74 files in 7 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
[00:52:54] <CIA-4> 03paul_c 07pc_2_6_test * 10emc2/src/ (31 files in 4 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
[00:56:25] <alex_joni> guess that puts you way up on the CIA stats ;)
[00:57:09] <alex_joni> can you make a check.list that doesn't include any version info?
[00:57:12] <paul_c> yup - No.1 today
[00:57:22] <alex_joni> perl-base (>= 5.6.0), passwd (>= 961025), debconf
[00:57:28] <alex_joni> should be :
[00:57:37] <alex_joni> perl-base, passwd, debconf
[01:12:22] <alex_joni> paul: I have the following not found:
[01:12:25] <alex_joni> perl-base
[01:15:52] <paul_c> checking...
[01:16:55] <paul_c> fsckit... Another group missing.
[01:20:18] <paul_c> New list with perl-5.8 added.
[01:20:56] <paul_c> I really appreciate your checks - It is trapping a number of errors.
[01:22:27] <alex_joni> I try...
[01:22:44] <alex_joni> although a lot can slip .. it's 3 am here.. so I'm not at my fittest form
[01:23:22] <paul_c> Hmmm... auto-configure failed the math check on 2.6.9
[01:28:23] <alex_joni> aspell-pt-common missing
[01:29:53] <paul_c> indeed, not in the local repo.
[01:29:54] <alex_joni> python-rhpl missing
[01:30:31] <alex_joni> kbd (but it's optional : console-tools (>= 1:0.2.3dbs-54) | kbd
[01:32:00] <paul_c> which package requires python-rhpl ?
[01:32:09] <jmk_away> jmk_away is now known as jmkasunich
[01:32:29] <paul_c> cl-tools...
[01:33:49] <alex_joni> * alex_joni is trying a different approach
[01:34:29] <paul_c> pythn-rhpl is missing - It is a meta-package for python2.3-rhpl
[01:41:16] <alex_joni> found cl-defaults missing
[01:42:25] <alex_joni> data-dumper
[01:43:32] <paul_c> data-dumper provided by perl-base
[01:44:41] <alex_joni> hal missing
[01:44:53] <alex_joni> ;)
[01:44:58] <paul_c> fsckit - Don't want anything that depends on udev & hal - So going to need to fix lsb-defaults
[01:47:44] <alex_joni> libapr0 & libapr0-dev
[01:54:10] <alex_joni> Name: mesa-common-dev
[01:54:10] <alex_joni> Version: 5.0.0-5.1
[01:54:10] <alex_joni> Provides: mesa-common-dev
[01:54:10] <alex_joni> Requires: mesag-dev (>> 5) | mesag-glide2-dev (>> 5) | mesag3+ggi-dev (>> 5)
[01:54:32] <alex_joni> neither mesag-dev, mesag-glide2-dev, mesag3+ggi-dev found
[01:56:11] <paul_c> Can you email a full list in the morning ?
[01:56:33] <alex_joni> ok
[01:56:41] <alex_joni> one more now: pkg-config
[01:57:26] <paul_c> gtk/gnome package
[01:58:40] <alex_joni> yup, but it's missing
[02:01:07] <paul_c> fix up auto-conf
[02:01:18] <CIA-4> 03paul_c 07pc_2_6_test * 10emc2/ (configure configure.in): Tweak configure for 2.6 rtai based installs
[02:05:11] <alex_joni> I sent you the list
[02:05:19] <alex_joni> it is very short ;)
[02:05:33] <alex_joni> 8 names ;)
[02:06:19] <alex_joni> * alex_joni is switching to runlevel: 0
[02:06:28] <paul_c> Thanks alex_joni
[02:06:35] <paul_c> See you tomorrow.
[02:07:17] <alex_joni> anytime paul_c
[02:07:39] <alex_joni> hope I'll make it tomorrow
[02:08:23] <alex_joni> I just finished installing doze on a Compaq desktop
[02:08:33] <alex_joni> I find it pretty neat (the machine...)
[02:08:45] <alex_joni> it's an old PII-300 MHz (passive cooling)
[02:08:59] <paul_c> Will update the list with the missing packages, then split the dev stuff out.
[02:09:00] <alex_joni> with an built-in speaker (connected to the soundblaster)
[02:09:17] <alex_joni> send me the list if you want me to recheck it
[02:09:19] <jepler> a binary tarball of AXIS for BDI 46 is now available
[02:09:40] <alex_joni> jepler: will AXIS go on the emc cvs?
[02:10:37] <jepler> alex_joni: I don't know. If there are other people who want to develop AXIS, that would be the easiest way to do it. While it's just me and Chris, hosting CVS locally is easier.
[02:10:40] <paul_c> A debian package for the emc repository ??
[02:13:06] <ottos> good day gents...
[02:13:14] <cradek> has anyone but us used it yet?
[02:13:25] <ottos> talking about axis?
[02:13:30] <cradek> yes
[02:13:36] <ottos> about to install it..:D
[02:13:41] <cradek> wonderful
[02:14:01] <alex_joni> * alex_joni : sending all proceses the KILL signal
[02:14:26] <paul_c> Goodnight alex_joni
[02:14:39] <alex_joni> night all
[02:14:48] <ottos> a bit off, does anyone know where I can get the pinouts for Vital System Montec-100 card.?is it the sme as STG?
[02:15:23] <paul_c> www.vitalsystem.com
[02:15:55] <paul_c> http://www.vitalsystem.com/motion/motenc-pin.pdf
[02:16:16] <paul_c> http://www.vitalsystem.com/motion/mtref.pdf
[02:17:14] <ottos> getting late...didn't read the fine print..:D thanx a mill Paul...
[02:17:47] <paul_c> If you go for one of those cards, get the breakout boards as well.
[02:18:42] <ottos> allready have...and was a smart ass (figured I can manage the cables better ) and have to buy it separatly...
[02:19:08] <paul_c> cradek: One suggestion, re the tarball...
[02:19:56] <paul_c> docs in /usr/share/doc/axis-1.0b1
[02:20:11] <paul_c> and a symlink from /usr/doc
[02:22:09] <jepler> yeah, that sounds like a good idea, though I'm not sure Python's bdist can create the symlink.
[02:22:30] <cradek> on my system, nothing else puts anything in /usr/doc
[02:22:39] <jepler> I think it's just a mistake
[02:22:45] <cradek> agreed
[02:23:49] <paul_c> Do you fancy doing a Debian package for the next BDI CD ?
[02:24:01] <cradek> doc dir fix committed
[02:24:04] <jepler> also, LICENSE-Togl wasn't included in setup.py
[02:24:57] <jepler> paul_c: there's some rumor that they're adding support for building debian packages to Python's "distutils", in which case it would be easy.
[02:25:06] <jepler> paul_c: I'm not sure I've picked up enough Debian yet to build a package on my own
[02:27:03] <paul_c> I dreaded the prospect, but it wasn't too bad once you try...
[02:27:46] <paul_c> emc2 has a basic debian rule set you can use as an example.
[02:28:36] <cradek> paul_c: I hope we get some good feedback about the beta so we can determine what it will take to release 1.0
[02:29:43] <paul_c> Well..... If you wanted (or need a hand to) build a deb for BDI-3, I can fit it in
[02:29:58] <cradek> how much time do we have?
[02:30:01] <paul_c> Already have the support packages included.
[02:30:31] <ottos> thank you all...night gents...
[02:30:44] <paul_c> I had hoped to resolve the final dependency issues tomorrow
[02:31:11] <paul_c> and build a final beta before Monday
[02:31:25] <jepler> that's not long .. we won't have anything to call a 1.0 release by then
[02:31:50] <paul_c> A pre-1.0 is fine
[02:32:08] <cradek> it's pretty late for the US folks to give this a try before tomorrow's meeting, but maybe we'll hear from some of you guys in Europe
[02:32:43] <jepler> I can look at creating a .deb package on my rc46 machine
[02:32:47] <paul_c> I don't think it will build on my test boxes
[02:33:56] <paul_c> EMC for BDI-3 uses libnml from emc2 along with the make system.
[02:34:51] <cradek> it will probably still work
[02:35:22] <cradek> as an aside, does that mean BDI-3 won't have my jog-after-abort fix?
[02:35:58] <paul_c> Just one return statement in emctaskmain.cc wasn't it ?
[02:36:05] <cradek> yes
[02:36:21] <paul_c> In that case, Yes.
[02:36:35] <cradek> yes it will, or yes it won't?
[02:36:44] <paul_c> Diffed the code this evening and made the change
[02:36:56] <cradek> great, thanks
[02:37:07] <cradek> if you also think it's right, you could check it in to emc2
[02:37:14] <cradek> then it will be your fault too
[02:37:29] <paul_c> Cheers Pal !
[02:38:07] <paul_c> also have a fix for axis runaway under screwball situations.
[02:39:07] <cradek> that sounds like a good one too
[02:39:54] <paul_c> And there is a /proc entry for debugging purposes
[02:40:50] <paul_c> hacking the kernel module, and want to see what a variable is doing...
[02:41:21] <paul_c> add it to the proc code, and cat /proc/emc
[02:42:00] <paul_c> with a little bit of work, can do a /dev node too.
[02:42:07] <jepler> paul_c: where do I get /usr/bin/debuild?
[02:42:36] <jepler> paul_c: I'm trying out the experimental python support for building debian packagfes, but it says "error: can't find /usr/bin/debuild; you should have the debuild package installed", while apt-get says "couldn't find package debuild"
[02:43:00] <paul_c> apt-get install devscripts
[02:43:26] <paul_c> bookmark
[02:43:29] <paul_c> http://www.debian.org/distrib/packages
[02:47:27] <jepler> paul_c: well I have here a file that ends in .deb
[02:48:31] <paul_c> for download, or did you want to mail it over ?
[02:49:13] <jepler> http://axis.unpythonic.net/index.cgi-files/downloads/01102198430/python2.3-axis_1.0b1-0.1_i386.deb
[02:52:06] <paul_c> OK... We'll need to add a dependency for emc/rcslib/nml at some point.
[02:53:35] <jepler> the .deb appears to work on my system, though it's easy to be wrong about that since I already had AXIS installed
[02:53:41] <jepler> and, yeah, I'm sure the deps are all wrong
[02:54:09] <paul_c> I'll try it out on the test box in the morning
[02:54:20] <jepler> because I didn't have to specify any
[02:55:07] <jepler> Unless a bad bug turns up this is probably the only version there will be between now and monday
[02:55:27] <paul_c> python2.3-opengl & Co need to be added to the deps.
[02:56:07] <paul_c> But I can set the install up so that they are in a mandatory list.
[02:57:33] <paul_c> Looks like Ray has a question for you on the user's list...
[02:58:44] <paul_c> Goodnight all.
[02:59:30] <jepler> answered...
[03:42:31] <jepler> 'night all, see you at 14:00 GMT
[03:42:56] <danfalck> * danfalck is away: going out to the shop...
[07:52:37] <bh74535> Hi, is anybody around?
[07:53:45] <bh74535> Guess not
[14:09:43] <cradek> good morning
[14:12:54] <jepler> good morning
[14:12:58] <paul_c> Afternoon.
[14:13:17] <Imperator_> Afternoon
[14:48:26] <cradek> jepler: well, I don't think anyone has run it yet
[14:54:24] <jepler> cradek: maybe not
[14:59:33] <jmk_away> these things take time guys ;-)
[15:00:19] <jmk_away> jmk_away is now known as jmkasunich
[15:00:30] <cradek> but everyone should be as excited about it as we are!
[15:02:18] <Imperator_> jep
[15:02:55] <Imperator_> have to install phyton on TNG-BDI
[15:05:39] <jepler> Imperator_: somehow I think you must be talking to me each time you say "jep".
[15:06:07] <jepler> I guess I need to learn that's not true
[15:06:53] <Imperator_> it is true
[15:07:10] <Imperator_> hopw i understand you the right way
[15:07:36] <Imperator_> * Imperator_ has downloaded phyton 2.4
[15:13:20] <cradek> my cat thinks he can dig his way under a closed door.
[15:13:31] <rayh> jepler: One thought on the GREAT gui.
[15:13:33] <rayh> Lube ought to be labeled coolant.
[15:13:50] <rayh> cradek: Wants at your keyboard?
[15:14:49] <jepler> rayh: hm, okay. I wonder where we got the idea to call it lube.
[15:15:34] <rayh> Probably from me.
[15:16:14] <rayh> There is a "Lube" alarm in tkemc and emc that watches a pin.
[15:16:20] <cradek> jepler: are you changing it or should I?
[15:16:24] <jepler> cradek: I've changed it
[15:17:00] <rayh> Most of the commercial machines have lube alarms that deal with way oil and ball nut oil levels or pressure.
[15:17:04] <rayh> That was quick.
[15:17:30] <rayh> I only wish that I could download the packages needed to run it.
[15:17:42] <cradek> why can't you?
[15:17:57] <rayh> .8k/s line
[15:18:09] <rayh> On a good day.
[15:18:11] <jepler> ouch
[15:18:15] <cradek> yow
[15:19:03] <rayh> And I'm pushing apt-get as the future -- who'd figure.
[15:19:06] <paul_c> rayh: BDI-3 will have all the python packages on it
[15:19:28] <jmkasunich> so how does ray get the BDI-3 iso ;-)
[15:19:29] <rayh> I see that. Fantastic.
[15:19:55] <rayh> Bought it from a t1 shop in Chicago.
[15:20:29] <jmkasunich> ? you just ask them to "download such-and-such an iso, burn it and mail it to me"?
[15:20:35] <rayh> The big gray dog met me at the highway.
[15:21:24] <rayh> Snow shoes and all, 'cause the county hadn't plowed the drive yet.
[15:21:56] <jmkasunich> dang ray, you _are_ up in the wild north!
[15:22:48] <rayh> Got a spare bedroom if anyone needs to get away for a while.
[15:22:49] <SteveStallings> Gee bandwidth and weather... such a deal!!!
[15:23:03] <jmkasunich> I'd have DSL withdrawl
[15:23:14] <cradek> get away from ... my 2Mbit connection??
[15:23:30] <rayh> When it gets really cold, 0f the other morning, the bits arrive very slowly.
[15:23:56] <jmkasunich> do you have hot chocolate ready for them when the get there?
[15:24:10] <rayh> You bet.
[15:26:01] <jmkasunich> could somebody glance at my last post to emc-users? I posted emc2 checkout and compile instructions, want to make sure they're right before I add them to the emc2 page at linuxcnc.org
[15:26:16] <paul_c> This thing defaults to a Brit dictionary, anything else needed ?
[15:26:20] <jmkasunich> (particuluarly the cvs checkout)
[15:28:04] <paul_c> add a note about the RT path just in case the usr has use /tmp/foo or ~/RTsommat
[15:28:55] <jmkasunich> exactly what should said note say? (I've not done anything with non-standard paths)
[15:29:26] <paul_c> ./configure --with-rtai=/home/foo/realtime
[15:30:09] <jmkasunich> "if you've installed your realtime patches at /home/foo/relatime, then do ./configure --with-rtai=/home/foo/realtime" ?
[15:30:58] <jmkasunich> to be honest, such notes should be in README or INSTALL, not on a webpage
[15:31:13] <paul_c> yes - With a similar format for --with-rtlinux
[15:31:22] <rayh> * rayh <nitpick> dislikes the word "do" in that context. </nitpick>
[15:31:40] <rayh> If you are an emc developer at SF, checkout a current copy from CVS:
[15:31:48] <jmkasunich> the page is mostly to tell folks how to download it, once they have it they should no longer need the page, all instructions should be contained in the checkout
[15:34:09] <alex_joni> good day gents
[15:34:48] <jmkasunich> hi alex
[15:36:02] <jepler> hi alex
[15:36:10] <rayh> Question regarding Axis.
[15:36:20] <rayh> I've now read both the README in the tarball and the install page
[15:37:24] <rayh> I'm confused by the use of directory terminology
[15:37:49] <rayh> A BDI uses /usr/local to house emc and rcslib
[15:38:12] <rayh> The emc source directory is /usr/local/emc/src
[15:38:38] <jepler> oh, is there a copy of the source tree there?
[15:38:48] <jepler> -bash: cd: /usr/local/emc/src: No such file or directory
[15:38:52] <jepler> not on my rc46 machine
[15:39:19] <rayh> Ah. You untar the bz in /usr/local to get the sources.
[15:39:51] <rayh> You mean to use /usr/local/emc/plat/linux_rtai
[15:39:53] <jepler> oh, I untarred it in /usr/local/src on my machine
[15:40:07] <rayh> Oh. Okay.
[15:40:41] <rayh> * rayh grabs a bit of breakfast.
[15:40:56] <alex_joni> * alex_joni prepares to try axis
[15:40:58] <jepler> if you untarred from /usr/local, then you would have to build with EMCSOURCEDIR=/usr/local
[15:41:56] <jepler> but if you're using bdi, give the binary tarball or the .deb package a try
[15:44:57] <SteveStallings> Just did a CVS update to the EMC2 installation on my laptop (BDI-RC46). The new config stuff worked fine, at least as far as I can tell without a real machine attached. Thanks Alex et all.
[15:45:52] <alex_joni> steve: glad to hear that
[15:46:18] <paul_c> did you update the kernel & rtai packages ?
[15:46:40] <alex_joni> oh..hi paul ;)
[15:46:44] <jepler> rayh: And untarring isn't enough, you have to build. Otherwise, the headers are not in the location setup.py expects, and there's no librcs.a
[15:46:58] <jepler> er, libemc.a
[15:47:02] <paul_c> Hi alex_joni - You only just crawled out of bed ?
[15:48:11] <SteveStallings> Who me? No, just the EMC2 tree. I have never compiled rtai or kernel stuff.
[15:48:36] <alex_joni> paul: no... I just got home (was at some friends 100 km from here)
[15:48:56] <alex_joni> paul: do you have a new list for me to test?
[15:49:15] <paul_c> SteveStallings: Sorry, I thought you'd done an apt-upgrade.
[15:50:18] <paul_c> alex_joni: eight broken packages to fix (version probs)
[15:50:50] <SteveStallings> Last Wednesday there was a commit by cradek to fix a jog bug in EMC1. Do we know if EMC2 needs the same fix?
[15:51:00] <paul_c> Yes
[15:51:15] <paul_c> Do you want to do the fix ?
[15:54:35] <SteveStallings> Learn by doing... sink or swim... whatever, I'm chicken. I have never been a C programmer. I can just barely read the stuff. I am an assembly language dinosaur. Happier with hardware....
[15:56:28] <jepler> if it's any consolation, people who are fond of languages like Python think C is too much like assemly language and too little like a high-level language.
[15:57:08] <alex_joni> paul: I'll comit cradeks fix to emc2 too
[15:57:13] <jepler> worry about the number of bits in an integer? check. forced to manually allocate memory? check.
[15:57:34] <CIA-11> 03paul_c * 10emc2/src/emc/task/emctaskmain.cc: Commit Chris Radek's abort bug fix
[15:57:46] <paul_c> Too late.
[15:57:50] <alex_joni> lol
[15:58:14] <alex_joni> jepler: what packages do I need to run axis?
[15:58:27] <alex_joni> python, python-dev, python-opengl ?
[15:58:56] <cradek> http://axis.unpy.net/index.cgi/installing
[15:59:10] <alex_joni> yeah yeah, just RTFM
[16:01:28] <jmkasunich> cradek: re: HLL vs C: know exactly what is going on, check!
[16:01:45] <paul_c> Okay.... The only packages with borked deps are all libXXX-dev packages.
[16:02:09] <alex_joni> jmk: that was jepler ;)
[16:02:24] <cradek> but it's ok, I agree
[16:02:25] <jmkasunich> oops... sorry cradek
[16:02:55] <jepler> yeah, cradek would have written AXIS in C and we'd be contemplating a beta next May or so
[16:02:56] <jmkasunich> (all the languages I know are at least 20 yrs old ;-)
[16:03:16] <jepler> Yeah, I don't think Python's much more than 12 years old
[16:03:21] <cradek> well, that's probably true
[16:03:24] <alex_joni> at least you know they don't change anymore (after 20 years)
[16:03:30] <cradek> but only because you wouldn't have helped me
[16:04:35] <jmkasunich> alex_joni: that's probably one of the reasons I like them - I _hate_ change!
[16:05:00] <jepler> alex_joni: that's not true... compared the C you know to C99?
[16:05:20] <jepler> Yay, doing CVS checkout of emc as a developer, not as anonymous
[16:06:13] <alex_joni> jepler: I agree some stuff gets changed once in a while
[16:06:22] <alex_joni> and I'm not that 100% c-fan
[16:06:29] <jepler> What's your favorite, then?
[16:06:43] <alex_joni> it is what I like most
[16:06:44] <alex_joni> ;)
[16:06:54] <alex_joni> but I don't like it 100%
[16:07:05] <alex_joni> there is stuff I like in other languages better
[16:07:16] <alex_joni> but hey, that's just me ;)
[16:09:15] <alex_joni> don't seem to fina a xlibmesa-dev on SuSE
[16:09:58] <paul_c> mesa or mesagl
[16:11:07] <paul_c> or libglut3
[16:12:02] <alex_joni> * alex_joni is fighting with SuSE install CD-s
[16:12:44] <jepler> alex_joni: on this fedora core 2 machine I think the package required is xorg-x11-devel. It's the package that provides <GL/gl.h>
[16:14:15] <cradek> on my redhat9 machine it's XFree86-devel
[16:14:34] <cradek> so you may already have it
[16:14:37] <cradek> try locate gl.h
[16:20:42] <jmkasunich> take a look at
http://linuxcnc.org/EMC2-description.html and tell me what you think
[16:21:36] <jmkasunich> (hopefully this will eliminate the need to explain the CVS commands on the lists)
[16:25:05] <SteveStallings> JMK - You might include some instruction about setting up a directory to contain all the new stuff (for true Linux newbies like me - grin)
[16:25:53] <alex_joni> jmk: for dev CVS checkout
[16:25:54] <jmkasunich> actually, if you run the cvs command from your home directory, it will create a directory called emc2 below your home dir
[16:25:59] <alex_joni> include de dev_name in the command
[16:26:04] <paul_c> SteveStallings:
http://www.linuxnewbies.org
[16:26:30] <SteveStallings> Ouch.... is it written in MS-Word??
[16:26:48] <jmkasunich> oops - I did include it, but it was like this "<devname>", and the <> make HTML think it was a tag
[16:26:51] <jmkasunich> * jmkasunich fixes
[16:27:45] <alex_joni> otherwise it sounds ok
[16:29:25] <paul_c> jmkasunich: Side note - Played around with mailman again, and should have fixed the notices from the Trackers.
[16:29:52] <jmkasunich> good - they were getting annoying
[16:30:14] <jmkasunich> checkout command should be fixed now
[16:30:54] <alex_joni> indeed it is
[16:31:39] <jmkasunich> SteveStallings: is what written in MS-Word?
[16:32:05] <SteveStallings> Paul - I would NOT recommend www.linuxnewbies.org to anyone. It is mostly adware and tries to set your homepage defaults, tries to launch popups, and other ill conceived behavior.
[16:32:56] <SteveStallings> The comment about MS-Word was a jab at Paul..... Linux newie docs should be in MS-Word format... 8-)
[16:32:59] <jmkasunich> seconded - I didn't see the ill bahavior cause I used Konqueror, but it is _not_ usefull to newbies
[16:33:30] <SteveStallings> My system is set up such that all the ill behavior was trapped, but it still annoyed me.
[16:33:51] <paul_c> SteveStallings: Appologies - I wasn't aware of linuxnebies.org popups
[16:35:25] <SteveStallings> What I really need is just the time to -USE- Linux. Skill comes from exersize.
[16:36:43] <paul_c> * paul_c hands SteveStallings a M$ erase utility.
[16:38:03] <SteveStallings> Somehow I don't trust something here.....
[16:38:43] <alex_joni> darn
[16:38:50] <alex_joni> I broke my Yast
[16:39:17] <jmkasunich> wat's a Yast?
[16:39:26] <alex_joni> Yet another setup tool
[16:39:34] <alex_joni> it's SuSE's tool for sysadmin
[16:39:39] <alex_joni> install packages & such
[16:40:01] <alex_joni> I seem to have flushed the list of installable packeges somehow :(
[16:40:45] <alex_joni> now I gotta install everything manually.. that's a PITA
[16:40:48] <jmkasunich> * jmkasunich wonders how much preload is too much on a ballnut
[16:41:58] <rayh> alex. My last problem might have been caused by some yast stuff I did.
[16:42:12] <rayh> SuSE problem that is.
[16:42:18] <alex_joni> I know ;)
[16:42:19] <Imperator_> cradek: is axis realy tested on EMC2 ?
[16:42:32] <SteveStallings> Preload will depend a lot on how precision the screw is made. Also, is it a rigid preload or a spring preload.
[16:43:10] <jmkasunich> spring - a thick wavey washer between the two ballnuts, with a threaded collar that compresses it, trying to push the nuts apart
[16:43:29] <rayh> Roland at Cardinal uses a couple of belville washers between two ballnuts on that cheap thompson.
[16:44:00] <jmkasunich> this is a surplus assembly, already had the two nuts, collar and wave washer
[16:44:02] <rayh> He sets the force to be just a bit more than the cutting force he wants.
[16:44:27] <SteveStallings> Spring is much more forgiving. Preload should be equal to max cutting force in order to be effective. Affect on screw life is another matter.
[16:45:00] <jmkasunich> this is a Z axis (quill)
[16:45:21] <jmkasunich> the upper nut is rigidly attached to a bearing, (nut rotates), screw attached to quill
[16:45:30] <jmkasunich> lower nut is spring loaded downward
[16:45:41] <jmkasunich> so when drilling, the spring will compress
[16:46:02] <jmkasunich> when milling or just holding the weight of the quill, the rigidly mounted nut will be in play
[16:46:38] <jmkasunich> * jmkasunich can't really measure the spring force
[16:46:41] <SteveStallings> It would be better if the situation could be reversed. That way the preload would only have to deal with force to pull quill up.
[16:46:42] <Imperator_> in my Bosch Rexroth katalog they say preload has not to be more thane one thired of the middle load (don't know if that information helps you)
[16:47:11] <cradek> Imperator_: I tried it, yes
[16:47:12] <jepler> Imperator_: cradek built emc2 and used it to run his maxnc mill. axis works, though there's a problem displaying jogs.
[16:47:18] <jepler> cradek: oh, you are still here
[16:47:26] <jepler> I'm not paying much attention, I'm afraid.
[16:47:39] <cradek> jepler: I'm here off and on
[16:48:33] <Imperator_> i have made the symlink in ..../emc2/bin
[16:48:47] <cradek> oh are you trying it now?
[16:49:11] <Imperator_> but it says .../emc2/bin/axis is a directory
[16:49:16] <Imperator_> jep
[16:49:24] <jepler> can you "ls -l emc2/bin/axis" ?
[16:49:58] <jmkasunich> SteveStallings: I think I like it better this way, if it was the other way and I was milling a slot, cutter downforce (from spiral endmill) might "pull" it down and make the slot too deep
[16:50:47] <Imperator_> yes i can do that
[16:51:00] <Imperator_> what do i have to type for building it ?
[16:51:14] <Imperator_> plat=nonrealtime ???
[16:51:27] <jmkasunich> I put the assy on my drill press table and used the drill press chuck to compress it... the spring flattens completely at force levels similar to what I would use to drill 3/8" in steel
[16:52:39] <jmkasunich> I think I'll adjust it to 2/3 or 3/4 flat
[16:52:41] <jepler> Imperator_: in the AXIS source directory, you type something like 'env PLAT=nonrealtime EMCSOURCEDIR=/usr/local python setup.py'.
[16:53:10] <jmkasunich> it will flatten out during heavy drilling, but should be stable for milling where depth control is more critical
[16:53:15] <jepler> if you're on a pure emc2 machine, you may have to change lines 47 and 51 of setup.py to refer to "emc2" instead of "emc"
[16:53:30] <rayh> jmkasunich: IMO it should not compress at all under normal cutting forces.
[16:53:31] <alex_joni> jepler: it segfaults here :(
[16:53:37] <ottos> day gents...
[16:53:57] <jmkasunich> it'
[16:53:58] <jepler> alex_joni: ouch
[16:54:03] <jmkasunich> it's not that stiff
[16:54:24] <jepler> alex_joni: did it leave a core file?
[16:54:32] <alex_joni> in /usr/bin/ ?
[16:54:34] <jmkasunich> I'd have to adjust it completely flat if I didn't want it to compress when drilling
[16:54:46] <jepler> alex_joni: Probably in /usr/local/emc ?
[16:55:00] <alex_joni> nope
[16:55:10] <rayh> I think that's why Roland used the Belville washers. He can get them stronger than the cutting force.
[16:56:02] <jmkasunich> I'm afraid if I did that here I might have accelerated screw wear
[16:56:17] <jepler> alex_joni: try running 'ulimit -c unlimited' before starting emc with axis
[16:56:58] <jmkasunich> I adjusted it nearly flat, it takes quite a bit of force to flatten it - milling should not deflect it, nor would drilling moderate size holes, or large holes with a pilot hole
[16:57:10] <jmkasunich> but drilling large holes from the solid would
[16:57:18] <jmkasunich> acceptable tradeoff, I think
[16:57:31] <alex_joni> ok... core dumped
[16:58:07] <jepler> now, "gdb python core", and /msg me the traceback
[16:58:10] <rayh> jmkasunich: close enough.
[16:58:49] <jmkasunich> total compression is less than 0.005, it's rare that depth control on a drilled hole is that critical
[16:59:20] <jmkasunich> and this is a cheap chinese 3-in-1 anyway - probably more flex than that in the head itself :-(
[17:01:18] <SteveStallings> JMK - That answers my un-posed question. So you are not trying to CNC the Van Norman. A friend of mine also has a #12. He, like most, is not lucky enough to have the head with a quill. I was wondering if you were so lucky.
[17:01:47] <jmkasunich> nope - #12 never had a quill - only the #1RQ
[17:02:56] <ottos> I have a question about the Vital pci card...does the vitalAmpEnable funcion have an association witht eh output wins on j6?
[17:03:15] <Imperator_> File "setup.py", line 42
[17:03:16] <Imperator_> togl = Extension("_togl", ["extensions/_toglmodule.c"], **get_togl_flags())
[17:03:18] <Imperator_> ^
[17:03:19] <Imperator_> SyntaxError: invalid syntax
[17:04:52] <paul_c> ottos - Should do...
[17:04:56] <jmkasunich> there's a very droolworthy 1RA at
http://www.toolbit.net/vn/, but the server seems to be down right now
[17:05:02] <jmkasunich> make that 1RQ
[17:07:22] <ottos> Paul is the spindle and aux I/o going the old way (pport ) or has it been changed?
[17:08:15] <jmkasunich> strange - after about 1-1/2" of travel the ballnuts seem to get tighter all of a sudden
[17:09:25] <jepler> Imperator_: what version of Python? 2.2 or greater?
[17:09:43] <Imperator_> the newst 2.4
[17:09:44] <jepler> Imperator_: on your terminal, what was the ^ below? Over here, it looks like it's past the end of the line
[17:10:04] <Imperator_> under the second star
[17:10:06] <paul_c> ottos: For the Vital card ?
[17:10:28] <ottos> PCi Motenc-100 8axis
[17:10:34] <ottos> yes..
[17:11:08] <paul_c> Currently, sindle on/off, etc are via the parallel port
[17:11:28] <ottos> ok..
[17:11:32] <paul_c> but sindle speed should work through the Vital card
[17:11:35] <jepler> Imperator_: make sure that you are getting python2.4 when you type "python". It should print a banner with the version number.
[17:12:07] <paul_c> ottos: It wouldn't take much to get all the IO working through the Vital card.
[17:12:13] <jepler> or run "python2.4 setup.py", that's another way to make sure you're getting the right version
[17:12:56] <paul_c> jepler: Does axis require Python2.4, or is it OK with 2.3 ?
[17:13:07] <ottos> Paul , might sound crazy but I was hoping to make a complete docs/ I/o map for easy Motenc install..any suggestions?
[17:13:12] <Imperator_> hmmm "Pyhton 1.5.2"
[17:13:22] <jepler> paul_c: It's supposed to work on 2.2 and 2.3. It's mostly tested with 2.3
[17:14:22] <paul_c> ottos: We can work on the IO shortly - I need to get this new CD finished before tackling anything new.
[17:15:11] <ottos> ok...sure thing...thanx again..
[17:18:31] <ottos> ok gents..later..a+
[17:21:23] <Imperator_> jepler: ok with "env PLAT=nonrealtime EMCSOURCEDIR=/home/martin/develop/emc2 python2.4 setup.py" it is much better but setup.py would like to have a additional command now
[17:21:59] <jepler> setup.py build, then setup.py install as root
[17:22:09] <Imperator_> ups
[17:22:12] <Imperator_> sorry
[17:23:25] <jepler> Imperator_: if you're on a pure emc2 machine, you may have to change lines 47 and 51 of setup.py to refer to "emc2" instead of "emc", otherwise you'll get lots of compiler errors when it tries to build the emc module.
[17:23:39] <jepler> (i said that earlier, but without your name, so I don't know if you caught it)
[17:24:27] <jepler> also, EMCSOURCEDIR is the directory where emc (or emc2) and rcslib directories exist, so you may need /home/martin/develop, not /home/martin/develop/emc2
[17:27:53] <Imperator_> i think i have to change much more than emc --> emc2
[17:28:31] <Imperator_> it don't find rcs.hh emc.hh and inifile.h
[17:29:01] <alex_joni> You probably need to change $EMCSOURCEDIR/plat/$plat/include with your $EMC2/include
[17:29:27] <jepler> it expects to find inifile.h in $EMCSOURCEDIR/emc/$PLAT/nonrealtime/include/inifile.h, etc
[17:29:54] <jmkasunich> no PLAT stuff at all in emc2
[17:29:55] <jepler> you can change setup.py to hard-code the proper include and library directories, lines 47 to 52 or so
[17:30:12] <alex_joni> DEFAULT_NMLFILE (you need to change that to %s/configs/emc.nml)
[17:30:47] <jepler> DEFAULT_NMLFILE isn't important for axis, only for gplot
[17:31:13] <alex_joni> martin: os.path.join(emcsourcedir, "emc2", "include") should be enough
[17:31:30] <alex_joni> for include_dirs
[17:31:39] <alex_joni> and the same one for library_dirs
[17:32:07] <alex_joni> probably you need to replace rcs with libnml too (line54)
[17:42:10] <Imperator_> I#m getting closer
[17:42:22] <Imperator_> step by step
[17:42:32] <jepler> you're really on the cutting edge to build axis on emc2
[17:44:29] <jmkasunich> rayh: anyone else: any news about Fest 2005?
[17:47:18] <Imperator_> py build
[17:47:19] <Imperator_> running build
[17:47:21] <Imperator_> running build_py
[17:47:23] <Imperator_> running build_ext
[17:47:24] <Imperator_> building 'emc' extension
[17:47:26] <Imperator_> c++ -pthread -shared build/temp.linux-i586-2.4/extensions/emcmodule.o -L/home/martin/develop/emc2/lib -L/home/martin/develop/emc2/rtlib -lemc2 -llibnml -lm -lstdc++ -o build/lib.linux-i586-2.4/emc.so -Wl,-rpath,/home/martin/develop/emc2/rtlib
[17:47:27] <Imperator_> /usr/bin/ld: cannot find -lemc2
[17:47:29] <Imperator_> collect2: ld returned 1 exit status
[17:47:31] <Imperator_> error: command 'c++' failed with exit status 1
[17:47:42] <Imperator_> and setup.py looks now like this:
[17:47:44] <Imperator_> togl = Extension("_togl", ["extensions/_toglmodule.c"], **get_togl_flags())
[17:47:45] <Imperator_> emc = Extension("emc", ["extensions/emcmodule.cc"],
[17:47:47] <Imperator_> define_macros=[('DEFAULT_NMLFILE', '"%s/emc2/emc.nml"' % emcsourcedir)],
[17:47:48] <Imperator_> include_dirs=[
[17:47:50] <Imperator_> os.path.join(emcsourcedir, "emc2", "include"),
[17:47:51] <Imperator_> os.path.join(emcsourcedir, "emc2", "rtlib")
[17:47:53] <Imperator_> ],
[17:47:55] <Imperator_> library_dirs = [
[17:47:56] <Imperator_> os.path.join(emcsourcedir, "emc2", "lib"),
[17:47:58] <Imperator_> os.path.join(emcsourcedir, "emc2", "rtlib")
[17:47:59] <Imperator_> ],
[17:48:01] <Imperator_> libraries = ["emc2", "libnml", "m", "stdc++"],
[17:48:03] <Imperator_> extra_link_args = ['-Wl,-rpath,%s' %
[17:48:04] <Imperator_> os.path.join(emcsourcedir, "emc2", "rtlib")]
[17:48:37] <jepler> Imperator_: where is libemc2.a or libemc2.so?
[17:48:51] <jepler> Imperator_: That directory needs to be listed in library_dirs
[17:50:19] <Imperator_> it is in ..../emc2/lib
[17:50:48] <Imperator_> that is stll listed, or ???
[17:51:07] <Imperator_> os.path.join(emcsourcedir, "emc2", "lib"),
[17:51:38] <jepler> what files are in /home/martin/develop/emc2/lib?
[17:51:51] <Imperator_> but it is libemc.a not libemc2.a
[17:52:20] <jepler> then the item in libraries must be "emc", not "emc2".
[17:52:37] <rayh> jmkasunich: Sorry away working. Been looking for someone to coordinate. Nothing so far.
[17:52:44] <rayh> Must get to work on that.
[17:52:51] <Imperator_> there are : hal_lib.o libemc.a libnml.a libnmld.a libpm.a ulapi.o
[17:53:11] <jepler> then try libraries = ["emc", "libnml", "m", "stdc++"]
[17:56:19] <Imperator_> that gives me the same error
[17:57:02] <Imperator_> i think the problem is that there are some spaces missing, or
[17:58:32] <Imperator_> /usr/bin/ld: cannot find -llibnml
[17:58:33] <jepler> I left out the comma that must be at the end of that line, did you include it?
[17:58:43] <Imperator_> no
[17:59:21] <jmkasunich> hi jon
[17:59:25] <elson> Hello, all!
[17:59:30] <jepler> libraries = ["emc", "nml", "m", "stdc++"],
[17:59:34] <jepler> ^^ try this
[18:00:40] <Imperator_> /usr/bin/ld: cannot find -llibnml
[18:01:10] <elson> Is anyone else working on hardware interfaces for EMC2?
[18:01:13] <jepler> if the file is libnml.a or libnml.so, then you have to have "nml", not "libnml" in libraries
[18:01:25] <elson> I was thinking it would be easier if maybe we standardized the
[18:01:58] <elson> way we'd present HAL pins for things like the STG, Vital and my PPMC boards.
[18:02:11] <jmkasunich> yes
[18:02:28] <jmkasunich> * jmkasunich is up to his elbows in little steel balls (repacking a ballnut)
[18:02:35] <jmkasunich> give me 10 mins
[18:02:42] <elson> Yes, it would be easier, or yes others are working on interfaces?
[18:02:55] <jmkasunich> yes we should standardize
[18:03:01] <elson> Umm, ballnuts, that can be messy. I have a neat trick for
[18:03:16] <elson> cleaning inside a ballnut without disassembling. You coat the
[18:03:31] <elson> screw with grease and run the nut back and forth a few times.
[18:03:45] <Imperator_> much better now, but there are some warnings and then it breaks
[18:03:49] <elson> The grit ends up sticking to the screw, and you can wipe it off.
[18:04:08] <jmkasunich> I had it apart to machine the ends
[18:04:33] <elson> I did one that was kind of tricky, the wipers on the end would
[18:04:44] <Imperator_> ..........................
[18:04:46] <Imperator_> In file included from thirdparty/togl.c:36,
[18:04:48] <Imperator_> from extensions/_toglmodule.c:2:
[18:04:49] <Imperator_> /usr/include/GL/glx.h:428: warning: function declaration isn't a prototype
[18:04:50] <Imperator_> In file included from extensions/_toglmodule.c:2:
[18:04:51] <elson> make it a bit hard to use a plug to keep the balls in the nut.
[18:04:52] <Imperator_> thirdparty/togl.c: In function `Togl_Cmd':
[18:04:54] <Imperator_> thirdparty/togl.c:1247: warning: `main' is usually a function
[18:04:55] <Imperator_> thirdparty/togl.c: In function `Togl_CreateWindow':
[18:04:57] <Imperator_> thirdparty/togl.c:1597: warning: unused variable `winPtr'
[18:04:58] <Imperator_> extensions/_toglmodule.c: In function `get_interpreter':
[18:05:00] <Imperator_> extensions/_toglmodule.c:9: parse error before `long'
[18:05:01] <Imperator_> extensions/_toglmodule.c:11: `interpaddr' undeclared (first use in this function)
[18:05:03] <Imperator_> extensions/_toglmodule.c:11: (Each undeclared identifier is reported only once
[18:05:05] <Imperator_> extensions/_toglmodule.c:11: for each function it appears in.)
[18:05:06] <Imperator_> error: command 'gcc' failed with exit status 1
[18:05:07] <elson> So I just machined the screw with the nut covered and taped
[18:05:09] <elson> in place.
[18:05:19] <Imperator_> must i have a newer wersion of gcc ??? maybe it is pretty old !
[18:05:24] <cradek> I know what this error is...
[18:05:41] <jepler> cradek: have you fixed that _toglmodule bug in CVS? If not, please do
[18:05:50] <cradek> yes I did
[18:08:38] <alex_joni> jmk: did you notice the hal_stg driver?
[18:08:56] <cradek> http://unpy.net/cgi-bin/viewcvs.cgi/*checkout*/axis/extensions/_toglmodule.c?rev=HEAD&content-type=text/plain
[18:09:06] <cradek> Imperator_: can you download the latest _toglmodule.c with that url?
[18:10:07] <Imperator_> jep
[18:10:17] <alex_joni> not jepler ;)
[18:10:24] <jmkasunich> * jmkasunich is ready to talk drivers
[18:10:37] <jmkasunich> alex_joni: noticed it yes, examined it closely, no
[18:10:48] <alex_joni> there is not much to examine
[18:10:57] <alex_joni> only some LS7266 stuff in there
[18:11:15] <alex_joni> should get some testing... (someday)
[18:11:25] <elson> There's an STG driver? I'll have to look at that!
[18:11:40] <jmkasunich> didn't know you had a STG card Jon?
[18:12:09] <alex_joni> Jon: you'll be disappointed.. not much there yet
[18:12:18] <alex_joni> but if you test...I can develop ;)
[18:12:20] <elson> Well, actually I DO! My Bridgeport mill is STILL run on an STG I,
[18:12:42] <elson> with analog servo amps, and a Dec 1999 version of EMC! Yikes, that's
[18:12:44] <elson> old!
[18:12:46] <jmkasunich> cobblers kid, eh... I would have expected it to be running PPMC
[18:13:51] <elson> That will happen some time! Yeah, I just hate to tear it apart, as I will surely have a mad scramble to get it all back together when I need to make something.
[18:14:25] <jmkasunich> well, don't do it until after we test the HAL STG driver ;-)
[18:15:05] <elson> If I rip that system apart, it will need a massive updating. It is
[18:15:23] <alex_joni> yay.. axis sorta runs ;)
[18:15:37] <elson> a 100 MHz Pentium classic with 16 (well, maybe 32) MB ram and a 1 GB hard drive.
[18:15:45] <jmkasunich> wow
[18:16:13] <Imperator_> alex_joni: you have axis running with emc2 ?
[18:16:26] <Imperator_> here now it build with some warnings
[18:17:12] <Imperator_> i have installed it but if i start emc2 with ./scrips.emc.run it says at the emd ............/emc2/bin/axis is a directory
[18:17:27] <alex_joni> Imperator_: give me 5 mins
[18:17:33] <Imperator_> is that symlink at the wrong dir ?
[18:17:40] <alex_joni> I just had a crashcourse in python :D
[18:17:52] <Imperator_> :-)
[18:17:52] <alex_joni> I did some debugging.. it crashed on my SuSE
[18:17:54] <jepler> Imperator_: emc2/bin/axis should be a symlink to /usr/bin/axis, which is the file installed by "setup.py install".
[18:18:00] <alex_joni> something is fishy with it
[18:18:02] <jepler> I have to go, see all you guys later
[18:18:07] <jmkasunich> Jon: how long can you stay online?
[18:18:09] <Imperator_> don't know anything about pyhton, thats the problem
[18:18:15] <alex_joni> I'll try to make it work for emc2, and I'll talk to you bout it
[18:18:28] <alex_joni> jmk: I'm interested on the drivers issues
[18:18:34] <elson> Oh, I'll be around a while.
[18:18:37] <Imperator_> jepler: chiao
[18:18:52] <Imperator_> thanks for hepling
[18:19:01] <jmkasunich> right - that's why I asked Jon how long he could stay - hopefully he can wait until you wrap up with AXIS
[18:19:27] <alex_joni> I can delay that
[18:19:39] <jmkasunich> wanna talk drivers then?
[18:19:46] <alex_joni> Imperator_ won't mind.. (I hope)
[18:19:51] <jmkasunich> I mean now ;-)
[18:19:59] <alex_joni> yup
[18:20:00] <alex_joni> talk away
[18:20:22] <cradek> I will try to take over helping with AXIS problems
[18:20:34] <alex_joni> can you do that on /msg ?
[18:20:35] <jmkasunich> ok, STG driver (and drivers for Jon's boards) has encoders, outputs (either stepgen or DAC), and digital IO
[18:20:49] <alex_joni> ok so far
[18:20:50] <cradek> let's start another channel #emc_AXIS
[18:20:59] <jmkasunich> thanks
[18:21:06] <alex_joni> ditto
[18:21:08] <alex_joni> ;)
[18:21:16] <jmkasunich> encoder will be similar to encoder.c (with changes)
[18:21:25] <cradek> Imperator_: join me there
[18:21:27] <jmkasunich> digital I/O will be similar to parport
[18:21:36] <alex_joni> there is hal_tiro.c (which has LS7166 in it)
[18:21:49] <alex_joni> and hal_stg.c (for the STG adresses)
[18:21:53] <jmkasunich> yes - forgot about that one
[18:21:55] <alex_joni> almost the same code
[18:22:16] <jmkasunich> code will get cut and pasted from all over the place
[18:22:17] <elson> And, my encoders work prety much the same way as the 7166, too.
[18:22:37] <jmkasunich> but right now I'm talking about how they look to the HAL
[18:22:41] <alex_joni> Jon: can you look at either file?
[18:22:42] <jmkasunich> (pins, params, etc)
[18:23:31] <jmkasunich> * jmkasunich opens encoder.c, tiro.c, hal_parport.c, stepgen.c, and freqgen.c in an editor ;-)
[18:23:39] <elson> hal_stg.c is not in the source generation I have (must be new) but
[18:23:45] <elson> hal_tiro.c is.
[18:23:53] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/src/hal/drivers/hal_stg.c?rev=1.1.2.1&view=markup
[18:24:07] <alex_joni> jmk: sorry it's py again :-)
[18:24:21] <elson> Well, I'm looking at hal_tiro.c now.
[18:24:32] <jmkasunich> * jmkasunich does "cvs up -dP"
[18:24:50] <jmkasunich> and opens stg.c as well ;-)
[18:25:44] <alex_joni> * alex_joni opens HARDMAN1-STG.doc
[18:25:59] <jmkasunich> well that was unexpected
[18:26:11] <elson> where is the bad position suppression done, and where is sign extension done?
[18:26:45] <alex_joni> not done
[18:26:50] <jmkasunich> not yet
[18:27:07] <jmkasunich> ditto for indexing
[18:27:25] <alex_joni> yup
[18:27:30] <alex_joni> and for DACs & IO
[18:27:33] <elson> OK, well those are things that we can worry about later. The overflow extension is what I really meant, that can come later.
[18:28:16] <alex_joni> Jon: as I don't have a STG, I don't know if the code written works
[18:28:16] <elson> The old EMC did NOT change the encoder count value when index was detected, it just reported that the index was seen.
[18:28:40] <jmkasunich> oh, one more thing to open -
http://www.linuxcnc.org/Hal_Introduction.pdf
[18:28:41] <alex_joni> wouldn't want to write the whole driver, and then rewrite it because it wasn't ok
[18:28:47] <elson> Oh, my! Well, I guess at some point I could drag a few boxes
[18:28:57] <elson> around and test it for you.
[18:29:41] <alex_joni> are you familiar with IPulse ?
[18:29:47] <alex_joni> how it's done on the STG?
[18:29:50] <elson> It is possible that there might be some STG I cards floating around that could be borrowed for a while.
[18:30:14] <elson> Of course, ISA slots are getting harder to find, too.
[18:30:27] <elson> IPulse?
[18:30:34] <jmkasunich> I have isa slots here - I would love to be able to borrow an STG
[18:31:01] <alex_joni> index pulse handling
[18:31:14] <jmkasunich> page 51 of Hal_Introduction.pdf
[18:31:31] <jmkasunich> there is a block diagram of the software based encoder counter
[18:31:37] <jmkasunich> (fig 3.7)
[18:31:38] <elson> Yes, I have used the index pulse to refine the home switch position on the boards that I make. It DOES work!
[18:32:12] <jmkasunich> on emc1, it does... not yet on emc2/hal
[18:32:12] <alex_joni> ok, AFAIK index pulse can be implemented in a LOT of ways
[18:32:32] <jmkasunich> you guys see fig 3.7 yet?
[18:32:37] <elson> Yes, that's THE problem! Which way should it be handled? I think this
[18:32:55] <elson> HAS to be standardized for different hardware to keep the HAL
[18:32:58] <alex_joni> I meant first the HW part...
[18:33:04] <elson> interface as consistent as possible.
[18:33:10] <alex_joni> does the index pulse reset the counter or not?
[18:33:17] <jmkasunich> right Jon...
[18:33:22] <alex_joni> should that be an option for HAL to know or not?
[18:33:24] <jmkasunich> alex_joni: that's what we're here to decide
[18:33:36] <elson> You have your choice, both in the 7166-based products and mine.
[18:33:42] <alex_joni> I was just typing the question out loud
[18:33:54] <elson> The old EMC does NOT reset the count. But, the 7166 hardware
[18:34:00] <jmkasunich> the software encoder in encoder.c resets the counter if HAL pin "index_enable" is true
[18:34:02] <alex_joni> ok, so we agree that some cards do the resetting, some don't
[18:34:10] <elson> permits you to set a mode where that WOULD happen. The old EMC
[18:34:27] <elson> would see this as a sudden and potentially large jump in position.
[18:34:28] <jmkasunich> Jon - can you type your whole sentence before hitting return? easier to read that way
[18:35:25] <elson> Yeah, sorry for the confusion - I rarely use IRC.
[18:35:44] <jmkasunich> no prob
[18:35:56] <jmkasunich> another picture:
[18:36:06] <alex_joni> ok, so some HW permit reseting the count, some don't... agreed?
[18:36:13] <elson> So, the point is that if we are going to reset the position counter, EMC is going to have to be able to handle the sudden jump in the count.
[18:36:17] <jmkasunich> yes alex
[18:36:25] <jmkasunich> yes
[18:36:40] <elson> Well, the hardware I have looked at closely ALL permit you to do this.
[18:36:50] <jmkasunich> in fact, we should standardize - even if the HW doesn't reset the count, the driver can emulate a reset
[18:37:07] <jmkasunich> so on the HAL side of the driver, it resets for all drivers
[18:37:18] <jmkasunich> and EMC would then expect that to happen
[18:37:38] <alex_joni> yes, but...
[18:38:00] <elson> Well, I guess it only is important back to the PID code.
[18:38:03] <jmkasunich> another picture -
http://www.linuxcnc.org/EMC2_Code_Notes.pdf, page 10, Fig 3.1
[18:38:12] <alex_joni> we have to bear in mind that the index pulse is used during homing (so it can count how far it overshot the index pulse)
[18:38:33] <jmkasunich> ewww, just realized something
[18:39:02] <jmkasunich> I was thinking that if emc altered it's command at the same time as the FB jumps, that the PID would see no change (because error doesn't change)
[18:39:15] <jmkasunich> but the PID would see a step in the command, and the FF terms would be affected
[18:39:47] <jmkasunich> note that right now, EMC2 does _not_ expect the driver to change it's output when it hits an index pulse
[18:40:09] <elson> Yes, if that is just carried over from the old EMC.
[18:40:25] <jmkasunich> actually, the lowest level of the motion controller is all new
[18:40:32] <jmkasunich> (but keeps some of the same ideas)
[18:40:41] <jmkasunich> homing has been completely rewritten
[18:40:46] <elson> But, if you followed the original math, then it works the same way.
[18:41:08] <jmkasunich> what math? PID stuff?
[18:41:15] <elson> The old homing was as close to impenetrable and anything in EMC :(
[18:41:27] <jmkasunich> that's why I rewrote it from scracth
[18:41:29] <jmkasunich> scratch
[18:41:43] <elson> Yes, basically the whole path from the trajectory to the motion logic.
[18:42:20] <jmkasunich> if you look at EMC2_Code_Notes fig 3.1, you'll see the low level structure for EMC2
[18:42:23] <elson> If anything is going to cause a discontinuity, then you have to prepare the whole system to accomodate it.
[18:42:47] <jmkasunich> during homing, the switch in the middle of that diagram is in the "free mode" position
[18:42:49] <elson> Yes, got that fig on my screen.
[18:42:54] <jmkasunich> free mode is used for jogs, homing, etc
[18:43:09] <jmkasunich> coord mode is used for coordinated motion, like MDI and AUTO
[18:43:35] <jmkasunich> the box labeled free mode traj planner is a simple single axis trapezoid planner
[18:43:53] <elson> Ahh, yes, now I see why the two modes.
[18:43:57] <jmkasunich> set free_pos_cmd, and it goes there, at free_vel_lim
[18:44:16] <jmkasunich> homing is a state machine that simply sets those params to move the axis
[18:45:00] <jmkasunich> and when it finds the home position, it sets "motor_offset" so that pos_fb becomes what it should be
[18:45:09] <elson> Well, the state machine was in EMC before, just that it was in tiny pieces all over the place!
[18:45:13] <jmkasunich> right
[18:45:44] <elson> So, motor offset is a velocity offset or a position offset?
[18:45:52] <jmkasunich> now it is in one place, and clearly designed as a state machine, with #defined state names that actually mean something
[18:46:18] <jmkasunich> position - everything in that disgram is position, except the output from the d/dT block in the center
[18:47:05] <elson> OK, so the PID is down BELOW HAL, now. Yes, I guess I knew that's how we had figured to break it up.
[18:47:07] <jmkasunich> the assumption is that too the right is a PID block, or _something_ that can move a motor to a commanded position
[18:47:38] <elson> OK, so if this jump in position is done in the right sequence, the
[18:47:40] <jmkasunich> to the left is the kinematics transforms, and further to the left is the coordinated mode trajectory planner
[18:48:02] <elson> (oops, sorry) system never actually gets a jump in the loop.
[18:48:07] <alex_joni> * alex_joni is still following...
[18:48:17] <elson> That's amazing!
[18:48:26] <jmkasunich> as it is now, motor_pos_fb (from the right side) never jumps
[18:48:37] <jmkasunich> motor_offset does, when you get to the home position
[18:49:02] <alex_joni> what if both jump?
[18:49:03] <jmkasunich> so pos_fb (leaving to the left) jumps, but that just means the display jumps (to zero, probably)
[18:49:17] <alex_joni> motor_offset and pos_fb
[18:49:25] <elson> Well, maybe this is the way it should be.
[18:49:38] <jmkasunich> if pos_fb jumps, it has problems
[18:49:55] <jmkasunich> (which means you can't have the driver resetting itself)
[18:50:03] <alex_joni> hmm.. the sum (pos_fb) would still be the same
[18:50:04] <elson> Well, it will jump if we reset the pos counter.
[18:50:46] <jmkasunich> pos_fb doesn't need to be stable, in fact it _should_ jump in most cases - it will jump from the original unknown position to the correct home position
[18:51:47] <elson> Then the motor_offset would be set to zero at the same time?
[18:52:01] <alex_joni> so.. during free mode there is no feedback to the traj planer?
[18:52:14] <jmkasunich> there is feedback
[18:52:36] <jmkasunich> in fact "pos_fb" is what drives the display
[18:52:52] <alex_joni> let's take only homing for now
[18:53:03] <jmkasunich> right - the display works during homing too
[18:53:18] <jmkasunich> I've done testing with simulated home and limit switches
[18:53:30] <jmkasunich> the display counts up as the motor moves toward home
[18:53:33] <alex_joni> I know.. but it's not very important what's on the display before homing
[18:53:37] <elson> And, it is fine that the display sees a discontiuity when home is reached.
[18:53:43] <jmkasunich> right
[18:54:02] <jmkasunich> let's back up a step
[18:54:25] <alex_joni> in free mode? or in teleop mode?
[18:54:31] <alex_joni> :-)
[18:54:43] <jmkasunich> the existing EMC2 homing design, and all the rest of the EMC2 motion controller, expects motor_pos_fb to _NEVER_ jump
[18:55:28] <jmkasunich> the drawing is missing some things - like HAL pins on the right side for the home and limit switches, and the index pulse
[18:55:49] <elson> Well, that is the most general solution, since there could someday be an interface that CAN'T load or reset the count on the home pos. But, that could be fixed is SW, too, I guess.
[18:56:15] <jmkasunich> it is general, and kind of cleaner too... there is only one hitch
[18:56:24] <elson> Well, only if sensing these events is NEEDED in this block.
[18:56:36] <elson> OK, what's the hitch?
[18:56:48] <jmkasunich> the existing design polls the home switch or index pulse once per servo cycle
[18:57:00] <jmkasunich> if you are running at less than one count per servo cycle, homing is accurate
[18:57:04] <elson> Ohh, high speed homing! Yup.
[18:57:10] <jmkasunich> you got it!
[18:57:36] <jmkasunich> the only way to do high speed homing is to let the driver handle it - and then you have jumps in motor-pos-fb, and things get messy
[18:57:42] <elson> There'a guy in the Netherlands that has some INSANE encoder on his machine.
[18:58:01] <jmkasunich> Mhz count rates ;-)
[18:58:32] <jmkasunich> the new homing algorithm does have different homing speeds for the initial search for home and the final latching
[18:58:46] <jmkasunich> so you can search fast, then back off, and approach slowly for accuracy
[18:59:20] <jmkasunich> but suppose that it is 1/2 turn of the screw from home switch to index pulse,
[18:59:25] <jmkasunich> you have a 50000 count encoder
[18:59:31] <jmkasunich> and a 1mS servo rate
[18:59:49] <jmkasunich> at one count per servo cycle, it will take you 25 seconds to go from home switch to index pulse
[19:00:14] <jmkasunich> with more mainstream 500 count encoders, it's only 0.25 seconds, not an issue
[19:00:32] <SteveStallings> If you have a 50000 count encoder, your update rate should be faster.
[19:00:36] <elson> Yup, it is more of a problem than I thought. My Bridgeport can easily go over 1 count/servo cycle.
[19:00:58] <jmkasunich> it's not that you can go over
[19:01:14] <jmkasunich> it's whether you need to go over
[19:01:18] <alex_joni> I have a 2500 count encoder -> 10000 counts in the LS
[19:01:30] <jmkasunich> the low speed is only required for the final phase of homing
[19:01:42] <jmkasunich> should only be 1/2 turn of the shaft
[19:02:03] <elson> Well, the old EMC homing cycle is not too good, either. It does
[19:02:09] <jmkasunich> so for alex, the final approach to the index pulse might take 5 seconds
[19:02:36] <elson> (oops) a violent reverse at home speed to the index, then a rather violent halt at home.
[19:02:43] <jmkasunich> the previous phases could happen at full rapid speed, if he wants - it just needs to be able to stop after hitting the switch, before it crashes
[19:03:16] <jmkasunich> new one: move toward home at user configured speed, max_accel stop when hitting the switch
[19:03:34] <elson> Well, you need to have a reasonable deceleration, not just turning the velocity to the opposite sign.
[19:03:35] <jmkasunich> pause 100mS (or 50, don't remember)
[19:03:42] <jmkasunich> then backoff at same speed
[19:03:46] <jmkasunich> pause again
[19:03:57] <SteveStallings> All of the machines I have looked at (Bridgeport and Hardinge with Fanuc) rely on being able to stop the axis in less than the distance between index pulses even during the initial medium speed home travel.
[19:04:02] <jmkasunich> approach at a second user configured speed (slower I hope)
[19:04:35] <jmkasunich> hit switch, and optionally continue on to index, then stop
[19:05:32] <jmkasunich> fig 3.2, on page 21 of EMC2 code notes, has details
[19:05:35] <elson> I think a simpler scheme might work, where you approach fast, decelerate, reverse and search for the index pulse. But, maybe what you suggest is the most flexible.
[19:06:10] <jmkasunich> there are actually four versions, you configure the one you want (see the pic)
[19:06:23] <elson> OK, I see it now!
[19:06:27] <jmkasunich> you are describing the third one
[19:06:57] <jmkasunich> I have always communicated better with drawings - IRC is a real handicap for me
[19:09:55] <jmkasunich> so the real issue here is: do we keep the existing scheme, where motor_pos_fb never jumps and the homing logic is entirely contained in the joint controller (fig 3.1) or do we move part of the homing process into the driver by allowing the driver to reset its counter
[19:10:10] <elson> OK, well, then the home sequence seems to be in hand. So, I need to know what features to code into the driver.
[19:10:51] <elson> I guess we have to move part of it into the driver, to accomodate the higher-speed homing.
[19:10:59] <jmkasunich> right
[19:11:28] <jmkasunich> (we'll also have to be able to reset in the driver to do threading - spindle sync is _not_ something you can slow down for
[19:12:04] <SteveStallings> Don't forget the tandem XX axis setup on gantries.
[19:12:05] <elson> There will be a HAL pin for "home detected", and we expect the position to jump to very close to zero in the very next servo cycle after home detected goes true.
[19:12:07] <jmkasunich> but before we can decide exactly how the driver will do it's thing, we need to figure out how the motion controller is gonna deal with the jumps
[19:12:10] <alex_joni> with higher speed homing you mean: during moving if the index pulse is encountered the count gets reset, so the joint controller will eventually stop the movement, and be homed already ?
[19:13:07] <jmkasunich> its not that simple
[19:13:26] <elson> Yup, tandem axes are a big problem, that is a bear with the old EMC.
[19:13:52] <jmkasunich> tandem axis may well be handled by a revised version of fig 3.1
[19:13:55] <alex_joni> I know in detail it's much more complicated, I just wanted to get a big picture
[19:14:03] <SteveStallings> There was already some discussion a week or two ago on IRC.
[19:14:25] <jmkasunich> I've given serious thought to makeing fig 3.1 a HAL block, so you could swap in a XX one or the standard one
[19:14:30] <jmkasunich> but Paul would probably shoot me
[19:15:35] <SteveStallings> I like it. 8-)
[19:15:39] <jmkasunich> let's ignore XX for now...
[19:15:41] <elson> It may not be necessary. A lower level HAL block could handle what fig 3.1 needs to see, and also split the motor_pos_command for the two axes.
[19:15:58] <jmkasunich> that was the original plan, and it might still work
[19:16:09] <alex_joni> * alex_joni is back in 5 mins
[19:16:13] <jmkasunich> depends on the interaction between fig 3.1 and whatever is to the right of it
[19:16:28] <elson> Oh, of course, this would preclude seeing BOTH encoders from the tandem axis on the screen. (Only needed for diag mode, anyway.)
[19:17:07] <jmkasunich> right - the tandem axis would appear as a single axis to EMC, only in the HAL would you be able to see the two different ones
[19:17:20] <jmkasunich> * jmkasunich needs a couple minutes too
[19:18:06] <elson> When the tandem axis is homed, the two encoders are very nearly the same all the time. The PID is to the right anyway. So, if you do a particular offset for the before/after homing modes, then tandem splitter module could do the same for the 2nd motor/encoder.
[19:20:46] <paul_c> Jon - What do you want to do with your drivers under 2.6 kernel ?
[19:21:16] <jmkasunich> * jmkasunich returns, refreshed....
[19:21:41] <elson> 2.6? For the next BDI? What is involved? Are we talking for the old EMC or EMC2?
[19:22:10] <paul_c> EMC, (emc2 is now where near being ready or BDI)
[19:23:23] <elson> OK, what is needed? I believe I have everything beat into shape so that it compiles and runs OK when put on the BDI-Live! rc46 distro.
[19:24:06] <paul_c> If there s a source file used to build two (or more) object files...
[19:24:32] <paul_c> it is doomed to building one or the other, NOT both.
[19:24:49] <paul_c> So no more #ifdef foo
[19:25:10] <elson> Ugh! I use common c code to build a number of different drivers
[19:25:17] <alex_joni> * alex_joni returns, refreshed.... (:-))
[19:25:23] <paul_c> Can mix #ifdefs for the user space stuff...
[19:25:24] <elson> for 4 and 8-axis versions of 3 different products.
[19:25:48] <jmkasunich> can you do something like this:
[19:25:53] <jmkasunich> driver1.c:
[19:25:58] <jmkasunich> #include common.c
[19:25:58] <elson> So, I have to remove ALL #ifdef?
[19:26:05] <jmkasunich> special stiff
[19:26:08] <jmkasunich> special stuff
[19:26:12] <jmkasunich> end driver1.c
[19:26:15] <jmkasunich> driver2.c
[19:26:25] <jmkasunich> #include common.c
[19:26:28] <jmkasunich> other stuff
[19:26:32] <jmkasunich> end driver2.c
[19:26:39] <jmkasunich> make driver1.o, driver2,o
[19:26:43] <jmkasunich> make driver1.o, driver2.o
[19:26:54] <paul_c> If the #ifdefs are to separate usr & kernel code, it will work
[19:27:24] <jmkasunich> so to be more precise, you can't make two or more kernel modules from one source file?
[19:27:25] <paul_c> but #ifdef STEPPER #else SERVO
[19:27:30] <paul_c> will fail.
[19:27:53] <jmkasunich> driver1.c:
[19:27:57] <jmkasunich> #define SERVO
[19:28:36] <jmkasunich> #include common.c
[19:28:40] <paul_c> One source file in, one object file out - A module can be built from a multitude of object files.
[19:28:43] <jmkasunich> end driver1.c
[19:29:02] <jmkasunich> oh, then it isn't that bad
[19:29:12] <elson> Well, this is going to cause a complete rewrite, from the ground up. I suppose I could just break the commonality, and expand everything to the max. That would generally mean about 12 different drivers to support the device combinations I currently have made work!
[19:29:23] <paul_c> The #ifdefs are in effect handed to the Makefiles
[19:30:52] <jmkasunich> jon - you just need to put the common code in a "library"
[19:30:56] <paul_c> jon - Do you need a 4 axis AND an 8 axis variant, or will a single 8 axis module work for both ?
[19:31:32] <alex_joni> jon.. look at hal_stg for a bit
[19:31:49] <alex_joni> you can define the number of axes handled at insmod time
[19:32:31] <alex_joni> insmod hal_stg num_chan=4
[19:32:34] <elson> No, it is imperative that the driver never try to talk to a board that doesn't exist, after the initial scan. It takes 10 us to timeout for EVERY transfer that is not acknowleged. It will lock up many slower PC's if you let a timeout happen.
[19:32:34] <alex_joni> or
[19:32:37] <jmkasunich> * jmkasunich is on the phone
[19:33:01] <alex_joni> you can try at insmod time to test if the specified axes really exist
[19:33:07] <jmkasunich> the init_module code could do the talking - one attempt only
[19:33:13] <alex_joni> before the RT stuff is started
[19:33:39] <alex_joni> hmmm.. it's been a while ;)
[19:33:46] <alex_joni> hello zwisk
[19:33:51] <zwisk> it has... Hard to find these days. Hello all!
[19:34:00] <zwisk> erm.... find time that is...
[19:34:06] <elson> To make the code as efficient as possible, with an absolute minimum of if's, I did it ALL by #ifdef and conditional compiles. I did make one version that can adapt to an extra DAC for spindle speed control, and disable that function if the board was not there.
[19:34:52] <paul_c> OK, so If we ignore the 4 & 8 axis #ifdefs for the moment
[19:35:01] <elson> Yup, making the modules more flexible and sensing the config is a good idea. The cost of a few ifs is a lot less now.
[19:35:12] <paul_c> how much else is #ifdefed ?
[19:35:53] <alex_joni> zwisk: how much time do you have now?
[19:36:08] <zwisk> great question... probably an hour or so....
[19:36:30] <elson> Ohhhhh, man, just count em! Lots! But, every one of these modules (for encoder, I/O and velocity command) has 4 and 8 axis ifdefs, and most have ifdefs for the particular version of the device (PPMC, USC or UPC).
[19:38:12] <alex_joni> Jon: when I wrote the first part I did it per axis basis
[19:38:14] <elson> ppmc_encoder has 12 #ifdefs (not all for my purposes, some of it is for user-mode test versions.)
[19:38:25] <alex_joni> I know it's not the best thing (speed-wise)
[19:38:36] <alex_joni> because 2-axes could be addressed at once
[19:39:17] <alex_joni> but like this it's more generic
[19:39:23] <cradek> can you use the preprocessor to generate the many files before the makefile builds them into objects?
[19:39:38] <alex_joni> and the code doesn't really care if you have 4 or 6 or 8 axes
[19:39:59] <elson> There are performance reasons why it is done all at once. It takes one bus transaction to set the address. Then you can read 12 bytes (4 axes x 3 bytes of position per axis) with 12 CPU instructions. So, that's how I do it.
[19:40:31] <alex_joni> I agree (performance-wise)
[19:41:11] <alex_joni> I'm not really sure gcc doesn't do some optimising aswell (break out the for, and do the transactions faster)
[19:41:33] <jmkasunich> but modern machines can probably execute 20-50 instructions while waiting for each parport byte
[19:41:41] <elson> Yup, using the preprocessor, assuming that the right flavor of ifdef's can be acted upon, might be fine. Or, I could just make it look a lot more like the STG, with one big driver block for all the functions of one board.
[19:41:44] <paul_c> looks like ppmc_dio.c is the worst...
[19:42:45] <elson> Yes, ppmc_dio.c IS the worst, becaus the register configuration is different on two of the products. The encoder is register-identical on all 3.
[19:43:19] <elson> But, the way the IEEE-1284 works is that the CPU is in a wait state
[19:43:33] <elson> until the transaction completes. (oops)
[19:43:54] <elson> Keep hitting that darn enter key at the end of the line.
[19:44:07] <jmkasunich> s'ok
[19:45:17] <elson> Anyway, putting the fast CPU in the wait state is pretty gross, but it does allow a handshaked byte transfer to be done very fast (now down to 600 ns or so with a PCI parallel port card or MoBo built-in port.)
[19:46:23] <jmkasunich> 600nS = 600 instructions :-(
[19:48:18] <elson> Yeah, but since it is a RT process, there's not a whole lot else you can really do during that time. I suppose you could have some really horrible threaded code checking the I/O every few instructions, but the checking is slow, since it is outside the CPU, anyway. And, all the branches would kill you, too.
[19:48:34] <jmkasunich> right
[19:49:06] <jmkasunich> but it points out that the bus transactions are the bottleneck
[19:50:19] <elson> Nothing you can do about that, except graft the parallel port to the inside of the CPU!
[19:50:33] <paul_c> ppmc_dio.c has two, maybe four #ifdefs in total that would need a work-round
[19:50:34] <alex_joni> lol
[19:51:00] <elson> I can still do 10 KHz servo updates on a 333 MHz Pentium 2, on 4
[19:51:00] <alex_joni> you could take some wires from the processor to the stepper
[19:51:12] <elson> axes, at less than 50% utilization.
[19:51:53] <elson> OK, Paul, thanks for looking at that. That sounds about right.
[19:52:09] <paul_c> Jon - The 4 or 8 axis #ifdefs can be worked round...
[19:52:34] <paul_c> even the univ_step #ifdefs have a solution...
[19:53:16] <elson> I think the short term solution is probably to try to make 4 versions, right now. PPMC 4 and 8 axes (maybe I can do that with one version that checks the config) and a USC and UPC version. That would only be 3!
[19:53:50] <paul_c> wots USC & UPC ?
[19:53:56] <jmkasunich> nobody likes my trick with the #include, eh?
[19:54:09] <elson> ppmc.h also has an ifdef.
[19:54:24] <jmkasunich> universal stepper controler, universal pwm controler
[19:54:32] <elson> The 3 products I have now are : 1. PPMC - analog servo board set
[19:54:38] <paul_c> jmkasunich: Missed the suggesion...
[19:54:41] <elson> 2. USC Universal Stepper COntroller
[19:54:52] <elson> 3. UPC Universal PWM servo controller
[19:55:42] <jmkasunich> very short C files that set the #defines and #include the common stuff
[19:55:53] <jmkasunich> the makefile would make the shorties
[19:56:21] <jmkasunich> so from makes perspective, they are all different files
[19:57:26] <paul_c> nah... Use sed & awk to generate the source files on the fly.
[19:57:51] <jmkasunich> ;-)
[19:58:21] <alex_joni> how bout make configure figure out the hardware?
[19:58:31] <alex_joni> and output the source files to make the hardware work?
[19:59:06] <paul_c> Fine if you have the hardware hooked up to the build box
[19:59:20] <elson> Ugh, then the user has to RECOMPILE if he changes the config? I wouldn't wish that on an ENEMY! Sensing the config at start-up time would be much better.
[19:59:41] <alex_joni> * alex_joni wonders why nobody noticed he was kidding....
[20:00:08] <paul_c> * paul_c hits alex_joni with the old trout
[20:00:32] <SteveStallings> 8-) too good!!!!
[20:00:50] <alex_joni> * alex_joni threw the trout to his cat
[20:01:07] <jmkasunich> besides, this is emc1 we're talking about - some folks don't even use configure for it
[20:02:09] <alex_joni> thought we started talking about HAL...?
[20:02:17] <elson> We WERE!
[20:02:55] <jmkasunich> but Paul came in with his 2.6 question while I was on the phone
[20:02:59] <paul_c> Same rules would apply for 2.6 kernels and emc2
[20:03:03] <jmkasunich> we've been talking about that ever since
[20:03:19] <paul_c> No kernel level #ifdefs
[20:03:30] <jmkasunich> the driver for HAL will be completely different anyway, and I expect we'll find a better way to deal with such issues
[20:04:06] <paul_c> I need to switch screens for a bit.
[20:04:21] <an0n> hello everyone
[20:04:26] <alex_joni> hello
[20:04:29] <jmkasunich> hi
[20:04:29] <an0n> ltns
[20:04:35] <jmkasunich> ?
[20:05:34] <paul_c> * paul_c is away: on another screen
[20:05:50] <jmkasunich> alex, jon... where were we
[20:06:16] <alex_joni> #ifdefs are going away
[20:06:25] <ve7it> greetings from Nanoose Bay BC, Canada... just getting irc setup so hope I dont mess up too badly.
[20:06:52] <elson> No #ifdefs in the future? Yikes!
[20:06:58] <jmkasunich> no....
[20:07:05] <alex_joni> no?
[20:07:08] <dave-e> greeting neighbor to the north ... Selah. WA
[20:07:16] <jmkasunich> #ifdefs are _NOT_ going away
[20:07:27] <alex_joni> greetings from Timisoara, RO (far away from Canada)
[20:07:39] <elson> OK, just in kernel code, then.
[20:07:39] <CIA-11> 03cradek * 10emc2/src/emc/task/emctaskmain.cc:
[20:07:39] <CIA-11> In the last version Paul applied this patch by hand but put the fix
[20:07:39] <CIA-11> in the wrong spot. You are in a twisty maze of passages, all alike.
[20:08:05] <jmkasunich> paul is referring to the fact that you can build only one kernel module from any given source file under 2.6 kernels (actually the 2.6 kernel make system)
[20:08:19] <jmkasunich> so you apparently can't do thisL
[20:08:36] <alex_joni> I see..
[20:08:37] <jmkasunich> gcc -DVERSION1 foo.c -o foo1.o
[20:08:49] <jmkasunich> gcc -DVERSION2 foo.c -o foo2.o
[20:09:00] <elson> OK, so this is a version tracking sort of problem, not the ifdef
[20:09:03] <elson> itself.
[20:09:24] <jmkasunich> but IMO a properly designed HAL driver for Jon's cards will figure out what it has without needing foo1-12.o
[20:09:36] <alex_joni> anyways.. we can put that stuff on hold, and return to the hal stuff
[20:09:38] <alex_joni> and the drivers
[20:09:50] <jmkasunich> gcc -DPPMV foo.c -o ppmc.o
[20:09:58] <jmkasunich> gcc -DPPMC foo.c -o ppmc.o
[20:10:08] <jmkasunich> gcc -DUSC foo.c -o usc.o
[20:10:15] <jmkasunich> not really versions per se
[20:10:27] <jmkasunich> disregard the PPMV one, I can't type
[20:10:28] <elson> Now, how does that apply to a kenel module built from a bunch of c files? Is it the first one that gets "linked" to the module?
[20:10:46] <jmkasunich> damned if I know - I've done nothing with 2.6
[20:11:15] <elson> OK, doesn't really matter, just wondering what the real interaction is.
[20:11:32] <jmkasunich> IMHO, it is onlyan issue for EMC1, because that code is already written and will require massaging
[20:11:56] <jmkasunich> for EMC2, the code isn't written yet, so as long as there is some planning, it can be made 2.6 compatible from the beginning
[20:12:03] <elson> Well, it certainly makes a difference in the code I throw together for EMC2, also!
[20:12:45] <jmkasunich> for HAL, I expect you will want three drivers - ppmc, usc, and upc
[20:12:52] <elson> Right.
[20:12:59] <jmkasunich> the insmod code will be responsible for figuring out everything else
[20:13:11] <elson> Anyway, where did we leave the homing issue?
[20:13:33] <jmkasunich> I'm having a heck of a time remembering - phone call and digressions hurt my brain
[20:13:40] <jmkasunich> * jmkasunich scrolls back
[20:14:17] <elson> Well, I think we figured out that the encoder routine needs to reset the position to zero when it is at home.
[20:14:26] <jmkasunich> not quite...
[20:14:41] <elson> Yes, I know there is more to it.
[20:14:43] <alex_joni> and the traj planner needs to accept some position changes
[20:15:03] <jmkasunich> the encoder driver needs to be able to reset the it's position feedback to zero when it sees and index pulse AND the motion controller has enabled the index
[20:15:30] <jmkasunich> and as alex said, the motion controller needs to be able to deal with that
[20:15:32] <elson> Right, only when in the search_for_index mode.
[20:15:44] <alex_joni> I agree
[20:15:57] <jmkasunich> but that functionality will be used for threading too
[20:16:19] <jmkasunich> going back to figure 3.7 in HAL_Introduction.pdf
[20:16:26] <elson> So, does there need to be a different mode for spindle axes, or can it be the same?
[20:16:36] <jmkasunich> the driver should be the same (I hope)
[20:17:25] <elson> I'm seeing a big blank space, but no fig 3.7
[20:17:45] <jmkasunich> hmmm that's not good
[20:18:01] <elson> Yes, same driver, but would it be a different mode sent through the pin, or the same?
[20:18:37] <jmkasunich> should look like: header "3.4 Encoder", then one paragraph, the figure, then header "Installing"
[20:18:56] <jmkasunich> IMO, drivers shouldn't know about things like "modes"
[20:19:18] <jmkasunich> an encoder is an encoder is an encoder, only the higher level code should know that one encoder is on a spindle and another is on a leadscrew
[20:19:32] <elson> That's where I see fig 3.2
[20:19:58] <elson> Well, the search_for_home is a "mode", it seems to me.
[20:20:05] <jmkasunich> go to the very first page, what is the date there?
[20:20:23] <elson> 5 sep 2004
[20:20:25] <jmkasunich> only EMC knows about search for home, the driver doesn't
[20:20:44] <jmkasunich> 5 oct here
[20:20:54] <jmkasunich> * jmkasunich FTPs the latest to linuxcnc.org
[20:20:58] <elson> Then, how does it reset the pos counter to zero when the index is seen?
[20:21:12] <jmkasunich> index_enable is set (by emc)
[20:21:27] <jmkasunich> that tells it that is should reset to zero on the next rising edge of index
[20:21:50] <elson> Hmm, I am loading it from linuxcnc.org, and did a reload to be sure.
[20:22:09] <jmkasunich> just checked the site, the file there is dated oct 5
[20:22:27] <elson> OK, so index_enable is a "mode", then. I used the wrong term.
[20:22:55] <jmkasunich> it's just a terminology thing - one of my strongest goals with HAL is that drivers should be generic
[20:22:56] <elson> this is the URL I'm using :
http://www.linuxcnc.org/EMC2_Code_Notes.pdf
[20:23:20] <alex_joni> me too.. still 5th September
[20:23:33] <jmkasunich> there are two docs... the fig 3.7 is in Hal_Introduction.pdf
[20:23:42] <jmkasunich> (sorry I wasn't more clear about that)
[20:24:23] <jmkasunich> fig 3.7 is on page 51 of the Hal_Intro doc
[20:24:37] <jmkasunich> the others we were looking at earlier are in EMC2_Code_Notes
[20:25:26] <elson> OK, see that fig now.
[20:25:39] <jmkasunich> that is the existing SW based encoder counter
[20:26:01] <jmkasunich> but HW based ones should look similar, on the left side where they connect to the HAL
[20:26:14] <jmkasunich> the right side is where they connect to hardware, and will be completely different
[20:26:41] <jmkasunich> (most everything right of the dashed line will actually be in hardware, there will be no "update_count()" function
[20:26:48] <alex_joni> don't think most will have a right side
[20:26:55] <alex_joni> at least not exported to HAL
[20:26:58] <jmkasunich> right
[20:26:59] <elson> OK, well, I just need to know what to code, but the index handling can be left mostly for later determination.
[20:27:30] <jmkasunich> if you don't care about indexing, you can just base it on the tiro driver
[20:27:41] <elson> OK
[20:27:43] <jmkasunich> but indexing is a big issue, one that needs fixed
[20:28:16] <elson> Yes, it is key to soem of the things that we want to do with EMC2's new capabilities.
[20:28:29] <jmkasunich> the existing driver (fig 3.7) isn't neccessarily what we want - we need to decide what it should really look like - because it will be the template for future hardware based drivers
[20:29:07] <alex_joni> btw, position-scale is an HAL-parameter (which can be changed during runtime)
[20:29:24] <jmkasunich> right
[20:29:44] <jmkasunich> I should explain that, in case Jon isn't aware
[20:30:14] <jmkasunich> in all these HAL block diagrams, a box like <position| that penetrates the "wall" is a HAL pin
[20:30:35] <jmkasunich> a box like |position-scale| that is inside the box is a HAL parameter
[20:31:00] <SteveStallings> Would it help with homing speed operations if the encoder module could capture the count instead of reset it upon index?
[20:31:03] <jmkasunich> parameters can be changed at runtime (and are usually set from the ini file
[20:31:06] <elson> A "parameter" is like a local variable?
[20:31:33] <jmkasunich> yes, except that you can view/modify it using a command line utility
[20:31:44] <elson> No, Steve, because the encoder module is only run once per servo cycle.
[20:31:46] <jmkasunich> and even capture it with halscope
[20:32:13] <jmkasunich> if the _hardware_ could capture the count, that would be nice
[20:32:18] <jmkasunich> but not all hardware can do that
[20:32:24] <elson> The hardware in the encoder counter can reset the count (or latch
[20:32:34] <SteveStallings> OK, I was thinking hardware capture....
[20:32:38] <elson> it, for that matter) in continuous time, or nearly so.
[20:33:01] <jmkasunich> the issue again becomes how does emc use that information
[20:33:28] <elson> The LS7166 doesn't have a separate register to hold the count at index pulse time, but it could use the latch. But, that is tripped every servo cycle.
[20:33:33] <jmkasunich> allowing a jump in feedback gets really ugly - the more I look at it, the uglier it gets
[20:35:22] <jmkasunich> position feedback goes not only to the joint controller (fig 3.1 in EMC2CodeNotes) but also direct to the PID loop
[20:35:33] <alex_joni> ouch
[20:35:43] <elson> Yeah, I was afraid of that. There is another option, at least with hardware.
[20:36:28] <jmkasunich> what is that?
[20:36:40] <elson> If you shut off the loop, you can just run at constant velocity, and dedicate the latch for capturing the index count.
[20:37:31] <jmkasunich> I thought about that... but it implies even more widely scattered knowledge of what EMC is doing... the PID loop also needs to know
[20:37:33] <elson> All of my devices have the option to run in velocity mode, just by writing the same value to the velocity register during the home.
[20:38:19] <elson> No, during that, you shut OFF the PID, or just ignore its output, and feed the velocity your own value.
[20:38:46] <jmkasunich> right... so you need a switch, that goes between the PID output and the DAC
[20:40:29] <jmkasunich> I fear I may be fighting a losing battle
[20:40:42] <elson> Right. And, the axis that has been set to index_enable will ignore the latch_encoder command, and only latch when it gets the index pulse.
[20:40:51] <jmkasunich> one of my main goals was to be able to break a machine control into independent chunks
[20:41:18] <jmkasunich> the motor control chunk would simply be given a position and go there, meanwhile reporting back it's current position
[20:41:51] <elson> Yes, but these interactions are pretty necessary. It causes some significant restrictions of you can't do it the "best" way.
[20:42:01] <elson> "if you can't...
[20:42:05] <jmkasunich> that chunk could be PID + DAC + encoder, or PID + freqgen, or stepgen alone, or ...
[20:43:19] <alex_joni> * alex_joni wonders why we got here...
[20:43:37] <alex_joni> where did the whole thing start?
[20:44:00] <jmkasunich> cause I knew that the existing method (no feedback jumps) was gonna make people unhappy sooner or later
[20:44:24] <alex_joni> what if there is no feedback jump?
[20:44:25] <jmkasunich> and to fix that implies revising encoder.c, which will be the template for all other encoders
[20:44:56] <jmkasunich> if there is no feedback jump, it works fine, but you can't do "fast homing", where you are getting more than one encoder count per servo cycle
[20:45:10] <alex_joni> let's say the encoder handles the offset from the index pulse
[20:45:36] <alex_joni> maybe a second count?
[20:45:43] <jmkasunich> I don't follow you
[20:45:49] <alex_joni> ok.. like this:
[20:45:56] <elson> How does it do that. We are stuck with what is in the LS7166 chip for boards that use that.
[20:46:10] <alex_joni> in SW ?
[20:46:40] <alex_joni> check that output has zero-ed
[20:46:47] <alex_joni> but don't export to hal
[20:46:57] <alex_joni> export the last value+current output
[20:47:03] <elson> That doesn't do me or any of the other users of hardware encoder counters any good. (I guess I could add functions to my boards, but I don't want to have to update a bunch of units in the field.)
[20:47:19] <alex_joni> not HW, only in SW
[20:47:22] <jmkasunich> no Jon, he's talking about things that the driver would do
[20:47:36] <alex_joni> don't know if it's doable
[20:48:02] <alex_joni> jmk: did you get what I'm meaning?
[20:48:17] <jmkasunich> I think so, I'm trying to wrap my head around it
[20:48:19] <elson> OK, but how does the driver do this? It is only sampling the counter every millisecond or whatever.
[20:48:41] <jmkasunich> is there a bit that tells us that the index has happened?
[20:48:43] <alex_joni> yes.. the driver knows it's in homing mode
[20:48:52] <jmkasunich> I mean a bit from the hardware
[20:49:16] <alex_joni> there is some info from the LS7166, but I'm positive that not all have that bit
[20:49:26] <alex_joni> so that's not generic enough
[20:49:32] <elson> The count suddenly jumps from a larger value to a small value, maybe <|20|
[20:49:33] <jmkasunich> so how do you know you hit the index then?
[20:49:43] <alex_joni> what Jon said
[20:49:49] <jmkasunich> what if the original position was only off by 1 or two counts
[20:50:18] <jmkasunich> if you see 1000,1010,1020,4,14,24, then you know it reset
[20:50:36] <elson> So, yes, you now KNOW the distance from index, as that is the count, and there is a bit that tells you index was seen, if that was in doubt. But, you still have to fake the count to the HAL pin to avoid a discontinuity.
[20:50:37] <jmkasunich> but what if you see -18, -8, 4, 14, 24?
[20:51:11] <jmkasunich> the question I was asking is "is there always a bit that tells you index was seen?" (to deal with the doubt)
[20:51:12] <alex_joni> got your point ...
[20:51:43] <elson> I think there IS a bit for that, yes. My hardware has it, and I pretty much followed the LS7166.
[20:52:00] <alex_joni> for the LS's there is...
[20:52:10] <alex_joni> but for generic... I don't know
[20:52:22] <alex_joni> let's say somebody builds a board with normal counters...
[20:52:23] <jmkasunich> because of the ambiguity, I would expect that it is neccessary
[20:53:01] <jmkasunich> hmmm... if the hardware counter can be reset on an index pulse, the doesn't mean that it gets reset on _every_ index pulse
[20:53:17] <jmkasunich> there must be a bit that you set to "arm" it, to reset on the next index
[20:53:59] <elson> Yes, there is the "arming" bit
[20:54:15] <alex_joni> there is a "mode" for the LS to do that
[20:54:16] <jmkasunich> does the arming bit get automatically cleared once you hit the index?
[20:54:35] <jmkasunich> or do you have to disarm it before the next index comes around?
[20:55:04] <elson> Umm, probably not! But, the index sensing is EDGE activated, so it responds to the RISING edge, only.
[20:55:21] <alex_joni> afaik it works only once
[20:55:21] <jmkasunich> right, and one rev later there will be another rising edge
[20:55:34] <elson> But, yes, you'd need to disable before the NEXT index pulse (next revolution).
[20:55:35] <alex_joni> you need to set it up again in order to make it work
[20:55:50] <jmkasunich> so right there we have two possibilities for the hardware
[20:56:03] <alex_joni> * alex_joni takes out the LS pdf
[20:56:05] <jmkasunich> alex_joni: auto-disarm, you need to explicitly arm it before it will reset again
[20:56:17] <alex_joni> jmk: not sure I'm right
[20:56:21] <jmkasunich> jon: no auto-disarm, if you don't disarm it it will reset every time
[20:56:53] <jmkasunich> doesn't matter who is right - we can't count on either one, because sooner or later there will be hardware that each way
[20:57:04] <jmkasunich> (different drivers for each way, of course)
[20:57:38] <jmkasunich> if there is auto-disarm, the clearing of that bit is the indicator that an index has arrived
[20:57:48] <jmkasunich> if not, there must be a different indicator
[20:58:00] <jmkasunich> so you know it is time to disarm
[20:58:58] <elson> I don't see this "auto-disarm" in the LS7266 documents. But, could be present in the LS7166. I don't have such a feature.
[20:59:13] <elson> And, I'm being called to lunch! I'll keep logging.
[20:59:18] <jmkasunich> ok, doesn't matter
[20:59:42] <jmkasunich> but our driver should pick one way (whichever we feel is better), and emulate it for hardware that works the other way
[20:59:55] <jmkasunich> * jmkasunich is torn
[21:00:00] <alex_joni> jmk: no disarm in LS
[21:00:10] <jmkasunich> I really _like_ the "no jumping feedbacK"
[21:00:21] <alex_joni> I think disarm should always be done
[21:00:28] <alex_joni> even if it's no code there
[21:00:36] <alex_joni> after index has been found of course
[21:00:42] <alex_joni> there would be 2 things to do
[21:00:50] <alex_joni> 1. disarm the index reset
[21:00:53] <jmkasunich> but "jumping feedback" is probably better
[21:01:08] <alex_joni> 2. let hal know that the index has been tripped
[21:01:27] <jmkasunich> yes
[21:01:43] <jmkasunich> I was thinking about two HAL pins on the left side of figure 3.7
[21:01:55] <jmkasunich> index_enable and index_latched
[21:02:08] <alex_joni> index_enable input to encoder
[21:02:13] <jmkasunich> rising edge of index_enable arms the latch
[21:02:14] <alex_joni> index_latched output
[21:02:18] <jmkasunich> yes
[21:02:39] <jmkasunich> falling edge of index enable disarms the latch
[21:03:03] <jmkasunich> rising edge of index input while armed resets counter and sets index_latched
[21:03:23] <jmkasunich> falling edge of index_enable clears index_latched
[21:03:36] <jmkasunich> does that make sense (again, I wish I could draw a picture)
[21:03:47] <alex_joni> no need for pictures
[21:03:53] <alex_joni> that makes perfectly sense
[21:03:57] <jmkasunich> I think better with pictures
[21:04:00] <jmkasunich> ;-)
[21:04:03] <alex_joni> I imagine a OR-gate
[21:04:16] <alex_joni> input from index-enable and from index-input
[21:04:22] <alex_joni> output to counter-reset
[21:04:32] <alex_joni> maybe NAND is more appropiate
[21:05:03] <jmkasunich> I was thinking more of a 7474 D flipflop
[21:05:08] <jmkasunich> index_input to clock
[21:05:10] <jmkasunich> D tied hi
[21:05:34] <jmkasunich> index_enable to RESET/
[21:05:43] <jmkasunich> index_latched is the Q output
[21:05:53] <jmkasunich> and a rising edge on index_latched resets the counter
[21:06:06] <SteveStallings> Still wondering if having a realtime encoder count and a "latched at last index" count would allow the motion code to chose jumpy or not on index. If there is no hardware latch, the resolution is no worse than if it did not emulate the counter latch.
[21:06:11] <alex_joni> yeah that too... (that even latches)
[21:07:03] <jmkasunich> SteveStallings: much hardware including the 7166 wouldn't let you do that
[21:08:00] <SteveStallings> .... looking up datasheets....
[21:08:58] <jmkasunich> I think it has _one_ "snapshot" register that can capture the value of the counter
[21:09:19] <jmkasunich> you can decide if you want it to be captured on an index pulse, or simply captured when you are ready to read it, but not both
[21:10:26] <jmkasunich> for several reasons, I think it is better to make the driver reset the output when the index happens... I just have to figure out how to keep the PID from getting flummoxxed by that
[21:10:47] <alex_joni> jmk: I think I'll leave now...
[21:10:58] <alex_joni> keep writing to IRC, I'll read tomorrow
[21:10:59] <jmkasunich> running away? ;-)
[21:11:18] <alex_joni> going to sleep
[21:11:24] <jmkasunich> ok... goodnight
[21:12:10] <jmkasunich> * jmkasunich ponders
[21:12:38] <jmkasunich> a spindle encoder driver _must_ reset to zero on the index pulse at least once in a while, otherwise it just keeps getting bigger and bigger
[21:12:55] <alex_joni> how about resetting every-time?
[21:13:14] <jmkasunich> for a spindle? or an axis? or both?
[21:13:21] <alex_joni> configurable
[21:13:40] <jmkasunich> spindle probably would not want to reset during a threading pass, it would reset right before the pass starts
[21:13:51] <jmkasunich> axis would only want to reset during homing
[21:15:07] <alex_joni> yup
[21:15:57] <alex_joni> I really like this AXIS thingy ;)
[21:16:03] <jmkasunich> I think all encoder drivers should try to emulate the "index_enable"/"index_latched" 74LS74 logic we just discussed
[21:16:28] <jmkasunich> and the homing logic and joint controller needs to be modified to deal with that
[21:16:31] <alex_joni> what for drivers (HW) without index_pulse?
[21:16:49] <jmkasunich> then they can't home on an index, they home on switch only
[21:17:21] <alex_joni> I thought so, but where does that stated?
[21:17:33] <alex_joni> wrong expression
[21:17:39] <elson> Right about the reset spindle just before threading pass, that's how I was thinking it should work.
[21:17:56] <alex_joni> how does the driver know? (it just doesn't get the index_enable?)
[21:18:04] <alex_joni> based on the stuff in the inifile?
[21:18:37] <jmkasunich> yes - index_enable for the encoder driver would be driven by a pin that leaves the right side of the joint controller (fig 3.1 EMC2CodeNotes)
[21:19:12] <jmkasunich> if the hardware doesn't support index pulses, the driver won't have an index_enable pin, and the joint controller pin won't be connected to anything
[21:19:35] <jmkasunich> there is a parameter "use_index" in the joint controller that decides whether it will be used
[21:22:01] <alex_joni> sounds about right
[21:22:28] <alex_joni> but PID needs adjustments..right?
[21:22:47] <SteveStallings> OK... I give up..... no support for capture the count. I'm beginning to seriously doubt if these folks (US Digital) have a clue about realtime. First the rollover glitches now this.
[21:23:36] <alex_joni> steve: the only thing there is
[21:23:49] <elson> I STILL don't know if the LS7166 rollover glitches are truly in the LS7166, or in the STG boards. (Although I suspect it IS the LS7166.)
[21:23:58] <alex_joni> is to connect the index pulse to the reset input of the counter (on the LS7x66)
[21:24:33] <alex_joni> Jon: can you describe the rollover glitch?
[21:24:35] <elson> I think that reset can be done INSIDE the chip, by a control reg setting.
[21:24:56] <alex_joni> but where do you connect the index pulse?
[21:25:16] <elson> I managed to trap this years ago with the EMC logging/graphing function. We had a problem with the sefvos "clicking" every once in a while.
[21:25:44] <elson> I had a problem with one of my axes being more sensitive, and causing an amp fault from these clicks.
[21:25:52] <alex_joni> I see
[21:26:14] <elson> I found out that it did it a lot worse when the machine was left at its startup position (where the encoder counter was zeroed).
[21:27:05] <elson> I believe it was a problem with the latch capturing the count before the 24-bit carry ripple had propagated across all bits. This should not happen, but it apparently does.
[21:27:41] <alex_joni> I think I read about this on some list (or maybe IRC log)
[21:27:53] <elson> So, you'd get a transition from, say 00000000 00000000 00000000 to, say 00000111 11111111 11111111.
[21:28:21] <elson> The next sample was always OK, either back to zero, or all 1's.
[21:29:07] <alex_joni> I see, but there is code inside emc to do more checks on faulty values
[21:29:09] <alex_joni> right?
[21:29:17] <elson> So, a software filter that supresses a count value that is impossibly too far from the last reading.
[21:29:28] <elson> Yes.
[21:29:53] <alex_joni> ok.. back to the resetting
[21:30:06] <elson> yes.
[21:30:15] <alex_joni> resetting the LS7266 can be done in 2 ways (from the index_pulse)
[21:31:02] <jmkasunich> was away for a minute
[21:31:23] <jmkasunich> That software filter that rejects bad sample - that should be in the driver, not in EMC
[21:31:27] <alex_joni> either connect the index_pulse to /RCNTR (resets the counter on index_pulse)
[21:32:13] <alex_joni> or connect it to /LCNTR/LOL (load counter on index_pulse)
[21:32:41] <jmkasunich> that can load a non-zero value into the counter?
[21:32:59] <elson> John, agee the filter should be in the driver. BUT! It needs to know the maximum velocity the system is theoretically capable of!
[21:33:08] <jmkasunich> not really
[21:33:10] <elson> More complexity and interconnection.
[21:33:28] <alex_joni> jmk: not loading a non-zero value into the counter, but...
[21:33:39] <alex_joni> it's actually a little bit more complex for the LS's
[21:33:46] <alex_joni> there is the 24-bit counter
[21:33:54] <alex_joni> and there is a 24-bit register
[21:33:59] <elson> Yes, the LCNTR can load a non-zero value from the preset reg. I have the same function in my boards.
[21:34:07] <jmkasunich> a more elegant solution is for it to keep track of velocity itself (difference between successive samples) and reject anything that represents an impossible change in velocity
[21:34:28] <elson> Yes, that might also work.
[21:34:49] <alex_joni> in order to read the value from the LS the counter gets copied to the register
[21:34:55] <jmkasunich> you could say "that just requires you to know max_accel instead of max_vel"
[21:35:14] <alex_joni> and then it gets read from the pc (because of more accesses needed)
[21:35:39] <alex_joni> so the value doesn't change during the read (which would imply a tainted read)
[21:35:48] <jmkasunich> right alex, that avoids you reading the LSB and then a count happening before you read the MSB
[21:35:56] <alex_joni> ok: so for index_pulse there are 3 vars.
[21:36:11] <alex_joni> 1. tie it to RCNTR (then counter gets reseted)
[21:36:38] <alex_joni> 2. tie it to /LCNTR/LOL (configured as /LCNTR)- (then the value from counter gets loaded to the register)
[21:36:57] <alex_joni> 3. tie it to /LCNTR/LOL (configured as /LOL)- (then the value from register gets loaded to the counter)
[21:37:04] <jmkasunich> oh - _to_ the register - a snapshot
[21:37:17] <alex_joni> yes
[21:37:22] <jmkasunich> which one did the STG people do?
[21:37:41] <alex_joni> I think it's software changeable (as long as the index_pulse is connected to this pin)
[21:38:04] <jmkasunich> but if index is connected to RCNTR then you can't
[21:39:07] <elson> STG is totally configurable. You don't "connect" wires on the outside of the chip, you steer the signals with the indec control reg, inside the chip.
[21:39:42] <jmkasunich> ok, so RCNTR and LCNTR/LOL aren't really physical pins?
[21:40:04] <jmkasunich> or are they physical pins, both connected to index_pulse, but configured inside?
[21:42:24] <jmkasunich> guess it doesn't really matter
[21:42:30] <alex_joni> * alex_joni doesn't know
[21:43:01] <paul_c> * paul_c is back
[21:43:11] <jmkasunich> comes down to "how badly will a jump on motor_pos_fb" affect the PID loop
[21:43:50] <jmkasunich> assuming "motor_pos_cmd" jumps the same ammount at the same time
[21:43:52] <elson> John, I can't find the index control register in the STG manual.
[21:44:10] <jmkasunich> error will remain small, it's only the FF terms that will mess things up
[21:46:01] <elson> Maybe you need to suppress the FF terms when in index_enable mode.
[21:46:39] <jmkasunich> gets right back to undesired coupling between modules
[21:48:22] <alex_joni> paul: any luck on the packages?
[21:48:52] <paul_c> Testing a new build - Didn't save as much space as I'd hoped..
[21:49:18] <alex_joni> :(
[21:49:32] <alex_joni> how bout a DVD-boot disk for BDI ?
[21:49:35] <alex_joni> :-)
[21:49:54] <paul_c> You wanna do one ?
[21:50:17] <alex_joni> hmmm... not different from a CD-one
[21:50:24] <alex_joni> is it?
[21:50:43] <jmkasunich> DVD drives aren't exactly common in machine controller class PCs
[21:51:01] <alex_joni> so weren't CD-s a few years back ;)
[21:51:03] <paul_c> just an increase in the size of the comps.xml
[21:51:12] <paul_c> by an order of magnitude
[21:51:34] <alex_joni> hmmm.. short question
[21:51:38] <jmkasunich> so in a few more years, we'll be ready for DVD based BDI
[21:51:43] <alex_joni> on the other extreme...
[21:51:52] <alex_joni> how small could a running image get?
[21:51:58] <jmkasunich> machine control - pushing the trailing edge of technology
[21:53:19] <jmkasunich> how small depends on how much cruft you are willing to do without
[21:53:30] <jmkasunich> like X, for starters ;-)
[21:53:54] <alex_joni> there are X-distro's in 16 MB
[21:54:14] <jmkasunich> 16MB ram, or disk?
[21:54:41] <alex_joni> http://jailbait.sourceforge.net/
[21:54:45] <alex_joni> disk
[21:54:53] <jmkasunich> cool
[21:55:14] <paul_c> Then there are minimal distros on single floppies
[21:55:52] <alex_joni> yeah..
[21:56:07] <alex_joni> even X-ones (I've seen a 2 floppy X-windows one)
[21:56:20] <paul_c> If you off load the GUI on to another box, you don't need much space
[21:57:23] <paul_c> Use busybox, and you might be able to use a single floppy
[21:57:46] <jmkasunich> busybox with a RT kernel on one floppy would be cool
[21:58:19] <jmkasunich> busybox is the "usual" cmd line stuff, like bash, grep, ls, etc?
[21:58:39] <elson> well, I think maybe we need to digest the home/index implications and maybe work on it some more later. Meanwhile, I'll keep trying to put together a simple encoder driver.
[21:58:53] <paul_c> a minimal shell and core utillities only.
[21:58:54] <jmkasunich> same here - need to think on it
[21:59:06] <elson> And, I think I'm going to sign off, and try to build some boards.
[21:59:15] <jmkasunich> for a simple driver, look at tiro.c
[21:59:29] <elson> Right, I have seen it. Thanks.
[21:59:37] <alex_joni> I need to sleep on it... :-)
[22:02:04] <paul_c> Looks like the new build is OK
[22:04:09] <CIA-11> 03Zathras 07BDI build system * 10Babylon Cluster/comps.xml: File changed. New revision:picax.xml
[22:05:33] <alex_joni> paul: great
[22:05:42] <alex_joni> * alex_joni is worn out...
[22:05:43] <alex_joni> bye
[22:05:48] <robin_sz> ello
[22:05:57] <paul_c> buggerit...
[22:05:57] <robin_sz> hes gorn ...
[22:06:06] <robin_sz> hi paul
[22:06:30] <paul_c> * paul_c was going to send him an ISO as an attachment
[22:06:45] <robin_sz> * robin_sz returns from yet another day of metal bashing
[22:08:52] <Imperator_> paul_c: the next BDI is it also Knoppix based ??
[22:09:18] <paul_c> No
[22:09:41] <robin_sz> debian?
[22:09:52] <paul_c> It is a merging of BDI-2.xx and the Morphix stuff
[22:10:27] <paul_c> Using the BDI-2.xx installer with Debian packaging.
[22:11:38] <robin_sz> interesting
[22:11:45] <robin_sz> in a pervy sort of way
[22:12:05] <robin_sz> has debian released Sarge as stable yet?
[22:12:15] <Imperator_> what is the reason for choosing the debain installer ??
[22:13:18] <paul_c> The instaler is from Red Hat (originally)
[22:14:01] <paul_c> From what I've seen of the Debian installers, they suck.
[22:18:18] <robin_sz> I've had fair success with them, especially the net based installs
[22:20:39] <Imperator_> is the new one then also runing without installing, like the Morphix CD's ?
[22:20:49] <robin_sz> is it possible just to do a normal debain install, add an emc foo to the sources list and then install the 'emc-run' package set over the net?
[22:21:06] <robin_sz> in theory it should be ... just drops in a new kernael and the other stuff
[22:21:21] <Imperator_> the realtime stuff is the problem i think
[22:22:17] <paul_c> You need a repository with pre-built kernels
[22:23:16] <robin_sz> presumably you have those for the distor anyway?
[22:23:19] <robin_sz> distro
[22:23:50] <paul_c> yup
[22:24:00] <paul_c> and emc packaged up
[22:24:34] <robin_sz> so its just a question of slapping em up somewhere and running that package lister whatsit?
[22:24:40] <Imperator_> and is it runnig without installing Paul ???
[22:25:16] <paul_c> Imperator_: No, you have to do an install to HD first
[22:25:31] <Imperator_> ok
[22:27:10] <Imperator_> robin_sz: this time i have switched on the light all the time during the building process. So this time you can see what it build's
[22:27:11] <Imperator_> http://cimweb.cim.fh-aalen.de/Menue/RapidProto/stereo/camera.html
[22:27:14] <paul_c> will probably do a slimmed down Live for testing purposes
[22:27:37] <Imperator_> also morphix based ?
[22:28:07] <paul_c> Yes - Will try to get it down to 50Meg
[22:29:02] <Imperator_> how many MB did fit on thos small CD's ???
[22:29:11] <robin_sz> ooh, cute .. look!
[22:29:14] <robin_sz> its making ...
[22:29:16] <robin_sz> well ...
[22:29:21] <robin_sz> a grren thing
[22:29:23] <Imperator_> :-)
[22:29:41] <robin_sz> UV laser?
[22:30:16] <robin_sz> heh, its got a windscreen wiper!
[22:30:17] <Imperator_> 360nm or so
[22:30:32] <robin_sz> right
[22:30:59] <Imperator_> a doctorplade sweeper :-)
[22:31:31] <robin_sz> is that removing stuff or laying doen a new layer of goo for the laser to play with?
[22:32:27] <Imperator_> Ok : The sixty-four-dollar question what is it, if it is ready ????
[22:33:17] <robin_sz> dunno, the java push stuff stopped after a minute or so in a broken sort of way :(
[22:33:38] <Imperator_> after lighting you can see that it goes down. then the resin flood over it. then it comes up again. the sweeper has then to remove the resin that is too much
[22:33:51] <robin_sz> ah right
[22:33:55] <Imperator_> jep you have to reload sometimes
[22:34:08] <robin_sz> thats Java for you
[22:34:09] <Imperator_> with mozilla it is much better than with IE
[22:34:28] <robin_sz> * robin_sz has Netscape 7.2
[22:34:32] <Imperator_> because mozilla can do server push
[22:34:43] <Imperator_> that's the same
[22:34:57] <robin_sz> ach, stopped again after the wiper blade
[22:35:19] <robin_sz> is that your Java, or soemting pre-built?
[22:35:24] <Imperator_> hm, with my mozilla it is quiet stable
[22:36:34] <Imperator_> or try it with IE if you are on Windows
[22:37:39] <robin_sz> * robin_sz takes it apart to see how it works
[22:37:58] <Imperator_> heyyyyyyyyyyyyyyyyyyyyyyyyy i have Axis running
[22:38:41] <Imperator_> after updating Readhat 7.2 to maybe Readhat 20
[22:39:35] <robin_sz> Imperator_: did you do the java, or is it a commercial product?
[22:39:36] <Imperator_> cradek: it is working now !!!!!
[22:40:16] <Imperator_> it is Webcam 32 a comercial software, but not that expensive
[22:40:58] <robin_sz> looks quite nicely written
[22:41:01] <Imperator_> it is running good on windowsNT and newer
[22:44:24] <Imperator_> the Java applet has mainly the problem that it doesen't read the proxi setup if a user is behind a proxi
[22:44:24] <robin_sz> right
[22:44:24] <Imperator_> on Netscape/Mozilla it works with server push that is much better
[22:44:24] <Imperator_> and you have nearly no problems with firewalls
[22:44:33] <robin_sz> so, it has its own little webservery thing to run on the server?
[22:45:26] <robin_sz> seems to use a mime type thats porbably not normally supported
[22:45:27] <robin_sz> printwriter.write("GET /video/javacampush WEBCAM32/1.0\n");
[22:45:32] <cradek> Imperator_: yay!!
[22:45:43] <Imperator_> cradek: :-)
[22:45:46] <robin_sz> anyway, thats quite neough Java talk
[22:45:54] <robin_sz> OK, so what exactly do you have running?
[22:45:56] <Imperator_> but you a right a P166 is too slow
[22:46:23] <cradek> at about 10x that speed it works great
[22:46:31] <Imperator_> :-)
[22:46:57] <cradek> it will be a little better if you turn off the tool cone
[22:48:00] <Imperator_> robin_sz: it has his own webserver, and we are running each cam on a own box. We had putted in the past 3 cams on one box but that makes too much problems and we have enough old computers
[22:48:13] <robin_sz> * robin_sz nods
[22:48:47] <robin_sz> arrgrhhh NOOOOOOOO!
[22:49:25] <Imperator_> robin_sz: ?????
[22:49:36] <Imperator_> cradek: how can I do that ?
[22:50:03] <robin_sz> Imperator_: Janet Street-porter has been voted off 'Im a celebrity, get me out of here'
[22:50:12] <robin_sz> Imperator_: that is a disaster
[22:50:36] <robin_sz> Imperator_: I was hoping one of the other contestants was going to murder her in her sleep for being irritating.
[22:50:51] <Imperator_> oh kids
[22:51:14] <Imperator_> I am happy that my TV has burend ayear before
[22:51:27] <robin_sz> mine went to the tip 5 years ago
[22:52:02] <robin_sz> but, Id have been happy beyond belief of a nasty death came to janet street-porte, horrible whining bag that she is.
[22:52:06] <Imperator_> but I haven't bought a new one :-)
[22:52:11] <robin_sz> like wise.
[22:57:18] <Imperator_> abouth the stereolithographie: the good thing is that Father Christmas was here and he brought us a new one. It is already in the lab, on january we install it, maybe also with a webcam
[22:57:44] <robin_sz> waht was it being made?
[22:58:04] <Imperator_> at the moment ?
[22:59:03] <robin_sz> on the webcam
[22:59:09] <Imperator_> a replika of a skull
[22:59:14] <robin_sz> heh :)
[22:59:16] <robin_sz> how ...
[22:59:18] <robin_sz> handy
[22:59:26] <Imperator_> ???
[22:59:41] <robin_sz> is that the sort of thing its normally used for?
[22:59:45] <robin_sz> body bits?
[23:00:00] <Imperator_> no technical prototypes
[23:00:13] <robin_sz> so the skull is just for fun then?
[23:00:18] <Imperator_> useless stupid plastic parts
[23:00:43] <Imperator_> no we have a research project about that
[23:00:46] <robin_sz> kewl
[23:01:23] <Imperator_> we have also a CT at teh university, with that we are scanning them
[23:01:41] <robin_sz> mmmm ... magnets
[23:02:11] <Imperator_> X-Ray
[23:02:22] <Imperator_> or how it is called
[23:02:54] <robin_sz> * robin_sz thought it was big magnets and an array of aerials and stuff
[23:02:59] <robin_sz> but hey, what do I know
[23:03:10] <robin_sz> or is that NMR?
[23:04:38] <Imperator_> maybe that is the one with the magnets
[23:05:32] <Imperator_> computer tomograph
[23:05:43] <Imperator_> is it called here
[23:10:52] <robin_sz> yeah
[23:11:25] <CIA-11> 03Zathras 07BDI build system * 10Babylon Cluster/ks.cfg: File changed. New revision:1.2
[23:11:35] <robin_sz> looks like I picked up a nice little project to make a 2 axis X Y thing for a local printing company
[23:12:54] <robin_sz> theres not a huge budget, but, it should be enough and leave some .. profit even :)
[23:13:53] <robin_sz> are we any closer to cheap servo/encoder cards for EMC? .. I do look occasioanlly but always seems to be 500 quid plus
[23:14:44] <paul_c> <$500
[23:14:55] <robin_sz> the vital card is that?
[23:15:56] <robin_sz> isnt Alex Joni working on some sort of cheap card?
[23:16:11] <paul_c> well.... $575 for the 8 axis version.
[23:16:41] <robin_sz> thats certainly competetive
[23:17:26] <Imperator_> I#m also working on something like that, but very slowly. Now a other german guy want's to help, maybe that speeds it up a bit
[23:17:36] <Imperator_> Alex has also something
[23:18:06] <robin_sz> yeah, we need somehting cheap
[23:18:08] <Imperator_> but search for a cheap DAC ISA card and use the software counters
[23:18:16] <paul_c> Alex is/was working on a PC104 card
[23:18:25] <robin_sz> oh,
[23:18:34] <robin_sz> not so handy for most people i guess
[23:18:35] <Imperator_> realy cheap was my siemens card 8 EUR
[23:18:41] <robin_sz> heh
[23:18:51] <robin_sz> did you get a driver working?
[23:19:01] <Imperator_> more or less
[23:19:24] <Imperator_> i had the chance to get 120 peaces of it but i was to slow
[23:19:44] <Imperator_> somwbody has bought them
[23:19:51] <robin_sz> I can buy commercial 4 axis controllers, with a usb connection and all the control and stuff onboard for 600 GBP
[23:20:21] <robin_sz> so,
[23:20:42] <robin_sz> you can see emc needs some nice cheap hardware to be attractive to hobbyists
[23:21:29] <Imperator_> GBP ?? Brit. pound ???
[23:21:37] <robin_sz> yeah
[23:21:49] <Imperator_> 900 EUR !!!!
[23:21:56] <robin_sz> yeah
[23:22:14] <cradek> Imperator_: in the edit menu
[23:22:24] <Imperator_> industiel quality !!
[23:22:34] <robin_sz> yeah, Baldor
[23:22:51] <robin_sz> thats NOT including drives though
[23:22:53] <Imperator_> ok cradek
[23:23:45] <Imperator_> not so bad, because for that plug in cards you need some additional hardware like optocopplers ....
[23:24:36] <robin_sz> yeah, the 900 EUR thing is quite neat, has 32 IO and various other stuff too
[23:26:52] <Imperator_> cradek: how can i move the view ???
[23:26:59] <robin_sz> oh 7 axis servo, 32 IO, 12 bit analogue (1 out, 2 in), serial, USB ...
[23:27:04] <robin_sz> http://www.baldor.com/products/motioncontrol/nmesb.asp
[23:29:54] <asdfqwega> * asdfqwega waves
[23:30:19] <robin_sz> * robin_sz waves back
[23:30:56] <asdfqwega> Now that I've seen the latest screenshots, I simply MUST try AXIS
[23:31:17] <robin_sz> the downside to thos controlelrs is yo end up spending at least that amount again on an HMI if you need one
[23:31:52] <Imperator_> jep
[23:32:02] <Imperator_> but it looks not so bad.
[23:32:07] <asdfqwega> * asdfqwega lurks - cleaning shop
[23:32:32] <Imperator_> but it depends also on how fast you get it running :-)
[23:32:38] <paul_c> www.baldor breaks if you don't dend it a browser ID
[23:36:11] <robin_sz> heh
[23:36:31] <robin_sz> why make websites so difficult eh?
[23:36:49] <robin_sz> just code em up in compliant html and bobs your autnies live-in lover
[23:37:22] <paul_c> and keep java out of the equation too.
[23:40:28] <robin_sz> itr has its uses
[23:40:41] <robin_sz> like whatshis names camera thing
[23:40:53] <robin_sz> but generally, its as you say, not needed
[23:41:00] <robin_sz> esp. for navigation
[23:41:54] <paul_c> Imperator_'s camera doesn't work (for me)
[23:42:23] <Imperator_> what browser are you using ?
[23:43:05] <paul_c> Konqueror 3.2.2
[23:43:16] <robin_sz> pah,
[23:43:22] <cradek> Imperator_: pan with the left mouse button, rotate with middle, zoom with right
[23:43:35] <cradek> Imperator_: or, there are preset views on the toolbar
[23:43:47] <Imperator_> ok cradek
[23:43:56] <Imperator_> Paul do you also have mozilla ?
[23:43:58] <cradek> asdfqwega: what's stopping you from trying it??
[23:44:22] <paul_c> Imperator_: nope
[23:44:30] <Imperator_> Hm
[23:44:44] <Imperator_> is java enabled ?
[23:44:58] <robin_sz> Konqueror rartely works with most modern websites, ive really no idea why KDE insist on trying to code their own browser
[23:45:06] <robin_sz> Imperator_: is it heck
[23:45:18] <paul_c> java enabled.
[23:45:46] <robin_sz> never worked for me
[23:46:13] <Imperator_> hm, maybe if you say to konqueror it has to say it is a IE
[23:46:27] <Imperator_> then it loads the java applet
[23:46:42] <Imperator_> because on mozilla it is runing with server push
[23:47:36] <robin_sz> does Konqueror have tabbed browsing in its latest incarnation?
[23:48:26] <Imperator_> our webside makes a difference if it is Netscape/mozilla or IE
[23:49:21] <Imperator_> on Ie it loads the java applet because it can't do server push, but that fails if you are behind a proxie
[23:51:25] <Imperator_> ok have to go to bed
[23:51:49] <Imperator_> chiao
[23:52:29] <robin_sz> ok ... so
[23:52:45] <robin_sz> you know those 'digimatic' style digital verniers?
[23:52:58] <robin_sz> HTF do they work then?
[23:53:25] <robin_sz> is there a little wheel an a quadrature deetector?
[23:53:58] <paul_c> capacative effect
[23:54:13] <robin_sz> the scale has some weirdness under it?
[23:54:27] <robin_sz> I can vaguely see some sort of 'fingers'
[23:55:34] <robin_sz> but they seem quite coarse, maybe 0.5mm spacing ...
[23:59:27] <robin_sz> anyway, theres a nice Mitutoyo 8" one on eBay ...