Back
[01:29:56] <jmkasunich> logger-devel: bookmark
[01:30:09] <jmkasunich> logger-devel bookmark
[01:30:18] <jmkasunich> logger_devel bookmark
[01:30:26] <jmkasunich> wtf?
[01:30:32] <jmkasunich> logger_devel, bookmark
[01:30:32] <jmkasunich> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-30#T01-30-32
[01:31:21] <SkunkWorks> thats odd
[02:05:08] <jepler> jmkasunich: next you'll be wanting C++ exception handling in HAL
[02:05:33] <jmkasunich> huh?
[02:05:50] <jmkasunich> oh, the error handling stuff?
[02:06:11] <jmkasunich> I'm just looking at pages and pages of the same 5-6 lines repeated, and wondering if there isn't a better way
[02:06:43] <jmkasunich> even if its "if (functioncall() != SUCCESS ) goto errorhandler;"
[02:08:01] <jmkasunich> btw, how familiar are you with the mega8 thingies?
[02:08:19] <jepler> http://www.nicemice.net/cexcept/
[02:08:38] <jepler> I'm not particularly familiar with mega8. I have been playing with AVRs for a year or two, though.
[02:09:04] <jmkasunich> re the exceptions, I'm not so concerned about errors deep in a call tree
[02:09:12] <jmkasunich> just the size of the code
[02:09:21] <jmkasunich> especially with your new API, one line does the work
[02:09:23] <jepler> you mean how many lines of code there are
[02:09:32] <jepler> not the size of the object file
[02:09:32] <jmkasunich> and 4-5 check for/report errors
[02:09:35] <jmkasunich> right
[02:09:50] <jmkasunich> although there is probably a relation between the two ;-)
[02:10:34] <jmkasunich> a real review of errorhandling would be something for later
[02:11:15] <jepler> there's always the data-driven approach
[02:11:24] <jmkasunich> yeah
[02:12:04] <jmkasunich> you know, the existing error print code won't work with the new api anyway
[02:12:23] <jmkasunich> because it prints the pin name, which isn't availabe outside the new functions
[02:12:29] <jepler> the case I looked at, in hal_parport, didn't use the name in the error message
[02:12:44] <jmkasunich> take a look at blocks.c, its more typical I think
[02:12:47] <jepler> hmm
[02:12:51] <jepler> maybe the new API is no good
[02:13:03] <jmkasunich> I wouldn't go that far
[02:13:15] <jepler> maybe it's not completely baked
[02:13:20] <jmkasunich> what if we had something like errno, only its errstr
[02:13:33] <jmkasunich> and the new api fills it in with a reasonable error message when something fails
[02:14:00] <jmkasunich> then the return can just goto something that prints the string (or not) and cleans up
[02:15:12] <jmkasunich> anyway, I tend to agree with the not completely baked thought
[02:15:24] <jmkasunich> its part way to a cleaner interface
[02:15:49] <jmkasunich> before we change all the components, I'd like to see if we can get farther toward a clean interface
[02:16:08] <jmkasunich> I dunno if data driven is too far or not
[02:16:23] <jmkasunich> even data driven needs to handle errors
[02:17:34] <jepler> "I couldn't register all my pins/parameters" seems like something that will always make a module want to exit.
[02:17:41] <jmkasunich> right
[02:18:05] <jepler> so there's no need for individualized error reporting -> put it in hal_new_pin
[02:18:08] <jmkasunich> I dunno if it is usefull to print the name of the one that failed
[02:19:00] <jmkasunich> oh, you mean put the print inside hal_new_pin....
[02:19:01] <jepler> in one error case (which I'm not sure I checked for) you would: if the name was too big to fit
[02:19:15] <jepler> also if the name was a duplicate, as opposed to an "out of memory" condition
[02:19:31] <jmkasunich> right, and you'd really like to report _why_ it failed
[02:19:44] <jmkasunich> which the pin_new function is certainly more likely to know
[02:20:30] <jmkasunich> error reporting in rtapi/hal probably needs looked at
[02:20:55] <jepler> what wouldn't benefit from being looked at?
[02:21:08] <jmkasunich> in some cases, a module calls hal which calls rtapi, and if the rtapi call fails, rtapi prints a message, then hal prints a message, and then the calling module prints a message
[02:21:25] <jmkasunich> I suppose that could be good or bad depending on your point of view
[02:23:30] <jmkasunich> duh... hal_pin_new already complains if there is a problem
[02:23:52] <jmkasunich> the individual components don't really need to print at all
[02:24:26] <jmkasunich> or at worst, they should all goto a single point that prints a generic "<blockname>: init failed" message and exits
[02:26:09] <jmkasunich> you did check for name too long (or any other vsnprintf error), but you don't print anything if it happens
[02:28:07] <jmkasunich> the reason I was asking about the mega8 (change of subject alert)....
[02:28:25] <jmkasunich> I'm looking at this board and limitations of the parport
[02:28:50] <jmkasunich> (we need 7 inputs, which means we have to run the parport in input mode, and there are only 4 outputs available)
[02:28:57] <jmkasunich> that means no spindle control, for example
[02:29:41] <jmkasunich> and I think "we got this uC, can't it count the pulses, and generate the PWM, and...."
[02:30:53] <jmkasunich> for a lathe you want 3 channels of encoder (X,Z, spindle) and 3 channels of PWM (X, Z, spindle)
[02:31:10] <jmkasunich> plus a few inputs for limit and home switches
[02:32:36] <jmkasunich> * jmkasunich is talking to himself again
[02:32:44] <SkunkWorks> I think cradek was just figuring on using another parport
[02:33:12] <jmkasunich> probably
[02:33:14] <SkunkWorks> but now that he has a uC on it.....
[02:33:37] <SkunkWorks> at what point do you go to a pico type board?
[02:33:56] <jmkasunich> pico is overkill
[02:34:03] <jmkasunich> $200 _without_ the power amps
[02:34:07] <SkunkWorks> thanks by the way for the explaination. very rusty
[02:34:16] <SkunkWorks> more reading for me.
[02:34:30] <jmkasunich> you're welcome
[02:35:05] <SkunkWorks> I mean using the uc for more than just encoder divide by - maybe actual comunication between emc and the encoders/servos/
[02:35:33] <SkunkWorks> but I would assume that would be too much for the one cradek is using.
[02:35:48] <jmkasunich> yeah, I was thinking of something like read 4 bytes: encoder X count, encoder Z count, encoder S count, home/limit/index
[02:36:07] <jmkasunich> and write three bytes, X PWM, Z PWM, S PWM
[02:36:31] <jmkasunich> if you do that every mS, you can handle count rates to 128KHz
[02:36:50] <jmkasunich> (if the AVR code is fast enough)
[02:36:58] <jmkasunich> so I want to think about the AVR code that would be needed
[02:37:48] <SkunkWorks> not much (realy none) experience with embedded up
[02:38:06] <jmkasunich> heh, I don't want to admit how long its been for me
[02:38:13] <jmkasunich> Z80 and 8051 era
[02:38:39] <SkunkWorks> I have one of those kits from best buy :) when I am bored at work I play with it.
[02:38:56] <SkunkWorks> I had some z80 in college
[02:40:03] <jepler> jmkasunich: sorry, I got distracted
[02:40:10] <jmkasunich> s'ok
[02:40:29] <jmkasunich> I found a doc with the avr instructions set, now I'm distracted too
[02:40:53] <jepler> which kit from best buy?
[02:41:02] <SkunkWorks> parralax
[02:41:06] <SkunkWorks> does that sound righ
[02:41:09] <SkunkWorks> right
[02:41:11] <jepler> oh -- the basic stamp people?
[02:41:14] <SkunkWorks> right
[02:41:15] <jepler> I didn't know best buy sold anything like that
[02:41:17] <jmkasunich> wonder how fast of a polling loop I can write that would count 3 encoders and generate 3 PWMs
[02:41:26] <SkunkWorks> radioshack
[02:41:39] <SkunkWorks> I was dissconnected when I corrected my self
[02:42:12] <SkunkWorks> * SkunkWorks phones are on the same freqency as the wireless.
[02:43:10] <SkunkWorks> so emc would send a number in relation to what the uP wanted for pwm output?
[02:43:26] <jmkasunich> not emc itself, this widget would have its own HAL driver
[02:43:31] <jmkasunich> just like the ppmc does
[02:44:29] <SkunkWorks> right - thats what I ment. instead of outputting pwm from freqgen - there would be a hal driver that would output a number in relation to the duty cycle.
[02:44:48] <jmkasunich> yes
[02:45:19] <SkunkWorks> cool
[02:46:56] <SkunkWorks> does anyone have a number for swp? could check up on him?
[02:47:40] <jmkasunich> I just remembered that I have his cell number
[02:47:42] <jmkasunich> calling
[02:48:23] <jmkasunich> no answer
[02:48:35] <jmkasunich> I hate leaving messages, so I didn't
[02:49:35] <SkunkWorks> damn
[02:49:44] <jmkasunich> you want the number?
[02:49:48] <SkunkWorks> thats ok
[02:50:53] <SkunkWorks> I sure he will show up - Just seems odd he hasn't been on for so long. even during vacation I would check in to see what is going on. but that is just me. :)
[02:51:53] <SkunkWorks> jmkasunich: don't know if you got my reply - but thanks.
[02:52:03] <jmkasunich> you're welcome
[02:52:06] <jmkasunich> (got it)
[02:52:13] <SkunkWorks> right
[02:52:27] <SkunkWorks> (about the pm)
[02:52:31] <SkunkWorks> :)
[02:57:01] <cradek> jmkasunich: you're going to make the "simplest servo drive ever" not so simple?
[02:57:39] <jmkasunich> I don't know what I'm doing
[02:58:10] <jmkasunich> simplest ever would have encoder PPR that matches the software count rate
[02:58:35] <jmkasunich> once you add the uC to divide things down, all kinds of other ideas appear
[02:58:41] <cradek> true
[02:59:00] <cradek> the avrs can generate pwm by themselves
[02:59:00] <jmkasunich> jepler already did the simplest ever anyway
[02:59:09] <jmkasunich> even the cheap one?
[02:59:17] <jmkasunich> looking at mega8 data sheet now
[02:59:21] <cradek> I think so, not sure if there are two channels though
[03:00:44] <jmkasunich> I want 3
[03:00:57] <jmkasunich> either X,Y,Z for mill, or X,Z,spindle for lathe
[03:01:02] <jmkasunich> ditto for encoders
[03:01:19] <SkunkWorks> why not 4 then - 3 axis and one spindle - that would almost cover everything.
[03:01:31] <jmkasunich> actually I overlooked something
[03:01:50] <cradek> the mega16/mega32 has a full 4 bytes of IO and is still available as dip
[03:01:51] <jmkasunich> lathe needs 2 PWM and the L298 for axis, and one PWM with an RC filter for spindle
[03:02:10] <jmkasunich> mill needs three channels of L298...
[03:02:27] <cradek> just need another one, no problem they're cheap
[03:03:00] <jmkasunich> yeah, but 4PWM plus 4 encoders starts to get iffy in terms of speed
[03:03:17] <cradek> seems it's easy to run out of cycles even at 16MHz
[03:04:04] <jmkasunich> yestarday (with little real knowledge, I may be over-optimistic) I thought we were at 9 or 10 cycles per encoder
[03:04:19] <jmkasunich> that was to divide, not to count, have to see how they compare
[03:05:05] <cradek> I think it's also possible to run that chip at 20 or even 24 MHz
[03:05:45] <SkunkWorks> night - maybe tomorrow I will be playing with the drive. Might like to look at your hal file cradek. at some point. or jeplers for that matter. (servo etch-o-sketch)
[03:06:38] <cradek> I was using jepler's modified only for pinout
[03:06:47] <jmkasunich> trying to understand addressing modes now
[03:06:59] <SkunkWorks> to get an idea how the connections work with the freqgen
[03:07:40] <SkunkWorks> I see it in the hal pdf but seeing it in a working machine helps :)
[03:07:45] <cradek> right, me too
[03:08:00] <cradek> there's a confusing scale parameter that you have to figure out, but that's the only hard part
[03:08:22] <SkunkWorks> ok - night. Thanks
[03:08:27] <cradek> goodnight
[03:08:28] <jmkasunich> thats right, I keep talking about making a non-confusing pseudo-PWM module, and never actually do it
[03:09:35] <cradek> that would be cool
[03:09:56] <jmkasunich> maybe I should be doing that instead of reading AVR datasheets
[03:11:13] <cradek> so far I've been able to write even timing-critical stuff mostly in C
[03:11:26] <cradek> I wouldn't worry too much about the instruction set
[03:11:50] <jmkasunich> :-P
[03:11:51] <cradek> when I was generating ntsc I inlined just a bit of asm
[03:11:56] <jmkasunich> I count cycles
[03:12:18] <jmkasunich> the entire program I have in mind is a single loop
[03:13:27] <jmkasunich> hmm, SPI
[03:14:51] <jmkasunich> base period = 20uS, servo-period = 1mS, so 50 bits per servo period
[03:15:02] <jmkasunich> not much
[03:16:17] <jmkasunich> could send 50 bits to/from each of 8 AVRs at once, that would be kinda cool
[03:17:16] <cradek> why not use the entire bidir byte and a strobe to send a byte each time? there's plenty of IO on the uc
[03:17:26] <jmkasunich> thats actually what I had in mind
[03:17:40] <jmkasunich> I'm just paging thru the data sheet and I saw the SPI
[03:17:47] <cradek> ah I see
[03:17:53] <jmkasunich> there isn't plenty of IO if you start talking about 4 channels
[03:18:12] <jmkasunich> 8 bits of PWM, 8 bits of encoder, plus at least 1 index
[03:18:13] <cradek> mega16 (dip-40) is still not expensive
[03:18:26] <cradek> with a full 4 bytes of IO
[03:18:31] <jmkasunich> 8 data plus a couple handshake to talk to the PC
[03:18:42] <jmkasunich> thats 3+ ports already
[03:19:15] <cradek> hmm
[03:20:00] <jmkasunich> the real issue comes down to speed
[03:20:18] <jmkasunich> how short can an encoder counter routing and a pwm routine be
[03:20:32] <jmkasunich> and how painfull is it to interleave the PC comms stuff
[03:21:05] <jmkasunich> sample encoder A, check PC, sample encoder B, check PC, sample encoder C, check PC, do PWM A, check PC, etc
[03:21:17] <jmkasunich> total loop time sets the PWM freq and the max encoder count rate
[03:22:19] <jmkasunich> might use interrupts for the PC side instead, but the ISR still needs to be short, because it delays the main loop
[03:22:29] <cradek> yeah
[03:22:35] <cradek> was just thinking about that
[03:22:48] <cradek> it might only read the byte and put it somewhere
[03:23:03] <jmkasunich> if all the key stuff can live in registers then the counting and PWM code can be fast
[03:23:20] <jmkasunich> encoder count would be 8 bits only, the PC would handle overflow/underflow
[03:23:37] <jmkasunich> you need a state variable and the count, per encoder
[03:23:40] <jmkasunich> thats 8 registers
[03:23:45] <jmkasunich> (for 4 chans)
[03:23:55] <cradek> the lpm? instruction is a little slow (lookup in a constant array)
[03:24:13] <jmkasunich> thats something I was trying to look up, but I didn't know what I was looking for
[03:24:32] <jmkasunich> I have an instruction set listing, but its missing some notes
[03:24:52] <jmkasunich> LPM Rd,Z
[03:24:54] <jmkasunich> what is Rd and Z
[03:25:05] <jmkasunich> Rd is a register in the bank of 32, right?
[03:25:16] <cradek> umm
[03:25:18] <jmkasunich> Z is a constant? that won't help
[03:25:50] <jmkasunich> Z is a special register maybe?
[03:25:59] <jmkasunich> yeah, thats it
[03:26:10] <jmkasunich> X, Y, and Z are used for indirect loads and stores
[03:26:17] <jmkasunich> only Z can be used for code space
[03:26:29] <cradek> aha
[03:26:56] <jmkasunich> that means I compute my lookup "key" and then I have to move it to Z before I can do the lookup
[03:29:04] <jmkasunich> LUTs don't need to be in program memory, they could be copied to ram on boot
[03:29:15] <cradek> there's not much ram
[03:29:15] <jmkasunich> but still looks like you need to use X,Y, or Z
[03:29:28] <jmkasunich> LUT for encoder will probalby be 16 bytes
[03:29:32] <jmkasunich> 64 worst case
[03:29:51] <cradek> here's gcc's generated code for the equivalent of a=b[c]
[03:29:58] <cradek> thisdim=PRG_RDB(dim+month);
[03:29:59] <cradek> 632: 80 91 64 00 lds r24, 0x0064
[03:29:59] <cradek> 636: e8 2f mov r30, r24
[03:29:59] <cradek> 638: ff 27 eor r31, r31
[03:29:59] <cradek> 63a: ea 5e subi r30, 0xEA ; 234
[03:30:01] <cradek> 63c: ff 4f sbci r31, 0xFF ; 255
[03:30:03] <cradek> 63e: c8 95 lpm
[03:30:06] <cradek> 640: 80 2d mov r24, r0
[03:30:08] <cradek> 642: 80 93 69 00 sts 0x0069, r24
[03:30:11] <jmkasunich> ewww
[03:30:33] <jmkasunich> I want 2-3 clocks,
[03:34:00] <jmkasunich> duh, X,Y, and Z are simply 6 of the 32 bit general purpose regs
[03:34:19] <jmkasunich> so if Z hi always points at the table, Zlow can be manipulated at will
[03:34:55] <cradek> Z must be r30,r31 looking at the above listing
[03:35:15] <jmkasunich> sounds right
[03:35:31] <cradek> and lpm puts the result in r0
[03:35:53] <cradek> and then it gets stored in ram
[03:36:13] <jmkasunich> lpm is 3 clocks
[03:36:37] <jmkasunich> ld reg, (X) is only 2
[03:36:41] <jmkasunich> so store the table in ram
[03:37:08] <cradek> how much ram does the mega8 have?
[03:37:14] <jmkasunich> 512 I think
[03:37:48] <cradek> ok, that's a ton
[03:38:39] <cradek> no it has 1k
[03:39:27] <jmkasunich> looks like 10 instructions to read the A and B pins, and inc/dec/do-nothing an 8 bit count
[03:39:29] <cradek> the avr I usually use has only 128
[03:40:55] <jmkasunich> 11 clocks
[03:41:23] <jmkasunich> 4 are to read the IO bits, 4 to inc/dec/nothing the count
[03:41:49] <jmkasunich> theres gotta be a faster way
[03:43:08] <cradek> ! units 11/16MHz microsec
[03:43:08] <cradek> * 0.6875
[03:43:30] <cradek> isn't that fast enough?
[03:43:39] <jmkasunich> times 4 channels plus PWM generation and PC comms....
[03:43:51] <cradek> oh pwm
[03:43:53] <jmkasunich> aiming for 100KHz+ count rates here
[03:44:05] <jmkasunich> PWM is probably faster then encoder
[03:44:19] <cradek> the pc does a good job of pwm already
[03:45:20] <jmkasunich> but the PC parport pins are busy doing comms
[03:46:14] <jmkasunich> I wonder if the flags register is one of the general purpose ones
[03:46:31] <jmkasunich> so you can do "skip if bit clear" where "bit" is a flag
[03:46:53] <jmkasunich> duh, you can use branch for that
[03:47:07] <jmkasunich> I thought branch would cost more than skip, but it doesn't
[03:50:48] <cradek> so a one-byte count would be enough?
[03:51:03] <jmkasunich> sure, +/- 128 counts in 1mS
[03:51:34] <cradek> ok I see how that would work
[03:51:35] <jmkasunich> the hal driver would handle extending it to 32 bits
[03:51:54] <cradek> you reset at every read so you're constantly sending deltas?
[03:52:14] <jmkasunich> could do that, or the hal driver could subtract
[03:52:25] <jmkasunich> the latter is probably easier to make foolproof
[03:52:39] <cradek> ok, I get it
[03:52:43] <jmkasunich> actually not sure there'd be much difference
[03:52:48] <cradek> sorry I'm slow, I hadn't thought about this before
[03:53:35] <jmkasunich> PWM is actually very easy, but the direction bit is messy
[03:54:20] <jmkasunich> want to PWM one of two output bits based on the state of a register bit
[03:57:26] <jmkasunich> damn, PWM looks like 10 clocks too
[03:57:40] <jmkasunich> although there seems like more chance of a better way
[03:58:19] <cradek> how many levels of pwm are needed?
[03:58:25] <jmkasunich> dunno
[03:58:43] <jmkasunich> that basically determines the max PWM freq, but nothing else
[03:59:00] <jmkasunich> I'm assuming a 8 bit value that is getting incremented, and each channel of PWM compares to it
[03:59:09] <jmkasunich> if higher, output on, if lower output off
[03:59:12] <cradek> ok
[03:59:29] <jmkasunich> for lower resolution and higher PWM freq, increment by more than 1
[03:59:54] <jmkasunich> there is a single incrementing value that serves all channels, so that overhead is shared
[04:01:48] <jmkasunich> ha, got it down to 7 per channel
[04:02:00] <jmkasunich> plus about 5 overhead
[04:02:33] <jmkasunich> 784=28+5=33 or so for the PWM
[04:02:51] <jmkasunich> 44 for the encoders (not counting index)
[04:03:29] <jmkasunich> the PC interface would also be a state machine
[04:03:59] <jmkasunich> with luck it could be kept to 10-12 clocks
[04:04:08] <jmkasunich> and it really only needs to run once per main loop
[04:04:24] <jmkasunich> so figure 33+44+12 = 89
[04:04:38] <jmkasunich> at 16MHz that is ~5.5uS
[04:04:52] <jmkasunich> not quite 200KHz sample rate for the encoders
[04:05:10] <jmkasunich> only 800Hz PWM if 256 levels
[04:05:53] <jmkasunich> true PWM ain't gonna fly if the base period is 5.5uS
[04:06:17] <jmkasunich> pseudo-PWM like freqgen would be better, but messy to code I think
[04:06:50] <jmkasunich> wonder how many levels are really needed
[04:06:58] <jmkasunich> 256 is almost certainly overkill
[04:07:03] <jmkasunich> 64 would work I suspect
[04:07:12] <jmkasunich> 16 is getting kinda course
[04:07:15] <jmkasunich> coarse even
[04:08:05] <jmkasunich> how much program memory is there again?
[04:08:31] <jmkasunich> 8K
[04:10:31] <jmkasunich> duh, there are 3 hardware PWM channels.....
[04:14:17] <jmkasunich> talking to myself again
[04:14:21] <jmkasunich> after midnight again
[04:14:26] <jmkasunich> sigh
[04:18:46] <jmkasunich> goodnight
[04:24:45] <cradek> ack
[04:24:50] <cradek> still there?
[04:25:00] <cradek> drat
[04:25:22] <cradek> my "rain detector" (flaky net connection) is working again
[12:23:24] <SkunkWorks> logger_devel: bookmark
[12:23:24] <SkunkWorks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-05-30#T12-23-24
[20:28:38] <SkunkWorks> hey steve - you ok?
[20:28:57] <SWPadnos> mostly. just got rear-ended. my trusty van isn't doing so well
[20:29:25] <SkunkWorks> its been a week or two - people where getting worried.
[20:29:39] <SWPadnos> sorry about that.
[20:29:46] <SWPadnos> I was trying to get my LabView peoject done
[20:29:53] <SWPadnos> the only way was to mot run chatzilla ;)
[20:29:55] <SWPadnos> not
[20:30:08] <alex_joni> SWPadnos: we can understand that :D
[20:30:14] <SWPadnos> heh
[20:30:23] <SkunkWorks> also wanted to say - It was nice meeting you at the workshop - didn't get to shake your hand before we left.
[20:30:24] <cradek> crap, sucks about the van
[20:30:43] <SWPadnos> now the project is done, because I can't drive the computer over to the customer site for updates ;)
[20:30:54] <SWPadnos> cradek, yes, it does :(
[20:31:19] <cradek> I hope this is where "I have lots of insurance" comes into play for you
[20:31:21] <SWPadnos> SkunkWorks, yep - good to meet you too. That's 50%+ of the reason I go to these things
[20:31:33] <SWPadnos> lots 'o insurance, but a 10 year old van
[20:31:46] <SWPadnos> right - I was just about to look up book value
[20:32:02] <cradek> insurance on an old car in good shape is the worst deal ever
[20:32:05] <cradek> I feel for you
[20:32:08] <SWPadnos> heh
[20:32:16] <cradek> I got rid of my favorite car ever because of that
[20:32:21] <jepler> SWPadnos: welcome back
[20:32:30] <cradek> (instead of fixing it up at great expense)
[20:32:40] <SWPadnos> it sucks that there's such a financial penalty to using things a long time
[20:32:45] <SWPadnos> thanks jepler
[20:32:46] <cradek> right
[20:32:54] <cradek> and taking care of them
[20:34:14] <SWPadnos> w00t! $4350 value
[20:34:27] <SWPadnos> max
[23:02:26] <jmkasunich> cradek: I just restarted the compile farm after a power outage... is there anything that needs to be restarted on cvs2?
[23:05:19] <jmkasunich> * jmkasunich goes to the grocery, back later
[23:35:10] <cradek> jmkasunich: I don't think so, it should be fine