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: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: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:11:47 <asdfqwega> asdfqwega has left #emc
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:18:36 <ottos> ottos has quit
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: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: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: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: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: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: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: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: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... :-)
21:59:54 <elson> elson has quit
22:02:04 <paul_c> Looks like the new build is OK
22:05:33 <alex_joni> paul: great
22:05:38 <robin_sz> robin_sz has joined #emc
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: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:18 <asdfqwega> asdfqwega has joined #emc
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:51:52 <Imperator_> Imperator_ has quit
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 ...