#emc-devel | Logs for 2007-10-19

Back
[00:15:08] <skunkworks> heh http://ubuntuforums.org/showthread.php?p=3564074#post3564074
[00:19:31] <cradek> "but as you can see ... there are good reasons for still using dapper"
[00:20:23] <skunkworks> :)
[00:20:40] <cradek> there hasn't been anything promising about that bug yet has there
[00:21:29] <skunkworks> no - from what I have been reading Compiz-Fusion is very buggy
[00:24:21] <cradek> did they release gutsy already?
[00:24:27] <SWPadnos> today
[00:24:28] <skunkworks> I think so
[00:24:35] <cradek> wonder if it works at all
[00:24:55] <SWPadnos> my laptop seems fully functional, except for the built-in webcam
[00:25:16] <SWPadnos> I haven't checked the built-in SD card reader because it doesn't support any of the card types I use
[00:25:34] <skunkworks> I really only had issues with the opengl with the fancy desktop magic
[00:25:42] <SWPadnos> and I didn't even have those :)
[00:26:06] <skunkworks> right
[00:26:34] <SWPadnos> I haven't tried doing DVD recording or that kind of thing yet, and I guess I haven't tried bluetooth or wifi yet either
[00:26:48] <SWPadnos> but the subset of functions I've wanted to use have all worked fine ;(
[00:26:52] <SWPadnos> :)
[00:27:21] <cradek> do opengl rpgorams work?
[00:27:28] <cradek> rpgorams?
[00:27:57] <SWPadnos> yes, openGL grpoagams fcintoin fine
[00:28:13] <skunkworks> yes - if you turn of the desktop 'effects' (for me anyways)
[00:28:24] <cradek> good to know that it's easy to turn off that breakage
[00:29:02] <skunkworks> * skunkworks thinks cradek missed when had said turning off the desktop effects fixed the opengl issues.
[00:29:40] <cradek> I don't always read every word...
[00:29:58] <SWPadnos> I don't always type every letter
[00:30:05] <SWPadnos> at least not the right ones
[00:30:11] <skunkworks> I usually type more than needed
[00:30:24] <cradek> lately I've had a problem with typing all the right letters, but in the wrong order
[00:30:46] <cradek> I hope my typing skills don't decline - that would suck
[00:30:52] <SWPadnos> that's a step in the right direction anyway
[00:56:05] <jepler> SWPadnos: nvidia chipset, closed-source driver?
[00:56:46] <SWPadnos> yep
[01:07:14] <cradek> would someone remind me if there's some way the 2.2 release is waiting for me to do something?
[01:10:54] <jepler> I think you did what I needed -- testing stepconf
[01:11:13] <jepler> too bad we don't have a lathe to test it on -- that part's bound to have bugs
[01:11:41] <cradek> matt S or maybe ray? has the nist-lathe...
[01:11:55] <jepler> yeah I saw ray asking recently..
[01:14:54] <cradek> we could sure run through it and see if it at least runs.
[01:15:08] <cradek> actually someone else doing it would probably be better.
[01:15:51] <jepler> did we get the halui+gui case to "works tolerably"?
[01:16:22] <cradek> I think so, but I haven't tested it on hardware
[01:16:48] <jepler> istr it happened on zenbot pretty easily (pause with halui, resume with gui)
[02:02:31] <cradek> I think the problem is back where you change the debuglevel with that AXIS window and then the normal gui takes a couple seconds to respond again
[02:02:40] <cradek> (I haven't debugged this at all)
[02:52:58] <SWPLinux> so - I'm trying to compile the driver for the 5i22, and I'm having a problem
[02:53:21] <SWPLinux> I have added the (seemingly) appropriate lines to src/Makefile
[02:55:01] <SWPLinux> hmmm. maybe I'll post the error if it comes up again after ./configure
[02:55:45] <SWPLinux> make -C /usr/src/linux-headers-2.6.15-magma SUBDIRS=`pwd` CC=gcc V=0 -o /usr/src/linux-headers-2.6.15-magma/Module.symvers modules
[02:55:46] <SWPLinux> make[1]: Entering directory `/usr/src/linux-headers-2.6.15-magma'
[02:55:48] <SWPLinux> make[2]: *** No rule to make target `/Project/emc2/src/hal/drivers/thoth-aio.o', needed by `/Project/emc2/src/abs.o'. Stop.
[02:55:49] <SWPLinux> make[1]: *** [_module_/Project/emc2/src] Error 2
[02:55:51] <SWPLinux> make[1]: Leaving directory `/usr/src/linux-headers-2.6.15-magma'
[02:55:52] <SWPLinux> make: *** [modules] Error 2
[02:55:54] <SWPLinux> steve@steve-xpc:/Project/emc2/src$
[02:56:48] <cradek> is there a src/hal/drivers/thoth-aio.c?
[02:57:14] <SWPLinux> oh - well I just noticed that I started writing it in drivers/mesa_5i2x
[02:57:17] <SWPLinux> duh
[02:57:52] <SWPLinux> seemed appropriate, since it's for a 5i22 with erxtra stuff attached
[02:57:56] <SWPLinux> extra
[02:58:20] <SWPLinux> I guess I should have copied the 5i2x lines instead of the 5i20 lines in the makefile ;)
[03:00:22] <SWPLinux> yay! now all I get are all the errors from the code. thanks
[03:00:38] <cradek> I didn't do anything...
[03:02:31] <SWPLinux> well, you reached the same conclusion as me, reinforcing that it was right
[03:02:37] <SWPLinux> or at least the same
[03:02:47] <cradek> that you were doing something wrong? :-)
[03:02:49] <SWPLinux> yes
[03:02:54] <cradek> glad you got it.
[03:03:01] <SWPLinux> also, the specific wrong thing I was doing
[03:03:15] <SWPLinux> yeah - less than one screen full of errors now too - woohoo!
[12:14:53] <alex_joni> morning samco
[12:16:05] <skunkworks> morning alex. How did the week go for you?
[12:18:33] <alex_joni> busy.. and it still goes :)
[12:19:14] <skunkworks> oh yah, for got your still in 'work' mode
[12:19:34] <skunkworks> forgot
[12:19:50] <alex_joni> I will certainly be a couple more hours
[12:26:45] <skunkworks> camp fire tonight - if it stops raining. Good times. You're all invited.
[12:27:46] <alex_joni> ha.. let me grab my jet
[12:29:06] <skunkworks> if that is what it takes ;)
[12:30:34] <SWPadnos> will there be food?
[12:33:10] <owhite> hey people -- does anyone know of problems of using emc2 with ubuntu 64 bit?
[12:33:30] <SWPadnos> you need to change the size of the tool status buffer, I think
[12:33:42] <SWPadnos> which may already be done
[12:33:55] <owhite> any other known problems with 64 bit machines?
[12:34:49] <SWPadnos> I know that jepler and I have both tested that, but I'm not sure if either of us has run hardware with it
[12:35:00] <SWPadnos> so there may be problems, but I don't know what they are
[12:35:30] <owhite> okay. what about 65 bit machines?
[12:35:32] <owhite> :-)
[12:43:07] <alex_joni> SWPadnos: lol
[12:43:20] <alex_joni> you know what Jymmmm said last night?
[12:43:53] <alex_joni> 23:36 < JymmmEMC> SWPadnos: ping
[12:43:53] <alex_joni> 23:37 < alex_joni> JymmmEMC: pong
[12:43:53] <alex_joni> 23:37 < alex_joni> he's eating
[12:43:53] <alex_joni> 23:37 < JymmmEMC> He's ALWAYS eating
[12:43:53] <alex_joni> 23:37 < alex_joni> you also noticed?
[12:43:55] <alex_joni> 23:38 < JymmmEMC> yeah, in person too.... The man loves his food =)
[12:43:58] <alex_joni> 23:38 < JymmmEMC> He can eat more than me even!!!
[12:44:54] <skunkworks> SWPadnos: yes food and drink.
[12:44:59] <skunkworks> :)
[13:27:56] <cradek> SWPadnos: that is already done
[18:06:24] <owhite> hey folks. I just installed emc2 as --run-in-place and ran the simulator, and recieved this complaint....
[18:06:56] <owhite> Can't execute server program /home/owhite/emc2.1.6/bin/emcsvr
[18:07:09] <owhite> and my bin does not contain emcsvr.
[18:07:09] <owhite> and suggestions?
[18:07:21] <owhite> er, -any-
[18:08:11] <cradek> do you mean --enable-run-in-place ?
[18:08:21] <owhite> yes.
[18:08:32] <cradek> did the compile fail?
[18:08:59] <owhite> I didnt see any complaints. seemed like it compiled all the way through. I could 'make clean' and try it again.
[18:09:44] <cradek> if you use "script" it's easy to save the compile log
[18:09:46] <alex_joni> owhite: does it contain other stuff (your bin/)
[18:10:04] <owhite> hang on....recompiling.
[18:11:08] <owhite> yah, didnt see any problems.....and yes, I got about 9 programs in bin
[18:11:23] <alex_joni> sounds like too few
[18:11:31] <owhite> yah it does.
[18:11:37] <cradek> I have 47 (trunk)
[18:12:09] <alex_joni> owhite: make clean
[18:12:15] <alex_joni> owhite: script
[18:12:13] <jepler> * jepler looks at his emc2 bin directory wonders why he has a program called "component-name"
[18:12:21] <alex_joni> owhite: make
[18:12:27] <owhite> so I just arbitrarily chose 2.1.6 for my cvs checkout. Would it be wise to try a different release?
[18:12:28] <jepler> #!/usr/bin/python
[18:12:28] <jepler> h = hal.component("component-name")
[18:12:36] <jepler> odd
[18:12:47] <cradek> owhite: depends what you want. I don't see why you would pick 2.1.6 over 2.1.7 though.
[18:12:49] <alex_joni> jepler: I don't have that here
[18:13:02] <jepler> I bet I was testing 'comp --install *.py'
[18:13:08] <owhite> cradek: only because that was waht was on the wiki install page.
[18:13:17] <alex_joni> I have 48 (trunk with simulator)
[18:13:27] <SWPadnos> 47 - trunk RT
[18:13:33] <alex_joni> err.. the 48th is .cvsignore I bet
[18:13:37] <SWPadnos> heh
[18:13:47] <owhite> alex_joni: once the compile is done, I do what?
[18:13:53] <SWPadnos> sudo make setuid
[18:13:55] <alex_joni> ctrl-d iirc
[18:13:58] <alex_joni> SWPadnos: shush
[18:13:59] <SWPadnos> oh ;)
[18:14:07] <SWPadnos> sorry - I'll go back to coffee drinking now
[18:14:19] <SWPadnos> * SWPadnos sticks to what he's good at
[18:14:22] <alex_joni> owhite: it should then say something about saved to 'typescript' or something like that
[18:14:29] <alex_joni> SWPadnos: eating?
[18:14:29] <owhite> setuid is not need for the simulator.
[18:14:36] <alex_joni> owhite: indeed it isn't
[18:14:42] <SWPadnos> oh - sim. sorry
[18:14:53] <alex_joni> did 2.1.x have sim?
[18:14:56] <jepler> alex_joni: yes
[18:15:00] <SWPadnos> alex_joni, no - actually, I think I might be a little ill from lack of sleep - I'm actually not hungry
[18:15:11] <alex_joni> SWPadnos: whoa...
[18:15:23] <alex_joni> jepler: ok, it's been long :(
[18:15:34] <SWPadnos> and I don't have the strength to hate LabView as much
[18:15:56] <owhite> so I should see something about emcsvr in my typescript, yes? it only has two lines, "Depending emc/task/emcsvr.cc
[18:15:57] <owhite> "
[18:15:57] <alex_joni> owhite: the 'script' you ran before compile should log everything from then on
[18:16:03] <owhite> got it.
[18:16:10] <alex_joni> owhite: can you pastebin.ca it?
[18:16:16] <SWPadnos> is this in a system with an installed emc as well?
[18:16:26] <owhite> yes. hang on.
[18:16:31] <jepler> http://pastebin.ca/upload.php
[18:16:38] <SWPadnos> do you need to source emc-environment then?
[18:16:53] <alex_joni> SWPadnos: not to compile
[18:17:01] <owhite> do you mean ". script/emc-environment"
[18:17:07] <SWPadnos> no, but to run - there shouldn't be an emcsvr for sim, should there?
[18:17:09] <alex_joni> owhite: not needed for compiling
[18:17:15] <alex_joni> SWPadnos: yes it should
[18:17:21] <alex_joni> emcsvr is a userspace component
[18:17:32] <SWPadnos> ok - I'll really go back to coffee drinking then ;)
[18:17:36] <alex_joni> it's the component that defines and owns all the NML channels
[18:17:53] <SWPadnos> ok - I wasn't sure that all the NML channels were done the same for sim
[18:17:56] <jepler> I don't see any reason that emcsvr would become an optional target (unlike, say, some of the GUIs)
[18:18:07] <owhite> http://pastebin.ca/742642
[18:18:49] <jepler> #
[18:18:49] <jepler> #
[18:18:49] <jepler> make: Failed to remake makefile `Makefile'.
[18:18:49] <jepler> #
[18:18:50] <jepler> make: Failed to remake makefile `Makefile'.
[18:18:52] <jepler> oops, sorry for the bad paste
[18:19:05] <jepler> these mean something is going wrong, but make isn't saying exactly what
[18:19:06] <SWPadnos> that looks like a pretty old makefile - the converters (conv*.comp) haven't been made for a long time
[18:19:46] <owhite> old makefile as in I should install a different version of emc?
[18:19:50] <alex_joni> owhite: easiest would be to delete the whole dir
[18:19:53] <alex_joni> and checkout 2.1.7
[18:19:56] <owhite> right.
[18:20:10] <SWPadnos> or do a checkout of TRUNK into a new dir :)
[18:20:30] <owhite> if you would be kind enough to shout out the cvs command for trunk that would be great.
[18:20:33] <jepler> make sure that the clock is set right on your system
[18:20:37] <SWPadnos> out of curiosity, can you look at ownership of the Makefile?
[18:20:51] <owhite> SWPadnos: just whacked the whole directory.
[18:20:54] <jepler> To track new feature development, use no "-r" argument. This is called the "CVS TRUNK" (or sometimes, incorrectly, the "CVS HEAD"):
[18:20:57] <jepler> export CVS_RSH=ssh
[18:21:00] <alex_joni> owhite: cvs -d:ext:anon@cvs.linuxcnc.org:/cvs/emc co emc2
[18:21:00] <jepler> cvs -z5 -d:ext:anon@cvs.linuxcnc.org:/cvs co -demc2-trunk emc2
[18:21:12] <alex_joni> oops.. /cvs
[18:21:21] <SWPadnos> what jepler said
[18:21:26] <owhite> hey look at all those great suggestions, now I just have to pick one. :-)
[18:21:35] <alex_joni> picke jepler's
[18:21:41] <alex_joni> he's good at pasting from the wiki :D
[18:21:48] <SWPadnos> cheater
[18:22:01] <SWPadnos> I was typing that exact thing, but it took too long
[18:22:10] <alex_joni> yeah, I typed it too.. but wrong :D
[18:22:18] <SWPadnos> I wasn't doing that ;)
[18:22:27] <alex_joni> sure you weren't
[18:22:38] <SWPadnos> well, I wasn't trying to anyway
[18:22:46] <owhite> so, what I did was just make a new installation of ubuntu 6.16 and then tried to make emc2 -- if you can think of any problems that might have to do with that, let me know. should I do something with the clock?
[18:22:55] <alex_joni> 6.06
[18:23:02] <alex_joni> clock?
[18:23:09] <owhite> okay. 6.06
[18:23:27] <jepler> I noticed that the pastebin said this at the top: Script started on Fri 19 Oct 2007 10:12:36 AM EDT
[18:23:35] <owhite> jepler said: make sure that the clock is set right on your system
[18:23:38] <owhite> right.
[18:23:45] <jepler> Makefile always uses timestamps to determine what to do .. and this time looks wrong
[18:23:54] <alex_joni> owhite: I usually use 'sudo ntpdate time.nist.gov'
[18:24:29] <jepler> (ntpdate may not be installed by default?)
[18:24:34] <alex_joni> I think it is
[18:25:08] <owhite> no server suitable for synchronization found
[18:25:09] <jepler> fwiw I reorganized the Installing_EMC2 page to list the incantation for TRUNK first; I think that's the most common reason people use CVS
[18:25:33] <alex_joni> owhite: try it a couple times
[18:25:53] <owhite> geeze you guys are smart.
[18:26:23] <owhite> either that or I am easily impressed.
[18:26:49] <alex_joni> that's more likely
[18:27:04] <jepler> bbl
[18:27:15] <alex_joni> we're actually markov-model based automatic reply IRC bots
[18:27:34] <alex_joni> make that hidden markov models :)
[18:31:27] <fenn> * fenn hides
[18:32:41] <owhite> so is it a bad idea to try to run emc -as a simulator- on an instalation of ubuntu/linux deployed on a vmware?
[18:32:55] <SWPadnos> no, that seems reasonable
[18:33:35] <SWPadnos> but you do need to be sure to . scripts/emc-environment, or you'll get weird stuff with the installed version
[18:33:35] <cradek> did you start with the emc2 live cd?
[18:33:45] <cradek> if so you can just install the -sim package
[18:33:56] <owhite> cradek: no I didnt.
[18:34:00] <owhite> just ubuntu.
[18:34:12] <SWPadnos> probably better that way for performance
[18:34:34] <cradek> you could still use the -sim package
[18:34:37] <cradek> but whatever
[18:34:37] <cradek> lots of ways
[18:35:23] <owhite> so I was hoping to fool around with trying to labjack, which is a data aquisition device that hangs off of USB.
[18:35:45] <owhite> will I have to have the non-simulator version to work with that?
[18:37:57] <fenn> tomp was working with one of those, but his requirements were pretty lax so it might not do what you want
[18:37:59] <SWPadnos> have you talked to tomp?
[18:38:16] <SWPadnos> the labjack is USB, which is inherently non-realtime
[18:38:21] <owhite> not yet. but I will.
[18:38:34] <SWPadnos> so you should be able to do everything with userspace drivers, which should run fine with sim
[18:38:55] <SWPadnos> unless you'd like to make a kernel-mode RT USB driver framework - that would be cool
[18:39:03] <owhite> well so the only thing I want to do is basically read temperature and display it.
[18:40:17] <SWPadnos> have you donwloaded the librarie sfrom their site?
[18:40:29] <SWPadnos> they have Python and C libs and demo code
[18:41:59] <owhite> yeah i was here a few weeks ago, and asked for advice on displaying temperature (and a couple other things) in pyVCP. People pointed out that they have the python libraries and such, and that it would be pretty easy to connect to pyVCP.
[18:42:28] <owhite> So this constitutes the beginning of that project. I am loading emc2 on a machine at work to fool around. :-)
[18:42:36] <SWPadnos> it's possible that tomp has gotten that far already
[18:42:48] <owhite> great.
[18:54:35] <skunkworks> owhite: have you been running your laser at home with emc2?
[18:55:15] <owhite> I sure have.
[18:57:25] <skunkworks> Cool :)
[19:01:31] <owhite> a recent creation...
[19:01:34] <owhite> http://www.flickr.com/photos/92863063@N00/1347045865/
[19:02:59] <SWPadnos> looks fishy to me
[19:03:24] <skunkworks> nice!
[19:03:48] <fenn> does the frog jump?
[19:04:01] <owhite> someone in my office....hang on.
[19:04:36] <fenn> heh food4thoth
[19:05:10] <SWPadnos> 4thoth? interesting
[19:05:24] <fenn> SWPadnos: http://www.flickr.com/photos/92863063%40N00/1351862215/
[19:05:41] <SWPadnos> ah - didn't notice the comment
[19:05:48] <alex_joni> SWPadnos: you had somethign thoth related.. right?
[19:05:48] <SWPadnos> should have, since that's my company name
[19:05:51] <SWPadnos> yes :)
[19:05:57] <fenn> and he eats a lot
[19:06:00] <SWPadnos> indeed
[19:06:02] <fenn> or so i hear
[19:06:07] <SWPadnos> well, most days
[19:10:46] <owhite> back
[19:19:49] <alex_joni> good night all
[19:57:48] <owhite> anyone have any suggestions on this emc error?....
[19:57:57] <owhite> rror in startup script: unknown option "-padx"
[19:58:08] <owhite> s/rror/error/
[20:01:29] <owhite> its a complaint from this program...
[20:01:32] <owhite> (file "/home/owhite/emc2-trunk/tcl/bin/pickconfig.tcl" line 219)
[20:02:04] <cradek> something wrong with your tcl, or a version incompatibility
[20:02:13] <cradek> tk
[20:02:26] <owhite> I'll look into it.
[20:02:38] <cradek> looks like dapper's is tk8.4
[20:03:23] <owhite> maybe I should apt-get on tk8.4.dev?
[20:03:37] <cradek> what tk do you have?
[20:04:10] <owhite> sorry I dont know how to get a version on it -- cant find the executable. I know its installed somewhere.
[20:04:56] <cradek> dpkg -l 'tk*'
[20:05:13] <cradek> ii tk8.4 8.4.12-0ubuntu1.1 Tk toolkit for Tcl and X11, v8.4 - run-time files
[20:05:53] <owhite> I have several listed. tk8.0, tk8.3, tk8.4
[20:06:10] <cradek> which one, if any, says 'ii'
[20:06:45] <owhite> tk8.0 and tk8.3
[20:07:06] <cradek> strange...
[20:07:16] <cradek> did you say this is dapper?
[20:07:22] <owhite> ubuntu
[20:07:27] <cradek> my dapper has 8.4 but not the others installed
[20:08:06] <owhite> right I had to use synaptic, and I think it (I) loaded more than one package at more than one time.
[20:08:22] <owhite> I was trying to get ./configure to be happy with finding the right lib files.
[20:09:13] <owhite> could I use an apt-get command to back out the tk and tcl files, and load the correct ones?
[20:09:20] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Pure_Simulator
[20:09:28] <cradek> there is a list here that ideally you would have seen before you started
[20:10:01] <owhite> got it.
[20:21:39] <owhite> I uninstalled a lot of older tcl and tk files with synaptic and ran: sudo apt-get install cvs libpth-dev cvs g++ gcc ncurses-dev pciutils-dev tk8.4-dev libgtk2.0-dev tcl8.4 bwidget
[20:22:09] <owhite> it also didnt like my version of wish, but I did "make clean" and emc works now.
[20:22:11] <owhite> :-)
[20:22:16] <cradek> yay
[20:23:46] <owhite> amazing as always.
[20:29:33] <cradek> build dependencies can be a pain...
[20:34:16] <skunkworks> another motherboard bited the dust from exploding capasitors.
[20:34:22] <skunkworks> bites
[20:34:27] <SWPadnos> skreek engrish
[20:35:01] <jepler> skunkworks: is it that one that didn't work with my gutsy realtime kernel?
[20:35:24] <skunkworks> No - different computer.
[20:35:24] <SWPadnos> heh - trying to blame it on the hardware? :)
[20:35:41] <jepler> no, just hoping he'd never be able to test another kernel on that one
[20:35:44] <SWPadnos> heh
[20:35:58] <jepler> speaking of which now that gutsy's really out I should look at that stuff again...
[20:35:59] <skunkworks> jepler: the problem was fixed by turning off the desktop effects.
[20:36:14] <jepler> skunkworks: I meant the system where you had to use "lapic" and got terrible latency
[20:36:36] <skunkworks> oh - have not gotten back to that one. the dell was working good though
[20:37:00] <skunkworks> http://ubuntuforums.org/showthread.php?p=3550299
[20:37:23] <skunkworks> jepler: you may have someone asking about the gutsy kernel
[20:38:08] <SWPadnos> I wonder if it's a smart thing to try to update a gutsy beta install to 7.10 today
[20:39:22] <SWPadnos> hmmm. so here's a driver question for you
[20:39:37] <SWPadnos> there are 4 LEDs on the analog board I made - one each red, green, yellow, white
[20:40:08] <SWPadnos> I'm thinking of naming them xxx.0.green.0 - the second 0 being the board number
[20:40:32] <fenn> what's the first 0?
[20:40:38] <SWPadnos> then again, they could just be blah.0.led.0 through 7 (2 boards(
[20:40:39] <SWPadnos> )
[20:40:44] <SWPadnos> the first 5i22 in the system
[20:40:54] <SWPadnos> one 5i22 can have up to 4 AIO boards
[20:40:57] <fenn> oh
[20:41:08] <skunkworks> ah - that makes sense.
[20:41:19] <fenn> i think you need to have .aio. in there somewhere
[20:41:28] <SWPadnos> I guess it could be .led.0.green or something
[20:42:02] <SWPadnos> yeah - I have a bad name at the moment "thoth_aio.0.dac.0.out" etc
[20:42:13] <fenn> the name hierarchy should match the physical wiring somewhat
[20:42:14] <SWPadnos> though I guess some of those should be dashes instead
[20:42:29] <fenn> so your aio board would be part of the m5i22, the led would be part of that, etc
[20:42:50] <SWPadnos> yeah, though this driver can't run a "normal" 5i22 config
[20:42:57] <fenn> that's ok
[20:43:06] <SWPadnos> I guess it could, for digital I/O only
[20:43:53] <fenn> m5i22.0.aio.0.green
[20:43:54] <SWPadnos> hmmm. maybe I should stick 4 sets of analog control blocks in there, so any connector could be used as digital I/O or an AIO connection
[20:44:03] <SWPadnos> hmmm. that could work
[20:44:57] <SWPadnos> for this driver, I'm not sure I want to use the m5i22 prefix though
[20:45:07] <SWPadnos> but I could
[20:45:12] <SWPadnos> hmmm
[20:45:33] <SWPadnos> actually, there's a problem with halcmd that caused me to name the component that way
[20:45:58] <SWPadnos> when you loadrt, halcmd will tell you that the module wasn't loaded unless it has the same HAL name as the module name
[20:46:14] <fenn> yeah i ran into that with userspace components too
[20:46:32] <SWPadnos> yep, though I think there's a -w or -W option for loadusr
[20:46:55] <fenn> if you use -W it just says waiting for component "foo" to become ready.........................
[20:47:03] <fenn> if the name doesnt match
[20:47:15] <SWPadnos> maybe it was -n or something - there's a way of telling it the name you're expecting
[20:47:19] <SWPadnos> that was added for pyvcp
[20:47:41] <SWPadnos> or -c ?
[20:48:11] <fenn> ion for loadusr
[20:48:18] <fenn> gr
[20:48:27] <fenn> -Wn name to wait for the component, which will have the given name
[20:48:58] <SWPadnos> ok - there you go
[20:49:10] <fenn> not helpful if you dont know what the name is
[20:49:21] <SWPadnos> that could be a problem
[20:49:25] <fenn> i was trying to randomize the name so i could load multiple instances of the hexapod simulator
[20:49:35] <SWPadnos> ah
[20:49:42] <SWPadnos> hexapod-sim$PID
[20:49:48] <fenn> partly because of the bug where it doesnt actually remove the module when you unload it
[20:49:57] <fenn> s/module/component/
[20:50:33] <SWPadnos> there should be a way of suppressing that message, I guess. the component does load, but halcmd doesn't know it
[20:50:50] <SWPadnos> at least with the kernel module, that's what I saw
[22:23:51] <jimlas53> Jepler, are you looking for testers for the emc2/Gutsy build?
[22:24:40] <skunkworks> jimlas53: I am samcoinc. what machines are you running with emc2?
[22:31:50] <jimlas53> Hi Sam! One bench mill with API servos using step/dir, one shop-built router with steppers. Both set up for 4th rotary A axis. The router is a P4 w/512Mb. The mill is Celeron w/512Mb. Both machines have plenty of drive space and they are dedicated.
[22:40:58] <fenn> besides the jiggly windows, why would you want to use gutsy?
[22:46:12] <skunkworks> I know ray was having a hard time getting dapper to run on newer hardware.
[22:52:56] <jimlas53> My first exposure to Linux was RedHat 9, along with the somewhat painful process of building the TR kernel and installing emc1. It was a major pain to network or to work with the system. Yes, I have been a windows user - that's what pays the bills. Ubuntu has been a great leap for those of us who don't want to live in the command line. Gutsy is the next step and it is better at the installation, networking, other system functions. Before I moved the
[22:52:58] <jimlas53> router to its own computer, I had it on my shop machine which was running emc2, VMware/windows/BobCAD, AND streaming music all at the same time. That was on Dapper. I've run Feisty for the last 6 months on my laptop and it has been very stable, but still a little short with dependable network browsing.