Back
[11:18:42] <lilo> [Global Notice] Hi all. Okay, here goes. In just a few moments, a rather large main rotation server will be restarted. It will be followed by another, and another, and then by smaller servers. Please bear with us.
[11:27:31] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[12:35:10] <lilo> [Global Notice] Hi all. We've completed our upgrade of the network to add a patch which should help us cope better with clonebots for the time being. Meanwhile, we can't stress enough---if you can't connect to freenode, please CHECK OUT THE WEBSITE NEWS PAGE. There's currently a summary of the events of the last 18 hours there; please take a look at
http://freenode.net/news.shtml for information on what happened and how it will affect your access to the n
[12:36:07] <lilo> [Global Notice] [...your access to the network.] Thanks for your patience and understanding, and thank you again for using the network!
[12:41:14] <alex_joni> morning
[16:31:25] <rayh> Any problems with me adding README files to the existing configs?
[16:31:31] <alex_joni> NONE
[16:31:32] <alex_joni> ;)
[16:31:43] <alex_joni> also .ini's if you'd like
[16:31:55] <alex_joni> a stepper/stepper_mm.ini would also be very appreciated
[16:32:28] <rayh> Did we get to the point where we allow more than one ini in a config directory?
[16:32:37] <alex_joni> sure
[16:32:45] <alex_joni> that was the plan all along
[16:32:56] <alex_joni> but on install only one will get copied over I think
[16:33:01] <rayh> and jmk's configurator will make a simlink to the chosen one.
[16:33:02] <alex_joni> or at least only one will be default
[16:33:12] <alex_joni> I think so ..
[16:33:25] <rayh> Okay.
[16:33:32] <alex_joni> right now the old emc.ini is in stepper/stepper_in.ini
[16:33:58] <rayh> okay.
[16:38:41] <rayh> can I commit a whole group of files after I've added them?
[16:39:33] <rayh> sure. I answered my own question.
[16:40:14] <alex_joni> yup.. you can
[16:40:29] <alex_joni> just make sure you don't have other changes you don't want to commit
[16:45:54] <alex_joni> going to take a nap.. was up too late last night
[16:46:00] <alex_joni> and too early up this morning
[16:47:00] <rayh> catch you later
[16:50:12] <SWP_Away> Hiya Ray
[16:50:56] <rayh> Hi SWP_Away. Get some sleep.
[16:51:03] <rayh> ?
[16:51:04] <SWP_Away> already did, thatnks :)
[16:51:07] <SWP_Away> thanks
[16:51:14] <SWP_Away> about 14 hours actually
[16:51:39] <rayh> I mentioned the change to ppmc.c to jmk and he thought you were going to commit it.
[16:51:57] <rayh> brb bread machine is beeping at me.
[16:52:02] <SWP_Away> yep - I think he was in a bad mood last night, so he just said "let JonE deal with it" :)
[16:52:05] <SWP_Away> ok
[16:54:45] <rayh> Okay. So you gonna put the number changes in?
[16:55:04] <SWPadnos> yep - I'll do that. there's another change to make as well though - I'll test that now
[16:56:29] <rayh> k
[16:57:59] <rayh> question for you.
[16:58:04] <SWPadnos> ya
[16:58:36] <rayh> univstep, univpwm, and univppmc will all share a common xx_io.hal
[16:59:02] <SWPadnos> not sure about the ppmc - isn't that a servo driver?
[16:59:10] <SWPadnos> or is that the cage system?
[16:59:22] <rayh> they all look like servo drivers
[16:59:29] <rayh> to emc and hal
[16:59:57] <SWPadnos> the I/O for the USC and UPC are the same
[17:00:37] <SWPadnos> if there's a different board for some other unit (the ppmc), then it might need different IO
[17:00:47] <rayh> Yes. The ppmc is a bit different. It uses 8 IO in any config.
[17:01:01] <rayh> so ppmc is out of this
[17:01:24] <SWPadnos> hmmm. does it only have 8 I/Os (vs the 16 in and 8 out of the USC)?
[17:01:53] <rayh> since io.hal is the only common whole file between upc and usc I suppose separate files is better than one.
[17:02:04] <rayh> directories sorry.
[17:02:12] <rayh> * rayh needs more coffee.
[17:02:13] <SWPadnos> actually, the PPMC I/O card and the PPMC DAC cards aren't supported by the driver at this point
[17:02:27] <SWPadnos> the encoder card is though
[17:02:52] <SWPadnos> at least, it'll get encoders exported if it's detected. I don't know if it'll work ;)
[17:03:17] <rayh> Okay. We leave the ppmc out completely for now.
[17:03:22] <SWPadnos> yep
[17:03:42] <SWPadnos> I think jmk wants jonE to actaully help a bit, so we've got a framework for him to put the code into now
[17:03:53] <rayh> I've got a univstep config about ready to go here.
[17:03:57] <SWPadnos> cool
[17:04:18] <rayh> I'm sure that it is different from jmk's so should I wait.
[17:04:40] <SWPadnos> the config files?
[17:04:55] <SWPadnos> the one you sent me was just about complete - is jmk working on something else?
[17:04:58] <rayh> I'll make all the filenames conform univstep.xx
[17:05:10] <rayh> I think that he said he had one running.
[17:05:14] <SWPadnos> ok
[17:05:57] <SWPadnos> one thing though - the estop interlock isn't there unless you use ladder
[17:06:46] <rayh> I thought I put a loopback in HAL. Let me look.
[17:07:10] <SWPadnos> I know the loopback is there, but I'm not sure that actually "works"
[17:07:46] <SWPadnos> though with the USC/UPC, it'll shut down regardless of what emc thinks anyway
[17:07:59] <rayh> newsig EstopSense bit
[17:08:00] <rayh> newsig EstopWrite bit
[17:08:00] <rayh> linksp EstopSense <= ppmc.0.din.15.in
[17:08:00] <rayh> linksp EstopSense => iocontrol.0.emc-enable-in
[17:08:01] <rayh> linksp EstopWrite <= ppmc.0.dout.07.out
[17:08:01] <rayh> linksp EstopWrite => iocontrol.0.user-enable-out
[17:08:16] <rayh> It loops back based on board pins.
[17:08:19] <SWPadnos> ok - the estop sense will be a little weird then
[17:08:39] <rayh> so it should get out of estop as long as the two jumpers are on the board.
[17:08:42] <SWPadnos> whenever SSR8 is off, input 15 will read "estop"
[17:09:08] <rayh> yep.
[17:09:24] <SWPadnos> so you can't tell the real state of the external estop chain until you try to turn the system on
[17:09:40] <SWPadnos> (which is why jonE says you should connect estop to input 14 as well)
[17:11:51] <SWPadnos> I'm about to commit a change that works for a single board, but may break multiple boards - can you test multiple boards yet?
[17:15:00] <rayh> I don't see that the jumper between 15 and 14 does anything.
[17:15:21] <rayh> Sure. I just have to edit the source to look for the second parport.
[17:15:26] <SWPadnos> it doesn't now, because there's no external estop connected
[17:15:35] <SWPadnos> no - I mean on one parport
[17:15:39] <SWPadnos> by chaining boards
[17:15:45] <rayh> As listed above, the tkemc does display the external estop condition.
[17:16:08] <SWPadnos> hook up a switch and set up halmeter
[17:16:16] <rayh> oh. I don't have the cards nor headers required for such a test.
[17:16:18] <SWPadnos> to look at EstopSense
[17:16:24] <SWPadnos> ok
[17:16:37] <SWPadnos> that's what the jmk change was for (the one I'm reverting)
[17:16:38] <rayh> I can and have tested a usc and upc at the same time
[17:17:04] <SWPadnos> sure - add "cfg=0x378,0x278,0x3bc" to check all 3 ports
[17:17:05] <rayh> on different parports
[17:17:22] <rayh> but how about b400
[17:17:23] <SWPadnos> it seems to pick up the first bus automatically
[17:17:36] <SWPadnos> I was going to try my PCI parallel port card as well
[17:17:47] <rayh> that's what I was using.
[17:17:50] <SWPadnos> I installed the dual PCI parport card ans the m5i20 yesterday
[17:18:01] <SWPadnos> I want to run some I/O benckmarks
[17:18:16] <rayh> Great.
[17:18:30] <SWPadnos> hey - were you running on a PCI parport when jonE had you cut the pin13 wire?
[17:18:40] <rayh> I wonder if you'll have any problems with estop with the dual parport.
[17:18:53] <rayh> It failed both ways.
[17:18:56] <SWPadnos> yes - you can't have multiple writers to the EStopSense pin
[17:18:59] <SWPadnos> ok
[17:19:09] <SWPadnos> you may have a PCI-connected parport in your chipset
[17:19:16] <rayh> but then this is the athalon64 3300
[17:19:26] <SWPadnos> A64 - cool
[17:19:48] <rayh> you could have multiple writers if you use an and or or block.
[17:19:53] <SWPadnos> I'd love to try RTAI on my dual opteron, but the 64-bit and SMP issues are holding me back (ie, I don't know if there are any :) )
[17:19:54] <rayh> Did that and it works fine.
[17:20:06] <SWPadnos> yes, you can combine them with logic
[17:20:22] <SWPadnos> the estop component really should be called a latch
[17:20:26] <rayh> Paul tells me that dual core is a problem for rt.
[17:20:45] <SWPadnos> yes - RTAI has SMP support, but I'm not sure how good it is
[17:21:11] <SWPadnos> if you can control it well, then keeping all RT tasks on one CPU (the one with direct access to I/O) is a good thing
[17:21:11] <rayh> There is a great posibility that rt interrupts happen during the exchange of floats
[17:21:28] <SWPadnos> between CPUs?
[17:21:39] <rayh> Yep that would be my solutions. rt on one proc and user on the other.
[17:21:57] <SWPadnos> floats are an atomic transfer - they're only 32 bits. doubles are either 64 or 80 bits, so they take multiple transfers
[17:21:59] <rayh> but still working both sides of shmem my trash it.
[17:22:09] <rayh> nope they are NOT atomic.
[17:22:21] <rayh> supposed to be but ...
[17:22:27] <SWPadnos> which - floats?
[17:22:38] <rayh> yes.
[17:23:15] <rayh> they are atomic on rt side but rt can interrupt a supposedly atomic in user space.
[17:23:28] <SWPadnos> getting a result from an FPU register to memory isn't atomic (I think you have to transfer it to a normal register first), but the store to memory is atomic
[17:23:43] <rayh> but what do I know of the truth or even comprehension of what I just typed.
[17:23:54] <SWPadnos> so you can't have a half-stored float in memory
[17:23:56] <SWPadnos> heh
[17:24:24] <rayh> I believe this was the problem Paul faced with the 4xx bdi.
[17:24:38] <SWPadnos> doubles are a different story, as I mentioned
[17:24:40] <rayh> and it's eating of stuff far away from emc.
[17:24:46] <SWPadnos> and most everything in emc is a double
[17:24:58] <SWPadnos> but not in HAL
[17:25:04] <cradek> rayh: I don't think that was the problem
[17:25:24] <rayh> I could send a log of my recent conversation with him.
[17:25:49] <cradek> rayh: I'd be interested to see that
[17:25:51] <SWPadnos> I would like to see it sometime - he's asmart guy and the rest of us may be overlooking something
[17:26:21] <rayh> I'll ask him if he minds that I share it.
[17:26:59] <SWPadnos> ok. or even better would be to write a short paper about the trouble, and we can try to come up with solutions (or rebuttals) to the problems he points out
[17:27:27] <rayh> k
[17:27:39] <SWPadnos> in his copious spare time ;)
[17:28:59] <rayh> I want to do a bit more testing before I add univstep to cvs.
[17:29:18] <rayh> I believe that I can reduce ferror and min_ferror more.
[17:29:41] <SWPadnos> hmm - univ_motion.hal is loaded after univ_servo, and it overrides the FF1 parameters
[17:29:55] <SWPadnos> sorry - usc_motion.hal
[17:29:55] <cradek> 0x0804832b <f+3>: mov 0xc(%ebp),%edx
[17:29:55] <cradek> 0x0804832e <f+6>: mov 0x8(%ebp),%eax
[17:29:55] <cradek> 0x08048331 <f+9>: mov %eax,(%edx)
[17:30:19] <rayh> What I saw the other day was ferrors in the e -4,5,6 and settings in the e -2
[17:30:25] <cradek> here's a store to memory in void f(float a, float *m) { *m = a; }
[17:30:33] <cradek> where m is a pointer to a malloced region
[17:30:40] <cradek> it shows that the mov is atomic
[17:30:45] <SWPadnos> yes - that's a float. check a double
[17:30:51] <SWPadnos> (if you don't mind)
[17:30:56] <cradek> but the issue is floats, right?
[17:30:58] <rayh> Yes it does with values from the ini file. I'd like to keep it that way. Would you do something different.
[17:31:13] <SWPadnos> no - I'm pointing out what the hal file does now :)
[17:32:08] <cradek> 0x0804833d <f+21>: mov 0xfffffff8(%ebp),%eax
[17:32:09] <cradek> 0x08048340 <f+24>: mov 0xfffffffc(%ebp),%edx
[17:32:09] <cradek> 0x08048343 <f+27>: mov %eax,(%ecx)
[17:32:09] <cradek> 0x08048345 <f+29>: mov %edx,0x4(%ecx)
[17:32:15] <cradek> double is definitely done in two steps
[17:32:22] <SWPadnos> yep - so I thought
[17:32:28] <cradek> but the issue is floats, right?
[17:32:45] <SWPadnos> actually, another interesting thing to see is what happens if the numbers are in float registers
[17:33:07] <rayh> ah. so we should remove the setp .. FF1 from univstep_motion.hal.
[17:33:19] <SWPadnos> like void f(float a, float b, float *m) {*m= (a*b); }
[17:33:26] <SWPadnos> rayh: yes
[17:33:49] <SWPadnos> cradek: then the same thing with doubles
[17:33:50] <rayh> I was thinking it would be nice if a [AXIS_x]INPUT_SCALE call would fail gracefully.
[17:33:58] <SWPadnos> how do you mean?
[17:37:37] <cradek> I was wrong, a lot of stuff in shmem is doubles
[17:37:49] <cradek> then that might be a problem without locking
[17:38:00] <SWPadnos> yes - the emc structs use doubles almost exclusively
[17:38:07] <cradek> paul kept saying float when he was talking about this, but he must have meant double
[17:38:10] <SWPadnos> but HAL doesn't use them
[17:38:14] <SWPadnos> that may be
[17:39:18] <cradek> but this is irrelevant to the problem where emc was messing up non-rt fp
[17:39:36] <cradek> that was an emc but or miscompilation
[17:39:46] <SWPadnos> yes - that would be an incorrect FSAVE/FRESTOR kind of thing
[17:39:47] <cradek> (something was leaving a value on the fp stack)
[17:39:52] <cradek> right
[17:40:07] <cradek> jepler proved that with his test program
[17:40:17] <SWPadnos> it seems likely that it would be an emc task that wasn't marked as using FP, but that actually did
[17:40:32] <cradek> agreed
[17:40:49] <cradek> he never would say what he did to fix it, except maybe he said he recompiled something
[17:41:00] <cradek> he was very evasive for some reason
[17:41:06] <SWP_Away> there weas a lot of that going on
[17:41:19] <SWP_Away> "I know how to do that, it's easy" full stop.
[17:42:21] <cradek> rayh: if you think he's found serious bugs in the basic emc architecture, I think we should investivate promptly.
[17:45:59] <rayh> phone
[17:47:41] <rayh> Okay. That guy just got his 4th axis running with m5i20.
[17:47:47] <cradek> slick
[17:48:01] <rayh> one more death defying act.
[17:48:17] <cradek> maybe I'll make driver for my rotary axis this weekend
[17:48:19] <rayh> And that guy claims to be the first to implement motion from a PC.
[17:48:29] <SWPadnos> which headers are used on the m5i20?
[17:48:48] <rayh> headers?
[17:49:07] <SWPadnos> yes - the m5i20 has 3 50-pin headers on it
[17:49:17] <rayh> oh yes.
[17:49:36] <rayh> he is using the first header to a 7i33 analog card.
[17:50:05] <SWPadnos> ok - that's the default configuration in the emc driver?
[17:50:14] <SWPadnos> (and FPGA code supplied with emc)
[17:50:19] <rayh> I've got the same here to their pwm motor amp card.
[17:50:34] <rayh> Yes. PeteV was the guy that did all that.
[17:50:40] <SWPadnos> yep
[17:50:57] <rayh> When you start the m5i20 configuration halcmd will show you all the pins.
[17:51:22] <rayh> You only need to watch the led's on the card to see that they all change from red to green.
[17:51:57] <SWPadnos> I think my card only has 8 LEDs on it
[17:52:31] <SWPadnos> and they're on the bottom side of the card (it's plugged into a riser card which is plugged into a motherboard on the back of a touchscreen)
[17:52:32] <rayh> Right. I used a beer coaster (aka dead cd) upside down to watch those.
[17:52:36] <SWPadnos> heh
[17:52:45] <SWPadnos> I've got one or two of those
[17:53:12] <SWPadnos> well - I just completed a run of CDS with the changes hal_ppmc driver
[17:53:44] <SWPadnos> it's quite sensitive to the ini/hal file settings though - it didn't work with the stock univstep config (from CVS last night, I think)
[17:54:21] <SWPadnos> I'm looking at what's different between that and the config that works (basically the one that you sent me)
[18:01:44] <rayh> Is there a stock univstep in cvs?
[18:02:10] <SWPadnos> I think there's something - not sure what state it's in
[18:02:12] <rayh> There should really be no need to change tuning settings for univstep.
[18:02:18] <SWPadnos> (except that it doesn't work ;) )
[18:02:44] <rayh> Right.
[18:02:55] <rayh> * rayh goes looking at sf
[18:04:12] <SWPadnos> this may just be an earlier copy of your stuff -I'm not positive that I got it from cvs
[18:04:32] <rayh> nope no univstep stuff yet.
[18:04:43] <SWPadnos> ok - then it must be me ;)
[18:04:47] <rayh> May have been my earlier tarball to you.
[18:04:52] <SWPadnos> that could be
[18:04:53] <rayh> That did not work.
[18:05:03] <SWPadnos> I'm just looking at the differences - there aren't many
[18:05:32] <rayh> interesting to watch fe trip point and fe on arcs and such.
[18:07:19] <SWPadnos> hmm - do you think I should add a "delta" pin to the encoders?
[18:07:46] <SWPadnos> I did for testing, and it was useful. it's a reasonable representation of velocity as well (at high speeds)
[18:07:52] <rayh> It certainly makes for some fascinating viewing.
[18:08:38] <rayh> I'm thinking a wiki writeup on "how to do delta" would be excellent.
[18:09:18] <SWPadnos> yep - there are a lot of p"probing" options available with the various available blocks
[18:09:29] <rayh> It costs almost nothing in compute power so perhaps we should for all the sample servo systems.
[18:09:34] <SWPadnos> you can do differences by usinga summer block, and setting one input scale to -1
[18:10:25] <rayh> Yes you can...
[18:11:02] <rayh> and then with a few motions we can create an autotune system.
[18:11:34] <rayh> but not for 2.0 release
[18:11:54] <SWPadnos> nope
[18:13:01] <rayh> I see that following error trip point drops off almost instantly when an axis stops
[18:13:24] <SWPadnos> yep - it's using the MIN_FERROR->FERROR formula
[18:13:25] <rayh> but any ringing or overshoot takes a bit to settle.
[18:23:12] <SWPadnos> hmm - you know - that should be a problem
[18:25:10] <SWPadnos> duh - I found the problem with the univstep from before
[18:25:22] <SWPadnos> no - wait, that shouldn't be it
[18:44:39] <rayh> do I need to set the time and tmax params for a sum2?
[18:45:37] <SWPadnos> mope - those are outputs
[18:45:48] <SWPadnos> the TMax is writable so you can reset it o 0
[18:45:51] <SWPadnos> to 0
[18:46:53] <rayh> ah sorry.
[18:51:13] <rayh> perhaps 'nother dumb one. both
[18:51:15] <SWPadnos> those are supposed to be for checking max execution time
[18:51:15] <rayh> 02 float R- 4.05995e-05 axis.0.f-error
[18:51:16] <rayh> 02 float R- 2.22069e-03 axis.0.f-error-lim
[18:51:27] <SWPadnos> also read only
[18:51:34] <SWPadnos> those show the current ferror, and the limit
[18:51:46] <SWPadnos> as it changes with the speed formula
[18:51:46] <rayh> are params and I want to connect them to sum2
[18:51:54] <rayh> Right I got that.
[18:51:55] <SWPadnos> you can't connect params
[18:52:02] <SWPadnos> only pins
[18:52:12] <rayh> I can to either halscope or halmeter.
[18:52:24] <rayh> another big failure of halcmd
[18:52:28] <rayh> ???
[18:52:36] <SWPadnos> no - it's a HAL thing
[18:53:03] <rayh> big failure of HAL???
[18:53:06] <SWPadnos> software can look at pins, params, and signals, but only pins can be connected to signals
[18:53:20] <SWPadnos> no - params aren't meant for lots of updating
[18:53:36] <SWPadnos> they're for settings and status - not "realtime" stuff
[18:54:00] <rayh> keep on with the excuses...
[18:54:06] <rayh> I'm all ears
[18:54:17] <SWPadnos> jmk was considering changing things in emc3 so that there are no params, only pins
[18:55:40] <rayh> the block constant says that it can make a param available on a pin.
[18:55:48] <rayh> how would that work?
[18:56:06] <SWPadnos> yes - you set the param, and the output pin of the constant block has that value
[18:56:22] <SWPadnos> it's a block with no input pins, and one output pin
[18:58:02] <rayh> so it does not track changes in a param only the setp commands to a param?
[18:58:29] <SWPadnos> params don't chenge, except via setp or code which is internal to the component that exports them
[18:59:36] <rayh> changes caused by "code which is internal to the component that exports them" is exactly what I want to watch.
[18:59:52] <rayh> and that is a BIG nfw?
[19:00:22] <rayh> can scope show the diff between signals?
[19:00:48] <SWPadnos> nope
[19:00:55] <SWPadnos> unfortunately
[19:01:48] <rayh> Okay I'll just write this up to a big failure in architecture.
[19:02:20] <SWPadnos> um -you're trying to use testing tools, and you can't look at something - that doesn't sound like a huge failure in the architecture to me
[19:02:45] <SWPadnos> it's an annoyance, but not a major architectural problem
[19:03:24] <SWPadnos> (this is like not having a differential probe for your oscilloscope, then complaining to the manufacturer about not having isolated grounds)
[19:05:07] <SWPadnos> so - try that update, make sure I didn't break anything ;)
[19:05:42] <SWPadnos> gotta run - it's time to clean the garage, so I might have achance of parking indoors this winter :)
[19:06:01] <rayh> thanks steven. I'll test that right away.
[19:06:15] <SWP_Away> cool - I'll be around, and check back from time to time
[21:33:22] <alex_joni> hello
[21:53:56] <alex_joni_> alex_joni_ is now known as alex_joni
[22:14:02] <cradek> who knows if these are bugs:
[22:14:10] <cradek> when you turn machine off, spindle stays running
[22:14:18] <cradek> when you switch to mdi mode, spindle stops
[22:14:54] <cradek> err, manual not mdi
[22:16:48] <SWPadnos> you'd think that the spindle should get shut off when you turn the machine off
[22:17:10] <cradek> it does stop if you hit estop
[22:17:14] <cradek> but not simply machine off
[22:17:15] <SWPadnos> though leaving it running has the advantage that you won't break bits as the machine coasts to a stop
[22:18:15] <cradek> well ESC turns off the spindle and aborts motion both
[22:18:56] <SWPadnos> what is esc in the GUIs?
[22:19:04] <cradek> TASK_ABORT
[22:19:09] <cradek> (stop motion and spindle)
[22:19:10] <SWPadnos> ok
[22:19:38] <SWPadnos> and machine off is MACHINE_OFF or the like (just making sure that the issue is in emc, not the gui)
[22:20:12] <cradek> TASK_SET_STATE(machine off)
[22:20:26] <cradek> there are three states
[22:20:36] <SWPadnos> estop, off , on
[22:20:52] <cradek> the off state might actually be called estop-reset, I don't remember
[22:20:53] <SWPadnos> or estop, ready, on
[22:20:55] <cradek> but yeah
[22:20:57] <SWPadnos> yep
[22:21:40] <cradek> I think it's more strange that switching to AUTO mode turns spindle off
[22:21:50] <SWPadnos> that is a weird one
[22:21:59] <cradek> err manual
[22:22:01] <SWPadnos> do you mean from auto, or any "mode" change
[22:22:03] <SWPadnos> ok
[22:22:10] <cradek> dammit I use axis so I never deal with these stupid modes
[22:22:25] <cradek> hit f3, f4, f5 until I can jog
[22:22:39] <cradek> hit f3, f4, f5 until R works
[22:22:44] <cradek> sorry
[22:22:51] <SWPadnos> so you can go between MDI and auto without affecting the spindle, but switch to manual, and it stops?
[22:22:58] <cradek> let me make sure
[22:23:27] <cradek> yes
[22:23:40] <cradek> going to manual causes EMC_TOOL_ABORT
[22:23:42] <SWPadnos> in tkemc or axis?
[22:23:47] <cradek> any
[22:23:52] <cradek> this is not a gui issue
[22:23:56] <SWPadnos> ok
[22:24:33] <cradek> wonder if I can run emc1... curious
[22:25:02] <SWPadnos> unless you've changed a lot in the last few weeks (when you switched to emc2) I would hope so ;)
[22:25:26] <cradek> I'm at a different machine...
[22:25:31] <SWPadnos> ah
[22:25:36] <SWPadnos> not kernel 2.6, I hope
[22:25:47] <cradek> nope
[22:26:01] <cradek> emc1 does not stop the spindle when switching to manual
[22:26:07] <SWPadnos> ok
[22:26:13] <SWPadnos> then I'd say it's a bug
[22:26:17] <cradek> emc1 does not stop it for estop-reset either, so I guess that's normal
[22:26:21] <cradek> I'll file a report
[22:26:30] <SWPadnos> ok
[22:26:48] <cradek> I wish we had more people actively using emc2 and filing bug reports...
[22:27:00] <cradek> I think I've filed (and fixed) most of the recent ones
[22:27:04] <SWPadnos> I'm sure that will happen after the first release
[22:27:19] <SWPadnos> the sourceforge page really makes it look like a dead project
[22:27:20] <cradek> I'd rather it happened before...
[22:27:31] <cradek> I agree it does
[22:27:36] <SWPadnos> well yeah - maybe a 0.9.9 release would be in order first
[22:27:43] <cradek> alex and I have started using the News items a little more
[22:27:48] <SWPadnos> I saw that
[22:28:08] <SWPadnos> it helps, but there's only one release, everything is hidden behind CVS or the lists
[22:28:40] <cradek> I wanted to put more in the files area, but ran into some disagreement about what should be there (disagreement from the board)
[22:28:54] <SWPadnos> ah - well, you can't have everything ;)
[22:31:55] <cradek> well son of a b****
[22:32:07] <SWPadnos> ??
[22:32:36] <cradek> not only do emc1 and emc2 not have cvs history in common so I can use cvs diff, but someone reformatted all the whitespace
[22:32:52] <SWPadnos> gotta love that - NOT!
[22:37:12] <cradek> I can't immedately spot the change in emctask.cc, assuming it's there
[22:37:43] <cradek> maybe alex will know right away how to fix it