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