Back
[00:33:42] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[00:33:48] <jepler> SWPadnos: get your keyboard fixed?
[00:55:42] <SWPadnos> I'm home now
[00:56:10] <SWPadnos> that was a weird problem - I had run EMC, and was left with a bunch of defunct halmeters and other programs
[00:56:32] <SWPadnos> I tried halrun -U, which didn't remove those processes
[00:56:47] <SWPadnos> kill, sudo kill, sudo kill -9 all didn't remove the processes
[00:57:12] <SWPadnos> then I tried running emc again, which (possibly coincidentally) killed the keyboard
[00:57:30] <SWPadnos> I unplugged and replugged it (USB keyboard), which didn't help
[00:57:50] <SWPadnos> so then I used character map and the mouse (which still worked fine) to type those few lines
[00:58:05] <SWPadnos> but character map apparently doesn't have the space character :)
[01:02:36] <SWPadnos> jepler, had a problem with axis today
[01:02:49] <SWPadnos> could be the fault of some updates I did a few days ago
[01:02:58] <SWPadnos> this is on my laptop, a 7.10 sim only system
[01:03:32] <SWPadnos> oh - I think it's the same thing Ray mentioned - some X get window properties function not found or similar
[01:03:48] <SWPadnos> and EMC doesn't run (with AXIS - works fine with tkemc)
[01:04:14] <SWPadnos> I updated today, and the problem wasn't fixed. I'll paste the errors as soon as I have the chance
[01:04:21] <jepler> hm, this doesn't ring a bell yet
[01:04:28] <SWPadnos> ok - lemme boot the laptop
[01:05:14] <jepler> ray mentioned this recently?
[01:06:04] <SWPadnos> I thought I saw something fly by one of the times I was on IRC this weekend
[01:06:14] <SWPadnos> could be unrelated - I probably had at most half the picture
[01:15:48] <SWPLinux> http://pastebin.ca/1017505
[01:16:30] <SWPadnos> I selected sim/axis
[01:17:29] <jepler> does glxgears work?
[01:17:47] <SWPLinux> interesting - no, it doesn't
[01:18:31] <SWPLinux> hmmm. I wonder if it could have to do with all the network shenanigans I went through last week
[01:18:51] <SWPLinux> I don't think there was an X or nvidia driver update in the last set, but I'm not sure
[01:23:00] <SWPadnos> ok, much better (with glxgears anyway) after dpkg-reconfigure xserver-xorg
[01:23:11] <SWPadnos> it had been switched to the nv driver
[01:23:36] <SWPadnos> I know that worked though, because I remember getting some terrible frame rates. now it's back up to an acceptable 12500+
[01:25:49] <SWPadnos> much snappier feel too - pretty amazing difference
[02:16:30] <jepler> oh I just noticed /etc/apt/sources.list.d on 8.04; we should probably put our entry there instead of >> /etc/apt/sources.list
[02:16:45] <jepler> $ cat /etc/apt/sources.list.d/emc2.list
[02:16:45] <jepler> deb
http://linuxcnc.org/hardy hardy base
[02:16:45] <jepler> deb-src
http://linuxcnc.org/hardy hardy base
[02:16:59] <jepler> (well, should have emc2.2 there too..)
[02:17:33] <SWPadnos> so, I was looking at the X configuration on an 8.04 machine, and I couldn't find out what driver was being used
[02:17:51] <SWPadnos> I may not have been patient enough looking at the Xorg.0.log file though
[02:18:05] <SWPadnos> there was no driver line in the xorg.comf file
[02:18:09] <SWPadnos> conf
[02:19:21] <jepler> yeah they did something magic I think
[02:19:31] <cradek> soon that file will just be empty
[02:19:47] <SWPadnos> the machine we installed on was a Dell dimension XPS 300 I think, with intel extreme graphics of some sort
[02:20:02] <SWPadnos> lstency was so-so, about 25000 under stress
[02:20:25] <SWPadnos> (very so-so for a recent dual-core CPU)
[02:41:09] <skunkworks> A few of the dual core or even the core 2 duos have not be spectacular. (that I have tested)
[02:42:08] <skunkworks> Pentium 4's seem to still be the most sub 15us range or better.
[03:23:16] <rayh> Semperon Base 7960 Servo 4932
[03:24:44] <rayh> That is the machine I got to 80+ Kpps without the pulsing thing jepler wrote.
[06:03:47] <seb_kuzminsky> here comes the hostmot2 patch bomb
[06:18:08] <alex_joni> seb_kuzminsky: cool :)
[06:20:34] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/ (hm2_5i20.9 hm2_7i43.9 hostmot2.9):
[06:20:34] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:20:34] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:20:34] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:20:34] <CIA-49> EMC: * More to come...
[06:20:35] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/ (Makefile Makefile.inc.in):
[06:20:39] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:20:41] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:20:43] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:20:45] <CIA-49> EMC: * More to come...
[06:20:47] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (17 files):
[06:20:49] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:20:51] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:20:53] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:20:55] <CIA-49> EMC: * More to come...
[06:20:57] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/doc/ (7 files):
[06:20:59] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:21:01] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:21:03] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:21:05] <CIA-49> EMC: * More to come...
[06:21:13] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/README:
[06:21:15] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:21:15] <seb_kuzminsky> criminy
[06:21:17] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:21:19] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:21:21] <CIA-49> EMC: * More to come...
[06:21:23] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/CPLD/SOURCE/ (7I43.ISE I43CPLD.UCF I43CPLD.VHD):
[06:21:28] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:21:30] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:21:32] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:21:34] <CIA-49> EMC: * More to come...
[06:21:36] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i20/ (8 files):
[06:21:38] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:21:46] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:21:48] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:21:50] <CIA-49> EMC: * More to come...
[06:21:52] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/CPLD/ (I43CPLD2.JED I43CPLD4.JED):
[06:21:55] <CIA-49> EMC: First release of the new hostmot2 driver.
[06:21:57] <CIA-49> EMC: * Supports the 5i20 and 7i43.
[06:22:01] <CIA-49> EMC: * Basic support for encoders, pwmgens, stepgens, and gpios.
[06:22:03] <CIA-49> EMC: * More to come...
[06:22:05] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/SOURCE/ (24 files):
[06:22:07] <CIA-49> (14 lines omitted)
[06:22:14] <seb_kuzminsky> "quits CIA-49: excessive flood"
[06:27:07] <CIA-49> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[06:28:31] <CIA-49> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[06:29:03] <seb_kuzminsky> uh-oh...
[06:42:36] <CIA-49> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hm2_5i20.c: dont need all those headers, hopefully this compiles on older kernels
[06:44:16] <CIA-49> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) realtime (2.6.12-magma) * 10emc2head/: build PASSED
[06:44:48] <seb_kuzminsky> yay
[06:45:53] <CIA-49> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build PASSED
[12:07:12] <Guest875> Guest875 is now known as skunkworks_
[12:58:35] <cradek_> cradek_ is now known as cradek
[12:59:48] <SWPadnos> oh - I had forgotten (or never knew) about the names=name1,name2 ... option for comps. I think that's very very useful in the context of multiple gearchange components
[13:00:17] <jepler> SWPadnos: oh I snuck that in just recently
[13:00:27] <SWPadnos> good job
[13:00:47] <SWPadnos> I was trying to think of how I could eliminate the .0 in the name of a single instance
[13:00:54] <SWPadnos> but keep it for multiples
[15:01:25] <alex_joni> seb_kuzminsky: nice job on the hostmot2 stuff
[15:01:37] <seb_kuzminsky> thanks :-)
[15:02:03] <skunkworks_> hostmot2 has the more accurite encoder velocity?
[15:02:13] <seb_kuzminsky> i'm pretty happy with how it's turning out
[15:02:28] <alex_joni> don't forget debian/changelog ;)
[15:02:38] <seb_kuzminsky> skunkworks: hm2 has excellent encoder support, but the driver for it is pretty primitive still
[15:02:58] <seb_kuzminsky> alex_joni: oh yeah! i spaced it. I'm working on the wiki right now
[15:03:36] <seb_kuzminsky> skunkworks: it should kick total ass by the end of summer
[15:04:59] <skunkworks_> seb_kuzminsky: making it to the cnc workshop?
[15:05:29] <seb_kuzminsky> i wish i could, but probably not... too much other stuff right now.
[15:05:38] <seb_kuzminsky> sounds like a blast though
[15:17:05] <skunkworks_> darn
[15:33:18] <rayh> Is hostmot2 ready to test with 5i20 cards?
[15:34:28] <seb_kuzminsky> yep! :-)
[15:34:52] <seb_kuzminsky> let me know if it catches your machine on fire
[15:35:04] <rayh> What do I have to change in the mesa config?
[15:35:35] <seb_kuzminsky> I'm not sure what the old (hostmot-4?) mesa config looks like, but i'm typing up usage instructions on the wiki right now
[15:35:49] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HostMot2
[15:36:05] <seb_kuzminsky> also there's some manpages
[15:36:38] <seb_kuzminsky> basically it goes like this:
[15:37:27] <seb_kuzminsky> loadrt hostmot2 debug_idrom=1 debug_module_descriptors=1 debug_pin_descriptors=1 debug_modules=1
[15:37:27] <seb_kuzminsky> loadusr -w bfload 5i20=/path/to/src/hal/drivers/mesa-hostmot2/firmware/5i20/SVST8_4.BIT
[15:37:27] <seb_kuzminsky> loadrt hm2_5i20
[15:38:04] <seb_kuzminsky> gives you a ton of debug info in the syslog and a pile of HAL objects representing the firmware on the card
[15:38:07] <rayh> okay I'll get there in a bit.
[15:39:56] <alex_joni> seb_kuzminsky: maybe you can set up a sample config?
[15:40:21] <alex_joni> configs/mesa-hostmot2/ with 5i20.ini, 7i43.ini, etc
[15:40:29] <seb_kuzminsky> good idea!
[15:40:52] <seb_kuzminsky> i've got the config i'm using for testing, i'll pastebin it for now
[15:42:01] <seb_kuzminsky> http://pastebin.ca/1018077
[15:42:34] <seb_kuzminsky> it'll need some hacking for you guys prolly, it drives both a 7i43 and a 5i20
[16:00:38] <SWPadnos> seb_kuzminsky, is there support (a bitfile) for the 5i22, or do I need to make one? :)
[16:01:48] <SWPadnos> hmmm. I don't see 5i22 files in the commit message subjects
[16:01:53] <seb_kuzminsky> the 5i22 isnt supported yet, but it's next on my list
[16:02:06] <SWPadnos> ok. if you wait long enough I'll do it for you :)
[16:02:10] <seb_kuzminsky> there's several hostmot2 configs available for it already
[16:02:14] <SWPadnos> yep
[16:02:25] <SWPadnos> it's a matter of driver support and bitfile loading
[16:02:43] <SWPadnos> I probably have a hostmot2 bitfile here, but I'm sure it's out of date
[16:04:44] <seb_kuzminsky> does bfload work with the 5i22 for you?
[16:04:48] <SWPadnos> yes
[16:04:52] <seb_kuzminsky> cool
[16:05:23] <seb_kuzminsky> i've got a 1M 5i22 here, i'll plug it in and start poking at it in the next week or so
[16:05:42] <seb_kuzminsky> is yours a 1M or 1.5M?
[16:05:50] <SWPadnos> OK - I have only tested it on the 1.5m version, so it'll be good to see that it also works for the 1.0
[16:05:55] <SWPadnos> ^^ :)
[16:06:08] <seb_kuzminsky> groovy
[16:06:49] <SWPadnos> that version of bfload may only be in the mesa-configtools CVS branch
[16:07:03] <seb_kuzminsky> ugh
[16:07:09] <seb_kuzminsky> i've been doing all my work on the TRUNK
[16:07:26] <seb_kuzminsky> and i've changed bfload quite a bit there
[16:07:31] <SWPadnos> I'm not sure though - that may only be the other stuff under drivers/mesa_5i2x
[16:07:57] <seb_kuzminsky> i'm preparing another round of bfload reorg...
[16:07:59] <jepler> I haven't checked them all, but at least atrans.vhd in the 5i20 and 7i43 directories need GPL license grants.
[16:08:24] <seb_kuzminsky> thanks, i'll let peter know
[16:08:37] <SWPadnos> ok, it looks like there are no other branches of bfload
[16:08:42] <seb_kuzminsky> whew!
[16:09:01] <SWPadnos> though there is some stuff in 2.2.5 which may not be in TRUNK (?)
[16:09:06] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/src/hal/utils/bfload.c?graph=1
[16:09:58] <SWPadnos> ok, there are 5i22 defines in there, so I think this is the right one :)
[16:10:08] <seb_kuzminsky> you mean 1.8.2.1? that's some changes from TRUNK i merged into 2.2
[16:10:21] <SWPadnos> yep, 1.8.2.1
[16:10:46] <SWPadnos> right - the bopard:file syntax or whatever it was :)
[16:10:48] <SWPadnos> board
[16:11:19] <seb_kuzminsky> yeah... though i'm having second thoughts about that now
[16:11:44] <seb_kuzminsky> maybe something like "bfload send <FirmwareFile> <Board> would be clearer
[16:12:24] <seb_kuzminsky> <shrug>
[16:15:49] <SWPadnos> dunno really
[16:16:23] <SWPadnos> I'll have to plug in a 5i20 or two, a 5i22 and maybe a 7i43, and see how cumbersome it is to program them
[16:16:32] <SWPadnos> (once I get a 7i43 that is)
[16:16:56] <seb_kuzminsky> i wonder if the hm2_5i20 driver will work with two 5i20's...
[16:17:06] <seb_kuzminsky> that'd be cool
[16:17:07] <SWPadnos> it better :)
[16:17:15] <seb_kuzminsky> heh
[16:17:28] <SWPadnos> that's probably the hard part - multiple boards of different types
[16:17:49] <SWPadnos> so more or less the same but different sets of capabilities die to 2, 3, or 4 connectors
[16:17:56] <seb_kuzminsky> that part's pretty much taken care of
[16:18:17] <SWPadnos> then no problem! :)
[16:18:37] <seb_kuzminsky> we'll see
[16:18:49] <seb_kuzminsky> i'm excited to get some testing feedback
[16:18:53] <seb_kuzminsky> gotta go, bbl
[16:19:02] <SWPadnos> see you. maybe some feedback next week
[16:19:05] <SWPadnos> from me
[16:19:14] <seb_kuzminsky> sweet
[18:56:03] <rayh_> rayh_ is now known as rayh
[21:23:58] <alex_joni> any idea how to remove a "hung" module?
[21:24:13] <alex_joni> lsmod only says it's in use (count =1), but doesn't say by whom
[21:24:25] <alex_joni> rmmod -f (or --force) modulename doesn't work
[21:25:22] <SWPadnos> I think that only works if you have "forced module unloading" (or similar) compiled into the kernel
[21:26:31] <alex_joni> CONFIG_MODULE_FORCE_UNLOAD ?
[21:27:12] <SWPadnos> something like that
[21:28:36] <rayh> I've got a pcmcia parport card. Supposed to be a real parport.
[21:29:57] <alex_joni> I had a similar card, and could only get it to work by loading parport_cs
[21:30:20] <alex_joni> afterwards I could unload parport_cs, parport_pc, parport, lp and use it with hal_parport
[21:30:30] <alex_joni> but it seems for ray parport_cs doesn't want to unload
[21:47:31] <jepler> other option: modify hal_parport to *not* claim the ports (possibly based on a module parameter e.g., unsafe=1)
[21:47:41] <jepler> then you don't have to force anything to unload
[21:49:26] <rayh> I'd have to compile that change in jepler
[21:49:44] <jepler> yes you would
[21:50:26] <rayh> Okay. That's also a thought.
[21:50:52] <rayh> Then I could run it with parport_pc also loaded?
[21:52:25] <jepler> hypothetically, yes
[21:52:45] <alex_joni> but it seems odd that you can't unload parport_cs once it's loaded
[21:52:50] <jepler> but then you'll get linux apps trying to send data to the ports ("hi is there a printer yet") and your machine will be unreliable
[21:53:12] <alex_joni> jepler: maybe not if he removes all stuff from cron/ cupsis/etc
[21:53:19] <rayh> So I'd have to kill off those aps
[21:53:46] <jepler> hypothetically, if one can determine which software that is
[21:54:12] <rayh> rebooting with /etc/modprobe.d/emc2 intact.
[21:54:25] <SWPadnos> if the card is still installed, the module should be there - that could be the dependency
[21:54:48] <SWPadnos> if the module won't unload even after the card is removed, then there's probably a bug in pcmcia_cs
[21:55:50] <rayh> I did try a soft remove of the card and the module would still not allow me to remove it.
[21:56:17] <rayh> "cardctl eject"
[21:56:32] <SWPadnos> did you physically remove the card?
[21:56:33] <rayh> And it did change the sound of the motors attached to the card.
[21:56:38] <SWPadnos> heh
[21:56:40] <rayh> Not running
[22:00:41] <rayh> Okay I tried starting emc and adding probe_parport
[22:00:59] <rayh> so that all of EMC's parport stuff is there.
[22:01:11] <rayh> modprobe parport_cs fails
[22:02:06] <rayh> Looking for two unknown symbols -- parport_pc_unregister_port and parport_pc_probe_port
[22:02:28] <rayh> Those symbols are in there if I load parport_pc
[22:05:44] <alex_joni> rayh: I meant only probe_parport and hal_parport
[22:05:53] <alex_joni> and see if that brings any functionality out of the card
[22:06:19] <alex_joni> (but it probably won't)
[22:06:52] <rayh> No it doesn't.
[22:06:56] <alex_joni> * alex_joni is fresh out of other ideas.. and going to bed
[22:07:06] <alex_joni> rayh: right.. didn't think it would
[22:07:31] <alex_joni> you could maybe try with emc 2.0.x I think (that one doesn't check for free mem range)
[22:08:00] <rayh> that's a thought.
[22:08:28] <alex_joni> yup.. I just checked
[22:08:40] <alex_joni> (it's probably full of other problems.. ;)
[22:08:55] <rayh> Think I'll try jepler's idea of a compile with the checking turned off.
[22:09:11] <alex_joni> if you have a devel setup, then it's fastest/best
[22:09:20] <rayh> If I can find a working compiler on 6.06
[22:09:42] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/hal_parport.c.diff?r1=1.13;r2=1.14
[22:09:50] <alex_joni> that's the stuff you need to disabled
[22:10:01] <alex_joni> * alex_joni is off to bed
[22:10:04] <alex_joni> good night all
[22:10:25] <rayh> Night Thanks again.
[22:10:26] <alex_joni> rayh: good luck ;)
[22:59:50] <rayh> Historical thought for the day. From FredP Feb 1999
[22:59:54] <rayh> I posted a new release of the EMC software on the FTP site. This fixes
[22:59:54] <rayh> Jon's problem with the G92 axis offsets getting clobbered when the
[22:59:54] <rayh> program ends. According to the RS-274-NGC spec this is what is supposed
[22:59:54] <rayh> to happen, but since these offsets are not stored anywhere and can't be
[22:59:54] <rayh> recovered, I decided to hell with the spec.
[23:07:45] <SWPadnos> heh
[23:16:34] <jepler> I guess his fix didn't stick
[23:16:38] <jepler> :-P
[23:18:56] <rayh> Darn that was a trip down memory lane.
[23:19:12] <rayh> BDI looks like april 2001