Back
[01:26:46] <memleak> Not sure where someone heard 3.2 and 3.0 support is dropped, they were both updated 3 days ago tops.
[01:27:18] <memleak> definitely not EOL.
[06:39:14] <jthornton> I finally guessed enough to make an anchor work... I created and anchor in axis.txt [[sec:tool-touch-off]] and a link in lathe-user.txt <<section:tool-touch-off,Tool Touch Off>> but the link just referenced the lathe-user.txt
[06:39:57] <jthornton> after I added an index entry behind the anchor the link started to work
[10:32:26] <seb_kuzminsky> here's debs of the linux 3.4.53, with the shabby/memleak rtai:
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[10:32:48] <seb_kuzminsky> boots in my vm, linuxcnc master builds & passes runtests
[10:32:58] <seb_kuzminsky> haven't tried it on real hardware yet
[10:33:00] <seb_kuzminsky> bbl
[10:35:24] <cradek> slick, thanks
[11:00:40] <ktchk> I am working on the
http://hart.sourceforge.net/rtai_installation_12_04_woc.html I can reboot with kernel 3.5.7 will try linuxcnc later
[14:43:50] <skunkworks> could axis get confused if you don't home it? (where it displays the file different from were it is running?)
[14:45:54] <seb_kuzminsky> linuxcnc has a coordinate system even when it's not homed, it just might not be aligned with your home switches
[14:46:13] <seb_kuzminsky> so it'll display the program in the correct location of the incorrect coordinate system
[14:47:53] <skunkworks> dad is having problems where the program is off from where it actually runs. I don't know why
[14:48:03] <skunkworks> on the lathe...
[14:48:32] <skunkworks> this program - but he seems to have issues withothers..
[14:48:36] <skunkworks> http://electronicsam.com/images/emco/fusee.ngc
[14:48:41] <skunkworks> (jmk's fusee)
[14:49:07] <skunkworks> so - he touches off - but it doesn't 'cut' where the program is drawn.
[14:49:18] <skunkworks> (he tried homing - same deal)
[15:06:02] <seb_kuzminsky> is there a big tool offset? wrong tool loaded?
[15:06:45] <skunkworks> no tool
[15:06:57] <skunkworks> I wonder if it is a G7,8 thing
[15:14:02] <skunkworks> bbl
[17:12:44] <CaptHindsight> just FYI when ktchk fails at building tell him to follow the readme.install @
https://github.com/ShabbyX/RTAI/blob/master/README.INSTALL
[17:17:22] <memleak> I highly doubt scilab works with my branch on the ShabbyX github tree. RTAI-lab might be even more broken.
[17:18:11] <memleak> I haven't touched anything outside of the scheduling code really.
[17:25:48] <seb_kuzminsky> memleak: i did my tests with the master branch in shabby's repo, is that the right branch to use?
[17:27:34] <memleak> yup!
[17:27:40] <seb_kuzminsky> oh good! :-)
[17:28:24] <memleak> ShabbyX couldn't quite get all the conflicts solved the right way though because of all my fancy scheduling tricks, i'm not sure what he did.
[17:28:59] <seb_kuzminsky> the other source of conflicts what the big whitespace change, i think that was a mistake
[17:29:32] <memleak> he might have fixed the compiling bugs and the merge conflicts but the code itself, mainly hal_x86.c is the new 32/64 unified code I've been working on.
[17:30:18] <memleak> I'll fix all the whitespace again, I always do.
[17:30:56] <seb_kuzminsky> why? that makes it harder to merge in the future
[17:31:04] <memleak> i have no idea what state the tree is in right now..
[17:31:19] <memleak> I can't read the code when all the indentation is terrible.
[17:31:43] <seb_kuzminsky> yeah i guess i can relate to that :-/
[17:32:02] <cradek> sometimes it makes sense to reformat the code to make it understandable, and then discard that before you make your substantive change
[17:32:24] <seb_kuzminsky> what do you mean cradek?
[17:32:36] <cradek> committing whitespace changes always makes your life harder in the future
[17:32:37] <memleak> I really don't really like how shabbyx is blindly copypastaing all of paolos code back into my branch.
[17:33:07] <memleak> I'm trying to go over the tree and clean it up, otherwise it's just a clone of the official RTAI tree.
[17:33:33] <cradek> seb_kuzminsky: if it's all wonky and unreadable, you might want to reindent or whatever, but then you usually shouldn't commit that change
[17:33:34] <memleak> and i'm trying to do a lot of work with it, and whitespace i don't really want to keep dealing with.
[17:34:13] <memleak> cradek: or just not re-commit the non-whitespace-fixed tree anymore...
[17:34:52] <cradek> it's sad that VC tools aren't smarter than diff+patch, but that's the world we live in, and whitespace changes are baffling to our merge/diff tools
[17:34:58] <memleak> paolo's code basically sucks and shabbyx is trying to keep up to date with his stuff, i'm trying to re-work all of paolo's code the right way, esepcially the scheduling code that shabbyx doesnt understand at all.
[17:35:22] <memleak> i'll have to tell him to ease off with the constant git merges..
[17:35:23] <cradek> yuck, sounds like a bad situation
[17:35:48] <seb_kuzminsky> cradek: if you fix the whitespace in a private commit, then change the code to fix a bug or whatever, then backporting the bugfix to before the whitespace has the "merge whitespace" problem, doesn't it?
[17:35:52] <memleak> eh it's alright, his mistakes will only take an hour to fix anyway
[17:36:02] <seb_kuzminsky> but i guess it's in your private tree so it doesn't confuse everyone else
[17:36:16] <cradek> seb_kuzminsky: I would discard those whitespace changes - not ever commit them
[17:36:17] <seb_kuzminsky> memleak: are you guys going to merge with paolo ever? sounds like not
[17:36:36] <seb_kuzminsky> if you're diverging from paolo
[17:36:37] <memleak> paolo has a stick up his ass, so no.
[17:37:02] <seb_kuzminsky> ... from paolo's tree and never intend to come back together, then merging his changes might not be the best way to do it
[17:37:24] <memleak> exactly. that was shabbyx's idea.
[17:37:26] <seb_kuzminsky> maybe a "manual cherry-pick" approach would be better, where you read & understand the intent of his commits, and re-implement the good parts in your repo
[17:37:33] <seb_kuzminsky> i see, yeah
[17:37:34] <memleak> he's the guy who merged all of magma back into it...
[17:37:41] <memleak> >_<
[17:37:49] <seb_kuzminsky> heh, maybe you should fork his fork of magma ;-)
[17:37:59] <memleak> nah i'll talk to him about it.
[17:38:00] <seb_kuzminsky> totally balkanize the rtai world
[17:38:01] <cradek> or maybe you should communicate and decide what you want to do
[17:38:07] <cradek> yep that :-)
[17:38:13] <memleak> he's not up-to-date with all my plans for the tree.
[17:38:20] <memleak> i'll tell him to hold off until it's done.
[17:38:21] <seb_kuzminsky> yay for healthy communication
[17:38:55] <memleak> this is my punishment for wanting to party all weekend..
[17:39:11] <seb_kuzminsky> you look away for *one second* ...
[17:39:17] <memleak> yup!
[17:39:58] <seb_kuzminsky> is there an earlier commit in master i should be using for my testing? or is the head of master still right, do you think?
[17:40:07] <seb_kuzminsky> ideally i'd like to leave the rtai hacking to you and shabby and just work on the packaging and linuxcnc side
[17:40:07] <memleak> in a few hours master will be boss.
[17:40:18] <memleak> (once again)
[17:40:19] <seb_kuzminsky> suhweet
[17:41:50] <memleak> I only really started merging 32/64 hal anyway, not all the 32/64 headers.
[17:42:30] <memleak> I have a lot of scripts that do most of the merging for me anyway.
[17:42:42] <memleak> automating a lot of this stuff..
[17:45:35] <memleak> makes merging in the future a lot less of a pain to do.
[17:49:31] <memleak> ill try and run through scilab and rtai-lab really quick too. bump 3.4 support up.
[17:50:25] <seb_kuzminsky> i'm going to try running your current master branch on some real hardware and spin some motors and stuff, possibly tonight
[17:51:08] <memleak> ok, first thing i'll do is work on the possibly really broken stuff
[18:12:18] <andypugh> Obvious bugfix to a driver only used by one person in the whole word (PCL720). Which branch?
[18:12:30] <cradek> 2.5
[18:20:29] <andypugh> Looks like I need to swap ssds...
[18:54:02] <andypugh> Looks like I didn't need to swap ssds. The commit got pushed, despite the error message, but wasn't notified by the 'bot!
[18:55:16] <andypugh> (How annoying, that was 30 minutes of reconfiguring back to an RTAI kernel and rebuilding linuxcnc, only to find that the bugfix was already there when I went to the file)
[18:55:30] <cradek> the stupid bot had fallen over
[18:55:33] <cradek> sorry it caused you trouble
[18:56:14] <cradek> the git server probably didn't say "the stupid bot has fallen over" very clearly :-/
[18:57:00] <andypugh> It said: remote: 500 Can't connect to localhost:9999 (Invalid argument) at /usr/local/lib/perl5/site_perl/5.14.2/App/KGB/Client/ServerRef.pm line 214
[18:57:01] <andypugh> remote: Unable to complete notification. All servers failed
[18:57:02] <andypugh> To ssh://andypugh@git.linuxcnc.org/git/linuxcnc.git
[18:57:03] <andypugh> 0ad42cb..5a82cec v2.5_branch -> v2.5_branch
[18:57:55] <cradek> ah. I wish you'd've asked - I might've correctly guessed what that meant
[18:58:17] <andypugh> Which I took to mean "You can't do stuff to the 2.5 branch when running a Xenomai kernel" (Well, it made sense at the time)
[18:58:36] <cradek> oh no, that's not the right guess at all...
[18:58:56] <andypugh> I interpreted "localhost" to mean, well, my machine..
[18:59:33] <cradek> brb
[18:59:37] <andypugh> And guessed at a versioning problem somewhere. You know what they say about assuming...
[18:59:49] <andypugh> I won't be, 'tis time to sleep.
[21:01:55] <skunkworks> dad thinks it was a g7,g8 issue.
[21:28:50] <seb_kuzminsky> skunkworks: oh good, i like the easy problems to fix :-)
[21:29:17] <seb_kuzminsky> so i'm running memleak's rtai on linux 3.4, and i've got the exact same problem as i saw on paolo's rtai
[21:30:03] <seb_kuzminsky> using the hm2-stepper 5i20 config, the steppers run away immediately upon starting linuxcnc
[21:30:32] <seb_kuzminsky> this is before even coming out of estop
[21:30:53] <seb_kuzminsky> the stepgen on the fpga has an 'accumulator' register that tells you how many steps the fpga has output
[21:40:44] <memleak> seb_kuzminsky, whats the exact issue?
[21:40:47] <memleak> i'd love to fix it :)
[21:41:16] <memleak> if its an issue with stepper motors and stuff, not latency issue, might be a linuxcnc issue.
[21:42:54] <memleak> post all dmesg output and kernel config
[21:48:58] <memleak> also is it a parallel port or a PCI E mesa card? (if it even is a mesa card)
[21:50:07] <memleak> if its a parallel port one you might need some fancy options like turning on and off IEEE 1234 I declare a thumb war modes, whatever it's called. also maybe messing with the DMA and or FIFO settings in the kernel, not sure.
[21:50:17] <memleak> If its PCI E make sure you're not using ASPM
[21:51:41] <seb_kuzminsky> i'm back
[21:51:47] <memleak> howdy!
[21:51:49] <seb_kuzminsky> this is with a pci card (5i20)
[21:52:14] <memleak> which kernel did you use with paolo's magma tree?
[21:52:35] <seb_kuzminsky> i can watch the writes go out of the hostmot2 driver and into a memcpy to the 5i20's memory bar, those writes are all bits 0 which is correct
[21:53:00] <seb_kuzminsky> i can watch the reads come in via memcpy from the memory bar into the hostmot2 driver, those reads show the fpga clocking out steps
[21:53:10] <seb_kuzminsky> i just tried the EPP board (7i43) and it does not have this problem
[21:53:17] <pcw_home> Yeah the stepgen should not run with a 0 rate
[21:53:18] <seb_kuzminsky> so this looks like a pci problem
[21:53:19] <memleak> does latency-test run fine and after you home your axis(es) does it work fine?
[21:53:36] <seb_kuzminsky> the machine can't home, because as soon as you come out of estop it gets a following error
[21:53:44] <pcw_home> you might try writing the LEDS
[21:53:52] <seb_kuzminsky> since the step accumulator register is showing steps going out
[21:53:57] <seb_kuzminsky> pcw_home: good idea
[21:54:05] <memleak> LEDS in linuxcnc or RTAI?
[21:54:12] <seb_kuzminsky> it's curious that i can flash the firmware and read all the module descriptors and stuff
[21:54:22] <seb_kuzminsky> leds on the 5i20, written via hostmot2 from linuxcnc
[21:54:24] <seb_kuzminsky> brb, testing
[21:54:35] <pcw_home> Yes thats pretty odd
[21:54:36] <memleak> ah ok, because RTAI has an LEDS debugging options as well
[21:54:48] <memleak> whats LEDS anyway?
[21:55:55] <pcw_home> the 5I20 has 8 "user' LEDs
[21:57:10] <memleak> pcw_home, are you now referring to LEDS debugging or light emitting diode?
[21:57:47] <pcw_home> Light Emitting Diodes
[21:58:11] <memleak> ....does RTAI really refer to that acronym the same way? i thought it meant something else..
[21:59:03] <pcw_home> I am strictly talking about debug hardware on the 5I20
[21:59:12] <memleak> ah.
[21:59:16] <seb_kuzminsky> the leds on the 5i20 blink when i write to the led pins via halcmd
[21:59:20] <seb_kuzminsky> so that part's working fine
[21:59:39] <seb_kuzminsky> when i use the raw interface to read back the led register from the fpga, i get all bits 1
[22:00:09] <seb_kuzminsky> same when i try to read back the step rate register
[22:00:09] <seb_kuzminsky> is that expected?
[22:00:18] <pcw_home> its not readable
[22:01:04] <pcw_home> Yes write only registers will read as 0xfffffff
[22:01:06] <pcw_home> trying to think of a available read/write register
[22:01:36] <seb_kuzminsky> i can read back the IO cookie and all that stuff
[22:01:41] <pcw_home> the DDR registers are R/W
[22:01:44] <seb_kuzminsky> the idrom reads fine
[22:01:47] <seb_kuzminsky> i'll check those
[22:02:51] <pcw_home> I can make a config with the stepgen rate readable (all that stuff is commented out to save space)
[22:04:00] <seb_kuzminsky> what's the ddr? i dont see it in the regmap
[22:04:11] <seb_kuzminsky> is it in the stepgen?
[22:05:03] <pcw_home> I/O port DDR (0x11xx) (best play with a unconnected port)
[22:05:04] <pcw_home> the low 24 bits are read/write
[22:05:12] <seb_kuzminsky> ah ok
[22:05:13] <seb_kuzminsky> brb
[22:08:45] <memleak> seb_kuzminsky, disable MMCONFIG support in PCI as well.
[22:08:57] <memleak> (if the issue doesnt go away)
[22:09:45] <memleak> the direct way is much less buggy and the code is much simplier for both writing to and enumerating the PCI busses
[22:12:11] <pcw_home> I know Charles S had some initial problems with some non 32 bit accesses (all hostmot2 access must be 32 bit)
[22:13:47] <seb_kuzminsky> reading the gpio ddr gives surprising values
[22:14:12] <seb_kuzminsky> i tried twiddling the .is_output pins to toggle bits in that register, and reading back the values with the raw interface
[22:14:23] <seb_kuzminsky> the ddr value changed apparently randomly
[22:14:49] <seb_kuzminsky> i've run out of time here, i'll have to debug further another day
[22:15:07] <seb_kuzminsky> pcw_home, if you want to, install precise 32-bit and install the debs here:
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[22:15:22] <seb_kuzminsky> then build the master branch of linuxcnc and try the 5i20 config
[22:15:36] <seb_kuzminsky> memleak: is MMCONFIG a kernel config option?
[22:16:22] <seb_kuzminsky> i currently have CONFIG_PCI_MMCONFIG=y
[22:17:04] <seb_kuzminsky> there are a couple of pci access methods, several are enabled, i bet i can switch at runtime (or at least boot-time)
[22:18:04] <pcw_home> OK I can try sometime this week (I can also try xenomai which is installed already)
[23:10:18] <memleak> seb_kuzminsky, use direct
[23:10:27] <memleak> yes, MMCONFIG is a kernel optio
[23:10:37] <memleak> n