alex_joni: do we updated any parts of rcslib since we included it to emc source tree?
I mean newest rcslib is from 12.2009
hmm.. I don't think so
rcslib sources are still at sourceforge
hmm.. this is interesting:
"Multireader queues were added. With multireader queues every reader will get
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
would get each message, removing it from the queue so that it is no longer
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
topof NML. "
sounds like something very usefull for emc2 GUIs
alex_joni: can't find it
from the changelog
eariler I've looked here http://www.isd.mel.nist.gov/projects/rcslib/getrcs.html
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
approximate fix for arc blend out of tolerance in tolerance mode: http://timeguy.com/cradek-files/emc/arc-blending.diff
yes, an exact solution seems much harder and this looks like it has adequate results
I think micges is still testing but initial reports are good :-)
yes I'm testing :)
micges: I'd love to see screenshots of the blends in your test cases
[16:43:25] <micges> http://imagebin.ca/view/SCJ6HxRh.html
that is the bad one you showed skunkworks yesterday?
good - much better
this is max zoomed
looks like you still got a bit of blend there, so it didn't have to stop
skunkworks: (a little hack makes AXIS show the blend in yellow)
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
cradek: better path is setting f8000 with acc=800
micges: does it stay in tolerance?
worse is setting f1000 and set AF=8.0
with G64 P0.01 it has deviation 0.037
sorry, once agian
better one is correct
with G64 P0.1 it has deviation 0.037
so it very good blends
so it seems that your solution will works
EMC: 03cradek 07v2.4_branch * rb8eb1be3d826 10/src/emc/kinematics/tc.c: Approximately fix overblending of arcs.
unfortunately now I can't say that someone else touched it last
cradek: it would be better if we comment that two functions in tc.c better
now getStarting doesn't really do what its name says
(other than that I don't think they are very messy)
is maxaccel isotropic?
as I understand, its magnitude should be 1x if aligned with axis, and 1.4x if 45 degree to them?
which maxaccel do you mean?
the one written to line/circle?
the one we use in tp.c calcs
that is what the canon level calculates as the maximum allowed *along the path* that obeys all machine constraints
so every line segment will have different maxaccel?
if they go in different directions, yes
(same for maxvel)
maxvel is cupped by feedrate, so it is not that important...
aystarik: see src/emc/task/emccanon.cc line 531
when FO > 100% it is important. that is why it's passed along
yes, I understand
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?
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.
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
and it does not _hurt_ line-line case
right, I think it would be no harm
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.
ideally you could join more than one segment this way and plan them all together (exactly what the old segmentqueue planner does)
how much lookahead current algo does? one segment?
depends what you mean. if using tolerance mode, up to 100 segments can get linked together
(before the realtime layer even sees them)
it's in emccanon?
the realtime layer plans every move it gets, and blends together the adjacent ones
does the upper layer knows there to stop? Is it possible to propogate maxvel from the end ?
slight parse error - can you rephrase?
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
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
seems like in those cases maybe you'd have to discard the preplanning and do it all again
yes, but that case is user-acked...
I mean user expects some sub-optimal behavior in such cases :)
cradek: seen http://kunena.uservoice.com/forums/11439-kunena/suggestions/113837-mail-to-forum-ability
"I need this because most of my users are elderly and they are accustomed to using Yahoo! & Google mailing list." <- LOL
guess we're all elderly by that definition ;)
cradek, looks like the arc blending is partly fixed now?
mozmck: looks like it
for 2.4 even
neat. looks like he didn't even have to change the algorithm...
mozmck: unlikely that you'll get a reply on the RTAI mailing list :/
I'm not sure if the bugs are really fixed that paolo said should be in the latest patch.
are you using : adeos-ipipe-18.104.22.168-x86-2.6-01.patch ?
at least one guy reported the same problem with the newest patch
newest patch from RTAI?
I'm using hal-linux-22.214.171.124-x86-2.6-01.patch from magma
I think that's what he said
hmm.. seems that's the latest
both from RTAI and from ADEOS
if there's going to a new patch, you'll probably find it here first (http://download.gna.org/adeos/patches/v2.6/x86/)
I have the same problem with 126.96.36.199 kernel and 188.8.131.52 before.
System does not boot after grub menu.
that's from the email on rtai by Vitaly
and that's a PITA to debug
did you try other boot flags?
like: noapic, nolapic, noacpi, irqpoll, etc
from what I've understood the rtai folks make changes to the adeos patch...
stuff going on - in and out here...
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...
i once fixed 9.10 booting by moving back to grub 1.0
is it harder with each ubuntu release to rebuild the kernel package and have it actually work?
huh, that's interesting. guy on the rtai list said he though some of the problems with the new booting stuff.
that didn't make any sense...
I noticed that too
he thought some of the problems were with the new boot config and dbus stuff. (that any better?)
I can parse that now, but I don't know much about what it means
quote: "Your problem is probably related to the new boot mechanism which used the
"*.conf" files under /etc/init and only partially the files under /etc/initd. "
not sure either. I don't know why they have to keep changing stuff that works already...
I think the idea with these changes is to get it to boot (much) faster
I wouldn't think the kernel would have much to do with it, but what do I know
yeah, some of them are.
10.04 does boot faster. and shut down faster.
anyone see these yet? http://www.uirobot.com/robot-archive-a-344.html
I guess that's important to some folks
[22:02:31] <mozmck> http://www.mechmate.com/forums/showthread.php?t=2687
yes, it's nice, if it doesn't break too much stuff.
bbl it's too nice outside to sit in here right now.
those look interesting
* alex_joni heads to bed..
good night all
cradek, so was it the implementation or the theory that was not right on the arc blending?
looking at your commit comment, I think I understand most of it...
it was an oversight in the design, not an implementation bug
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
the math to get it exactly right isn't obvious to me
I see. I would like to understand some of this stuff better, and I think I slowly am. fascinating stuff...
do you even need blending on arcs where the ends have the same tangent? (I presume that's what is meant by tangent arcs?)
different size arcs?
big to small or such