Back
[14:47:10] <aystarik> question about emccanon.cc:ARC_FEED... why get_last_pos() and direct canonEndPoint.{x,y} are both used?
[14:54:02] <cradek> good question. seems like it might be wrong in cases where there are points chained?
[15:04:33] <aystarik> this is what worries me :)
[15:04:48] <cradek> yes I get worried just opening that file
[15:07:33] <aystarik> stupid question, why 9 axis? I see all the CAMs struggle to support 5, Mach supports 6... Existing centers support 4-5 axis max...
[15:08:11] <cradek> lots of machines have odd combinations of axes
[15:08:20] <cradek> a lathe with a tailstock might be X,Z,W
[15:08:30] <cradek> a two turret lathe might be X,Z,U,W
[15:08:42] <cradek> it gives a lot of flexibility to have more than 3 linear axes
[15:10:55] <aystarik> so, it makes sence to have say 6 unnamed axis and then name them as we see fit?
[15:12:31] <cradek> well I think xyzabcuvw are the only letters available in our gcode dialect, so I don't think you could make it any more flexible than it already is
[15:13:37] <cradek> also it's not just about their names - there are three orthogonal sets of axes, and that is important when you calculate feed rates etc.
[15:15:27] <cradek> brb
[15:17:34] <aystarik> examples you gave, X and U are independent, so their acceleration/velocity is not summed up
[15:18:24] <aystarik> if we speak of W as quill then it's velocity should be concidered summed with Z...
[15:20:15] <aystarik> robot arms velocities and accelerations are polar in most cases, thus orthogonal system is not working for them at all...
[15:27:14] <cradek> yes maybe if Z is quill and W is knee their velocities should influence one another - not sure
[15:28:12] <cradek> imagine a puma with a cutting tool - you want the maxvel/maxaccel to be in the rotaries but the feed rate to be in the orthogonal system
[15:28:27] <cradek> this is the distinction between axes and joints
[15:31:08] <aystarik> right
[15:31:33] <cradek> did you find a problem with ARC_FEED?
[15:31:35] <aystarik> same with quill. maximums are for axis, but feed is from sum
[15:32:04] <aystarik> no, I'm trying to understand how to make native NURBS_FEED...
[15:32:29] <cradek> you mean not using biarcs?
[15:33:00] <cradek> (probably 100x easier to fix the biarc implementation) did you see my comments about that a few days ago?
[15:34:27] <aystarik> yes. I've found that strange variable, which might be an answer :
[15:34:30] <aystarik> static void
[15:34:30] <aystarik> arc(int lineno, double x0, double y0, double x1, double y1, double dx, double dy) {
[15:34:30] <aystarik> double small = 0.0001;
[15:35:25] <aystarik> if arc is smaller than 'small', it will be put as line, otherwise -- it's an arc.
[15:36:07] <aystarik> in master, small is: double small = 0.000001;
[15:36:09] <cradek> that's not how I read arc()
[15:36:29] <cradek> what I see is if the radius is huge it will make a straight line
[15:36:57] <cradek> that does not affect the number and/or spacing of subdivisions which is what I think is causing the jerky motion
[15:37:42] <aystarik> may be.
[15:41:40] <aystarik> btw, what is G5.1? G5.2/G5.3 are somehow documented, but G5.1 is there with no comments?
[15:43:34] <cradek> all I have is this:
http://timeguy.com/cradek-files/emc/Leto_art837759.pdf
[15:47:27] <cradek> guess it's for splines - but I don't know how to use it
[15:50:27] <cradek> actually the subdivision doesn't look too bad:
http://timeguy.com/cradek-files/emc/butterfly.png
[15:51:00] <cradek> maybe a bit on the small side
[15:55:55] <aystarik> how did you made it?
[15:56:42] <aystarik> emccanon and gcodemodule use different algorithms for NURBS...
[15:57:23] <cradek> this is a backplot display of the motion
[15:59:21] <cradek> http://timeguy.com/cradek-files/emc/technicolor.diff
[16:01:05] <aystarik> cool
[16:02:13] <cradek> ugly but it makes the separate moves more apparent
[16:05:31] <cradek> - unsigned int div = nurbs_control_points.size()*4;
[16:05:31] <cradek> + unsigned int div = nurbs_control_points.size()*2;
[16:05:52] <cradek> this gives fewer points, but there is one abberant motion on the right wing
[16:06:27] <SWPadnos> what happens with 3? (or does it have to be a power of 2?)
[16:06:34] <cradek> I don't understand the algorithm enough to answer that
[16:06:38] <SWPadnos> ok
[16:06:48] <SWPadnos> you could try changing it :)
[16:08:06] <cradek> well I'm suspicious that there's a bug elsewhere:
http://timeguy.com/cradek-files/emc/right-wing.png
[16:08:17] <cradek> off by 1 maybe?
[16:08:55] <SWPadnos> huh. what's the white path?
[16:09:28] <SWPadnos> that's actually an error in motion, rather than the NURBS->arcs conversion, isn't it?
[16:09:38] <SWPadnos> (white being the correctly calculated preview path ?)
[16:09:48] <cradek> white is preview. I don't know if it's correct.
[16:09:59] <SWPadnos> it sure looks more correct to me :)
[16:10:02] <SWPadnos> ie, smooth
[16:10:05] <cradek> yes
[16:10:43] <cradek> at 3 there's still an abberation but it's smaller
[16:10:59] <cradek> something goes wrong with the biarc conversion at that spot
[16:12:23] <cradek> unsurprisingly that's one of the two spots where the motion jerks almost to a stop
[16:12:39] <cradek> motion is turning a pretty sharp corner
[16:13:36] <SWPadnos> it's probably coincidence, but the purple and yellow lines look like they're parallel to the tangent line of the middle of the arc that the purple misses
[16:13:55] <SWPadnos> that corner is one motion too, isn't it? (being all purple)
[16:14:44] <cradek> hmm seems like it must be. I wonder if it's an invalid arc somehow?
[16:16:47] <cradek> sure isn't smooth, whatever it is
[16:16:53] <SWPadnos> heh, no
[16:19:24] <cradek> I think my colors are wrong, there are two purples
[16:19:39] <cradek> looking very close I think most of these arc intersections are NOT tangent
[16:20:04] <SWPadnos> huh
[16:27:56] <aystarik> you may add print in NURBS_FEED it it encounters coords near this position...
[16:34:13] <cradek> http://timeguy.com/cradek-files/emc/abberation.png
[16:34:34] <cradek> I think motion is doing what it's told...
[16:40:57] <cradek> it seems to pick different arcs every time I run it
[16:42:59] <cradek> guh, I have no idea
[16:50:13] <aystarik> I've set feed override to 20% and can't see any abberation...
[16:50:22] <cradek> try 1%
[16:50:28] <cradek> it's very small
[16:54:24] <cradek> even that is not enough - maybe try very low max velocity
[16:55:27] <cradek> oh god, look at alpha_finder()
[17:00:14] <aystarik> there is it&
[17:00:16] <aystarik> ?
[17:01:37] <aystarik> cool
[17:01:45] <aystarik> atan2 to the rescue?
[17:02:37] <cradek> fixing that moves the glitch to a different quadrant crossing
[17:04:17] <cradek> do you know where is the biarc algorithm paper?
[17:07:04] <cradek> found it
[17:07:16] <cradek> I bet this math is just wrong
[17:07:40] <cradek> bbl, lunch
[17:10:36] <aystarik> dxe = cos(alphaM);
[17:10:37] <aystarik> dye = sin(alphaM);
[17:10:37] <aystarik> unit(dxe, dye);
[17:10:56] <aystarik> I like this one :)
[17:16:15] <LawrenceG> cradek, good day... what model is your mori mill?
[17:58:30] <cradek> aystarik: biarc() sends it though unit() again for good measure
[17:58:35] <cradek> LawrenceG: MV Jr.
[18:00:26] <LawrenceG> cradek, thanks.... was just cruising epay mori mills... there are some serious machines out there for little money.... its too bad that 15hp spindles are not very practical for a home shop!
[18:01:05] <cradek> yeah, 5hp is about the limit, 3hp is better since you can run it on single phase
[18:04:54] <aystarik> cradek, sin^2 + cos^2 == 1 to any degree of accuracy, why call unit?
[18:05:28] <cradek> yes, I agree unit is not needed, and especially not calling it twice
[18:05:51] <cradek> (but I don't care about optimizing the code until it works right)
[18:13:33] <aystarik> what paper are you refering too&
[18:13:35] <aystarik> ?
[19:18:31] <CIA-2> EMC: 03cradek 07master * re90dc7c95634 10/src/emc/ (rs274ngc/nurbs_additional_functions.cc task/emccanon.cc): Fix glitchy motion in NURBS.
[19:18:39] <CIA-2> EMC: 03cradek 07master * r219b79110514 10/src/ (5 files in 5 dirs): Merge branch 'v2.4_branch'
[19:18:39] <CIA-2> EMC: 03cradek 07master * re006da9ee923 10/src/ (Makefile emc/usr_intf/pncconf/pncconf.py): Fix pncconf help files on installed emc
[19:18:40] <CIA-2> EMC: 03cradek 07master * r632cf36a5942 10/src/emc/usr_intf/pncconf/ (pncconf-help/help-welcome.txt pncconf.py): fix mesa firmware loading for released version of emc
[19:19:28] <micges> cradek: hi
[19:20:18] <cradek> hi micges
[19:25:57] <micges> friend asked me if connecting inpos pin of each joint to step driver pin enabling low current of driver will works
[19:26:29] <micges> so when joint will be not moving then driver will be in low current mode
[19:26:46] <cradek> does it work?
[19:27:08] <micges> I think that will not work
[19:28:29] <micges> iirc that was many times discussed here and there were opinions that steps will be sended at time of inpos change and driver will be not enough fast
[19:31:57] <cradek> yes I've heard people guess that many times
[19:32:02] <cradek> I don't know if anyone has tried it
[19:32:26] <cradek> others say that drivers that need current reduction are just defective and should be replaced with proper choppers
[19:33:13] <cradek> maybe the driver documentation can say how much time is needed before a step pulse, after resuming full current
[19:34:39] <micges> ok thanks
[19:39:05] <cradek> aystarik: did you figure out how to use G5.1?
[19:39:33] <aystarik> no, I found it needs I and J
[19:39:50] <cradek> yeah
[19:41:52] <cradek> oh it works in the obvious way :-)
[19:42:13] <cradek> g0x1y1; g5.1x-1y1i-1j-1
[19:44:12] <cradek> eww, but it doesn't always get it right: g0x1y3; g5.1x-1y3i-1j-5
[19:53:12] <aystarik> what is i and j?
[19:53:35] <cradek> incremental distance to the control point
[19:55:07] <cradek> wow!! very quick hack of truetype-tracer to use G5.1 looks like it works right
[19:58:24] <cradek> http://timeguy.com/cradek-files/emc/g5.1.png
[20:00:55] <aystarik> may be document it then ? :)
[20:03:33] <cradek> still needs a lot of love and testing
[20:04:03] <cradek> it should give errors for cases it can't handle
[20:05:55] <aystarik> may be mark it expiremental or something? if it is not mentioned, nobody will use it, so it will just die eventually, like nurbs did.
[20:07:17] <cradek> yeah it should probably be in trunk docs
[20:11:14] <aystarik> btw, have you seen this effort?
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=34
[20:11:56] <awallin> what is g5? splines?
[20:12:16] <cradek> g5.1 is conic spline, g5.2 is nurbs
[20:12:28] <cradek> and I think they pretty much work now
[20:12:30] <seb_kuzminsky> nifty :-)
[20:13:02] <awallin> are they pushed as nurbs/splines all the way to the traj-planner? or are they chopped up into tiny lines/arcs?
[20:13:20] <cradek> they are converted into biarcs
[20:13:51] <awallin> is g5 an industry standard? or something emc2-specific?
[20:13:59] <cradek> = series of arcs with ends tangent, so the motion is nice and smooth
[20:14:24] <cradek> I doubt there is any industry standard but I didn't research it (nor did I choose the gcodes)
[20:14:27] <aystarik> emc2-specific.
[20:14:47] <aystarik> fanuc has g6.1/g6.2 which are almost the same
[20:15:01] <cradek> cool
[20:15:25] <awallin> ok
[20:15:50] <cradek> seb_kuzminsky: how was your vacation?
[20:15:56] <seb_kuzminsky> sunny & lazy
[20:16:07] <cradek> nice
[20:16:08] <aystarik> fanuc is capable of nurbs in any 3 axis given on the first line
[20:16:48] <cradek> yeah ours are 2d so far.
[20:18:01] <aystarik> and always xy :)
[20:18:16] <cradek> yep guess so
[20:18:30] <cradek> I suppose they could be any plane if someone cared to do it
[20:18:40] <aystarik> right
[20:20:42] <cradek> is a cubic spline the same as a nurbs with two control points?
[20:21:24] <aystarik> seems so.
[20:21:50] <micges> hi seb_kuzminsky
[20:21:58] <seb_kuzminsky> hi micges
[20:23:12] <micges> I have question: if float a = 1.0, b =1.0 ; in c code they always be equal?
[20:23:54] <cradek> yes, but I bet your real question isn't so simple
[20:27:13] <micges> here it is: I've refactored some part of tp.c to try to fix blending tangent arcs, yesterday I had blending at 0.3, exceeding commanded 0.1
[20:27:59] <micges> today at same pc, same source, same config test cases works perfectly :|
[20:28:23] <micges> no idea what else matters..
[20:28:25] <micges> brb
[20:30:14] <aystarik> 'make clean' in between? :)
[20:36:57] <cradek> micges: did you figure out the math for deviation of arc-arc and arc-line? I (obviously) only did the line-line case.
[20:37:18] <cradek> plugging in the right math in that spot will make it work - not sure what you mean by refactoring to fix it.
[20:38:28] <cradek> (it's well commented and there is a picture in blend.fig)
[20:42:05] <micges> cradek: not yet
[20:44:07] <cradek> do you understand the cause of the problem?
[20:44:16] <micges> refactor in mean of understand it
[20:44:59] <cradek> ok when you have a proposed fix, please be sure the refactor and fix are separate so we can pick one or the other or both
[20:45:01] <micges> not yet, trying from sunday to do it, but only spended 4h to
[20:45:25] <micges> rest was services :|
[20:45:31] <cradek> a fix might be appropriate to go in 2.4 - a refactor that changes more than the absolute minimum amount of code cannot go in 2.4
[20:45:51] <cradek> services?
[20:45:54] <micges> I got it
[20:46:16] <micges> err machine failures :)
[20:46:25] <cradek> ah, sorry to hear that :-/
[20:46:50] <cradek> a fix for arc-arc and arc-line blending tolerance doesn't seem easy to me - hope you can get it
[20:47:13] <micges> gladly not our faults, but many hours in a car
[20:48:14] <micges> I must fix it, other case our company leaves emc as a base motion controller for plasmas and lasers :/
[20:48:43] <micges> until it will be fixed :)
[20:48:48] <cradek> ah! very strong incentive is good! :-)
[20:49:27] <micges> hehe yeah
[20:49:36] <skunkworks_> I thought that the nieve cam converted arcs to lines..
[20:49:44] <skunkworks_> and then blended them
[20:50:06] <cradek> only if they are so small that they don't matter (completely within tolerance limit)
[20:50:21] <cradek> micges is seeing a different problem that we've known for a long time
[20:50:43] <micges> to much deviation to achieve high feedrates
[20:51:02] <cradek> when lines are tangent/continuous you can blend them as far as you like because it doesn't matter. when arc ends are tangent, you can't, because you don't stay on the arc
[20:51:55] <cradek> micges has to calculate the deviation of the blend for arc-arc, arc-line, line-arc
[20:52:28] <skunkworks_> sounds like fun :)
[20:52:33] <cradek> if you make a huge circle out of four quadrant arcs and run it with high speed and very low acceleration, you'll see some big unexpected deviation
[20:52:55] <cradek> the path won't be very round at all
[20:53:09] <skunkworks_> huh - interesting
[20:54:19] <micges> skunkworks_:
http://imagebin.ca/view/K25wRF.html
[20:55:03] <skunkworks_> ah - interesting.
[20:55:27] <cradek> not much scale there to go on, but yeah that's like what I expected to see
[20:55:45] <cradek> it will do that even with G64 P.001
[20:55:55] <micges> yep
[20:56:09] <micges> only acc matters on that case
[20:56:15] <cradek> yes
[20:57:01] <micges> to make proper path on machine we're building I should set acc to 40000 :D
[20:57:05] <micges> 4g
[20:57:55] <micges> little to much
[20:59:45] <skunkworks_> heh
[21:00:03] <skunkworks_> you have something working now?
[21:00:26] <micges> what working?
[21:00:49] <skunkworks_> your fiddling with the tp.c
[21:01:18] <micges> not yet
[21:01:35] <micges> will be informing here
[21:03:44] <skunkworks_> neat!
