Back
[00:03:19] <KGB-linuxcnc> 03seb 05master 7c32c4a 06linuxcnc 10tests/ 10(12 files in 11 dirs) * tests: use NO_FORCE_HOMING with the linuxcncrsh tests
[00:03:19] <KGB-linuxcnc> 03seb 05master c237d02 06linuxcnc * Merge remote-tracking branch 'origin/v2.5_branch'
[00:44:32] <seb_kuzminsky> holy shit, ja3 has soft limits for teleop jogging
[00:45:03] <seb_kuzminsky> wish i'd been paying attention back in 2010 when micges added it...
[00:54:37] <CaptHindsight> does it look like ARM only for Xenomai + kernel 3.x for the next release?
[00:55:28] <CaptHindsight> will there be any 3.x kernel support for x86?
[00:56:44] <CaptHindsight> + realtime anyflavor
[00:57:35] <seb_kuzminsky> i'm hoping we'll merge zultron & mhaberler's rtos work for the next release
[00:57:58] <seb_kuzminsky> then we'd have linux 3.x xenomai and rt-preempt on x6, 32-bit & 64-bit, plus maybe xenomai on arm
[00:58:08] <CaptHindsight> any idea of the versions of the kernel and what RT flavor?
[00:59:06] <seb_kuzminsky> the current target for is linux 3.5.7 with xenomai 2.6.2.1
[00:59:18] <CaptHindsight> Lars and Alec are working on an in kernel debugger for RT-PREEMP
[00:59:37] <seb_kuzminsky> cool
[00:59:54] <seb_kuzminsky> i think the new rtos branch also works with rt-preempt
[01:00:01] <seb_kuzminsky> but i haven't tried that part yet
[01:00:59] <CaptHindsight> they have tried all the clearly available combinations and it all stalls out with the page fault problems
[01:01:33] <CaptHindsight> if you find anything post it in the open
[01:01:40] <seb_kuzminsky> do you mean all the realtime kernels have the pagefault problem, or all the rt-preempt kernel have the pf problem?
[01:01:55] <seb_kuzminsky> ie does it affect xenomai too, or just rt-preempt?
[01:01:56] <CaptHindsight> RT-PREEMPT so far
[01:02:25] <seb_kuzminsky> were you and jepler working on that? something about mlockall() not working right?
[01:02:48] <CaptHindsight> Lars said that everything is already mlocked
[01:03:31] <seb_kuzminsky> i thought mlock prefaulted everything? so only new allocations can cause page faults after mlockall returns
[01:03:35] <seb_kuzminsky> does that match your observations?
[01:04:08] <CaptHindsight> we don't know, that is why we are writing the in kernel debugger
[01:04:44] <CaptHindsight> they are writing their own ftrace kernel module that will collect all the info regarding latency issues
[01:04:54] <seb_kuzminsky> i think i'd use pmc before a kernel debugger for that kind of debugging
[01:05:05] <seb_kuzminsky> but i'm not doing the work, so i don't get a vote ;-)
[01:06:09] <linuxcnc-build> build #1161 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:06:14] <CaptHindsight> Lars is doing most of it
[01:06:16] <linuxcnc-build> build #1160 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1160 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:06:20] <linuxcnc-build> build #1159 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1159 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:06:21] <linuxcnc-build> build #1158 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1158 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:06:24] <CaptHindsight> we are following his hunch
[01:06:27] <seb_kuzminsky> oh joy
[01:07:20] <CaptHindsight> I'm sorry but there is a bunch of broken code
[01:08:05] <CaptHindsight> I think we all assumed that things were actually farther along than they actually are :)
[01:09:33] <seb_kuzminsky> do you mean the rt-preempt support is broken?
[01:09:49] <CaptHindsight> at this point I would go more with that all "new" realtime support is more broken than working
[01:10:05] <CaptHindsight> yes, it's broken
[01:10:12] <seb_kuzminsky> but you said above you've only tested rt-preempt so far, not xenomai
[01:10:16] <seb_kuzminsky> or did i misunderstand you?
[01:10:46] <CaptHindsight> we have tested RT=PREEMP Xenaomai and RTAI on x86
[01:11:06] <seb_kuzminsky> oh! well that's interesting news
[01:11:16] <seb_kuzminsky> what problems are you seeing on xenomai?
[01:11:44] <CaptHindsight> the ARM support apparently works but it's way ahead of x86 and we followed the howto and it doesn't work for any of us
[01:12:05] <CaptHindsight> if you use the prebuilt image it works
[01:12:24] <CaptHindsight> but nobody can recreate the steps
[01:12:31] <seb_kuzminsky> that sucks
[01:12:34] <CaptHindsight> if you can please let us know
[01:12:46] <seb_kuzminsky> i'm not working on arm at the moment...
[01:13:17] <seb_kuzminsky> i think i'll be happy if we can get 2.6 stable on lucid-rtai, and anything newer than that is a bonus
[01:13:52] <CaptHindsight> checkout memleaks avalanche RTAI branch
[01:14:33] <seb_kuzminsky> link?
[01:14:54] <CaptHindsight> https://github.com/ShabbyX/RTAI/tree/avalanche
[01:15:20] <seb_kuzminsky> is memleak == shabby? i didn't know that. so many aliases...
[01:15:53] <CaptHindsight> his tree memleaks branch
[01:15:58] <seb_kuzminsky> oh
[01:16:11] <CaptHindsight> disrto independent
[01:18:11] <CaptHindsight> memleak has kernel 2.6.38.8 and all latest long term kernel releases with RTAI based off of vulcano 3.9.1
[01:18:54] <seb_kuzminsky> is it working better than xenomai and rt-preempt?
[01:19:10] <CaptHindsight> if you're going to build memleaks branch, turn off math support in the config
[01:19:44] <CaptHindsight> it's much better and it works with v2.5_branch and Linuxcnc master
[01:20:39] <CaptHindsight> if you have questions as Alec = memleak
[01:20:46] <CaptHindsight> pm me for email
[01:20:58] <CaptHindsight> as/ask
[01:24:36] <seb_kuzminsky> well that sounds promising... Alec Ari is memleak?
[01:24:41] <CaptHindsight> yes
[01:24:44] <seb_kuzminsky> ok
[01:25:10] <seb_kuzminsky> i built some variant of 3.9.1 off volcano (i think) back in march and had lots of strange problems
[01:25:18] <seb_kuzminsky> that was out of paolo's cvs repo
[01:25:29] <seb_kuzminsky> i should try alec's branch
[01:30:57] <memleak> seb_kuzminsky: hello!
[01:31:02] <seb_kuzminsky> hi!
[01:31:27] <seb_kuzminsky> CaptHindsight tells me you have a healthy rtai branch for x86? that's awesome
[01:31:37] <memleak> yep!
[01:31:46] <seb_kuzminsky> i had bad results with paolo's 3.9.1-ish repo back in march
[01:32:00] <memleak> yeah the official tree is quite a mess.
[01:32:17] <seb_kuzminsky> you and shabby have been busy fixing it?
[01:32:35] <seb_kuzminsky> i've been lurking on some of the conversations you've been having on github
[01:33:06] <memleak> yeah the master branch on github doesn't have 2.6 kernel support anymore but it's basically a complete re-write of the tree.
[01:33:28] <memleak> yeah him and I got into an argument recently, heh.
[01:34:00] <seb_kuzminsky> it happens..
[01:34:29] <seb_kuzminsky> so what's the state of the master branch and the avalanche branch now? should i try building a kernel with it?
[01:34:48] <CaptHindsight> seb_kuzminsky: our goal is to get all the real time flavors playing well with Linuxcnc on 3.8 and higher plus distro Independence
[01:35:04] <memleak> master branch is only really there until the new RTOS gets its severe clean-up / fixing time.
[01:35:26] <memleak> if you're not using master for linuxcnc, its much better than the official magma tree.
[01:35:39] <seb_kuzminsky> is linux 3.8 an LTS kernel?
[01:36:00] <memleak> no, its EOL (and 3.x based obviously so it doesnt work with linuxcnc)
[01:36:47] <seb_kuzminsky> both linuxcnc 2.5 and master build and run with the broken rtai 3.9.1 + linux 3.5.7 kernel i built back in march, and all the tests even pass! so it's not totally broken
[01:36:52] <CaptHindsight> we just need 3.8 and higher for the driver support on new AMD hardware
[01:37:09] <memleak> 3.x works with linuxcnc on master!?
[01:37:22] <seb_kuzminsky> new drivers are good - i think the worst thing about our being stuck on lucid is missing out on all the cool new hardware
[01:37:32] <CaptHindsight> anything 3.8 and higher LTS is great
[01:37:35] <memleak> rtai 3.9.1 doesnt support 3.5.7 ...
[01:37:42] <memleak> i'm confused.. you mean magma?
[01:37:52] <memleak> RTAI magma works with linuxcnc v2.5_branch and linuxcnc master!?
[01:38:37] <seb_kuzminsky> yeah it's not the real 3.9.1, it's something out of paolo's experimental cvs repo that's only *labeled* 3.9.1...
[01:38:48] <memleak> that's magma ;)
[01:38:53] <seb_kuzminsky> heh
[01:39:09] <memleak> I did a little spin on the whole thing having the first RTAI branch named after something cold.
[01:39:33] <seb_kuzminsky> here's the most recent build from that buildbot vm:
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/361
[01:39:52] <seb_kuzminsky> if you click on the 'environment-report' stdio you can see the kernel version:
[01:40:02] <seb_kuzminsky> Linux precise-rtai-x86 3.5.7-rtai+ #5 SMP Thu Feb 28 00:21:45 MST 2013 i686 i686 i386 GNU/Linux
[01:40:15] <memleak> what is precise? ubuntu release?
[01:40:26] <seb_kuzminsky> yes, ubuntu precise == 12.04 LTS
[01:40:33] * memleak hasn't used ubuntu since 2007
[01:40:49] <seb_kuzminsky> linuxcnc devs are moving to debian in droves...
[01:41:06] <memleak> mhaberler said 3.x kernels wouldnt work with v2.5 and master...
[01:41:16] <seb_kuzminsky> that kernel is 3.5.7 from git.kernel.org, with the rtai patch from magma (i guess?)
[01:41:23] <memleak> another time that guy misleads me.. ffs
[01:41:24] <seb_kuzminsky> works a treat :-)
[01:41:37] <seb_kuzminsky> both master and 2.5
[01:41:45] <CaptHindsight> I thought I smelled fish
[01:41:57] <memleak> well i'm going to try my RTAI master branch and see if that works with linuxcnc!!
[01:42:06] <memleak> (v2.5 and master)
[01:42:21] <seb_kuzminsky> here's the most recent 2.5 build on that vm:
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/357
[01:43:17] <seb_kuzminsky> back when i was working on rtai-for-linuxcnc, i spent some time getting the kernel to load on my test machine, and once that was done the linuxcnc part just worked
[01:43:19] <memleak> well seb_kuzminsky if you want to help me test it you can try with the master branch on github too
[01:43:26] <seb_kuzminsky> hooray for rtapi!
[01:43:40] <seb_kuzminsky> yeah man i totally want a working rtai on linux 3.x, i'll help test
[01:43:52] <memleak> I spent like two months cleaning up the tree on master.
[01:44:06] <memleak> +/- 1,000,000 lines of code changed
[01:44:25] <seb_kuzminsky> yowser
[01:44:34] <CaptHindsight> well 100K anyway
[01:45:02] <seb_kuzminsky> so if i want to build rtai for linux 3.x, which repo & branch should i use? avalanche on shabby's github?
[01:45:15] <memleak> I actually got pretty fancy with python, perl, and sed to do most of it for me (it's a secret..)
[01:45:31] <memleak> avalanche doesnt have 3.x support at all, use master.
[01:45:43] <memleak> avalance is basically vulcano with better kernel-side support
[01:46:02] <memleak> for example, it has the BFQ low-latency I/O scheduler for 2.6.38.8 etc
[01:46:29] <seb_kuzminsky> ok so master on shabby's github for linux 3.x, got it!
[01:46:58] <memleak> yep! if you have any problems let me know and i'll do my best to fix whatever it is!
[01:47:29] <seb_kuzminsky> ok!
[01:47:52] <memleak> i really enjoy working on the master branch of RTAI, its pretty much all i do when i'm bored matter of fact..
[01:47:54] <seb_kuzminsky> i'll try to make that happen within the next week or so and report back
[01:48:37] <memleak> because of it's cleanliness i don't mind anymore. the main reason i cleaned it up was because it was too impossible to change anything in the tree without breaking everything else!
[01:48:42] <memleak> it was terrible!!
[01:49:16] <seb_kuzminsky> yeah it was pretty hairy, i'm glad you guys are working on it
[01:49:27] <seb_kuzminsky> are you in communication with paolo at all or is this a complete fork?
[01:49:56] <memleak> Paolo doesn't want anything to do with my code, so it's a fork.
[01:50:14] <seb_kuzminsky> bummer :-(
[01:50:23] <memleak> I've tried talking him into it but he won't budge one teeny tiny bit. Not even a few whitespace changes.
[01:50:29] <seb_kuzminsky> he ignored my bug fix patches too
[01:50:37] <memleak> yeah i don't get the guy.
[01:51:18] <memleak> Everyone on the RTAI mailing list is really just asking questions and reporting bugs about my tree.
[01:51:26] <seb_kuzminsky> thanks for the pointers, i'll try it out
[01:51:43] <memleak> it's started to take over RTAI from the looks of it, not to brag or anything but upstream people lost interest in.
[01:51:49] <seb_kuzminsky> but now i gotta look into this massive breakag i just pushed to linuxcnc master, and then it's bedtime for me
[01:53:06] <memleak> heh, i've posted some breakage myself recently, hence those comments you saw on github.
[01:53:23] <memleak> we all make mistakes :)
[01:54:24] <seb_kuzminsky> yeah... this one's been bugging everyone for months and months now :-(
[01:54:27] <memleak> the linuxcnc devs (minus one that i refuse to mention) tend to be polite about those kinds of things though :) good night seb_kuzminsky! good talkking with you
[01:54:40] <seb_kuzminsky> good talking with you too :-)
[01:54:45] <memleak> what change, if i may ask, really quick..
[01:55:04] <memleak> i noticed you've been making a lot of doc fixes. hard to really "break" those, :)
[01:55:27] <seb_kuzminsky> oh, i added a bunch of tests, using the "linuxcncrsh" user interface, and i didn't realize how broken it it
[01:55:36] <seb_kuzminsky> it sometimes hangs and causes a test failure
[01:55:44] <seb_kuzminsky> and requires manual intervention to clean up :-(
[01:55:48] <memleak> "oh no! my readme.txt won't compile anymore!"
[01:56:11] <seb_kuzminsky> heh
[02:00:06] <memleak> take care seb, talk to you soon! thanks a lot for the info about 3.x on master and v2.5 i never would have even tried it.
[02:00:26] <memleak> i'll give 3.8.13 a shot
[02:11:03] <seb_kuzminsky> this latest runtests failure is different than the no-mdi-while-homed one we saw before
[02:11:34] <seb_kuzminsky> the test.sh script connects to linuxcncrsh and starts sending stuff, but linuxcncrsh doesn't acknowledge any of it
[02:14:07] <seb_kuzminsky> task starts up but gets none of the things the test.sh client sends
[02:14:58] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-amd64-sim
[02:14:58] <linuxcnc-build> build #1162 forced
[02:14:58] <linuxcnc-build> I'll give a shout when the build finishes
[02:15:05] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386-sim
[02:15:06] <linuxcnc-build> build #1160 forced
[02:15:06] <linuxcnc-build> I'll give a shout when the build finishes
[02:15:16] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386-realtime-rip
[02:15:17] <linuxcnc-build> build #1161 forced
[02:15:17] <linuxcnc-build> I'll give a shout when the build finishes
[02:34:30] <seb_kuzminsky> oh joy, it's already onto the spanish "translation" of our docs
[02:34:36] <seb_kuzminsky> only forever more to wait
[02:46:37] <linuxcnc-build> build #1160 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1160
[02:49:22] <seb_kuzminsky> the client actually does connect to linuxcncrsh and send a ton of traffic, it looks like linuxcncrsh just doesnt act on it
[02:50:12] <seb_kuzminsky> i wonder if this ini change to the tests that i just merged to master made it worse? seems like it. it worked fine in 2.5
[02:57:14] <linuxcnc-build> Hey! build lucid-amd64-sim #1162 is complete: Retry [11retry compile exception slave lost]
[02:57:15] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1162
[02:57:22] <linuxcnc-build> Hey! build lucid-i386-realtime-rip #1161 is complete: Retry [11retry compile exception slave lost]
[02:57:23] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1161
[02:57:33] <linuxcnc-build> build #1162 forced
[02:57:33] <linuxcnc-build> I'll give a shout when the build finishes
[02:57:37] <linuxcnc-build> build #1163 forced
[02:57:37] <linuxcnc-build> I'll give a shout when the build finishes
[02:57:38] <linuxcnc-build> build #1163 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1163
[03:35:06] <linuxcnc-build> Hey! build lucid-i386-realtime-rip #1162 is complete: Warnings [8warnings compile]
[03:35:06] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1162
[09:28:00] <skunkworks> hmm - could you have 2 separate stepgens running and switch between the two at a certain velocity threshold?
[09:28:51] <skunkworks> (one would be running 1/2 step - one would be running full step..)
[09:29:39] <skunkworks> hmm - no probably not - the phasing would be wrong between the 2 most of the time...
[09:29:54] <skunkworks> (4 phase drive)
[09:30:42] <skunkworks> why even care - we are talking the difference between .0005 and .00025
[09:36:02] <skunkworks> or would it...
[09:52:49] <dgarr> my attempt at linear delta kins:
http://www.panix.com/~dgarrett/stuff/ldkins.png
[09:53:35] <jepler> all my notes are much messier than that
[09:54:14] <jepler> the arduino firmwares for rostock-type printers have equations that look substantially like the ones you end up with for inverse kinematics
[09:54:37] <dgarr> do you have a link for those?
[09:54:44] <jepler> hold on
[09:54:49] <jepler> it's on a github somewhere
[09:55:52] <jepler> https://github.com/johnoly99/Marlin-for-rostockmax-rambo/blob/master/Marlin/Marlin.pde#L1687
[09:56:47] <jepler> a notable difference between yours and theirs is that they put the build platform center at 0,0 and so all of the verticals are at non-0,0 coordinates
[09:58:47] <dgarr> thanks, i started with alec's tripodkins.c and made a sketch from there, verticals centered about the origin would probably be better
[09:59:03] <jepler> what is arm-to-base? the distance from where the arms meet the platform to the center of the platform?
[09:59:34] <jepler> they account for that by subtracting it off of DELTA_RADIUS (that's DELTA_EFFECTOR_OFFSET and/or DELTA_CARRIAGE_OFFSET)
[10:00:53] <jepler> in h_a is |AP|^2 correct? you square it again so you've got |AP|^4 as a term
[10:00:58] <jepler> and so on for h_B and h_C
[10:01:36] <dgarr> you're correct -- typo
[10:02:39] <jepler> > Crustless bread was used as an eraser in the past; a Meiji-era (1868-1912) Tokyo student said: "Bread erasers were used in place of rubber erasers, and so they would give them to us with no restriction on amount. So we thought nothing of taking these and eating a firm part to at least slightly satisfy our hunger."[1]
[10:03:56] <dgarr> updated to fix typo
[10:06:54] <jepler> I think that now matches what the johnoly99 marlin firmware is doing
[10:07:36] <jepler> are you going to do the forward kins next?
[10:07:40] <dgarr> good for some confirmation -- i was wondering if it could really be that simple
[10:07:56] <jepler> I started with the forward kins and struggled without result
[10:08:29] <jepler> probably I had the wrong approach
[10:08:30] <dgarr> forward -- will try later, alec's example should be a good guide
[10:09:11] <dgarr> alec==alex
[10:09:14] <jepler> yes
[10:10:29] <jepler> I started with some equations in sympy
[10:10:29] <jepler> x**2 + y**2 + (z-Az)**2 - L**2, # = 0
[10:10:29] <jepler> (x-Bx)**2 + y**2 + (z-Bz)**2 - L**2, # = 0
[10:10:30] <jepler> (x-Cx)**2 + (y-Cy)**2 + (z-Cz)**2 - L**2, # = 0
[10:10:44] <jepler> and asked it to solve them for me in terms of motor positions Az Bz Cz
[10:10:46] <jepler> .. but it just churned
[10:11:41] <skunkworks> does the marlin do both forward and inverse
[10:12:00] <jepler> skunkworks: no
[10:12:07] <jepler> linuxcnc is supposed to work with inverse-only so I may just try that
[10:12:08] <skunkworks> ah
[10:12:23] <jepler> and I also have a (not even compile-tested) kinematics file started:
http://emergent.unpythonic.net/files/sandbox/deltakins.c
[10:12:31] <jepler> oops no license notice
[10:12:44] <skunkworks> is it that you just can't switch from joint to world and back?
[10:13:19] <jepler> I think the way that inverse-only is supposed to work is: you can only switch from joint to world at a special position
[10:13:42] <skunkworks> ah - like home
[10:13:45] <jepler> that would be e.g. x=y=0, z=max, the position you end up in after homing
[10:13:56] <jepler> (if you use the zero-at-platform-center coordinate system anyway)
[10:14:19] <jepler> bbl
[10:15:27] <jepler> if I was trying to solve the forward kins again I think I'd ask: this circle of radius L intersects each column. Find the line-circle intersections.
[10:15:40] <jepler> (circle of radius L around xyz)
[10:54:49] * skunkworks is excited that you guys are still interested in linuxcnc...
[10:58:07] <jepler> cradek: OK for 2.5?
http://emergent.unpythonic.net/files/sandbox/0001-get-rid-of-FP-use-where-it-is-unneeded.patch
[10:58:24] <jepler> the type of tmptmp is __s32
[10:58:30] <jepler> the type of is __s32
[10:58:35] <jepler> err
[11:08:33] <cradek> jepler: sure that looks fine (what a weird smell that had)
[11:15:33] <jepler> cradek: ok, will push shortly
[11:21:48] <seb_kuzminsky> sorry about the bad smell :-/
[11:21:57] <seb_kuzminsky> i have no idea what i was thinking
[11:22:31] <seb_kuzminsky> oh, i think i just copied it from the float abs component
[11:24:42] <cradek> aha
[11:26:26] <KGB-linuxcnc> 03jepler 05v2.5_branch 399d48e 06linuxcnc 10src/hal/components/abs_s32.comp * get rid of FP use where it is unneeded
[11:28:35] * seb_kuzminsky hides in shame
[11:47:57] <jepler> er what I said earlier about solving the forward kins made no sense
[11:48:06] <jepler> I was describing solving the inverse kins again
[13:09:51] <dgarr> jepler: the forward kinematics are beyond my skill level but if found:
http://tinyurl.com/o5kajek
[13:11:21] <dgarr> may be helpful
[13:13:02] <dgarr> i wonder if deltakins.c wouldn't be better named something like lineardeltakins.c to avoid confusion
[13:14:07] <jepler> quite possibly
[13:32:03] <jepler> dgarr: looks like equations 3..5 are just waiting to be transcribed, I'll see if I'm up to it
[13:38:24] <jepler> errr except equation 3 for px has pz on the right-hand side and equation 5 for pz has px on the right-hand side
[13:47:06] <jepler> and my computer-assisted algebra system is clearly taking me afield. It seems unlikely that any of the terms of the real solution are 122880*Ay**7*Cy**3
[14:10:08] <cradek> dgarr: I think the config picker will always create ~/linuxcnc/nc_files when you use it to copy a sample config. I am not sure if pncconf/stepconf do that, though.
[14:10:42] <dgarr> jepler: ugh -- i was still trying to figure out what the subscripts on e meant -- like e(sub ix) and del e(sub 2x)
[14:11:30] <dgarr> cradek: i dont know, i was generalizing to conifgs that are hand written and don't use config pickers etc.
[14:11:39] <cradek> yeah
[14:11:55] <cradek> making it configurable would be smart (and it should be for touchy too, I suppose)
[14:12:48] <dgarr> jepler: this paper, often sited, may be useful:
http://www.lirmm.fr/~company/papers/PKM2000.pdf
[14:13:13] <jepler> dgarr: in theory, the forward kinematics are not needed
[14:13:18] <dgarr> although it doesn't give close form solution: "... can be solved easily y deriving the roots of the following ..."
[14:57:12] <jepler> python -c 'import deltakins; d = deltakins.inverse(-10,-10,0); print d, deltakins.forward(*d)'
[14:57:17] <jepler> (229.32714078364123, 232.90006724589313, 242.3931386752902) (-9.9997226503885557, -9.9997259248310346, 0.0065133032861523967)
[14:57:31] <cradek> woo
[14:57:39] <jepler> it seems like it should be substantially closer
[14:57:44] <cradek> well yeah
[14:57:47] <jepler> double precision math all the way through, and it can't get closer than .0001?
[14:57:56] <cradek> that'd diverge pretty darn fast
[14:58:20] <cradek> the z difference is huge
[15:17:54] <jepler> I probably copied something out of the paper wrong
[15:17:56] <cradek> seb_kuzminsky: I think for 2.6 we oughta take a close look at the sample configs, and remove any that are out of date enough that they probably don't work anymore, and maybe also any that can be easily reconstructed with stepconf
[15:20:54] <cradek> at first glance: stg, stepper-*, plasma-*??, nist-lathe, motenc, max, lathe-pluto, gantry??, demo_mazak, dallur-thc, boss
[15:28:09] <cradek> and any that take a weird combination of hardware that's unlikely to be found at more than one point in spacetime (especially demo_mazak, maybe etch-servo)
[15:32:05] <jepler> groan .. I found a wrong transcription from the paper (paper says 1, I wrote L^2) .. and now it's wildly wrong ! :(
[15:32:42] <jepler> (229.32714078364123, 232.90006724589313, 242.3931386752902) (9.9906503544107395, 9.7546369188957716, 469.46223564954681)
[15:33:15] <cradek> um, keep looking
[15:38:23] <jepler> oh I was taking the wrong root
[15:38:33] <jepler> (229.32714078364123, 232.90006724589313, 242.3931386752902) (-10.000000000000002, -10.000000000000004, 2.4475965131557134e-15)
[15:38:49] <cradek> ahhh
[15:39:07] <cradek> that looks very right
[15:41:15] <jepler> it's still not right
[15:45:59] <jepler> (-9.0 8.0 -6.0)->(-9.4 8.3 -15.6) err=92.1
[15:49:18] <seb_kuzminsky> cradek: good idea about dropping configs
[15:49:52] <seb_kuzminsky> i'll make a list of things i think we might want to drop, and ask (on emc-devel i guess) if anyone wants to keep any of them
[15:57:15] <jepler> the kinematics as I've implemented them appear to be right for locations where x=y and progressively more wrong elsewhere
[15:58:36] <cradek> what's special about x=y except that it's immune to certain transcription errors?
[15:58:52] <jepler> that's about it..
[15:59:16] <cradek> is it inverse or forward that's wrong?
[15:59:30] <jepler> I'm not sure how to answer that
[16:00:17] <cradek> try positions similarly near each strut - you should be able to see if inverse looks sensible
[16:00:55] <cradek> er, near each leg? I don't know what the parts are called
[16:02:28] <jepler> >>> for angle in 0, radians(120), radians(240): print inverse( 50*cos(angle), 50*sin(angle), 0)
[16:02:31] <jepler> ...
[16:02:34] <jepler> (256.75073028133727, 215.36814411606932, 215.36814411606932)
[16:02:36] <jepler> (215.36814411606932, 256.75073028133727, 215.36814411606932)
[16:02:39] <jepler> (215.36814411606929, 215.36814411606932, 256.75073028133727)
[16:02:46] <cradek> that looks sane
[16:03:14] <jepler> >>> for angle in 0, radians(120), radians(240): print forward(*inverse( 50*cos(angle), 50*sin(angle), 0))
[16:03:18] <jepler> ...
[16:03:20] <jepler> (44.568000944336895, -0.0, 25.645492798874351)
[16:03:23] <jepler> (-29.226530968688888, 50.621836566754396, -39.908500870863634)
[16:03:25] <jepler> (-23.968588782044346, -41.514813556226194, 9.7389740652418464)
[16:03:54] <cradek> would rather see those in r-theta
[16:04:09] <cradek> oh, the Zs are bogus
[16:04:16] <jepler> yes
[16:04:28] <cradek> well now you know it's the forward
[16:04:43] <jepler> yes I think so
[16:05:24] <cradek> if 0 is toward one leg, x=y has no special geometric meaning, right?
[16:05:38] <jepler> I can't figure a geometric meaning for x=y
[16:06:32] <jepler> but >>> for xy in [-50, 0, 50]: print forward(*inverse(xy, xy, 0))
[16:06:32] <jepler> ...
[16:06:32] <jepler> (-50.000000000000014, -50.000000000000007, 9.4401436457250237e-15)
[16:06:32] <jepler> (0.0, 0.0, -1.5459855617905305e-14)
[16:06:32] <jepler> (49.999999999999986, 49.999999999999993, -1.4391699191472172e-15)
[16:06:35] <jepler> but it sure is right along that line
[16:06:51] <jepler> and wrong elsewhere
[16:06:52] <jepler> >>> for xy in [-50, 0, 50]: print forward(*inverse(xy, -xy, 0))
[16:06:52] <jepler> ...
[16:06:52] <jepler> (-63.343779631977085, 62.465763697436095, -59.179630856525414)
[16:06:52] <jepler> (0.0, 0.0, -1.5459855617905305e-14)
[16:06:55] <jepler> (39.525315624147773, -38.834256341975859, 46.386207471930497)
[16:07:13] <cradek> an x vs y typo in the paper?
[16:07:34] <cradek> (unfortunately you might have to understand it all to find it)
[16:07:44] <jepler> X and Y aren't involved in the expression to solve to get Z
[16:08:08] <jepler> (as symbols)
[16:08:40] <jepler> z is a solution to the quadratic F z 2 + 2G z + H = 0
[16:08:45] <jepler> z is a solution to the quadratic F z^2 + 2G z + H = 0
[16:09:03] <jepler> where A..H are in terms of R, L, r (=0) and the joint positions
[16:11:28] <jepler> bbl
[16:11:52] <jepler> meanwhile here's a different javascript kinematics
https://gist.github.com/kastner/5279172 that includes forward code
[16:16:06] <mhaberler> jepler: at some point I would like to take up the actual-time-passed-to-thread-functions theme again (not for 2.6, but rather conceptual at this point); I have the gut feeling this could be the basis for some improvements downsteam (just raising it on the bathtub thinking agenda ;)
[17:07:24] <CaptHindsight> cool, we're gonna have accuracy down to the femto-degree :)
[20:34:04] <KGB-linuxcnc> 03dgarrett 05master ab4fa67 06linuxcnc 10(8 files in 3 dirs) * pyngcgui: allow configuring send_to_dir
[21:30:55] <jepler> I transcribed the github forward and inverse kins and they are at least inverses of each other
https://gist.github.com/kastner/5279172
[21:31:48] <jepler> I noticed that there are two conventions: first tower at (0,R) or first tower at (R,0). If I got that confused, then there would be something magic about x=y. but I was pretty sure I had those assumptions expunged from the version I wrote based on the "PKM2000" paper
[21:33:45] <jepler> deviations are now on the order of 6e-14
[21:38:50] <linuxcnc-build> build #1162 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1162 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:38:53] <linuxcnc-build> build #1165 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1165 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:42:02] <linuxcnc-build> build #1164 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1164 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:42:02] <linuxcnc-build> build #1160 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1160 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:43:02] <skunkworks> jepler: yay?
[21:50:58] <jepler> > command timed out: 1200 seconds without output, killing pid 21798
[21:51:05] <jepler> dgarr: the build failure's not your fault
[21:51:13] <jepler> seb_kuzminsky: can we take that test out and shoot it yet?
[21:51:25] <jepler> seb_kuzminsky: buildbot requires attention, since that failure makes all linuxcnc runs until reboot fail
[21:51:51] <KGB-linuxcnc> 03jepler 05jepler/lineardeltakins 596a6f5 06linuxcnc 10(6 files in 3 dirs) * Linear delta kinematics
[22:32:40] <linuxcnc-build> build #1165 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1165 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:33:30] <linuxcnc-build> build #1163 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1163 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:34:22] <linuxcnc-build> build #1164 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1164 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:35:23] <linuxcnc-build> build #1166 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1166 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:36:16] <linuxcnc-build> build #1167 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1167 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:38:04] <linuxcnc-build> build #1166 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1166 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:39:27] <linuxcnc-build> build #364 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/364 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:42:13] <linuxcnc-build> build #1163 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1163 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:42:33] <linuxcnc-build> build #1165 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1165 blamelist: Jeff Epler <jepler@unpythonic.net>
[22:42:33] <linuxcnc-build> build #1161 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1161 blamelist: Jeff Epler <jepler@unpythonic.net>
