Back
[01:40:37] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/Submakefile: oops, didn't define yet, just use yapps instead
[01:43:11] <CIA-8> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[01:43:14] <CIA-8> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot3_log.txt
[01:43:17] <CIA-8> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot5_log.txt
[01:43:17] <CIA-8> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot4_log.txt
[01:43:27] <CIA-8> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[01:43:48] <jepler> compile-farm: ssssssssh
[02:19:29] <A-L-P-H-A> dir
[02:19:32] <A-L-P-H-A> oops. :)
[02:22:51] <CIA-8> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED
[02:22:53] <jmkasunich> one down, four to go...
[02:29:54] <jepler> hi jmkasunich
[02:29:58] <jepler> that was the easy one :-P
[02:30:09] <jepler> I assume, anyway
[02:30:22] <jmkasunich> hi
[02:30:29] <jmkasunich> I like apt ;-)
[02:30:37] <jepler> yeah it's pretty good
[02:30:50] <jepler> I used to think rpm+yum were just as good but that's before I used dpkg+apt
[02:30:56] <jmkasunich> slot 4 now has yapp, and is compiling (but its the slowest one)
[02:31:04] <jmkasunich> slot 3 is doing an apt-get update
[02:31:05] <jepler> yum in particular sucks -- everything is terribly slow
[02:31:38] <jepler> did you see my notes on #emc-devel about the rpm packages you might try to install on bdi2?
[02:31:43] <jmkasunich> yeah
[02:31:50] <jepler> you'll have to download yapps2 source separately of course
[02:31:50] <jmkasunich> I was going for the easy ones first
[02:31:55] <jepler> I don't blame you
[02:32:27] <jmkasunich> crapp
[02:32:36] <jmkasunich> the BDI-Live apt-get can't find yapp2
[02:32:43] <jepler> drat
[02:32:53] <jmkasunich> thats morphix
[02:33:09] <jmkasunich> wonder if there are other repositories that might have it
[02:34:11] <jmkasunich> sources.list includes debian stable and testing...
[02:39:01] <jmkasunich> I find it odd that "deb
http://ftp.debian.org/debian/ testing main non-free contrib
[02:39:01] <jmkasunich> " doesn't include yapp
[02:39:51] <jepler> I'm looking at the source for the ubuntu package .. it looks like they changed it fairly heavily compared to "2.1.1"
[02:41:51] <jepler> http://us.archive.ubuntu.com/pub/ubuntu/pool/main/y/yapps2/yapps2_2.1.1-17.diff.gz
[02:43:28] <jepler> I could change the yapps stuff to be optional for now
[02:43:42] <jmkasunich> that might be good
[02:43:52] <jmkasunich> without yapps you just don't get those extra components, right?
[02:43:55] <jepler> right
[02:44:57] <jmkasunich> what are .mak files?
[02:45:33] <jmkasunich> maybe I should just read the commit message diff
[02:47:39] <jepler> oh don't ask
[02:47:46] <jepler> the commit doesn't really explain
[02:48:22] <jepler> for kbuild, you put the name of each module you want to build in the variable 'obj-m', and the name of all the object files that go into it in objs-modulename
[02:48:35] <jmkasunich> dang, dave E has great timing doesn't he
[02:49:12] <rayh> Dave and I were both having trouble today.
[02:49:16] <jepler> make isn't flexible enough to create all those variables, so instead I create a bunch of very short makefiles (objects/.../*.mak) which create the variables, which are all included in the makefile
[02:49:29] <jmkasunich> ok
[02:49:38] <jmkasunich> I guessed some kind of makefile stuff
[02:49:57] <jmkasunich> configure creates those? or make?
[02:50:01] <jepler> make does
[02:50:05] <jmkasunich> duh
[02:50:12] <jepler> when it sees a particular .comp file, it makes and then includes a .mak file
[02:50:34] <jmkasunich> and the include in the submakefile includes *.mak
[02:52:40] <CIA-8> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[02:53:43] <jmkasunich> two down
[02:53:53] <jmkasunich> strange tho: from farm_log:
[02:53:54] <jmkasunich> 2006-09-07 02:50:32 results_cia: emc2head : mailing cia.msg
[02:53:54] <jmkasunich> 2006-09-07 02:52:32 results_cia: emc2head : mail failed
[02:53:54] <jmkasunich> 2
[02:54:04] <jepler> huh
[02:54:13] <jmkasunich> must not have failed, we got the message
[02:55:46] <jmkasunich> what is the actual line for getting the build deps? is it "sudo apt-get install build-deps
[02:55:48] <jmkasunich> oops
[02:55:56] <jmkasunich> what is the actual line for getting the build deps? is it "sudo apt-get build-deps emc2"
[02:56:03] <jepler> sudo apt-get build-dep packagename
[02:56:15] <jmkasunich> close
[02:56:22] <jepler> but that gets the requirements to build the packaged version of emc2, which is different than what it takes to build the CVS version
[02:56:57] <jmkasunich> oh
[02:57:01] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (Makefile.inc.in configure configure.in): make 'yapps2' optional for now -- but you have to install it to get the new *.comp components
[02:57:01] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/Submakefile: make 'yapps2' optional for now -- but you have to install it to get the new *.comp components
[02:57:02] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/components/Submakefile: make 'yapps2' optional for now -- but you have to install it to get the new *.comp components
[02:57:11] <jmkasunich> the yapp2 dependency won't be in there until we package up 2.1.testing I guess
[02:57:16] <jepler> right
[02:59:38] <jepler> in the file debian/control the Requires: and Build-Requires: lines are usually kept up-to-date
[02:59:51] <jepler> but I'm not sure how to tell apt or dpkg 'look at this control file and get me the requirements'
[03:00:03] <jmkasunich> not gonna sweat it
[03:00:15] <jmkasunich> I just corrected my initial email to the list
[03:00:52] <rayh> Should we update the wiki page?
[03:01:04] <jmkasunich> about what? comp?
[03:01:53] <CIA-8> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[03:02:10] <jmkasunich> now what!?
[03:02:18] <jepler> jmkasunich: I forgot to make python optional again
[03:02:20] <jmkasunich> still wants python
[03:02:30] <jmkasunich> I can install python,
[03:04:41] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (configure configure.in): make python optional again too
[03:16:34] <CIA-8> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[03:17:03] <jepler> goodnight
[03:17:49] <CIA-8> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED
[03:19:22] <jmkasunich> goodnight
[03:19:41] <jmkasunich> only one left... (slow one)
[03:26:48] <CIA-8> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build PASSED
[03:27:31] <jmkasunich> one big happy family again ;-)
[03:53:31] <dave1> jmk ... got thru the second cvs up -dP
[03:54:59] <dave1> so did I wipe enough stuff with the rm -rf lib so I need to configure and make again?
[04:02:21] <dave1> is anyone awake?
[04:02:45] <dave1> pretty late | early for alex
[10:19:15] <acemi> I have libxaw7 and libxaw7-dev installed, but I get "checking for main in -lXaw... no, configure: WARNING: Xaw lib missing". After adding "-L /usr/X11R6/lib" to "ac_link=..." in src/configure at line 3822, I get "checking for main in -lXaw... yes". My box is Debian Sarge and libXaw.a is in /usr/X11R6/lib
[10:20:21] <acemi> is there a configure parameter whick cab be used to set -L value
[10:38:22] <alex_joni> acemi: not sure there is, but I'll make the change
[10:38:43] <acemi> thanks alex_joni
[10:42:39] <alex_joni> acemi: you can try ./configure --help
[10:44:17] <acemi> thanks agian
[10:44:26] <alex_joni> acemi: no need for all the thanking :D
[10:44:34] <alex_joni> glad if I can help
[10:45:01] <alex_joni> I'm hating VMWare Server right now
[10:46:36] <danex> Hello All
[10:47:37] <alex_joni> hello
[10:49:14] <danex> I will be trying to do test cuts today with my project machine
[10:53:08] <alex_joni> nice to hear
[10:54:08] <danex> Still have to get the M code thing done and some E-stop quirks ironed out, but expect it to be O.K.
[10:54:45] <alex_joni> acemi: it'll take a while, I'm reinstalling my vmware :/
[10:55:53] <acemi> LDFLAGS=-L/usr/X11R6/lib/ ./configure works
[10:56:13] <alex_joni> acemi: good.. but I think it should still be in configure
[10:56:19] <acemi> ok
[10:58:58] <alex_joni> acemi: what kernel did you use on sarge?
[10:59:03] <alex_joni> did you go with the BDI one?
[10:59:32] <danex> Have to go to work now, be back later
[10:59:43] <alex_joni> see you danex
[11:00:25] <acemi> 2.6.12.6 kernel from BDI
[11:02:14] <alex_joni> acemi: ok..
[11:02:22] <alex_joni> hmm.. users do some crazy things..
[11:02:36] <alex_joni> like using breezy kernel & packages on dapper :(
[11:04:35] <acemi> maybe one install script which control the distrubition will be nice
[11:08:18] <alex_joni> acemi: can you test the above again, but using LIBS=/usr/X11r6/lib/ instead of the LDFLAGS
[11:08:28] <alex_joni> I'm not 100% sure how LIBS is supposed to work :)
[11:08:35] <A-L-P-H-A> wuzzup?
[11:08:39] <acemi> ok
[11:11:01] <acemi> checking for C compiler default output file name... configure: error: C compiler cannot create executables
[11:12:18] <alex_joni> eeek.. ok.. drop it ;)
[11:13:39] <acemi> LDFLAGS=-L/usr/X11R6/lib/ works at configure time but I get error at make -> Linking xemc, /usr/bin/ld: -lX11 bulunamadi
[11:13:51] <acemi> bulunamadi -> not found
[11:13:52] <alex_joni> yes, I know
[11:14:04] <alex_joni> what is bulunamadi ??
[11:14:30] <acemi> bulunamadi means not found
[11:14:42] <alex_joni> lol, OK
[11:15:38] <alex_joni> acemi: can you test a change on configure.in ?
[11:15:51] <alex_joni> my vmware is still installing
[11:16:58] <acemi> yes
[11:17:13] <acemi> what I'll change
[11:18:22] <acemi> what will I change in configure.in?
[11:18:54] <alex_joni> ok, find these lines:
[11:19:03] <alex_joni> if test "x$HAVE_XAW" = "xno"; then
[11:19:03] <alex_joni> AC_MSG_WARN(Xaw lib missing, you won't be able to build/run xemc. try installing it with 'apt-get install libxaw7-dev')
[11:19:06] <alex_joni> else
[11:19:08] <alex_joni> XAW_LIBS="-lX11 -lXaw"
[11:19:11] <alex_joni> fi
[11:19:23] <alex_joni> change XAW_LIBS="-lX11 -lXaw", to XAW_LIBS=$LIBS
[11:19:49] <alex_joni> then rerun configure with the LDFLAGS in front of it, and tell me what the Makefile.inc has for XAW_LIBS
[11:20:14] <alex_joni> although it makes me wonder if maybe something is not quite set up as it should on debian
[11:20:31] <alex_joni> the /usr/X11R6/lib should be in the default path for libs
[11:24:37] <acemi> I can't run configure now, I get checking for C compiler default output file name... configure: error: C compiler cannot create executables
[11:25:12] <alex_joni> that sounds like a different error
[11:25:21] <alex_joni> maybe it's using the wrong gcc?
[11:25:25] <acemi> I'll try again
[11:25:40] <alex_joni> but the change you made shouldn't at all influence this
[11:29:05] <alex_joni> acemi: is /usr/X11R6/lib in your /etc/ls.so.conf ?
[11:29:48] <acemi> there is no file as /etc/ls.so.conf
[11:30:18] <acemi> ld.so.conf ?
[11:30:25] <alex_joni> ld.so.conf ;)
[11:30:28] <alex_joni> sorry.. typo
[11:30:37] <acemi> yes, there is
[11:31:07] <alex_joni> what's in there?
[11:31:21] <alex_joni> I expect /lib /usr/lib /usr/X11R6/lib ?
[11:31:23] <acemi> there is no XAW_LIBS in Makefile.inc
[11:31:43] <acemi> /usr/X11R6/lib
[11:31:58] <alex_joni> XLIBS
[11:32:05] <acemi> XLIBS = -lX11 -lXaw
[11:32:33] <alex_joni> odd.. try running 'ldconfig'
[11:32:44] <alex_joni> and see if that makes it work ?
[11:35:03] <acemi> configure: WARNING: Xaw lib missing
[11:35:46] <alex_joni> so still not found.. durn it
[11:35:59] <alex_joni> ok, my vmware server finished reinstalling :)
[11:36:15] <alex_joni> I'll have a look where Xaw is on Ubuntu
[11:44:39] <alex_joni> acemi: it seems on Ubuntu it's under /usr/lib
[11:45:56] <alex_joni> acemi: can you test another change?
[11:46:01] <acemi> yes
[11:46:16] <alex_joni> replace:
[11:46:17] <alex_joni> AC_CHECK_LIB(Xaw, main,
[11:46:17] <alex_joni> [],
[11:46:17] <alex_joni> [HAVE_XAW=no])
[11:46:19] <alex_joni> with:
[11:48:40] <alex_joni> AC_CHECK_LIBS(main, [Xaw /usr/X11R6/lib/Xaw], [], [HAVE_XAW=no])
[11:51:05] <acemi> configure: WARNING: Xaw lib missing
[11:52:18] <alex_joni> I trust you recreated configure
[11:52:45] <acemi> I recreated all emc directory
[11:54:24] <alex_joni> to recreate ./configure you usually run autoconf
[11:54:33] <acemi> AC_CHECK_LIBS or AC_CHECK_LIB
[11:54:38] <alex_joni> then it generates ./configure from configure.in
[11:54:43] <alex_joni> CHECK_LIBS
[11:54:49] <alex_joni> and notice the order is inverted
[11:55:11] <acemi> the old one is LIB
[11:55:19] <alex_joni> right
[11:55:52] <alex_joni> I found a similar issue on another project, and they seem to use ./configure --with-Xawlibdir=/path/foo to overcome it
[11:55:56] <alex_joni> would that be a problem?
[11:56:22] <acemi> for me? no
[11:56:54] <alex_joni> I think that would be the 'proper' fix for it
[11:57:51] <acemi> maybe configure can get lib path from /etc/ld.so.conf
[11:59:30] <alex_joni> don't think so ..
[12:01:45] <jepler> maybe AC_PATH_X is what you want
[12:02:25] <jepler> there are a bunch of macros in /usr/share/autoconf/autoconf/libs.m4 related to detecting X properly
[12:02:29] <jepler> we sholdn't have to write this ourselves
[12:02:57] <alex_joni> I know .. but it's a mess (documentation wise)
[12:03:12] <alex_joni> jepler: a recent update seems to be failing..
[12:03:26] <jepler> eh?
[12:03:41] <jepler> what update?
[12:03:45] <alex_joni> cvs update
[12:03:52] <alex_joni> on a vmware dapper I had around
[12:04:01] <jepler> what failed about it?
[12:04:06] <alex_joni> hang on, I'm trying to paste the problem
[12:04:11] <alex_joni> comp related
[12:05:31] <alex_joni> emc/usr_intf/axis/scripts/comp.g emc/usr_intf/axis/scripts/comp.py
[12:05:31] <alex_joni> make: execvp: emc/usr_intf/axis/scripts/comp.g: Permission denied
[12:05:31] <alex_joni> make: *** [emc/usr_intf/axis/scripts/comp.py] Error 127
[12:05:38] <jepler> you updated at the wrong moment
[12:06:12] <jepler> well, it was longer than a moment, but that's fixed now
[12:08:19] <alex_joni> I just updated now
[12:08:25] <jepler> and you still get that error?
[12:08:45] <alex_joni> nope :)
[12:08:50] <jepler> oh
[12:08:51] <jepler> good
[12:09:09] <alex_joni> how about the libxaw ?
[12:09:25] <alex_joni> think we can include something ?
[12:14:57] <alex_joni> AC_PATH_X or AC_PATH_XTRA sound promising
[12:17:31] <jepler> how come AC_PATH_X isn't documented in my autobook.info? it's frustrating
[12:17:47] <alex_joni> it is in the autoconf.html I have around
[12:18:43] <alex_joni> www.gnu.org/software/autoconf/manual/autoconf-2.57/autoconf.html
[12:19:10] <jepler> huh -- the documentation must have gotten worse for 2.59
[12:33:18] <jepler> man what a pita
[12:33:20] <jepler> autoconf
[12:33:23] <jepler> I think I'm just about done
[12:34:54] <alex_joni> me too ;)
[12:35:03] <jepler> oh
[12:35:05] <jepler> :-P
[12:35:24] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (Makefile.inc.in configure configure.in): use AC_PATH_X and the variables it sets when looking for Xaw and building/linking xemc
[12:35:24] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/Submakefile: use AC_PATH_X and the variables it sets when looking for Xaw and building/linking xemc
[12:35:45] <alex_joni> I think AC_PATH_X is not OK
[12:35:51] <alex_joni> I would use AC_PATH_XTRA
[12:36:04] <alex_joni> because it sets X_LIBS X_EXTRA_LIBS and X_PRE_LIBS
[12:36:10] <alex_joni> and at least X_LIBS is needed..
[12:36:17] <alex_joni> but then again.. what do I know ;)
[12:41:20] <alex_joni> jepler: looking at that stuff I doubt it will work for acemi
[12:41:36] <alex_joni> XAW_LIBS needs to have -L/usr/X11/lib in it
[12:49:36] <alex_joni> acemi: can you test what jepler put in CVS if it works for you?
[12:53:22] <jepler> alex_joni: perhaps I got it wrong
[12:53:35] <alex_joni> jepler: I have a small change I'll commit.. can you verify ?
[12:53:49] <jepler> I don't have a system with this problem either...
[12:54:23] <alex_joni> ok, then at least that it still works as it should :D
[12:55:05] <jepler> * jepler waits for his 'cvs up'
[12:55:28] <jepler> it's much slower when I'm not at home
[12:56:02] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/ (Makefile.inc.in configure configure.in): slightly different fix to check for X and Xaw
[12:57:07] <alex_joni> hi ray
[12:57:19] <alex_joni> jepler: I can imagine ;)
[12:57:31] <rayh> And I just figured out I needed Xaw but have not figured out why.
[12:57:49] <alex_joni> rayh: for xemc you need it
[12:58:23] <rayh> Okay.
[12:58:37] <rayh> Hi Alex.
[12:58:42] <alex_joni> :)
[12:58:48] <rayh> Sent a reply to your note.
[12:58:55] <rayh> Will be here for a bit this morning.
[12:59:28] <rayh> I see wiki.linuxcnc.org is not working for me now.
[12:59:43] <jepler> alex_joni: ok I think your version looks better than mine
[13:00:19] <jepler> rayh: yeah my browser is also not loading it .. or loading slowly
[13:00:35] <jepler> all together now: "than you sourceforge for the reliable services you offer"
[13:00:43] <jepler> bbl
[13:00:56] <rayh> Right!
[13:01:05] <lilo> whoops
[13:07:56] <alex_joni> hello lilo, not everyday we have such prestigeous guests in here :)
[13:13:37] <acemi> "XAW_LIBS=-L/usr/X11R6/lib ./configure" works fine, but I couldn't check the last change yet
[13:13:40] <lilo> hehe, unfortunately, I'm just passing through this time, but hopefully I'll have a chance to stay for longer at some point! :)
[13:13:42] <lilo> * lilo waves
[13:31:02] <jepler> wiki loads for me now
[13:38:37] <rayh> thanks for the heads up.
[13:40:20] <rayh> still nothing here.
[13:40:26] <alex_joni> hmm.. too bad acemi is gone
[13:40:36] <alex_joni> jepler: I noticed one strange thing
[13:40:43] <jepler> alex_joni: what's that?
[13:41:13] <alex_joni> when linking xemc now, some lICE or similar strange name gets linked too
[13:41:24] <alex_joni> does that have any impacts?
[13:41:39] <jepler> alex_joni: yeah that's probably a side-effect of using those autoconf macros
[13:41:40] <alex_joni> maybe size of the bin?
[13:42:41] <jepler> a tiny penalty in size maybe -- if it's dynamic linking, then little more than the name of the library will be stored in the binary
[13:44:10] <alex_joni> then it's probably safe
[13:44:40] <jepler> I notice that emcsh already linked to libICE so it won't create extra dependencies either
[13:44:44] <jepler> in the apt-get sense
[13:44:55] <alex_joni> I was wondering about the X_EXTRA_LIBS I put in there.. maybe that can go away .. but I'd like to have acemi test first
[13:45:20] <alex_joni> I think the libICE only appears in that list if it exists by the time configure does it's magic
[13:45:36] <alex_joni> configure is some powerfull thing, with crappy docs
[13:45:51] <jepler> yep that's good summary
[13:45:53] <jepler> probably applies to emc2 too
[13:46:09] <alex_joni> probably applies to most any OSS
[13:46:33] <alex_joni> although emc2 has begun to have better docs lately
[13:47:09] <alex_joni> * alex_joni hides a bit in his real work
[13:47:27] <rayh> X11 Inter-Client Exchange library
[13:47:27] <rayh> This package provides the main interface to the X11 Inter-Client Exchange
[13:47:27] <rayh> library, which allows for communciation of data between X clients.
[13:48:28] <rayh> Whatever that means.
[13:48:44] <alex_joni> indeed :)
[13:49:52] <rayh> It looks like ./configure is fairly happy with the packages I've installed.
[13:50:38] <alex_joni> ./configure is a happy piece of crap :D
[13:51:08] <rayh> Yesterday I had a problem getting a new make to run.
[13:51:28] <alex_joni> there was a bit of problem with a yapps thingie ;)
[13:51:29] <rayh> Seems that some of the "old" emc was in the kernel and it couldn't remove them.
[13:51:37] <alex_joni> oh.. like that?
[13:51:57] <alex_joni> usually I get it to work if I restart emc2 a couple of times
[13:52:05] <rayh> Odd issue but until I rmmod'd them it hung.
[13:53:28] <rayh> what's up with all the @@@ during make?
[13:53:39] <alex_joni> tex2html
[13:54:12] <rayh> okay.
[14:41:38] <alex_joni> laters everyone
[14:42:32] <jepler> see you alex_joni
[15:02:41] <Lerneaen_Hydra> 'lo
[15:14:28] <jepler> hi Lerneaen_Hydra
[15:20:16] <Lerneaen_Hydra> what's happening in the world of EMC?
[15:29:20] <jepler> heard about 'comp' yet?
[15:29:35] <jepler> hi pier
[15:33:10] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/task/emctaskmain.cc: emove dead code: LINUX_KERNEL_2_2 has no way of ever being defined
[15:37:20] <Lerneaen_Hydra> jepler: hmm, nope
[15:37:58] <Lerneaen_Hydra> jepler: wassat?
[15:38:34] <pier_gar> hi all
[15:38:38] <pier_gar> hi jepler
[15:45:22] <jepler> Lerneaen_Hydra: a nice way to write hal components without writing tons of code
[15:45:29] <Lerneaen_Hydra> ooh
[15:45:31] <Lerneaen_Hydra> nice
[15:45:42] <Lerneaen_Hydra> so custom hal components are feasible
[15:45:56] <jepler> yeah
[15:46:29] <jepler> here's one of the simplest possible examples:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/components/charge_pump.comp?rev=1.1;content-type=text%2Fx-cvsweb-markup
[15:46:38] <Lerneaen_Hydra> anything new wrt image-to-gcode?
[15:46:41] <jepler> it just creates a bit that toggles on and off forever
[15:46:57] <jepler> no I haven't done much more on i2g
[15:47:13] <Lerneaen_Hydra> oh, ok
[15:47:21] <Lerneaen_Hydra> any plans on adding more?
[15:47:53] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/comp.g: use new HAL direction constants
[15:47:53] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/components/ (blend.comp ddt.comp edge.comp maj3.comp): use new HAL direction constants
[15:48:25] <jepler> I've been distracted by other things ...
[15:49:07] <jepler> I think my next task is putting together a sim-lathe configuration
[15:49:56] <Lerneaen_Hydra> you mean .ini?
[15:50:05] <Lerneaen_Hydra> or some axis-simulation?
[15:50:16] <Lerneaen_Hydra> s/axis/AXIS
[15:50:52] <jepler> an ini file really
[15:51:04] <jepler> it will use axis of course
[15:52:10] <Lerneaen_Hydra> oh, ok
[15:52:37] <Lerneaen_Hydra> I started thinking 3d-opengl stuff (which might be cool, but probably not very important)
[15:53:09] <Lerneaen_Hydra> what is it that differs between lathe and mill though? other than number of axes and LATHE = trye
[15:53:16] <Lerneaen_Hydra> s/trye/true
[15:57:00] <jepler> a simulated spindle of slightly irregular speed
[15:57:34] <cradek> jepler: you can find that in max's history somewhere, that's the first thing I did for threading
[15:57:51] <cradek> but I don't remember why I took it out, maybe it didn't work right
[16:01:52] <CIA-8> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[16:02:11] <alex_joni> back
[16:02:35] <Lerneaen_Hydra> hi alex
[16:03:47] <cradek> uh-oh
[16:03:53] <jmkasunich> ?
[16:04:01] <alex_joni> cradek: what? did I scare you that much?
[16:04:07] <cradek> hi jmk, not used to you being here
[16:04:10] <cradek> the compile failure
[16:04:13] <jmkasunich> boo!
[16:04:17] <jmkasunich> comp
[16:04:27] <alex_joni> .me looks at jepler
[16:04:27] <jmkasunich> didn't like the most recent change I think
[16:04:30] <alex_joni> * alex_joni looks at jepler
[16:04:42] <jmkasunich> loads of inscrutable python (I think) messages
[16:04:48] <jepler> wth?
[16:05:05] <jmkasunich> on breezy
[16:05:18] <Lerneaen_Hydra> * Lerneaen_Hydra tries to look reasonably intelligent
[16:05:22] <jmkasunich> dunno about the others, they probably haven't gotten that far
[16:05:26] <jepler> sigh
[16:05:32] <jepler> attack of the last minute "harmless" edit
[16:05:55] <alex_joni> * alex_joni tries on dapper
[16:05:58] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/comp.g: apparently you can't put a line-break there -- doh!
[16:07:13] <jmkasunich> isn't python the language where blocks are determined by indentation?
[16:07:17] <jmkasunich> btw, that fixed it
[16:07:27] <jmkasunich> it will take the farm a while to figure it out tho
[16:08:28] <jepler> yeah that's basically true but that part is in the "grammar" of comp.g, and my intuition was that I could put a newline there because it was inside a "{{ ... }}" block (which is yapps, not python)
[16:08:47] <alex_joni> * alex_joni looks at the CF logs, and smiles in proudness
[16:09:29] <alex_joni> it seems all the compile_farm slots figured out X properly, and Xaw too
[16:09:29] <jmkasunich> damn thats a lot of builds
[16:09:50] <CIA-8> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED
[16:10:37] <alex_joni> jmkasunich: the others probably don't have yapps
[16:11:04] <jmkasunich> BDI-4.20 does, I installed it last night
[16:11:20] <alex_joni> then maybe it didn't get so far
[16:11:48] <jmkasunich> its still building on the first commit, which will fail, then it will see the fix and do it again
[16:11:55] <jmkasunich> that is by far the slowest slot
[16:12:07] <alex_joni> * alex_joni wonders why
[16:12:10] <jmkasunich> bloat
[16:12:22] <alex_joni> more than breezy...
[16:12:26] <alex_joni> * alex_joni hmmms
[16:12:26] <jmkasunich> breezy would probably be worse, if it was running on the same hardawre
[16:12:33] <alex_joni> ahh.. ok :)
[16:12:40] <jmkasunich> but the breezy "slot" is actually this box
[16:12:45] <alex_joni> remembered you have another box for that
[16:13:14] <jmkasunich> 1600MHz instead of 200 ;-)
[16:17:44] <alex_joni> jmkasunich: I'm working on replacing RD/WR with IN/OUT
[16:17:55] <alex_joni> just wanted to tell you so we don't work on the same thing
[16:18:19] <CIA-8> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot5_log.txt
[16:18:45] <jmkasunich> ok
[16:18:59] <jmkasunich> I'm working on threading some parts, so there's no danger of that right now
[16:19:10] <jmkasunich> (I'm way behind schedule on these jigs I'm building)
[16:19:20] <alex_joni> ok, good
[16:42:44] <CIA-8> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[16:49:35] <Lerneaen_Hydra> O.o , what's this with BDI?
[16:53:56] <alex_joni> it finally finished to compile
[16:54:30] <Lerneaen_Hydra> I was thinking more along the lines of why run a BDI machine?
[16:56:35] <jmkasunich> we certainly don't encourage it
[16:56:53] <jmkasunich> but we try to make sure emc2 will run on if if you want
[16:57:07] <Lerneaen_Hydra> oh, so you try to support it nonetheless?
[16:57:23] <alex_joni> Lerneaen_Hydra: right
[16:57:23] <jmkasunich> yeah
[16:58:29] <alex_joni> jmkasunich: I changed all HAL_RD to HAL_IN, HAL_WR to HAL_OUT, and HAL_RD_WR to HAL_IO
[16:58:33] <alex_joni> only for pins
[16:58:39] <alex_joni> is it ok if I commit it like that?
[16:58:43] <alex_joni> and then tackle params?
[16:58:53] <jmkasunich> sure
[16:58:54] <alex_joni> or do you prefer one big lump
[16:59:00] <jmkasunich> and thank you
[16:59:05] <jmkasunich> no need
[17:03:26] <alex_joni> flood away
[17:04:08] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/emc/motion/motion.c: changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:04:13] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/hal/classicladder/module_rt.c: changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:04:13] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/hal/drivers/ (11 files): changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:04:34] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/hal/user_comps/devices/hal_joystick.c: changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:04:34] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/hal/components/ (16 files): changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:04:41] <CIA-8> 03alex_joni 07HEAD * 10emc2/src/hal/user_comps/vcp/vcp_widgets.c: changed all HAL pin types according to the new naming: HAL_RD => HAL_IN, HAL_WR => HAL_OUT, HAL_RD_WR => HAL_IO
[17:12:24] <alex_joni> jmkasunich: I see that params exist of 3 types: HAL_RD, HAL_WR and HAL_RD_WR
[17:13:00] <alex_joni> I get it that HAL_RD -> HAL_RO and HAL_RD_WR = HAL_RW
[17:13:07] <alex_joni> how about HAL_WR params ?
[17:16:08] <jmkasunich> HAL_WR -> HAL_RW
[17:16:27] <jmkasunich> there is no such thing as a write only param (from the user's perspective)
[17:16:50] <jmkasunich> the old WR meant "the user writes this to config the component, and the component will never change it"
[17:17:00] <alex_joni> right.. irrelevant
[17:17:08] <alex_joni> ok, gotta run for a bit.. I'll continue later
[17:17:17] <jmkasunich> got the OD of my bronze nuts threaded...
[17:17:28] <jmkasunich> now I have to make matching threads in the ID of the holes they fit in
[17:22:25] <Lerneaen_Hydra> jmkasunich: threading in a lathe?
[17:22:37] <jmkasunich> yeah
[17:22:54] <jmkasunich> I really should get my CNC retrofit done, it would be much easier to thread
[17:23:38] <Lerneaen_Hydra> nice
[17:23:46] <Lerneaen_Hydra> oh, you're doing it in a manual?
[17:24:01] <jmkasunich> worse, on a Shoptask
[17:24:06] <jmkasunich> no half nuts
[17:24:16] <Lerneaen_Hydra> shoptask?
[17:24:20] <Lerneaen_Hydra> * Lerneaen_Hydra looks around
[17:24:24] <jmkasunich> 3-in-1 machine
[17:24:33] <Lerneaen_Hydra> oh noes
[17:24:42] <Lerneaen_Hydra> that looks... nasty
[17:25:24] <Lerneaen_Hydra> aka why get three seperate devices that do three things well when you can get one device that does three things really badly?
[17:25:24] <jmkasunich> not fin
[17:25:52] <jmkasunich> back in 1998 when I got it I didn't know better
[17:26:02] <jmkasunich> the lathe part is pretty decent, and more CNC ready than most
[17:26:21] <jmkasunich> the mill part is crippled by short Z (quill) travel and limited rigidity
[17:26:37] <jmkasunich> the drillpress part even more limited by the quill travel problem
[17:26:40] <Lerneaen_Hydra> argh
[17:26:46] <Lerneaen_Hydra> how little travel?
[17:26:48] <jmkasunich> but I have a nice 15" Clausing drillpress
[17:26:49] <jmkasunich> 3"
[17:27:04] <jmkasunich> and I have a Van Norman #12 mill
[17:27:07] <Lerneaen_Hydra> haha
[17:27:12] <jmkasunich> (both purchased _after_ the shoptask)
[17:27:15] <Lerneaen_Hydra> that's really nothing
[17:27:20] <Lerneaen_Hydra> 75mm, ffs
[17:27:28] <jmkasunich> however, the shoptask has one big advantage, I was able to get it into the basement
[17:27:38] <Lerneaen_Hydra> oh, yeah that's a benefit
[17:27:43] <jmkasunich> the mill is in the unheated, detached garage
[17:27:52] <Lerneaen_Hydra> oh, not fun in the winter
[17:28:09] <jmkasunich> I also have a 13" lathe, which is also in the garage, and which I almost _never_ use
[17:28:18] <jmkasunich> because the shoptask is more convenient
[17:28:58] <jmkasunich> I paid less for the mill and 13" lathe combined (used) than I did for the Shoptask new :-(
[17:29:04] <Lerneaen_Hydra> :(
[17:29:14] <jmkasunich> but the ST fits on a 2x4 foot bench
[17:29:20] <Lerneaen_Hydra> the shoptask looks very retrofittable
[17:29:48] <jmkasunich> yeah - the desire to CNC it is what got me involved in EMC in the first place
[17:29:57] <Lerneaen_Hydra> oh, I see
[17:30:15] <jmkasunich> 4 years or so later, I'm a lead developer for EMC, but the conversion is barely started
[17:30:21] <Lerneaen_Hydra> haha
[17:31:16] <Lerneaen_Hydra> are lathe users relatively new IRT emc?
[17:31:23] <jmkasunich> wow, shoptask really got expensive
[17:31:27] <jmkasunich> $4K now
[17:31:30] <Lerneaen_Hydra> as lathe stuff seems to have been added really recently
[17:31:31] <jmkasunich> mine was $1500
[17:31:32] <Lerneaen_Hydra> eek
[17:31:35] <Lerneaen_Hydra> EEK!
[17:31:40] <jmkasunich> that's fscking insane
[17:31:49] <Lerneaen_Hydra> that's...
[17:31:52] <Lerneaen_Hydra> unreasonable
[17:35:21] <Lerneaen_Hydra> then again, that's for a brand new machine
[17:35:38] <jmkasunich> they've changed a lot since mine
[17:36:00] <jmkasunich> the Z drive on mine was rack and pinion like a drill press, tons of backlash
[17:36:06] <jmkasunich> no power feed on Y
[17:36:29] <Lerneaen_Hydra> rack and pinion for a mill O.o
[17:36:39] <Lerneaen_Hydra> sounds promising ;)
[17:37:05] <jmkasunich> you pretty much had to feed to depth and lock, then start milling
[17:37:42] <Lerneaen_Hydra> and how do you know you're at the right depth?
[17:37:47] <jmkasunich> heh
[17:37:56] <jmkasunich> I made a "readout"
[17:38:17] <jmkasunich> got a cheap 4" dial calipers, ground the jaws off, and mounted it to measure the quill travel
[17:38:29] <jmkasunich> worked pretty well
[17:38:42] <Lerneaen_Hydra> oh, heh.
[17:38:52] <Lerneaen_Hydra> spring loaded?
[17:38:58] <jmkasunich> no
[17:39:11] <jmkasunich> you know the little rod that sticks out the back end to measure depth?
[17:39:17] <Lerneaen_Hydra> yeah
[17:39:22] <jmkasunich> I clamped that rod to the quill, and the body to the head of the machine
[17:39:37] <jmkasunich> so as the quill goes down, the rod gets pulled out and the dial turns
[17:39:39] <Lerneaen_Hydra> how'd you clamp it to the quill?
[17:40:08] <jmkasunich> tiny version of a milling clamp
[17:40:14] <Lerneaen_Hydra> oh, does that bit of the quill spin?
[17:40:19] <jmkasunich> no
[17:40:22] <Lerneaen_Hydra> ah, ok
[17:40:27] <Lerneaen_Hydra> that simplifies stuff
[17:40:45] <jmkasunich> you know the part on a drill press that holds the depth stop rod and moves up/down with the quill>?
[17:40:48] <jmkasunich> I attached it to that
[17:41:29] <Lerneaen_Hydra> I think I know what you mean
[17:41:48] <Lerneaen_Hydra> the fact that all the terms I know are in swedish doesn't help :p
[17:43:47] <jmkasunich> quill is not the rotating part - its the part that goes up and down on a drillpress or bridgeport mill. It holds the spindle bearings, and the spindle passes through it
[17:44:38] <Lerneaen_Hydra> oh, with the sliding bearing?
[17:44:50] <Lerneaen_Hydra> (depending on the design of the press)
[17:45:00] <jmkasunich> yeah, quill OD is polished and slides up and down in the head casting
[17:45:27] <Lerneaen_Hydra> yeah, then I know what you're talking about
[17:45:48] <Lerneaen_Hydra> so the backlash between the quill and the thrust bearings wasn't that bad?
[17:46:14] <jmkasunich> the lash was in the rack and pinion (rack teeth cut into quill, just like a drillpress)
[17:46:38] <Lerneaen_Hydra> yeah, ok
[19:11:44] <jepler> jmkasunich: it appears that memory returned by hal_malloc() is always initialized to 0 (like 'calloc') -- is this actually guaranteed?
[19:12:07] <jmkasunich> no
[19:12:38] <jmkasunich> the first 4 bytes of a shared memory block are inited to zero, only when it is first opened
[19:12:55] <jmkasunich> that way the program that opened it knows its the first one and can init any structs or whatever
[19:13:31] <jmkasunich> the stick a magic number in the first 4 bytes, so when other programs open it they know its already inited
[19:14:14] <jepler> so I should explicitly memset() the buffer returned by hal_malloc() to 0
[19:14:21] <jmkasunich> hmm, you are talking about hal_malloc
[19:14:49] <jmkasunich> which is _in_ a shmem block, but it doesn't actually create the block (its already created by hal_lib)
[19:15:48] <jmkasunich> what kind of a buffer are you talking about?
[19:16:10] <jmkasunich> hal_malloc memory should be used for pins, params, and possibly for a small amount of local data
[19:16:25] <jmkasunich> if your component needs largish buffers, it should get them some other way
[19:16:28] <jepler> when I create an instance of a component, I get some memory with hal_malloc() and create pins parameters and user data
[19:16:49] <jepler> in practice that all seems to start as "0"
[19:17:16] <jmkasunich> well I don't clear them
[19:17:37] <jepler> OK
[19:17:43] <jepler> I'll memset() it to zeros the
[19:17:45] <jepler> n
[19:17:48] <jmkasunich> and rtapi_shmem_new (which gets the pool from which halmalloc allocates) doesn't clear them
[19:18:03] <jmkasunich> maybe the OS did, but don't count on it
[19:24:47] <jepler> ok
[19:30:51] <pier> do you think that a "broken file error" when installing Emc2 on an Ubuntu Bb might depend on being behind a proxy?
[19:34:27] <jepler> I'm not familiar with "broken file error"
[19:47:52] <robin_z> meep?
[19:48:10] <jepler> hi robin_z
[19:48:16] <robin_z> dood
[19:48:22] <robin_z> are you well?
[19:48:41] <jepler> good, thanks
[19:48:50] <jepler> you?
[19:49:09] <robin_z> tired, but well, thanks,
[19:50:08] <robin_z> processed lots of steel today
[19:50:53] <robin_z> probably 4 tonnes
[19:51:39] <jepler> wow
[19:52:05] <robin_z> yep, laser has been busy :)
[19:53:24] <davidf> Hi
[19:54:01] <robin_z> hi
[19:54:36] <davidf> Is there any way to rotate an angular axis and move a linear axis simultaneously at _different_ feed rates?
[19:54:44] <davidf> Hi robin_z
[19:54:58] <robin_z> your question does nto really make sense
[19:55:10] <davidf> So what's new?
[19:55:13] <pier> jepler: ok thanks... I'll try some other way
[19:55:23] <davidf> Here's what I want to do:
[19:55:30] <cradek> they move so as to start, accelerate, decelerate and stop together
[19:55:45] <robin_z> right
[19:56:02] <davidf> I have my lathe chuck configured as Y, and the cross-slide as X.
[19:56:38] <cradek> you have a stepper in place of the spindle motor?
[19:56:44] <davidf> I want to rotate a small rod of steel stock in the chuck, and cut it off with a cutoff wheel mounted on the tool post.
[19:56:46] <robin_z> Im still trying to figure out how a angular axis and a linear axis could have feedrates that were "the same" or "different" ... ones angular, ones linear .. they are different things, so ...
[19:56:55] <davidf> Yes. a stepper.
[19:56:56] <robin_z> I geuss the answer is "yes"
[19:57:00] <robin_z> or "no"
[19:57:05] <robin_z> or "fruitbat" ;)
[19:57:17] <pier> night all
[19:57:40] <davidf> robin_z, the numbers must be the same with say a G01, even thoiugh the units are different.
[19:57:41] <cradek> so if the radius is 1, you would start at x1y0 and cut to x0y360
[19:58:01] <cradek> assuming you have configured the "y" scale so that it works as degrees
[19:58:10] <robin_z> exactly
[19:58:26] <robin_z> davidf, no "the numbers" woudl not be the same
[19:58:28] <cradek> ideally you should use a rotary (a b or c) for the chuck
[19:58:39] <davidf> well, I want the spindle turning fast, and the x slow though.
[19:58:56] <cradek> then you have to tell y to turn further
[19:59:01] <cradek> they start and stop together.
[19:59:05] <davidf> yeah, I know. But Y was already set up so I just used it. I can change it.
[19:59:13] <cradek> if you want 10 rotations of y, use x0y3600
[19:59:39] <davidf> I see that, but that's not the problem.
[19:59:52] <cradek> ok I don't understand the question either then, tell us more
[20:00:11] <robin_z> easy ..
[20:00:11] <robin_z> G0 X1 Y0
[20:00:11] <robin_z> G1 X0 Y36000
[20:00:14] <robin_z> 10 revs for 1mm of movement in X
[20:00:15] <davidf> The feed rate for X is 0.1 inch/minute, and the feed rate I want on Y is 60 rev/min.
[20:00:23] <robin_z> right
[20:00:33] <cradek> with this combined move you do specify a feed rate, it's the feed rate in X
[20:00:40] <cradek> well no, wait
[20:00:44] <jepler> inverse time feed mode
[20:00:45] <cradek> you've got a mess here
[20:00:53] <davidf> I don't want to stop and start the spindle for each x move.
[20:01:10] <robin_z> oh. well, you are stuffed then.
[20:01:17] <cradek> the feed for your move is specified along the XY "diagonal"
[20:01:28] <davidf> :) thats what I thpought
[20:01:32] <cradek> by using a linear axis as a rotary, you've messed it up :-)
[20:01:46] <cradek> use a rotary for your rotary, and the feed will be in X for your XA move
[20:01:47] <davidf> ok.
[20:02:07] <cradek> or, you can use inverse time mode like jepler suggests
[20:02:22] <davidf> So if I use A instead (np) then can it be done?
[20:02:26] <jepler> if you want your move to take 10 minutes, then program G94 F10 X0 Y360
[20:02:40] <davidf> ah.
[20:02:47] <jepler> oops, that's wrong
[20:02:50] <jepler> F[1/10]
[20:02:55] <cradek> yeah
[20:02:58] <davidf> uh huh.
[20:03:40] <jepler> but then you have to figure that it's a 10 minute move, so you need 60 * 10 * 360 degrees moved in 'Y'
[20:03:53] <davidf> But, in the above, the spindle will take 10 minutes to go 360 right?
[20:03:55] <cradek> but if you use XA you can specify F.1 X0 A360 (feed rate is .1 inch/min in X)
[20:04:18] <cradek> (in normal feed mode)
[20:04:20] <robin_z> 10 minutes for 360 right
[20:04:25] <robin_z> if thats what you want
[20:04:37] <davidf> cradek:
[20:04:38] <jepler> if you always want the chuck motor to spin at 60 rev/min, then don't program it from g-code. Use a 'freqgen' to create a constant pulse train for it.
[20:04:53] <cradek> another good idea
[20:05:08] <robin_z> I suspect he only wants that behaviour some of the time
[20:05:13] <jepler> you can even set it up to be the spindle (M3 S60)
[20:05:14] <davidf> hmm... ok maybe.
[20:05:19] <cradek> or put a spindle motor on it and use a parting tool like a normal person :-)
[20:05:28] <davidf> ha.
[20:05:47] <cradek> looks like you have many options
[20:05:56] <jepler> the challenge is to choose one option
[20:06:04] <robin_z> you always have options with EMC :)
[20:06:05] <davidf> It actually has a spndle motor attached, with a gear engaement lever.
[20:06:13] <cradek> cool
[20:06:40] <robin_z> attach pneumatic cylinder to leaver ... work it from EMC
[20:06:47] <cradek> that would be very cool
[20:06:48] <robin_z> leaver? lever!
[20:06:54] <robin_z> it would
[20:06:58] <davidf> The reasoun I want it this way is so I can cnc the whole part in several steps, including cutting a point on the end, milling two flat sides, then cutoff.
[20:07:09] <robin_z> right up to the moment when it banged it in at 3000rpm
[20:07:12] <cradek> then if you program a slow enough spindle speed, it could switch "gears" and drive the stepper
[20:07:41] <cradek> the mazak does this (change gears), using classicladder
[20:08:18] <davidf> The gear lever needs a hercukean effort to move into gear & back out.
[20:08:36] <davidf> herculean
[20:09:03] <cradek> brb
[20:09:14] <robin_z> nothing for a pneumatic cylinder
[20:09:46] <davidf> I want to keep it simple. Need parts yesterday.
[20:10:31] <robin_z> mmm ... tricky
[20:10:46] <acemi> hi
[20:10:50] <robin_z> What about a nice Fanuc?
[20:10:52] <davidf> Hey, why not use two emc instances on two computers one for spindle, & one for the x?
[20:10:54] <acemi> is there a problem in CVS
[20:11:20] <robin_z> davidf, that would indeed be a simple solution ... err. not.
[20:11:59] <robin_z> acemi, in one of the stable releases or in HEAD?
[20:12:05] <davidf> robin_z, can you spare a simple fanuc?
[20:12:11] <acemi> in HEAD
[20:12:18] <alex_joni> acemi: what kind of problem?
[20:12:39] <alex_joni> acemi: btw, did you get around to test the latest configure ?
[20:12:44] <acemi> I get "Cannot access /cvc/CVSROOT"
[20:12:47] <alex_joni> hi all, btw
[20:12:49] <robin_z> HEAD doesnt have problems as such, it just has "interesting bits" :0
[20:13:00] <robin_z> cvc?
[20:13:02] <acemi> now, I'll try the latest
[20:13:14] <acemi> typo
[20:13:23] <alex_joni> acemi: works here
[20:13:59] <acemi> ok now, I wrote cvc
[20:14:50] <robin_z> remind me to buy a bigger laser!
[20:16:07] <dave_1> robin... yep... just get a bigger hammer!
[20:16:40] <acemi> does the lastest configure need an environment varaible for Sarge?
[20:16:41] <Lerneaen_Hydra> big hammer and duct tape
[20:16:46] <alex_joni> watch out.. gonna flood
[20:17:03] <alex_joni> acemi: try without
[20:17:10] <acemi> ok
[20:18:12] <alex_joni> * alex_joni wonders why CIA is silent again
[20:18:17] <davidf> jepler, cradek, robin_z thanks. I'm gonna play with the inverse time thing & set up for A as spindle drive. It looks like that'l work find.
[20:20:02] <dave_1> anyone have ideas on how to grab axis position off of tkemc .... to a non-realtime program?
[20:20:58] <alex_joni> dave_1: what kind of program ?
[20:21:17] <Lerneaen_Hydra> bah, 'night folks
[20:21:28] <alex_joni> night LH
[20:22:04] <dave_1> edm control ... using a small C program to monitor gap voltage and sending commands thru usrmot to tkemc
[20:22:41] <alex_joni> hmmm.. emcsh has the values
[20:22:50] <alex_joni> but you need a tcl app to get them
[20:22:53] <alex_joni> is that ok ?
[20:23:32] <dave_1> might be but I don't do tcl.... could learn ... but only under immense pressure. ;-)
[20:23:51] <alex_joni> the other way would be to connect to emc directly using NML
[20:24:05] <alex_joni> that way you can send any commands for it to move (liek any other GUI)
[20:24:12] <alex_joni> and get the position and other status back
[20:24:37] <alex_joni> it's actually quite easy to do
[20:24:40] <dave_1> probably beyond my skills or I would have done it already.
[20:24:41] <cradek> halcmd can definitely show the positions too
[20:25:07] <cradek> beware units
[20:25:13] <dave_1> since edm's run for hours ... or days this needs to be completely automagic.
[20:25:56] <dave_1> there isn't a C interface to emcsh?
[20:26:09] <cradek> emcsh is a C program that provides a tcl interface to nml
[20:26:24] <alex_joni> dave_1: start by looking at this:
http://cvs.linuxcnc.org/cvs/emc2/src/emc/usr_intf/halui.cc?rev=1.1;content-type=text%2Fplain
[20:26:29] <cradek> nml is at its heart c++
[20:26:34] <alex_joni> that's the first version of halui
[20:26:54] <alex_joni> it doesn't have much more than the core of emcsh (basicly only the comms to EMC)
[20:27:09] <alex_joni> if you know C I trust you'll easily understand that file
[20:27:31] <dave_1> the halui file?
[20:27:45] <alex_joni> dave_1: yeah, it's actually a NML to HAL convertor
[20:27:56] <alex_joni> but the first revision (link I gave you) had very little HAL in it
[20:27:57] <dave_1> ah ... maybe there is hope.
[20:28:21] <alex_joni> just look at it (start with main() at the very bottom)
[20:28:22] <cradek> why not feed the gap voltage into hal, and use it to control the adaptive feed? that's how mac is doing it
[20:28:41] <alex_joni> cradek: if I understood it correctly, this is sinker not wire
[20:28:45] <cradek> I don't see why you would want to calculate positions externally, emc is perfectly good at following a line already
[20:28:52] <alex_joni> and they use a different approach on speeds
[20:29:09] <cradek> oh
[20:29:19] <alex_joni> and positions and clearing short circuits
[20:29:27] <alex_joni> so I trust they know way more than we do :D
[20:29:35] <cradek> I'm sure that's true
[20:30:07] <dave_1> I'm sinker..... think of this as a window comparator... above the window advance (into burn) ... in window ... don't move ... below window move out of burn.
[20:30:38] <cradek> ok
[20:30:52] <dave_1> that is the simple part ... I can do that with C or with C -> usrmot -> tkemc
[20:31:06] <jepler> this is a Python program that prints the current position about once per second (set with the first commandline argument):
http://emergent.unpy.net/files/sandbox/dro.py
[20:31:08] <cradek> seems you could still do that in hal (feed freqgen + or - for "into" or "out")
[20:31:26] <jepler> you could use popen() and fscanf() to get this information into your C program
[20:32:32] <dave_1> once you get to the bottom of the burn you stop and spark out... then do a small orbit.. 0.0005 in a X or other pattern ... actually in increments of 0.001 or 0.0005 until you get to dimension and are clean... adequate surface finish
[20:32:59] <dave_1> In addition one needs to back out once in a while ... to flush.
[20:33:22] <cradek> gotcha, sounds complex
[20:33:30] <alex_joni> ok, the last part I recognize
[20:33:44] <dave_1> It sound simple ... the devil is in the details
[20:34:19] <robin_z> backing out is the hard bit
[20:34:28] <alex_joni> robin_z: not for sinker
[20:34:34] <alex_joni> for wire
[20:34:34] <dave_1> Pete is getting close to being able to test prototype....
[20:35:00] <danex> hello all
[20:35:06] <alex_joni> hi danex
[20:35:07] <robin_z> alex_joni, well, yeah, but apparently sometimes sinker does undercuts
[20:35:10] <dave_1> I have a stepper driven z to test with
[20:35:42] <alex_joni> dave_1: simplest thing.. start only HAL and stepgens
[20:35:59] <alex_joni> then feed positions to stepgen using halcmd sets zpos
[20:36:02] <cradek> that's how I'd start too I think
[20:36:08] <alex_joni> where zpos is a signal for position
[20:36:32] <dave_1> yes... one of the important things once you get into an undercut is to return to center before pulling out.
[20:36:44] <cradek> the whole emc motion controller is not very well suited to your task
[20:36:53] <alex_joni> nor usefull
[20:36:55] <dave_1> but hal might be...
[20:37:14] <alex_joni> at those speeds...
[20:37:24] <dave_1> yes you pretty well have to break emc to make it do edm.
[20:37:28] <alex_joni> you can go away with userlevel motion control only
[20:38:02] <dave_1> speeds are in the range of 1 ipm into burn and maybe 3 ipm retracting
[20:38:31] <cradek> yes I think I'd use hal as a hardware interface only, and do all the motion control in userland
[20:38:32] <alex_joni> 3ipm = 0.05 ips
[20:38:50] <dave_1> not too challanging
[20:39:01] <alex_joni> what precision do you have usually ?
[20:39:27] <cradek> you give up the use of gcode but seems that's no big loss in your case
[20:39:30] <dave_1> remember the gap may be in the 0.0005 to 0.001 range and you really should be in control and not short
[20:39:53] <dave_1> edm goes for way better than a thou
[20:40:00] <alex_joni> I think you can get 100 updates / second in userland
[20:40:19] <alex_joni> maybe even more
[20:40:25] <acemi> alex_joni, there is no problem with Xaw. configure and make works fine without an environment variable
[20:40:33] <alex_joni> acemi: YAY
[20:40:54] <alex_joni> acemi: any other problems?
[20:41:08] <acemi> no
[20:41:13] <dave_1> prototype will run on a 800 or 1200 MHz P3
[20:41:14] <alex_joni> even better
[20:41:17] <acemi> everythink is OK
[20:41:29] <alex_joni> another happy customer :)
[20:41:57] <dave_1> so being a dummy ... I need a roadmap... but I can go look at the halui stuff
[20:42:01] <acemi> :)
[20:42:23] <alex_joni> dave_1: the NML stuff might not be the best thing, now that I think of it
[20:42:33] <alex_joni> I'd definately start with HAL only at first
[20:42:46] <jepler> ooh, nice -- if you give a step function to stepgen, it gives a nice S-shaped ramp to the final position
[20:42:47] <alex_joni> then use halcmd sets Xpos, halcmd sets Ypos, etc
[20:42:50] <jepler> I suppose this is no surprise
[20:43:04] <alex_joni> jepler: no, it does the accel & vel limits inside
[20:43:19] <alex_joni> however, it's only S-shaped on position
[20:43:33] <alex_joni> it would be "ideal" if it were S-shaped on velocity too
[20:46:05] <danex> alex_joni, The test run today failed, was unable to get the m-code to activate with the switch
[20:46:28] <danex> and some e-stop issues came up
[20:46:38] <alex_joni> oh.. what kind?
[20:47:12] <dave_1> ok ... so can I drive halcmd from a C program... most of my problem is not motion but position and the timing between flushes.
[20:47:53] <alex_joni> dave_1: halcmd show pin stepgen.0.position or similar gives you that position
[20:48:23] <dave_1> can I capture that someway?
[20:48:45] <danex> User m-code remain active, when the e-stop is released the m-code continues even though the GUI is still in e-stop
[20:48:52] <alex_joni> popen() and scanf()
[20:49:10] <alex_joni> danex: I think that's a feature
[20:49:39] <alex_joni> I never read that custom M-codes need to get deactivated on estop
[20:49:46] <alex_joni> maybe I missed it in the RS274NGC manual
[20:49:58] <jepler> I don't think custom M-codes are covered in the manual
[20:50:23] <jepler> in any case, that's the current benavior of emc: there's no attempt to "kill" the program stared by a custom m-code just because estop has been entered
[20:50:49] <danex> In any case I am adding additional hardware e-stop
[20:51:40] <alex_joni> danex: that's only normal to do :)
[20:51:50] <alex_joni> I would expect anyone with serious iron to do that
[20:52:16] <alex_joni> you guys are from the US.. right?
[20:52:28] <alex_joni> something nice for you to sign up :
http://www.tgdaily.com/2006/08/14/toms_hardware_10000_dollar_pc_sweepstakes/
[20:52:28] <dave_1> body parts are hard to replace
[20:52:28] <danex> I do have hardware e-stop in place , I just have to make it latch
[20:52:46] <alex_joni> hardware e-stop _always_ latches
[20:53:02] <alex_joni> you push it it dies, and stays off from then on
[20:53:28] <alex_joni> I would love that screen :-&
[20:53:56] <alex_joni> * alex_joni drools: "Apple's 30" Cinema display, which has a dazzling 2560x1600 pixel resolution"
[20:54:25] <jepler> alex_joni: how can that machine possibly cost $10,000? The 30" display is only $2000, that leaves you $8000 to spend on .. a box with a ugly finish and a logo you don't want?
[20:55:02] <danex> For free, I would take it
[20:55:17] <dave_1> OK ... back to the drawing board... talk to you later.
[20:55:30] <jmkasunich> rather have take the cash - spend 1/3 of it on a really nice PC and keep the rest
[20:56:12] <danex> Cash is good
[20:57:07] <cradek> I'd definitely take the display, but don't care about the rest
[20:57:55] <cradek> especially the windows xp pro
[20:58:09] <jepler> I think I'd feel .. too small .. next to a 30" display
[20:58:20] <cradek> haha
[20:58:36] <cradek> I bet it would be very nice
[20:58:56] <cradek> ha it's water-cooled
[20:59:16] <alex_joni> cradek: right, and with a dual geforce .. not sure why..
[20:59:25] <jepler> monarch computer'll sell me a 4-way (2 x dual-core opteron 64) system with 8GB memory and 1.6TB disk for only $5500...
[20:59:30] <cradek> probably takes two DVIs to run the screen
[20:59:43] <alex_joni> cradek: there are 2 dvi's on one geforce
[20:59:49] <cradek> I think DVI bandwidth maxes out around 1600x1200
[20:59:52] <alex_joni> they put 2 in there for SLI, faster computing
[20:59:53] <cradek> ah
[20:59:56] <cradek> dunno then
[20:59:57] <alex_joni> not likely :)
[21:00:08] <alex_joni> check a google on Nvidia Quadro Fx4500 X2
[21:00:21] <alex_joni> those go up to 3840 x 2600 or something
[21:00:28] <alex_joni> on 4 screens at once !
[21:00:39] <alex_joni> I mean on each screen
[21:01:00] <cradek> maybe they can do that by using a very slow update rate (20 Hz)?
[21:01:05] <alex_joni> 24Hz
[21:01:20] <cradek> ok that's the trick
[21:01:23] <alex_joni> but it's for cinematography applications, so I think that's OK
[21:01:26] <cradek> I'm surprised gamers will tolerate that
[21:01:32] <alex_joni> not for gamers
[21:01:39] <cradek> ah
[21:01:42] <alex_joni> gamers can't afford the 4000$ graphics card
[21:01:52] <alex_joni> not even the serious ones :D
[21:02:18] <jepler> according to wikipedia, DVI clock speed can be:
[21:02:19] <jepler> Maximum clock frequency in single link mode: Capped at 165 MHz (3.7 Gbit/s)
[21:02:19] <jepler> Maximum clock frequency in dual link mode: Limited only by cable quality (more than 7.4 Gbit/s)
[21:02:19] <alex_joni> even if it has some specs they would drool all over
[21:03:27] <alex_joni> cradek: that board still can do 2800x1900-ish on VGA analog links
[21:03:38] <alex_joni> at 70Hz or so
[21:07:47] <danex> alex_joni, just to clarify my e-stop does latch at push and requires physical key (seperate from the e-stop button)to release The additional hardware will close the emc program
[21:12:21] <alex_joni> danex: ok.. sounds good enough :)
[21:14:30] <danex> On the M-code to be activated by a switch, the program you talked about is in the machine, but I have been unable to make that one work
[21:18:13] <alex_joni> maybe jepler or cradek can help..
[21:18:37] <alex_joni> jepler wrote mdi I think, and cradek is really great at scripts :)
[21:19:30] <alex_joni> * alex_joni wonders if that would be an interesting addition to halui ?
[21:19:51] <alex_joni> have 1-2 pins which upon changing would trigger an M-code with a predefined value
[21:19:58] <alex_joni> and maybe 1-2 parameters aswell
[21:20:20] <acemi> libncurses5-dev is installed but I get the following at configure:
[21:20:23] <acemi> checking ncurses.h usability... yes
[21:20:23] <acemi> checking ncurses.h presence... yes
[21:20:23] <acemi> checking for ncurses.h... yes
[21:20:23] <acemi> checking for initscr in -lncurses... no
[21:20:23] <acemi> configure: WARNING: ncurses lib missing
[21:21:08] <alex_joni> acemi: might be the same thing :/
[21:21:18] <alex_joni> where is ncurses located ?
[21:21:25] <davidf> cradek: I switched to A axis. G93 is inverse time mode, not G94. That's regular units/time mode.
[21:21:50] <acemi> libncurses.a is in /usr/lib
[21:21:56] <davidf> But I'm not getting the results I expected based on what You & jepler said.
[21:22:18] <alex_joni> davidf: I think cradek is on his way home.. maybe try a bit later
[21:22:25] <alex_joni> acemi: odd..
[21:22:26] <danex> alex_joni, that would add some flexabiliy ?
[21:22:46] <alex_joni> danex: maybe, but I'm not sure how many peopl would actually use that
[21:22:51] <davidf> 'k thanks.
[21:25:15] <davidf> cradek: No, it does work. Great. thanks. tnx jepler
[21:25:36] <danex> the ability to change and make use of parts of the program makes EMC better
[21:27:46] <alex_joni> * alex_joni heads to bed
[21:27:49] <alex_joni> good night all
[21:28:06] <danex> good night alex_joni
[21:28:55] <danex> cradek, could you give me an explanation of the custom m-code arguments?
[22:34:44] <jepler> danex:
http://unpy.net/emc2-docs/gcode/main/index.html#SECTION00460000000000000000
[22:35:45] <jepler> so if you program M101 Q1 P2, it will invoke the command: M101 2 1
[22:47:26] <robin_z> the problem I have with the M codes is that as I understand it, they cannot control machine motion
[22:51:01] <danex> what I am trying to achieve is an m-code activates a pump and a switch deactivates it
[22:51:30] <robin_z> should be easy
[22:52:26] <jepler> danex: OK, do you have a HAL pin that controls the pin?
[22:52:45] <robin_z> infact, strangely enough, turning on coolant pumps is one thing EMC does well :)
[22:53:14] <jepler> er, that controls the *pump*
[22:53:28] <robin_z> M7, M8 and M9 ...
[22:54:45] <danex> I have an output pin wired but the HAL pin is where I get lost in this venture
[22:55:09] <danex> I have looked at the HAL show at pins
[22:55:30] <jepler> ok .. what pin of your I/O board or parport is the pump wired to?
[22:55:56] <danex> motenc.0.out-10
[22:57:10] <jepler> and the pump is on when motenc.0.out-10 is high?
[22:57:19] <danex> yes
[22:58:28] <jepler> you want to turn motenc.0.out-10 off again when this external signal arrives
[22:58:41] <jepler> do you want to turn it off by m-code too?
[22:59:03] <danex> switch only is required
[22:59:56] <jmkasunich> ladder rung could do that
[23:00:24] <danex> the input for the switch is motenc.1.in-01
[23:00:30] <jepler> yeah this sounds like an R-S latch (is that the term I mean?)
[23:00:59] <jepler> does classicladder have R-S latch as a primitive?
[23:02:02] <jepler> the R input is just motenc.0.in-01
[23:02:03] <jmkasunich> no, but that is a "classic" thing to do with a ladder
[23:02:27] <jepler> the S input will be connected to a HAL signal that will be manipulated by 'halcmd sets' from the M1xx script
[23:03:10] <jepler> it might say: halcmd sets turn-pump-on 1; sleep .5; halcmd sets turn-pump-on 0'
[23:03:15] <jmkasunich> think of any industrial motor starter - two buttons, one NO "start" that pulls in the main relay, an aux NO of the main shunts the start button to latch it on, and an NC "stop" in series with the whole thing to drop it out
[23:03:42] <jmkasunich> arg, typos
[23:04:11] <jmkasunich> s/an aux NO of the main shunts/an auxiliary NO contact on the main relay shunts/
[23:08:59] <danex> jepler, the "sleep.5" would be a time base?
[23:10:00] <jmkasunich> its a delay
[23:10:12] <jmkasunich> turn on the signal, wait a half second, turn it back off again
[23:10:24] <jmkasunich> just like a momentary press of the "start" button of a motor starter
[23:13:01] <danex> As a sub note, know anyone who wants a 3 axis snk mill for retrofit, One of my customers just dragged one out onto the lot
[23:14:27] <danex> They tried to give it away, fair iron old control
[23:33:09] <A-L-P-H-A> anyone able to explain to me the difference between ext2/ext3/hfs/hfs+/jfs etc...?
[23:37:28] <danex> jepler,jmkasunich this gives me something to try , thank you,,
[23:38:16] <danex> time for supper, goodbye all
[23:38:20] <danex> * danex is away: Away at the moment
[23:46:02] <A-L-P-H-A> found one.
[23:46:09] <A-L-P-H-A> I guess I'm going for ext2 or 3...
[23:48:13] <bill20r3> I usually use ext3
[23:48:58] <A-L-P-H-A> is the journaling of any use?
[23:49:23] <bill20r3> makes the system come up faster after a hard-shutdown
[23:49:35] <bill20r3> and less chance of data loss.