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