Back
[00:40:34] <pcw_home> http://ibin.co/1li1vC6KQ3SS
[00:40:35] <pcw_home> rather nasty velocity spike in new TP
[00:58:09] <seb_kuzminsky> cradek: imagine the true start point is at 0.00049, and the true center is at 10.00050, and the CAMm is working with a resolution of 0.001, and rounding
[00:58:44] <seb_kuzminsky> start will get rounded to 0.000, center to 10.001
[00:59:18] <seb_kuzminsky> true radius is very nearly 10, rounded radius is 10.001
[08:15:51] <micges-dev> pcw_home: paste gcode that caused that spike
[08:23:34] <pcw_home> http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=190#54250
[08:24:39] <cradek> seb_kuzminsky: where you wrote 2^-1 (= 1/2) did you mean something else?
[08:25:56] <pcw_home> I didn't see any errors until I ran it with his .ini file (with some minor mods so it would run here)
[08:33:46] <pcw_home> freeby.mesanet.com/fe.zip (hal, ini and gcode files for 7I76E that exhibit the bug)
[08:33:48] <pcw_home> sorry should have done a sim config but this was quick and dirty
[08:56:56] <pcw_home> (ferror magnitude looks like ~450 in X)
[09:02:15] <pcw_home> single steppping throug the gcode works...
[09:02:30] <pcw_home> (no error)
[09:04:41] <skunkworks> must be realtime vs sim - I cannot get it to happen in sim.
[09:05:07] <skunkworks> hmm
[09:22:32] <cradek> that would be surprising and scary
[10:11:51] <pcw_home> skunkworks: did you use his .ini file? (I dont get an error just with the gcode and my configs)
[10:18:51] <skunkworks> ok
[10:19:09] <skunkworks> I only used the acc/vel settings
[10:19:24] <skunkworks> maybe it is a 2 axis thing?
[10:32:31] <pcw_home> maybe
[11:02:42] <seb_kuzminsky> cradek: oops
[11:02:50] <seb_kuzminsky> yeah i totally meant something else
[11:03:09] <seb_kuzminsky> 2^(1/2)
[11:03:12] <seb_kuzminsky> sqrt(2)
[11:03:21] <cradek> oh ok
[11:03:35] <cradek> it felt like a sqrt2 should be in there somewhere because of ... squares
[11:04:03] <seb_kuzminsky> yeah
[11:04:44] <cradek> so anyway, I wonder what our goal is, and then I wonder how we should accomplish it
[11:06:11] <seb_kuzminsky> if there's a true path in a drawing, and cam reads the drawing and write gcode with all the coordinates rounded to the nearest 0.001, then the largest-magnitude move of a point from its true location to its rounded location would be from (0.000499, 0.000499) to (0.000, 0.000), or from 0.000501, 0.000501) to (0.001, 0.001)
[11:07:17] <cradek> for 2d I agree with that
[11:07:42] <cradek> and I think we just can consider the 2d case for the arc radii problem
[11:07:43] <seb_kuzminsky> the magnitude of that move is sqrt(0.5^2 + 0.5^2), which is sqrt(2)/2
[11:07:48] <seb_kuzminsky> yeah
[11:10:10] <seb_kuzminsky> so the worst-case arc radius error is one endpoint and the center moving together (making the radius change by sqrt(2)), and the other endpoint and the center moving apart, making another sqrt(2)
[11:10:12] <cradek> so each radii can be off by sqrt(2)
[11:10:18] <seb_kuzminsky> thus 2 * sqrt(2) * Resolution
[11:10:20] <seb_kuzminsky> yeah
[11:10:31] <cradek> I agree with your derivation
[11:12:22] <cradek> but I still am not sure what to do with some of the arcs that you get when you round or truncate the three points onto a grid
[11:12:48] <seb_kuzminsky> some of them end up with zero entry radius or exit radius (or both)
[11:12:56] <seb_kuzminsky> are those the ones you're unsure about?
[11:13:14] <cradek> yes those are the simplest/first examples I can picture
[11:13:40] <seb_kuzminsky> for the record, i'm also unsure that 0.002828 is a reasonable arc radius error
[11:13:52] <cradek> we could make them into semicircles? make them into lines?
[11:14:45] <seb_kuzminsky> lines sounds reasonable
[11:14:55] <seb_kuzminsky> you need to finish at the endpoint, even if it's silly
[11:15:08] <seb_kuzminsky> making a semicircle would require you to move the centerpoint?
[11:15:16] <cradek> I think you have arc direction and a guess at radius (mean of the two given radii) and that gives you a semicircle
[11:16:54] <seb_kuzminsky> in that situation you'd move the end point of the arc? away from the incorrectly specified centerpoint
[11:17:13] <cradek> no, I think you must always leave the endpoint
[11:18:36] <seb_kuzminsky> you'd leave the start point and the end point, and make a half circle between them, with radius = 1/2 of the entry radius?
[11:18:39] <seb_kuzminsky> i'm confused
[11:19:07] <cradek> so (assume grid precision of 1) if you start at 0,0 and give g3 x1 y0 i1 j0, you'd actually run the arc with center i0.5 (not on the grid)
[11:19:37] <cradek> because 0.5 is the mean of 1 and 0 (the two given radii)
[11:20:25] <seb_kuzminsky> yes, ok, i see
[11:20:38] <cradek> I think the R-format code actually does this kind of thing already
[11:20:39] <seb_kuzminsky> that's a clearer way of saying what i tried to say above with r=1/2 entry radius
[11:22:09] <cradek> I'm having a terrible time trying to picture all the cases we'd have to consider and choose what arc to give
[11:23:13] <seb_kuzminsky> and we'd have to decide if 0.002828 is an acceptable default arc radius slop tolerance
[11:23:19] <seb_kuzminsky> gtg bbl
[11:23:54] <cradek> I don't think this is a question of tolerance, it's a question of what SHAPE to give in response to sloppy input
[11:24:23] <cradek> as you allow more slop, you will see weirder shapes
[11:29:29] <cradek> I think it would be great if we could actually give the spiral the gcode asks for in slightly sloppy cases
[11:29:37] <cradek> I'm not sure if that is still possible
[11:30:21] <seb_kuzminsky> yeah that would be cool
[11:32:05] <cradek> but still two problems: you need a tolerance for "whoah your cam is nuts or you don't understand arcs", and some are still degenerate, like one radius is 0
[11:33:15] <cradek> it seems like the only other option is to circularlize the arc in one of various ways
[11:34:08] <cradek> I think the new planner already tries to do this (from code inspection only) but I think it doesn't work right (from experimenting with a wide tolerance)
[11:34:35] <cradek> I know the old planner made the spirals
[11:35:01] <seb_kuzminsky> but you tried the new planner and you're not sure what shape it makes?
[11:36:03] <cradek> yes
[11:36:33] <cradek> old planner, (endpoint offset?) bug showing spiral:
http://timeguy.com/cradek-files/emc/thats-no-arc.png
[11:37:28] <cradek> I think we need rob's help to be smart about this
[11:38:23] <seb_kuzminsky> not sure what i'm looking at in that screenshot
[11:38:48] <cradek> the big pink line is a spiral that accidentally got through the earlier layers
[11:38:54] <cradek> it's an aside - forget it
[11:39:34] <seb_kuzminsky> oh
[11:39:35] <seb_kuzminsky> heh
[11:43:57] <seb_kuzminsky> i think you're right that we need to know what rob's planner does with spiral arcs
[11:44:37] <seb_kuzminsky> i just verified that increasing the arc radius tolerance to that number we talked about, 0.002828, makes the jer10b.ngc program from the forum run without trouble
[11:44:45] <cradek> do you think before we bother him we should figure out what we would like it to do?
[11:44:50] <seb_kuzminsky> http://pastie.org/9797528
[11:45:07] <seb_kuzminsky> yeah
[11:45:27] <seb_kuzminsky> we should know what we want it to do, and ideally have a test that verifies that it does that thing
[11:45:38] <cradek> loading and running the gcode without apparent trouble is necessary but not sufficient
[11:46:00] <seb_kuzminsky> yeah...
[11:46:01] <cradek> spirals might cause constraint violation in blend arcs, for instance
[11:46:42] <cradek> in fact I think I heard they did earlier (most arcs are a little bit spirally), and there's an existing workaround for it
[11:49:16] <cradek> see findSpiralApproximation()
[11:49:54] <cradek> but I am not sure it works right
[11:52:12] <cradek> hmm, it didn't get run when I mdi'd my test spiral
[11:55:52] <seb_kuzminsky> here's what i got:
http://highlab.com/~seb/linuxcnc/2.7-arc.png
[11:56:00] <seb_kuzminsky> the grid's 0.001
[11:56:29] <seb_kuzminsky> abs_err = sqrt(2) * 0.001
[11:56:36] <seb_kuzminsky> lemme try twice that
[11:58:13] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/2.7-arc-big-r-err.png
[11:58:50] <seb_kuzminsky> the bigger spiral thingy has an entry radius of 3 and an exit radius of 1 (times 0.001)
[11:58:59] <seb_kuzminsky> oh wait, so it's not maximally bad, hold on
[11:59:34] <cradek> maybe one spiral gets run as a spiral, but the circularization is something blending does? (guessing)
[12:03:07] <seb_kuzminsky> ok here:
http://highlab.com/~seb/linuxcnc/2.7-arc-max-r-err.png
[12:03:11] <seb_kuzminsky> now i really gotta run
[12:03:13] <seb_kuzminsky> bye!
[13:51:46] <cradek> that's pretty spiralley
[14:13:45] <Tom_itx> what causes that?
[14:13:54] <Tom_itx> tolerance error?
[14:14:29] <cradek> days and days of conversation that I don't want to summarize :-)
[14:14:38] <Tom_itx> np
[14:14:45] <Tom_itx> i followed some of it
[14:15:32] <cradek> I guess the summary is ijk arcs are overspecified so it's easy to get invalid ones - so which ones are really invalid and what to do about it all
[14:30:24] <CaptHindsight> http://linuxgizmos.com/orange-pi-sbc-tempts-raspberry-pi-clone-fans/ another Rpi with an A20 and GB ethernet $50
[14:31:03] <CaptHindsight> still need to try hm2_eth on one
[15:13:11] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/wonky-arc-preview.png
[15:16:21] <cradek> yeah, that was on purpose
[15:16:57] <cradek> so motion is giving you the real spirals?
[15:17:17] <cradek> I wonder if you're getting arc blends (and if so, whether they're right)
[15:39:50] <seb_kuzminsky> yeah, the motion output looks right (not sure if they're blended)
[15:43:05] <seb_kuzminsky> they're blended:
http://highlab.com/~seb/linuxcnc/wonky-arc-preview-blended.png
[15:43:16] <seb_kuzminsky> (i had to turn accel down & feedrate up to see it)
[15:43:49] <cradek> I wonder if those are circular blends or old-planner blends
[15:44:07] <cradek> it does look tangent
[15:44:43] <cradek> you might want to put some long lines before and after these moves?
[15:44:47] * cradek waves his hands
[15:48:06] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/wonky-arc-preview-blended-with-lines.png
[15:48:10] * seb_kuzminsky shrugs
[15:48:13] <seb_kuzminsky> bbl
[15:51:18] <cradek> pretty
[16:05:46] <tjtr33> hello, Merry Christmas & thx to all the devs and hard working testers of LinuxCNC. best wishes to all for the new year. you're amazing!
[16:08:13] <PetefromTn_> Ditto here a heartfelt THANK YOU for all you guys do to make LinuxCNC work so well and continue to be developed into the powerful package that it is today.
[17:47:41] <skunkworks> wow - I have no clue what I am looking at
[17:47:55] <skunkworks> andd merry christmas!
[17:48:12] <skunkworks> (no I have not started drinking yet_)
[19:36:55] <micges-dev> PCW: pcw_home: skunkworks: I've got nan in this plasma XY setup with 7i76e and rt-preempt:
http://ibin.co/1lnZ1EZUi0fZ
[19:38:07] <PCW> yeah something about the corner radius
[19:39:47] <PCW> Skunkworks thought it might be related to 2 Axis (I dont get the error running that gcode with my standard 3 axis hm2-stepper config)
[19:41:34] <PCW> (the ferror magnitude looks like 450)
[19:41:36] <PCW> it does not make the error if you run line by line
[19:42:27] <micges-dev> mhm
[19:45:20] <PCW> I guess Rob E will look at it when he gets a chance
[19:45:52] <micges-dev> I don't see any bogus numbers in debug output so it couldan be tp pro
[19:45:59] <micges-dev> I don't see any bogus numbers in debug output so it could be tp problem
[19:46:44] <PCW> Yeah the OP says the old TP doesn't have the issue
[19:53:32] <PCW> the -450 error looks a bit like 0 was used instead of the current X position somewhere
[19:54:49] <micges-dev> may be
[19:55:07] <micges-dev> atom525 is too weak to enable new tp debugging :)
[19:55:41] <PCW> Yeah the 525s are painfully slow
[19:56:21] <micges-dev> hope to get j1900 on cristmas
[20:07:03] <PCW> J1900s are much nicer (a G3258 is nicer still)
[22:23:23] <skunkworks> well - I think all the presents are assembled and under the tree...
[22:36:46] <skunkworks> looks like the J1800 will work just fine as a media pc.
