Back
[12:07:34] <micges_work> cradek: hi
[12:34:42] <micges_work> alex_joni: do we updated any parts of rcslib since we included it to emc source tree?
[12:35:20] <micges_work> I mean newest rcslib is from 12.2009
[12:50:53] <alex_joni> hmm.. I don't think so
[12:51:01] <alex_joni> rcslib sources are still at sourceforge
[12:55:09] <alex_joni> hmm.. this is interesting:
[12:55:18] <alex_joni> "Multireader queues were added. With multireader queues every reader will get
[12:55:18] <alex_joni> every message (assuming the queue does not become full). With normal NML queues while multiple processes could read from the same queue only one process
[12:55:21] <alex_joni> would get each message, removing it from the queue so that it is no longer
[12:55:24] <alex_joni> available to the other processes. This is intended to be used with OE Endpoints and OE Endpoint Groups however neither of these has yet been implemented on
[12:55:27] <alex_joni> topof NML. "
[12:55:35] <alex_joni> sounds like something very usefull for emc2 GUIs
[12:55:56] <micges_work> alex_joni: can't find it
[12:56:05] <alex_joni> from the changelog
[12:56:11] <alex_joni> CHANGES.TXT (2004..)
[12:56:24] <micges_work> eariler I've looked here
http://www.isd.mel.nist.gov/projects/rcslib/getrcs.html
[12:56:47] <alex_joni> yes, that's where I just downloaded it from
[12:56:58] <alex_joni> http://www.isd.mel.nist.gov/projects/rcslib/rcslib-2009.12.17.tar.gz
[16:09:19] <cradek> approximate fix for arc blend out of tolerance in tolerance mode:
http://timeguy.com/cradek-files/emc/arc-blending.diff
[16:38:08] <skunkworks> cradek: aproximate?
[16:38:45] <cradek> yes, an exact solution seems much harder and this looks like it has adequate results
[16:38:53] <skunkworks> neat!
[16:39:14] <cradek> I think micges is still testing but initial reports are good :-)
[16:39:29] <micges> yes I'm testing :)
[16:40:40] <cradek> micges: I'd love to see screenshots of the blends in your test cases
[16:43:25] <micges> http://imagebin.ca/view/SCJ6HxRh.html
[16:43:55] <cradek> that is the bad one you showed skunkworks yesterday?
[16:44:29] <micges> yes
[16:44:39] <cradek> good - much better
[16:44:41] <micges> this is max zoomed
[16:44:45] <skunkworks> very nice!
[16:44:57] <cradek> looks like you still got a bit of blend there, so it didn't have to stop
[16:45:36] <cradek> skunkworks: (a little hack makes AXIS show the blend in yellow)
[16:46:32] <skunkworks> cradek: I saw your comments in the code. (I remember that from when you first started playing with the tp. :)
[16:57:09] <micges> http://imagebin.ca/view/4u4fGFl.html
[16:57:44] <micges> cradek: better path is setting f8000 with acc=800
[16:58:00] <cradek> micges: does it stay in tolerance?
[16:58:03] <micges> worse is setting f1000 and set AF=8.0
[16:58:25] <cradek> AF?
[16:58:46] <micges> with G64 P0.01 it has deviation 0.037
[16:58:54] <cradek> which one?
[16:59:09] <micges> sorry, once agian
[16:59:26] <micges> better one is correct
[16:59:37] <micges> with G64 P0.1 it has deviation 0.037
[16:59:49] <micges> so it very good blends
[17:01:22] <micges> so it seems that your solution will works
[17:02:40] <cradek> yay
[17:03:58] <CIA-2> EMC: 03cradek 07v2.4_branch * rb8eb1be3d826 10/src/emc/kinematics/tc.c: Approximately fix overblending of arcs.
[17:04:47] <micges> yay
[17:06:53] <micges> thanks cradek
[17:08:06] <cradek> welcome
[17:08:36] <cradek> unfortunately now I can't say that someone else touched it last
[17:19:40] <skunkworks> Neat!
[17:27:00] <micges> cradek: it would be better if we comment that two functions in tc.c better
[17:27:06] <micges> they're messy
[17:27:45] <cradek> now getStarting doesn't really do what its name says
[17:27:57] <cradek> (other than that I don't think they are very messy)
[18:27:24] <aystarik> is maxaccel isotropic?
[18:29:03] <aystarik> as I understand, its magnitude should be 1x if aligned with axis, and 1.4x if 45 degree to them?
[18:29:21] <cradek> which maxaccel do you mean?
[18:30:46] <aystarik> the one written to line/circle?
[18:31:02] <aystarik> the one we use in tp.c calcs
[18:31:31] <cradek> that is what the canon level calculates as the maximum allowed *along the path* that obeys all machine constraints
[18:32:43] <aystarik> ok
[18:33:27] <aystarik> so every line segment will have different maxaccel?
[18:34:12] <cradek> if they go in different directions, yes
[18:35:17] <cradek> (same for maxvel)
[18:36:11] <aystarik> maxvel is cupped by feedrate, so it is not that important...
[18:36:22] <micges> aystarik: see src/emc/task/emccanon.cc line 531
[18:36:37] <cradek> when FO > 100% it is important. that is why it's passed along
[18:39:52] <aystarik> yes, I understand
[18:43:20] <aystarik> cradek, do I understand right and if cos(theta)=0 we should not do _blending_ but rather match speed at the end of tc and beginning of nexttc?
[18:51:09] <cradek> yes if they have the same velocity you could skip the blend, but it might be tricky since at the particular velocity, the segment might not chop up into an integer number of pieces of servo cycle length.
[18:52:45] <cradek> for lines it does not matter - for arcs the improvement you're talking about will keep the tool on the path better without slowing down
[18:55:26] <aystarik> and it does not _hurt_ line-line case
[18:55:59] <cradek> right, I think it would be no harm
[18:56:36] <cradek> you have to be careful though - if the segment you blend into is the last segment but is not long enough to stop, you are too late. you have to check more than the angle if you want to do it.
[18:57:10] <cradek> ideally you could join more than one segment this way and plan them all together (exactly what the old segmentqueue planner does)
[18:57:28] <aystarik> how much lookahead current algo does? one segment?
[18:58:50] <cradek> depends what you mean. if using tolerance mode, up to 100 segments can get linked together
[18:59:28] <cradek> (before the realtime layer even sees them)
[19:00:02] <aystarik> it's in emccanon?
[19:00:08] <cradek> the realtime layer plans every move it gets, and blends together the adjacent ones
[19:00:12] <cradek> yes
[19:03:35] <aystarik> does the upper layer knows there to stop? Is it possible to propogate maxvel from the end ?
[19:05:16] <cradek> slight parse error - can you rephrase?
[19:07:47] <aystarik> if emccanon knows there line segment should have 0 speed (stop), we could propogate maxvel back, so we could stop at that point using maxaccel
[19:09:10] <cradek> aystarik: yes when I get started thinking about that sort of thing I quickly get lost in stuff like - what if you want to pause and then step one line at a time - what if you turn feed override up - etc
[19:09:40] <cradek> seems like in those cases maybe you'd have to discard the preplanning and do it all again
[19:10:39] <aystarik> yes, but that case is user-acked...
[19:12:24] <aystarik> I mean user expects some sub-optimal behavior in such cases :)
[20:43:15] <alex_joni> cradek: seen
http://kunena.uservoice.com/forums/11439-kunena/suggestions/113837-mail-to-forum-ability ?
[20:43:42] <alex_joni> "I need this because most of my users are elderly and they are accustomed to using Yahoo! & Google mailing list." <- LOL
[20:44:28] <cradek> hahahahaha
[20:45:12] <alex_joni> guess we're all elderly by that definition ;)
[21:19:08] <mozmck> cradek, looks like the arc blending is partly fixed now?
[21:24:43] <alex_joni> mozmck: looks like it
[21:24:47] <alex_joni> for 2.4 even
[21:25:22] <mozmck> neat. looks like he didn't even have to change the algorithm...
[21:34:30] <alex_joni> mozmck: unlikely that you'll get a reply on the RTAI mailing list :/
[21:34:42] <mozmck> looks like
[21:35:19] <mozmck> I'm not sure if the bugs are really fixed that paolo said should be in the latest patch.
[21:35:32] <alex_joni> are you using : adeos-ipipe-2.6.32.7-x86-2.6-01.patch ?
[21:36:03] <mozmck> at least one guy reported the same problem with the newest patch
[21:36:55] <alex_joni> newest patch from RTAI?
[21:37:01] <mozmck> I'm using hal-linux-2.6.32.7-x86-2.6-01.patch from magma
[21:37:18] <mozmck> I think that's what he said
[21:37:44] <mozmck> he used...
[21:37:48] <alex_joni> hmm.. seems that's the latest
[21:37:54] <alex_joni> both from RTAI and from ADEOS
[21:38:22] <alex_joni> if there's going to a new patch, you'll probably find it here first (
http://download.gna.org/adeos/patches/v2.6/x86/)
[21:39:11] <mozmck> I have the same problem with 2.6.32.7 kernel and 2.6.31.8 before.
[21:39:11] <mozmck> System does not boot after grub menu.
[21:39:41] <mozmck> that's from the email on rtai by Vitaly
[21:39:52] <alex_joni> and that's a PITA to debug
[21:40:11] <alex_joni> did you try other boot flags?
[21:41:13] <alex_joni> like: noapic, nolapic, noacpi, irqpoll, etc
[21:41:29] <alex_joni> acpi=off
[21:48:14] <mozmck> from what I've understood the rtai folks make changes to the adeos patch...
[21:48:30] <mozmck> stuff going on - in and out here...
[21:49:07] <mozmck> I haven't tried those flags yet. nomodeset got it to boot. I haven't gotten back and gotten rtai and emc compiled yet either...
[21:53:16] <aystarik> i once fixed 9.10 booting by moving back to grub 1.0
[21:54:08] <cradek> is it harder with each ubuntu release to rebuild the kernel package and have it actually work?
[21:54:30] <mozmck> huh, that's interesting. guy on the rtai list said he though some of the problems with the new booting stuff.
[21:55:32] <mozmck> that didn't make any sense...
[21:55:39] <cradek> I noticed that too
[21:56:18] <mozmck> he thought some of the problems were with the new boot config and dbus stuff. (that any better?)
[21:56:44] <cradek> I can parse that now, but I don't know much about what it means
[21:58:59] <mozmck> quote: "Your problem is probably related to the new boot mechanism which used the
[21:58:59] <mozmck> "*.conf" files under /etc/init and only partially the files under /etc/initd. "
[21:59:24] <mozmck> not sure either. I don't know why they have to keep changing stuff that works already...
[21:59:48] <cradek> I think the idea with these changes is to get it to boot (much) faster
[22:00:15] <cradek> I wouldn't think the kernel would have much to do with it, but what do I know
[22:00:22] <mozmck> yeah, some of them are.
[22:01:02] <mozmck> 10.04 does boot faster. and shut down faster.
[22:01:42] <mozmck> anyone see these yet?
http://www.uirobot.com/robot-archive-a-344.html
[22:01:47] <cradek> I guess that's important to some folks
[22:02:31] <mozmck> http://www.mechmate.com/forums/showthread.php?t=2687
[22:04:54] <mozmck> yes, it's nice, if it doesn't break too much stuff.
[22:04:54] <mozmck> bbl it's too nice outside to sit in here right now.
[22:07:39] <cradek> those look interesting
[22:09:17] <alex_joni> * alex_joni heads to bed..
[22:09:23] <alex_joni> good night all
[23:10:21] <mozmck> cradek, so was it the implementation or the theory that was not right on the arc blending?
[23:15:16] <mozmck> looking at your commit comment, I think I understand most of it...
[23:16:30] <cradek> it was an oversight in the design, not an implementation bug
[23:18:45] <cradek> the only good things about the fix are: I'm sure it doesn't break anything, it seems to make it work close to right
[23:19:22] <cradek> the math to get it exactly right isn't obvious to me
[23:27:58] <mozmck> I see. I would like to understand some of this stuff better, and I think I slowly am. fascinating stuff...
[23:30:12] <mozmck> do you even need blending on arcs where the ends have the same tangent? (I presume that's what is meant by tangent arcs?)
[23:45:32] <skunkworks> different size arcs?
[23:45:41] <skunkworks> big to small or such