#linuxcnc-devel | Logs for 2014-02-02

[05:51:24] <trshfx> hi
[11:21:46] <zultron> logger[mah], foo
[11:21:46] <logger[mah]> zultron: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-02.html
[11:31:20] <tinkerer> hello zultron
[11:31:28] <zultron> Hi tinkerer
[11:32:29] <tinkerer> i've made a short example:
[11:32:29] <tinkerer> https://github.com/tinkercnc/testdriver
[11:33:30] <tinkerer> its independent of my original driver
[11:33:57] <zultron> I see. You're compiling this outside the LinuxCNC source tree with 'comp'?
[11:34:06] <tinkerer> jep
[11:35:22] <zultron> That must be why the rtapi_compat.o symbols aren't available.
[11:35:33] <tinkerer> i've analyzed the make mechanism
[11:35:47] <tinkerer> yes maybe
[11:35:56] <zultron> I'm afraid I haven't played with comp much. I'll see if I can make your example work.
[11:37:47] <tinkerer> when you change the comp exe on line 1219 with
[11:37:47] <tinkerer> finally:
[11:37:47] <tinkerer> print "tempdir: ", tempdir
[11:37:47] <tinkerer> #shutil.rmtree(tempdir)
[11:38:41] <tinkerer> you can see the generated files in /tmp/tmbxxxxxx
[11:39:06] <tinkerer> if instead when ;)
[11:40:39] <zultron> Handy, thanks!
[11:40:49] <tinkerer> the first problem is that the rtapi_comp.h is not in {linuxcnchome}/include
[11:41:11] <tinkerer> i've copied it manually
[11:41:29] <tinkerer> maybe its the clue to the prob
[11:42:04] <zultron> That's the first problem I'm running into also.
[11:42:27] <tinkerer> :)
[11:44:58] <zultron> tinkerer, I'm adding the .h file to the Makefile. Thanks for pointing that out.
[11:45:36] <tinkerer> ok
[11:46:26] <zultron> So the compile completed.
[11:46:59] <zultron> after I removed the #error about not being on beaglebone platform.
[11:47:20] <zultron> So to test, I'd have to run your hal program before seeing the missing symbol.
[11:47:25] <zultron> Es correcto?
[11:47:41] <tinkerer> si
[11:50:09] <zultron> No wait, have to enable the bit of code with that symbol to see it in nm output. There it is.
[11:51:19] <zultron> Alright, that looks like something one ought to be able to do. I'll have to go back & look to remember where rtapi_compat.o is normally linked in.
[11:51:35] <zultron> Gotta run right now, though. Thanks again for pointing this out.
[11:52:19] <tinkerer> well
[11:52:37] <tinkerer> sounds well :)
[11:55:31] <tinkerer> it would be kind if there would be a make-structure-schematic... :)
[11:56:56] <zultron> Yeah, I'd like that too. :-/
[11:57:21] <tinkerer> xexe
[12:13:59] <tinkerer> zultron: where did you make the changes?
[12:15:15] <zultron> Still in my tree, so you won't see them. Add rtapi/rtapi_compat.h to the Makefile HEADERS to do it for yourself.
[12:16:11] <tinkerer> which Makefile? the comp generated?
[12:16:42] <zultron> No, src/Makefile.
[12:16:57] <tinkerer> ah ok
[12:17:10] <zultron> Then it's copied to the 'include' directory in the source tree.
[12:17:39] <zultron> (Hope I understood the question; that simply does what you did manually, already.)
[12:20:39] <tinkerer> yes but it has been possible it's some Submakefiles
[12:22:51] <zultron> Well, I mean to get rtapi_compat.h somewhere that comp can read it, that's the change needed.
[12:23:02] <zultron> As for the symbol problem, I think it's something more involved.
[12:23:52] <tinkerer> yes i've understood
[12:25:20] <zultron> I think if we want to access that function from comps, it might best be declared in rtapi.h, and the function's symbol exported.
[12:25:37] <zultron> Anyway, sorry, really do have to go now. Talk to you later!
[12:33:02] <tinkerer> ok
[12:33:13] <tinkerer> seeu
[12:35:06] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 a560f1d 06linuxcnc 10(6 files) xhc-hb04 sim configs: remove two restrictions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a560f1d
[13:01:59] <skunkworks> Rob is working on non tangent line-arc blends for read ahead.
[13:02:52] <skunkworks> http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=70#43448
[13:02:54] <skunkworks> yay
[13:03:20] <skunkworks> http://www.linuxcnc.org/media/kunena/attachments/18312/workingline-arcandarc-line.png
[21:46:48] <skunkworks> dad thinks he got the estop problem figured out.. Or atleast where the issue is. A heater is opening up on a relay. He has to dig into it some more. Also why it was taking a while to allow it to reset - the heater had to cool down. (doesn't know if it is the oiler or maybe cooling fans..)
[21:48:42] <skunkworks> cradek: http://www.linuxcnc.org/media/kunena/attachments/18312/arc_parabolic_blend.ngc
[21:49:21] <skunkworks> I don't know if that is related to the bug I submitted. I guess I could add this program. Rob found that it violates constraints on the current planner
[22:03:28] <cradek> http://25.media.tumblr.com/71281acddf6480888ce8f07dfcfaf094/tumblr_mwwyqfoPr91qdlh1io1_400.gif