Back
[05:01:54] <memleak> i see linuxcnc is not used to kernel 3.10's new version.h thingy.. include/generated/uapi/linux/version.h ;)
[05:03:27] <memleak> ah.. in order for kernel 3.10 and newer support i'll need a linuxcnc developer volunteer. 3.10 changed the way /proc works and linuxcnc/src/hal/hal_lib.c is borked
[05:13:22] <memleak> https://github.com/NTULINUX/RTAI (biggest problem is make clean and make distclean which honestly isn't the worst thing to be battling right now)
[05:15:23] <memleak> this commit broke linuxcnc but was required for 3.10 kernel support:
https://github.com/NTULINUX/RTAI/commit/aaf9ddfbaa7d347fa520bc925a60d190c06649da
[05:17:18] <memleak> pastebin.ca/2696861 <- linuxcnc compilation errors
[05:18:46] <memleak> once that's fixed we can start worrying about chasing kernels 3.12 3.14 etc (if that's the only problem linuxcnc has with 3.10 kernel that is...)
[05:20:03] <memleak> 3.10.37 RTAI kernel patch itself has been added to that RTAI tree btw
[05:28:33] <memleak> testsuite works so the scheduler and all is fine!
[05:28:37] <memleak> YES!
[05:31:39] <memleak> pastebin.ca/2696865
[08:37:59] <memleak> who wrote most of the rtapi code btw?
[08:38:13] <memleak> the stuff in master v2.x i mean^
[08:39:41] <memleak> i recall a few people in here asking about newer kernels and now that i have something, i just need the linuxcnc tree to be modified accordingly.
[08:58:57] <skunkworks__> memleak: so rtai support for 3.1x?
[09:00:34] <memleak> skunkworks_, yes, perfectly on the RTAI side but linuxcnc is throwing errors due to the way 3.10 deals with /proc
[09:01:10] <memleak> skunkworks__, pastebin.ca/2696861
[09:01:46] <memleak> i had to make these changes to RTAI userspace in order to get it to work:
https://github.com/NTULINUX/RTAI/commit/aaf9ddfbaa7d347fa520bc925a60d190c06649da
[09:02:02] <memleak> (on the RTAI side of course)
[09:03:08] <memleak> the shabbyx fork and upstream have too much code for me to deal with so i trimmed it down several MBs and really only included the necessary stuff for linuxcnc on x86
[09:03:47] <memleak> i broke make clean and make distclean so until i fix that, i suggest git clean -fd
[09:04:37] <memleak> i rather be battling with autotools and kconfig than the scheduler :)
[09:05:13] <memleak> if i can get people to take care of the linuxcnc side of things i can get 3.12 running too given enough time
[09:06:19] <memleak> i believe PCW wanted 3.12 or 3.14 because of his new intel chipset
[09:09:23] <skunkworks__> yes - the video drivers suck for < 3.1
[09:09:31] <skunkworks__> that would be awesome!
[09:09:49] <skunkworks__> we could have realtime linux running on 14.04 without too much work
[09:09:59] <skunkworks__> (sim runs just fine)
[09:10:51] <memleak> how much work would it be to update the proc stuff in linuxcnc?
[09:11:19] <skunkworks__> 1fps on 12.04
[09:11:24] <memleak> XD
[09:11:26] <cradek> I bet nobody knows that any better than you do
[09:11:32] <skunkworks__> memleak: sorry - I don't speak developer...
[09:11:46] <memleak> cradek, i dont know anything about the linuxcnc source code.
[09:12:04] <skunkworks__> memleak: what did you do to get it to work?
[09:13:10] <memleak> the kernel side of things you mean?
[09:14:42] <skunkworks__> no - I though you had got linuxcnc to run... (like you had fixed the proc)
[09:14:58] <skunkworks__> (didn't look at the pastebin)
[09:15:05] <memleak> yes, the pastebin.
[09:15:41] <memleak> i fixed proc for RTAI and kernel
[09:16:31] <memleak> took a mix of paolo's patches, took some code from adeos and modified it to make it work with RTAI, had to rebase it though off of the latest 3.10 kernel to ensure stability
[09:17:58] <skunkworks__> sounds scary :)
[09:18:09] <seb_kuzminsky> skunkworks__: did you get linuxcnc sim working on 14.04? how did you fix the tclstubs problem?
[09:18:31] <memleak> i did it all in one night so not really..
[09:19:37] <memleak> proc for linuxcnc will be hosed until someone who knows linuxcnc will fix it. i would if i knew how but im the village idiot when it comes to the linuxcnc tree
[09:19:47] <skunkworks__> tclstubs? oh - I didn't. forgot about that.. that still doesn't work.. :(
[09:20:04] <seb_kuzminsky> heh
[09:20:27] <cradek> it looks really isolated in rtapi_proc.h
[09:20:39] <cradek> I don't think there's any real "tree" knowledge needed
[09:20:39] <skunkworks__> the only thing I noticed was 'show hal configuration' doesn't work
[09:20:53] <cradek> I still suspect you know more about it than anybody else
[09:21:17] <cradek> have you found something that says how the proc interface changed?
[09:22:35] <memleak> it's all in the one single commit on github, exact syntax and everything
[09:23:06] <memleak> i made the commit history as cleanly as possible in case i'd run into this exact issue i'm facing right now
[09:23:45] <cradek> do you mean
https://github.com/NTULINUX/RTAI/commit/aaf9ddfbaa7d347fa520bc925a60d190c06649da
[09:24:00] <memleak> yes
[09:24:24] <memleak> only and only the necessary proc changes are in there
[09:27:23] <memleak> the changes to hal_32.c would be most relevant
[09:27:51] <cradek> oh good, that's one of the comprehensible parts
[09:28:56] <memleak> XD
[09:29:55] <memleak> lines specifically 1481 / 1483 to be exact
[09:34:25] <cradek> unfortunately I can't do anything more than point you at the code like I did - I have no way to run/test any changes and I'm not going to guess and push for you to try
[09:34:42] <cradek> maybe someone else can help if you don't want to make the changes
[09:37:11] <memleak> in cases like these my changes are always wrong. i fix compiling errors but open up another pandora's box later on that only other people seem to fall into.
[09:37:48] <cradek> fortunately with buildbot we can easily see whether we broke old versions - I bet that's the main pitfall to worry about here
[09:38:19] <memleak> ah yes, retaining compatibility with non 3.10 kernels is way over my head, let me say that right now.
[09:39:12] <memleak> i didnt even do that to the RTAI tree, i got it working and started jumping in joy.
[09:40:20] <memleak> an RTAI tree for every new kernel.. *_*
[09:40:43] <cradek> ugh
[09:41:52] <memleak> ill try a few things out on the linuxcnc tree later on, it's 9:30am here, no sleep so im not really in the mood for anymore C
[09:42:16] <cradek> yikes, sleep first!
[09:42:22] <cradek> no coffee until after sleep
[09:43:22] <memleak> meanwhile right next to me are three red bulls and a cup of coffee
[09:44:17] <memleak> i have no motivation to work during the day, only throughout the night, its weird.
[09:45:05] <cradek> thanks for all your rtai work, it really helps our project
[09:45:20] <seb_kuzminsky> yeah, thanks memleak!
[09:45:52] <memleak> no problem! i do it for myself too.
[09:46:39] <memleak> i think a few days ago i was talking about PREEMPT_RT not being fast enough for what we were doing so, gotta do whatcha gotta do!
[09:48:53] <skunkworks__> seb_kuzminsky: I just find vauge references to the tclStubsPtr error - like you have to point directly to libtclstubs8.6.a (or
[09:48:55] <skunkworks__> whatever version is installed).
[09:49:11] <skunkworks__> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724830
[09:49:45] <memleak> and im going ice skating soon.. probably under the worst conditions right now, eh?
[09:57:32] <skunkworks__> memleak: still ice around chicago?
[09:59:48] <memleak> it snowed i think yesterday for about 30 mins, heh
[10:00:46] * memleak is now known as Greenland
[10:09:10] <cradek> seb_kuzminsky: ooh your wiki page
[10:09:56] <seb_kuzminsky> it's not done yet...
[10:20:25] <skunkworks__> I already posted it on all the forums...
[10:20:38] <skunkworks__> ;)
[10:20:46] <seb_kuzminsky> heh
[10:20:50] * seb_kuzminsky is off to work
[16:18:37] <PCW> skunkworks_ 7I76E 2 KHz for a day so far with a newer preemt_rt kernel, getting better...
[16:42:04] <skunkworks_> PCW: awesome - what platform?
[16:48:48] <micges1> PCW: mesa 5i24-25 will have 0x15 flash id?
[16:59:46] <andypugh> micges: Any ideas? I am out of my depth:
http://www.linuxcnc.org/index.php/english/forum/49-basic-configuration/27724-homing-a-dual-motor-for-one-axis-gantry-machine/46009
[17:00:09] <micges> looking...
[17:06:34] <cradek> is he trying to do index homing?
[17:11:06] <micges> andypugh: should work this way
[17:13:30] <micges> andypugh: I'll try ja4 gantry in an hour
[17:22:14] <PCW> skunkworks_ Gigabyte J1800
[17:25:02] <PCW> micges, currently they have 0x14 id (16 Mbit)
[17:26:32] <andypugh> I am not sure what homing type he is looking at. He did seem interested in doing a version of gantry homing that worked for him, which seemed like a good start.
[17:26:42] <PCW> we use 16 Mbit pretty much every where now (so we just have to buy one type)
[17:26:44] <PCW> If we start using bigger FPGAs like XC6SLX45 we will need to go to 32 Mbit (0x15 ID)
[17:27:15] <andypugh> <ponder> Can the homing code look for clues in the kins section?
[17:32:11] <micges> PCW: I see
[17:41:51] <PCW> no, IC
[17:42:43] <seb_kuzminsky> andypugh: i think it doesn't currently
[18:18:57] <andypugh> seb_kuzminsky: I know that it doesn’t currently, and I suspect that it is probably better to explicitly deefine behaviour rather than have the software make a best-guess.
[18:34:54] <micges> andypugh: lcnc must be set in teleop mode after homing, then gentrivkins will work
[18:35:50] <andypugh> micges: I though that the whole point of gentrivkins was that it was trivial kins with no joint mode?
[18:35:51] <micges> Axis won't let me do that, it must patched in some way
[18:36:39] <micges> yes. but lcnc is default in joint mode regardless
[18:37:43] <micges> I just patched gui, but I didn't think of any acceptable solution for this
[18:38:06] <andypugh> That’s really disappointing.
[18:38:26] <andypugh> I _thought_ JA4 and gentrivins was a solution, not a problem.
[18:39:25] <micges> ja4 isn't finished
[18:40:54] <micges> hold on, I've got idea for simple fix for this
[18:54:02] <micges> andypugh: see lst post in thread
[18:54:12] <micges> works ok
[19:03:34] <andypugh> Great,
[19:04:35] <andypugh> I have been a fan of JA4 for years, I do think that it needs a concerted push. it should be merged after 2.6, even if it breaks Master, in my opinion. Not that my opinion matters.
[19:06:38] <cradek> fwiw, I agree with you
[19:07:26] <cradek> also rob's planner
[19:07:36] <cradek> not sure how much they will conflict -- probably not too bad
[19:08:17] <andypugh> Apparently not at all, the Splitters already have both.
[19:09:40] <CaptHindsight_> PCW: are the 7i90's ready for testing?
[19:09:41] <skunkworks_> spinter has ja4? I don't think so..
[19:10:04] <skunkworks_> I thought it had jog while paused and robs planner
[19:11:13] <CaptHindsight_> PCW: memleak is working on updating RTAI, will your drivers work with RTAI?
[19:11:40] <andypugh> skunkworks_: You might be right. I have kind-of backed away from both.
[19:12:17] <skunkworks_> I am about 90% sure ;)
[19:13:49] <micges> I'm 100% sure machinekit doesn't have ja4 (yet)
[19:17:58] <PCW> 7i90 should work with the 7I90 branch now
[19:18:39] <PCW> (and eventually merged when hm2_7i43 and hm2_7i90 become hm2_epp)
[19:23:56] <micges> PCW: latest binary shouldn't have epp timeout problem, I'll send you 10.04 binary later
[19:24:40] <micges> (mesaflash3)
[19:40:48] <PCW> Thanks
[19:51:27] <skunkworks_> PCW: memleak has rtai working with 3.1x.. (supposedly... ) ;)
[19:52:01] <PCW> 3.10 I heard
[21:18:57] <seb_kuzminsky> are you guys advocating breaking master because you think it will spur... someone? into fixing it? (i'm not trying to be grumpy or argumentative, i only want to understand your motivations)
[21:22:07] <seb_kuzminsky> andypugh: in
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingConfigurationsForDevelopmentVersions, it says the pin hm2_5i23.0.8i20.0.0.amp-enable was deleted - is the 8i20 just always enabled now?
[21:22:12] <seb_kuzminsky> (oh, he left)
[21:33:57] <seb_kuzminsky> heh, we now have a pin called "hm2_5i25.0.8i20.0.1.fault.no-enable-not"
[21:35:12] <seb_kuzminsky> ok, i think
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingTo2.6 has all the content it needs, did i miss anything?
[21:37:26] <skunkworks_> nice!
[21:39:05] <cradek> yay that's nice progress
[21:42:10] <cradek> seb_kuzminsky: that's a fair question. a branch can spend a very long time in the state where people have stopped really working on it, but every time you actually try to use it for something real, you find some other little thing wrong with it. I think ja4 is in that state now, and maybe has been for years, and it would be nice if early in this next cycle, people used it by default. I think (to finally answer your question) ...
[21:42:16] <cradek> ... things would shake out, and yes, it might cause a bit of motivation. There's always 2.6 for people who want something stable during the shakeout.
[21:45:35] <cradek> it is sure true, on the other hand, that people can get motivated and do the shakeout on the branch. but they don't seem to do that. WHY that's the case is more a PR or psychology question than a technical question, I think, and I don't know the answer.
[21:47:21] <seb_kuzminsky> it's probably true that merging nearly-finished things hastens detection of the lingering issues
[21:48:57] <seb_kuzminsky> the balance i'm unsure about, and worried about, is that if master doesn't work, testers will go to the stable branches, and we'll loose the eyeballs that are necessary but not sufficient for stabilizing master
[21:52:14] <skunkworks_> well - if it is anyting like the new tp.. all you need is just a couple people... :)
[21:56:30] <seb_kuzminsky> your collaboration with rob ellenberg is a wonderful example of how (imo) thinks should work - development and thurough testing on a feature branch, where it doesnt break things for other people
[21:57:42] <cradek> I'm very sympathetic to that opinion too
[21:58:42] <seb_kuzminsky> and skunkworks_ is right: "all you need is just a couple people" ;-)
[22:02:58] <cradek> ok we're all right... what the hell should we do?
[22:03:37] <cradek> we should wait for andy, I'd like to hear what he thinks
[22:07:25] <cradek> goodnight, folks
[22:10:11] <seb_kuzminsky> good night cradek
[22:10:16] <skunkworks_> night!
[22:11:27] <seb_kuzminsky> it's clear to me people are unhappy with how i decided what to merge (aka, when to release)
[22:11:37] <seb_kuzminsky> so i'd like to try some other technique next
[22:12:04] <seb_kuzminsky> maybe someone else wants to be release manager for 2.7, or maybe we should try some other kind of governance
[22:13:17] <skunkworks_> I don't know all that went down. seem from my perspective is most people expected way too much from just a hand full of people (or you alone)
[22:14:35] <skunkworks_> because the 'work was all done!' just merge it!
[22:15:13] <seb_kuzminsky> well
[22:15:22] <seb_kuzminsky> collaborating is hard
[22:15:45] <seb_kuzminsky> wow, cmorley is on a bug squashing rampage
[22:16:53] <cmorley> I'm late...I'm late... for a very important date... 2.5.4 release...
[22:17:25] <skunkworks_> heh
[22:18:16] <skunkworks_> working with rob was really easy.. He didn't have an issue at all with bugs. or suggestions. Very open minded
[22:18:52] <skunkworks_> I think we are down to issues with unequal axis velocities..
[22:18:59] <seb_kuzminsky> cmorley: about #294, i've never seen a stepgen spindle control before
[22:19:39] <skunkworks_> some bobs use frequency to voltage converters (instead of pwm)
[22:20:02] <skunkworks_> so stepgen in velocity mode works well for this
[22:20:10] <seb_kuzminsky> that makes sense
[22:20:35] <cmorley> yes i have not personally used one yet, but others have.
[22:20:42] <skunkworks_> (I assume that is what your talking about - I didn't look at #294)
[22:20:48] <skunkworks_> I have a bob that does this
[22:21:04] <skunkworks_> or - somepeople actually use steppers for spindles..
[22:21:06] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/294/
[22:21:09] <skunkworks_> or step-servos
[22:21:12] <cmorley> yes velocity mode stepper
[22:21:44] <seb_kuzminsky> i dont know what the OP is using for a spindle, but they report that the spindle brake stays on and their oscilloscope detects no pulses on that stepgen
[22:21:58] <skunkworks_> I have to go to bed - night!
[22:22:01] <seb_kuzminsky> pncconf configured the stepgen for velocity mode
[22:22:05] <seb_kuzminsky> seeya skunkworks_ !
[22:39:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 3f5e5a5 06linuxcnc 10debian/changelog 2.6.0~pre1 changelog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f5e5a5
[22:39:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 9a9a5bf 06linuxcnc 10VERSION update VERSION for 2.6.0~pre1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a9a5bf
[22:39:33] <seb_kuzminsky> bet this wont work the first time...
[23:16:24] <linuxcnc-build> build #160 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/160 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:16:32] <asah> so to check my head rawcounts on a bldc component with an absolute encoder should always increment decrement to +- infinity, correct?
[23:16:45] <asah> commutation is modded off that?
[23:17:56] <asah> (really an andy pugh question)
[23:20:33] <seb_kuzminsky> yeah that's one for andy...
[23:22:38] <asah> seems broken in the ssi interface, but I may be doing something stoopid.
[23:26:02] <seb_kuzminsky> i'd think the rawcounts would increment and decrement to the limits of the data type, which i assume is signed 32-bit integer
[23:27:14] <asah> right. true. I really mean it shouldnt reset to 0 if the absolute encoder rolls past 1.0 (or counts-per-rev)
[23:29:16] <seb_kuzminsky> looking at the hostmot2(9) manpage, it seems like there are two kinds of ssi encoders, regular and "split", and the split kind maybe reverts to 0 after one revolution?
[23:29:22] <seb_kuzminsky> i really don't know
[23:30:03] <seb_kuzminsky> grump, "git push" doesn't push tags by default
[23:32:42] <asah> thanks seb.
[23:34:15] <seb_kuzminsky> asah: hope that helps, try emailing the emc-developers list if it's still not working right for you
[23:37:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 8060e4e 06linuxcnc 03v2.6.0-pre1 LinuxCNC 2.6.0~pre1 (tagged commit: 9a9a5bf) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8060e4e
[23:38:06] <seb_kuzminsky> linuxcnc-build: help force
[23:38:06] <linuxcnc-build> Usage: force build [--branch=branch] [--revision=revision] [--props=prop1=val1,prop2=val2...] <which> <reason> - Force a build
[23:46:07] <linuxcnc-build> build #161 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/161 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:46:10] <asah> PCW: the ssi code doesn’t look like it is doing any velocity calcs.