Back
[00:00:03] <paul_c> Have about 3mm clearance on three sides
[00:00:14] <alex_joni> ok.. so 2xLS7266; 16 x I; 16 x O; (how bout 4 DACs ;)
[00:00:39] <paul_c> All on one PC104 card ??
[00:00:53] <alex_joni> don't think they can be fitted
[00:00:59] <robin_sz> sure?
[00:01:03] <robin_sz> surface mount?
[00:01:05] <alex_joni> LS-through hole
[00:01:17] <alex_joni> IO can be SM
[00:01:28] <robin_sz> all can be sm surely?
[00:01:29] <alex_joni> DAC's maybe too
[00:01:47] <alex_joni> there must be some connectors
[00:01:58] <alex_joni> I'll give it a try...
[00:02:04] <paul_c> Hmmm.. 82C55 surface mount, and two LS7266 in 24DIP package
[00:02:20] <alex_joni> you want 82C55 for IO?
[00:02:51] <paul_c> bit dated...
[00:03:06] <alex_joni> I did the first one with plain 74HC574's
[00:03:55] <robin_sz> I'd be suprised if it needed a whol pc104 for just that ... should be a snap in smd
[00:04:29] <paul_c> one little FPGA could do it all..
[00:04:30] <alex_joni> robin: hmmm... there are a lot of chips...
[00:04:35] <alex_joni> that's true
[00:04:40] <alex_joni> but the LS's are better
[00:04:58] <robin_sz> 7266's are available smd
[00:05:18] <alex_joni> well.. I'll call you to change them when they are broken
[00:05:36] <alex_joni> without breaking stuff around them
[00:05:48] <paul_c> But don't use the laser to get them off the board.
[00:06:01] <robin_sz> easier than than changing through-hole
[00:06:03] <alex_joni> although that's not such a bad idea
[00:06:16] <alex_joni> I always mount through-hole on sockets
[00:06:37] <robin_sz> anyway, why should they break more than any other chip?
[00:07:02] <alex_joni> because... they are connected to the outside world
[00:07:08] <alex_joni> and it's such a cruel world out there...
[00:07:10] <alex_joni> :D
[00:07:17] <robin_sz> heh :)
[00:07:33] <alex_joni> I usually optocouple the LS's as well ;)
[00:07:57] <alex_joni> but I found that they usually brake if you don't get voltages right (forget to tie one unused pin and stuff like that)
[00:08:04] <robin_sz> having done a little production engineering on this sort of stuff, I just think smd these days. through hole is too costly to consider in most apps
[00:08:17] <alex_joni> * alex_joni is cursing STG's arrangement of ports
[00:08:30] <alex_joni> not for prototypes...
[00:08:33] <alex_joni> or small series
[00:08:56] <robin_sz> true, but its expensive in board space
[00:08:57] <alex_joni> you gotta bear in mind one major factor I have to consider is availability
[00:09:12] <alex_joni> I ain't got no Farnell around the corner
[00:09:23] <robin_sz> they deliver europe wide
[00:09:33] <alex_joni> down here it can take up to 2 weeks delivery on a chip
[00:09:42] <robin_sz> wheres down here again?
[00:09:44] <alex_joni> and small stuff I get delivered only 500+
[00:09:49] <alex_joni> romania ;)
[00:09:52] <robin_sz> ah yes.
[00:09:57] <alex_joni> or even 50+
[00:10:04] <alex_joni> when I just need one damn piece
[00:10:15] <robin_sz> I think my last resistor order was 150K pieces :)
[00:11:03] <robin_sz> suffice it to say, farnell where a 'little' more expensive than the others at that volume
[00:11:25] <alex_joni> little?
[00:11:36] <alex_joni> stuff from farnell is usually 50% more then others :D
[00:11:49] <robin_sz> well, like double or more in those quantities
[00:12:49] <robin_sz> I'm paying around 1.60 a thousand for 1206 size resistors at the moment
[00:13:02] <alex_joni> nice
[00:13:47] <robin_sz> remember how you keep leaded resistors noce and tidy, because they cost money?
[00:14:15] <robin_sz> well, chip R's you can pop em out the tape feeders just to check they feed nicely
[00:14:34] <robin_sz> run out 50 or more and its still less than 1 leaded resistor
[00:15:27] <CIA-5> 03paul_c * 10emc/src/emcmot/ppmc_aio.c: Ran this file through dos2unix to get rid of M$ line terminators.
[00:17:25] <paul_c> Note for any budding driver authors - Don't use a single source to build different variants. It won't work with kbuild.
[00:17:59] <alex_joni> what do you mean with diff variants?
[00:18:18] <paul_c> #ifdef build_stepper
[00:18:31] <paul_c> #else // build a servo module
[00:18:34] <paul_c> #endif
[00:18:36] <alex_joni> I see
[00:20:07] <paul_c> there are tricks to work round the problem, but it may break in later kernel versions
[00:20:35] <robin_sz> eek.
[00:21:00] <robin_sz> did we agree a #if/#endif protocol for the code?
[00:21:04] <paul_c> however, you can build kernel modules and user space apps from the same source files.
[00:21:29] <robin_sz> like 'more than 5 levels of nesting, shot at dawn
[00:21:44] <robin_sz> 8 levels, hung, drawn and quartered
[00:21:53] <paul_c> shot on sight for nore than two levels.
[00:22:01] <robin_sz> right.
[00:22:07] <robin_sz> harsh, but fair.
[00:22:27] <paul_c> 5 levels will get you removed from the list.
[00:22:45] <robin_sz> I fear we may have a very small list :
[00:22:47] <robin_sz> )
[00:23:10] <robin_sz> also, while we're on ...
[00:23:11] <paul_c> 8 levels, and you'll be forced to work on an XP box for the rest of your natural.
[00:23:24] <robin_sz> now now, xp aitn that bad
[00:23:50] <paul_c> msdos-3.2 thaen
[00:24:02] <robin_sz> ah that aitn that bad either :)
[00:24:12] <robin_sz> win 95, 98, ME ..
[00:24:12] <paul_c> with USB keyboards
[00:24:23] <robin_sz> win 3.1
[00:24:27] <robin_sz> now .. thats BAD
[00:24:34] <rayh> paul_c: Installing 3.01 now.
[00:24:40] <paul_c> wanna copy of Win-1.2 ?
[00:24:42] <robin_sz> anyway ...
[00:24:45] <robin_sz> I need ..
[00:24:53] <robin_sz> a bridgport stepper motor ..
[00:25:00] <robin_sz> one of the big finned things
[00:25:03] <paul_c> rayh: Duff burn ?
[00:25:10] <robin_sz> looks like a pineapple on acid
[00:25:22] <paul_c> NEMA42
[00:25:33] <robin_sz> bigger I think ...
[00:25:37] <rayh> Yep. Still can't read it on the box I wanted but others will okay.
[00:25:52] <robin_sz> old series 1 thing
[00:25:56] <paul_c> only ever seen them attached to a couple of tons of scrap iron.
[00:26:03] <robin_sz> thats them!
[00:26:05] <rayh> Might be something with the via 800 MiniITX mb.
[00:27:11] <paul_c> rayh: It's probably the boot kernel not set up for the VIA chip.
[00:27:27] <rayh> Seems like the installer asked english three times and standard or custom install twice.
[00:27:55] <paul_c> will need to recompile without some of the Intel options...
[00:28:14] <rayh> That could be but rc45 works fine.
[00:28:24] <rayh> As does the 2xx stuff.
[00:28:41] <robin_sz> ooh, Interact 720 HV? any good?
[00:28:47] <paul_c> 2.6.x is compiled with IOAPIC enabled
[00:29:07] <paul_c> and 686 processor
[00:29:26] <robin_sz> looks nice, 20 station tool changer
[00:29:30] <robin_sz> 1400 notes
[00:29:32] <paul_c> rc46 and BDI-2.xx are 586 only as I recall.
[00:29:44] <alex_joni> my last laptop crashed when local-APIC was enabled
[00:30:20] <paul_c> * paul_c makes a note to recompile the boot & install kernels without PAIC support.
[00:30:31] <paul_c> or even APIC
[00:30:45] <alex_joni> gotta love PAIC
[00:31:43] <rayh> the proc says that it's a 6.
[00:32:07] <rayh> I think you did have a 5x86 def in 45.
[00:34:44] <alex_joni> what's the mod sign in .c again?
[00:34:46] <alex_joni> % ?
[00:37:13] <rayh> I like the watts furniture logo.
[00:38:02] <paul_c> alex_joni: yes
[00:38:28] <rayh> Who's indexer is that -- cutting gears?
[00:40:25] <paul_c> Hal May - photgraphed by Dan.
[00:40:47] <rayh> Oh. I thought it might be. Great shot.
[00:41:36] <paul_c> Can add more to the slideshow, but do need to watch the overall size
[00:41:58] <paul_c> too many large images, and will run out of space for the installer.
[00:42:21] <rayh> Right.
[00:42:35] <rayh> 25 minutes remaining.
[00:43:03] <paul_c> install is a little slower than an RPM based distro
[00:43:26] <alex_joni> paul: is the new BDI available for download?
[00:43:57] <paul_c> nope - Ray is testing a very beta version.
[00:44:30] <alex_joni> I see... I wanna test too... ;)
[00:45:03] <paul_c> Don't want to appear rude...
[00:45:16] <alex_joni> don't worry
[00:45:17] <alex_joni> ;)
[00:45:22] <paul_c> but downloading an ISO hits my bandwith bad.
[00:45:32] <alex_joni> ohh.. I see..
[00:45:40] <alex_joni> if you need mirror space....
[00:45:43] <rayh> I've got to do a bit more arm twisting with the guy in town.
[00:46:01] <paul_c> At the moment, I'm doing a 34Gig update of my Debian mirror
[00:46:18] <rayh> If I can get him to do downloads, perhaps I can get him to put it up on his t1.
[00:46:18] <alex_joni> yuck
[00:46:31] <paul_c> Space isn't the problem, it's bandwidth I need.
[00:46:47] <alex_joni> I could put BDI-s at college (on a 150 MBit)
[00:47:04] <paul_c> bit faster than my 128K up.
[00:47:08] <alex_joni> deb mirror is there already
[00:47:22] <rayh> When you are ready for a trial release, I'm thinking maybe we can put it on his company site.
[00:47:57] <alex_joni> ftp://ftp.timisoara.roedu.net/mirrors/
[00:48:03] <paul_c> Will have to rebuild a couple of kernel packages, and then roll EMC in
[00:48:51] <paul_c> The RTAI package is now in two halfs...
[00:49:02] <rayh> I did notice that on the via box, I saw a deb page on boot. Huge lettering.
[00:49:20] <rayh> On the athalon box it did not show -- only text.
[00:49:37] <paul_c> Bootsplash...
[00:49:57] <rayh> Why did it not come up on the athalon.
[00:50:05] <paul_c> dunno...
[00:50:23] <paul_c> what graphics card is in the Athlon box?
[00:50:24] <rayh> All of these boxes are video in RAM.
[00:50:36] <rayh> Let me look.
[00:51:14] <CIA-5> 03alex_joni * 10emc2/src/hal/drivers/hal_stg.c: Started the STG driver. this is pre-alpha right now. some encoder feedback should be available. The rest (DAC, IO) will follow.
[00:52:58] <rayh> sis 660
[00:53:08] <paul_c> Ug.
[00:53:19] <rayh> Trident cyberblade on the via.
[00:53:43] <rayh> The sis works fine for 46, Suse, and knoppix.
[00:54:07] <rayh> We'll see how 3.01 looks in about 10 minutes.
[00:54:19] <alex_joni> ok... guess I'll call it a day
[00:54:33] <alex_joni> night guys
[00:54:41] <rayh> see you.
[00:57:26] <paul_c> Which SuSE version are you running ?
[01:01:10] <rayh> 9.1 enterprise server.
[01:01:45] <paul_c> with a stock 2.6 kernel ?
[01:01:59] <rayh> Yep. No real-time yet.
[01:02:37] <paul_c> I'll take a look at the config on my laptop and compare with the boot & install kernels.
[01:03:14] <rayh> 4 minutes.
[01:04:18] <paul_c> Don't believe the time estimates - It is probably way out.
[01:07:01] <rayh> "An unhabndled exception has occurred....
[01:07:58] <paul_c> fsckit - Can you save the debug to floppy ?
[01:09:38] <rayh> I can try.
[01:11:20] <rayh> Nope won't save it. I can transcribe it here.
[01:11:45] <rayh> Nope it died when I pressed cancel.
[01:11:51] <paul_c> The last line ?
[01:12:08] <rayh> could not find GRUB runtime files.
[01:12:51] <paul_c> OK - Sound's like grub didn't get selected for install.
[01:13:01] <rayh> I'll boot up knoppix and have a look round.
[01:13:28] <paul_c> There may be a couple of logs in /root
[01:14:00] <rayh> k
[01:16:24] <rayh> Knoppix uses LILO but I'd bet i could add 3.01 to it.
[01:17:56] <rayh> in /root there is anacdump.txt (1.2MB) install.log(21.7 KB) and install.log.syslog (1.2 KB)
[01:18:22] <paul_c> anacdump.txt is the debug log
[01:19:02] <rayh> the install log is just complaining about not finding some postfix.sendmail stuff.
[01:19:03] <paul_c> The other two will also have some usefull info about the package selections
[01:19:44] <rayh> install.log says 456 packages.
[01:20:28] <paul_c> Is grub in the selected package list ?
[01:21:00] <rayh> grub not found.
[01:21:40] <paul_c> Any chance you could zip those three files up and mail them over ?
[01:22:24] <rayh> I can try.
[01:22:41] <rayh> tar okay?
[01:22:49] <paul_c> yup
[01:23:10] <paul_c> tgz, bz2, or zip...
[01:24:01] <paul_c> I'll look at it first thing in the morning.
[01:24:59] <paul_c> time for me to slide off to bed.
[01:25:00] <robin_sz> I would like to say thankyou ... to all the zoos and circuses whose kind loan of monkeys has made the testing of EMC2 possible
[02:32:45] <jepler> hm .. I had installed bdi-46 last week, and was able to run sherline_inch without any actual hardware connected
[02:32:56] <jepler> I reinstalled bdi-46 and running sherline_inch says something about "amplifier fault"
[02:33:17] <jepler> I really only need to run in sim mode, but there's no sim.run / sim.ini on bdi
[02:33:48] <jepler> any idea what's going on?
[02:39:29] <jepler> well, I copied sim.* from another machine and got going
[12:09:27] <alex_joni> hello
[13:23:49] <jepler> huh, pretty quiet night. Morning all.
[13:24:36] <alex_joni> gmorning jepler
[13:26:27] <jepler> alex_joni: what's new?
[13:27:02] <alex_joni> nuttin much
[13:27:07] <alex_joni> it's a free day here
[13:27:11] <alex_joni> national day ;)
[13:27:38] <alex_joni> I started a stg driver for emc2, but lacking a STG board I can only write blindly ;)
[13:28:07] <jepler> Why write a driver for a board you don't have?
[13:28:19] <alex_joni> because it'll help emc2 ;)
[13:28:47] <alex_joni> and because the encoder part is pretty similar to the one on my board (I already wrote that driver)
[13:29:20] <alex_joni> emc2 is pretty nice, but without hardware support it's pretty useless for a lot of people
[13:34:09] <jepler> What Linux distro do you use? I'm working on my new backplotter, and I've been concentrating on getting it to run on RedHat 9 and on BDI-46 (because I have easy access to them), but really I have no idea what most people are using.
[13:36:37] <jepler> (and on fedora core 2, as a ngc-file previewer)
[13:41:17] <alex_joni> I am using SuSE 8.2
[13:42:17] <alex_joni> but that's because I had troubles installing BDI on my hardware
[13:42:40] <alex_joni> and at home (also SuSE 8.2) it was easier for me to patch the kernel and install EMC, than reinstall everything
[13:42:55] <alex_joni> but I plan to switch to the next BDI (deb based)
[13:43:22] <jepler> do you know what version of Python is installed on that system? Do you know if SuSE has a python-opengl package you could install?
[13:43:37] <alex_joni> give me a moment
[13:45:09] <alex_joni> python-opengl-2.0.0.44-87.i586.rpm
[13:46:13] <alex_joni> and a few othe python packeges (around 10-15)
[13:46:26] <alex_joni> taken from ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/i386/8.2/suse/i586/
[13:48:11] <alex_joni> python-opengl-2.0.0.44-395.i586.rpm on the SuSE 9.1
[13:49:16] <alex_joni> jepler: short question, did you play with tar ?
[13:49:28] <alex_joni> * alex_joni is wondering how to make incremental backups using tar
[13:53:31] <jepler> I don't know much about tar
[13:53:42] <paul_c> man tar
[13:53:48] <jepler> when I make backups, it's of the form "burn my home directory on 20 CDs"
[13:54:08] <alex_joni> I do have a tar -cvzf in cron.weekly
[13:55:27] <jepler> alex_joni: and the version of Python? python 2.2.x? 2.3.x?
[13:55:37] <jepler> alex_joni: thanks for the info
[13:55:37] <alex_joni> cd /home && for i in * do tar -cvzf /backup/$i.tgz $i done
[14:01:26] <paul_c> use j in place of z and replace tgz with bz2
[14:02:35] <paul_c> as long as you have bzip2 installed...
[14:04:44] <alex_joni> is bz2 better than gz?
[14:04:56] <alex_joni> I really like gz because I have gz support on M$
[14:05:13] <alex_joni> no bzip2 on M$ (at least not standard)
[14:05:49] <alex_joni> jepler: python-2.2.2-92.i586.rpm
[14:05:55] <alex_joni> on SuSE 8.2
[14:06:44] <alex_joni> sorry it took so long but I just copied 12 GB of backups
[14:18:00] <jepler> bz2 is 10-20% better than gz on many types of files.
[14:18:04] <jepler> For example:
[14:18:05] <jepler> -rw-rw-r-- 1 anthony webmaster 7840762 Nov 30 03:18 Python-2.4.tar.bz2
[14:18:05] <jepler> -rw-rw-r-- 1 anthony webmaster 9198035 Nov 30 03:27 Python-2.4.tgz
[14:42:05] <cradek> alex_joni: for anything more complex than what you have, you (in my opinion) should be using dump and its built-in incremental support
[14:44:58] <cradek> dump -0af - /home |bzip2 >/backup/home.dump.bz2
[14:45:04] <cradek> (assuming /home is a partition)
[14:45:11] <cradek> use dump -1 for incrementals
[14:45:16] <cradek> for interactive restore mode:
[14:45:35] <cradek> cd /home; bzcat /backup/home.dump.bz2 |restore -rvf -
[14:46:29] <cradek> actually, several dump -1 will be differentials, not incrementals, but that's probably what you want if you only want to have to look through two files (the 0 and the latest 1) for your data.
[14:55:23] <paul_c> Hi Ray
[14:56:33] <rayh> Hi Paul.
[14:57:05] <rayh> Seems that SuSE started a mail transfer agent and I'm getting some mail in two places.
[14:57:08] <paul_c> don't understand why grub failed - It is installed as part of the initial setup
[14:58:19] <rayh> Got your most recent mail in /var/spool/mail
[14:58:33] <paul_c> * paul_c is no expert with postfix/exim
[14:58:46] <rayh> I agree that most of these issues would be resolved with a completed install.
[14:59:34] <rayh> I was installing to hda5. I wonder if extended ext3 might be an issue?
[14:59:59] <paul_c> It shouldn't
[15:00:22] <rayh> I got it going by modifying the knoppix LILO.
[15:00:23] <paul_c> If it had been xfs or reiserfs, it may have been..
[15:01:11] <rayh> Had a very bad experience with reiser a few years ago.
[15:02:05] <paul_c> at least with ext3, you can mount it as ext2 and recover data if it goes tits up.
[15:03:18] <rayh> Let me dig out a hd and try a clean install.
[15:17:50] <alex_joni> cradek: that is some very valuable information
[15:18:43] <alex_joni> I'll look at dump
[15:23:27] <alex_joni> don't seem to have dump installed... there is a dump2efs..
[15:23:53] <alex_joni> make that dumpe2fs
[15:24:51] <cradek> dumpe2fs is not what you want
[15:24:58] <alex_joni> I guessed so...
[15:26:00] <alex_joni> I found a dump.sourceforge.net ... seems more like it
[15:26:12] <alex_joni> now I gotta compile for 2.2.13 ;) and some ancient glibc
[15:26:13] <cradek> it should come with your OS distribution
[15:26:33] <cradek> look for an OS package first
[15:26:34] <alex_joni> gcc 2.7.2.3 ;)
[15:26:42] <cradek> -> rpm -qf /sbin/dump
[15:26:42] <cradek> dump-0.4b28-7
[15:26:45] <alex_joni> for SuSE 6.3 ?
[15:26:57] <cradek> well, I don't know anything about SuSE
[15:27:07] <alex_joni> I'll look .. maybe I still have the CD's ;)
[15:27:32] <cradek> but every unix that's not an abomination has dump/restore
[15:27:53] <alex_joni> *g*
[15:27:57] <alex_joni> thanks again for the hint
[15:28:03] <alex_joni> * alex_joni is going home now...
[15:28:12] <cradek> no problem
[15:28:43] <cradek> cool, my modern dump has a -z for built-in compression
[15:30:05] <alex_joni> I could pipe the output through gz.. right?
[15:30:10] <cradek> sure
[15:30:26] <cradek> looks like you also need to use dump's -u flag for incrementals or differentials to work
[15:30:32] <alex_joni> logger_aj .. are you getting this?
[15:30:34] <alex_joni> :D
[15:33:05] <alex_joni> bye guys
[16:19:03] <rayh> paul_c: Same problem with the clean install.
[16:19:58] <paul_c> Testing another build here with a new kernel.
[16:20:13] <les> cradeck: confirmed abort bug on june 2004 emc build
[16:21:15] <cradek> les: great
[16:21:30] <les> so it's not a new thing
[16:21:53] <cradek> I don't know whether I think that's good or bad news.
[16:22:04] <paul_c> les: What happens if you put a % on the first line ?
[16:22:21] <cradek> paul_c: doesn't help
[16:22:22] <les> it returns to 0,0
[16:22:44] <les> % seems not to matter
[16:23:15] <paul_c> the same for a comment block ?
[16:24:23] <les> did not try...but non motion prep codes did not seem to help right?
[16:24:38] <cradek> I think that did help
[16:25:06] <cradek> if your first real program line is g64, for instance
[16:25:08] <les> ok...I was in a hrry and did not try them
[16:26:18] <les> well that's the workaround I guess...and the reason I never saw it before
[16:26:27] <cradek> yeah
[16:26:47] <cradek> it's nice to understand the problem
[16:26:54] <les> for safety all my programs have lots of prep codes
[16:26:55] <cradek> all I knew before is "sometimes" this happens
[16:27:39] <les> well it needs to be found...I will be looking as I get the chance
[16:27:52] <les> emcmot.c and what else?
[16:28:38] <paul_c> More likely in the task interface or the interp.
[16:29:13] <paul_c> emctaskmain.cc for starters.
[16:36:21] <rayh> Could you guys get me up to speed on this error?
[16:36:33] <cradek> everything we know is in the bug tracker on sf
[16:37:03] <cradek> (I think)
[16:37:49] <cradek> http://sourceforge.net/tracker/index.php?func=detail&aid=1074914&group_id=6744&atid=106744
[16:37:52] <cradek> here is the url
[16:39:54] <rayh> thanks
[16:41:02] <rayh> bits are flowing slower than gear oil at the pole.
[16:50:37] <les> sorry phone call
[16:51:02] <les> I will look those files
[16:51:29] <les> yikes got the custom router bits ordered
[16:51:39] <les> $100 each!!!
[16:51:55] <cradek> wow
[16:52:10] <les> they are cnc ground
[16:52:50] <les> I almost started ordering diamond wheels, c2 carbide, and silver brazing paste
[16:53:13] <les> I could make em...but it would be a learning curve
[16:53:33] <les> and diamond wheels ain't exactly cheap
[16:54:03] <cradek> and I think they're easy to ruin
[16:54:24] <les> especially when dressing them
[16:56:00] <rayh> Dress a diamond wheel?
[16:56:26] <les> yes...the resin bonded ones are dressed to true them
[16:56:51] <les> the plated ones are not dressed...but they are less accurate
[16:57:06] <rayh> I've got a pile of diamond drums out in the shop for stone work.
[16:57:16] <rayh> Never heard of dressing any diamond cutter.
[16:57:48] <rayh> Take that back. I've got a 30" diamond saw that you dress by mashing the diamonds back into the babbit.
[16:57:53] <asdfqwega> A diamond grinding wheel or a diamond cutting wheel?
[16:58:10] <les> I did some research on wheel manufacturer sites
[16:58:10] <paul_c> * paul_c has a diamond/CBN wheel that needs to be dressed after mounting.
[16:58:14] <rayh> Both
[16:58:24] <les> diamond grinding wheel
[16:58:35] <rayh> Also got a bunch of diamond bands.
[16:58:47] <les> "crush dressing" is the best method
[16:59:07] <les> but truing with a diamond point works too
[16:59:25] <les> it just breaks the soft resin bond I guess
[17:00:34] <rayh> Never to old to learn.
[17:00:47] <les> but I have not done it...and dressing the wheel the first time would be scary
[17:02:15] <les> but then shelling out the $500 for 5 router bits is a bit unpleasant too
[17:03:19] <rayh> Where you getting those bits?
[17:04:31] <les> http://www.southeasttool.com/about_us.htm
[17:05:28] <les> bet that machine costs a buck or two
[17:18:06] <les> ah..just got a call from them...talked em down to $350...that helps
[17:18:33] <les> a few words on the phone can be worth some money!
[17:19:11] <les> I told them the price had to be low enough that I am not inclined to make em in house
[17:25:51] <jepler> Your search - cnc etch-e-sketch - did not match any documents.
[17:25:55] <jepler> didn't someone do this once?
[17:26:48] <les> seem to recall it yes
[17:27:24] <les> funny project
[17:27:30] <asdfqwega> Yeah, I saw a picture of a cnc etch-a-sketch
[17:27:46] <cradek> I'm pretty sure I've seen it too
[17:27:54] <les> now what I need is one of those robotic vacuum cleaners
[17:28:04] <les> wonder if they work well
[17:28:12] <cradek> neat idea but the etch-a-sketch really needs a Z bit
[17:28:16] <les> roomba?
[17:28:40] <asdfqwega> I've often thought about one of those robotic lawnmowers...
[17:28:52] <asdfqwega> but what I need is a brushhawg
[17:29:38] <asdfqwega> When automating large equipment with whirling blades, one must ask oneself:
[17:29:50] <asdfqwega> "Just how good is my programming?"
[17:30:07] <les> haha for sure
[17:30:19] <asdfqwega> I have cats, you see :)
[17:30:37] <cradek> but cats know to stay away from whirling things
[17:30:47] <asdfqwega> Not always
[17:30:48] <cradek> kids, however, aren't so smart.
[17:30:54] <asdfqwega> I've had some pretty stupid cats
[17:30:58] <les> I designed a lawn mower guidance system but never prototyped it
[17:31:04] <asdfqwega> This litter is pretty smart
[17:31:15] <cradek> litter of kids or cats?
[17:31:17] <les> used rotating laser beacons
[17:31:31] <les> need to see at least two at all times
[17:31:44] <les> dif GPS is too slow
[17:31:54] <asdfqwega> I've played with several ideas...it usually came down between precision and cost
[17:32:27] <les> well this boiled down to product liability
[17:34:22] <les> beacons linked with rf to servo lock...each sends an ID modulated on the beam
[17:34:53] <asdfqwega> I think my best best for a "hard" safety limit would be one of those electronic dog fences
[17:35:22] <les> shock em if they get too close?
[17:35:24] <asdfqwega> But I live out in the sticks, so it would've been a couple miles of wire to bury :(
[17:36:16] <les> asdfqwega: I am seriously out in the sticks too
[17:36:38] <asdfqwega> And I have too much "statistical noise" for beacons
[17:37:02] <les> that is why they are modulated
[17:37:18] <asdfqwega> I'd have to put beacons every 10 feet or something - so we're back to miles of wire for power :(
[17:37:38] <les> battery/solar
[17:37:51] <asdfqwega> I'm in ohio - not enough solar
[17:38:33] <asdfqwega> And being in a valley on a hill doesn't help - and that's not including the trees
[17:38:50] <les> well...put em on a stake...beacon can be removed, taken in, plugged in to wall wart
[17:39:18] <les> for trees and stuff must always see at least 2
[17:39:36] <les> might need several
[17:40:17] <les> anyway the real problem is mowing grass but not fingers
[17:40:43] <asdfqwega> Actually, the best solution: Get a Gravely - It cuts a widers swatch, so several acres doesn't take long
[17:41:08] <asdfqwega> and it cuts heavier grass, so I don't have to do it as often
[17:41:13] <les> ha...I have a gravely model L
[17:41:25] <asdfqwega> And if you REALLY don't want to cut your grass:
[17:41:34] <asdfqwega> Get 3 sets of lawn ornaments
[17:41:52] <asdfqwega> with those wires to stick in the ground?
[17:42:11] <asdfqwega> Get one with 1' wires, one with 2' wires, and one with 3' wires
[17:42:37] <asdfqwega> When the grass gets higher, just pull them up and put in the next set
[17:42:48] <asdfqwega> That way, people think you mowed your lawn ;)
[17:43:08] <les> I had better like cutting grass...I will be building the two hole golf course next spring
[17:43:21] <les> mow green DAILY!
[17:43:53] <cradek> yay, I fixed the abort bug
[17:44:05] <asdfqwega> That quickly? Wow.
[17:44:05] <les> cool!!! how?
[17:44:39] <cradek> by digging through the layers and layers of embedded switch() statements in emctaskmain.cc
[17:45:23] <cradek> it also fixes RUN / ESC / RUN
[17:45:32] <cradek> this used to give a strange "File is already open" error
[17:45:51] <les> yes have had that
[17:46:54] <les> bringing up emctaskmain.cc to have a look
[17:52:14] <les> no line numbers (using Word)...could you give me a search term?
[17:52:49] <cradek> return retval;
[17:53:01] <les> k
[17:53:05] <cradek> the one in the middle of case: statements
[17:53:21] <cradek> what was happening was this:
[17:53:34] <cradek> it would do the abort message, which cleared interp_list and closed the interpreter.
[17:53:54] <cradek> then, since it was in state READING, it would go on to read the next line, which reopened the file and skipped to the first gcode
[17:54:12] <cradek> this would leave the file open, leading to the error if you hit run again
[17:54:39] <cradek> if instead, you hit abort again, the abort would do the right thing since the interp is no longer in READING state
[17:56:22] <les> wow
[17:57:00] <les> got multiple finds of return retval...what is the preceding line?
[17:57:04] <cradek> this also explained why the repeated lines were required (so the interp was still READING when you hit ESC)
[17:57:38] <cradek> previous line is retval = emcTaskIssueCommand(emcCommand)
[17:57:44] <les> k
[17:58:19] <cradek> heh, I think my fix is way wrong
[17:58:20] <cradek> hmmm
[17:58:22] <jepler> cradek: next, fix the problem with step at the beginning of the program not setting pause when it's done (I think that was it)
[17:58:26] <cradek> * cradek looks at the surrounding code
[17:58:28] <jepler> oh, well, fix this first
[17:59:22] <cradek> I bet I should split out ABORT
[17:59:36] <cradek> but my two minutes of testing said it was fixed right!
[18:04:07] <les> hmm still can't find it using previous line...emctaskmain.cc is the file?
[19:10:45] <paul_c> Hi Dave..
[19:11:16] <paul_c> Hi Dave..again
[19:11:21] <dave-e> hi paul
[19:11:49] <paul_c> what you broken ?
[19:12:00] <dave-e> I'm still trying to get a good compile for the motenc..off the cvs
[19:12:32] <dave-e> vitalmod.o is about 105.5K which is different from what ray gets.
[19:13:15] <dave-e> tkemc comes up with wierd numbers ... just like it did before you fixed the type for the encoder
[19:13:35] <paul_c> leme see what I have...
[19:13:47] <paul_c> Build from Oct 28th
[19:13:47] <dave-e> it also changes numbers when I come out of estop.
[19:14:02] <paul_c> vitalmod.0 105410 bytes
[19:14:12] <dave-e> that sounds about right
[19:15:21] <dave-e> I'm busy moving computer, etc from the machine to my test setup.
[19:15:26] <paul_c> the most recent build, vitalmod.ko is 110349, but you don't want to know about that..
[19:15:59] <dave-e> off the current cvs...rc47?
[19:16:00] <cradek> dave-e: have you confirmed you are using the same compiler? you can't compare .o sizes otherwise
[19:16:23] <dave-e> what ever is native to rc46
[19:17:07] <paul_c> the latest build is for 2.6.9-adeos
[19:17:47] <dave-e> ie. brand-new install of rc46...don't screw with anytthing...just load the cvs and move the rcslib/etc
[19:18:38] <paul_c> just need the rtai & linux-rtai defs.
[19:18:47] <dave-e> yep!
[19:19:51] <paul_c> To be honest, once you have rcslib compiled, you don't udate from cvs.
[19:20:25] <dave-e> that makes sense since it hasen't changed.
[19:20:47] <cradek> ok, I take it back, I don't think my fix broke anything
[19:21:12] <dave-e> going to go shopping and see if I can get the experimental rig up.
[19:21:34] <dave-e> see ya later.
[19:50:07] <les> must have had a power bump when out in the shop...need new ups battery I think
[21:05:05] <alex_joni> g'evening
[21:05:30] <cradek> hello
[21:06:02] <alex_joni> hey cradek
[21:07:00] <alex_joni> what's up?
[21:07:30] <cradek> not much, but I fixed the jog bug
[21:07:45] <alex_joni> really? what was it?
[21:08:55] <cradek> well, all the symptoms we found were right, and it just did the wrong thing in that case.
[21:09:20] <cradek> after the abort, the interpreter tried to read the next line from the (closed) file, so it reopened it and read the first line
[21:09:35] <jepler> so are you confident of your fix now? I thought you said earlier you found something it had broken, but didn't elaborate.
[21:09:35] <cradek> but only when it was in the READING state
[21:09:45] <cradek> jepler: I'm pretty sure it's ok.
[21:09:51] <jepler> did you commit the change?
[21:09:54] <cradek> yeah
[21:10:03] <cradek> please test it!
[21:10:35] <alex_joni> if my memory serves me well this was for emc1 too.. right?
[21:10:52] <jepler> yeah, which tree did you fix it in?
[21:11:25] <cradek> just emc1
[21:13:22] <alex_joni> nice going cradek ;)
[21:14:17] <cradek> thanks, but it really wasn't hard once I decided to actually look for it instead of complain and hope someone else would
[21:16:36] <alex_joni> lol
[21:16:50] <alex_joni> yeah... usually I get there too
[21:19:34] <alex_joni> paul_c: are you around?
[21:19:38] <alex_joni> hello les
[21:20:56] <les> yes just got back
[21:21:10] <alex_joni> les: paul said you have a STG?
[21:21:26] <les> yes stg 2
[21:21:34] <alex_joni> or don't I remember it right?
[21:21:41] <alex_joni> darn
[21:21:55] <alex_joni> I started a emc2 driver for STG
[21:21:57] <alex_joni> but stg1
[21:22:15] <les> stg1 is not made anymore I think
[21:22:57] <les> but there are a lot out there so a driver is needed
[21:23:10] <alex_joni> very different stg2 from stg1?
[21:23:42] <les> just some index latching changes...they are very similar
[21:25:11] <les> the only functional driver for the current stg II and emc1 is newstgmod
[21:25:26] <les> oh and newstgsegmod for segmentqueue
[21:25:50] <les> ....but segmentqueue has problems
[21:26:27] <les> most unfortunately
[21:26:51] <asdfqwega> Okay, I have a question about motion blending - if anybody wants to here it
[21:26:59] <les> all ears
[21:27:24] <asdfqwega> Can it be enabled and disabled, and can I change how much?
[21:27:47] <asdfqwega> Or is this something that must be done at compile time?
[21:27:55] <les> yes G64 enables it
[21:28:00] <alex_joni> yeah but newstgmod is not GPL
[21:28:41] <les> right...like emc it is public domain
[21:29:49] <alex_joni> well emc2 is supposed to be GPL
[21:30:47] <les> sounds ok to me...if possible when using public domain emc elements
[21:31:32] <alex_joni> not using public domain elements
[21:31:52] <jepler> P src/emctask/emctaskmain.cc
[21:31:59] <jepler> cradek: I'm going to try your patches now
[21:32:21] <asdfqwega> * asdfqwega needs to cvs co 'documents'
[21:32:40] <les> I was down for a while...doing a fix for the abort thing?
[21:33:03] <paul_c> * paul_c scrolls up...
[21:33:35] <paul_c> alex_joni: Yes, I have an STGII card.
[21:33:59] <jepler> cradek: the problem is gone .. of course, I can't comment on any new problems you introduced..
[21:34:15] <les> hooray
[21:35:51] <alex_joni> paul_c: actually I wanted to ask you about that PC104 board
[21:36:15] <paul_c> fire away
[21:36:27] <alex_joni> need optocoupling on the IO ?
[21:36:55] <paul_c> That would be wise
[21:37:50] <alex_joni> hmmm.. then I don't think it can fit
[21:38:04] <alex_joni> maybe with SM optocouplers
[21:38:47] <jepler> so on the simulator, I've noticed that "step" goes a little bit into the next motion each time
[21:38:50] <asdfqwega> alex_joni: You make boards?
[21:39:08] <alex_joni> once in a while
[21:39:23] <asdfqwega> That must be handy
[21:39:38] <alex_joni> paul: don't seem to find any SM 82C55 (only DIP and PLCC)
[21:39:46] <asdfqwega> I've tried, and it looks like butchery :(
[21:39:47] <alex_joni> maybe SM socket for PLCC
[21:39:56] <alex_joni> it's pretty easy actually ;)
[21:40:13] <alex_joni> but you need a good autorouter (I have a very good one )
[21:40:29] <alex_joni> he's doing this for the last 6 years ;)
[21:41:24] <paul_c> plcc is sm
[21:41:42] <jepler> I have a feeling it has something to do with motion blending
[21:44:07] <paul_c> alex_joni: Farnell part No. 54064
[21:44:10] <alex_joni> not always
[21:44:23] <alex_joni> but I agree there are sm sockets for plcc
[21:44:32] <paul_c> sm opt-coupler in an 8 pin sm package
[21:44:35] <alex_joni> hard to solder
[21:44:41] <alex_joni> one pice?
[21:44:44] <alex_joni> piece?
[21:44:49] <paul_c> 20p each
[21:45:16] <alex_joni> 2 opt-couplers inside?
[21:45:29] <paul_c> single
[21:45:41] <asdfqwega> * asdfqwega just tried to use lyx 1.3.4 - no go
[21:45:57] <alex_joni> 8 pin is kinda a waste for single ;)
[21:46:01] <asdfqwega> * asdfqwega urpmi'd back to 1.3.3 - go
[21:46:58] <alex_joni> anyways... I'll see tomorrow what I can get around here
[21:47:59] <asdfqwega> les: thanks - G64 sounds just like what I was looking for
[21:49:32] <paul_c> Part No. 143480 - Dual opto in an 8 pin sm package
[21:49:39] <paul_c> 85p each
[21:50:26] <alex_joni> sounds better ;)
[21:50:42] <alex_joni> can you try the hal_stg some day?
[21:51:03] <asdfqwega> alex_joni: Does the machine you use to autoroute PCB's also drill?
[21:51:43] <asdfqwega> Oh, wait, I didn't read that right
[21:52:11] <alex_joni> I don't use a machine to autoroute PCB's
[21:52:12] <alex_joni> ;)
[21:52:24] <alex_joni> I was talking about designing (the autoroute stuff)
[21:52:29] <alex_joni> that does a friend of mine
[21:52:31] <asdfqwega> Ah
[21:52:40] <asdfqwega> Heh
[21:52:41] <alex_joni> when the design is done I take it to a local board manufacturer
[21:52:48] <paul_c> alex_joni: nope - Not until jmk produces a sane config method.
[21:52:52] <alex_joni> masks & stuff
[21:53:00] <alex_joni> config?
[21:55:01] <paul_c> halcmd and the baggage that goes with it.
[21:57:44] <alex_joni> hmmm... seems you don't like it ;)
[21:59:00] <paul_c> That's one way of putting it.
[21:59:35] <alex_joni> lol
[21:59:53] <alex_joni> do you have a better version in mind?
[22:00:14] <paul_c> of halcmd ?
[22:01:38] <alex_joni> of whatever bugs you
[22:02:00] <alex_joni> halcmd is ok if you want to test just some parts
[22:02:20] <alex_joni> e.g. connect a halmeter to a encoder count board
[22:02:25] <alex_joni> and see if it works
[22:02:50] <alex_joni> I think a halgui would help a lot
[22:03:47] <paul_c> OK... Now try taking a rank newbie through setting up and configuring his machine with halcmd
[22:04:23] <alex_joni> I agree on this...
[22:04:41] <alex_joni> it's not that easy if you don't know it...
[22:04:50] <paul_c> and who do you think will end up having to provide the support ?
[22:07:25] <alex_joni> hmm.. some very good manual :D
[22:07:40] <alex_joni> just RTFM all over the place ,)
[22:07:44] <paul_c> and how many read the manual ?
[22:08:04] <asdfqwega> Manuals? If I need help, I just whining to Paul :D
[22:08:28] <asdfqwega> Gr, can't type or speak today
[22:08:58] <alex_joni> you could read a manual...
[22:09:06] <alex_joni> how to type or speak ;)
[22:09:30] <alex_joni> ok... so there should be a more intuitive version of halcmd
[22:09:39] <alex_joni> not comand line?
[22:09:54] <paul_c> * paul_c hands alex_joni the "Regular Expression" handbook
[22:11:22] <asdfqwega> Yeah, something X-windows, with pastel colours and big, gay WinXP-style icons
[22:11:47] <asdfqwega> And the talking paperclip for help
[22:12:14] <paul_c> Much of the data required to configure hal is already in a stock emc.ini
[22:12:39] <paul_c> some of it is implied data...
[22:13:04] <paul_c> about all that is missing is pin assignments for RT IO
[22:15:25] <alex_joni> so a halconf utility that takes values from emc.ini
[22:15:30] <alex_joni> sets up hal connections
[22:15:37] <alex_joni> if I got you right?
[22:15:49] <alex_joni> pin assignments also in emc.ini ?
[22:17:16] <paul_c> Not for step/dir, home, & limit pins
[22:19:56] <alex_joni> those in a .hal file?
[22:30:29] <paul_c> configs/*.hal
[22:38:47] <alex_joni> that's not very different from now...
[22:38:52] <alex_joni> is it?
[22:41:40] <paul_c> For the current demo emc.ini, core_stepper.hal AND standard_pinout.hal are required
[22:43:52] <paul_c> 4-5 new lines in emc.ini
[22:44:13] <paul_c> and only 41 lines in the two *.hal configs
[22:45:03] <paul_c> virtually doubling the number of parameter required to get emc running.
[22:45:30] <alex_joni> and you want to remove some?
[22:45:35] <alex_joni> or make them implicit?
[22:46:22] <paul_c> Many of them can be inferred from the stock ini, yes.
[22:48:25] <alex_joni> I see..
[22:48:45] <alex_joni> I think there can be a compromise between what you want, and what is currently done
[22:49:32] <paul_c> maybe... But there are other issues that need to be fixed first.
[22:50:27] <paul_c> for example - Run the emc demo
[22:51:09] <paul_c> and from another console rmmod the parport driver, or any of the other "components"
[22:52:02] <paul_c> better still - Set up a loop that rmmods and insmods the parport driver.
[22:52:27] <alex_joni> I see.. no lock on modules
[22:52:55] <paul_c> It can get much worse than that...
[22:53:12] <paul_c> at some point, the computer will crash
[22:53:37] <alex_joni> well without lock it's pretty obvious it can
[22:53:57] <alex_joni> on the other hand.. locking a module because emc is running is also bad
[22:54:04] <alex_joni> if emc hangs... rmmod won't work
[22:54:33] <paul_c> If emc hangs, a reboot is required.
[22:55:49] <alex_joni> then I guess a lock would be ok
[22:56:11] <alex_joni> problem is.. who sets it, and who can read it ;)
[22:56:19] <paul_c> Once emc is configured, a lock is mandatory
[22:58:18] <alex_joni> is there a common way to lock modules?
[22:59:51] <paul_c> There is the MOD_IN_USE macros
[23:00:32] <paul_c> but due to the emc/hal structure, that won't work too well.
[23:00:46] <paul_c> there is another method...
[23:01:05] <asdfqwega> I understand the security/safety aspects - but when you're making chips, who's going to be poking around with rmmod?
[23:02:47] <paul_c> in a single user workshop, perhaps.
[23:03:10] <asdfqwega> * asdfqwega thinks of all the goofballs he's ever worked with...
[23:03:18] <asdfqwega> Question withdrawn.
[23:03:18] <paul_c> In an industrial environment, look at the average ape.
[23:03:43] <asdfqwega> I take it normal separation of root priveleges isn't enough
[23:04:02] <paul_c> Stability, security, and robustness.
[23:04:31] <asdfqwega> I defer to those who know those three better than I
[23:05:28] <paul_c> Loading and unloading of modules requires root priviledges
[23:07:00] <paul_c> however, there are ways round that... 2.4 & 2.6 kernels have some neat tricks for hotplugging that could be used.
[23:09:00] <asdfqwega> I understand (from using 2.6 kernel) that modules can have a 'user count' - being in use can make module removal impossible (depending on kernel compile options)
[23:10:01] <paul_c> that feature is available from 2.2 onwards
[23:13:26] <asdfqwega> So how do you lock a module, when there appears to be several ways to circumvent that?
[23:14:19] <asdfqwega> replace rmmod with a symlink to a script?
[23:15:16] <paul_c> nope - It needs to be done within the kernel module
[23:15:44] <asdfqwega> An internal lock
[23:16:53] <paul_c> yup - A variation on the MOD_IN_USE counters
[23:19:31] <asdfqwega> Paul, I'd like to tell you that you're clever - but I probably don't know enough to full appreciate everything you do
[23:20:22] <asdfqwega> Now, I'm going to be chased out of my own shop - the fumes are getting think in heree
[23:25:04] <alex_joni> paul: how about "The 2.6 kernel, however, knows not to unload a module that owns a character device that's currently open."
[23:25:16] <alex_joni> that sound usefull for 2.6
[23:26:03] <paul_c> 2.6 modules can also be forcably removed (depending on kernel configs)
[23:26:31] <alex_joni> I see..
[23:26:56] <alex_joni> but the MOD_INC_USE_COUNT, MOD_DEC_USE_COUNT sounds useable
[23:27:44] <alex_joni> only 2 macro calls...
[23:32:18] <paul_c> those macros work fine if a hal driver is locking hal.o
[23:32:54] <paul_c> but the drivers need to register with hal.o and be locked themselves.
[23:34:38] <alex_joni> there is a can_unload function
[23:34:41] <alex_joni> that can be defined
[23:35:03] <alex_joni> "For more complicated module unload locking requirements, you can set the can_unload function pointer to your own routine, which should return 0 if the module is unloadable, or -EBUSY otherwise."
[23:40:50] <alex_joni> ok.. me going to bed
[23:40:51] <alex_joni> night
[23:40:53] <paul_c> Need to be carefull with some of the kernel level functions - Some of them are not available in all releases