Back
[00:21:18] <skunkworks> why does adding backlash comp require a lower speed and acc?
[00:46:46] <jepler> skunkworks: emc's backlash compensation works as follows: when you reverse direction, move the motor an additional B units
[00:46:49] <jepler> you want to do that 'as fast as possible'
[00:47:10] <jepler> 'as fast as possible' is defined as accelerating at the inifile maxaccel, up to maxvel
[00:47:30] <jepler> -- but that is above and beyond the acceleration already being used in the reversal, and above the velocity requested by the move
[00:47:45] <jepler> so while we usually say that emc "doesn't exceed machine constraints", it actually does when taking up backlash
[00:51:51] <skunkworks> ah - thanks :)
[01:26:43] <SWPadnos> which should be OK in many circumstances, since theoretically you aren't pushing the table or cutter when doing backlash comp - you're only reversing the motor and screw
[01:34:50] <SWPadnos> jmkasunich, do you think andy holcomb's problem could be a problem with the stepgen position loop going one count too far or something?
[01:35:08] <SWPadnos> (seems like a longshot, and everyone and their brother would have seen it if so)
[01:38:50] <jepler> hm
http://emergent.unpy.net/index.cgi-files/sandbox/vel-acc-profile.png
[01:39:05] <jepler> it's a bit ugly looking really
[01:39:16] <SWPadnos> "normal" stepper system with backlash?
[01:39:44] <jepler> yes, all values from commanded
[01:39:59] <jepler> inifile maxvel is 1.0, maxaccel is 28.0
[01:40:12] <SWPadnos> wow, that's quite a pseudomachine you've got there ;)
[01:40:31] <jepler> (inches)
[01:40:34] <jepler> it's my real machine
[01:40:45] <SWPadnos> that's very high accel, I think
[01:40:55] <SWPadnos> but then again, I don't really know
[01:41:26] <jepler> I don't think that's atypical for itty bitty stepper machines
[01:41:51] <jepler> looks like the old 3-axis "max" has .5667 and 20
[01:42:07] <SWPadnos> I wonder how many steps stepgen might output between "capture-position" and "update-freq"
[01:42:09] <jepler> funny considering that I have smaller motors running at a lower voltage than chris
[01:42:43] <jepler> SWPadnos: if andy's report is accurate, though, it's position-cmd that is changing
[01:42:49] <SWPadnos> true
[01:43:01] <jepler> and I assume he's in "machine on", otherwise no steps should be commanded
[01:43:04] <SWPadnos> backlash in part of position-cmd though, isn't it?
[01:43:09] <SWPadnos> s/in/is/
[01:43:13] <jepler> yes I suppose so
[01:43:20] <jepler> motor-position-cmd anyway
[01:43:31] <SWPadnos> so stepgen is going full tilt one way, taking up backlash
[01:44:06] <jepler> fwiw I haven't seen this on zenbot
[01:44:07] <SWPadnos> on a slow-ish CPU, motion may take a little while to execute, so you get one extra step, and now backlash goes full tilt the other way
[01:44:11] <jepler> its scale is 32000
[01:44:30] <SWPadnos> unfortunately, that's the question Andy didn't answer ;)
[01:45:23] <SWPadnos> I wonder if it's possible to use the BACKLASH setting as something like DEADBAND
[01:45:52] <SWPadnos> ie, if you're within the backlash, don't bother moving the motor
[01:46:45] <jepler> my axis.0.motor-pos-cmd is stable at -1.720783e-05 for as long as I care to watch
[01:47:14] <SWPadnos> what CPU speed?
[01:47:26] <jepler> fast enough
[01:47:31] <SWPadnos> or maybe more importantly, what's tmax on the motion functions
[01:47:36] <jepler> little enough
[01:47:42] <SWPadnos> good enough
[01:48:37] <jepler> I think you're wrong talking about stepgen -- he says the commanded position is changing, and that's before the position gets to stepgen
[01:48:55] <SWPadnos> yes, but backlash calcs are dependent on the feedback from stepgen
[01:49:29] <jepler> hm I didn't realize that's what you were getting at -- I'm not sure whether that's true or not
[01:49:41] <jepler> I assumed that "reversal" was commanded reversal, not feedback reversal
[01:50:01] <jmkasunich> he says the commanded position is changing three or four digits down
[01:50:10] <SWPadnos> stepgens synthesized position feedback is what motion uses to decide when to apply backlash comp
[01:50:17] <jmkasunich> meanwhile he also said that the axis (its angular) moves something like 20 degrees
[01:50:22] <SWPadnos> (if it needs to reverse to get back "on target"
[01:50:25] <SWPadnos> )
[01:50:33] <jmkasunich> SWPadnos: thats not true
[01:50:46] <jmkasunich> comp is based on commanded direction and position only
[01:50:47] <jepler> and I don't think you want to treat backlash like deadband. On my backlash-happy mill I can still get good 5 mil features (like a trace narrowing to fit between two pads, then widening again) with 9mil backlash. if it was "like deadband", that wouldn't work anymore
[01:50:53] <jepler> jmkasunich: hi and good evening
[01:50:58] <jmkasunich> hi
[01:51:09] <SWPadnos> jepler, ok, thanks - I wasn't sure it was a good idea
[01:51:20] <SWPadnos> jmkasunich, hmmm - ok, right. there's no PID in motion
[01:51:41] <SWPadnos> did he ever mention how he created this config?
[01:52:03] <jmkasunich> don't think so
[01:52:23] <SWPadnos> he's been dabbling (at least) for quite some time though, I think
[01:52:24] <jmkasunich> I just read his latest - it seems he is saying that turning off backlash comp solved his problem?
[01:52:29] <SWPadnos> yes
[01:52:32] <SWPadnos> seems that way
[01:52:44] <jmkasunich> I wish people would speak precisely
[01:52:49] <cradek> what is the problem exactly?
[01:53:04] <cradek> just what I was thinking.
[01:53:05] <jepler> From: andyholcomb <andyholcomb@verizon.net>
[01:53:08] <jepler> Subject: Re: [Emc-users] Problems with axises in auto and mdi
[01:53:16] <SWPadnos> some axes wiggle back and forth sometimes, but not in manual mode
[01:53:16] <cradek> "then I do what I do to make it go crazy"
[01:53:26] <jmkasunich> In manual mode it works great, MDI and Auto mode it will
[01:53:26] <jmkasunich> randomly go nuts on on one or two varying axises. Nuts, sometimes
[01:53:26] <jmkasunich> going back and forth about 10 or 20 degrees on a axis with no movement
[01:53:26] <jmkasunich> on the digits on the screen. Or, moving slowly in one direction with no
[01:53:26] <jmkasunich> movements on the location display of the screen.
[01:53:28] <jepler> ^^ this thread, I won't mislead you with an attempt to summarise
[01:54:11] <jmkasunich> since he talks about degrees, and says "on a axis" I read that to mean on his angular A axis
[01:54:17] <cradek> but later he says 'in the 4th or 5th digit'
[01:54:25] <cradek> that's not 10-20 degrees
[01:54:34] <jmkasunich> but it probably means "my X or Y or Z linear axis motor shaft turns by 20-30 degrees"
[01:54:49] <cradek> and he says the dir signal is changing but step "is fine"
[01:54:55] <jmkasunich> exactly - he doesn't speak precisely, and his reports are self contradictory
[01:54:58] <jmkasunich> so I ignored him
[01:55:13] <SWPadnos> I'll ask him to post his config files again
[01:56:18] <cradek> that's frustrating; I like to help but I despise fishing for information
[01:56:44] <jepler> 4 mil backlash on 20TPI is abuot 30 degrees. naive cam which changes an axis by a tiny bit in every move? that could give "crazy" behavior like this.
[01:56:49] <jmkasunich> if he has jittering on the last digit or two, EMC/stepgen might be going back and forth one step, but his drives could be missing the direction change so they'd walk one direction (at least for a while)
[01:56:54] <jepler> x.001 / x-.001 / repeat
[01:57:29] <cradek> jepler: so maybe it's when running a certain gcode
[01:57:35] <jmkasunich> he seems to say it sits there and jitters at the MDI promot
[01:57:38] <jmkasunich> pt
[01:57:43] <jmkasunich> (last message)
[01:58:08] <SWPadnos> he didn't say that the axes lose position
[01:58:17] <SWPadnos> just that they wobble, and they stop when he goes to manual mode
[01:58:33] <SWPadnos> does jogging apply backlash comp?
[01:58:38] <SWPadnos> (I guess it should)
[01:58:40] <jmkasunich> he didn't say they don't lose position
[01:58:57] <SWPadnos> that's true, he didn't say either way
[01:59:00] <cradek> SWPadnos: yes it does
[01:59:04] <jmkasunich> if the motor moves 20 degrees, and the feedback doesn't change (1st msg) or changes only in a very small digit (2nd) then yes, he lost position
[01:59:06] <SWPadnos> ok
[01:59:23] <SWPadnos> I think he was talking about two different things tehre
[01:59:36] <SWPadnos> the first was the DRO, which didn't change (it wouldn't, since it's only 3 or 4 digits)
[01:59:52] <SWPadnos> the second was halscope/meter showing motor-pos-cmd and stepgen feedback
[01:59:58] <jmkasunich> ok, so those two are consistent with each other
[02:00:01] <SWPadnos> which did change in the 4/5/6 digit or something
[02:00:32] <jmkasunich> not consistent with 20 degrees - his motors or drives must be misinterpreting the signals from stepgen, or else stepgen has a bug that nobody else has seen
[02:00:52] <jepler> motor-pos-cmd or joint-pos-cmd?
[02:00:55] <SWPadnos> the DRO doesn't change when backlash is applied, does it?
[02:00:59] <SWPadnos> dunno
[02:01:31] <jmkasunich> depends on whether the DRO is in cmd or fb mode, and how well stepgen's fb tracks its command
[02:01:37] <jepler> this gcode "makes my X axis go crazy", because it's continually reversing and taking up backlash.
http://pastebin.ca/1192152
[02:01:45] <jmkasunich> it should not change (and won't, in cmd view, but in fb view it might)
[02:02:20] <jmkasunich> jepler: I understand, but that seems to contradict what he is describing
[02:02:22] <jepler> the X DRO does change in the 4th digit while running this code
[02:02:47] <jmkasunich> They jitter sometimes as soon as I go into mdi or auto mode, if I move x
[02:02:47] <jmkasunich> in manual mode and then then go to mdi mode, the x axis may start to
[02:02:47] <jmkasunich> jitter, it seems like it only jitters if the axis has been moved. I was
[02:02:47] <jmkasunich> messing with it earlier I moved all of my axises in manual mode and them
[02:02:47] <jmkasunich> went to mdi mode, the x and the z axis were jittering, I entered g00
[02:02:48] <jmkasunich> x0y0 and the x and the y move as they should; but the z was still
[02:02:50] <jmkasunich> jittering during the move.
[02:04:29] <SWPadnos> hmmm. are there actually joint-pos-cmd outputs from motion?
[02:04:46] <SWPadnos> I guess I should check the manual
[02:08:29] <jepler> crap -- I've misplaced all my broken drill bits
[02:08:41] <jepler> (they're what I use for touching off "Z")
[02:09:16] <jmkasunich> I just asked andy to come to IRC - dunno if it will work
[02:09:45] <jmkasunich> need to get back to cutting, but I'll check here once in a while
[02:09:56] <jmkasunich> have I ever mentioned how much I hate "built up edge"
[02:10:16] <jepler> I guess I'll just have to break another
[03:16:06] <jepler> uh oh, he's using plu-toh
[03:16:27] <SWPadnos> yay! config files
[03:17:11] <jmkasunich> andy holcomb is using pluto?
[03:17:25] <cradek> no he's not
[03:17:33] <cradek> he just pasted a few extra files for some reason
[03:17:50] <jmkasunich> * jmkasunich refrains from saying something unkind
[03:18:02] <jepler> er, oh
[03:19:05] <cradek> these are not stepgen configs
[03:19:12] <cradek> er, this is not a stepgen config
[03:19:32] <cradek> no timings are set
[03:20:52] <jepler> his base period is small enough to get me a realtime delay message
[03:20:54] <jmkasunich> it looks like a copy of our standard config
[03:22:25] <jepler> OK, I have the config running and went into mdi mode -- what am I supposed to do to see a problem?
[03:22:36] <SWPadnos> G0anything
[03:22:41] <SWPadnos> or something like that
[03:23:01] <cradek> Y backlash .024, ouch
[03:23:12] <SWPadnos> and 0.02 on X
[03:23:23] <jepler> I got a 'joint 0 following error' on a G0 move
[03:24:29] <SWPadnos> hard to get 40ksteps/sec with 14000 base period
[03:24:30] <jepler> I bet stepgen accel headroom has to be much greater with backlash, since up to 2x accel is used while reversing
[03:24:43] <SWPadnos> you'd need 12500 or less
[03:24:45] <jepler> SWPadnos: that too
[03:25:03] <SWPadnos> so it sems likely that these aren't the correct files
[03:27:41] <jepler> it's running better with maxvel changed to 0.7 and STEPGEN_MAXACCEL changed to 45 in all instances
[03:28:02] <jepler> homed, G0'd X away from origin then back .. commanded position is stable
[03:28:02] <jepler> 4 float OUT 8.673617e-18 axis.0.motor-pos-cmd ==> Xpos-cmd
[03:28:10] <jepler> goodnight
[03:28:24] <SWPadnos> night
[03:31:33] <jmkasunich> what chat client is installed on ubuntu by default?
[03:31:46] <jmkasunich> I use xchat, but I can't remember if I had to install it
[03:31:55] <cradek> gaim unfortunately
[03:35:15] <jmkasunich> hmm, andy replied to my message, but I didn't get it myself
[03:38:40] <SWPadnos> I've had that happen, then the earlier message shows up sometime in the next day or so
[07:52:34] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/tcl/ (tkemc.tcl TkEmc):
[07:52:34] <CIA-40> EMC: Patch by Dewey Garett:
[07:52:34] <CIA-40> EMC: * add separate sliders for linear/angular joints:
[07:52:34] <CIA-40> EMC: uses DEFAULT_LINEAR_VELOCITY/DEFAULT_ANGULAR_VELOCITY if existant (or DEFAULT_VELOCITY if not)
[07:52:34] <CIA-40> EMC: * new key bindings (semicolon, apostrophe) for incrementing angular jog speed
[07:52:37] <CIA-40> EMC: * fix typo in spindle override slider that made it's popup behave different
[13:38:27] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (5 files): french translation update
[13:38:27] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (user_intro_fr.lyx integrator_intro_fr.lyx): french translation update
[13:38:27] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/ (ini_homing_fr.lyx stepconf_fr.lyx): french translation update
[13:38:28] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/install/installing_emc2_fr.lyx: french translation update
[13:38:52] <tissf> hi all
[13:38:56] <jepler> hi tissf
[13:39:03] <jepler> thanks for your continuing work on the docs!
[13:39:32] <tissf> jepler: np a pleasure for me
[13:45:31] <tissf> I have a recurrent problem with ini_homming_fr.lyx
[13:45:47] <tissf> All the characters are underlined in blue, I suspect that to be the error source to the compilation
[13:46:21] <tissf> But I do not see why!
[13:46:23] <SWPadnos> could it be an HTML-style link problem?
[13:46:40] <SWPadnos> (text getting displayed as a link)
[13:47:39] <tissf> all the texte is black but underlined in blue
[13:47:47] <SWPadnos> hmm
[13:52:03] <tissf> a very clear message of the compiler!
[13:52:05] <tissf> LyX: Missing quote [around line 1838 of file /tmp/lyx_tmpdir153998srxmW/153996jfMWz]
[13:52:18] <SWPadnos> heh
[13:53:50] <tissf> and the first thing that it does... it eliminates this file!
[13:54:08] <SWPadnos> well, it is a temp file ;)
[13:54:33] <tissf> sure :)
[13:55:19] <tissf> the error's not temp!
[13:55:47] <SWPadnos> if only we knew which file that one was generated from
[13:57:15] <tissf> the suspicious one is config/ini_homing_fr.lyx for me
[13:57:28] <tissf> but...
[14:01:07] <SWPadnos> HOME", c'est le point final de la séquence de prise d'origine.
[14:01:08] <SWPadnos> La valeur par défaut est zéro.
[14:01:45] <SWPadnos> line 701
[14:12:27] <tissf> I do not see any error except can be the format of the ""
[14:13:02] <tissf> who seems different of the other files
[14:13:03] <SWPadnos> there's only one quote on that line, and no matching end quote (")
[14:14:30] <tissf> yes, I added the " lacking, that changes nothing apparently
[14:14:54] <jepler> tissf: I don't know why
[14:15:12] <tissf> no! missing "
[14:16:33] <SWPadnos> oh, ok
[14:16:37] <tissf> If jepler does not know... that will be difficult
[14:16:47] <tissf> :)
[14:18:19] <jepler> OK -- I think I figured it out
[14:18:45] <jepler> in that file there are many lines in the .lyx file which say "\lang french". I removed all those lines, and now the blue lines are gone
[14:19:31] <tissf> jepler oh ok can you commit it ?
[14:19:42] <jepler> I found a hint that it might be due to language when I searched for: lyx blue underline
[14:20:23] <tissf> ok
[14:20:33] <jepler> yes I will check it in .. give me a moment
[14:21:13] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/ini_homing_fr.lyx: fix all letters being underlined in blue when edited in lyx
[14:21:17] <cradek_> can someone independently verify what I think is a bug in canned cycles?
[14:21:34] <cradek_> "In incremental distance mode: when the XY-plane is selected, X, Y, and R numbers are treated as increments to the current position and Z as an increment from the Z-axis position before the move involving Z takes place"
[14:21:39] <cradek_> cradek_ is now known as cradek
[14:22:40] <tissf> jepler: thank you
[14:22:40] <cradek> a sequence to trigger it is g90g0x0z1 / g90g17g81z-1r.1x.1l10
[14:22:54] <cradek> a sequence to trigger it is g90g0x0z1 / g91g17g81z-1r.1x.1l10
[14:23:08] <jepler> cradek: G90 is absolute mode?
[14:23:14] <cradek> yes
[14:28:01] <cradek> I meant the second sequence above - the first line was a typo
[14:30:30] <jepler> I had to add an F-word too
[14:30:37] <cradek> oh right
[14:31:07] <jepler> so you expect the cycle to go down to z0 but it goes to z.1 instead?
[14:31:40] <cradek> yes
[14:31:50] <jepler> are you also surprised that it moves to z1.1 before the first cycle?
[14:32:01] <jepler> or does it say it's supposed to do that?
[14:32:02] <cradek> no
[14:32:15] <cradek> "At the very beginning of the execution of any of the canned cycles, with the XY-plane selected, if the current Z position is below the R position, the Z-axis is traversed to the R position."
[14:32:20] <jepler> ok
[14:33:56] <jepler> if "the move involving Z" is the traverse to R then it's wrong. If it's the feed down to the depth specified by Z then it's right. I am not sure the language is precise enough to say which one was intended
[14:35:07] <cradek> oh I see what you mean. I didn't consider "move involving Z" that way
[14:35:09] <jepler> how's that for refusing to "steak out"(sic) a position
[14:36:12] <cradek> very skillful
[14:36:23] <cradek> skillfull (sic)
[14:37:28] <SWPadnos> yew guise arrr wired [sic]
[14:38:51] <cradek> well I didn't really want to be the last one to touch canned cycles anyway.
[14:40:39] <jepler> huh, I'd never thought about how for repeated canned cycles you have to move "one beyond" the first hole to start
[14:41:33] <cradek> yeah it's a bit odd
[14:43:28] <jepler> g90g0x0z1 / g91g17g81z-1r-.1x.1l10f20
[14:43:40] <jepler> that drills down to z-.1
[14:45:29] <cradek> is that different from what you expect?
[14:46:03] <SWPadnos> Z-0.1?
[14:46:20] <jepler> cradek: I'm not sure
[14:46:42] <SWPadnos> hmmm. does it leave the cutter at Z-0.1?
[14:47:25] <jepler> SWPadnos: no, Z0.9
[14:47:35] <SWPadnos> ok
[14:47:50] <jepler> cradek: so I am thinking it's a doc bug, and the docs should say something like "Z is an increment from the retract plane" which I think describes the current behavior
[14:47:57] <jepler> and is maybe even sensible
[14:48:43] <jepler> current position -> apply "R" (if specified) as increment to get retract plane -> apply "Z" as increment to get depth
[14:48:44] <cradek> I agree that's the behavior and the docs should be clearer, but I'm not sure the behavior is desired
[14:49:48] <jepler> I guess the question is, what numbers is it natural for the person coding the program to know
[14:50:09] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_cycles.cc: I see no reason to forbid g95/fpr canned cycles.
[15:42:06] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: on lathes, always draw dwells so they can be seen
[19:28:31] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: large DRO font option
[19:28:33] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: large DRO font option
[19:29:58] <BigJohnT> cradek: I can't wait to try that
[19:30:11] <cradek> don't tell jepler
[19:31:12] <BigJohnT> LOL
[19:31:14] <BigJohnT> ok
[19:48:19] <cradek> he asked if I gave the two choices of font that will make all users happy - I said 'yes' with a straight face.
[21:57:21] <CIA-40> EMC: 03flo-h 07TRUNK * 10emc2/src/po/de_axis.po: updated some translations
[22:09:58] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (8 files): french translation cleaning - fix lyx errors - new filenames for docclean
[22:09:59] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (5 files): french translation cleaning - fix lyx errors - new filenames for docclean
[22:09:59] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/ (6 files): french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:09] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/ (4 files): french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:13] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:13] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/ (8 files): french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:14] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/install/ (compiling_emc2_fr.lyx installing_emc2_fr.lyx): french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:16] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ladder/ladder_intro_fr.lyx: french translation cleaning - fix lyx errors - new filenames for docclean
[22:10:19] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/quickstart/stepper_quickstart_fr.lyx: french translation cleaning - fix lyx errors - new filenames for docclean
[22:11:07] <jepler> cradek: looks like your font change will leak display lists when repeatedly changed
[22:11:29] <jepler> cradek: this probably causes x server memory to grow and not be reclaimed until axis exits, or maybe makes axis fail with an opengl error after awhile
[22:15:55] <skunkworks> sure - rain on his parade. ;)
[22:19:16] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: do not leak display lists when switching font
[22:20:10] <jepler> with many cooks, all broth is shallow
[22:20:23] <jepler> er .. something like that
[22:24:28] <skunkworks> heh
[22:25:05] <tissf> good night all
[22:34:39] <SWPadnos> many cooks make light broth?
[22:42:24] <skunkworks> what is it called - step/dir you get individual steps instead of a servo where you get a smooth velocity movement
[22:42:42] <skunkworks> wait - did that make sense?
[23:05:57] <cradek> is quantization the word you want?
[23:08:48] <LawrenceG> hey chris
[23:11:09] <skunkworks> cradek: yes - thanks
[23:11:24] <LawrenceG> http://imagebin.ca/view/u11asXn.html http://imagebin.ca/view/3iFDcau.html It works!
[23:20:33] <skunkworks> cradek: free shipping code for enco (supposidly) WB8SP
[23:25:26] <cradek> ordered already, thanks :-)
[23:25:52] <cradek> LawrenceG: cool!
[23:26:05] <cradek> skunkworks: wait a couple days into the month, then search on any old machining web bbs
[23:26:20] <skunkworks> heh
[23:26:31] <skunkworks> this was on cnczone ;)
