Back
[05:52:19] <jthornton> cradek, yep a spammer
[09:57:02] <KGB-linuxcnc> 03Dewey Garrett 052.6 2da9de9 06linuxcnc 10(5 files in 2 dirs) xhc-hb04: synthesize several per-axis buttons * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2da9de9
[11:28:42] <skunkworks> pcw_home, error-previous-target = TRUE really is nice...
[11:29:18] <pcw_home> Yeah otherwise you have a conflict with the I term
[11:29:50] <skunkworks> well - for the k&t - ff1 is now really close - or is 1...
[11:30:52] <skunkworks> (when I tuned it originally I used following error - probably should have use pid error instead at the time...)
[11:31:09] <pcw_home> If you have a velocity mode drive and normalized PID output (scaled in machine units per second)
[11:31:11] <pcw_home> 1 is the expected value for FF1
[11:31:17] <skunkworks> exactly...
[11:32:02] <pcw_home> so with the PID driven stepgen FF1 is 1.000
[11:32:23] <pcw_home> and does 99.9% of the control
[11:32:28] <skunkworks> Y was the worse - chris spend a little time on it - but it is down to a few tenths following error at 180ipm
[11:32:47] <skunkworks> x and z only need the ff1 set to 1
[11:32:55] <pcw_home> Thats pretty good (probably a lot better than original)
[11:33:14] <skunkworks> oh - I am sure..
[11:34:11] <skunkworks> I think the few tenths was jerk...
[11:34:36] <skunkworks> although it is all fuzzing together now..
[11:34:51] <skunkworks> either way - it is much better now.
[11:35:09] <pcw_home> Yeah until theres a finite jerk TP that's unavoidable
[11:35:47] <pcw_home> (well you can lower acceleration but thats no fun)
[11:37:20] <skunkworks> this is pretty low 12 - 15in/s^2 acceleration... but with the new tp - you could feel it (mainly because of the small amount of backlash in z)
[11:39:38] <pcw_home> a finite jerk TP would probably make the backlash a bit more liveable (slower reversals)
[11:39:46] <skunkworks> right
[11:39:50] <skunkworks> some day :)\
[11:40:19] <pcw_home> micges is doing something with it not sure what
[11:40:33] <pcw_home> (I mean with the source)
[11:41:04] <skunkworks> right. it would have to be shoe horned into the new tp - I think he is working with the current TP
[11:41:11] <micges1> I almost finished porting, on two days left, then tests on real machine
[11:41:24] <skunkworks> cool
[11:42:21] <micges1> Robert will guide me to introduce jerk into his tp, but it will be few weeks from now
[11:44:07] <skunkworks> that would be awesome
[11:44:23] <micges1> I must release mesaflash and docs for it then I'll make machinekit image with mesa ethernet support,then again fun with tp
[11:45:37] <pcw_home> didn't check today yet but as of last Friday hm2_eth up 45 days 24/7 at 2 KHz on J1800
[11:45:50] <micges1> and I NEED to test this error-previous-target
[11:45:59] <zultron> micges1, are you adding RTnet to some kernel?
[11:46:12] <zultron> And if so, which?
[11:46:59] <micges1> not now, rt-preempt first
[11:47:38] <micges1> pcw_home: so seems no more memleaks in driver
[11:48:12] <pcw_home> if they are they must be pretty slow leaks :-)
[11:48:35] <micges1> zultron: I worked with xenomai 2.6.2.1 with latest rtnet and kernel > 3.2
[11:48:50] <zultron> micges1, I see. If/when you ever do, let me know; I'm interested in pulling RTnet into my kernel packages.
[11:49:12] <micges1> zultron: oh ok
[11:49:58] <pcw_home> RTnet ought to be capable of faster servo thread rates as the expense of limited MAC choices and general fussyness
[11:50:08] <pcw_home> at the expense
[11:52:00] <zultron> Yeah. And it might not be horrible to port the Beaglebone NIC driver to RTnet.
[11:52:21] <micges1> jerk planner on top of master:
http://ibin.co/1NK35q4FFbje
[11:52:25] * zultron says something he's completely unqualified to say
[11:53:11] <micges1> rtnet drivers are all mess
[11:54:35] <pcw_home> You need skunkworks to pound on the jerk limited TP :-)
[11:55:12] <micges1> yeah I know :)
[13:07:23] <skunkworks_> logger[psha],
[13:07:24] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-09.html
[16:31:14] <andypugh> I wonder if Aran is being paid for this job that PCW and I are doing for him?
[17:16:14] <skunkworks_> most likely..
[17:17:46] <skunkworks_> machinekit is having a meeting in madison at the end of June.. Linuxcnc must be evil now.
[17:20:14] <andypugh> Well we rejected all the Tormach mods after all :-(
[17:20:44] <andypugh> (I am not entirely sure the “we” were up there.
[18:02:45] <seb_kuzminsky> at least some of the mods we rejected were kind of crazy
[18:02:52] <seb_kuzminsky> forking redis?
[18:05:47] <CaptHindsight> machinekit in Madison Wi?!
[18:07:19] <andypugh> Tormach offered to host a meetup last year too.
[18:08:32] <CaptHindsight> not a long drive for me
[18:08:55] <CaptHindsight> I just can't stand all that maker stuff
[18:09:34] <CaptHindsight> Linuxcnc in Houston this year it looks like
[18:10:09] <andypugh> I am not happy about the split. I don’t feel to belong in either camp :-(
[18:12:58] <seb_kuzminsky> i think the split was good for both communities
[18:13:20] <andypugh> I think it is bad that it became two communities
[18:13:26] <seb_kuzminsky> i'm sorry you don't feel part of linuxcnc
[18:13:37] <seb_kuzminsky> i've thought of you as one of us for a long time, fwiw
[18:14:44] <seb_kuzminsky> if the two communities had been better at communicating and cooperating, then it would have been better if we'd stayed together
[18:15:14] <seb_kuzminsky> but there was too big a difference in collaboration style between the linuxcnc group and the machinekit group
[18:15:30] <andypugh> They have some pretty cool stuff, and I don’t see it finding its way back to LinuxCNC
[18:16:13] <CaptHindsight> andypugh: whay did you notice that is neat? I haven't been following
[18:16:19] <CaptHindsight> whay/what
[18:16:28] <seb_kuzminsky> they have a lot of cool stuff, and i agree it probably won't make it back to linuxcnc
[18:16:45] <seb_kuzminsky> maybe if they had followed the c4 collaboration guidelines it would have made it in...
[18:16:58] <andypugh> I am slightly worried that they are pushing a somewhat flaky experimental system and have users comoplaining that the 2.6 LinuxCNC on BBB wasn’t right on their “production machine” !
[18:17:26] <andypugh> The distributed HAL and replacement for NML looks like a win
[18:17:37] <seb_kuzminsky> replacing nml would be a huge win
[18:17:46] <seb_kuzminsky> they're not using the linuxcnc name, are they? that's not ok
[18:18:20] <seb_kuzminsky> bbl
[18:18:30] <andypugh> I was sort-of waiting for that NML replacement for the tool table stuff, because that would let userspace Python code field the toolchange messages
[18:24:18] <CaptHindsight> I wouldn't mind a version that runs on an imx6, A10/20/80 or similar.
[18:25:14] <andypugh> I _think_ I have nearly managed that. I got it to launch but not run on a Udoo
[18:25:31] <andypugh> Using the UBC branch and a home-patched kernel
[18:25:54] <CaptHindsight> I need the SOC to run a GUI in HD on the machine
[18:27:41] <andypugh> The Udoo could do that, it’s got a ton of CPU
[18:28:19] <andypugh> (quad core 1Ghz and a lot of IO on an Arduino pinout. (and there is an Arduino sharing the pins)
[18:28:59] <CaptHindsight> yeah, we started on the A20 cubie2, but the tool chain is a mess
[18:29:16] <CaptHindsight> almost all magic
[19:02:49] <skunkworks_> seb_kuzminsky: 2.6-pre runs great on the k&t
[19:47:14] <cradek> I didn't think redis ever did anything...? someone copied it wholesale into our tree and made it sort of build, and then removed it because everyone agreed doing that is a terrible idea, and then that was the last I heard of it
[19:55:14] <cradek> like andy, I was also unhappy that MK gave our major changes to users without (apparently) suitable release notes or instructions, and it reflected badly on linuxcnc
[19:55:32] <cradek> that's bad for EVERYONE, not just our feelings
[19:55:53] <cradek> (but I'm not losing sleep over it)