Back
[06:51:48] <jthornton> arceye has an arc tolerance patch if anyone would like to look at it
http://linuxcnc.org/index.php/english/forum/20-g-code/28689-arc-tolerance#54258
[08:21:37] <cncuser> hey guys, for the last couple weeks, my dropbox-client has stopped responding under linuxcnc 2.5.3, and linuxcnc 2.6.5. Resinstallation of dropbox-nautilus and from the official dropbox page delivers errors upon start of dropbox. Does anyone have the same issue here?
[08:22:36] <cncuser> Traceback (most recent call last):
[08:22:37] <cncuser> File "dropbox/callbacks.py", line 92, in run_handlers
[08:22:38] <cncuser> File "dropbox/client/high_trace.py", line 794, in trace
[08:22:40] <cncuser> File "dropbox/client/high_trace.py", line 691, in trace
[08:22:41] <cncuser> ValueError: cannot convert float NaN to integer
[08:22:43] <cncuser> Traceback (most recent call last):
[08:22:44] <cncuser> File "dropbox/callbacks.py", line 92, in run_handlers
[08:22:46] <cncuser> File "dropbox/client/high_trace.py", line 794, in trace
[08:22:47] <cncuser> File "dropbox/client/high_trace.py", line 691, in trace
[08:22:49] <cncuser> ValueError: cannot convert float NaN to integer
[08:36:40] <cradek> I don't understand why you think that problem is related to linuxcnc
[09:01:37] <cncuser> I'm currently trying to narrow down my problem, in order to see if that is computer-related or a general problem. Since that problem persists over several versions of linuxcnc with different kernels, I thought I'd ask around
[09:02:16] <seb_kuzminsky> jthornton: i put this commit in 2.7 a few days ago:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=2cc22013dfdbd33ceba36570ed78711e0d310e99;hp=4fee078a2f30f2d81b7440f531f56780b852969d
[09:28:15] <cradek> cncuser: your error message is all over the googles
[09:32:11] <seb_kuzminsky> zlog:
[09:40:25] <seb_kuzminsky> jthornton: hrm, but even with that patch the jer10b.ngc program from ctrl-freq doesn't run
[09:40:45] <seb_kuzminsky> abs_err=0.0006257 rel_err=0.1894%
[09:40:51] <seb_kuzminsky> on one of those tiny arcs
[10:06:40] <cradek> I think the TP does circularize arcs
[10:07:20] <cradek> it moves the center point
[10:10:58] <pcw_home> it fudges to make the end points match?
[10:11:08] <cradek> yes
[10:11:27] <cradek> so I don't think we actually get spirals anymore (the old planner gave us spirals)
[10:11:49] <cradek> I'm going to open up the tolerance and see what it does
[10:19:12] <cradek> weird, I don't get a circle OR the spiral I expect
[10:27:42] <mozmck> does anyone here use the xhc-hb04 pendant? I don't have one, but I was looking at the code for the component and found a memory leak.
[10:30:11] <mozmck> in setup_asynch_transfer() a new transfer struct is allocated, and that function is called after each packet is received. But the transfer is only freed once when the program exits
[10:30:28] <cradek> eek
[10:31:55] <mozmck> There are at least two ways to handle it properly. One is to free the transfer at the end of cb_response_in() just before calling setup_asynch_transfer() again. Another is to set the flag in libusb to auto-free the transfer when finished.
[10:32:53] <mozmck> And another is to simply re-use the same transfer if you are sure that last transfer is finished, which looks to be the case here.
[10:33:31] <mozmck> That is best since you don't have to allocate and free memory for each transfer.
[10:36:32] <seb_kuzminsky> mozmck: i'm helping a friend build a machine with that pendant (the wireless kind)
[10:36:36] <seb_kuzminsky> i haven't looked at the code
[10:37:02] <mozmck> seb_kuzminsky: so if I make a little patch y'all can test it?
[10:39:13] <seb_kuzminsky> yes, i'd love that
[10:39:24] <seb_kuzminsky> do you have the wired or wireless kind?
[10:39:31] <mozmck> ok. I don't have any!
[10:39:37] <seb_kuzminsky> oh
[10:39:47] <seb_kuzminsky> oh, you said that, duh
[10:39:59] <mozmck> I was looking at component code as documentation and examples for writing my own component
[10:40:04] <mozmck> and ran across that.
[10:40:10] <seb_kuzminsky> cool
[10:40:12] <seb_kuzminsky> code review ftw
[10:44:49] <seb_kuzminsky> mozmck: i'm looking at the libusb-1.0 docs here:
http://libusb.sourceforge.net/api-1.0/group__asyncio.html#gabb0932601f2c7dad2fee4b27962848ce
[10:45:26] <mozmck> Yes?
[10:45:34] <seb_kuzminsky> i think libusb-1.0 uses reference-counting, so it should be safe & correct to call libusb_free_transfer() after libusb_submit_transfer()
[10:48:05] <mozmck> Hmm, I don't know. I think the best is to not free it at all. It is only used again after the last transfer has completed, so there is no need to alloc and free the transfer each time.
[10:48:24] <JT_Shop> seb_kuzminsky, I missed that commit but I miss a lot from time to time
[10:48:47] <mozmck> I know this works because I do it that way in a program of mine, and I was told this method by one of the maintainers of libusb.
[10:50:25] <pcw_home> Was there some discussion of adding an upstream position offset into motion for things like Jog while paused and maybe THC/EDM?
[10:52:50] <mozmck> pcw_home: I'm not sure what upstream position offset means, but I would like a way to update position of the Z for our THC which moves it independent of linuxcnc while cutting.
[10:55:04] <pcw_home> I mean a way that avoids having to trick motion (and subtract offsets in hal) when you offset a commanded position
[10:56:17] <mozmck> I'm not sure...
[10:56:31] <mozmck> seb_kuzminsky: here's my proposed patch:
http://pastebin.com/ZHa1Dd4k
[10:56:35] <skunkworks> logger[psha],
[10:56:35] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-12-23.html
[10:56:50] <mozmck> seb_kuzminsky: simply move one line
[11:31:15] <seb_kuzminsky> mozmck: i like what your patch does, but it doesn't apply cleanly for me to 2.6 or 2.7, maybe pastebin munged the whitespace?
[11:31:34] <seb_kuzminsky> in any case, looks good, please apply to 2.6
[11:31:47] <mozmck> that's odd, maybe so. I did a fresh pull and that is on 2.7
[11:32:25] <seb_kuzminsky> JT_Shop: i changed the metric arc tolerance to be identical in size to the imperial arc tolerance, but that arc in ctrl-freq's program is still too far out-of-round to run
[11:32:31] <mozmck> ok. I'm using eclipse and it is doing funny with the whitespace for some reason in that file.
[11:32:38] <seb_kuzminsky> aha
[11:34:28] <seb_kuzminsky> JT_Shop: cradek had the very sensible idea of making the arc tolerance so large that any valid arc in "imperial rounded to 3 figures after the decimal point" or "metric rounded to 2 figures" would be accepted
[11:35:11] <seb_kuzminsky> pcw_home: a feature like that sounds like a great idea
[11:36:43] <cradek> ideally rounded or truncated
[11:37:27] <seb_kuzminsky> ah yeah, good point, can't count on CAM to do the right thing
[11:38:29] <cradek> both my testing and reading the code are inconclusive wrt what motion gives you for an extreme spiral
[11:39:33] <cradek> I wonder if the spiral-proportion test serves a purpose
[11:40:05] <cradek> if we go back to simple tolerance (and set it according to the above criteria) a tiny arc can have a huge spiral proportion
[11:40:18] <mozmck> heh, looks like this xhc-hb04 has a strange mixture of tabs and spaces to start with.
[11:40:30] <cradek> but if it's tiny, who cares what the exact shape is
[11:40:41] <cradek> ... if motion doesn't crap out on it
[11:40:53] <seb_kuzminsky> cradek: if it's less than the G64 P-word, it should maybe just become a line?
[11:41:11] <mozmck> What is preferred in linuxcnc code? hmm, there's probably a coding policy if I looked...
[11:41:11] <cradek> the ncd actually does (something like) that already
[11:41:24] <seb_kuzminsky> oh cool
[11:41:30] <cradek> fbofw
[11:41:45] <seb_kuzminsky> cradek: you're not in vi edit mode, pal
[11:42:20] <seb_kuzminsky> mozmck: src/CodingStyle
[11:42:43] <seb_kuzminsky> but it doesn't mention whitespace
[11:43:24] <seb_kuzminsky> there's docs/src/code/Style_Guide.txt
[11:43:38] <cradek> :e CodingStyle dG:wq
[11:43:46] <seb_kuzminsky> aka
http://www.linuxcnc.org/docs/html/code/Style_Guide.html
[11:43:51] <mozmck> ok, thanks, I'll look at those.
[11:44:00] <mozmck> cradek: huh? :)
[11:44:18] <seb_kuzminsky> mozmck: he's saying he doesnt like our coding style document ;-)
[11:44:27] <mozmck> oh, heh!
[11:44:59] <cradek> :s/our/any/
[11:45:06] <cradek> :g/Do no harm/p
[11:45:13] <cradek> sorry
[11:46:43] <seb_kuzminsky> hey, the coding style document that gets built into our docs actually starts with Do No Harm, so maybe...?
[11:47:20] <seb_kuzminsky> :q
[11:47:30] <cradek> in plain language, I believe the primary goal should be to not mess up source control (diff and patch) and any style/whitespace consistency concern is comparatively very unimportant
[11:47:31] <mozmck> Do no harm being what? Don't change existing code just to make it fit the coding style?
[11:47:40] <cradek> yes exactly
[11:47:50] <mozmck> makes sense to me!
[11:47:58] <cradek> when making changes, match the surrounding code, and don't mess with anything unnecessarily
[11:48:00] <seb_kuzminsky> yep
[11:48:09] <mozmck> ok
[11:48:15] <cradek> for new code, follow a style guide if that suits you :-)
[11:48:42] <mozmck> Some projects are *really* picky about following their style guide it seems.
[11:49:19] <cradek> if you do that from day 1, you can end up with all your whitespace matching, which is a pleasant thing
[11:49:22] <seb_kuzminsky> cradek: what test is the spiral-proportion test?
[11:49:28] <mozmck> I have contributed a little to Kicad, and they are pretty picky, and I don't like their coding style either!
[11:49:49] <mozmck> But I follow it anyhow, doesn't really matter to me.
[11:49:58] <cradek> seb_kuzminsky: CHKS(abs_err > 100*tolerance || (abs_err > tolerance && (rel_err > .001)),
[11:50:01] <seb_kuzminsky> mozmck: that's awesome of you and definitely the right thing to do
[11:50:04] <cradek> the .001 test here
[11:50:08] <seb_kuzminsky> cradek: aha
[11:50:27] * seb_kuzminsky closes the terminal where he was grepping in tests/
[11:51:06] <seb_kuzminsky> i think we have two conflicting goals with arc tolerance
[11:51:20] <seb_kuzminsky> one is to accept anything sloppy-but-reasonable CAM does
[11:51:45] <seb_kuzminsky> the other is to not make broad assumptions about the scale of features the user wants
[11:52:54] <seb_kuzminsky> i think our users only care about (1), and hardly anyone cares about (2)
[11:52:55] <archivist> those un-manufacturable features?
[11:54:06] <seb_kuzminsky> archivist: some CAM will program tiny arcs but then round (or truncate) the start, end, and center coordinates to a certain number of figures after the decimal point
[11:54:19] <seb_kuzminsky> maybe 3 or 4 for imperial, and maybe 2 or 3 for metric
[11:54:42] <seb_kuzminsky> in those situations, the starting and ending radius can be off by enough that the interpreter rejects them
[11:55:23] <archivist> as it should, probably
[11:55:27] <seb_kuzminsky> maybe
[11:55:51] <seb_kuzminsky> rejecting it is probably the technically correct thing to do
[11:56:15] <archivist> was talking to someone yesterday on maths and bridges collapsing, dont ignore the detail
[11:56:18] <seb_kuzminsky> but in practice we should maybe do what the user wants, at least by default, if it doesnt actually hurt anything
[12:00:05] <seb_kuzminsky> bbl
[12:00:14] <seb_kuzminsky> merry newtonmas everybody
[12:22:47] <mozmck> cradek: do I still have push access?
[12:30:02] <cradek> I never remove push access
[12:30:54] <cradek> should say: have never removed
[12:35:11] <mozmck> heh, ok. I don't have it set up right on my end.
[12:43:30] <KGB-linuxcnc> 03Moses McKnight 052.6 a5744e0 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc Fix memory leak in xhc-hb04 component. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a5744e0
[12:43:54] <cradek> yay! thanks
[12:44:20] <mozmck> Ah, it went, good, thank you!
[16:02:28] <seb_kuzminsky> cradek: the most that rounding or truncating can change the distance between two points is +/- (Resolution * 2^-1), i think
[16:04:34] <seb_kuzminsky> which would make our new abs_err limit be 2 * Resolution * 2^-1 = 0.002828 (that's for Res = 0.001 inch)
[16:04:51] <seb_kuzminsky> which seems uncomfortably high to me, but maybe it's not
[16:04:59] <seb_kuzminsky> i dont know what motion would make of it...
[16:05:02] <seb_kuzminsky> bbl
[17:20:17] <jthornton> yea, that seems high to me too...
[17:58:30] <PCW> where are the TuneX, TuneY, TuneZ gcode files?
[18:07:00] <Tom_itx> PCW, are you closed xmas - newyears?
[18:07:19] <Tom_itx> or will you ship stuff then
[19:05:17] <PCW> Yes closed Dec 25,26, Jan 1
[19:08:34] <Tom_itx> any reason the 7I90 wouldn't be a drop in for the 7i43?
[19:08:44] <Tom_itx> other than support for it in 2.5.x
[19:09:07] <Tom_itx> or will it work in 2.5.x?
[19:22:50] <PCW> Needs 2.6
[21:27:48] <cradek> I think what I want (accept all arcs that are rounded to .01 mm or .01 inch grid) is impossible
[21:29:10] <cradek> for any certain grid imagine a semicircle with endpoints 0,0 and 0,1. the center will end up being one of the endpoints, which is degenerate and no tolerance setting can let you accept it
[21:30:03] <cradek> which means you must either refuse some arcs with this property, or require a finer grid for the centers
[21:30:50] <cradek> I'm not sure I explained that in a way that makes sense
[21:35:49] <cradek> I sure don't understand this: 2 * Resolution * 2^-1 = 0.002828 (that's for Res = 0.001 inch)
[21:36:32] <cradek> seb_kuzminsky must not have typed what he meant
[21:36:54] <cradek> uh above of course I meant .001 inch grid
[22:56:55] <cmorley> seb_kuminsky: How did you package up glade 3.8.x for linuxcnc? there is another project that needs this same thing. I know nothing about packaging :)
[23:12:06] <cradek> cmorley: you can apt-get source it, and look at whatever he did
[23:12:15] <cradek> he may have just found the right old version and built it
[23:13:46] <cmorley> Ya I looked at synaptic package manager and it seemed to indicate he might have got it from Ubuntu...
[23:21:29] <cradek> yeah looks like he didn't change it, just built it
[23:21:45] <cradek> glade-3 (3.8.0-0ubuntu6) raring; urgency=low
[23:22:43] <cmorley> its all a bit greek to me but that's a start :) thanks.
[23:23:39] <cradek> sure, no problem
[23:23:56] <cradek> someone who knows packaging can do that zippity no problem
[23:24:12] <cradek> someone who doesn't know packaging maybe could just use ours?
[23:24:17] <cradek> not sure what you're up against
[23:25:12] <cmorley> I bet - there is resistance to keeping the old :) I will see what they say.