Back
[01:02:15] <jmkasunich> this is disturbing - nothing has changed (that I know of), but my machine is now stalling during rapids
[01:02:55] <SWPadnos> temperature?
[01:05:04] <jmkasunich> seems unlikely
[01:06:29] <SWPadnos> true, it's in the basement
[01:09:34] <cradek> both axes?
[01:23:35] <jmkasunich> so far I've seen it only on X
[01:23:51] <SWPadnos> the hard one
[01:23:56] <jmkasunich> lathe x
[01:23:58] <jmkasunich> the table
[01:24:19] <SWPadnos> oh
[01:24:32] <jmkasunich> steppers sucj
[01:24:36] <jmkasunich> k
[02:07:58] <jepler> speaking of steppers and them sucking, pluto-step has a dynamic error that is about 2 * velocity * servorate (e.g., around .0008 inches at 48 in/min and .5ms servo). Is this a level of error at which I should just shrug and move on, or should I fix it by changing the control loop inside the pluto_step hal drivre?
[02:08:56] <jepler> in the case of my system this is a much smaller effect than, say, the backlash ..
[02:09:03] <jepler> probably smaller than screw irregularity
[02:09:18] <SWPadnos> I don't understand what the error actually is - can you post a scope trace or reword that description? ;)
[02:09:34] <jepler> it's following error
[02:09:50] <SWPadnos> oscillating around 0?
[02:10:54] <jepler> no, during a move. always the same sign.
[02:11:18] <SWPadnos> ok, so it goes to some calue then stays constant (relative to speed)?
[02:11:20] <SWPadnos> value
[02:11:43] <SWPadnos> pluto is lagging the command?
[02:12:13] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pluto-ferror.png
[02:12:14] <jepler> yes
[02:12:24] <jepler> I can't get a good trace that shows it, but -fb is lagging -cmd
[02:12:41] <SWPadnos> ok, that makes sense
[02:12:53] <SWPadnos> I suspect it's a latency problem
[02:13:33] <SWPadnos> scope.sample is at the end of the thread, axis.n.motor-pos-cmd is already updated, but the feedback isn't yet
[02:14:07] <jepler> but axis.0.f-error is "real"
[02:14:21] <SWPadnos> oh, true
[02:14:28] <jepler> and anyway that would account for one cycle of offset
[02:14:31] <jepler> but there is about 2
[02:14:34] <SWPadnos> if the step rate commands are clocked into the pluto by the driver, then the new rate doesn't take effect until the end of the thread though
[02:14:48] <SWPadnos> it's the USB cycle time problem, only faster :)
[02:14:51] <jepler> heh
[02:16:16] <jepler> actually pluto-step seems to work quite well. the "stopped" error is <1 step (it has sub-step "accuracy" like stepgen), and the "moving" error is small compared to the slop in the machine
[02:16:44] <SWPadnos> is it used like that USC, ie with PID?
[02:16:47] <SWPadnos> that is cool
[02:16:57] <SWPadnos> s/that/the/
[02:17:27] <jepler> it is more like stepgen -- the position loop is inside the HAL component, and there is no user tuning
[02:17:44] <SWPadnos> ok
[02:17:45] <jepler> but otherwise it's like USC -- a frequency command goes to the FPGA, and a position feedback comes from the FPGA
[02:17:54] <jepler> all my best ideas are stolen
[02:18:07] <SWPadnos> right - I was wondering about FF0 (or FF1 or whatever it is)
[02:18:10] <SWPadnos> heh
[02:19:24] <jepler> the position loop should read as follows: /* copy from stepgen, except that jmkasunich went over my head -- oh and no accel constraints, oops! */
[02:19:50] <SWPadnos> heh
[02:19:59] <SWPadnos> the FPGA should slew from one rate to the next ;)
[02:20:05] <jepler> that's funny
[02:20:13] <jepler> I already used all 500 FF+LUTs
[02:20:17] <SWPadnos> heh
[02:20:38] <jepler> hm actually there is a knob you can turn: v = v - debug_2 * est_err / fperiod;
[02:21:01] <jepler> double v = new_position_cmd - data.old_position_cmd[i];
[02:21:02] <jepler> double est_err = stepgen_position_fb(i) + data.old_velocity_cmd[i] * fperiod - new_position_cmd;
[02:22:07] <SWPadnos> is that a paste (or two)?
[02:22:08] <jepler> I understand this even less well now than when I wrote it
[02:22:22] <jepler> that's two pastes, it put things a bit out of order (first line comes last)
[02:22:25] <SWPadnos> right
[02:22:37] <SWPadnos> I'm just wondering why new_position_cmd isn't subscripted
[02:22:57] <jepler> double new_position_cmd = stepgen_position_cmd(i);
[02:23:02] <jepler> it's referred to several times so I pull it into a local
[02:23:07] <SWPadnos> ok
[02:23:44] <SWPadnos> I think you can get rid of that est_error stuff - that should be to compensate for acceleration, which pluto doesn't do
[02:23:49] <SWPadnos> just use v
[02:23:53] <jepler> actually, I think I've convinced myself not to touch it
[02:23:57] <SWPadnos> heh
[02:24:32] <jepler> this servo motor I bought from you doesn't make a bad jog wheel
[02:24:37] <SWPadnos> heh
[02:24:50] <SWPadnos> it's the right shape to stick on a panel
[02:24:52] <SWPadnos> a big panel
[02:24:56] <jepler> a real big panel
[02:25:02] <jepler> you sold all of these motors, right?
[02:25:16] <SWPadnos> no, I still have 6
[02:25:20] <jepler> oh, hm
[02:25:42] <jepler> chris was threatening to make a new circuit board milling machine for himself, and I was thinking these motors might be good ones
[02:25:52] <jepler> but then I'd have to give up my jog wheel
[02:26:05] <SWPadnos> hah
[02:26:29] <jepler> soft limits are great but I think I need to write a userspace component to go "thunk" when you hit one
[02:26:33] <SWPadnos> well, if he actually does get far enough to need motors, you guys can let me know. I don't expect to sell any more until next year
[02:26:45] <SWPadnos> a coconut shell sound
[02:29:46] <jepler> yeah that's the ticket
[02:30:34] <SWPadnos> I think that line you pasted is the culprit actually - it subtracts a little from V
[02:33:15] <jepler> the power-up value for debug_2 is 0.5. setting debug_2 = 0, it ferrors. setting debug_2 = 1, it whines a little like a hunting servo.
[02:33:54] <jepler> I think est_err is negated compared to what you expected
[02:34:00] <SWPadnos> could be
[02:35:02] <SWPadnos> what's pluto_step.tmax?
[02:35:28] <SWPadnos> err - put a read and a write in there somewhere
[02:37:05] <jepler> http://pastebin.com/m3975f2d0 (machine is 2.1GHz)
[02:38:51] <jepler> yuck:
http://emergent.unpy.net/index.cgi-files/sandbox/oscillation.png (setting debug_2 too high causes this)
[02:39:27] <SWPadnos> it could be timing related, but if it stays constant during long moves, that leads me toward a calculation error
[02:39:36] <jepler> or just phase shift
[02:39:37] <SWPadnos> yow
[02:40:23] <jepler> I think I want to go back to earlier, where I didn't care abuot this
[02:40:28] <SWPadnos> sure - you can see in that trace that it's ping-ponging around some value (changing every cycle)
[02:40:30] <SWPadnos> heh
[02:41:57] <SWPadnos> you should set v (or old_velocity) to a value calculated from the final rate sent to the pluto
[02:45:03] <jmkasunich> jepler: what is scripts/latency-test?
[02:45:30] <SWPadnos> it pops up a dialog with HAL latency numbers
[02:45:32] <jmkasunich> attempting to run it did strange ane meaningless things, is it intended to be invoked from stepconf or something?
[02:46:00] <SWPadnos> you may need emc-environment for it to work correctly (unless it's installed)
[02:46:05] <jmkasunich> no dialog, just a series of lines in the shell with "." on each one
[02:46:22] <SWPadnos> emc-environment
[02:46:29] <jmkasunich> I'm about 95% sure I did the emc-env thing, lemme try again
[02:46:38] <SWPadnos> I think those are "waiting for stuff to load" prints
[02:46:44] <jepler> you didn't run it while emc was running, did you?
[02:47:37] <jepler> um, the realtime script and/or halcmd will print dots while waiting for something -- I think 'loadusr -W' will print dots, for instance
[02:47:55] <jmkasunich> I don't know what I did wrong, but its working now
[02:47:57] <jepler> huh
[02:48:13] <jmkasunich> eww, 300uS on the base thread
[02:48:22] <SWPadnos> that's a long time
[02:48:27] <jmkasunich> yes, it is
[02:48:29] <jepler> did you lose your smi fix somehow?
[02:48:44] <jmkasunich> good question
[02:49:13] <jmkasunich> ah, I bet thats it - this is a RIP cvs checkout, not the installed version
[02:49:29] <jepler> flowsnake really hurts on a machine with backlash comp
[02:49:44] <SWPadnos> heh
[02:49:56] <SWPadnos> or it looks like crap on a machine with a lot of uncompensated backlash
[02:50:18] <jepler> both are probably true
[02:50:27] <jepler> well I have no idea how this looks .. it might still look like crap
[02:51:29] <SWPadnos> re: pluto-step, I think the debug_2 sensitivity is because the old vel is saved as the ideal number, not the actual number sent to the pluto
[02:51:51] <jepler> good news is it kept position during flowsnake
[02:56:49] <SWPadnos> interesting - this dell has good latencies when run remotely
[02:56:55] <jmkasunich> looks like smi fixed the problem
[02:57:09] <SWPadnos> I think it wasn't as good with the local X server
[02:57:41] <jepler> goodnight all
[02:57:47] <SWPadnos> see you
[02:59:41] <jmkasunich> crap, not fixed
[02:59:47] <jmkasunich> goodnight
[03:12:52] <jmkasunich> hmm, undocumented HAL pins
[03:13:04] <SWPadnos> heh
[03:13:08] <jmkasunich> motion.spindle-speed-in
[03:13:22] <SWPadnos> I think it isn't hooked to anything yet
[03:13:27] <jmkasunich> used for feed per rev I believe
[03:13:27] <SWPadnos> not sure though
[03:13:48] <SWPadnos> oh, I must be thinking of spindle-at-speed or something like that
[03:14:01] <SWPadnos> (which may not even exist ;) )
[03:14:11] <jmkasunich> spindle-speed-out is RPM, I wonder what the units of spindle-speed-in are?
[03:14:21] <SWPadnos> RPS
[03:14:33] <SWPadnos> you have to scale by 1/60 outside, IIRC
[03:15:03] <jmkasunich> well, if it is coming from the encoder module it will already be in rps
[03:15:31] <SWPadnos> ok, it's RPM - you have to scale it from the encoder output
[03:15:39] <SWPadnos> I knew there was scaling in there somewhere :)
[03:16:04] <SWPadnos> hmmm. no, it's RPS
[03:16:13] <SWPadnos> sorry - looking at sim/lathe.hal
[03:16:29] <SWPadnos> rps goes to spindle-speed-in
[03:18:46] <jmkasunich> yeah (I tried it)
[03:43:09] <jmkasunich> weird - G76 with a P word of 0.020 (50 tpi) is moving much faster in Z than it should
[03:43:20] <SWPadnos> I thought K was the thread pitch
[03:43:25] <SWPadnos> or is that for rigid tapping?
[03:43:37] <jmkasunich> K is for G33
[03:43:43] <jmkasunich> and 33.1
[03:43:45] <SWPadnos> whatever that is ;)
[03:44:02] <jmkasunich> 33 = a single synced move, 33.1 = rigid tap
[03:44:07] <jmkasunich> 76 = threading canned cycle
[03:44:17] <SWPadnos> ok
[03:44:33] <SWPadnos> it isn't 60 times faster is it? :)
[03:44:51] <jmkasunich> 60x faster is well past rapid
[03:44:58] <jmkasunich> its running at rapid, so I can't rule that out
[03:45:20] <jmkasunich> but threading moves aren't controlled by spindle-speed-in, they're controlled by spindle-position
[03:45:29] <SWPadnos> true
[03:50:22] <SWPadnos> weird. emd2-dev is installed, and i just did build-dep emc2, and I still have no cvs
[03:50:42] <SWPadnos> I figured that would be pulled in somewhere, but I guess it isn't strictly necessary
[03:51:00] <jmkasunich> nope, you might have gotten the code from a tarball
[03:59:42] <jmkasunich> this is freaky
[04:00:08] <jmkasunich> motion doesn't seem to be asserting spindle-index-enable at the start of each threading pass
[04:02:30] <SWPadnos> are all the moves in the loop (I'm assuming you're looping) synch moves?
[04:02:38] <SWPadnos> or is the return non-synched?
[04:02:47] <jmkasunich> I'm using G76, the looping is in the canned cycle
[04:02:49] <SWPadnos> oh wait, you're using a canned cycle - nevermind
[04:03:41] <jmkasunich> G33 shows the same thing
[04:07:10] <jmkasunich> actually, its like the synced moves are being completely ignored
[04:08:01] <jmkasunich> why am I having a deja vu? I think this happened once before
[04:08:03] <SWPadnos> I'd think that would make synchronized moves not work, so I wonder about your testing
[04:08:12] <SWPadnos> emc-environment? :)
[04:08:41] <jmkasunich> I'm almost certain I ran it
[04:09:34] <SWPadnos> run-in-place should refuse to run if it doesn't detect some of the settings emc-environment sets up
[04:09:45] <SWPadnos> unless they're there anyway for an installed system, of course
[04:10:46] <jmkasunich> I'm pretty sure that isn't it
[04:11:53] <jmkasunich> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-08.txt
[04:11:58] <jmkasunich> I was right - deja vu
[04:12:48] <SWPadnos> that was feed rate related though
[04:13:14] <jmkasunich> and this program, like that one, doesn't set an F value, because the only moves are G0 and the threading
[04:13:23] <SWPadnos> ah
[04:13:26] <SWPadnos> don't do that :)
[04:14:00] <SWPadnos> I think when I looked at it, it seemed like it's not an easy fix
[04:14:39] <SWPadnos> though I don't recall the specifics
[04:16:06] <jmkasunich> yep, putting an F1 in the program fixes it
[04:16:27] <SWPadnos> did either of us ever file a bug report for that one?
[04:18:55] <jmkasunich> probably not
[04:31:17] <SWPadnos> bed time. night
[04:32:51] <jmkasunich> night
[04:45:17] <jmkasunich> I'm not going to be able to test the effect of spindle speed droop
[04:45:38] <jmkasunich> any cut that is near heavy enough to slow the spindle causes work deflection
[12:17:38] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile): Fixed intro in integrator manual
[12:17:53] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/integrator_intro.lyx: Fixed intro in integrator manual
[12:19:00] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile): fixed integrator intro
[12:19:10] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/integrator_intro.lyx: fixed integrator intro
[12:36:50] <BigJohnT> hmmm, when I go to CVS and show only files with tag: v2_2_branch docs/src/examples/spindle.lyx does not show up. It does show up in trunk
[12:37:08] <BigJohnT> did I miss something?
[12:45:44] <rayh> I see the same here. The examples directory is there but nothing is in it.
[12:47:09] <BigJohnT> hmmm
[12:47:51] <BigJohnT> morning Ray
[12:48:44] <rayh> Hi John
[12:50:30] <rayh> In the commit message for spindle.lyx I don't see that it was added to the 2.2 branch.
[12:50:58] <BigJohnT> I could not find it either...
[12:51:20] <BigJohnT> I just edited the file to see if it will commit now
[12:51:44] <BigJohnT> nope
[12:52:32] <BigJohnT> "/emc2-2.2.x/docs$ cvs -z5 diff -u" gives me "? src/examples"
[12:56:44] <rayh> I see that latex is still complaining about our using titles the way we do.
[12:57:01] <BigJohnT> hows that?
[12:57:40] <BigJohnT> Jeff added this to trunk /docs/submakefile "$(filter objects/examples_%.xml,$(DOC_TARGETS_XML)): objects/examples_%.xml: $(DOC_SRCDIR)/examples/%.lyx $(XMLDEP)
[12:57:42] <BigJohnT> $(call lyx2xml,examples,$*,$<)"
[12:58:00] <BigJohnT> wonder if I need to add it to the branch?
[12:58:06] <rayh> There is some sort of "issue" with the EMC2 image in the title block. It does it fine but doesn't like doing it.
[12:58:16] <jepler> BigJohnT: you may after you add the new file in the new directory to 2.2
[12:58:27] <jepler> BigJohnT: I'm trying to figure out what step you need to do to successfully add it..
[12:58:36] <BigJohnT> ok
[13:00:28] <jepler> BigJohnT: move your newly-created examples directory to a different name (examples.1). then: cvs -f up -d examples. move the new lyx files into the new examples directory. now you should be able to "cvs add" it. remove the examples.1 directory when you no longer need it
[13:00:53] <BigJohnT> ok thanks
[13:10:55] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/spindle.lyx: added spindle chapter
[13:11:15] <BigJohnT> ok, thanks jepler that worked
[13:12:19] <jepler> BigJohnT: OK good
[13:15:47] <jepler> BigJohnT: same fix is now needed in the 2.2 Submakefile; I'll check it in in a second.
[13:16:04] <BigJohnT> I was about to do it
[13:16:07] <BigJohnT> :)
[13:16:11] <CIA-34> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/Submakefile: from TRUNK: new documentation directory
[13:16:25] <BigJohnT> you beat me too it :)
[13:17:04] <jepler> hope your toes don't feel too stepped on
[13:17:20] <BigJohnT> not at all thanks for the help
[13:19:05] <jepler> see you later; it's breakfast time here
[13:19:11] <BigJohnT> ok
[15:42:25] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/spindle.lyx: fixed formatting
[15:42:56] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: fixed formatting
[15:42:57] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/spindle.lyx: fixed formatting
[15:56:31] <SWPadnos> in case you didn't get that far in the IRC log, it was the change from rev 1.122 to 1.123 that caused the problem
[15:57:40] <cradek> oh, ick.
[15:58:20] <SWPadnos> yes
[15:58:50] <cradek> now where is my knobkerrie
[15:59:10] <jmkasunich> for mung?
[15:59:23] <cradek> and for emccanon.cc
[16:00:51] <SWPadnos> I wonder if getStraightAcceleration is needed on synch moves
[16:01:53] <cradek> I'm thinking along those lines too.
[16:04:24] <rayh> Hi guys.
[16:04:30] <cradek> hi
[16:04:34] <SWPadnos> hi Ray
[16:05:24] <rayh> I stuck my foot in my mouth on cnczone last night with respect to PyVCP and relative numbers.
[16:05:43] <SWPadnos> how did it taste? :)
[16:05:56] <rayh> So I modified halui.cc this morning and added relative pins.
[16:07:31] <rayh> someone want to test my work before we make any changes to the official source.
[16:07:52] <SWPadnos> you can change the DRO size in AXIS
[16:08:23] <rayh> yes we can but that is not the issue I was addressing.
[16:08:34] <SWPadnos> still reading the thread :)
[16:08:55] <cradek> sorry I don't yet understand what you added
[16:08:56] <rayh> And I would like to see an axis change font menu item.
[16:09:20] <rayh> I added relative position pins to halui.
[16:09:42] <rayh> I asked alex about it but have not gotten an answer yet.
[16:09:44] <cradek> oh! that sounds great.
[16:09:54] <cradek> I didn't know it was missing.
[16:11:46] <cradek> for a font change in AXIS we'd probably want to scale all the little indicator bitmaps too. That makes it a little harder but not impossible.
[16:12:12] <cradek> I think there are only two: homed and on limit switch
[16:12:34] <rayh> I know nothing of writing this kind of code so modeled from xemc.cc, copied, pasted, and changed axis names.
[16:12:41] <SWPadnos> heh
[16:12:54] <rayh> Yes you are right about scaling those. I didn't think of that.
[16:13:16] <SWPadnos> are those (or similar) glyphs available in some scalable font?
[16:13:51] <cradek> no, those are hand-generated and not in a font
[16:14:40] <cradek> rayh: want to put a patch on pastebin? other than just checking it in that seems the easiest way for someone to review it
[16:15:03] <rayh> Um. How do I create a patch?
[16:15:17] <cradek> cvs diff -u halui.cc
[16:15:55] <rayh> okay.
[16:16:21] <cradek> but if it is working, you have probably already done it right...
[16:16:50] <SWPadnos> there are similar glyphs in these sets:
http://www.unicode.org/charts/PDF/U2980.pdf http://www.unicode.org/charts/PDF/U2B00.pdf http://www.unicode.org/charts/PDF/U2A00.pdf
[16:19:42] <SWPadnos> ooooh - 2345-2438 look good here:
http://www.unicode.org/charts/PDF/U2300.pdf
[16:20:25] <SWPadnos> and maybe 233E or 2388 for homed
[16:20:54] <cradek> neither of those look like an origin symbol to me
[16:21:13] <jmkasunich> 2388 is an isometric view of a 3D origin ;-)
[16:21:13] <cradek> (I'd be surprised if unicode didn't have the right symbol)
[16:21:16] <SWPadnos> the symbol could be a house - it doesn't have to be an origin
[16:21:24] <SWPadnos> yes, 2388 did look like a 3-D origin
[16:21:28] <cradek> SWPadnos: you're mistaken about that :-)
[16:21:53] <SWPadnos> heh
[16:22:02] <SWPadnos> ok, so there are other constraints, huh? ;)
[16:22:10] <jmkasunich> 2347 and 2348 seem reasonable for limits
[16:22:15] <jmkasunich> "you are at the edge of the box"
[16:22:34] <cradek> I agree
[16:22:47] <SWPadnos> ah-ha! 21E4 and 21E5:
http://www.unicode.org/charts/PDF/U2190.pdf
[16:22:54] <jepler> there's no guarantee that any particular font will have all those symbols, though
[16:23:03] <SWPadnos> true
[16:23:08] <cradek> I was about to say we'd have to ask jepler if we can use any of this.
[16:23:37] <cradek> haha 21AD
[16:23:51] <SWPadnos> "following error"
[16:24:05] <cradek> 21AF: "amplifier fault"
[16:24:06] <jmkasunich> 21B9
[16:24:10] <SWPadnos> 21B9 is there too, for "both limits" :)
[16:24:14] <SWPadnos> right
[16:24:54] <jmkasunich> the limit icons in axis don't tell you which limit do they?
[16:25:07] <cradek> nope
[16:25:24] <cradek> is that information available now? it would be nice if they did.
[16:25:34] <cradek> (it wasn't available when we did that)
[16:25:34] <jepler> I know it's a cliche, but I'm too busy to look into this right now
[16:25:34] <SWPadnos> could SVG images be used?
[16:25:42] <jmkasunich> no idea
[16:25:45] <SWPadnos> heh - enjoy your trip :)
[16:28:34] <cradek> for a couple more choices of [traditional X] fonts, scaling those few bitmaps by hand would be foolproof
[16:31:06] <cradek> even one big bold font like 10x20 might be enough to make people happier.
[16:31:31] <jmkasunich> what is the current font?
[16:31:59] <jmkasunich> s/what/how big
[16:32:06] <cradek> looks like it's 9x15
[16:32:13] <cradek> hmm, 10x20 isn't as big as it used to be
[16:32:25] <cradek> it is much bolder though.
[16:32:26] <jmkasunich> heh
[16:33:10] <jmkasunich> somebody shrunk the pixels
[16:33:37] <cradek> there is 12x24
[16:33:51] <cradek> ugh, it's ugly though
[16:33:58] <jmkasunich> is there by any chance n x 30?
[16:34:15] <cradek> 12x24 is the biggest I see in 'misc'
[16:34:19] <jmkasunich> ah
[16:34:39] <jmkasunich> I was thinking if you could get 18x30 or 20x30 or something, you could just double the icons
[16:35:02] <cradek> true. but it would be simple to redraw them too.
[16:35:19] <jmkasunich> and it would look better
[16:35:27] <cradek> yes
[16:36:05] <jmkasunich> those m x n fonts are all monospaced, right?
[16:36:08] <cradek> yes
[16:36:10] <jepler> cradek: scalable fonts should work fine too
[16:36:29] <jmkasunich> I imagine those unicode things that swp found are not monospaced
[16:36:42] <cradek> jepler: don't they do various things based on dpi etc?
[16:37:25] <cradek> (I guess that's a feature, but it makes it hard to match a bitmap to the font.)
[16:37:45] <jepler> cradek: you can find the pixel height of the font fairly easily
[16:38:12] <jepler> coordinate_linespace = int(coordinate_font_metrics[linespace_index+1])
[16:38:27] <cradek> bbl...
[16:38:31] <cradek> jepler: go pack!
[16:38:34] <cradek> and have a safe and fun trip
[16:38:49] <jepler> thanks
[16:38:56] <jmkasunich> ditto
[16:39:48] <SWPadnos> heh
[16:40:00] <SWPadnos> just noticed the GPIO driver - cool
[16:40:15] <SWPadnos> I wonder how well it works WRT realtime
[16:43:43] <jmkasunich> biab
[16:53:22] <rayh> http://www.pastebin.ca/1063083
[16:59:33] <jepler> rayh: that change looks plausible
[17:00:44] <rayh> Okay. Should this be included in 2.2 or only trunk?
[17:03:30] <jepler> rayh: I think this would be OK for 2.2 if it gets tested first.
[17:04:34] <rayh> Okay. I'll commit to trunk and then when others have tested/revised we can get it in the next release.
[17:05:09] <rayh> Thanks but aren't you supposed to be packing, jepler ;
[17:09:29] <jepler> rayh: I have trouble taking good advice
[17:09:42] <CIA-34> EMC: 03rayh 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: added relative position pins
[17:09:57] <rayh> Hey have a good trip, guy.
[18:36:51] <BigJohnT> rayh: is halui.axis.n.pos-relative for making a big DRO?
[18:39:16] <SWPadnos> it's so pyvcp displays can show the same number as the AXIS (or other UI) displays
[18:40:07] <BigJohnT> ok cool
[18:41:51] <BigJohnT> I noticed that when you touch off .pos-relative gives you a wierd number
[18:42:04] <BigJohnT> until you move
[18:42:25] <SWPadnos> odd
[18:43:12] <BigJohnT> 4.400171e-06
[18:43:57] <BigJohnT> then if i move 0.0001 it displays 0.0001001798
[18:45:09] <rayh> Yep.
[18:45:42] <rayh> small number. I saw that as well.
[18:45:47] <SWPadnos> sounds like a formatting problem - the 4.4...e-06 should print as 0.000
[18:46:10] <SWPadnos> does pyvcp have a format string for the printed value?
[18:46:24] <rayh> I also see that my fix does not compensate for tool length on z
[18:56:43] <alex_joni> rayh: that's a pita to do right
[18:56:52] <alex_joni> imo this shouldn't come from halui
[18:57:03] <alex_joni> it's more likely something from the GUI
[18:57:17] <alex_joni> (based on user settings .. etc)
[19:02:25] <alex_joni> but then again.. what do I know :)
[19:08:57] <alex_joni> 2638 is nice for a home symbol
[19:09:02] <alex_joni> "wheel of dharma"
[19:09:23] <alex_joni> http://www.decodeunicode.org/u+2638
[19:11:51] <BigJohnT> so it can be scaled?
[19:14:05] <alex_joni> if it's available in a font.. yeah
[19:14:13] <BigJohnT> cool
[19:21:17] <BigJohnT> * BigJohnT is off to shoot holes in some paper and maybe blow something up
[19:48:18] <cradek> rayh: if you add in tool offset, be sure you get all of X,Z,W
[19:48:47] <rayh> okay.
[19:49:29] <rayh> X would just be diameter offse
[19:49:32] <rayh> t
[19:50:35] <rayh> I don't know that we show this in X pos.
[19:51:11] <rayh> But for w we should have it.
[19:53:55] <cradek> nope, on lathes tool "length" offset can be in X,Z
[19:54:37] <cradek> g43 can give both X,Z on a lathe
[19:56:51] <rayh> Okay.
[19:57:41] <cradek> thanks for doing this. I hope to try putting a position display on the front panel of my mill when I convert it.
[19:57:45] <rayh> I suppose you'd want to see it show the finished diameter.
[19:58:12] <rayh> Ah. That sounds like a good use for the hal display stuff.
[21:03:29] <SWPadnos> I wonder if motion (or something else) should just output the appropriate coordinates
