Back
[01:22:01] <jepler> seb: corrected
[01:22:05] <jepler> that's a manually generated file.
[03:03:38] <KimK> While we're on the subject of docs (and while I wait for a reboot), I was going to ask if there is a source somewhere for the "G Code Quick Reference" card (gcode.html) I found the gcode.html file, but it seems (and I may regret saying this, but...) that there should be a source (LyX?) so that there can also be an easily printable PDF version. Comments? Advice? Bronx Cheers?
[03:12:31] <jepler> KimK: docs/html/gcode.html is handwritten.
[03:14:40] <jepler> it's been years since it fit in one column on one page
[03:17:26] <cradek> html is extremely easy to print - I dare say a pdf is harder
[03:18:53] <Jymmm> The output of printed html can be inconsistent compared to a printed pdf
[03:33:08] <KimK> I bring it up because I heard a request for a second g-code ref page in strict numerical order for lookup. It sounded like a good idea to me. The card now is grouped by function, which is also good, we keep that.
[03:33:26] <KimK> And also because we might want a source for other reasons, if it won't fit on one page anymore, maybe a duplex trifold on A3/legal/whatever? Like those Vim reference cards you see, very handy. And the Lyx source could be handled "automagically" as we are doing everything now.
[03:34:00] <KimK> Just something to think about
[03:36:47] <KimK> Maybe after the rush I'll put something together and post it for public derision?
[03:45:54] <KimK> Of course, maybe LyX *isn't* the best choice if the idea is to make sure it fits on one page/two pages. That could lead to a lot of lather, rinse, repeat. Maybe (and I'm just throwing ideas out here) this shouldn't be done in LyX, so if not LyX, than what? OOo Writer or Calc? Suggestions? Rejections? Public Rioting?
[03:47:29] <cradek> I'm afraid I have no useful suggestion - I don't know how to make it reformattable like you want.
[03:47:59] <cradek> I can sympathize with whoever wants a list in numeric order, though. it would be better for reverse-engineering gcode if you don't already know it well.
[03:54:08] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?WrappedRotaryAxes
[03:54:29] <cradek> ugh, someone (ahem) should document how this really works
[03:56:19] <CIA-2> EMC: 03cmorley 07v2.4_branch * r471643e574f5 10/src/emc/usr_intf/pncconf/pncconf.py: fix firmware directory names for 7i43 and 5i22
[04:34:21] <Jymmm> * Jymmm volunteers cradek to document how that really works!
[04:36:06] <Jymmm> Seriosusly? I'f think it would be the opposite....
[04:36:10] <Jymmm> # If the sign of the axis-word is "+", then the motion is counterclockwise
[04:36:10] <Jymmm> # If the sign of the axis word is "-", then the motion is clockwise
[04:36:44] <cradek> ccw is the positive angular direction in virtually the whole world except on clocks
[04:37:20] <Jymmm> I'm thinking compass.... 0 at 12oclock, 90 @ 3oclock, etc
[04:38:53] <cradek> in the math world, 0 is to the right, and angles increase counterclockwise
[04:39:33] <Jymmm> ah.
[04:39:49] <Jymmm> I was thinking this (and clocks)...
http://en.wikipedia.org/wiki/File:Kompas_Sofia.JPG
[04:43:36] <Jymmm> The EU Protractors are BOTH 0-180 and 180-0 =)
[04:48:56] <cradek> http://upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Unit_circle_angles_color.svg/720px-Unit_circle_angles_color.svg.png
[04:49:59] <Jymmm> zero @ 3oclock too
[06:28:39] <KimK> If any developer can tell me what the "debug" numbers mean in ClassicLadder's "Sections Manager", I will be happy to add the information to the docs. Screenshot:
http://imagebin.ca/view/TibErk.html Of F=, L=, P=, the only pattern I see is that P is always =0. F and L have no pattern that I can see as far as big/small, complex/simple, etc.
[14:32:18] <skunkworks> jepler: Do you happen to remember what classic ladder was missing for the print button to work? Some package? Random? ;)
[14:53:11] <jepler> skunkworks: AC_MSG_CHECKING(for libgnomeprintui-2.2)
[14:53:15] <jepler> AC_MSG_RESULT(no -- printing from classicladder will not be possible)
[14:53:20] <jepler> looks like it's libgnomeprintui
[14:53:33] <skunkworks> thanks!
[15:00:03] <jepler> -dev
[15:09:50] <mhaberler> jepler: thanks for exhaustive git answer.. I had always done a git pull -rebase and somehow missed that change
[15:10:06] <jepler> mhaberler: I hope it clarified more than it confused
[15:10:48] <mhaberler> I have to do more reading on git - it really blows svn and cvs away but the rope is still a bit long for me.
[15:42:55] <jepler> it sure wouldn't suck to have floating-point support in rtapi_printf. it only sucks to implement it.
[15:48:57] <jepler> dtoa is the go-to implementation of float->ascii conversions .. only problems are that it performs memory allocations and seems to run for 17000 to 40000 CPU cycles on this system (5-13us @ 3.16GHz)
[15:50:40] <psha> jepler: dtoa seem to be composition of two itoa and one float format parsing
[15:50:42] <psha> is not it?
[15:51:36] <jepler> psha: converting the mantissa of a floating-point number accurately to decimal is very hard to get right in all cases
[15:53:11] <psha> hm, i have to refresh memory about it...
[15:53:18] <jepler> I recommend this paper:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.164.813&rep=rep1&type=pdf
[15:53:35] <jepler> er, that's not the one I wanted
[15:54:17] <jepler> I think this is the one:
http://kurtstephens.com/files/p372-steele.pdf
[15:54:51] <jepler> I've never implemented the algorithm, rather the paper convinced me to find a ready-made implementation based on the paper's algorithm (dtoa/gdtoa)
[15:54:59] <jepler> .. for a non-emc2 project, that is
[15:55:07] <psha> i'll first glance trough 754 format specs...
[16:01:11] <psha> yes, key word is 'accurate' :)
[16:01:44] <psha> it's not that easy to decide how to round number as i expected...
[16:01:46] <jepler> yes, I'm sure there are tons of fast but wrong conversions
[16:02:11] <jepler> bbl, meeting
[16:19:02] <jepler> tempting to write a %A formatter for kernel space. It's easy to convert that to decimal in userspace, unlike the current hex representation.
[16:19:06] <jepler> $ printf '%f\n' 0XC.8F5C28F5C28F5C3P-2
[16:19:08] <jepler> 3.140000
[16:42:31] <cradek> I don't know what you're talking about, but that looks a lot more useful
[16:48:58] <cradek> seems easy to make a filter to make it human-readable
[16:49:22] <cradek> dmesg | scripts/fix-my-%f-please
[16:54:32] <jepler> here's %A-like formatter
http://emergent.unpy.net/files/sandbox/fp_a.c in case someone wants to fit it into rtapi_snprintf while my back's turned
[16:54:42] <jepler> bbl again
[17:14:19] <jepler> huh, it's a bit to my surprise that the exponent in a %A-format is in decimal. $ printf '%A %A\n' $((2**12)) $((2**13))
[17:14:22] <jepler> 0X8P+9 0X8P+10
