Does this look okay for the emc configure output?
[02:37:38] <mozmck2> http://www.pastebin.ca/1857523
just the section where it looks for the rtai stuff.
SWPadnos: there is an rtai_math module but no libm, was that the rtai math module?
libm is the gcc math library, isn't it?
(which can't be used in RT or kernel code)
I don't know. I just saw it said this: checking for kernel math support... ok, using RTAI's libm kernel module
and then: checking for rtai_libm... not found
I don't know if that's normal unfortunately
emc seems to work anyhow. it even worked when it couldn't find rtai_shm, but I fixed that.
I would have thought that rtai_shm would be necessary, because all kernel <-> userspace communications are through shared memory
(in HAL anyway)
those different blends in http://imagebin.ca/view/Ogncx2eT.html
are because some of those corners have an extra short segment near the corner.
it's as expected and not related to any possibly existent bug :-)
mozmck2: the rtai_shm test can be bogus if rtai_shm is configured as Y instead of M
emc's configure process doesn't find rtai_shm, but the shared mem mechanism is included in the kernel
(not as a module, but compiled in)
that pastebin doesn't open for me (stays blank..)
maybe it's the same for rtai_math
EMC: 03jthornton 07v2.4_branch * ree4f691d383f 10/docs/src/hal/pyvcp.lyx: added some missing info on disable pins
SWPadnos: logger is down - on #emc
no - thank you :_
I wonder why that happened
(it wasn't me)
SWPadnos: it's quite often
I meant the second disconnect/reconnect
I know it dies from time to time
[17:49:32] <alex_joni> http://doc.openerp.com/contribute/15_guidelines/coding_guidelines_python.html
might be interesting reading material
what happens if you're in G20 mode, do G64P0.001, then switch to G21?
presumably, it would still be 0.001 inches
ok. same as G1X1 being 1 inch, regardless of whether you change to G21 later
(ie, the position is still 1 inch, even if that is 25.4 mm)
guys, is there any interest to make NURBS based trajectory planner?
since the vast majority of gcode is made up of lines and arcs, and NURBS can exactly represent neither, I do not understand why that would be considered a good design choice. Would you explain it to me?
as I understand, the whole point of NURBS is what it can represent exactly both lines and arcs. Other types of splines can't, so I don't consider them
if that is so, then I am misinformed.
Both Fanuc and Siemens have their TP done with NURBS
you are right - circular arcs are representable - my mistake
does an arbitrary NURBS have a closed form solution for its acceleration in different directions?
I've found several papers, which describe ways have even jerk calculated and controlled in real time for NURBS
that sounds like a very nice benefit of switching then
I wonder how kinematics would affect a NURBS TP
if you think you can do it, count me interested
and whether it would make it easier or harder (or have no effect on complexity) to implement joint constraints on non-trivial kins machines
I am new to this area, so can't say if can do it alone...
SWPadnos: effect on joint constraints is a good question and I don't know the answer
heh. I barely know enough to ask the question :)
it is interesting to think that maybe you can just monkey the weights of control points to affect blending
today I've digging in joint constraints area, and my first idea is to interface TP to canon
don't have idea how to do that
I could dig out some papers I looked at for nurbs-TP. If I remember correctly the hard part is to go from parameter space where 0<t<1 is along the curve to how long the curve actually is
I don't understand what you mean
after few tests it seems to me that canon must simulate motion in user space
cradek, length of the curve is not trivial
micges: I also think that's right
aystarik: then that makes me think vel and acc are also not trivial?
yes, this is why we need to read papers to accomplish such TP
aystarik: I'm interested in this as well. I have a collection of papers I've found on the subject.
awallin: I think those papers could help if we're going do it
Rida Farouki has stuff on pythagorean hodograph curves relating to TP that looks interesting.
as I understand, there are 3 problems: TP itself, conversion from lines and arc into nurbs, and possibly tool-offset for nurbs. Fanuc ignores last problem, so we might lower it's priority as well...
am I miss something?
luckily (?) motion/realtime doesn't know or care about our cutter compensation and offsets
so if you can arc->nurb cutter comp isn't a special case
but it's still necessary if you want to have comp with NURBS input (like G5.x)
different issue I know
at least to start, another layer between the existing canon calls and the real interp list (which would now be exclusively nurbs I guess)
SWPadnos: interesting point. currently we just don't have that.
I bet that is another hard problem
if we want compensated nurbses, maybe we can/should move all of cutter comp into nurbs-space
if it's possible in the first place - I have no idea
there is paper on compensation for NURBS too.
that appears to make the most sense to me - it gives a uniform interface to offsetting, since lines and arcs are also NURBS
I hope we can put all these papers in a pot and stir them, and out comes a new TP
unfortunately I have about 20% success rate turning scholarly papers into working code - I hope you guys have higher
it depends on how much is left between lines :)
yes, or whether the author actually got it working before the paper's deadline (yes I've written some)
one more feature is to be able to reverse a move...
sounds like it is time for a new new tp wiki ;)
not wiki -- git branch
(meant for a spec..)
ah yes, reverse move is one of my goals too
with a git branch you could put all the papers in there right?
or would those be better put in some place on a website for people to download?
I don't think that would be the best place for them ... yeah that
papers should be on linuxcnc.org somewhere
because I have some that I don't remember where I found them and they were in unobvious places.
micges: if they're freely redistributable
the scholarly paper black market
I don't know about these, I found them around the web and downloaded them.
mozmck_work: see licence of those docs
I don't think most of them say... some were on sites for obvious download, others came up in searches and were just in directories.
maybe this is the copyright line on this one: 詳細的內容請參照附錄中的英文內文
that line says that you can copy it :)
hm, if you say so!
I see a copyright and a registered trademark symbol in there, but otherwise ... :)
good! It's from a university in China I think. All in English except the first couple pages of introduction.
I think obvoius paper can be put on linxcnc and other can be requested if needed
we want to be very sure that we're not hosting anything that shouldn't be distributed - better safe than sorry
"The purpose of this paper is to present several methods to implement NURBS interpolation."
if there's any doubt, the paper(s) can be hosted by an individual
cradek: re ja3: if we add simulation to canon, it seems that it must be interpolated whole, so many thousands of interplation calls?
or maybe other way to do this
SWPadnos: yes I agree
I don't know. the brute force approach is to chop it up into "adequate" pieces (can be somewhat bigger than servo cycle) and simulate them, and scale back the whole move proportionally if you find a joint exceeds a constraint
yeah, I don't have a regular website or I'd stick them somewhere. I might can find links to most of them again too.
here's one: http://cadcam.me.ccu.edu.tw/english/paper/journal/2007_03.pdf
now, wouldn't it be nice to have a filesystem that could keep track of where you got stuff in some sort of file attributes?
yeah! search on nurbs pc-based cnc on google scholar. there are links directly to pdfs on the right.
Here's the one I mentioned above: http://thesis.lib.ncu.edu.tw/ETD-db/ETD-search/view_etd?URN=89323109
python-numarray is no longer available on ubuntu lucid.
there is python_numpy which replaces it though. I can run emc2 as run-in-place without that even, so I'm not sure where it is used?
python-numpy I mean...
in image2gcode for sure
I see. I haven't used that yet.
I think numpy and numarray are pretty much compatible
[19:57:01] <aystarik> http://www.cadanda.com/CAD_4_1-4__04.PDF
I'll have to try running image2gcode with numpy installed and see if it works.
[19:57:59] <aystarik> http://infolib.hua.edu.vn/Fulltext/ChuyenDe/ChuyenDe07/CDe85/CheTaoMay3_50.pdf
the paper on cadanda is one I had...
[19:59:49] <aystarik> http://www.springerlink.com/content/6g02326722142274/fulltext.pdf
this one looks interesting: http://cadcam.me.ccu.edu.tw/english/paper/journal/2007_03.pdf
oh, I posted that already...
but it's interesting indeed ^)
aystarik: have to pay to see that one!
springerlink seem expensive - ~$30 per paper?
I'm connected though local university network... probably springer counts that as scientific interest... :)
here it want me to pay too
I might send it to you directly, so that it does not appear on any web?
aystarik: along thinking about new nurbs TP, I also wonder how can we connect it with needs of simulation moves in userspace
I am not aware of the problem... What is simulation in userspace?
aystarik: idea is to calculate axes vel/acc in canon like now and then simulate move to see if move extend joints vel/acc constraints
if so scale move down to be below joints cnstraints
ries_ is now known as ries