Back
[00:01:38] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile:
[00:01:38] <CIA-2> EMC: Michael Buesch reports that this fixes a crashing problem on x86_64 systems.
[00:01:38] <CIA-2> EMC: I still have not had the time to test it myself for 2.3 (and it doesn't affect
[00:01:38] <CIA-2> EMC: our supported platforms anyway), but there'll be a lot of time to test it on
[00:01:38] <CIA-2> EMC: TRUNK
[00:25:27] <jepler> SWPLinux: It'd be interesting to know wheter you can run a vismach model
[00:25:36] <jepler> that's python + tk + hal but without most of axis
[00:25:43] <jepler> I think you can 'loadusr' them inside a halrun
[00:25:49] <jepler> without the need to start emc or connect anything
[00:30:55] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$ cat gantry.hal
[00:30:55] <jmkasunich> loadusr -Wn gantrypanel pyvcp -c gantrypanel gantry.xml
[00:30:55] <jmkasunich> loadusr -Wn jmkgantrygui src/emc/usr_intf/axis/scripts/jmkgantrygui.py
[00:30:55] <jmkasunich> net gantry gantrypanel.gantry-f jmkgantrygui.gantry
[00:30:55] <jmkasunich> net crotary gantrypanel.crotary-f jmkgantrygui.crotate
[00:30:56] <jmkasunich> net vertical gantrypanel.vertical-f jmkgantrygui.ram
[00:30:58] <jmkasunich> net saddle gantrypanel.saddle-f jmkgantrygui.saddle
[00:31:19] <jmkasunich> I use this ^^^ hal file to run vismach + pyvcp without EMC
[00:36:56] <jepler> gantrypanel lets you jog the gantry around?
[00:37:02] <jmkasunich> yeah
[00:37:05] <jepler> neat
[00:37:12] <jmkasunich> I was using vismach as crude 3-D cad
[01:25:37] <SWPLinux> I'm back now
[01:25:42] <SWPLinux> lemme see about vismach
[01:29:21] <SWPLinux> hmmm. on an installed system, how does one run vismach?
[01:33:14] <jepler> the visualization programs should be installed in /usr/bin and loadable by loadusr
[01:33:35] <jepler> $ halrun halrun: loadusr scaragui
[01:33:36] <SWPadnos> hmmm. not by make install
[01:33:43] <SWPadnos> hmmm
[01:33:48] <jepler> o rly?
[01:33:53] <SWPadnos> no, not really :)
[01:34:43] <SWPLinux> halcmd: loadusr scaragui
[01:34:44] <SWPLinux> halcmd: alloc: invalid block: 0x7fa2d1081558: 0 0 0
[01:35:19] <SWPLinux> strangely, the joints are still there in HAL, but there's no display window
[01:35:57] <SWPLinux> and ps shows scaragui as defunct:
[01:36:09] <SWPLinux> 22023 pts/0 S+ 0:00 halcmd -kf
[01:36:10] <SWPLinux> 22073 pts/0 Z+ 0:00 [halcmd] <defunct>
[01:36:12] <SWPLinux> 22450 pts/0 Z+ 0:00 [scaragui] <defunct>
[01:36:48] <jepler> the pins probably stay around until you shut down hal
[01:36:56] <SWPLinux> yep
[01:37:04] <SWPLinux> unload didn't get rid of them
[01:37:11] <jepler> (they only get removed by clean shutdown of the creating component, or clean shutdown of hal)
[01:37:16] <SWPLinux> yep
[01:37:38] <jepler> hm, zombie -- I wonder if halcmd has a duty to waitpid on the userspace components it creates .. quite possibly it does
[01:38:27] <SWPLinux> it seems that it shouldn't for loadusr
[01:38:29] <jepler> anyway, it sure looks like a bug or bad interaction with my "togl" (opengl tk widget) or "minigl" (python opengl api) modules
[01:39:52] <jepler> which narrows it down considerably
[01:40:20] <jepler> and based on your traceback, it's probably not in minigl
[01:40:26] <jepler> it happens when first touching togl which would be before touching minigl
[01:40:51] <SWPLinux> do you think it would help for me to try it with python 2.4?
[01:40:57] <SWPLinux> I think it used 2.6 by default
[01:41:29] <jepler> ummm
[01:41:34] <jepler> no idea
[01:41:41] <SWPLinux> "it" being configure ...
[01:41:56] <SWPLinux> I think the error isn't in the exact same place as before
[01:42:12] <jepler> that's not necessarily a huge surprise
[01:42:27] <SWPLinux> I thought it was in the "Tcl_PkgPresent" line before
[01:42:48] <SWPLinux> the line numbers must be screwed up, because it seems like it's on "return NULL" Now
[01:43:06] <SWPLinux> unless I understand what rows and columns are - duh
[01:43:26] <SWPLinux> yes, it's still the pkgpresent line in PyObject *install()
[01:44:26] <SWPLinux> I had tried sticking a printf just above that stanza, but there were other problems with that :)
[01:45:40] <jepler> the other time you reported this problem, was it in sim?
[01:45:51] <jepler> on jaunty?
[01:45:54] <SWPLinux> no. same system as now
[01:46:01] <jepler> oh, realtime both times?
[01:46:04] <SWPLinux> yep
[01:46:04] <jepler> on jaunty?
[01:46:08] <SWPLinux> yep
[01:46:14] <SWPLinux> I can try a sim build
[01:46:53] <jepler> I'm installing a jaunty in vmware but I don't intend to spend a day building a realtime kernel
[01:47:02] <SWPLinux> heh
[01:47:13] <SWPLinux> it only takes 30 minutes, including modules
[01:47:16] <SWPLinux> but not in a VM
[01:47:26] <jepler> there's the part where I have to get it right :-P
[01:47:39] <jepler> why'd the put a coffee cup stain on the background image?
[01:47:41] <SWPLinux> well, I can give you some config files that seem to work
[01:48:06] <jepler> hm this can't be right
[01:48:15] <jepler> it is spewing "starting file manager" across the bottom of the screen
[01:48:21] <jepler> it gets up to about 6, then gets back down to about 2
[01:48:24] <SWPLinux> sounds like Windows
[01:49:03] <SWPLinux> same problem with sim
[01:49:33] <jmkasunich> FWIW, I've had defunct vismach related processes before
[01:49:49] <SWPLinux> good to know
[01:49:56] <jmkasunich> usually when I've done something that made vismach/foogui.py crash
[01:50:01] <SWPLinux> but since I got basically the same error, I think they may be related :)
[01:50:10] <SWPLinux> yep, that's what happened here
[01:50:24] <jmkasunich> I do my "3D cad" by editing the python, running, editing, running, editing, running, etc, so mistakes do happen
[01:50:30] <SWPLinux> coredump, and both scaragui and the halcmd child end up as zombies
[01:50:56] <jmkasunich> scaragui shouldn't be crashing tho
[01:51:08] <jepler> https://bugs.launchpad.net/ubuntu/jaunty/+source/nautilus/+bug/325973/+viewstatus
[01:51:20] <jepler> jmkasunich: right, that's the problem -- *gui and axis crash on jaunty
[01:51:54] <jmkasunich> I see
[01:52:17] <jmkasunich> I just threw my two cents in there in case the debugging was going into "why the zombie", rather than "why the crash"
[01:52:23] <SWPLinux> hmmm. I have python 2.5 and 2.6 installed, and /usr/bin/python is 2.6.1
[01:52:28] <jmkasunich> * jmkasunich goes back to the cursed CIM jigs
[01:52:32] <SWPLinux> heh
[02:01:03] <SWPLinux> ok, same problem with python 2.4
[02:01:28] <jepler> I'll see if I can reproduce it after I have jaunty installed
[02:03:50] <SWPLinux> ok
[02:04:08] <SWPLinux> thanks. sorry I'm mostly useless at debugging this stuff
[02:23:13] <jepler> hm, this vmware is running at totally the wrong speed
[02:23:24] <jepler> it thinks those packages took 17 minutes to download, it was more like one minute
[02:25:07] <SWPLinux> weird. I'd expect the opposite
[02:28:35] <jepler> $ ssh 10.0.3.248 date; sleep 10; ssh 10.0.3.248 date
[02:28:35] <jepler> Mon Mar 23 22:19:31 CDT 2009
[02:28:35] <jepler> Mon Mar 23 22:20:29 CDT 2009
[02:28:47] <jepler> time passed 6x too fast in the virtual machine during that ten seconds
[02:29:13] <SWPLinux> weird
[02:31:25] <jepler> Need to get 396MB of archives.
[02:31:25] <jepler> After this operation, 887MB of additional disk space will be used.
[02:31:35] <jepler> ugh, that's quite a lot (build-dep emc2)
[02:32:13] <SWPLinux> yeah, that does seem like a lot
[02:32:30] <SWPLinux> but then again, I've gotten used to downloading 3-400 MB/day in updates
[02:32:51] <jmkasunich> it would be interesting to look at a list of EMC2's build deps, sorted by size
[02:33:22] <SWPLinux> including obvious ones like gcc?
[02:33:42] <jepler> I wouldn't be surprised if stuff for building the documentation is biggest, followed by stuff to build user interfaces, followed by stuff to actually do stuff
[02:33:44] <SWPLinux> (most others are probably optional, but a compiler is sure needed)
[02:33:59] <jepler> gcc is tiny compared to all the crap that gets pulled in for tex and lyx
[02:34:08] <jmkasunich> build-essential is a given anyway
[02:34:10] <SWPLinux> I think gcc and a couple of libraries are all you need for the core
[02:34:34] <jmkasunich> the reason for the sort order is to see what would gain you the most if you made it optional (or eliminated it completely)
[02:34:36] <SWPLinux> but yeah, tcl/tk, python, gtk ... are all optional
[02:34:52] <jepler> in principle they're optional
[02:35:01] <SWPLinux> true
[02:35:03] <jepler> probably configure and/or make have bitrotted to the point where they're required for some stupid reason
[02:35:07] <jepler> since everyone has them
[02:35:31] <jepler> or we force them to get it anyway
[02:36:00] <jmkasunich> I think I remember when gtk made that step (optional to required)
[02:36:08] <SWPLinux> I have an interest in small systems, and several others have mentioned a similar interest
[02:36:10] <jmkasunich> when it was just halscope and halmeter, it was optional
[02:36:20] <SWPLinux> pickconfig should also be optional
[02:36:42] <SWPLinux> I'm not sure what else needs it, that isn't also optional
[02:36:51] <jepler> all that's needed is to do the work to make it truly optional again
[02:37:20] <SWPLinux> we need a different package scheme before that's really useful IMO
[02:38:01] <SWPLinux> for 2.3, firmware is moved outside the EMC2 package - was anything else done on that front?
[02:38:53] <jepler> no
[02:39:20] <SWPLinux> ok. then I vote to wait until at least 2.4 to mess with the dependencies :)
[02:39:31] <jepler> TRUNK's for development again
[02:39:39] <jepler> so if you think you'll benefit from it .. knock yourself out
[02:40:10] <SWPadnos> I probably would, from hitting my head against a wall :)
[02:40:34] <jmkasunich> I have nothing but gratitude for the folks who have worked on packaging
[02:40:41] <jmkasunich> since I haven't a clue about how any of that works
[02:41:07] <jepler> well it's all made of perl scripts and C code, compressed until they become a diamond
[02:41:17] <jepler> not a beautiful diamond, but some industrial artificial diamond
[02:41:32] <SWPadnos> I just end up scratching myself or shattering them :)
[02:41:50] <jmkasunich> I suppose "works" is the wrong word
[02:42:10] <jmkasunich> I don't know what it is supposed to do, OR how it does it
[02:42:55] <jmkasunich> the sad part is that I don't want to know
[02:43:08] <SWPadnos> I'd probably have to study graph theory to really understand how it does the work
[02:43:59] <jmkasunich> and large chunks of debian project docs to figure out what it is supposed to do
[02:44:05] <jepler> well I'm sure this will not clarify things:
http://arxiv.org/abs/0811.3620
[02:44:35] <SWPadnos> yes, it doesn't
[02:44:39] <jepler> 2.2.1 Result: Installability is NP-complete
[02:44:57] <jmkasunich> heh
[02:45:08] <jmkasunich> NP stands for Nasty Problem
[02:45:19] <SWPadnos> "completely Nasty Problem" :)
[03:11:04] <jepler> 'night
[11:55:30] <fenn> the biggest chunk of emc build-dep is lyx and associated texlive-fubar packages
[11:56:26] <alex_joni> yup
[11:56:57] <alex_joni> pushing the docs into a different deb package won't help though
[11:57:18] <fenn> why not?
[11:57:31] <alex_joni> if that package gets built from the same sourcedir, then the build-dep remains (as the build-dep needs to provide packages to build all packages from the current source)
[11:57:52] <fenn> well that's silly
[11:57:58] <alex_joni> that's the debian policy
[11:58:34] <alex_joni> we need to split the emc2 source in more than one source package
[11:58:45] <alex_joni> then each of those will have it's own build-dep
[11:59:01] <fenn> docs used to be a separate repository but they got merged to synchronize with the source code
[11:59:01] <alex_joni> I think they can still reside in the same dir and have a single debian/ folder..
[11:59:15] <alex_joni> yes, and it's pretty good they did
[11:59:35] <fenn> so.. i dont really know what counts as a "sourcedir"
[12:08:04] <alex_joni> something defined in debial/control I think
[12:12:00] <jepler> a source directory is a directory tree with a debian/ directory. it's turned into one source package and one or more binary packages by dpkg-buildpackage.
[12:13:26] <alex_joni> jepler: wonder if a debian/configure can be used to "bastardize" that convention
[12:13:58] <alex_joni> debian/configure docs (generates rules and control to build docs)
[12:14:00] <jepler> I don't like that idea much.
[12:14:12] <jepler> that means the docs source package carries around all the source code, and the source code package carries around all the docs
[12:14:20] <jepler> it's a waste that, over time, adds up to as much as the build-deps you're trying to decrease
[12:14:43] <alex_joni> hmm..
[12:14:47] <alex_joni> I can see that
[12:15:40] <alex_joni> so it's either move the docs to a new module
[12:15:56] <alex_joni> or create some dirs in the emc2 module
[12:16:09] <alex_joni> one for docs/ one for source/, etc
[12:16:25] <alex_joni> but that means moving all the source tree around.. which is probably a HUGE pita
[12:16:37] <jepler> oh, I forgot: you *have* to have the source tree to build docs, because there's all the manpages generated by comp
[12:16:46] <jepler> or at least, you have to have the .comp files
[12:16:51] <jepler> so it's a big mix-and-match
[12:16:59] <jepler> not easily divided into two buckets with no duplication
[12:17:15] <alex_joni> except if the docs/ only takes care of html and pdf (without manpages)
[12:17:23] <alex_joni> and the source/ takes care of manpages
[12:17:29] <jepler> emc2-some-of-the-docs-its-complicated-sorry_2.4.0beta999
[12:17:32] <alex_joni> (but should rather duplicate pdf and html building)
[12:18:19] <alex_joni> surely there must be a good solution to this :)
[12:20:13] <fenn> there are html manpages
[12:20:30] <fenn> i'd be happy if just pdf was in a separate package
[12:20:42] <fenn> but i dont see how that would work with debian's silliness
[12:21:44] <alex_joni> the other way would be to keep the big build-deps
[12:22:09] <alex_joni> how about providing a meta package which depends (not build-depends) on the minimum stuff needed to build emc2
[12:22:19] <alex_joni> without docs & all
[12:22:53] <alex_joni> I mean, the users who want to apt-get build-dep emc2 usually just want to build TRUNK, not build packages & all
[12:23:14] <jepler> cradek did that with emc2-cvs-build-dep or something like that
[12:23:24] <jepler> I don't know that it ever really cured any problems
[12:23:40] <jepler> it's a separate package list that has to be maintained, and maintainers are lazy
[12:23:50] <jepler> step 0: find a developer who will actually pledge to keep the list up to date
[12:24:00] <jepler> it isn't me; I install the doc-building stuff on all machines where I work with emc anyway
[12:24:36] <alex_joni> right, and even if you don't.. I'm sure you don't spend more than 5 minutes to figure out what deps you're missing
[12:27:16] <jepler> as for the docs: someone enterprising should replace tetex-extra with whatever the correct texlive package name(s) is/are
[12:27:25] <jepler> it's tetex-extra that pulls in an astonishing amount of texlive
[12:27:32] <jepler> such as all the -lang- packages
[12:30:51] <jepler> on TRUNK, IMO you only need to look at how this affects hardy (or newer, if you care); on 6.06, tetex-extra is still a real package, not a replacement
[12:31:17] <jepler> SWPadnos: I get the same crash running scaragui
[12:31:33] <jepler> on jaunty
[12:45:43] <jepler> alex_joni: will you contact Floca Alexandru <alexandru.floca@yahoo.de> about the romanian translation?
[12:46:43] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/po/pl_axis.po: updated translation from micges
[12:47:16] <CIA-2> EMC: 03jepler 07v2_3_branch * 10emc2/src/po/pl_axis.po: from TRUNK: updated translation from micges
[12:48:10] <alex_joni> jepler: sure
[12:49:15] <jepler> bbl, going to the office..
[12:49:45] <alex_joni> * alex_joni stayed home sick today
[13:46:51] <micges1> alex_joni: on what system you are now ?
[13:47:02] <alex_joni> right now?
[13:47:11] <alex_joni> doze
[13:47:29] <micges1> hardy? dapper?
[13:47:48] <alex_joni> on this machine I have a hardy install, a doze install with hardy & dapper VMs on it
[13:48:24] <micges1> 2.3 packages are for what system builded now ?
[13:48:52] <alex_joni> hardy
[13:49:00] <alex_joni> and they will be built for dapper too
[13:49:11] <alex_joni> not sure if the beta is built for dapper yet
[13:49:36] <alex_joni> no, it's not.. only hardy beta packages so far
[13:50:48] <alex_joni> why are you asking?
[13:51:14] <micges1> I've installed emc2.3 beta on hardy and it's not working
[13:51:21] <micges1> from packages
[13:52:01] <alex_joni> what isn't working?
[13:53:29] <micges1> looks like axis.py is updated and axis.tcl isn't
[13:53:30] <micges1> moment
[13:57:33] <micges1> alex_joni: uff everything works now
[13:58:11] <micges1> ./configure was run without --inplace
[13:58:50] <SWPadnos> uh. I thought you said you had installed from packages ...
[13:59:59] <micges_emc> when you have 3xcvs and one misconfigured and the you install emc2.3 from packages, none of them will be working :)
[14:00:12] <SWPadnos> heh
[14:01:02] <alex_joni> too bad you can only run one at a time
[14:11:34] <micges_emc> yep
[14:15:53] <alex_joni> but I guess PC's are cheap today
[14:16:15] <alex_joni> and if you want sim, there's alwasy VMware and Xen & co
[14:51:09] <aystarik> is there any tutorial/how-to about making firmwares (hostmot2?) for MESA cards?
[14:52:31] <SWPadnos> which parts?
[14:53:04] <SWPadnos> are you wondering how to get the Xilinx tools to generate a bitfile you can use, or how to create the VHDL/Verilog source to get the FPGA to do what you want?
[14:53:38] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BuildingHostmot2
[14:53:57] <jepler> however I think the paths have changed in the meantime
[14:54:41] <jepler> there's now a single copy of the firmware in firmware/src
[14:55:43] <SWPadnos> there should also be some useful information in the src/hal/drivers/mesa_5i2x directory, maybe in the mesa-configtools branch
[14:56:07] <jepler> I'm not sure how to select to build a specific board and pinout with the current setup (we simply receive the .pin, .bit and source files from peter wallace at mesa and put them in our CVS; we don't build the firmwares ourselves)
[14:56:12] <SWPadnos> there are makefiles that will generate bitfiles from your source
[16:54:16] <aystarik> thanks
[18:04:07] <micges> what mean Leadscrew Pitch ? (stepconf)
[18:05:40] <BJT-Work> number of turns per unit
[18:05:51] <SWPadnos> turns per inch or mm per turn of the screw (assuming you're using a leadscrew)
[18:06:04] <BJT-Work> heh
[18:06:05] <SWPadnos> if you have a rack and pinion, it's the travel per revolution of the pinion
[18:06:13] <alex_joni> "Steigung" in german
[18:06:34] <jepler> and if you have a multiple-start screw, then you don't actually enter its pitch
[18:07:01] <micges> mhm
[18:07:07] <SWPadnos> and the calculation is inverted if you select mm machine units
[18:07:13] <SWPadnos> (vs. inch)
[18:07:14] <jepler> you enter its advance, which is pitch * starts
[18:07:31] <jepler> right, for inch you enter "8" if you have a 1-start, 1/8TPI screw
[18:07:32] <micges> oh I see now
[18:07:34] <SWPadnos> not sure all that matters if you're just translating stepconf strings :)
[18:07:56] <alex_joni> sure it does
[18:07:57] <jepler> for mm you enter "5" if you have a screw that advances by 5mm in one turn
[18:08:12] <alex_joni> after hearing all that, it's _waaaay_ more complicated to translate the simple string
[18:08:18] <SWPadnos> alex_joni, sure, but for translating the help and/or docs :)
[18:08:23] <micges> I know what it is but I didn't get it why it is inverted
[18:08:46] <alex_joni> micges: mm screws are labeld in mm/turn
[18:08:49] <SWPadnos> lead screws are specified differently, similar to machine screws
[18:08:59] <alex_joni> american screws are labeled turn/inch
[18:09:12] <micges> ok I see now
[18:09:19] <micges> thanks
[18:10:13] <BJT-Work> Enter the pitch of the leadscrew here. If you chose "Inch" units, enter the number of threads per inch here (e.g., enter 8 for 8TPI). If you chose "mm" units, enter the number of millimeters per thread here (e.g., enter 2 for 2mm/rev). If the machine travels in the wrong direction, enter a negative number here instead of a positive number or invert the direction pin for the axis.
[18:10:36] <BJT-Work> should this say "millimeters per rev"?
[18:10:52] <alex_joni> probably
[18:11:07] <micges> BJT-Work: yes that would be correct
[18:11:17] <BJT-Work> ok, I'll fix that
[18:23:11] <micges> Direction Hold time?
[18:23:46] <micges> and direction setup time ?
[18:24:27] <micges> what are they mean?
[18:26:26] <jepler> http://www.linuxcnc.org/docview/html/hal_rtcomps.html#sub:Stepgen-Step-Types
[18:26:38] <jepler> the minimum time of various parts of the step+direction waveform
[18:27:26] <micges> minimum time - thanks
[19:18:19] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/po/pl_axis.po: updated translation from micges
[19:59:15] <SWPadnos> jepler, did you do a 32-bit or a 64-bit Jaunty VM install yesterday?
[20:10:03] <alex_joni> 48-bit :)
[20:10:31] <SWPadnos> well, 32 or 64 would be 96 ;)
[20:22:04] <jepler> SWPadnos: 99 bit
[20:22:09] <jepler> 50 cent?
[20:22:10] <jepler> I forget
[20:22:13] <SWPadnos> 8mile
[20:22:20] <SWPadnos> 4dos
[20:22:24] <jepler> 16 tons
[20:22:28] <SWPadnos> anyway
[20:22:57] <alex_joni> 2pac
[20:23:09] <SWPLinux> 7up
[20:23:21] <alex_joni> 1way
[20:23:40] <SWPLinux> this looked like it could be relevant to the crashes, but it seems not:
http://mail.python.org/pipermail/python-list/2008-July/672444.html
[20:25:49] <SWPLinux> then again, I should be absolutely sure I did everything correctly before saying that
[20:28:29] <alex_joni> since jepler reproduced the problem, I'm not sure it's something you might have done wrong
[20:28:40] <SWPLinux> heh
[20:29:03] <SWPLinux> yeah, I'm pretty sure I didn't screw anything up, since I first saw the problem with unmodified sources
[20:29:18] <SWPLinux> I'm just trying a little debugging, which I may have done wrong
[22:35:09] <jepler> SWPadnos:
http://emergent.unpy.net/index.cgi-files/sandbox/emc-axis-jaunty.png
[22:35:32] <jepler> SWPadnos: I had to *remove* python2.5 tcl8.4 tk8.4 and *install* python2.6-dev tcl8.5-dev tk8.4-dev
[22:35:47] <jepler> the crash is because parts of emc2 were compiled with tcl8.4 and python was compiled with tcl8.5
[22:35:52] <jepler> that mix&match doesn't work
[22:36:41] <jepler> so changes to debian/configure et al to adapt to this will be necessary
[22:36:53] <jepler> right now tk8.4 is hardcoded on all versions, and that'll have to change
[23:05:33] <KimK_> KimK_ is now known as KImK
[23:38:06] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: expand a bit on the leadscrew desc
