Back
[00:00:00] <jepler> jmkasunich: yeah
[00:00:07] <jmkasunich> what does the pluto use for a clock?
[00:00:43] <jepler> jmkasunich: there's a little 4 pin crystal oscillator (black rectangular thing) on the bottom side
[00:01:01] <jepler> I'm running this on sim-with-hacked-outb() so it could be due to that
[00:01:09] <jmkasunich> ok - crystals are usually well under 1% (like 0.01%), so thats probably not it
[00:01:29] <jepler> it's marked 40.0000
[00:01:48] <jmkasunich> and you are using 40MHz in your timing calculations?
[00:02:38] <jmkasunich> oh, sim
[00:02:44] <jmkasunich> that could explain a lot ;-)
[00:03:14] <jepler> I wouldn't expect it to be so consistent
[00:03:32] <jepler> I suppose I should try a real machine though
[00:03:56] <jmkasunich> if its not too much of a pain, that would either explain it, or rule out sim effects
[00:03:59] <jepler> yeah
[00:06:51] <cradek> jmkasunich: did you see stuart's homing images? they look ok to me. seems maybe he's getting more index pulses than he should
[00:07:01] <jmkasunich> yeah
[00:07:34] <jmkasunich> I'm reluctant to once again publically blame it on the ppmc, but I blame it on the ppmc
[00:08:49] <cradek> ha
[00:08:55] <cradek> noise maybe
[00:09:09] <jmkasunich> that would suck
[00:09:27] <cradek> on the other hand, I think the ppmc has a pin that says it's latched an index during this cycle. it would be nice to watch that.
[00:09:59] <jmkasunich> you mean a HAL pin?
[00:10:41] <jmkasunich> if the index-enable hal pin is borked (hw or driver issue), I dunno how the "I saw an index" pin can be trusted either
[00:11:35] <cradek> wah
[00:11:43] <jmkasunich> ?
[00:11:56] <cradek> that's just how I feel about index problems.
[00:12:15] <jepler> grumble, the key repeat on this machine is acting weird
[00:12:24] <jepler> "eeeeee" I type, accidentally
[00:12:29] <cradek> your laptop with the dodgy keyboard?
[00:12:46] <jepler> no, this is my 64-bit machine -- the only machine in my house that might have working realtime
[00:13:01] <jepler> but at least while it is working on building emc2 (make -j2) the keyboardd is aaacting funny
[00:13:05] <cradek> oh interesting. wonder if that's the bug that haunts me too
[00:13:12] <cradek> yep bet so
[00:13:14] <jmkasunich> cradek: wah sounds like a youpper-ism
[00:13:15] <jepler> this is 3 or 4 extra letters, not a thousand
[00:13:19] <jmkasunich> you been hanging around with ray?
[00:13:53] <cradek> nope...
[00:15:00] <jepler> 3 float IN 10 pluto-step.stepgen.0.velocity-cmd <== vel
[00:15:01] <jepler> 3 float OUT 20.03115 pluto-step.stepgen.0.velocity-fb
[00:15:11] <jepler> did I say I trusted realtime on this machine?
[00:15:20] <cradek> yeah I remember something about that
[00:15:38] <cradek> I have a great realtime machine just sitting - you can have it if you want
[00:15:41] <jmkasunich> vel fb is pos-fb thru a ddt?
[00:15:59] <jepler> jmkasunich: no, it's computed inside the module
[00:16:23] <jmkasunich> duh
[00:16:29] <jmkasunich> hence the pluto on the front ;-)
[00:16:49] <jmkasunich> so, fb is new-pos-fb - old?
[00:17:10] <jmkasunich> and velcmd is what? new cmd - old?
[00:18:34] <jepler> velocity-cmd is the velocity command, it's an input
[00:18:39] <jepler> it's arbitrarily set to 10
[00:18:55] <jmkasunich> ok, you use that with a PID
[00:19:10] <jepler> baby steps first .. velocity mode is (should be) easier to do
[00:19:13] <jmkasunich> right
[00:19:25] <jepler> velocity-fb is based on (new - last)
[00:19:32] <jmkasunich> do you make frequency visible as a param?
[00:21:26] <jepler> I think I changed one of these constants between the time I was getting 5% too low, and when I changed machines and got 100% too high
[00:21:37] <jmkasunich> ah
[00:21:46] <jepler> now it's wobbling between just-over-10 and just-under-10
[00:22:04] <jepler> there's still a scale wrong somewhere, because position-fb is not changing 10 per second
[00:22:19] <jepler> but I probably just have constant factors wrong because I haven't thought things through
[00:23:08] <jmkasunich> if you put a constant vel cmd in, frequency cmd to the hardware, and actual frequency out, should be constant
[00:24:00] <jmkasunich> pos fb will be quantized, so vel fb will jump around
[00:24:23] <jmkasunich> do you have a scope or freq counter to check the actual output?
[00:24:35] <jepler> I do have a scope
[00:25:07] <jmkasunich> if you can confirm that the output is right, then you can focus on the feedback/counter part
[00:25:12] <jmkasunich> (or vice versa)
[00:26:37] <jepler> ID Type Name PID Sta
[00:26:37] <jepler> ID Type Name PID Sta
[00:26:50] <jmkasunich> Sta?
[00:27:21] <jepler> sorry -- paste gone wrong
[00:27:38] <jepler> my mouse seems to have freaked out, as a matter of fact
[00:28:31] <jepler> mes[2461053.212867] psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
[00:28:34] <jepler> getting a lot of these messages
[00:29:36] <jmkasunich> not a happy kernel?
[00:29:52] <jepler> something
[00:30:07] <jepler> I've removed my cheap kvm from the mix, let's see if that makes any difference
[00:30:45] <jmkasunich> you shoulda bought my cheap kvm
[00:31:05] <jepler> well, the stuttering keyboard problem still exists so I don't think it's the cause
[00:31:38] <cradek> which kernel is it?
[00:31:48] <jepler> Linux tall 2.6.20.12-smp-magma #1 SMP PREEMPT Wed Jun 6 17:50:57 CDT 2007 x86_64 GNU/Linux
[00:32:15] <cradek> I don't remember if I had it in 2.6.20 or not
[00:32:22] <cradek> I know 2.6.17 has it
[00:32:39] <cradek> you wouldn't think they could screw up keyboards...
[00:32:46] <jepler> unfortunately I reinstalled my only 32-bit system with realtime, because after my success on this machine I figured getting a RT kernel to work on 32-bit feisty would be a piece of cake
[00:33:05] <cradek> seriously, I can bring you a machine
[00:33:26] <jepler> stepgen_velocity_fb(i) = (count - data.last_count[i]) / stepgen_position_scale(i) / fperiod / (1 << F);
[00:33:36] <cradek> but I suppose you have parts around anyway
[00:33:39] <jepler> yeah I have parts
[00:33:43] <jepler> they just have the wrong OSes installed on them
[00:34:30] <jepler> oh, found it -- I divided out the fractional part of the feedback twice
[00:35:14] <cradek> * cradek grumbles about the 1 hour battery life of his new laptop
[00:36:08] <jmkasunich> rt kernel?
[00:36:16] <cradek> nope, normal one
[00:36:18] <jmkasunich> eww
[00:36:41] <jmkasunich> is this a new new laptop, or an new old laptop?
[00:36:39] <cradek> I got two new batteries, might get it up to 3-4 hrs like I'm used to
[00:36:51] <cradek> only new to me
[00:37:06] <jmkasunich> so the batteries might be a little pooped
[00:37:09] <cradek> it can take 3 batteries at a time :-)
[00:37:20] <cradek> it's quite a large laptop
[00:38:28] <jmkasunich> Intel Server / Dual P3 550mhz/ 1Gb/ SCSI - $350 <-- craigslist
[00:38:38] <cradek> ha, good luck
[00:38:40] <jmkasunich> people obviously don't know what old computers are worth
[00:38:53] <jmkasunich> take off the zero and they might do better
[00:38:58] <cradek> right
[00:39:52] <jmkasunich> otoh: Dualcore Gateway Laptop MT6456 160gb 1gb ram 802.11n - $500
[00:40:01] <jmkasunich> claimed to be brand new
[00:40:10] <cradek> woo
[00:40:46] <jepler> woo?
[00:41:08] <cradek> that seems like a good price for a laptop you can go check out
[00:41:28] <jmkasunich> Dualcore Gateway Laptop MT6456 160gb 1gb ram 802.11n - $500
[00:41:38] <jmkasunich> oops
[00:41:49] <jmkasunich> http://cleveland.craigslist.org/sys/367078127.html
[00:42:39] <cradek> eh
[00:42:53] <cradek> 1280x800 = no good
[00:43:00] <cradek> I hate widescreens
[00:43:37] <jepler> looks like the wireless is not likely to work
[00:43:54] <cradek> Marvell TopDog!?
[00:44:11] <jmkasunich> I'm not even remotely interested, and its too far away for you guys... I just was browsing
[00:47:27] <jepler> jmkasunich: this can't possibly be all there is to it: vel_cmd = (pos_cmd - stepgen->old_pos_cmd) * recip_dt;
[00:47:47] <jmkasunich> for position mode?
[00:47:50] <jepler> yes
[00:47:54] <jmkasunich> no, thats not all there is to it
[00:47:59] <jepler> where's the rest hidden?
[00:48:12] <jmkasunich> you are looking at stepgen?
[00:48:14] <jepler> yes
[00:49:19] <jmkasunich> lines 924-996
[00:50:04] <jmkasunich> vel_cmd is the commanded velocity from EMC (or whatever), its not the velocity that you need to send to the hardware
[00:50:13] <jepler> ah
[00:50:52] <cradek> wow, stepgen is complicated. glad you understand it.
[00:50:54] <jmkasunich> new_vel is the velocity that is sent to make_pulses
[00:51:15] <jmkasunich> making it obey the vel and accel limits is the messy part
[00:51:19] <jepler> let's say I'm not doing acceleration limiting
[00:51:26] <jepler> (I'll leave that to a limit3 or to emc)
[00:51:55] <cradek> oh I'm the slow one - are you doing pluto stepgen?
[00:52:00] <jmkasunich> you still need to correct for the odd step that gets rounded off here and there, otherwise those errors will integrate
[00:52:06] <jepler> then I should look at "we can match velocity in one period" (962)?
[00:52:14] <jepler> cradek: yes
[00:52:15] <cradek> neat
[00:52:40] <jepler> new_vel = vel_cmd - 0.5 * est_err * recip_dt;
[00:53:05] <jepler> cradek: 4 stepgens + dio fits (barely); no pwm or watchdog
[00:53:04] <jmkasunich> jepler: I'm not sure
[00:53:22] <jmkasunich> 4 stepgens + counters for feedback I assume?
[00:53:45] <jepler> yes -- all with not quite as many bits as you'd wish for
[00:54:27] <jmkasunich> is the feedback a separate counter, with one count granularity? or is it the accumulator value of the stepgen itself (with quite a few fraction bits)
[00:54:28] <jepler> 9-bit+sign velocity to fpga, 9.9bit location from fpga
[01:12:55] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/not-quite.png
[01:14:07] <jepler> hmm is it just hitting a velocity limit?
[01:14:45] <jmkasunich> might be
[01:14:48] <jmkasunich> what is the limit?
[01:15:15] <jepler> it should have been 1e30 units per second
[01:15:21] <jepler> with a slower sine wave it works much better:
http://emergent.unpy.net/index.cgi-files/sandbox/maybe-so.png
[01:15:35] <jmkasunich> there is a limit in the HW
[01:15:50] <cradek> very nice
[01:15:52] <jepler> the first screenshot was a sine wave frequency=1 amplitude=10; the second if frequency=.2 (I think)
[01:16:07] <jmkasunich> when you put all 1s into the freq register, you will get some maximum frequency
[01:16:19] <jmkasunich> well below 1e30 ;-)
[01:16:24] <jepler> well sure
[01:19:05] <jepler> I thought my limit was about 1/1600ns = 625kHz, but this was more like 200kHz
[01:19:50] <jepler> I've probably still got scales wrong or something
[01:19:58] <jepler> my programming style is too "cowboy"
[01:22:43] <jmkasunich> completely irrelevant, but...
http://jmkasunich.dyndns.org/pics/buddy-under-table1.jpg
[01:24:48] <cradek> sometimes I miss having a dog
[01:25:06] <cradek> I need to make friends with someone who has a dog to play with.
[01:25:06] <jmkasunich> you used to?
[01:25:19] <cradek> have had two, long time ago
[01:25:28] <jmkasunich> buddy is our third
[01:25:32] <jmkasunich> one at a time
[01:25:43] <cradek> yeah one is plenty
[01:26:23] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pluto-step-following-error.png
[01:26:51] <jepler> the error is a *lot* of steps
[01:26:53] <jmkasunich> when did halscope start displaying the units/div under the trace names?
[01:27:24] <jepler> after somebody implemented it
[01:27:28] <jepler> not long, but before fest
[01:27:28] <jmkasunich> how much is the error in time?
[01:27:30] <cradek> it's very nice
[01:28:00] <jmkasunich> 50 counts of error at 50KHz is 1mS
[01:28:07] <jmkasunich> you have to expect a mS or so of lag
[01:33:45] <jepler> no, something else is wrong -- I can get steady-state error
[01:33:58] <jepler> .200 units when the input is unchanging
[01:42:12] <jmkasunich> _tkinter.TclError: Togl: X server has no OpenGL GLX extension
[01:42:25] <jmkasunich> trying to run sim/axis on this machine (sim)
[01:42:45] <cradek> does glxgears work?
[01:43:05] <jmkasunich> no
[01:43:11] <cradek> ouch
[01:43:17] <jmkasunich> Xlib: extension "GLX" missing on display ":0.0".
[01:43:17] <jmkasunich> Error: couldn't get an RGB, Double-buffered visual
[01:43:22] <cradek> nvidia driver breakage?
[01:43:24] <jmkasunich> I could swear it did before
[01:43:39] <jmkasunich> I'm running stock dapper kernel (I think, lemme check)
[01:43:56] <jmkasunich> Linux mahan 2.6.15-28-686 #1 SMP PREEMPT Thu May 10 09:56:30 UTC 2007 i686 GNU/Linux
[01:44:02] <jmkasunich> yep
[01:44:23] <jmkasunich> I wonder tho, I was switching kernels a while back, maybe the driver needs rebuilt?
[01:44:29] <cradek> sure could be
[01:44:38] <cradek> make sure you have linux-restricted-modules-`uname -r`
[01:44:42] <cradek> (and then reboot)
[01:44:57] <cradek> be sure to curse nvidia the whole time - that's what I do
[01:45:41] <jmkasunich> I've already started that
[01:45:51] <cradek> it seems to help
[01:46:07] <jmkasunich> ii linux-restricted-modules-2.6.15-28-686 2.6.15.12-28.2 Non-free Linux 2.6.15 modules on PPro/Celero
[01:46:14] <jmkasunich> that means I have it, right?
[01:52:16] <cradek> I think so
[01:52:28] <jmkasunich> I think I've managed to make a mess of my system
[01:52:42] <jmkasunich> I tried to get rid of some of the many kernel packages that were installed
[01:52:48] <jmkasunich> (a couple weeks ago)
[01:53:13] <jmkasunich> and now its not sure whether it has 2.6.15-26, or 2.6.15-28
[01:55:16] <jmkasunich> arrgh
[01:55:22] <jepler> huh -- I'm getting more and more puzzled as time goes by
[01:55:31] <jepler> I think it's time to quit working on this for the night
[01:55:34] <jmkasunich> that makes two of us
[01:56:42] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$ dpkg -l | grep linux-image
[01:56:42] <jmkasunich> ii linux-image-2.6.15-28-686 2.6.15-28.55 Linux kernel image for version 2.6.15 on PPr
[01:56:42] <jmkasunich> ii linux-image-686 2.6.15.26 Linux kernel image on PPro/Celeron/PII/PIII
[01:57:34] <jmkasunich> isn't the "linux-image-686" a sort of meta-package thats supposed to refer to the newest image available?
[02:18:04] <jmkasunich> ok, after much fiddle-farting around, I have open-gl working, and I can run sim-axis
[02:18:14] <jmkasunich> which brings me to the question I wanted to ask 30 mins ago
[02:18:30] <jmkasunich> what do you call the widget that axis uses for the jog increment?
[02:19:09] <jmkasunich> it normally says "continuous", but when you click on it you get a bunch of choices - pick one and it goes back to being a single line with the selected choice in it
[02:19:32] <jmkasunich> I thought it was a "listbox", but the online info I've found for tkinter listboxes don't look anything like that
[02:19:38] <jepler> that's a "combobox"
[02:19:41] <jmkasunich> thanks
[02:20:28] <jepler> http://aspn.activestate.com/ASPN/docs/ActiveTcl/8.4/bwidget/ComboBox.html
[02:20:43] <jmkasunich> ah, its a bwidget thing, not native tkinter
[02:20:51] <jepler> yeah
[02:20:52] <jmkasunich> no wonder I couldn't find it on the tkinter docs
[02:22:14] <jepler> if it's not necessary to (A) look too much like a standard control or (B) enter text not found on the menu, Tk offers "tk_optionMenu"
[02:22:38] <jepler> (Tkinter.OptionMenu)
[02:23:21] <jmkasunich> I specifically don't want to allow text not found in the menu
[02:23:42] <jmkasunich> this is basically an "enum" thing - display the options, and let the user pick from only those options
[02:25:18] <jepler> >>> v = Tkinter.StringVar(app)
[02:25:17] <jepler> >>> m = Tkinter.OptionMenu(app, v, "eggs", "bacon", "sausage", "beans")
[02:25:21] <jepler> example of optionmenu
[02:25:32] <jepler> you might want to 'v.set(defaultvalue)' before showing the window, otherwise it starts empty
[02:26:31] <jmkasunich> there will always be a "current value" when the widget is drawn, so I use that value to set the default, right?
[02:26:38] <jepler> right
[02:29:28] <jmkasunich> looks like optionMenu will do the trick
[02:36:03] <jmkasunich> jepler: if "eggs", "bacon", and "ham" are a list, how do I pass them?
[02:36:22] <jmkasunich> passing the list results in a single choice that is the entire list
[02:37:16] <jepler> use "*" in a way you might not be familiar with: f(*[a,b,c]) is equivalent to f(a,b,c)
[02:38:00] <jmkasunich> indeed I was unfamiliar with that
[02:38:06] <jmkasunich> it works!
[02:48:59] <jmkasunich> jepler: thanks for the help
[02:50:58] <jepler> glad to help
[02:51:24] <jepler> now if only I could figure out what is going on with my stuff enough to ask you a smart question
[02:52:18] <jmkasunich> ask a dumb one instead
[02:53:08] <cradek> do you refrigerate potatoes?
[02:53:15] <jmkasunich> no
[02:54:20] <jepler> cradek: ingrid says a cold root cellar is best, but a fridge works OK -- better than leaving them on the counter
[02:54:51] <cradek> my parents always did. but, the internets unanimously say it ruins them (turns them sweet)
[02:55:12] <jmkasunich> we don't use many potatoes, so we buy them as needed instead of the the big bag
[02:55:21] <cradek> we normally use the counter method, but it's tempting to refrigerate them because we currently have lots
[02:55:25] <jmkasunich> otherwise we'd have them sprouting
[02:55:38] <cradek> yeah I've sprouted my share of potatoes too
[02:55:55] <cradek> just keeping up with knocking the sprouts off helps a lot
[02:56:06] <jepler> jmkasunich: I must have some bit widths wrong, but what I saw right before I gave up was the raw commanded velocity value (which I expect to go from -512 to 512) was going from about 160 to 240 instead
[02:56:11] <cradek> but, sometimes, I have other things to worry about instead
[02:56:21] <jepler> when following a sine wave, feedback velocity clearly on both sides of zero
[02:57:01] <jmkasunich> you're saying the value you wrote to the HW varied from 160 to 240, but the actual result was bipolar?
[02:57:11] <jepler> right
[02:57:21] <jepler> all those should have been adding to the accumulator, but I was observing that the accumulator went up and down both
[02:58:06] <jmkasunich> 160 = A0, right?
[02:58:57] <jmkasunich> and 240 = F0?
[02:59:04] <jmkasunich> so both have the high bit (sign bit) set
[02:59:05] <jepler> I don't even know if those are the exact values, but it was something like that
[02:59:10] <jepler> not crossing 128 or 256, that's what I remember for sure
[03:00:38] <jmkasunich> strange
[03:06:58] <jmkasunich> poor dog....
[03:07:07] <jmkasunich> he doesn't like fireworks
[03:07:14] <jmkasunich> whine, whine
[03:09:14] <jmkasunich> I think I'm going to go keep him company
[03:09:16] <jmkasunich> goodnight all
[03:09:16] <jepler> see you
[03:35:37] <elson> Hello, all!
[03:36:16] <elson> Just got back from a soggy Texas, and I'm looking into the problem reported by Stuart Stevenson.
[03:38:10] <elson> And, he seems to be right. I do homing with both velocities in the same direction, and I might have seen it glitch once, but it might have been a sticky indicator. I then changed it so it did the final search for the index pulse in the opposite direction, and I got very erratic home positions. On my system, it seemed to home in .020" quanta.
[03:38:56] <elson> So, I decided to update the Bridgeport to the current CVS, and I got a HAL error "setp requires 2 arguments, 3 given"
[03:39:40] <elson> This was a collection of configs files that worked before. I can't find this 3rd argument, even looked for non-printing chars on the line. Any ideas?
[03:41:12] <elson> anybody on?
[12:04:40] <jepler> halcmd: setp and2.0.in1 1
[12:04:40] <jepler> halcmd: setp and2.0.in1 1 a
[12:04:40] <jepler> HAL:5: setp requires 2 arguments, 3 given
[12:08:08] <jepler> aha
[12:08:18] <jepler> inifile: [S]X=1 1
[12:08:23] <jepler> setp and2.0.in1 [S]X
[12:16:31] <cradek> oops
[12:19:05] <jepler> hi ChanServ
[12:19:06] <jepler> er
[12:19:07] <jepler> hi cradek
[12:19:11] <cradek> hi
[12:19:15] <cradek> you at work already?
[12:19:25] <jepler> nope
[12:19:28] <jepler> got a slow start this morning
[12:19:43] <cradek> what are your plans for breakfast?
[12:20:09] <jepler> I dunno, I'd sure go to stauffer's around 8
[12:20:47] <jepler> I have really gotten a slow start this morning and should be doing anything but talking on IRC
[12:20:58] <cradek> sounds good to me. wonder if we should meet at work or there
[12:21:09] <jepler> I bet michael is already biking into work .. he'll need a ride from one of us
[12:21:16] <cradek> ok we'll meet at work
[12:21:22] <jepler> OK
[12:21:34] <jepler> I'll try to make it in by around 8
[12:21:39] <cradek> me too
[13:17:35] <alex_joni> heh
[13:18:42] <skunkworks> must be nice.. ;)
[13:28:02] <skunkworks> barry is all stitched up with a drain tube.. He seems to be doing fine.. Just looks like a hurting unit.
[14:10:55] <jepler> * jepler <-- back from stuffing himself with an omlette, hash browns, and biscuit
[14:15:02] <alex_joni> * alex_joni had a schnitzel the other day
[14:15:25] <alex_joni> although initially I could swear it's a pizza
[14:15:26] <alex_joni> http://81.196.65.201/~juve/ram/DSC00062.JPG
[14:18:58] <cradek> what is it?
[14:19:49] <jepler> it's not food
[14:20:19] <jepler> "Wiener schnitzel (from the German Wiener Schnitzel, meaning Viennese cutlet) is a traditional Vienna dish, consisting of a thin slice of veal or other light meat, coated in breadcrumbs and fried."
[14:21:02] <cradek> with french fries on top for good measure?
[14:21:04] <jepler> at least I think that's what we're talking about here
[14:24:50] <alex_joni> indeed
[14:25:14] <alex_joni> I might have ordered the wrong thing.. it was called gigantic schnitzel for a reason :/
[14:26:10] <skunkworks> sounds like country fried steak for breakfast
[14:27:35] <alex_joni> this was dinner, not breakfast.. and I had no food the next day :D
[14:29:18] <skunkworks> jepler: how did the stepper coding go? The_Ball may be a good one to test it..
[14:29:42] <jepler> skunkworks: I ran into a bunch of bugs
[14:29:55] <jepler> skunkworks: it's not ready yet by a longshot
[14:30:05] <skunkworks> :) thats ok..
[14:30:35] <jepler> at first everything seemed to be going so well, but then I started seeing weird behavior
[14:30:53] <skunkworks> I read a little bit of it.. but it was a bit over my head.
[14:33:44] <jepler> don't feel too bad
[14:34:54] <jepler> I do think I found one bug which would make speeds between 256 and 512 make the motor go backwards (wrong # of bits in one place) -- but that doesn't quite square with what I saw in halscope, unless I was misreading the display
[14:35:31] <jepler> but that's certainly the easiest explanation
[15:00:42] <cradek> that's not on my short list of things I think are silly about NGC...
[15:04:09] <skunkworks> It is one of those - cool - things that would probably only be used once.
[15:04:51] <cradek> it could be nice for some programatically generated gcode
[15:05:10] <cradek> but yeah, probably won't be used often.
[15:05:12] <skunkworks> if the post-processor supports it..
[15:05:19] <cradek> right
[15:06:50] <skunkworks> franken-barry seems to be doing ok so far. He was bright eye-ed and bushy tailed this morning.
[15:07:14] <cradek> he has good people looking after him
[16:04:19] <cradek> http://timeguy.com/cradek-files/emc/arbarc.png
[16:04:38] <cradek> ^ arc in the plane normal to (1,1,1)
[16:05:03] <cradek> the underlying code works, it's just a gcode issue
[16:09:15] <SWPadnos> cool
[16:09:43] <jepler> how silly and un-featureproof
[16:09:53] <SWPadnos> oh right - I fogot
[16:09:58] <SWPadnos> forgot, too
[16:10:09] <SWPadnos> a feature-proof future
[16:11:16] <cradek> I'm trying to wrap my head around a good representation for arbitrary helixes
[16:12:02] <SWPadnos> I think some controls allow you to specify an arbitrary plane with some G17/18/19-like code
[16:12:07] <SWPadnos> that may be a good way to do it
[16:12:34] <cradek> oh so set the plane first, in a separate gcode?
[16:12:39] <SWPadnos> yep
[16:12:52] <jepler> G17.1 "set plane for arcs"
[16:12:58] <jepler> or whatever number you want to assign
[16:13:00] <cradek> that only gives the normal then?
[16:13:19] <SWPadnos> well, you'd have to also specify an origin, I think (so it is more complex)
[16:13:32] <cradek> what do you mean origin?
[16:13:56] <SWPadnos> one sec - phone
[16:14:30] <cradek> I should work backward instead of forward - do the gcode last - that worked for uvw
[16:15:58] <jepler> the start point plus the normal gives you the plane of the arc
[16:16:34] <jepler> you can find how far off the plane the end point is, that gives the helicalness
[16:16:56] <jepler> and you can find the center in the same way as now given the start point, the plane, and the end point projected onto the plane (either with IJK or R)
[16:17:42] <cradek> that's where I was headed - the canon call would be start (implicit), normal, end, rotation (direction)
[16:17:53] <cradek> the end can be off the plane for a helix
[16:19:08] <cradek> rotation is like the existing canon call: positive is the right-hand arc etc
[16:20:36] <jepler> http://blog.modernmechanix.com/2007/07/06/psychology-and-the-instrument-panel/
[16:27:52] <Skullworks-PGAB> jepler: that same (cunfusion) issue is why they rotate all the gages in race cars so the "normal" has the needles pointing straight up.
[16:28:01] <cradek> I ran into this on the mazak. To move the quill up, you turn the jogwheel to the right (Z +). I never messed it up, but it's totally unnatural.
[16:28:59] <cradek> maybe that's natural to cnc folks, but to someone who is used to manual machines, it feels very wrong
[16:30:33] <SWPadnos> were you using your left hand on the Mazak?
[16:30:39] <cradek> no
[16:30:38] <SWPadnos> (or your right, if you're left-handed)
[16:30:41] <SWPadnos> ok
[16:30:51] <cradek> my left hand is even dumber than my right
[16:31:06] <SWPadnos> right - it's backwards, so it would feel natural to turn the wrong way :)
[16:32:20] <cradek> I guess Y is backwards from a manual machine too isn't it
[16:32:23] <SWPadnos> regarding origins - it isn't needed in plane selection - it would be a different feature
[16:32:37] <SWPadnos> the screw is left-handed on a BP
[16:32:44] <cradek> sure
[16:32:49] <SWPadnos> so it turns correctly
[16:32:59] <cradek> I mean on the jogwheel it's backwards
[16:33:04] <SWPadnos> ah - could be
[16:33:11] <cradek> cranking the jogwheel "in" causes the table to move "out"
[16:33:21] <cradek> * cradek shivers
[16:33:22] <SWPadnos> heh
[16:34:07] <cradek> ok three jogwheels mounted parallel to the three axes...
[16:34:49] <Skullworks-PGAB> Remember its all an illusion - the table never moves - the tool moves...
[16:35:19] <skunkworks> Skullworks-PGAB: exactly
[16:35:30] <SWPadnos> yeah yeah - frame of reference and all that
[16:35:34] <cradek> Skullworks-PGAB: I know how it works and how to figure it out, but I have to think about it each time and it feels unnatural
[16:35:43] <cradek> that's what jepler's article is about (preventing mistakes)
[16:35:56] <SWPadnos> it's easier if you're looking at a workpiece and tool
[16:36:37] <cradek> that's why mills have one RH screw and one LH on the table - to make it feel natural
[16:38:16] <skunkworks> I was just going to say that.
[16:39:08] <skunkworks> (in reference to the 3 jog wheels mounted on 3 sides of a box.)
[16:39:27] <cradek> yeah that's what I want
[16:39:39] <cradek> then they could all turn the "right" ways
[16:39:51] <cradek> and god help anyone else who tries to use it
[16:41:01] <skunkworks> one mounted on the top,side and front of the monitor ;)
[16:41:02] <Skullworks-PGAB> How about 1 MPG - but the wiring for axis select could invert A/B to provide the direction for the axis of choice...
[16:41:50] <cradek> yes that's definitely possible in HAL
[16:41:54] <Skullworks-PGAB> assumes a rotary switch
[16:42:02] <cradek> nah, do it in HAL
[16:42:21] <Skullworks-PGAB> that works (if you say so)
[16:43:39] <Skullworks-PGAB> what truely get me is people that make DIY machines and wire Z+ to be going down into the work...
[16:46:20] <cradek> I know it's not customary, but that is not surprising to me. If you turn a crank to drill a hole, what should the dial read? depth.
[16:51:56] <Skullworks-PGAB> yeah but 6th grade math taught |ABS|.
[22:41:58] <jepler> aha! the step generator was issuing more steps per servo cycle than could be correctly extended, due to the limited number of bits transmitted to emc
[22:42:16] <jepler> no wonder there was no particular logic in the *output* step rate which caused the problem
[23:16:47] <Skullworks-PGAB> kinda buffering the extra and dumping on the next cycle?
[23:18:20] <jepler> crap, I think the vertical deflection on my (borrowed) scope is broken
[23:19:13] <cradek> onoz
[23:19:22] <jepler> it will trigger on the signal from the 300mV square wave test point (so it's not that I've selected REF/GND on the scope probe or input) but nothing I can do (even adjusting "position" and "trace sep") moves the trace from the line where it falls
[23:19:34] <cradek> both channels?
[23:19:39] <jepler> yes
[23:19:55] <cradek> well crap
[23:20:39] <jepler> I used it some time in the month before fest, that's the last I remember
[23:23:04] <jepler> there are no surprising smells coming from it ..
[23:23:11] <jepler> cradek: I want my money back...
[23:23:19] <cradek> haha
[23:23:53] <cradek> if the position knob doesn't move it, the failure must be pretty close to the deflection output
[23:24:15] <cradek> might not be too hard to figure out what's gone wrong
[23:24:31] <cradek> would be best to have a schematic to see how the HV works though
[23:28:23] <cradek> there's something on bama - downloading it now
[23:28:39] <jepler> cradek: whee
[23:28:42] <jepler> you'll fix it for me, right?
[23:29:12] <jepler> OK, since I can't actually scope the step waveform, back to trusting the position feedback which I do think I've fixed
