Back
[00:55:04] <SWPadnos> what's jmk-solo?
[00:56:02] <skunkworks> SWPadnos: your back :)
[00:56:12] <SWPadnos> is it sunburned? :)
[00:56:16] <jmkasunich> the new computer - its in an antek solo case, and I was very uncreative when giving it a hostname
[00:56:21] <SWPadnos> ah - thanks :)
[00:57:08] <SWPadnos> what did you end up with?
[00:57:11] <jmkasunich> intel
[00:57:21] <SWPadnos> single-chip?
[00:57:45] <jmkasunich> E6600, D975XBX2 mobo, 2G ram, 150G WD raptor (10Krpm)
[00:58:06] <jmkasunich> I'm pretty pleased with it
[00:58:09] <SWPadnos> cool. I bet it's a little faster than the athlon
[00:58:31] <jmkasunich> 3-6x faster than this box
[00:58:40] <SWPadnos> nice
[00:58:50] <SWPadnos> is that on one core or two?
[00:59:01] <SWPadnos> or is that a quad?
[00:59:04] <jmkasunich> 2
[00:59:25] <SWPadnos> ah, ok. is the farm moved over there yet?
[01:00:11] <jmkasunich> compiling emc2: old box with VMs idle, 6 mins, with VMs off, 3 mins, new box single threaded (make), 1:20ish, multi-thread (make -j) about 47 seconds
[01:00:16] <jmkasunich> not yet
[01:00:30] <SWPadnos> 47 seconds - interesting
[01:00:34] <SWPadnos> is that after make clean?
[01:00:39] <jmkasunich> yeah
[01:00:58] <jmkasunich> making the sim version, I don't have a RT kernel there
[01:01:00] <SWPadnos> ah, simulator only though, due to the SMP
[01:01:06] <SWPadnos> right - same problem here
[01:01:06] <jmkasunich> its running dapper, with the 686-SMP kernel
[01:01:13] <SWPadnos> ok
[01:01:45] <skunkworks> - you don't know about the smp kernel :)
[01:01:59] <jmkasunich> I also tested an fpga build, went from several minutes to 20 seconds
[01:02:02] <SWPadnos> so the only data point we have for CPU comparisons is that a dual opteron 275 is faster than a single E6600
[01:02:10] <SWPadnos> heh - memory and CPU are *very* beneficial there
[01:02:28] <jmkasunich> what do you get with the 275's?
[01:02:42] <SWPadnos> 20 seconds or so for a full (non-RT) build
[01:03:00] <jmkasunich> wow
[01:03:09] <jmkasunich> I bet mine was cheaper ;-)
[01:03:16] <SWPadnos> no bet
[01:03:18] <SWPadnos> :)
[01:03:22] <SWPadnos> fold
[01:03:29] <jmkasunich> you got the 275's from ebay?
[01:03:33] <SWPadnos> yep
[01:04:03] <SWPadnos> more than tripled the speed relative to the older stepping single-core (slower clock speed) 244's I had
[01:04:14] <jmkasunich> nice
[01:04:14] <SWPadnos> with just the CPU upgrade, no other changes to the system
[01:04:50] <jmkasunich> I've read that the 6600 (2.4GHz) is very overclockable, as in just about every one can to go 3.0GHz with stock cooler and voltage
[01:04:53] <jmkasunich> tempted to try it
[01:05:06] <SWPadnos> I hear the same about the particular stepping Opteron I have - that's why I got it
[01:05:29] <SWPadnos> most of the CCBBE batch gan get over 3 GHz, and this one is rated for 2.2, so that would be a significant boost
[01:05:32] <SWPadnos> s/gan/can/
[01:05:46] <jmkasunich> however, the core2 is new enough that linux driver for the onboard temp sensors isn't in the kernel yet
[01:06:09] <SWPadnos> unless you got very high end memory, you'll prbably be limited by memory speed
[01:06:16] <jmkasunich> so I'd have to build a kernel to be able to measure temp, and I don't want to clock it without doing that
[01:06:22] <SWPadnos> indeed
[01:06:35] <jmkasunich> not so sure about the memory issue. I got DDR2-800
[01:06:39] <SWPadnos> it's interesting to see how often the Opterons are at 1 GHz (the minimum)
[01:07:04] <SWPadnos> DDR2-800 is only 400 MHz, which I think is the bus speed for that CPU
[01:07:08] <jmkasunich> the stock fsb clock is 267, and the memory runs at 3:2, so 400MHz (800 in ddr2)
[01:07:32] <jmkasunich> the cpu multiplier is 9, times 267 gives 2.4Ghz
[01:07:36] <SWPadnos> ok
[01:07:44] <jmkasunich> clockers usually change the memory multiplier to 1:1
[01:08:06] <jmkasunich> if I did that and took the fsb clock to 333, the memory would be loafing, and the cpu would be at 3.0
[01:08:09] <SWPadnos> that means that the memory is already running at full speed, so you'll only get the core speed improvement
[01:08:14] <SWPadnos> right
[01:08:37] <SWPadnos> with the 4M cache (according to a waeb page I just saw), that may be significant anyway
[01:08:41] <jmkasunich> right
[01:09:22] <SWPadnos> skunkworks, what SMP kernel are you referring to? :)
[01:09:27] <jmkasunich> also could tweak the memory timings. since its rated for 400, and I'd be running 333, I could change from 5-5-5-12 to 4-4-4-something without pushing it
[01:09:40] <jmkasunich> cradek built an experimental SMP RT kernel
[01:09:49] <SWPadnos> cool. did it boot? :)
[01:10:05] <jmkasunich> didn't try it on the new box
[01:10:17] <SWPadnos> hmm. did he post the .config anywhere?
[01:10:18] <skunkworks> only for a dual processor motherboard.
[01:10:19] <jmkasunich> it ran on my 2xP3-666 box
[01:10:25] <SWPadnos> nice
[01:10:42] <SWPadnos> unless he specifically changed NR_CPUS, it'll handle up to 32 or so
[01:10:51] <skunkworks> he was hoping it wouls work on a single processor machine but it doesn't seem to.
[01:10:52] <SWPadnos> (or maybe 8 is the normal max)
[01:11:00] <SWPadnos> that's odd, it should
[01:11:15] <skunkworks> something to do with acpi I think
[01:11:45] <SWPadnos> oh, maybe the ACPI data structures aren't the right version or something
[01:12:09] <SWPadnos> I wonder if I should tell M-Tech that their laptop showroom page has "Laptop Sowroom" for the title
[01:12:25] <SWPadnos> I'm not in the market for a sow at the moment ;)
[01:13:00] <skunkworks> where they keep thier laptops is their business ;)
[01:13:17] <SWPadnos> heh
[01:18:22] <skunkworks> works great on a dual 600 penium III.
[01:20:33] <SWPadnos> so, is there a place I can get (a) the SMP kernel or (b) the .config/notes on how to build it?
[01:20:53] <mschuhmacher> http://www.linuxcnc.org/experimental/
[01:21:02] <SWPadnos> thanks
[01:21:17] <SWPadnos> hmm
[01:21:37] <SWPadnos> anyone know if that kernel provides blahblah-magma that emc depends on?
[01:21:56] <skunkworks> you have to build head with the new kernal installed
[01:22:01] <skunkworks> if thats what you mean
[01:22:05] <skunkworks> trunk
[01:22:12] <SWPadnos> ok - I can probably do that :)
[01:22:39] <SWPadnos> I guess if I can boot it, I can get the .config (if he didn't disable that option)
[01:45:29] <elson> hello, everybody!
[01:45:45] <jmkasunich> hi Jon
[01:45:53] <elson> Hello, John.
[01:46:32] <cradek> hi all, fwiw that kernel boots fine on MOST single processor machines (any with local apic)
[01:47:59] <cradek> * cradek just woke up from a nap at the most popular napping spot in the house - on the floor by the window (I can tell because there was a significant pile of cats there)
[01:48:45] <elson> I got another wierd report from Stuart Stevenson that looks like it might tie into the problem I've been having with spindle sync and homing. He reports when he moved his machine with a battery box while EMC was in Estop, he saw the encoder position resetting randomly to zero. This sounds like the opposite of the spindle sync/homing problem, where it was dropping out of index-enable sometimes.
[01:48:46] <skunkworks> do you have carpet face?
[01:49:18] <cradek> nope, I luckily ended up face-side-up
[01:49:23] <elson> carpet face goes away quicker than keyboard face!
[01:49:30] <skunkworks> :)
[01:50:28] <cradek> have you been able to catch index-enable in halscope misbehaving on one of your systems?
[01:52:21] <cradek> http://timeguy.com/cradek-files/emc/axis-limits.png
[01:52:44] <jmkasunich> neat
[01:52:48] <elson> Anyway, I also had a problem here on my Bridgeport, and it duplicated the trouble Stuart had on his machine, with index-enable getting reset without the encoder count clearing. I had this happen 8 times in a row, then it went away! I had halscope running, and the only thing I saw was that when it misbehaved, the index-enable was true for a very short time. The time from home switch close to index pulse should be quite repeatabl
[01:52:49] <elson> e. I believe that SOFTWARE cleared the index-enable HAL pin, not the encoder index pulse.
[01:53:02] <jmkasunich> what software? the driver?
[01:55:37] <elson> I don't know. I have stared at the code of hal_ppmc.c, and I can't see anything wrong there, although the code is a bit convoluted. But, all these different symptoms make me thing another variable has somehow gotten mapped on top of the location where either index-enable is stored in the encoder structure, or a related internal variable associated with it.
[01:56:58] <jmkasunich> so instrument it
[01:57:13] <elson> One thing is I do have some kernel message writes that tell whether index-enable was cleared by the driver (index pulse seen) or cleared through the hal pin (index cancelled). I'm going to turn those writes back on until I get some idea what is going on.
[01:57:35] <cradek> I sympathize - these disappearing problems really suck to diagnose
[01:57:53] <cradek> yeah looks like there are some prints there already
[01:58:10] <jmkasunich> yeah, I was just looking at the code too
[01:59:05] <elson> I was kind of worried when we had a hal signal that is set by one program and cleared by another. Two codes writing to the same place, and a bunch of copying around to keep everybody updated. Is there any other place where this is done with a HAL signal?
[01:59:33] <jmkasunich> there isn't "a bunch of copying around"
[01:59:49] <jmkasunich> the pins are pointers, and they both point to the same place
[02:00:14] <elson> Well, as far as I can tell, hal_ppmc.c has a local variable, index-enable, in its encoder structure.
[02:00:43] <elson> Is that the only instance, or does "motion" have its copy on the "other side"?
[02:00:47] <jmkasunich> hal_bit_t *index_enable; /* enable index pulse to reset encoder count */
[02:00:50] <jmkasunich> pointer!
[02:01:38] <jmkasunich> when you connect two (or more) HAL pins with a signal, what you are doing is setting the pointers associated with those pins so that they all point to memory that is part of the signal
[02:01:38] <elson> Aha! Yes, so that's how this works. So, the real storage location is buried by hal, somewhere.
[02:02:20] <jmkasunich> yes, somewhere = a field in the signal structure, in shared memory
[02:03:00] <elson> Hmmm, I wonder if the other local variables in my driver are all static? That could certianly screw things up if they arent!
[02:03:17] <jmkasunich> what local variables?
[02:03:49] <jmkasunich> any data that needs to last between successive invocations of a HAL function needs to be in the struct
[02:04:26] <jmkasunich> signed long oldreading; /* used to detect overflow / underflow of the counter */
[02:04:27] <jmkasunich> unsigned int indres; /* copy of reset-on-index register bits (only valid on 1st encoder of board)*/
[02:04:30] <jmkasunich> like those
[02:04:32] <elson> There's this struct encoder_t, actually just a typedef.
[02:05:39] <elson> Yes, those, index_enable and indres are the ones I'm concerned about. index_enable is a hal pin, indres is a local copy of a write-only register in the PPMC.
[02:07:00] <jmkasunich> why this?
[02:07:01] <jmkasunich> /* note it only makes sense for one channel to have this
[02:07:01] <jmkasunich> function active at a time, so the code takes a shortcut
[02:07:01] <jmkasunich> and the highest numbered channel takes precedence. */
[02:07:20] <jmkasunich> the hardware can't deal with indexes on two channels at once?
[02:07:28] <elson> That comment is obsolete, referred to my crummy code, and needs to be removed.
[02:08:05] <elson> The hardware is independent, so it COULD handle syncing/homing more than one axis at a time.
[02:08:26] <elson> As long as you were going to set all axes to the same value, like zero.
[02:08:56] <cradek> I don't understand the 'else' on line 1067
[02:08:59] <jmkasunich> the canonical encoder sets to zero on index (if enabled) and the goal of all drivers should be to emulate the canonical encoder
[02:11:41] <jmkasunich> question: what is the hal pin ppmc.0.encoder.00.index?
[02:11:55] <elson> The else on line 1067, if the code is right, is to separately handle the case where encoder-index was turned off by whoever else is tied to that hal pin.
[02:12:42] <jmkasunich> which is something that I believe never happens the way EMC uses the index
[02:12:50] <jmkasunich> that doesn't mean it shouldn't be implemented
[02:12:51] <cradek> do you mean index_enable?
[02:12:57] <elson> the driver keeps a copy of what the encoder-index state was last servo cycle, and does special stuff when it detects a change of state.
[02:13:01] <jmkasunich> it does mean a print should be there to tell you if that code ever runs
[02:13:16] <jmkasunich> cradek: no, I mean index
[02:13:37] <elson> The only time encoder-index might go false other than the driver is an aborted home move.
[02:13:43] <jmkasunich> elson: you mean the state of the actual hardware index input pin?
[02:14:05] <elson> No, the HAL index-en pin.
[02:14:28] <jmkasunich> you are telling me that the HAL pin index is a copy of the previous value of the hal pin index-enable?
[02:14:32] <jmkasunich> why make it a pin?
[02:15:18] <jmkasunich> if its just for internal use, do it the way oldreading and indres are done
[02:15:56] <elson> no, sorry. I have grouped 4 bits together, they are a software copy of what the driver wrote to the hardware (read-only_ register that enables the encoder count to be zeroed by the index pulse.
[02:16:13] <jmkasunich> now I'm really confused
[02:16:28] <cradek> I am too
[02:16:33] <elson> I need to keep a copy anyway, as the register is WRITE_ONLY, not read-only as I mistyped above.
[02:16:49] <cradek> I see .index, .index_enable, .indres, and indextemp all interacting
[02:17:01] <jmkasunich> in encoder_t, there is: hal_bit_t *index; /* output: index flag */
[02:17:13] <jmkasunich> that better NOT be a 4 bit value
[02:17:13] <elson> OK, when the hal pin index-enable is set to true, the driver sets the bit in the hardware to make it happen.
[02:17:23] <jmkasunich> understood
[02:17:58] <elson> No, the 4-bit thing is "unsigned int indres"
[02:18:23] <jmkasunich> sigh.... I was asking about *index, and you answered me talking about the 4 bit thing
[02:18:34] <jmkasunich> now you see why I'm confused?
[02:18:38] <jmkasunich> what is *index?
[02:19:22] <elson> OK, *index reports whether the index pulse has been seen. I'm a little vague on which sense condition this variable picks up.
[02:19:56] <jmkasunich> ok, that seems to be a duplication of what index-enable does
[02:20:07] <jmkasunich> I have a suggestion
[02:20:14] <jmkasunich> all three of us can look at the code
[02:20:17] <elson> There are two things you can sense from the hardware. Whether the index signal is true RIGHT NOW, very unreliable, or whether the leading edge of the index pulse was seen since the last time you checked this register.
[02:20:20] <jmkasunich> how's about we walk thru it
[02:20:42] <elson> I'm looking at it right now, just downloaded a fresh copy from CVS to be sure.
[02:20:46] <jmkasunich> which of those two is "ENCISR"?
[02:21:03] <jmkasunich> indextemp = slot->rd_buf[ENCISR]; /* see if index was seen, clears latches */
[02:21:20] <elson> ENCISR is the index detect latch register.
[02:21:24] <jmkasunich> is that comment accurate? does reading ENCISR actually clear something?
[02:22:06] <elson> Yes, it clears the latch after reading it. So, without moving the encoder, you should never read a 1 there twice in a row.
[02:22:20] <jmkasunich> ok, that comment is deceptive
[02:22:30] <jmkasunich> because that line of code isn't reading the register
[02:22:36] <jmkasunich> its reading a cached value
[02:22:46] <jmkasunich> the latch was reset when the cache was being filled
[02:23:02] <elson> Right, the original read that FILLED the cache did the clearing.
[02:23:06] <jmkasunich> the whole cache concept has issues if reads have side effects, something I was unaware of
[02:23:39] <elson> Right. As long as the cache read-in is only done once, then no problem (I think)
[02:23:48] <jmkasunich> I hope the cache code doesn't read that register twice, if so you could lose an index pulse between the reads
[02:23:52] <jmkasunich> right, what you said ;-)
[02:24:15] <elson> There is still the possibility of losing the index pulse, but it is a very narrow time window.
[02:24:24] <jmkasunich> so, indextemp has all 4 "an index has happened and been latched" bits?
[02:24:51] <jmkasunich> (after running line 1010)
[02:25:22] <elson> Yes, I think that's right.
[02:25:27] <jmkasunich> ok
[02:25:37] <jmkasunich> next we start a loop over the 4 channels
[02:25:49] <jmkasunich> first thing inside the loop is read one channel's position
[02:26:17] <elson> read it, and then sign extend and do rollover calc.
[02:26:22] <jmkasunich> 1017 thru 1023 handles rollover of the 24 bit counter
[02:26:22] <jmkasunich> right
[02:26:30] <jmkasunich> those lines could use some {}
[02:26:44] <jmkasunich> nested if's especially make me nervous without {}
[02:27:10] <elson> Yeah, that's a concern for portablility.
[02:27:22] <jmkasunich> the position code ends at line 1033
[02:27:39] <elson> yes.
[02:28:07] <jmkasunich> you use mask to check an individual "index happened and was latched" big
[02:28:16] <jmkasunich> and write that to the 'index' HAL pin
[02:28:26] <jmkasunich> (line 1035)
[02:29:02] <jmkasunich> does that hardware latch get set on _every_ rising edge of index, or only when enabled?
[02:29:02] <elson> I think I'm assembling bits from all 4 axes into mask.
[02:29:20] <jmkasunich> mask starts out as 1 and gets shifted
[02:29:43] <jmkasunich> you have bits from all axes in indextemp, line 1035 tests ONE of them on each pass thru the loop
[02:30:10] <jmkasunich> mask only ever has 1 bit set
[02:30:12] <elson> The hardware latch [ENCISR] is independent of index-en, it senses any rising edge on the index input.
[02:30:43] <jmkasunich> ok, so basically the HAL pin 'index' is a once-per-rev pulse that lasts for one servo period
[02:30:57] <elson> Where does mask get set to 1?
[02:30:57] <jmkasunich> and is completely independent of anything else
[02:31:10] <jmkasunich> line 997
[02:31:21] <jmkasunich> I hate that practice (initing a var when you declare it)
[02:31:28] <elson> Ahh, see it now.
[02:31:51] <elson> I probably did not write that, then! I don't like it, either.
[02:32:10] <jmkasunich> do you mind if I make some tweaks as we do this walkthru?
[02:32:18] <jmkasunich> like that thing, and some {} on the ifs, etc
[02:32:35] <elson> Does an init on the declaration get performed on ever invocation of the procedure, or just at the first invocation?
[02:32:45] <jmkasunich> every one, if its an auto variable
[02:32:49] <jmkasunich> once only if its static
[02:33:04] <elson> Go ahead! The code is practically impenetrable to my mind as it is!
[02:33:30] <elson> Yeah, that is dangerous, but mask is no declared static.
[02:33:48] <jmkasunich> I just realized I don't want to change that yet- don't want to throw off the line numbering while we are talking
[02:33:48] <jmkasunich> later
[02:34:10] <jmkasunich> ok, we were at line 1035 and 1036
[02:34:16] <jmkasunich> that controls the 'index' hal pin
[02:34:47] <elson> right, just sets the pin true if the index pulse was detected.
[02:34:48] <jmkasunich> I take it that reset on index (load on index) only works in version 2 or higher?
[02:35:05] <elson> Yes.
[02:35:32] <jmkasunich> line 1044 tests the hal index-enable pin
[02:35:41] <elson> Earlier versions LATCHED the count on index, but you couldn't CLEAR the count on index.
[02:36:19] <jmkasunich> you realize that hardware that latches on index can be made to work like clear on index in the driver?
[02:36:22] <elson> Right, and then 1045 detects that the pin has gone true since last look.
[02:36:37] <jmkasunich> 1045 is a bug
[02:36:45] <jmkasunich> no its not, sorry
[02:37:11] <jmkasunich> you're not shifting indres and then storing it back, you are just shifting it, testing bit 0, and discarding the shifted value
[02:37:22] <jmkasunich> thats ok
[02:37:23] <elson> Well, we have both possibilities available. But, the servo loop would have to stop latching the count in software, ie. go open-loop until the index pulse.
[02:37:39] <jmkasunich> confusing, but ok.... why not use the mask like you did a few lines earlier?
[02:37:45] <elson> Hmmm, that sounds important!
[02:38:10] <jmkasunich> no, what is being done is correct, I misread the >>i as >>= i
[02:39:01] <jmkasunich> wait, I confused myself again
[02:39:24] <jmkasunich> indextemp is the hardware saying "there was an index edge"
[02:39:24] <elson> This IS my code, sorry!
[02:39:41] <elson> Yes.
[02:39:54] <jmkasunich> 'indres' is what? it didn't come from the hardware at all
[02:40:27] <elson> It is a local copy of what has been written to the 4-bit "reset axis count on index pluse" register.
[02:41:09] <elson> That reg is write-only, so we have to save a copy of what bits are 1 and 0 so we don't mix them up. Only matters if more than one bit is true at a time.
[02:42:02] <jmkasunich> I understand line 1046, it is setting the relevant bit in indres, which will eventually be written to the hardware
[02:42:19] <jmkasunich> why line 1045? why not just set the indres bit whenever index-enable is true?
[02:42:46] <elson> right - but it is also used to remeber what state index_enable was from last servo cycle.
[02:43:01] <jmkasunich> why do you care?
[02:43:30] <elson> line 1045 makes driver do extra step, making wure 3-byte counter preset register has zero in it.
[02:43:42] <elson> "making sure"
[02:43:46] <jmkasunich> if index-enable is true, set the bit in indres (and in the hardware) to enable latch (reset) on the next index pulse
[02:44:00] <jmkasunich> I was going to question that next ;-)
[02:44:19] <jmkasunich> why not zero that register once at init?
[02:44:32] <elson> Why do I care? Because we need to detect rising edge of index_enable, and external falling edge of same, so we can set hardware to same condition.
[02:44:56] <jmkasunich> set the hardware all the time
[02:45:06] <jmkasunich> (the cache is probably writing to that reg all the time anyway
[02:45:24] <elson> Yes, it always does set the bit to enable the latch to reset the axis counter.
[02:45:45] <jmkasunich> if ( index-enable) then indres |= 1 << i else indres &= ~ (1 << i )
[02:45:53] <elson> Yup, it writes it every cycle, it is in the bit mask.
[02:46:17] <elson> But, the encoder preset reg is not in the write bitmask, so I have to write to it at least once.
[02:46:27] <jmkasunich> ok, we've forked
[02:46:45] <jmkasunich> lets defer the issue of the preset register zeroing, and concentrate on indres
[02:47:00] <jmkasunich> (IRC conversations can fork easily, and get confusing)
[02:47:05] <elson> right, indres could very well be the problem.
[02:47:33] <jmkasunich> if I understand the hardware, the register that indres gets written to controls the resetting (loading actually) of the counter
[02:48:01] <jmkasunich> if bit N is 1, and an index arrives on counter N, counter N gets loaded with the contents of the preload register
[02:48:17] <jmkasunich> if bit N is zero, no loading happens
[02:48:21] <jmkasunich> is that right?
[02:48:21] <elson> Yes. if the bit (one per axis) is one, then when the rising edge of the index pulse is seen, the encoder counter is loaded with the value in the preset reg.
[02:48:51] <elson> if the bit is zero, the encoder counts A-B quadrature counts, and never resets.
[02:48:53] <jmkasunich> ok, then all you really need to do is set the appropriate bit in indres based on whether index-enable is true
[02:49:55] <jmkasunich> I think you want the following, (in this order):
[02:50:01] <elson> Yes, that seems right. And, when another part of the driver detects the index latch had been set, it clears index-enable, and indres bit is cleared.
[02:51:19] <jmkasunich> right
[02:51:48] <jmkasunich> there is a bit of a race there with the simple logic
[02:51:55] <elson> Is any of this code actually WRONG, (I admit it is overly complex)
[02:52:22] <jmkasunich> good point, lets continue the walkthru before we start redesigning it ;-)
[02:52:48] <elson> Well, there are indications that a race may be happening.
[02:52:49] <jmkasunich> what is line 1052?
[02:53:11] <jmkasunich> 1049-1051 clears the preset register
[02:53:31] <jmkasunich> 1052 writes indres to the hardware
[02:53:39] <elson> 1052 writes out the value in indres to the register in the hardware.
[02:53:50] <jmkasunich> you might wind up doing that 4 times then, since its inside the loop
[02:54:03] <jmkasunich> although again, not a bug
[02:54:07] <elson> So, it only does this when it first sees index_enable go true.
[02:54:23] <elson> bad practice, putting this in the loop!
[02:55:31] <jmkasunich> ok, 1046 thru 1053 runs only when index-enable is true and indres is not, and after it runs indres is true, so it won't run again
[02:55:43] <jmkasunich> (when I say "indres", I mean "bit i of indres" )
[02:56:44] <jmkasunich> 1061 thru 1066 runs when index-enable is true and an index pulse has happened
[02:56:49] <jmkasunich> it clears index-enable
[02:56:52] <elson> ENCINDX is NOT in the bit mask!
[02:56:52] <jmkasunich> clears indres
[02:57:04] <jmkasunich> huh?
[02:58:34] <elson> export_encoders sets up to read from ENCCNT0 to ENCISR, I don't see where it writes ANYTHING.
[02:59:28] <jmkasunich> you mean as far as the cache goes?
[03:00:08] <elson> When reading the encoders, you have to give the command to latch the count, but that is not a linear addr sequence, so it is done somewhere with procedure calls.
[03:00:28] <jmkasunich> you are jumping all over the place, and I can't follow you
[03:00:34] <elson> Otherwise, I don't think the cache code has any writes to the encoder part of the board.
[03:01:14] <elson> Sorry, I have the complete schematics/VHDL pretty much in my head, and the general register layout, nobody else could be expected to.
[03:01:41] <jmkasunich> you are talking about the writes of indres to ENCINDX, right?
[03:01:56] <elson> What I was saying is the cached writes do not include ENCINDX, which is derived from variable indres.
[03:02:37] <jmkasunich> writes to ENCINDX don't go thru the cache, lines 1052, 1064, and 1070 write direct to the board
[03:02:48] <elson> Yes.
[03:03:07] <jmkasunich> so therefore the cache doesn't NEED to write anything to the encoder section
[03:03:27] <elson> Other than causing the counts to be latched at the beginning, no.
[03:04:00] <jmkasunich> so why did you yell "ENCINDX is NOT in the bit mask!" in the middle of the conversation?
[03:04:03] <jmkasunich> it confused me (again)
[03:04:04] <elson> And, that's why there's no add_wr_funct in export_encoders
[03:04:47] <elson> Because I discovered that ENCINDX was not being written by the caching mechanism, as you were suggesting. Maybe it should be!
[03:04:57] <jmkasunich> btw, the latch strobing is done in lines 770 thru 775
[03:05:07] <jmkasunich> well, lets keep going
[03:05:13] <elson> OK
[03:05:25] <jmkasunich> I think its not pretty that its written directly, but I don't think (yet) that its wrong
[03:06:03] <elson> OK.
[03:06:36] <jmkasunich> when you read ENCISR and see a 1 in there, that means a rising edge on index has arrived
[03:07:04] <elson> yes.
[03:07:09] <jmkasunich> does it also mean that if the relavant bit in ENCINDX was true, the preload has already happened?
[03:07:54] <elson> it is SUPPOSED to mean that. The preload could happen up to one microsecond later, as the latch is clocked by index, but the encoder counter runs on a 1 MHz clock.
[03:08:32] <jmkasunich> oh, the latch is asynchronous?
[03:08:53] <elson> This is a kind of timing vulnerability, but the IEEE-1284 latency is 800 ns min, and the servo loop is one millisecond, so it should be a RARE event.
[03:09:01] <elson> Yes, the latch is async!
[03:09:29] <elson> Really, not "async', but a different clock domain, in FPGA speak.
[03:09:51] <jmkasunich> is there pulse stretching or anything, to ensure that a 50nS index pulse won't set the latch, but fail to load the counter because it goes away before the counter clock?
[03:11:18] <elson> No, that is another mess. Maybe the index pulse is messier than I think. The index pulse needs to be qualified by being 1 us wide before it clears a glitch filter. So, it COULD set the latch, but not be accepted to load/clear the counter.
[03:11:34] <jmkasunich> actually, we don't want a 50nS index pulse to do anything, but doing half of the desired things is worse than doing all of them
[03:12:24] <elson> YES! The problem is I only want to accept the RISING edge of the index pulse, and not re-zero the counter on a noisy falling edge. That's why all this mess.
[03:12:33] <jmkasunich> that is a noise immunity issue though - unless Stuart is running insanely high PPR and very fast, any _real_ index pulses last a lot more than a microsecond
[03:13:00] <jmkasunich> and as far as we can tell, we've seen this problem on real index pulses, not noise
[03:13:29] <elson> Yes, they should. But, if noisy enough, it could set the latch, but not get through to clear the count until the noise settles down. But, I don't think that is happening.
[03:13:45] <jmkasunich> I agree
[03:13:50] <elson> Yes, it did this 8 times in a row, here, then mysteriously went away!
[03:14:32] <jmkasunich> that sucks
[03:15:06] <jmkasunich> well, after reading thru the code, it seems correct to me
[03:15:15] <elson> Also, he was seeing the count zeroing out when he was in E-stop, so index-enable couldn't be true then. I think this is the flip side, index-enable (or INDXRES) getting set true when it shouldn't.
[03:15:38] <jmkasunich> I'm less than thrilled about the way it is done, but I can't see any actual errors
[03:16:05] <elson> I'm glad you think it is OK, as the complexity boggles me. I was pretty sure it was doing what it needed to do when I got it working in December or so.
[03:16:06] <jmkasunich> what is INDXRES?
[03:16:16] <jmkasunich> I haven't seen that one
[03:16:30] <jmkasunich> do you mean ENCINDX? or is there a third register in the picture
[03:16:58] <jmkasunich> ENCISR = "an index happened", read only ENCINDX = "reset on index", write only
[03:16:58] <elson> Sorry, ENCINDX is the register that enables the clear count on index pulse.
[03:17:05] <jmkasunich> ok
[03:17:16] <elson> Yes.
[03:18:03] <jmkasunich> as long as its non-repeatable, we're kind of up a creek
[03:19:03] <jmkasunich> I'm tempted to redo this section, so that 1) it uses the cache for ENCINDX 2) it writes the proper value (stored in indres) to ENCINDX every time, and 3) it presets the preload register to zero during init
[03:19:11] <elson> Well, my write statements should note if the driver sees the index-en pin going false from outside the driver. If I see that when I get the problem, it probably indicates the PPMC hardware is not failing to clear the count on the index pulse.
[03:20:26] <elson> If you want to dig into it, you are welcome. I can test it here. Since the preload reg isn't used to ever load a non-zero value to the counters, once should be good enough.
[03:20:30] <jmkasunich> one advantage to the existing approach (for debugging) is that most of that code only runs when there is a transition, so you can easily print without flooding the kernel log
[03:21:03] <jmkasunich> If I redo it, I will be setting or clearing the relevant bit in indres every time, based on index-enable, instead of doing edge detection
[03:21:30] <elson> It is not so non-repeatable. The threading demo on the minimill seems to fail quite repeatably. I only have to run it about 3 times to guarantee a failure.
[03:21:50] <jmkasunich> oh, why didn't you say so? ;-)
[03:21:57] <elson> The less states being maintained in odd places, the better!
[03:22:18] <jmkasunich> let me get on this, I'll commit this evenign
[03:22:21] <jmkasunich> evening
[03:22:32] <jmkasunich> dunno how late you will be up to test
[03:23:10] <jmkasunich> do all versions have the preset register?
[03:23:21] <elson> Well, the minimill result is from the NAMES show, I never ran it enough times here to make it fail. It ran about 8 times the first time I set up there, and then for the next 2 days it would go haywire after one or two runs. Restarting EMC fixed it for at least one run.
[03:23:23] <jmkasunich> (so I can always set it to zero, even if not version >= 2)
[03:24:01] <elson> Sure, it is never used except maybe at initial startup on earlier versions.
[03:24:20] <jmkasunich> you are confusing me again.... first you said " I only have to run it about 3 times to guarantee a failure."
[03:24:33] <jmkasunich> then you said "oh, that was at NAMES, I haven't had a failure here"
[03:25:14] <jmkasunich> do you or do you not have something set up right now that can demonstrate the failure
[03:25:23] <jmkasunich> (even if only once in 10 tries)
[03:26:52] <jmkasunich> heh, it looks like the preload register is already being zeroed during startup
[03:27:30] <elson> Sorry, I can't explain this intermittent stuff. I never ran the threading.ngc program enough in one EMC startup here at home to see the failure. I kept resterting EMC to change some setting, config, whatever. At NAMES, I was just standing there hitting run everytime it ended. First day, it ran 8 times, I think, then started failing to sync to the spindle after one or at most 2 runs. Restarting EMC got me one good run for sure
[03:27:30] <elson> . Also, if it was going to fail, it failed on the first spindle sync of the program run.
[03:27:34] <jmkasunich> line 2018 (or thereabouts, I think I might have added a line or two)
[03:28:16] <elson> Yes, I believe the minimill setup will demonstrate the failure mode. I will test this to be sure before any software change is attempted.
[03:28:23] <jmkasunich> ok
[03:29:37] <elson> OK, yes, 2018 does the clear the preset reg. in exort_encoders.
[03:30:23] <jmkasunich> can you think of any case where somebody would use "read-all" but not "write-all"
[03:30:43] <jmkasunich> I guess if all they want to use is the encoders, they might say "why do I have to call that function?"
[03:30:45] <elson> When I say failing to sync to the spindle, I saw index-en go false, but the encoder-position kept counting up.
[03:31:23] <jmkasunich> read_all reads from EPP into cache, then calls things like read-encoder, it never writes back from cache
[03:31:35] <jmkasunich> write-all calls functions, then writes from cache to EPP
[03:31:54] <jmkasunich> it might make sense to put the handling of index-enable -> ENCINDX in write-all
[03:32:02] <elson> I think the driver needs to be used as designed, and you probably need to call both functions.
[03:32:09] <jmkasunich> agreed
[03:32:39] <elson> Hmmm, there definitely are some things that are sequence-dependent.
[03:34:20] <elson> I'm not sure that the index stuff is, but there are some real nasty sequence-dependencies in the way to come out of E-stop. Even the execution order of the HAL components needs to be just right, or it forms a loop.
[03:34:51] <jmkasunich> yeah, addf's need to be in the proper order
[03:35:04] <jmkasunich> read, process, write
[03:38:32] <elson> Well, I appreciate your looking into this, even going over the code has been helpful, as my memory of what it did was fading. I need to see what the family is up to, but I'll keep an eye on the IRC. Thanks again!
[03:38:44] <jmkasunich> you're welcome
[03:39:07] <elson> If you get something you think is ready to try, let me know.
[03:39:28] <SWPadnos> hmm. I wasn't following along during the discussion (though I did read it all) - it sounds like no "definite bug" was found
[03:39:41] <SWPadnos> just some "could be done better ways" situations
[03:39:55] <jmkasunich> right
[03:41:26] <cradek> I think SWPadnos is thinking the same thing I am
[03:41:42] <SWPadnos> hmmm. I'm not sure SWPadnos is thinking at the moment ;)
[03:41:59] <SWPadnos> could be the same, I suppos
[03:42:01] <SWPadnos> e
[03:42:29] <SWPadnos> oh, I tried booting the SMP kernel on my Opteron - didn't boot
[03:42:59] <SWPadnos> it complained about a buggy BIOS, and some info area not protected by e820
[03:44:47] <cradek> hey I have a tool length probe!
[03:45:01] <SWPadnos> that sounds like a spam subject line :)
[03:46:54] <jmkasunich> I think I might have stumbled on something about the ppmc issue, maybe
[03:47:04] <SWPadnos> excellent (maybe)
[03:47:07] <jmkasunich> the handling of index-enable was done in the encoder read function
[03:47:15] <jmkasunich> but that runs before the motion controller
[03:47:26] <jmkasunich> so, in one run of the thread, motmod sets index-enable
[03:47:38] <jmkasunich> and absolutely nothing is done with it
[03:47:55] <jmkasunich> in the next run, the driver sees it set, and arms the hardware to detect the index
[03:48:21] <jmkasunich> sometime later, the hardware sees an index and does its thing
[03:48:38] <jmkasunich> in the next run, the driver sees the hardware latch set and clears index-enable
[03:48:57] <jmkasunich> I guess thats not a problem, it just adds one servo period of lag to index-enable
[03:49:08] <jmkasunich> in any case, this change will fix that
[03:49:14] <SWPadnos> plus the actual index lag, which will in most cases be much larger
[03:49:35] <jmkasunich> motmod sets index-enable, the driver write funct sees that and arms the hardware right away
[03:50:30] <SWPadnos> ok, if the write can logically be decoupled from the read (which it seems it can), then enabling in the same thread run as motmod asks for it is good
[03:51:09] <SWPadnos> it's definitely important to let motmod know that an index has occurred in the same period in which it's detected, so the current mode is the lesser of evils, at worst (IMO)
[03:51:41] <jmkasunich> the read function will still be the one that notices that the hardware latch has tripped, and clears index-enable
[03:54:47] <jmkasunich> I hate the C " foo ? a : b " statement
[03:55:16] <jmkasunich> mostly cause I never use it, and when I see it I can't remember the details
[03:55:25] <SWPadnos> heh
[03:55:29] <jmkasunich> if foo is non-zero, then it returns a, else b, right?
[03:55:44] <SWPadnos> if foo then a else b
[03:55:51] <SWPadnos> so yes, that's how it works
[03:55:55] <jmkasunich> thanks
[03:56:11] <SWPadnos> it used to generate more efficient code, but that's questionable these days
[03:57:41] <jmkasunich> ((indextemp & mask) == mask) is a bit redundant
[03:57:50] <SWPadnos> no pun intended ;)
[03:57:51] <jmkasunich> (mask is a single bit)
[03:58:16] <jmkasunich> lol, I didn't even realize that...
[03:58:21] <SWPadnos> heh
[03:58:34] <SWPadnos> odd - make clean still re-runs configure
[04:09:24] <cradek> yuck, joint following errors while probing
[04:09:51] <jmkasunich> la la la la la I can't hear you la la la la
[04:09:52] <SWPadnos> yuck as in "things don't get cleaned up correctly"?
[04:09:57] <cradek> haha
[04:10:21] <cradek> yuck as in we've got a bug and it's probably gonna suck
[04:10:38] <jmkasunich> when does it happen
[04:10:43] <jmkasunich> when the probe hits?
[04:12:10] <cradek> still trying to figure that out
[04:12:53] <cradek> after I hit the probe, and I move up
[04:14:32] <cradek> using relative coordinates
[04:15:11] <cradek> relax, looks like it's in task
[04:15:25] <jmkasunich> ;-)
[04:15:44] <cradek> http://sourceforge.net/tracker/index.php?func=detail&aid=1703238&group_id=6744&atid=106744
[04:15:54] <cradek> I suspect it's this bug or extremely near it
[04:17:34] <cradek> heh, I "fixed" it with g91g0z0
[04:18:01] <jmkasunich> dammit, CIA is slacking
[04:18:20] <cradek> yeah it has been all day
[04:18:48] <jmkasunich> well, I removed 45 lines and added 45 lines
[04:19:02] <jmkasunich> I like to believe the ones I added are nicer than the ones I took out ;-)
[04:19:51] <jmkasunich> elson: modifications committed
[04:19:57] <jmkasunich> I think its simpler and cleaner now
[04:20:22] <SWPadnos> doesn't the write_encoders function need to be added to the hal file(s)?
[04:20:25] <jmkasunich> it may or may not fix anything, but I'm pretty sure I didn't introduce any new bugs
[04:20:49] <jmkasunich> nope, ppmc has read-all and write-all
[04:21:15] <jmkasunich> because they use the parallel port in EPP mode for comms, you can't mix and match functions anyway
[04:21:17] <SWPadnos> oh right - qdd_{rd,wr{_funct are ppmc-local functions, for the reader/writer lists
[04:21:31] <SWPadnos> add, that was
[04:22:30] <jmkasunich> elson: the write function looks at HAL pin 'index-enable' and updates indres accordingly, then writes it to hardware
[04:23:09] <jmkasunich> the read function looks at ENCISR and indres and if an index pulse happened, AND we were waiting for one (indres) then it clears index-enable
[04:24:20] <jmkasunich> elson: let me know what you find when you test it
[04:24:27] <jmkasunich> time for sleep
[04:26:45] <SWPadnos> cradek, which RT patches did you use to build that smp kernel?
[04:26:55] <cradek> the recent release 3.5
[04:27:07] <SWPadnos> from gna.org?
[04:27:39] <cradek> no, the release from the front page of rtai.org
[04:27:44] <SWPadnos> ok, thanks
[04:28:16] <cradek> well kick ass
[04:28:23] <SWPadnos> ouch!
[04:28:34] <cradek> I just did a tool change with length offset set by the probe switch
[04:28:40] <jmkasunich> yay
[04:28:41] <SWPadnos> nice!
[04:28:55] <jmkasunich> dija figure out the following error? or work around it?
[04:29:12] <cradek> it moves down to the switch fast, then backs off a bit and refines the position going slower
[04:29:16] <cradek> just like homing
[04:29:32] <cradek> I worked around it with g91g0z0 after each probe move
[04:30:03] <jmkasunich> you coded the moves (fast, backoff, slow) in g-code?
[04:30:05] <cradek> after all, if you're already where you're going, it doesn't matter how fast you get there
[04:30:14] <cradek> yes it's all in gcode
[04:30:19] <jmkasunich> nice
[04:30:30] <jmkasunich> I wonder if we could do homing that way then?
[04:30:41] <cradek> that simple change I made allowed it all to be done in gcode
[04:30:45] <jmkasunich> give people more ability to tweak it to their needs
[04:30:58] <cradek> not sure if I like that, but 'possible' is better than not possible
[04:31:23] <SWPadnos> it would allow for arbitrarily complex homing schemes, plus special multi-axis homing stuff
[04:31:24] <jmkasunich> well, its late and I don't want to talk about it tonight
[04:31:31] <cradek> goodnight
[04:31:37] <cradek> I can go to bed now too - I saw it work once
[04:31:44] <SWPadnos> heh
[04:31:46] <jmkasunich> what you said about "just like homing" made the thought pop into my head
[04:31:46] <SWPadnos> hight guys
[04:31:52] <jmkasunich> we'll see if its still there tomorrow
[04:31:55] <SWPadnos> night, not hight :)
[04:32:05] <jmkasunich> goodnight
[04:32:54] <jmkasunich> except...
[04:33:07] <jmkasunich> I just realized I never restarted the compile farm after my reboot yesterday
[04:33:33] <SWPadnos> that's why your responses have been so fast tonight ;)
[04:34:26] <jmkasunich> unfortunately thats about to change - 4 full builds coming up
[04:35:18] <cradek> my workaround gives me a clue about an easy way to fix that bug - just send a move to the current position, let it use up its wrong velocity on that, and everything is normal again afterward
[04:35:53] <cradek> (and the new display of limits is cool)
[04:35:54] <SWPadnos> err
[04:36:45] <SWPadnos> so you're thinking the problem is that the switch "suddenly" tells task to stop motion (like estop, except we care about position), and the decel causes the position to go beyond FERROR?
[04:36:52] <jmkasunich> I wonder what the limits display looks like for a scara?
[04:37:00] <cradek> jmkasunich: SHHH
[04:37:04] <SWPadnos> heh
[04:37:12] <cradek> SWPadnos: no, read this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1703238&group_id=6744&atid=106744
[04:37:28] <cradek> I think it's the same problem
[04:37:43] <SWPadnos> ah
[04:38:35] <SWPadnos> "rin from line" should probably be rethought anyway
[04:38:39] <SWPadnos> run
[04:38:51] <cradek> it's problematic in many ways
[04:39:20] <SWPadnos> all it needs to do is collect endpoints and modal settings, then issue all of the modes at once after parsing the whole file
[04:39:45] <SWPadnos> the endpoints are only needed so they can be used to set modal things, like coordinate systems
[04:40:07] <SWPadnos> since they're immaterial for any motion command (as pointed out in that bug report)
[04:40:51] <SWPadnos> of course, run-from-line can be problematic if the line is an arc ...
[04:41:02] <cradek> yes, and it is - try it sometime
[04:41:02] <SWPadnos> err - the line to be executed is an arc command
[04:41:16] <SWPadnos> don't need to try - I think it's bad, therefore it is :)
[04:41:30] <cradek> it makes some beautiful and surprising arcs
[04:41:35] <SWPadnos> heh
[04:41:43] <cradek> sweeping, glorious arcs
[04:41:49] <jmkasunich> or if tool radius comp is supposed to be on at that line, or a crapload of other things
[04:41:55] <SWPadnos> or gives annoying errors, depending on the center mode
[04:41:58] <SWPadnos> yep
[04:42:10] <cradek> yes, crapload is right
[04:42:46] <SWPadnos> I wonder if it makes sense to do a linear move to the previous motion line's endpoint before executing the run-from line
[04:43:11] <jmkasunich> hard to say
[04:43:21] <SWPadnos> yeah, it probably makes sense in some cases and not in others
[04:43:32] <jmkasunich> I bet one use of run-from-line is to pick up where you left off after replacing a broken tool or such
[04:43:50] <jmkasunich> that linear move might be thru the material if you don't choose the position wisely before telling it to run
[04:44:08] <cradek> I think if you use RFL you better think it through and know what you're doing
[04:44:17] <cradek> other than that advice, I don't know how we can really improve it
[04:44:26] <SWPadnos> true, though "repositioning" to the start of that line causes the entire line to be run, rather than something else that ends up at the same endpoint
[04:44:55] <cradek> SWPadnos: if only you knew how to get there...
[04:45:09] <SWPadnos> straight line - crank the spindle if you have to! ;)
[04:46:33] <jmkasunich> ok, farm is running, now I really am going to bed!
[04:46:54] <SWPadnos> good night. see you later
[12:35:01] <skunkworks> logger_dev: bookmark
[12:35:02] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-05-01.txt
[12:49:42] <skunkworks> hey ray :)
[12:55:26] <rayh> How you doing today?
[12:57:20] <skunkworks> so far so good
[12:57:46] <rayh> That sounds iffy?
[12:58:35] <skunkworks> too early to tell ;)
[12:58:50] <rayh> I know the feeling.
[13:08:32] <skunkworks> cradek: what kind of repeatablility did you get out of your switch? was it a microswitch?
[13:11:06] <jepler> cradek: nice new feature -- now make it work for nontrivial kinematics :-P
[13:16:46] <cradek> skunkworks: surprisingly, it seemed like about .0008, from a plain old lever microswitch with the lever still on
[13:18:03] <cradek> hi ray
[13:18:18] <rayh> Hi Chris
[13:18:45] <skunkworks> cradek: cool ;)
[13:19:31] <cradek> skunkworks: I don't know if I even intend to use it, I was just testing mostly
[13:20:09] <skunkworks> you have preset tooling. I think others will use it. :)
[13:28:42] <rayh> Several of the tool measuring systems I know of average several presses of the switch.
[13:46:54] <cradek> skunkworks: for drill bits (jacobs chuck) it could be useful to me
[13:49:32] <skunkworks> I bet. For our gantry it would work great. (almost thinking of setting it up to do the circuit boards)
[13:49:53] <cradek> does that just have a collet and loose tools?
[13:50:08] <skunkworks> yah - like a rotozip.
[13:50:30] <cradek> how were you doing it previously?
[13:50:40] <skunkworks> measuring it each time off the table.
[13:51:14] <skunkworks> then setting z acordingly.
[13:51:19] <cradek> bleah
[13:51:24] <skunkworks> yep
[13:51:39] <cradek> sometimes I have 4-5 drill sizes on a pcb
[13:52:14] <skunkworks> yah - I just drill them all the smallest size - then drill them to the correct size by hand in the drill press :O
[13:52:29] <cradek> yep I've done that too
[13:52:47] <cradek> it's sure a lot easier to drill by hand when there's already a hole there
[13:53:01] <skunkworks> exactly
[13:53:33] <skunkworks> but using a microswitch to set the tool - I might actually drill them on the gantry ;)
[13:53:57] <jepler> seems like .0008 would be plenty of accuracy for drilling circuit boards
[13:54:14] <cradek> I always seem to break drills when I drill by hand.
[13:54:29] <jepler> (in Z)
[13:54:55] <skunkworks> cradek: I break more than I would like to admit.
[13:55:08] <skunkworks> (drilling by hand)
[13:55:30] <tomp> are the boards flat within .0008" ?
[13:56:15] <cradek> tomp: only if you tape them down flat - clamping is hopeless
[13:56:22] <tomp> :)
[13:56:26] <skunkworks> I use a vacumm table.
[13:56:35] <tomp> big boards
[13:56:59] <cradek> a vacuum table is one of the first things I'd make if I got a full size mill...
[13:57:04] <cradek> if/when?
[13:57:09] <skunkworks> when
[13:57:33] <skunkworks> http://www.electronicsam.com/images/KandT/vactop.JPG
[13:57:47] <skunkworks> http://www.electronicsam.com/images/KandT/vacback.JPG
[13:58:12] <skunkworks> I had to face the top of the maple off - so it was flat enough
[13:59:13] <cradek> man I need to do that
[13:59:28] <cradek> I even have a vacuum pump (that I think might work)
[13:59:40] <skunkworks> (scrap maple dieboard from our laser)
[13:59:44] <cradek> but unfortunately it's 3x the size of my mill...
[13:59:51] <cradek> what do you use for a pump?
[14:00:08] <cradek> how do you cover the holes that aren't covered?
[14:00:09] <skunkworks> it is millitary 1hp vane pump. works great
[14:00:38] <skunkworks> cradek: plastic and duct tape.
[14:01:07] <skunkworks> we had gotten a few surplus - sealed and everything.
[14:01:45] <tomp> cnc clamps... you can program them to move after you drill one area ;)
[14:02:12] <jepler> hah
[14:02:39] <skunkworks> or train a mouse to hold it down.
[14:03:13] <skunkworks> trane
[14:03:26] <skunkworks> one or the other.
[14:03:38] <cradek> you had it right
[14:04:45] <skunkworks> trane makes air conditioners
[14:08:53] <tomp> we used vac tables to work thin pieces of graphite, but also 'hold downs' on magnetic chucks,
[14:09:02] <tomp> thin strips of metal like a machinist's ruler with the groove, but bent at a slight angle lengthwise. place one on each side of non-ferrous item,
[14:09:08] <tomp> apply magnet power, and the angled edges would clamp the thin side of the non-magnetic item enough to grind on.
[14:09:09] <tomp> We'd make em out of heavy banding strap, grinding a thin web 1/32 wide for the length on each side, making a 'living hinge'
[14:09:46] <skunkworks> cool.
[14:10:04] <cradek> neat idea, I'll remember it
[14:10:11] <skunkworks> But with circuit board - I tried to hold it by the edge - the center would be up.
[14:10:39] <cradek> yeah that just doesn't work
[14:10:49] <cradek> no matter how you bend the pcbs they're never flat
[14:10:55] <skunkworks> exactly
[14:10:56] <cradek> vacuum or tape is the only way
[14:11:22] <tomp> you likely dont want to drill into your mag chuck anyway :)
[14:11:37] <skunkworks> they make offical circuit board routers that have a foot that pushes down the board where the spinle is
[14:11:47] <skunkworks> spindle
[14:12:43] <jepler> ARGH. when petev removed the vhdl source from e.g., src/hal/drivers/m5i20/countere.vhd and anders put new source at /emc2/src/hal/drivers/m5i20/hostmot5_src/, we switched from files with GPL notice blocks to files without
[14:13:02] <cradek> oh good grief
[14:20:58] <cradek> wonder if FO should be ignored or capped for probe moves
[14:22:31] <jepler> ugh
[14:22:32] <jepler> no
[14:22:40] <jepler> don't open that ball of worms
[14:22:42] <jepler> can
[14:23:19] <cradek> I already did (for homing)
[14:23:23] <cradek> same problem
[14:24:25] <jepler> ARGH
[14:24:27] <jepler> I hate lyx
[14:24:36] <jepler> it is the worst document preparation system, except for all the rest
[14:24:51] <cradek> you'll get no argument from me
[14:24:55] <jepler> the source says: comp --install rtexample.comp
[14:24:59] <jepler> the HTML says: comp -install rtexample.comp
[14:25:32] <cradek> magic em-dash?
[14:26:05] <jepler> or something
[14:29:07] <jepler> for(i=3; i>0; i-) out(i) = out(i-1);
[14:29:42] <jepler> thanks lyx
[14:30:46] <cradek> the latex output is wrong?
[14:32:01] <jepler> not sure
[14:32:06] <jepler> haven't looked at pdf docs yet either
[14:33:47] <jepler> it's right in pdf
[14:34:03] <jepler> I think the pdf output also goes via latex
[14:36:24] <jepler> \begin{lyxcode}
[14:36:24] <jepler> comp~-{}-install~rtexample.comp
[14:37:14] <cradek> is it a latex 'feature'?
[14:38:25] <jepler> dunno -- obviously, \begin{lyxcode} isn't vanilla latex
[14:39:11] <jepler> but {} sounds familar as a way to avoid special interpretation of the two characters that would have been together otherwise
[14:39:16] <cradek> yes
[14:39:16] <jepler> ~ must just be a spacing character
[14:41:05] <jepler> it's a latex2html bugger
[14:41:17] <jepler> this document: \documentclass{letter}\begin{document}-{}-\end{document}
[14:41:19] <cradek> jepler: is the updated gcode quickref available on the web? I know it's in cvs (and an old version is on unpy)
[14:41:29] <jepler> appears as two dash characters in the dvi but a single dash in the html
[14:41:40] <jepler> latex2html is the worst document conversion software for latex, except for all the rest
[14:41:40] <cradek> latex2html strikes again
[14:41:57] <jepler> cradek: yes
http://linuxcnc.org/docs/devel/html/gcode.html and
http://linuxcnc.org/docs/2.1/html/gcode.html
[14:42:29] <cradek> great thanks, I see that it's automagically updated too
[14:43:01] <cradek> you might want to take down yours, or make it a pointer - iirc it has at least one error
[14:43:03] <jepler> yes, I have a cron job that runs several times a day to do that
[14:43:08] <jepler> yes indeed
[14:43:27] <cradek> (I think google finds yours)
[14:43:39] <cradek> I think google is afraid of linuxcnc.org for reasons I don't understand
[14:46:40] <jepler> OK, redirect added to
http://axis.unpy.net/files/gcode.html
[14:46:49] <cradek> thanks
[15:36:39] <jepler> cradek: for nontrivial machines, I'm thinking it's a mistake for getStraightVelocity to refer to AXIS_MAX_VELOCITY[x] because those are actually joint velocities.
[15:37:07] <cradek> that's definitely true
[15:37:25] <SWPadnos> kinematics modules should have vel and acc functions, in addition to position
[15:38:13] <SWPadnos> and/or functions to check the validity of a move over its entire length
[15:38:16] <jepler> yes, but failing that the next best thing is to not erroneously impose the joint 0 max speed in degrees per second to axis 0 as though it was mm/second
[15:38:25] <SWPadnos> indeed :)
[15:44:49] <jepler> there's no MAX_ANGULAR_ACCELERATION?
[15:51:02] <skunkworks> so.. If you have a robot arm - I assume you setup the acceleration for each physical joint. Now does it take into acount when on physical joint is accelerating the opposite way as another physical joint wouldn't the affective acceleration be more than the limit the individal joint was set to?
[15:51:08] <skunkworks> or am I thinking to far into this?
[15:53:54] <jepler> it is difficult to figure out the actual maximum linear velocity for a particular move when you are using a machine with nontrivial kinematics
[15:54:35] <jepler> as you point out, sometimes two joints are working together and sometimes they are working at cross pruposes, even for a simple move along one axis
[15:57:42] <jepler> my goal is to do something simpler than solving that problem (which actually would have to be solved for each kinematics type, since they are governed by different equations) -- not incorrectly apply joint limits to axes. but even that looks like more work than I thought when I started, because the numbers I want don't even seem to be in the inifile
[15:59:08] <skunkworks> ew
[15:59:56] <skunkworks> woo hoo - my 2 256mb ram came in for my portable. the stupid thing maxes out at 512. that is for a 1.7ghz
[16:00:47] <jepler> 512 is fine for most purposes
[16:01:06] <skunkworks> yah - considering I have been puting up with 256 ;)
[16:01:16] <skunkworks> for around 5 years
[16:01:20] <skunkworks> biab
[16:30:18] <cradek> If the probe trips, the probe is retracted slightly from the trip point at the end of command execution. If the probe does not trip even after overshooting the programmed point slightly, an error is signalled.
[16:30:23] <cradek> </ngc>
[16:30:32] <cradek> does anyone else wonder what "slightly" means?
[16:30:41] <SWPadnos> "a little" ?
[16:30:58] <jepler> I assume it's like moving off the home switch in the homing sequence: enough that the probe is now open when the probing move ends
[16:31:08] <jepler> otherwise, the subsequent G0 move would fault, because it begins with the probe closed
[16:31:14] <jepler> (or whatever kind of move it is
[16:31:14] <jepler> )
[16:31:22] <cradek> moves don't fault if they start with the probe closed
[16:31:31] <cradek> well probe should (I wonder if it does)
[16:31:32] <SWPadnos> probe moves do
[16:31:37] <SWPadnos> right - should
[16:32:19] <cradek> nope it doesn't
[16:32:23] <jepler> I thought probe closed during a normal move (whether at the start or not) caused a fault
[16:32:47] <cradek> it doesn't, but I can sure see that maybe it should
[16:33:06] <cradek> in fact I'm going to go write that
[16:34:29] <cradek> hmm though if I write that, I do have to pull off the switch before ending a successful probe
[16:34:29] <jepler> since I don't think the retract happens now, it'll make probing pretty useless
[16:34:29] <jepler> I assume the retract would be a movement in the reverse of the probing move until the traj cycle where the probe opens
[16:34:32] <skunkworks> jepler has a new friend. ;)
[16:34:34] <cradek> otherwise (like you said)...
[17:13:11] <skunkworks> SWPadnos: The experimental kernel didn't work for you?
[17:16:58] <SWPadnos> nope
[17:17:19] <SWPadnos> I should reboot that machine and search for the actual errors it printed
[17:17:50] <skunkworks> what did you try it on?
[17:18:22] <SWPadnos> my dual Opteron machine
[17:18:36] <SWPadnos> dual dual-core, so that could have had sometihng to do with it
[17:19:51] <skunkworks> ah - so 4 cores.
[17:19:56] <SWPadnos> yep
[17:21:41] <skunkworks> (I keep saying it doesn't work on single processor motherboards because the 2 I tried it on didn't work) sorry cradek.
[17:25:20] <SWPadnos> I should probably try it on my single-core athlon64 box
[17:29:27] <skunkworks> I tried it on a 450 II and a pent 4 1.7ghz m
[17:30:52] <skunkworks> the dual 600 pent III worked
[17:52:31] <jepler> daisy.ngc is the coolest thing ever
[17:53:58] <cradek> heh
[17:54:34] <jepler> next you need to do some two-part piece for lathe
[17:55:57] <skunkworks> :) I didn't get it to work as I needed to make a xyza hal_speaker
[17:56:02] <cradek> two isn't very many axes to have a harmony
[17:56:32] <cradek> I would have liked to have five (four notes for the 7ths)
[18:06:07] <alex_joni> XYZA + hal_speaker?
[18:07:51] <skunkworks> there is a sim_inch which uses the hal_speaker. but it is only xyz.
[18:09:03] <cradek> that should be simple to add
[18:09:32] <alex_joni> haha
[18:09:39] <alex_joni> +/* I can see the puzzled look on your face now. Why do we need
[18:09:38] <alex_joni> + a write function for encoders? You don't write to encoders...
[18:09:38] <alex_joni> + Well, you do write to the index latching hardware.
[18:09:38] <alex_joni> +*/
[18:12:21] <skunkworks> I did a man hal_speaker and it didn't come back with anything ;)
[18:15:33] <jepler> onoz
[18:15:51] <jepler> you should write one
[18:18:54] <skunkworks> well - that is no on the priority list just yet. Which is why I also have not done the xyza hal_speaker setup. :)
[19:11:14] <cradek> jepler: where is that link to the handbook you always paste?
[19:17:19] <jepler> cradek: most of the items from the gcode quickref are still links to the handbook
[19:18:20] <cradek> I found that
[19:18:26] <cradek> (I couldn't find the handbook any other way)
[19:18:46] <cradek> btw, I use that quick ref ALL the time
[19:18:51] <cradek> that's a really nice summary
[19:22:50] <jepler> I'm glad you like it
[19:23:34] <jepler> I wonder how much a laminated version would cost to print -- might be a nice item to give away at fest, but much of the value comes from the hyperlinks
[19:24:11] <cradek> good question
[19:27:10] <cradek> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_38a.html#999268
[19:27:16] <cradek> I don't see any talk about concave corners here
[19:27:28] <cradek> I could have sworn it was explained
[19:28:23] <jepler> the TOC lists B.5.3 Cutter Gouging (11) 82
[19:28:26] <jepler> but that page doesn't have a B.5.3
[19:28:56] <jepler> this copy is more complete:
http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_38a.html
[19:29:00] <jepler> beats me why
[19:35:56] <tomp> cradek: do 4 pwm or freq gens driving 4 small speakers = harmony?
[19:36:23] <cradek> tomp: no, 4 stepper motors on my 4 axis mill = harmony
