Back
[00:18:15] <BigJohnT> I bet too
[07:38:37] <micges> good morning
[07:55:25] <alex_joni> morning
[10:39:58] <BigJohnT> alex_joni: are you around?
[10:56:32] <alex_joni> am now
[14:40:47] <tomaw> [Global Notice] Hi all. One of our server sponsors appears to be having connectivity issues. Please keep with us while we try to resolve the issues. Sorry for the inconvenience and thanks for using freenode!
[14:58:07] <micges> yesterday I had gcode with circles with points START - END < 0.0001 and when I've run it with G64 P0.01 they were skipped
[14:58:49] <micges> and when I've run it with G61 everything was ok
[14:59:05] <micges> is this ok?
[14:59:27] <skunkworks_> are you saying arcs? or complete circles?
[14:59:42] <micges> circles
[15:00:59] <skunkworks_> hmm - that would be a question for jepler.
[15:01:17] <skunkworks_> It sounds like a bug.
[15:01:31] <micges> I'll bug him later
[15:01:43] <micges> going home from work
[15:01:44] <micges> bbl
[15:13:53] <jepler> it sounds like a bug. file enough information so that I can reproduce it, and I'll look at it.
[15:15:36] <SWPadnos> huh. I thought the naive CAM detector looked at the start, mid, and end points to see if an arc could be skipped
[15:16:21] <SWPadnos> if the actual arc was tiny (2 orders of magnitude less than the G64 tolerance), then it should have been aggregated
[15:31:03] <jepler> SWPadnos: micges didn't give much information, but I assumed he meant the circle itself was not small
[15:31:09] <jepler> but the distance from the endpoints was
[15:31:13] <SWPadnos> yeah, sure could be
[15:31:21] <jepler> that's the part where I need enough information to reproduce it
[15:31:27] <SWPadnos> heh
[15:32:01] <jepler> but yes, it's true: in G64P- tolerance mode, 2.3 will decompose certain arcs into lines so that arc+line sequences can be improved by the naive cam detector
[16:06:29] <skunkworks_> http://www.pastebin.ca/1373058
[16:10:05] <jepler> #
[16:10:06] <jepler> #<_yPos> = [#<_yPos> + #<_ySize> - #<_yPos>]
[16:10:16] <SWPadnos> yeah, I noticed that
[16:10:20] <jepler> this seems like a rather odd way to do #<_yPos> = #<_ySize>
[16:10:24] <SWPadnos> ypos = ysize would be more clear
[16:10:30] <jepler> yes
[16:11:18] <jepler> the loop condition is "le", so it seems to me that it'll loop forever
[16:11:20] <SWPadnos> or even ypos = ypos + ystep / if ypos > ysize ypos = ysize
[16:11:21] <jepler> which is not intended
[16:11:35] <SWPadnos> right, LT would make more sense
[16:11:56] <skunkworks_> that is the issue - it would loop forever. :)
[16:11:57] <SWPadnos> and might even work as intended
[16:12:52] <skunkworks_> it came from this
http://www.cnczone.com/forums/showpost.php?p=588773&postcount=11
[16:13:02] <SWPadnos> figured :)
[16:13:17] <SWPadnos> the if condition sets _yPos to _ySize
[16:13:45] <SWPadnos> but the while loop will repeat as long as _yPos is less than *or equal* to _ySize
[16:13:51] <SWPadnos> so it loops forever
[16:14:08] <SWPadnos> the while should be changed to LT instead of LE
[16:14:31] <skunkworks_> Thanks guys
[16:22:11] <skunkworks_> http://www.cnczone.com/forums/showthread.php?p=588828#post588828
[16:22:32] <jepler> you tested before posting, I hope
[16:22:43] <SWPadnos> heh
[16:22:48] <SWPadnos> I sure didn't ;)
[16:22:54] <skunkworks_> he agreed ;)
[16:22:58] <jepler> oh I guess you didn't post any actual code anyway
[16:23:16] <jepler> unfortunately, "do something at each increment of depth and then at the bottom" is not easy to write as a gcode loop
[16:23:26] <jepler> it's so common in cnc that it almost deserves its own language construct
[16:23:27] <SWPadnos> I wonder why it wouldn't work for him using LT
[16:24:16] <jepler> O- peck [target var] [start] [end] [increment ... O- endpeck
[16:24:47] <SWPadnos> for a=START to FINISH step STEP ...
[16:24:52] <SWPadnos> back to BASICs :)
[16:26:33] <jepler> basic's for loop doesn't give the termination condition you typically want in cnc, though ("always have an iteration at the FINISH depth")
[16:27:08] <jepler> I wonder, were there any basics that calculated a = START + i*(FINISH-START)/STE␂P, rather than a += STEP
[16:27:16] <SWPadnos> right. the syntax could be close to BASIC, but make it always exactly meet the end condition
[16:27:26] <SWPadnos> I don't remember any
[16:27:32] <jepler> because that's the other problem with this kind of while loop on floating numbers
[16:27:35] <SWPadnos> like "go from A to B in N steps"
[16:28:05] <SWPadnos> there are a lot of options on how to deal with start and end conditions
[16:28:09] <SWPadnos> or a few anyway
[16:28:12] <jepler> yes
[16:28:30] <SWPadnos> but a subroutine to calculate the steps and/or do the loops could be written
[16:29:12] <jepler> * jepler tries to imagine that not sucking
[16:29:17] <SWPadnos> heh
[16:29:39] <jepler> just typing '#<_yPos> = #<_ySize>' earlier was enough of a strain on my fingers, it's such an alien language compared to C++ or python
[16:29:44] <SWPadnos> there would be at least one restriction if it did the loops: the code to run would have to be in a numbered subroutine
[16:29:50] <SWPadnos> heh
[16:30:11] <jepler> what else should I put on this digikey order? I actually need 6.6 cents worth of surface mount capacitors..
[16:30:23] <SWPadnos> heh
[16:31:04] <SWPadnos> how about one of those interesting programmable-resolution encoders
[16:31:04] <jepler> (but the min qty is 10 so I have to buy at least 33 cents worth.. what a gyp)
[16:32:22] <SWPadnos> this one:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=102-1307-ND
[16:32:56] <jepler> huh, what's a capacitive encoder?
[16:33:02] <SWPadnos> damfino
[16:33:09] <alex_joni> magnetic?
[16:33:16] <SWPadnos> bust be wunna them there electronical ones
[16:34:00] <alex_joni> looks like those coloured thingies have some metal inside them
[16:34:14] <alex_joni> and act as the thing that gets sensed by the capacitance sensor
[16:34:19] <jepler> and the output PPR is set by dip switch
[16:34:20] <SWPadnos> I think they're just sleeves for different shaft sizes
[16:34:34] <SWPadnos> right, there are 16 resolutions
[16:34:55] <alex_joni> 2048 PPR ?
[16:35:07] <alex_joni> crazy :D
[16:35:19] <skunkworks_> you have to look at the actual acuracy though
[16:35:19] <SWPadnos> yes, and I think that's 2k CPR, so 8kPPR (not positive though)
[16:35:29] <jepler> yes I also think that's what the datasheet says
[16:39:50] <jepler> micges: please provide a gcode file that demonstrates the problem you described earlier. if the program doesn't exist in a standard sim config, please provide the config too.
[16:39:58] <jepler> you know the drill :)
[16:40:09] <micges> ok
[17:38:29] <tomaw> [Global Notice] Hi again. One of our hubs had connectivity issues causing some servers and users to be unable to connect to the network, resulting in a rather noisy set of splits. The issue has been resolved now and we believe there should be no further interruptions. Thanks!
[17:49:54] <jepler> SWPadnos: 12:15:50 <ikirst> You are so in luck...Brendan just stopped by to drop off a thank you card for the
[17:49:57] <jepler> oops
[17:50:04] <jepler> SWPadnos:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2710920&group_id=10894
[17:50:32] <jepler> SWPadnos: they've reproduced the odd problem you ran into
[17:50:39] <SWPadnos> great!
[17:50:49] <jepler> (the tcl path problem)
[17:52:27] <SWPadnos> yep
[18:00:09] <micges> jepler: this is gcode:
http://www.pastebin.ca/1373163
[18:00:52] <micges> this is config:
http://www.emc-files.webpark.pl/gustlik.zip
[18:01:06] <jepler> micges: so the problem doesn't exist on a standard sim config?
[18:01:11] <jepler> or you just didn't check that yet?
[18:03:32] <micges> I'm checking it
[18:03:52] <jepler> also, can you say which of the over 1700 lines the problem occurs on?
[18:05:08] <micges> on second circle at 20 line
[18:05:15] <micges> on circle at 20
[18:05:34] <jepler> didn't happen here, then.
[18:05:46] <jepler> using configs/sim and specifying "G21" to turn on metric distance units
[18:05:55] <jepler> I also specified F99999 instead of F2000 so that it went faster
[18:07:04] <jepler> my slightly modified part program:
http://emergent.unpy.net/files/sandbox/1776.ngc screenshot showing that backplot and preview plot match:
http://emergent.unpy.net/files/sandbox/1776.png
[18:08:43] <jepler> .. updating my CVS to TRUNK now, just to make sure it is not a recent bug
[18:08:54] <jepler> (probably hadn't updated for several weeks here)
[18:09:22] <micges> jepler: have you run gustlik config just to see what happening ?
[18:15:13] <jepler> yes, it happens in the config file you sent me
[18:19:28] <jepler> so the next thing it would be useful for you to figure out is the relevant difference from configs/sim/axis.ini to your configuration
[18:20:09] <micges> I'm doing it now
[18:28:29] <jepler> hm, I did see it once but now I don't see it
[18:28:53] <jepler> in between I rebuilt emc
[18:28:57] <jepler> and did a cvs update
[18:36:26] <micges> odd
[18:37:54] <jepler> ugh. here's what made the bug go away: I added a debugging printf statement
[18:45:08] <micges> I've changed everything in axis_mm.ini step by step and no result
[19:06:40] <alex_joni> jmkasunich: motioncontrol in #emc reported an "insufficient memory for signal Yhome" error
[19:06:59] <alex_joni> jmkasunich: it seems it appears when he uses 2 m5i20 boards + halui (so lots of pins & signals)
[19:07:17] <alex_joni> jmkasunich: maybe we should bump the HAL_SIZE define in src/hal/hal_priv.h for 2.3 ?
[19:10:54] <alex_joni> I'm surprised seb_kuzminsky didn't see such an issue
[19:12:23] <seb_kuzminsky> i've just used lots of pins & params, not so many signals
[19:12:26] <seb_kuzminsky> dont know if that matters
[19:12:52] <alex_joni> dunno either
[19:13:05] <alex_joni> but I suspect a signal takes a bit more space than a pin
[19:13:47] <seb_kuzminsky> maybe a problem with halui rather than low-level hal stuffs?
[19:14:01] <seb_kuzminsky> motioncontrol says it's only when he enables halui
[19:14:15] <alex_joni> yeah, but I bet it's the number of pins halui exports
[19:14:16] <jepler> halui obviously allocates a lot of stuff
[19:14:19] <alex_joni> which are quite a few
[19:14:39] <jepler> if we're going to bump it, bump it now before we finish betas
[19:14:40] <seb_kuzminsky> i see
[19:14:59] <SWPadnos> I didn't get that error when I had 2 5i20 boards installed, but I don't think I loaded halui as well
[19:15:02] <alex_joni> jepler: that was my intention too
[19:15:12] <alex_joni> SWPadnos: got 2 boards around?
[19:15:14] <alex_joni> or 4?
[19:15:15] <SWPadnos> I think I tried a 5i20 + 5i22 also
[19:15:35] <seb_kuzminsky> i've tested about 535 pins, similar number of params, no problems
[19:15:44] <SWPadnos> I do, but I don't know that I hve a PC with more than 2 or 3 PCI slots
[19:15:45] <seb_kuzminsky> (without halui tho)
[19:18:21] <jepler> we last bumped hal memory size in '06 (doubled it)
[19:18:26] <jepler> it's 09 so we can double it again
[19:18:37] <jepler> that's only doubling half as fast as moore's law, so it's probably OK
[19:18:51] <alex_joni> moore said we could double it every 18 months
[19:20:42] <SWPadnos> I say we go straight to 1 meg
[19:20:52] <SWPadnos> let's preempt that next doubling
[19:21:37] <SWPadnos> any particular reason why it's 2^x - $small_number ?
[19:22:14] <jepler> used to be that in the kernel the most efficient allocations were powers-of-two-pages
[19:22:36] <jepler> presumably jmk didn't use the whole 64k in case a realtime layer used a few bytes for its own bookkeeping as well
[19:22:41] <SWPadnos> I'll bet that $small_number changed
[19:27:15] <jepler> micges: I was able to find a slightly different program that demonstrates the problem on sim/axis_mm
[19:28:16] <micges> can I see it ?
[19:28:37] <jepler> http://emergent.unpy.net/files/sandbox/circles.ngc
[19:30:28] <jepler> the bottom 4 sets of circles are in G64 tolerance mode
[19:32:22] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: (log message trimmed)
[19:32:22] <CIA-2> EMC: micges found a case where a full circle would be mangled by the naive cam
[19:32:22] <CIA-2> EMC: arc->line converter as though it was a no-motion. introduce a fudge factor
[19:32:22] <CIA-2> EMC: that fixes this on the cases I tested, by treating circles under 1e-5 radians
[19:32:22] <CIA-2> EMC: as full circles. In my tests, the actual theta difference was on the order of
[19:32:25] <CIA-2> EMC: 1e-16 to 1e-15.
[19:32:27] <CIA-2> EMC: Even if a very short arc is treated as a full circle by chord_deviation, it
[19:32:49] <jepler> the non-blue circles show where the problem strikes:
http://emergent.unpy.net/files/sandbox/sim-arc-tolerance-bug.png
[19:35:14] <micges> jepler: great, thanks
[19:35:35] <jepler> I hope my bugfix is right
[19:38:12] <SWPadnos> ugh
[19:38:31] <SWPadnos> it's a little annoying that the webCVS revision graphs are images instead of text
[19:38:40] <SWPadnos> (that could be searched with /<text>)
[19:38:43] <jepler> you try doing that in html
[19:38:46] <SWPadnos> heh
[19:38:58] <SWPadnos> I understand the problem, but it's still annoying :)
[19:39:23] <SWPadnos> oops. a little annoying
[19:40:49] <SWPadnos> ok - aliases may be part of the problem with HAL_SIZE now
[19:41:28] <SWPadnos> it adds one int per pin/param, plus the alias list pointers in the main data area
[20:34:29] <micges> jepler: It seems that you fixed it
[20:34:48] <alex_joni> why does jepler get to have blue circles?
[20:35:42] <micges> It can be changed (jepler told me how but I forgot;))
[20:35:53] <alex_joni> * alex_joni was partly joking :)
[20:36:27] <jepler> *Togl.backplotarc: #4040c0
[20:36:31] <jepler> in ~/.Xresources
[21:03:46] <micges> good night all
