Back
[00:39:00] <maddash> I'm trying to install the emc2 package from synaptic, but it requires me to also install the magma linux image. anyone know why? I've already got the latest linux kernel...
[00:40:04] <maddash> also, is emc2-dev incompatible w/gcc-4? everytime I try installing it, it begs me for gcc-3.4
[00:42:09] <jepler> maddash: "magma" is the kernel with realtime support. you must use a realtime kernel to control hardware with emc2
[00:42:28] <jepler> that kernel is compiled with gcc3.4, and the same version of gcc must be used to compile the kernel and the modules.
[00:43:04] <jepler> there is a lot of contradictory information about which compilers are "safe" to use for the realtime kernel patches, so cradek and alex_joni were conservative and chose gcc3.4 rather than 4.0.
[00:54:26] <maddash> now that I've got emc2-dev installed, can someone point me to the module that acts as g-code interpreter?
[00:56:44] <maddash> jepler: thanks, btw
[01:09:08] <jepler> the g-code interpreter turns g-code into a series of "canon calls", which in emc go down a number of layers before they actually create motor position commands every millisecond.
[01:09:20] <jepler> the g-code interpreter is in src/emc/rs274ngc/
[01:51:06] <maddash> when I run emc2 w/the following config file (
http://pastebin.ca/292967), I get an error telling me that "/usr/bin/keystick" is invalid...anyone know why?
[01:52:37] <SWPadnos> I'm not sure keystick is included in the installed emc - you probably have to compile HEAD or v2_1_branch to get it (I could be wrong about that though)
[01:59:01] <maddash> tried to compile...got an err msg: make: *** No rule to make target `rtapi/@RTPREFIX@_ulapi.c', needed by `depends/rtapi/@RTPREFIX@_ulapi.d'. Stop.
[01:59:01] <maddash> "
[02:01:34] <maddash> scratch that - I fresh extracted the "emc2" folder from the source tarball, and the new err msg is:
[02:01:42] <maddash> make: *** No rule to make target `rtapi/_ulapi.c', needed by `depends/rtapi/_ulapi.d'. Stop.
[02:02:07] <SWPadnos> are you building to install, or to run in place?
[02:02:22] <maddash> what's the difference?
[02:02:47] <jepler> that message (/_ulapi.d or @RTPREFIX@_ulapi.d) indicates something went wrong in the configure script
[02:02:53] <SWPadnos> the installed files go in /usr, /lib ..., adn are available from any command prompt (and also get menu entries)
[02:02:53] <maddash> I did, however do a "./configure --enable-run-in-place" before the "make", as prescribed by
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
[02:03:21] <SWPadnos> when you run in place, you can have several versions on the same machine, and they won't interfere with each other (unless something goes wrong)
[02:04:47] <maddash> jepler: the configure did have an error: "tcl lib not found." However, I fail to see why that should be a problem, as I don't intend on using any of the gui's...
[02:05:08] <maddash> swpadnos: let's say I'm building to run in place...then what?
[02:05:10] <jepler> configure must complete successfully, or you can't "make"
[02:05:22] <SWPadnos> I was getting to the configure issue
[02:05:41] <SWPadnos> (eventually)
[02:07:25] <maddash> is there anyway I can bypass the tcl check?
[02:08:24] <SWPadnos> I can't answer that for you - configure scripts are outside my realm
[02:08:32] <maddash> jepler?
[02:08:36] <jepler> only by changing the configure.in script
[02:10:11] <SWPadnos> tcl is only needed so the runscript can be set up (and emc_environment), right?
[02:10:49] <jepler> SWPadnos: well the Makefiles are set up to assume you can always build emcsh, which requires tcl/tk development environment
[02:10:58] <SWPadnos> oh, right
[02:11:05] <SWPadnos> forgot about emcsh
[02:11:20] <jepler> for someone who is not familiar with the build system and configure script, it will probably take less time to install the devel packages even if you'll never use those parts of the system
[02:11:32] <jepler> but it's possible to get rid of the need, in the sense that everything is possible
[02:12:01] <SWPadnos> ie, "enter at your own risk" ...
[02:12:53] <jepler> bbl
[02:12:54] <maddash> huh? I've tried commenting out every reference to EMC2_TCL_DIR
[02:13:02] <maddash> that doesn't seem to work
[02:15:38] <maddash> tcl isn't even mentioned in any of the source files
[02:16:10] <SWPadnos> emcsh is somewhere in there, and it's a custom tcl wish shell that has emc-specific commands added
[02:18:50] <maddash> so how the heck do I bypass the tcl check in configure?
[02:19:37] <SWPadnos> you need to remove at minimum the lines that actually look for tcl. after that, I'm not sure what will happen
[02:25:25] <jmkasunich> maddash: why not just get tcl, even if you aren't gonna use it?
[02:25:48] <jmkasunich> ie: compile _all_ of EMC2, then just use the parts that are non-gui
[02:27:47] <maddash> it's not a matter of "just [using] parts that are non-gui" - it's a matter of cutting out as much as I can, and tcl is entirely unnecessary
[02:28:52] <maddash> besides, if I wanted to compile all of emc2, wouldn't I simply install the emc package via synaptic?
[02:32:26] <jmkasunich> if you are cutting for the sake of cutting, then have fun
[02:32:58] <jmkasunich> if you are trying to get something to work within memory limitations, then compiling everything is an easier way to get there
[02:33:15] <jmkasunich> (if you have disk space issues as well, then of course more cutting is needed)
[02:36:31] <maddash> I'm cutting, because I'm trying to build an embedded sys to contain the emc images
[02:36:41] <jmkasunich> ok
[02:36:56] <maddash> anyway, I finished compiling, but the "emc" binary is nowhere to be found in emc/bin
[02:37:22] <jmkasunich> a more sophisticated configure script _might_ detect what you have installed, and only build what is possible to build
[02:37:55] <jmkasunich> of course, then everybody else will wonder why they're not getting everything, they'd prefer that configure bitch about missing dependencies so they can install everything
[02:38:33] <maddash> gotcha...how do I start emc?
[02:38:46] <jmkasunich> an even more sophisticated configure script would break emc into chunks, and let you specify --with-<some-chunk> and --with-no-<otherchunk>
[02:39:15] <jmkasunich> with X, you cd to the top level dir and do "scripts/emc"
[02:39:23] <jmkasunich> but that invokes a gui/tck config picker
[02:39:49] <jmkasunich> to skip that, do "scripts/emc config-dir/inifile"
[02:39:56] <jmkasunich> (for the config you want to run)
[02:53:24] <maddash> ok, so I got "make" and "make install" both done
[02:53:57] <maddash> when I launch the emc script, it gives me the config chooser, and after I choose, I get the following msgs:
[02:53:58] <maddash> Can't write to /dev/rtai_shm - aborting
[02:53:58] <maddash> Realtime system did not load
[02:54:06] <maddash> any ideas, guys?
[02:54:41] <jmkasunich> you do have the magma kernel installed?
[02:54:44] <maddash> yep
[02:54:45] <jmkasunich> and are running it?
[02:54:48] <maddash> yep yep
[02:54:54] <jmkasunich> hmm
[02:55:08] <jmkasunich> /dev/rtai_shm is the rtai shared memory device
[02:55:16] <jmkasunich> on a stock install it just works
[02:55:20] <maddash> I did get something like "NOTE: rtapi kernel module must be loaded"
[02:55:33] <jmkasunich> ok, try this:
[02:55:35] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting
[02:55:40] <jmkasunich> scripts/realtime start
[02:56:13] <jmkasunich> yeah, read the page SWPadnos said
[02:56:28] <SWPadnos> section 1.1, I think (you may be missing the device nodes)
[02:56:37] <maddash> I assume I have to ssudo it?
[02:56:55] <SWPadnos> you should have had to sudo make install, I think
[02:56:57] <maddash> b/c I got "can't write to /dev/rtai_shm - aborting"
[02:57:04] <SWPadnos> you don't need sudo to run emc
[02:57:18] <maddash> no, I mean sudo realtime tart
[02:57:19] <maddash> start*
[02:57:33] <jmkasunich> no, realtime has the neccessary parts setuid
[02:57:49] <maddash> hold on, let me restart
[02:57:59] <SWPadnos> this is not run-in-place (you did make install), so you should
[02:58:01] <SWPadnos> argh
[02:58:15] <SWPadnos> he's quick though
[02:58:23] <jmkasunich> arg, not rip?
[02:58:29] <SWPadnos> I don't think so
[02:58:48] <SWPadnos> <maddash>ok, so I got "make" and "make install" both done
[02:59:16] <jepler> jmkasunich: there was a trivial bug in streamer, but after fixing it I was able to use it for a test of and/or/not/mux
[02:59:35] <jmkasunich> cool
[02:59:37] <jepler> jmkasunich: thanks for writing the sampler/streamer stuff, it makes writing these regression-type tests easy
[02:59:52] <jmkasunich> you're welcome
[02:59:55] <jmkasunich> thanks for writing the test
[02:59:58] <jmkasunich> s
[03:00:23] <jepler> we'll see how many I get around to
[03:00:39] <jepler> it would be nice to have at least one test for each component, but I'm not there yet
[03:08:12] <maddash> alright, I've "./configure" 'ed, I've "make"-ed, I've "sudo make install"-ed, and I've rebooted, with the magma kernel running
[03:08:37] <maddash> /etc/init.d/realtime status reports all modules loaded, including "rtai_shm"
[03:08:37] <jmkasunich> ok, you are running installed, not run-in-place
[03:09:00] <maddash> yep, that's right, because I did "./configure", not "./configure -enable run in place"
[03:09:13] <maddash> but when I start emc, I still get the same err msg...
[03:09:43] <maddash> /dev/rtai_shm doesn't exist...
[03:10:09] <jmkasunich> ok, read section 1 of
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting
[03:10:39] <jmkasunich> especially section 1.1
[03:11:52] <maddash> does that say to issue "sudo mknod /dev/RTAI_SHM c 10, 254;"??
[03:12:00] <maddash> what's the "c 10,254"?
[03:12:12] <jmkasunich> device type "c" = char
[03:12:17] <jmkasunich> and device node numbers
[03:12:33] <jmkasunich> man mknod for details, or you can just consider them magic numbers
[03:14:16] <cradek> hi all
[03:14:44] <jmkasunich> hello
[03:16:05] <jepler> hi chris
[03:16:21] <maddash> i assume that the "c 10, 254;" holds for the others, right? like "sudo mknod /dev/rtf0 c 10, 254;"
[03:17:18] <SWPadnos> no - those should be 150, 0 for rtf0, 150, 1 for rtf1 ...
[03:17:29] <SWPadnos> look at the numbers in the ls output on the wiki page
[03:17:44] <SWPadnos> (you don't have to create rtc ;) )
[03:17:46] <maddash> god. how obtuse of me.
[03:17:51] <jepler> the "," shold not be in the mknod command, though it's shown in dir -- is the wiki wrong?
[03:17:59] <SWPadnos> could well be
[03:18:05] <jepler> though it looks like it's accepted by mknod
[03:18:07] <jepler> so it's not a bfd
[03:18:30] <SWPadnos> it does show the comma for rtai_shm
[03:18:42] <SWPadnos> and it says RTAI_SHM instead of rtai_shm
[03:20:24] <maddash> ... I did both - "rtai_shm"' and it's uppercase brother
[03:21:52] <maddash> ok, so I've jumped thru all the sudo mknod hoops... ./realtime restart still returns "cannot write to /dev/rtai_shm"
[03:23:20] <maddash> this (
http://pastebin.ca/293023) might help...
[03:23:34] <maddash> at the leftmost column,
[03:23:52] <maddash> the read/write permissions are slightly different than what is shown in the wiki - could this be the problem?
[03:23:56] <jepler> rtai_shm must be writable by all users
[03:24:06] <maddash> chmod 666?
[03:24:09] <jepler> yes
[03:25:27] <jepler> with the "official packages", this is done whenever the rtai shared memory kernel module is loaded, by the file /etc/udev/rules.d/emc2.rules:
http://cvs.linuxcnc.org/cvs/emc2/debian/extras-Ubuntu-6.06/etc/udev/rules.d/emc2.rules?rev=1.1.2.1;content-type=text%2Fplain
[03:28:58] <maddash> "Can't find HAL config file: /etc/emc2/sample-configs/stepper//core_stepper.hal" <---- I know that the problem is the "//" just before "core_stepper" (should be "//")...I can't figure out which file holds the token, though...
[03:29:10] <maddash> should be "/" **
[03:29:32] <cradek> extra // don't matter
[03:30:39] <cradek> and that file does exist on my install, it must not on yours
[03:35:05] <maddash> well, it looks like I've gone as far as I can - "emc" refuses to run without emcsh
[03:36:13] <cradek> emcsh is only used for tkemc and mini.
[03:37:05] <cradek> so do you really not have enough disk space for tcl? how big is your disk?
[03:39:23] <maddash> the machine in which emc will reside permanently is rather old...has about 2 GB on the HD
[03:40:08] <maddash> the thing is that the processor is as slow as it is old, so I really would prefer to cut down the performance requirements by taking out tcl
[03:40:35] <maddash> so if I don't use either tkemc and mini, what do I use? usrmot?
[03:40:43] <cradek> xemc
[03:40:45] <jepler> xemc and keystick both work for me on head
[03:40:57] <maddash> how do I get keystick?
[03:41:02] <jepler> keystick opens its own xterm so you'll have to modify that if you're not using X at all
[03:41:09] <maddash> /usr/bin/keystick doesn't exist...
[03:41:16] <jepler> keystick is in the CVS tree, and will be in emc2.1.
[03:41:28] <jepler> I think someone mentioned that about 2 hours up that way ^^^
[03:41:38] <jepler> 19:53:05 <SWPadnos> I'm not sure keystick is included in the installed emc - you probably have to compile HEAD or v2_1_branch to get it (I could be wrong about that though)
[03:41:50] <maddash> gee, I must not have seen it
[03:41:54] <maddash> thanks, though
[03:43:07] <maddash> what does he mean by, "compile HEAD"? sounds vulgar...
[03:43:15] <cradek> maddash: where do you live?
[03:44:29] <maddash> cradek: why? am I getting billed for your help? ;)
[03:44:45] <SWPadnos> $275/hour, didn't you know? ;)
[03:44:58] <jepler> We use CVS to store the source code -- it keeps track of versions and allows everyone to download past and present revisions of the software. The revision called "HEAD" is always the very newest revision of the software.
[03:45:10] <cradek> if you were near any of us I bet we'd give you a 4G hard disk and/or a SIMM
[03:45:31] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS
[03:45:31] <cradek> ... you're spending a lot of time to save yourself maybe $20 worth of hardware
[03:46:05] <cradek> and you'll be happiest learning to configure and use EMC2 if you have all the parts of it.
[03:46:27] <SWPadnos> if he plans to make 1000 of them, it's worth the time ...
[03:46:38] <cradek> oh? I didn't see that
[03:46:45] <SWPadnos> he didn't say that
[03:46:48] <cradek> forgive me for coming into the middle of the conversation
[03:46:54] <cradek> oh
[03:47:00] <maddash> haha cradek, you're almost right...
[03:47:03] <cradek> well then my offer still stands
[03:47:11] <SWPadnos> but it is an embedded system, and the effort to get it to work is useful
[03:47:33] <jmkasunich> even if you're making a thousand - why not compile it on a complete machine, then move the pieces you need to later
[03:47:34] <cradek> it should be easy to install all the parts of EMC2 even in 2G.
[03:47:49] <cradek> **easy**
[03:47:59] <cradek> removing unneeded packages from the OS is the place to start
[03:48:11] <cradek> for instance firefox is probably bigger than all of EMC2
[03:48:35] <maddash> jmkasunich: what do you mean "moe the pieces you need later"? sounds like I can chop up the emc2 files and take whatever I need...
[03:48:52] <cradek> as is openoffice, gimp, evolution, etc.
[03:49:11] <maddash> well, then again, firefox is kinda bloaty
[03:49:24] <jepler> firefox Installed-Size: 22868
[03:49:45] <cradek> emc2 Installed-Size: 4604
[03:50:36] <jmkasunich> maddash: I mean, build and test on a capable box, then after its working, pare it down for the smaller box(es)
[03:50:51] <maddash> well, the other thing is, I really don't have any need for the gui...all I'm doing is really inputting a g code file and hoping that the correct signal pulses come out of LPT1
[03:50:54] <jmkasunich> but cradek's point is even more important
[03:51:24] <cradek> maddash: you will NOT get it configured and running without a GUI if you aren't already familiar with it. it's impossible.
[03:51:39] <jepler> s/impossible/a daunting task/
[03:51:43] <maddash> cradek: so I'm getting familiar with it...
[03:52:14] <jmkasunich> some things, like bringing the machine out of estop, homing axes, etc, are currently only done thru the GUI
[03:52:16] <SWPadnos> defining what "correct signal pulses" means is the part that's hard for beginners
[03:52:26] <jmkasunich> you can't just feed it a g-code file and have all that happen
[04:08:43] <maddash> jmkasunich: what did you mean by "pare it down"? how does one go about this?
[04:10:30] <jmkasunich> carefully ;-)
[04:10:57] <cradek> configure it and get it running, and then delete the files that aren't used
[04:11:24] <cradek> but the most you will possibly save is 2 megabytes, because that's the installed size of the package.
[04:13:44] <maddash> cradek: so you're telling me that I can start off with a full install of emc2, then waltz my bash into /usr/bin and start deleting stuff? w/o scrapping emc2?
[04:13:47] <cradek> sorry, 4.6 MB
[04:14:18] <cradek> depends what you delete, obviously
[04:14:39] <maddash> obviously. but I can do rm emcsh and it's likes?
[04:15:27] <cradek> if you're not using emcsh, probably, but I still think you're on the wrong track. I can't fathom why you would want to trim a 4 MB package that you aren't even familiar with using yet.
[04:16:02] <cradek> even if you have only a 2GB disk, emc2 will take up 0.2% of it
[04:16:04] <jmkasunich> when there is probably 400M of stuff in an average distro that you also won't be using and has nothing whatsoever to do with emc
[04:17:25] <maddash> I can't help but think this - are you guys mad at me for trying to tamper with your code?
[04:17:32] <jmkasunich> no
[04:18:13] <cradek> I can only speak for me, but if anything we're mad because we perceive you're wasting your time and ours
[04:18:17] <jmkasunich> we're a little annoyed that you are asking us to help you do something that is quite difficult even if you already know emc, when you obviously don't have much experience with it yet
[04:18:32] <cradek> hey that was more diplomatic than mine...
[04:18:34] <jmkasunich> and when there are better ways to reach your stated goals
[04:19:17] <cradek> personally I'd rather you succeed using EMC2, but you ignore all my ideas about how to do that.
[04:25:11] <maddash> I think there's an error on line 975 of usrmot.c "if (0 != usrmotLoadComp(axis, compfile, type)) {"
[04:25:33] <SWPadnos> what do you suppose is an error there?
[04:25:35] <maddash> usrmotloadcomp takes only 2 args, according to usrmotintf.h
[04:25:45] <SWPadnos> hmmm
[04:26:47] <cradek> ./src/emc/motion/usrmotintf.h: extern int usrmotLoadComp(int axis, const char *file, int type);
[04:27:37] <maddash> nope
[04:27:45] <jmkasunich> ?
[04:27:48] <maddash> looks like I've got an old version
[04:28:13] <maddash> both of my usrmotinf 's define usrmotloadcomp w/ 2 args
[04:28:29] <SWPadnos> both?
[04:29:00] <maddash> yeah - I'm using the header files from the source tarball
[04:29:18] <SWPadnos> with a CVS HEAD checkout?
[04:29:21] <jmkasunich> alex added the third param on 7-oct-06
[04:29:38] <jmkasunich> (version 1.17 of that file)
[04:29:43] <jmkasunich> 2.0.x has the old version
[04:29:52] <maddash> I'm referring to the tarball downloaded from the linuxcnc.org front page
[04:29:55] <jmkasunich> pre-2.1, and head, both have three args
[04:30:17] <jmkasunich> that tarball must be 2.0.x then
[04:30:21] <cradek> ./src/emc/motion/usrmotintf.h: extern int usrmotLoadComp(int axis, const char *file);
[04:30:24] <cradek> ./src/emc/usr_intf/usrmot.c:if (0 != usrmotLoadComp(axis, compfile)) {
[04:30:27] <cradek> (2.0 branch)
[04:30:30] <maddash> http://prdownloads.sourceforge.net/emc/emc2.0.5.tar.gz?download
[04:30:33] <SWPadnos> I guess I'm not sure why you'd mix and match headers and source from two sources
[04:30:42] <maddash> looks like you're wrong about the 2.0.x having 3 args
[04:31:01] <SWPadnos> yes - sourceforge only gets releases now
[04:31:04] <maddash> swpadnos: haha. just admit that you're wrong
[04:31:06] <jmkasunich> in version 2.0.5, it is defined in the .h with 2, and called with 2
[04:31:21] <SWPadnos> maddash, haha - I never said anything about it :)
[04:31:30] <jmkasunich> in everything after october 7, it is defined with 3 and called with 3
[04:31:45] <jmkasunich> if you have it defined with 2 and called with 3, you've mixed up two versions
[04:32:03] <maddash> uhh I know that
[04:32:12] <SWPadnos> well, don't do that ;)
[04:32:17] <maddash> "looks like I've got an old version"
[04:32:39] <jmkasunich> no, you've got MIXED versions
[04:32:43] <SWPadnos> that's why I was sondering why (or how) you mixed the headers and source from two different places
[04:32:44] <jmkasunich> half old and half new
[04:33:00] <jmkasunich> theres nothing wrong with the "old" version 2.0.5
[04:33:09] <maddash> hence, "looks like I've got an old version" [of the header, vs. the *new* version of the .c]
[04:33:11] <jmkasunich> as long as you don't try to mix it with pieces of version 2.1
[04:34:07] <SWPadnos> whatever - this is a silly discussion at this point. you need to untar one version of the code somewhere (somewhere new, not over an old set of sources), and configure and build there
[04:34:08] <jmkasunich> so if you understood the issue, then why are you wasting time trying to get us to admit that something is wrong?
[04:34:33] <cradek> this is fascinating
[04:34:56] <SWPadnos> whyzzat?
[04:35:23] <maddash> jmkasunich huh??
[04:35:28] <SWPadnos> jmk - did you catch the polygon lathe video?
[04:35:45] <cradek> that was very cool
[04:35:52] <jmkasunich> SWPadnos: yeah, pretty amazing
[04:36:07] <SWPadnos> that's a great application of simple mathematics
[04:36:35] <SWPadnos> maddash, did you do something to mix up the headers/source, or are you saying that the tarball on sourceforge is screwed up?
[04:36:51] <cradek> really makes me want to try to set up something like that
[04:36:53] <maddash> former
[04:37:09] <SWPadnos> ok, then I stand by what I said: "then don't do that" ;)
[04:37:12] <cradek> it would be great to be able to cut even just hex
[04:37:22] <SWPadnos> I likes the tangs on the various tapers
[04:37:25] <SWPadnos> liked
[04:37:41] <maddash> yay-xor, I got it working
[04:37:46] <jmkasunich> cradek: the spinning toolhead has to have bearings,etc that are just as rigid as the spindle
[04:37:55] <SWPadnos> cool. the whole thing or just the compile?
[04:37:58] <maddash> emc w/usrmot. woohoo. and no tcl
[04:38:01] <maddash> everything
[04:38:09] <maddash> no ncurses, no xlibs-dev
[04:38:15] <jmkasunich> cool
[04:38:31] <SWPadnos> great. did you take notes? (the wiki could always use some info on paring emc2 down to the bare minimum)
[04:38:35] <maddash> u guys want to know everything I did?
[04:38:43] <maddash> well then again , you're the experts
[04:38:50] <SWPadnos> well, not right now, but the wiki would love to know
[04:38:59] <maddash> okey doke
[04:39:19] <maddash> can I get back to this tomorrow? I kinda wanna play around w/my stripped emc now..
[04:39:20] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps
[04:39:32] <SWPadnos> sure, as long as you can remember that long
[04:39:34] <SWPadnos> :)
[04:40:39] <maddash> hah. a crucial part of adolescence is to have a vast capacity for grudges. hence the large memory bank.
[04:40:54] <SWPadnos> hmmm - I'll have to remember that
[04:41:23] <SWPadnos> I'm a Leo, so I keep grudges well past adolescence
[04:42:08] <maddash> on the off-chance that I *do* forget...
[04:42:08] <maddash> thanks a bunch to (in order): swpadnos, jmkasunich, cradek and jepler
[04:42:34] <SWPadnos> what - it's not my fault
[04:42:39] <SWPadnos> err - you're welcome
[04:43:10] <A-L-P-H-A> blame him... he likes the attention
[04:43:20] <SWPadnos> pthbthbhtbhtbthtbthb
[04:53:00] <maddash> what syntax does usrmot look for when "load"-ing a file? G code?
[04:54:07] <SWPadnos> hmmm - we should probably have a link to the RS274NGC_3.pdf file linuxcnc.org
[04:55:25] <SWPadnos> http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf
[04:55:39] <SWPadnos> that's the language specification that emc should be loading
[04:56:18] <maddash> was that a potshot at me? because I think there's a g code primer included in the emc manual...
[04:56:32] <SWPadnos> oh, is there? I haven't read the manual :)
[04:56:38] <SWPadnos> no - not a potshot
[04:57:14] <SWPadnos> I guess there is a link to it then
[04:57:18] <SWPadnos> sort of
[04:58:19] <maddash> usrmot doesn't seem to like "N10 M90"....
[04:59:16] <SWPadnos> I'm not entirely sure usermot has the interpreter
[04:59:39] <SWPadnos> I don't know that part of the code well, so I'm probably not going to be of much help there
[05:01:13] <maddash> ok
[05:02:38] <cradek> usrmot is not a gcode interpreter
[05:03:05] <cradek> it sends low level commands directly to the motion controller
[05:05:11] <SWPadnos> err - bye
[05:05:13] <jmkasunich> strange one there....
[05:05:30] <SWPadnos> indeed
[05:05:39] <cradek> woo
[05:05:40] <SWPadnos> too much Joly or Mountain Dew, I think
[05:05:42] <SWPadnos> Jolt
[05:08:54] <cradek> SWPadnos: just admit you were wrong!
[05:09:25] <SWPadnos> never!
[05:09:27] <SWPadnos> NEVER!
[05:09:33] <cradek> JUST ADMIT IT
[05:09:33] <SWPadnos> what?
[05:09:41] <cradek> oh I dunno
[05:09:45] <SWPadnos> heh
[05:10:04] <cradek> btw, the pony express went today, I sent you a check
[05:10:07] <SWPadnos> "Lessons in courtesy, number one"
[05:10:11] <SWPadnos> oh, thanks
[05:10:15] <cradek> 1) be courteous
[05:10:26] <SWPadnos> 2) goto 1
[05:11:41] <SWPadnos> any last-minute additions?
[05:11:46] <cradek> nope
[05:11:59] <SWPadnos> ok
[05:12:09] <cradek> I was surprised to see how large the total was already - you know how it goes
[05:12:15] <SWPadnos> yep
[05:12:24] <SWPadnos> I think my total will be just over $800
[05:12:36] <cradek> ooh
[05:13:03] <SWPadnos> I'm getting one of the 4C81-R64M-F64M-FPGA units
[05:13:31] <SWPadnos> that's the PC-104 board with a 166Mz (?) ARM chip, 64M ram+64M flash, and a 400kgate FPGA
[05:13:54] <cradek> neat - what's the plan for it?
[05:14:02] <SWPadnos> I may make a robot controller out of it
[05:14:08] <SWPadnos> I think the CPU takes 2W or so
[05:14:22] <cradek> cool
[05:14:33] <SWPadnos> they distribute a Linux distro that runs on it
[05:14:40] <SWPadnos> but it's not RTL or RTAI
[05:14:46] <cradek> it would be fun to make a two-wheeler segway type robot
[05:14:55] <cradek> just a toy to drive around
[05:15:02] <cradek> or do you mean something that will do work?
[05:15:07] <SWPadnos> work, for money
[05:15:12] <SWPadnos> (lots of it, ideally)
[05:15:15] <cradek> ah, boooring
[05:15:16] <cradek> heh
[05:15:21] <SWPadnos> $80k each
[05:15:28] <SWPadnos> not so boring ;)
[05:15:33] <cradek> no.
[05:16:03] <jmkasunich> I was a little impressed when I got my total too
[05:16:17] <jmkasunich> but, the same day, I got the check for the CIM jigs ;-)
[05:16:23] <SWPadnos> heh - karma
[05:16:29] <cradek> yay
[05:16:33] <SWPadnos> you should get another 7i37
[05:16:43] <cradek> on the same day, I paid some other bills too. not quite the same karma.
[05:16:53] <SWPadnos> heh
[05:18:34] <SWPadnos> maybe I should pay some bills some day
[05:55:40] <A-L-P-H-A> this is a cool idea.
http://www.time.com/time/arts/article/0,8599,1572805,00.html if there was something like that in Toronto, I think I'd volunteer there.
[05:58:58] <A-L-P-H-A> wrong place. :D
[05:58:59] <A-L-P-H-A> but oh well
[07:44:12] <jmk-st> shoptask PC is now packaged....
[07:45:52] <jmk-st> everything except the power supply is mounted on a 9" x 13-3/4" aluminum panel, plug in boards are solidly supported, hard disk is shockmounted, and a fan cools the CPU, memory, hard drive and graphics card
[10:05:56] <alex_joni> jepler: actually I used gcc-4.0 for dapper
[13:38:32] <jepler> alex_joni: my mistake then
[13:38:39] <jepler> alex_joni: I wonder if there's an error in the build-deps then
[13:40:12] <alex_joni> jepler: hardly
[13:40:15] <alex_joni> it works for me
[13:50:36] <alex_joni> Build-Depends: debhelper (>> 4.0.0),linux-headers-2.6.15-magma,g++,gcc-4.0,make,libc6-dev,tcl8.4-dev,tk8.4-dev,libgtk1.2-dev,pciutils-dev
[13:50:50] <alex_joni> that's from the dapper package
[13:52:11] <jepler> ok glad to know it's not wrng
[13:52:12] <jepler> wrong
[13:52:24] <jepler> at one point we suggested he try the breezy live cd, maybe he installed breezy
[13:53:17] <alex_joni> maybe
[13:53:41] <alex_joni> breezy definately is with gcc-3.4 iirc
[13:53:54] <jepler> yeah I thought so too -- that's why I wasn't too surprised at his report
[14:04:29] <skunkworks> There are vauge references of SWPadnos sending out totals?
[14:04:43] <jepler> skunkworks: yes, he e-mailed them a few days ago
[14:04:52] <jepler> sunday or monday
[14:05:15] <skunkworks> crap.
[14:05:36] <skunkworks> I don't delete any emails. I only seeing ones from the list
[14:05:55] <jepler> Date: Sun, 24 Dec 2006 23:30:12 -0500
[14:05:55] <jepler> From: Stephen Wille Padnos <spadnos@sover.net>
[14:05:55] <jepler> To: Jeff Epler <jepler@unpythonic.net>
[14:05:55] <jepler> Subject: Mesa order total
[14:06:15] <skunkworks> maybe he doesn't like me much.. ;)
[14:06:17] <jepler> oops, I hope he's not paranoid about seeing his address spelled out
[14:06:31] <jepler> s/paranoid/concerned and for entirely valid reasons/
[14:08:22] <skunkworks> well - he does know where you live... well maybe not if he is sending the package to cradek ;)
[14:09:24] <jepler> it would not be hard for anyone to track me down
[14:09:57] <skunkworks> never mind... I sent him the message from my work email... and somehow he sent it back to my gmail account ;)
[14:10:03] <jepler> sneaky!
[14:10:08] <skunkworks> yes
[14:23:22] <cradek> if I was harevesting emails from logs, I would have figured out AT and DOT a long time ago
[14:24:21] <cradek> or maybe we should use@signs all the time to screw@up.their.lists
[14:33:27] <skunkworks> samcoinc%gmail*com
[14:33:46] <cradek> timeguy.com!cradek
[14:35:13] <jtr> that brings back memories
[14:38:35] <skunkworks> SWPadnos: you have been paypalled
[14:45:04] <skunkworks> what is the link to jmk site again?
[14:45:12] <cradek> jmkasunich.dyndns.org
[14:45:25] <skunkworks> cradek: Thank you
[15:02:02] <alex_joni> do you guys mind if I paste a couple of lines?
[15:02:41] <alex_joni> "I may have some things to contribute to EMC2. You can give your comments if they are useful to EMC.
[15:02:44] <alex_joni> 1) a random signal generator. Currently I put this one in siggen.c. It can generate (1) normally distributed number, (2) Psuedo-Random-Binary-Signals(PRBS), (3) similar to PRBS, but both the magnitude and interval are random within certain range. I use PRBS for system identification.
[15:02:49] <alex_joni> 2) a relay tuning PID algorithm. Put a relay in the place of PID, then recording input-output data, calculate Kp, Ki, Kd. (Under testing now. ).
[15:02:52] <alex_joni> "
[15:08:32] <cradek> #2 sounds very interesting
[15:08:45] <cradek> #1 isn't useful to me but it can't hurt to add it
[15:09:26] <alex_joni> by relay I assume he (Xuecheng Xi) meant a step
[15:14:17] <cradek> yes I bet so
[15:16:14] <jepler> I think (1) should probably be a new component, not part of siggen
[15:23:46] <skunkworks> why would you not want it part of siggen?
[15:24:12] <SWPadnos> a separate component has no possibility of screwing up an existing component ...
[15:24:41] <skunkworks> ah - I was just thinking it would make sense as it is another signal
[15:24:45] <SWPadnos> plus, it may be good to keep the random signals in a separate basket, so to speak ;)
[15:25:36] <jepler> siggen always generates all the signal types
[15:25:55] <jepler> I don't want to make it always generate 3 new signal types
[15:26:13] <jepler> especially since the new signal types are unlike the existing ones, which are all simple periodic signals
[15:26:16] <skunkworks> I see - that also makes sensel
[15:26:21] <skunkworks> sense even
[15:26:27] <SWPadnos> now there's a reasonable addition to siggen - make it take parameters for the kinds of signals to generate
[15:26:41] <SWPadnos> like loadrt siggen sin=3 cos=2 square=5
[15:27:20] <jepler> on the other hand, having sin and cos generators guaranteed to always have the proper phase relationship, that's useful..
[15:27:27] <SWPadnos> true ehough
[15:27:30] <SWPadnos> enough
[15:27:59] <jepler> (hm I don't think there's a way to be sure to get 90 degrees OOF sawtooth waves with siggen -- am I wrong?)
[15:28:15] <jepler> (or anything but sine/cosine)
[15:28:25] <cradek> I'm sure you're right
[15:28:35] <cradek> we could add cawtooth
[15:28:35] <SWPadnos> correct, I bet
[15:28:44] <SWPadnos> haw haw tooth
[15:28:59] <alex_joni> caw ?
[15:29:00] <jepler> and criangle and cquare?
[15:29:03] <cradek> no I bet it's cosawtooth
[15:29:16] <cradek> cosquare
[15:29:19] <SWPadnos> crawtooth
[15:29:25] <jepler> bucktooth?
[15:29:28] <alex_joni> wonder how arccawtooth looks like then
[15:29:41] <SWPadnos> inversehyperboliccawtooth
[15:29:48] <jepler> nah I'd just say "go write your own .comp; it's not that hard, you ninny"
[15:29:52] <cradek> now you're getting all silly
[15:29:56] <SWPadnos> oh
[15:30:01] <SWPadnos> I hadn't noticed
[15:30:13] <alex_joni> it is so
[15:31:21] <jepler> emc was hard to write; it should be hard to configure as well
[15:31:53] <alex_joni> don't forget hard to run
[15:31:55] <cradek> don't worry - it is
[15:33:46] <jepler> I want to add a new command to halcmd: "net"
[15:33:58] <jepler> it optionally creates a new signal and then links the given pins to it
[15:33:59] <jepler> e.g., net Zpos axis.2.motor-pos-cmd axis.2.motor-pos-fb comp.2.in1 ddt.4.in
[15:34:43] <cradek> that sounds great to me
[15:34:53] <SWPadnos> that would be taken care of if the command parser woiuld be extended to allow many "second" parameters
[15:35:06] <SWPadnos> linksp sig pin pin pin pin ...
[15:35:48] <cradek> jepler: would you allow <= and =>?
[15:35:48] <SWPadnos> also useful for things like show (show pin siggen.0 axis.0 ...)
[15:35:57] <jepler> cradek: the current implementation doesn't
[15:36:08] <jepler> it's confusing since <= and => seem to refer to two items
[15:36:17] <jepler> SWPadnos: yeah I've thought about adding that as well
[15:36:22] <cradek> net in => out1 out2 out3 out4
[15:36:26] <jepler> but in the case of 'show pin' you don't want the banner printed over and over again
[15:36:39] <jepler> cradek: ooooh yeah that sounds nice!
[15:36:47] <SWPadnos> we had discussed the idea some time ago, but since several commands would need their parameters reversed, it was dropped
[15:36:48] <cradek> err
[15:36:55] <cradek> net hookups in => out1 out2 out3
[15:37:35] <SWPadnos> that's basically the output of halcmd list in script mode
[15:38:13] <SWPadnos> but RW pins would screw that up, since there acan be several "drivers"
[15:38:28] <cradek> net myswitch axis.home axis.limit <= parport.in
[15:38:47] <jepler> I can easily change the "
[15:38:59] <jepler> net" command to allow <= and => and <=> without paying attention to their meaning (like the existing link*)
[15:39:13] <jepler> doing the right thing in "save netla" is harder
[15:39:14] <cradek> I don't even think I know the rules for RW
[15:39:29] <SWPadnos> it seems simpler to have the OUTs first, then the INs, but you do need to make sure there's a delimiter between OUT and IN
[15:40:12] <SWPadnos> I think the RW rule may be that you can have as many RW as you want, as many readers as you want, but no WR if there are RW (?)
[15:40:28] <SWPadnos> at least, that makes sense to me
[15:41:38] <jepler> you can't link a HAL_OUT signal to a signal that already has a writer.
[15:42:09] <jepler> It looks like you can have a HAL_OUT and a HAL_IO on the same signal by linking the HAL_OUT first but not second
[15:42:20] <jepler> but not if you link in the opposite order
[15:43:21] <SWPadnos> I wonder if that's a mistake
[15:45:21] <jepler> halcmd: net net0 dir.0.out0 dir.0.io0 dir.0.in0
[15:45:21] <jepler> halcmd: net net1 dir.0.io1 dir.0.out1 dir.0.in1
[15:45:21] <jepler> HAL: ERROR: signal 'net1' already has writer(s)
[15:45:21] <jepler> HAL:4: link failed
[15:45:54] <jepler> (I believe it is the same for 'linksp' but this is shorter to paste)
[15:46:00] <SWPadnos> sure
[15:47:32] <SWPadnos> I'm not sure if that's intentional though
[15:48:16] <jepler> when printing, 'netla' should print the OUT pin (if any) first, then the I/O pins with <=> between them (including between the OUT and the first IO), then "=>", then the IN pins
[15:48:21] <SWPadnos> I don't think it makes sense to connect a RW pin to a WR pin, since the WR will always take precedence (though you could use the RW as an input in that case
[15:48:41] <jepler> e.g., net net1 dir.0.out0 <=> dir.0.io0 <=> dir.0.io1 => dir.0.in0 dir.0.in1
[15:49:49] <jepler> I'm not sure if it's intended or not, but it might break working configurations to "fix" it to not permit OUT and IO pins on the same net
[15:50:04] <SWPadnos> right
[15:50:33] <alex_joni> wonder what IO pins exist there
[15:50:41] <SWPadnos> wouldn't that have been net net1 dir.0.out0 => dir.0.io0 <=> dir.0.io1 => dir.0.in0 dir.0.in1
[15:50:49] <SWPadnos> since out0 can't take an input ...
[15:51:20] <jepler> hm, maybe
[15:51:22] <SWPadnos> though I suppose dir.0.io0 could try to write to dir.0.out0 :)
[15:51:28] <jepler> yeah
[15:57:45] <SWPadnos> hmmm - I suppose I should look at how RW pins work at a low level
[15:58:31] <SWPadnos> oh wait - signals are the things that actually allocate storage for the signal, not the pins themselves
[16:04:20] <jepler> net net0 dir.0.out0 => dir.0.io0 <=> dir.0.io1 => dir.0.in0 dir.0.in1
[16:04:33] <jepler> net sh0 mux2.0.out => mux2.0.in1
[16:05:05] <SWPadnos> I think the net command should check all pins for "suitability" before creating te signal and attaching anything
[16:05:20] <jepler> eek
[16:05:35] <SWPadnos> ie, if there are multiple WR pins, first and last on the line, it shouldn't create a net with all but the last one, then give an error ...
[16:05:52] <jepler> I would rather not to duplicate all the logic in hal_link()
[16:05:56] <jepler> s/to//
[16:06:08] <SWPadnos> sure, I can understand that :)
[16:16:59] <jepler> yuck -- hal_link() removes any existing link, so 'net x dir.0.out0 dir.0.out0' will succeed even though it's nonsense
[16:19:21] <SWPadnos> right, and there wasn't a way of naming two pins in one command until linkpp
[16:19:34] <SWPadnos> does linkpp do the same stupid behavior?
[16:19:48] <SWPadnos> (probably)
[16:20:15] <jepler> halcmd: linkpp mux2.0.in0 mux2.0.in0
[16:20:18] <jepler> 32769 float IN 0 mux2.0.in0 <== mux2.0.in0
[16:20:53] <SWPadnos> ok, so it does what's expected (ie, create signal, link pin to it, then unlink and link the pin to it again)
[16:21:05] <jepler> before trying to "preflight" the command, it would work to issue this command twice: net sh0 mux2.0.out => mux2.0.in1
[16:21:22] <jepler> but now it won't, because it will see that sh0 already has a writer
[16:22:10] <SWPadnos> I wonder if it would make more sense to use ne t to create nets only, and then use linksp to add pins to a net (ie, net fails if the net already exists)
[16:24:10] <jepler> mmmmaybe
[16:25:31] <SWPadnos> the other option is to do extensive "preflight" checks (which I like better, but it's more complicated and requires actual specifications for what may be connected as a net)
[16:25:58] <SWPadnos> I'm not sure we have real specs, we just have the current behavior ...
[16:30:58] <jepler> I made 'net' skip calling hal_link if the pin is already on the signal
[16:31:07] <SWPadnos> ok, that works too
[16:31:10] <jepler> same with preflight
[16:31:38] <jepler> now I think preflight is nearly right, in that it will error when hal_link would error
[16:33:38] <jepler> or maybe not
[16:36:11] <jepler> oh that was just a mutex bug
[16:36:39] <jepler> halcmd: net net0 dir.0.in0 dir.0.out1
[16:36:39] <jepler> HAL:8: Signal 'net0' may not add OUT pin 'dir.0.out1'
[16:36:52] <jepler> oops!
[16:36:53] <jepler> halcmd: net mixedtypes mux2.in0 mux2.sel
[16:36:53] <jepler> /usr/src/emc2/scripts/halrun: line 22: 30785 Segmentation fault halcmd $@
[16:36:56] <jepler> more bugs!
[16:37:06] <SWPadnos> segfault - hmmm :)
[16:37:21] <SWPadnos> durned double and triple indirection
[16:39:03] <jepler> oh -- that was really: net xxx pin-that-does-not-exist
[16:39:37] <jepler> halcmd: net x x
[16:39:37] <jepler> HAL:2: pin 'x' does not exist
[16:39:42] <jepler> there, much better
[16:39:46] <SWPadnos> heh
[16:40:01] <jepler> halcmd: net mt mux2.0.in0 mux2.0.sel
[16:40:01] <jepler> HAL:4: Type mismatch on pin 'mux2.0.sel'
[16:41:28] <cradek> "I suspect that the standard to use is Adobe/Macromedia Flash."
[16:41:54] <SWPadnos> ha ha
[16:41:55] <cradek> (This message is for you and is not intended for publication)
[16:42:03] <SWPadnos> I've nearly recovered from that line :)
[16:42:09] <SWPadnos> the flash line
[16:44:22] <cradek> TYPETYPETYPETYPE :q!
[17:07:13] <jepler> halcmd: net p
[17:07:13] <jepler> /usr/src/emc2/scripts/halrun: line 22: 19328 Segmentation fault halcmd $@
[17:07:18] <jepler> whoops, at least one bug left in 'net'
[17:27:21] <alex_joni> oh my..
[17:27:33] <alex_joni> that flash thingie is certainly a wacko idea
[17:27:55] <alex_joni> but I remember someone else wanting to do that.. or maybe I'm just losing it
[17:29:21] <jepler> flash sure makes it easy to create a godawful "GUI" that is like nothing else on the face of the planet
[17:29:21] <SWPadnos> it could have been the same guy
[17:29:49] <SWPadnos> either we're crazy together, or it has come up before :)
[17:29:52] <jepler> if it's a crappy 3d translucent tetrahedron, then it's a radiobutton that is off .. if it's opaque, then it's on. Icosahedrons denote checkbuttons ...
[17:30:07] <cradek> can they spin?
[17:30:07] <jepler> oh wait, flash doesn't do "3d"
[17:30:11] <jepler> cradek: well yes
[17:30:15] <SWPadnos> what are rotating dodecahedrons though?
[17:30:26] <jepler> my idea was that all the controls have a location in 3- or 4-dimensional space, and you can rotate them in a nonintuitive way to access the desired control
[17:30:27] <cradek> clockwise = on
[17:30:31] <alex_joni> jepler: flash does 3d by embedding mpegs
[17:31:00] <alex_joni> cradek: how about one single octahedron, and sequence for various tasks
[17:31:08] <alex_joni> machine on = left 12, right 4, left 24
[17:31:20] <alex_joni> now that would be ... cool
[17:31:23] <cradek> hey that's the combination to my locker!
[17:31:35] <SWPadnos> I think a hyper-icosahedron could show everything in some very nonintuitive way
[17:31:53] <jepler> anyway, my point is that flash is *freedom* in a way that the largely rectangular layout of gtk is slavery
[17:31:56] <alex_joni> of course having more than one direction could accomodate for a lot of different things
[17:32:12] <cradek> alex_joni: like left-handed people
[17:32:19] <SWPadnos> we could make running emc like playing Myst!
[17:32:19] <alex_joni> ha
[17:32:27] <jepler> ooh I have a neat idea
[17:32:32] <cradek> oh god
[17:32:36] <jepler> take a trackball and add "index pulse"
[17:32:39] <alex_joni> how about like one of those old dungeon games
[17:32:43] <jepler> draw some kind of gridlike system on the trackball
[17:32:47] <SWPadnos> Dragon's Lair
[17:32:57] <SWPadnos> but you need a laserdisc player hooked to your PC
[17:33:01] <jepler> now hook it up to a circuit to accept a "combination" which unlocks something with a solenoid
[17:33:03] <alex_joni> "you are in a dungeon. you can proceed North, South and Vest"
[17:33:16] <jepler> the 2d (or better yet call it 3d) combination lock
[17:33:18] <SWPadnos> vich bay is best?
[17:33:23] <SWPadnos> vay, that is
[17:33:38] <SWPadnos> man - that came out all screwed up, didn't it?
[17:33:39] <alex_joni> I'd go North
[17:33:50] <jepler> I'd turn left and continue that way until I reach a wall
[17:34:10] <alex_joni> if you turn left fast enough, you might hit yourself
[17:34:21] <SWPadnos> wait a sec -you can have two trackballs spaced 7 feet apart, and require both to be manipulated together to allow the lock to open!
[17:34:43] <cradek> *click* OPERATE YOUR TRACKBALL SIR
[17:35:24] <skunkworks> http://bellsouthpwp.net/e/d/edburns00/classic-gaming/tunnels/
[17:35:47] <alex_joni> jepler: still have that link for the vista doc?
[17:36:16] <jepler> alex_joni:
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt
[17:36:29] <alex_joni> jepler: thx, the guys webpage reminds me of those games
[17:36:41] <alex_joni> http://www.cs.auckland.ac.nz/~pgut001/old_home/index.html
[21:42:00] <SWPadnos> jepler, I just had a thought on the PDM vs PWM LED brightness issue you were having
[21:42:46] <SWPadnos> I mentioned briefly (and Peter W explained in the post you linked to) that his interleaved PWM scheme has the ability to control the minimum pulse width of the resulting waveform
[21:43:04] <SWPadnos> you do that by not reversing some of the low bits of the counter
[21:43:44] <SWPadnos> so int_counter[7-3] = counter [3-7], and int_counter[0-2] = counter[0-2]
[21:44:16] <SWPadnos> that gives you a pulse width of 8 clock periods (and is basically what is in the Mesa code)
[21:45:44] <jmkasunich> alex_joni: are you around?
[21:46:03] <jmkasunich> where is the source for the parameterized version of rtai_smi.ko that you sent me?
[21:49:33] <jmkasunich> I think it doesn't reset the mask on rmmod like the original did
[21:50:44] <alex_joni> jmkasunich: hi
[21:51:02] <alex_joni> http://dsplabs.cs.utt.ro/~juve/tempdebs/rtai_3.3-2.tar.gz
[21:54:16] <jmkasunich> 3.4megabytes?
[21:54:35] <jmkasunich> * jmkasunich downloads
[21:55:15] <jmkasunich> ah, you defaulted smiReset to zero
[21:55:28] <jmkasunich> thats why my power button didn't work
[21:56:21] <jmkasunich> I'd suggest changing that default to 1, like the original
[21:56:31] <jmkasunich> that restores the original SMI state when you rmmod the module
[21:56:41] <jmkasunich> which lets the power button be used to turn off the PC
[21:59:07] <SWPadnos> did it not work when held for 5 seconds?
[21:59:38] <jmkasunich> not with smi disabled
[22:00:05] <jmkasunich> which is kind of a bonus actually
[22:00:13] <SWPadnos> interesting
[22:00:29] <SWPadnos> I thought the 5 second hold was a chipset function
[22:00:31] <jmkasunich> on the Mazak, we put in a relay that disconnected the front panel power button from the mobo whenever the master estop relay was closed
[22:00:41] <jmkasunich> (not good to power down the PC while milling)
[22:00:50] <SWPadnos> heh
[22:00:55] <jmkasunich> with SMI disabled, the button doesn't work
[22:01:05] <jmkasunich> until EMC exits and you rmmod the module
[22:01:13] <SWPadnos> we should make an ATX power harness that brings out an isolated PG signal from the PC power supply :)
[22:01:29] <SWPadnos> stick that in the estop chain
[22:01:51] <jmkasunich> any servo system should (IMO) have a charge pump type estop device
[22:01:59] <jmkasunich> to detect _any_ PC lockup
[22:02:05] <SWPadnos> true - that would take care of it
[22:02:51] <jmkasunich> btw, with SMI disabled, I was able to use a USB flash drive without latency problems
[22:03:02] <jmkasunich> I think the SMI is used for automount
[22:03:48] <jmkasunich> hmm, thats not good....
[22:04:09] <jmkasunich> I tried pressing the power button while SMI was disabled (as I reported a few mins ago)
[22:04:15] <SWPadnos> did you mean not able to use??
[22:04:16] <jmkasunich> and it didn't turn off the power supply
[22:04:40] <jmkasunich> but when I rmmod'ed the SMI disable module, the queued SMI interrupt turned off the supply
[22:04:45] <SWPadnos> heh
[22:04:52] <SWPadnos> that would be a surprise, wouldn't it?
[22:04:59] <jmkasunich> it was
[22:05:23] <jmkasunich> I am very tempted to completely ignore the mobo power button
[22:05:51] <SWPadnos> it should be hard to turn the machine on in that case
[22:05:52] <jmkasunich> connect a front panel button that grounds the PS "turn on" pin
[22:05:59] <SWPadnos> hmmm
[22:06:07] <jmkasunich> a relay that holds that pin low once power is up
[22:06:16] <SWPadnos> you can't disable that though - it has to make a connection to turn the machine on
[22:06:18] <SWPadnos> ok
[22:06:18] <jmkasunich> and a NC button to turn it off
[22:06:46] <jmkasunich> I can short the NC button with the estop relay so it won't turn off unless estop is off
[22:07:18] <jmkasunich> that sucks tho, what I really want is "can't turn off until Linux is shut down"
[22:08:24] <jepler> SWPadnos: yes, I was inverting all but the low 2 bits already.
[22:08:31] <SWPadnos> ok
[22:09:06] <SWPadnos> was that after you noticed the diminished brightness of the LED in PDM mode, or duringthose tests?
[22:09:36] <jepler> no, before
[22:09:40] <SWPadnos> ok
[22:09:51] <jepler> I think that it was mentioned in the old usenet post I found on the interleaved pwm method
[22:09:59] <SWPadnos> hence the 100ns pulses, instead of 25ns
[22:10:19] <jepler> right
[22:11:29] <jepler> I could easily change the # bits but I don't have enough gates to make it runtime-selectable
[22:11:40] <SWPadnos> no indeed
[22:12:37] <jepler> (and I'd spend them on making it per-pwm instead)
[22:12:49] <SWPadnos> the interleaved option?
[22:13:01] <jepler> yes
[22:13:05] <jepler> time to drive home
[22:13:14] <jmkasunich> jepler: how are you doing the bit reversal?
[22:13:24] <SWPadnos> hmmm. yeah - conceptually it's very simple, but it still takes gates for the mux
[22:28:02] <jepler> jmkasunich: you can write an expression like b <= {a[0], a[1], a[2]} to permute the bits of a and then assign them to b
[22:28:38] <jmkasunich> * jmkasunich is a hardware guy
[22:28:42] <jepler> then in the expression that gives the value for the output pin, I write .... pwm0 < (pwm_is_pdm ? counter : counter_reversed)
[22:28:50] <jmkasunich> that should reduce to simply wire routing (no logic)
[22:28:52] <jepler> I assume that is implemented with a mux or sthe like
[22:29:37] <jepler> I'm not sure what the implementation is, but it uses a lot more chip resources to have each pwm have its own pwmX_is_pdm variable
[22:29:57] <jmkasunich> how wide are the counters?
[22:30:02] <jepler> 11 bits
[22:30:05] <jepler> I'm reversing 9 of the bits
[22:30:13] <jmkasunich> thats 9 two input muxes
[22:30:57] <jmkasunich> if its like a Xilinx device, the mux probalby occupies one logic block
[22:31:02] <jepler> yes, I think so
[22:31:20] <jepler> 9 if I have a single one for all the PWM outputs, but 36 if I have a different pwmX_is_pdm for each of the 4 PWMs
[22:31:30] <SWPadnos> you may be able to get 2 muxes in one LE
[22:31:43] <SWPadnos> depends on carry or other block inputs
[22:32:16] <jmkasunich> Xilinx CLB contains two LUTs, so that would work (for Xilinx)
[22:32:34] <SWPadnos> which Xilinx family are you referring to?
[22:33:00] <jmkasunich> well, I'm most familiar with ancient 4000 series, but as far as I can tell the Spartan II is the same
[22:33:00] <SWPadnos> (not that it matters - it's an Altera part)
[22:33:17] <jmkasunich> exactly - thats why I qualified what I said
[22:33:40] <SWPadnos> ok. I think the Virtex uses different structures from the Spartan - I wasn't sure if that's true for all part families
[22:33:45] <SWPadnos> sure
[22:34:25] <jepler> I should try it again -- after changing some sythesis options it implemented the bit reversal as a ROM look-up and gave me back some LEs. There are 3 "EABs" that can be used in this way.
[22:37:22] <alex_joni> jmkasunich: I left the smiReset as it was originally in the rtai sources
[22:37:28] <jepler> whee: 567/576 (98%)
[22:37:33] <alex_joni> that page from captain.at suggested to default it to 1
[22:37:50] <jepler> (total logic elements used)
[22:38:04] <jepler> hum, but it didn't use any of the array blocks !?
[22:38:13] <alex_joni> jmkasunich: I'd rather have them both at 0 (previous behaviour), and specify them at insmod time.. but then again, I don't use it :)
[22:45:08] <jepler> hm it appears I'm on the first page of google results for the search: opengl manpages
[22:45:21] <jepler> (for
http://emergent.unpythonic.net/01157053957)
[22:45:34] <alex_joni> jepler: :P
[22:47:07] <jepler> and top hit for: opengl manpages ubuntu
[22:54:38] <alex_joni> well.. you could google for welding in romanian :D
[23:38:22] <jmkasunich> this smi thing sucks
[23:39:14] <jmkasunich> if you press the power button (even briefly) while the SMI is disabled, when you rmmod the module (and re-enable the SMI), the computer will power down
[23:39:42] <skunkworks> hmm - have not tried that.
[23:40:43] <skunkworks> the way mine is set up - it is run when emc starts - and unloaded when emc ends.
[23:41:01] <skunkworks> exited
[23:41:07] <jmkasunich> usually, a brief press will be ignored (unless the system is shutdown), and you have to hold it for 4 seconds to shutdown
[23:41:09] <jmkasunich> exited?
[23:41:30] <skunkworks> and unloaded when emc is exited
[23:41:33] <jmkasunich> oh
[23:41:44] <jmkasunich> start EMC, then briefly press the power button
[23:41:46] <jmkasunich> then stop emc
[23:41:58] <skunkworks> ok - be back in a bit
[23:42:05] <skunkworks> (in xp right now)
[23:54:30] <skunkworks> I can hit the button while emc is running - nothing happens. the second I exit - the computer shuts down.