Back
[00:11:03] <KGB-linuxcnc> 03Chris Morley 05v2.5_branch cdacc13 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -honour 7i43 address changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cdacc13
[00:11:03] <KGB-linuxcnc> 03Chris Morley 05v2.5_branch 448a200 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix off by one error on pin numbering of 5i25 boards * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=448a200
[00:17:27] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision=v2.6.0-pre1 0000.checkin
[00:17:33] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[01:03:45] <linuxcnc-build> build #162 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/162 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[01:26:08] <seb_kuzminsky> does anyone know who ArcEye <arceye@mgware.co.uk> is? we've got a commit in 2.6 from him, but no real name :-/
[01:27:13] <seb_kuzminsky> also, i'm assuming aw@aw-VirtualBox.(none) (author of commit 15cc8c87) is awallin ?
[02:57:44] <linuxcnc-build> build #163 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/163 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[02:58:56] <linuxcnc-build> build forced [ETA 7h26m36s]
[02:58:56] <linuxcnc-build> I'll give a shout when the build finishes
[02:59:21] <linuxcnc-build> build #2019 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2019
[03:02:36] <linuxcnc-build> build #368 of 1402.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-amd64/builds/368
[03:02:37] <linuxcnc-build> build #177 of 1401.rip-wheezy-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/177
[03:02:38] <linuxcnc-build> build #176 of 1400.rip-wheezy-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/176
[03:02:46] <linuxcnc-build> build #206 of 1403.rip-wheezy-armhf is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-armhf/builds/206
[03:02:57] <linuxcnc-build> build #1817 of 1901.clang-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/1817
[03:03:09] <linuxcnc-build> build #1102 of 1303.rip-precise-xenomai-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1303.rip-precise-xenomai-amd64/builds/1102
[03:03:12] <linuxcnc-build> build #1102 of 1305.rip-precise-rtpreempt-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1305.rip-precise-rtpreempt-amd64/builds/1102
[03:03:14] <linuxcnc-build> build #1118 of 1304.rip-precise-rtpreempt-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1304.rip-precise-rtpreempt-i386/builds/1118
[03:03:26] <linuxcnc-build> build #1128 of 1302.rip-precise-xenomai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1302.rip-precise-xenomai-i386/builds/1128
[03:11:31] <linuxcnc-build> build #2020 of 1200.rip-lucid-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2020
[03:15:43] <linuxcnc-build> build #2019 of 1300.rip-precise-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2019
[03:18:14] <linuxcnc-build> build #2021 of 1306.rip-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2021
[03:19:39] <linuxcnc-build> build #1223 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1223
[03:33:07] <linuxcnc-build> build #2024 of 1102.rip-hardy-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/2024
[03:35:59] <linuxcnc-build> build #2027 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/2027
[03:37:28] <linuxcnc-build> build #2022 of 1100.rip-hardy-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/2022
[03:39:10] <linuxcnc-build> build #2021 of 1202.rip-lucid-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2021
[03:39:15] <linuxcnc-build> build #2022 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2022
[03:39:16] <linuxcnc-build> build #2023 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2023
[07:42:23] <skunkworks> The TP run realtime - doesn't it?
[08:06:37] <seb_kuzminsky> skunkworks: yes
[08:08:26] <seb_kuzminsky> cradek: it appears that pushing just a tag to glo does not cause the the buildbot poke script to get run
[08:09:14] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[08:09:15] <linuxcnc-build> build forced [ETA 7h26m36s]
[08:09:15] <linuxcnc-build> I'll give a shout when the build finishes
[08:50:29] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision=v2.6.0-pre1 0000.checkin
[08:50:36] <linuxcnc-build> build #2025 forced
[08:50:36] <linuxcnc-build> I'll give a shout when the build finishes
[08:54:43] <cradek> seb_kuzminsky: step 8 is "Push both the branch and the new tag together" so I don't think I've ever noticed that. does it matter?
[09:22:51] <linuxcnc-build> build #164 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/164
[09:51:20] <cradek> pushing only a new tag means there's nothing new to build
[10:06:35] <linuxcnc-build> build #165 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/165
[10:35:48] <linuxcnc-build> Hey! build 0000.checkin #2025 is complete: Success [3build successful]
[10:35:48] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2025
[10:39:41] <seb_kuzminsky> cradek: yeah, i think you're right
[10:40:02] <seb_kuzminsky> i messed up my push, but i fixed it (and i updated the wiki page to remind me next time)
[10:41:45] <cradek> holy smokes, cmorley closed all the 2.5 bugs
[10:42:16] <seb_kuzminsky> he was on a roll last night
[10:44:56] <cradek> that leaves us with only
http://sourceforge.net/p/emc/bugs/307/
[10:54:54] <cradek> in 2.5 bug 307 is self-healing; it fails to start but still creates a new and valid position.txt file
[10:58:36] <seb_kuzminsky> wow, down to 1 open bug against 2.5? that's great
[10:59:15] <seb_kuzminsky> (though i bet there are open bugs that don't have a milestone set that affect 2.5)
[10:59:26] <cradek> and I just moved it to 2.6
[10:59:52] <seb_kuzminsky> heh
[10:59:57] <cradek> oh there still is one
[11:00:07] <seb_kuzminsky> linuxcnc-build: commands
[11:00:07] <linuxcnc-build> buildbot commands: commands, dance, destroy, force, hello, help, last, list, mute, notify, source, status, stop, unmute, version, watch
[11:01:04] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision=v2.6.0-pre1 0000.checkin
[11:01:10] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[11:01:29] <cradek> whoah
[11:01:43] <cradek> wheel scrolling of program start is in 2.6 touchy? I thought that was lost.
[11:01:51] <cradek> that's great
[11:02:15] <seb_kuzminsky> the git remembers
[11:02:46] <cradek> only if you remember to tell git to remember
[11:48:10] <skunkworks> is 2.6 up? (I mean - could I follow those directions?)
[11:48:33] <cradek> nope
[11:48:38] <skunkworks> ok
[11:49:05] <skunkworks> no rush ;)
[11:49:41] <cradek> I think he's still trying to coerce buildbot into doing the right thing
[11:49:44] <cradek> guessing it's close
[11:52:38] <skunkworks> so - where is the realtime/nonrealtime break? The TP is realtime - what is sent to the tp?
[11:52:56] <skunkworks> I think it is cannon? but what is cannon?
[11:52:59] <memleak> .gitignore .gitremember
[11:53:28] <cradek> the motion controller is a realtime component
[11:53:45] <cradek> it takes commands from userland through a shared memory interface
[11:54:04] <cradek> that interface is the boundary
[11:54:44] <seb_kuzminsky> skunkworks:
http://www.linuxcnc.org/docs/2.5/html/code/Code_Notes.html#_architecture_overview
[11:55:13] <skunkworks> Ah..
[11:55:27] <seb_kuzminsky> 2.6.0-pre1 is in the 2.6 branch, i'm trying to get the buildbot to build the debs correctly, then i'll upload them to the deb archive at w.l.o, then i'll send out the announcement to emc-users and -developers, hopefully tonight some time
[11:58:01] <cradek> I wish I could tell buildbot (at push time) to not bother building this one
[12:02:07] <skunkworks> Thank you'
[12:10:19] <KGB-linuxcnc> 05cradek/254 37bab41 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37bab41
[12:11:17] <cradek> seb_kuzminsky: can I build 2.5.4 now/soon?
[12:11:43] <cradek> I can do it in the morning if it would be in your way
[12:23:07] <linuxcnc-build> build #2026 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2026
[12:23:38] <seb_kuzminsky> i'm working an issue in the buildmaster config with the detection of releases, so i'll have to restart the buildmaster repeatedly until i get it fixed
[12:24:11] <cradek> ok
[12:24:13] <seb_kuzminsky> if you can hold off on pushing stuff until i get it fixed that'd help me (but if you push something anyway, it's not the end of the world)
[12:24:25] <cradek> yell when I can push -- I'm ready anytime
[12:24:30] <seb_kuzminsky> ok
[12:25:52] <seb_kuzminsky> thanks
[12:28:01] <skunkworks> one reboot ah ha ha ha ha...
[12:29:23] <seb_kuzminsky> two... two reboots
[12:29:27] <skunkworks> (sorry - watching too much seseme street...
[12:29:36] <skunkworks> sesame
[12:29:46] <skunkworks> heh
[12:30:37] <cradek> AXIS turns ten this year...
[12:30:46] <skunkworks> wow
[12:32:07] <skunkworks> he has grown up so fast...
[12:32:30] <seb_kuzminsky> Axis is still working well :-)
[12:33:57] <cradek> ten-year-old software is good - not too crusty, but the bugs are worked out long ago
[12:34:25] <cradek> although probably 5 is better than 10
[12:44:46] <asah> anyone know andy pughs handle?
[12:44:57] <cradek> haha, it's andypugh
[12:45:00] <asah> =)
[12:45:19] <cradek> he's one of us bold ones who use our names
[12:45:20] <asah> and he is therefor, not here. ...
[12:45:43] <asah> =(
[12:49:52] <seb_kuzminsky> asah: i bet if you email the emc-developers list, he'll reply
[12:50:10] <asah> yeah, yeah… thats so not immediate. =) I am impatient.
[12:50:23] <asah> (reading bldc comp now…)
[12:50:44] <skunkworks> ask your question
[12:51:19] <asah> I am looking to get BLDC going with an absolute encoder.
[12:52:04] <asah> I am looking at a barebones config, no PID no nothing. I just want to spin the motor using the feedback commutation of the absolute encoder
[12:52:21] <asah> I can spin the motor fine in n mode (Dump VFD mode)
[12:52:54] <asah> now I have zeroed the motor to the absolute encoder and am having issues getting it to commutate.
[12:53:35] <asah> my zeroing method was to apply some current accross two of the phases, then do a reset on the encoder (in hardware on the encoder, this survives power cycles)
[12:54:13] <asah> setting bldc.1.value does not spin the thing around and around as I would expect.
[12:54:56] <asah> In absolute mode value should still be relative no?
[12:55:15] <asah> like a value of 10 would be a velocity input, not an absolute input.
[12:55:21] <asah> no?
[13:00:58] <linuxcnc-build> build #166 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/166
[13:02:58] <seb_kuzminsky> ok, this time for sure
[13:02:58] <seb_kuzminsky> maybe
[13:04:15] <seb_kuzminsky> yep
[13:04:32] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision-v2.6.0-pre1 0000.checkin
[13:04:32] <linuxcnc-build> Something bad happened (see logs)
[13:04:38] <seb_kuzminsky> aww
[13:04:45] <seb_kuzminsky> oh
[13:04:51] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 --revision=v2.6.0-pre1 0000.checkin
[13:04:52] <linuxcnc-build> build #2027 forced
[13:04:52] <linuxcnc-build> I'll give a shout when the build finishes
[13:05:14] <seb_kuzminsky> cradek: ok, i think the buildbot is unhorked, push when you're ready
[13:05:26] <seb_kuzminsky> let's coordinate on copying the debs to w.l.o
[13:34:53] <linuxcnc-build> build #167 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/167
[13:37:15] <skunkworks> wlo?
[13:46:44] <archivist> world linux organisation?
[13:48:54] <skunkworks> heh
[14:02:46] <asah> so the problem now with my bldc commutation seems to be that I can really only electrically commutate from one electrical pole to another.
[14:03:26] <asah> ie with a 6 pole motor, I get only really .16 of a phase swing if I push a triangle wave into the value of the bldc comp.
[14:03:53] <asah> I cannot jump into the next “valley” of phase.
[14:03:59] <asah> or pole.
[14:04:58] <asah> if I disconnect one of the phases from the motor I get what I would expect, motor spins up to speed (many turns) then slows down, reverses, etc back and forth.
[14:06:28] <asah> seems that the electrical angle is off, but having a hard time pinning it down.
[14:07:16] <pcw_home> the bldc phase angle needa to go from 0 to 1 for one electrical rotation
[14:07:21] <pcw_home> needs
[14:10:05] <asah> right, so I have encoder.rawcounts hooked in to bldc.1.rawcounts and scale set to the number of counts per revolution.
[14:10:35] <pcw_home> and bldc.n.poles = 6
[14:11:22] <asah> yes
[14:11:28] <pcw_home> (6 poles means 3 detent positions if you apply a small DC current to the motor windings)
[14:11:50] <asah> yes
[14:12:15] <asah> so I put current between two windings as we discussed, then zeroed out the encoder
[14:12:19] <asah> (in hardware)
[14:12:35] <linuxcnc-build> Hey! build 0000.checkin #2027 is complete: Success [3build successful]
[14:12:35] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2027
[14:12:48] <pcw_home> so if thats all correct, encoder direction is a possibility
[14:13:42] <pcw_home> fix with negative bldc.n.scale (I think)
[14:19:19] <linuxcnc-build> build #168 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/168
[14:19:37] <seb_kuzminsky> skunkworks_: wlo = www.linuxcnc.org
[14:19:47] <seb_kuzminsky> we also say glo for git.linuxcnc.org sometimes
[14:20:14] <asah> bldc.n.scale negative gave me better results. totally different results from bldc.n.rev which is lame IMHO
[14:20:17] <asah> =)
[14:20:42] <skunkworks> seb_kuzminsky, ah. makes sense
[14:21:05] <asah> but in this absolute case bldc.1.value is a velocity input correct? if I am setup with absolute encoders?
[14:21:55] <pcw_home> bldc1.value is a voltage value for bare HBridges
[14:22:05] <pcw_home> so ~= velocity
[14:22:28] <asah> right.
[14:23:02] <asah> ok. so then why is it only spinning in one direction now even though value is pos and neg.
[14:25:09] <pcw_home> so the offset setting is not correct somehow
[14:25:16] <asah> its at zero
[14:26:09] <pcw_home> I mean the encoder/rotor alignment is not as expected
[14:26:24] <asah> ah. ok.
[14:26:29] <asah> ill play with that some.
[14:26:53] <asah> prob off by half a phase or something? play with lead-angle?
[14:26:56] <pcw_home> it should spin at the same speed in both directions with equal +- voltages if that is correct
[14:27:13] <pcw_home> possibly 90 degrees off
[14:27:34] <asah> yes it was.
[14:28:04] <pcw_home> well possibly anything...
[14:28:38] <asah> meaning, now it works. =)
[14:28:44] <asah> I was at 180, 90 is correct
[14:28:46] <asah> yay!
[14:28:50] <asah> thanks peter
[14:29:09] <pcw_home> well that was "easy" :-)
[14:29:31] <asah> yeah. I was making the dumb assumption that bldc.1.rev actually reversed it
[14:29:41] <asah> user error always.
[14:29:53] <pcw_home> I'm not even sure what that is
[14:31:10] <asah> pcw_home it looks like the SSI stuff is not doing any velocity calculations
[14:31:51] <pcw_home> # ofpoles, encoder scaling, motor UVW vs encoder direction and offset all have to be right... lots or error space
[14:32:58] <asah> yes indeed.
[14:33:15] <pcw_home> Im not sure if the absolute encoders have velocity pins or not
[14:33:15] <asah> and little old me wandering around in all those dimensions.
[14:33:53] <asah> they don’t. I had to hack the driver code to get stable absolute out. hacking it now to add velocity calcs in, but its rather involved (stealing from encoder.c)
[14:34:11] <pcw_home> Um not needed
[14:34:25] <pcw_home> DDT of position is velocity
[14:34:33] <pcw_home> (PID does this)
[14:35:25] <pcw_home> I mean PID does this for the D term for example
[14:35:33] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch 88ba3df 06linuxcnc 10debian/changelog Changelog for 2.5.4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=88ba3df
[14:35:33] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch eba1f42 06linuxcnc 10VERSION Release 2.5.4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eba1f42
[14:35:34] <KGB-linuxcnc> 03Chris Radek 05signed tags a67fa33 06linuxcnc 03v2.5.4 LinuxCNC v2.5.4 (tagged commit: eba1f42) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a67fa33
[14:37:20] <skunkworks> yay!
[14:37:37] <pcw_home> for quadrature encoders where you get instant position updates you can timestamp the velocity estimation makes sense
[14:37:39] <pcw_home> but for absolute encoders that are periodically sampled you can do no better than D/DT of position
[14:38:22] <asah> but isn’t the point of the vel calcs in the driver that they happen at high rate in the fpga, not in the driver?
[14:39:13] * seb_kuzminsky crosses fingers & looks sideways at the buildbot
[14:39:26] <cradek> haha
[14:40:48] <pcw_home> the quadrature encoder time stamp is high speed (= better time resolution)
[14:40:49] <pcw_home> but timestamping the absolute data is not helpful
[14:41:16] <pcw_home> because there are no updates between servo thread periods
[14:43:06] <asah> ah. right. ok. Well, another good reason for softdmc ? =) (ducks)
[14:45:48] <pcw_home> well basically its a good reason for absolute encoders to have all the resolution possible
[14:47:20] <seb_kuzminsky> wow, there's some good stuff in 2.5.4
[14:52:11] <cradek> yes definitely
[14:52:49] <cradek> holy smokes it's been a year
[14:53:07] <seb_kuzminsky> heh
[14:53:31] <seb_kuzminsky> at some point soon we should as a group talk about plans & hopes for 2.7
[14:53:43] <seb_kuzminsky> one of my hopes is that 2.7 will be released in 2014
[14:54:09] <cradek> I have three weeks of vacation to use before july... we should have a hackfest.
[14:54:19] <seb_kuzminsky> ooohh yeah
[14:54:37] <cradek> we could build my delta engraver and get master+ja4 running it
[14:54:44] <cradek> that would make me very pleased
[14:55:02] <seb_kuzminsky> i want to run ja on the robot arm my hackspace bought
[14:55:57] <pcw_home> It would be great to get the bugs shaken out of JAx
[14:56:07] <seb_kuzminsky> yes definitely
[14:56:18] <cradek> yes we all seem to really want that
[14:56:48] <seb_kuzminsky> i really want to add more automated tests to master to verify all the important functionality that ja monkeys with, and see what breaks
[14:57:40] <cradek> that sounds extremely hard
[14:58:06] <seb_kuzminsky> some of it's easy low-hanging fruit - things like the jogwheel
[14:58:17] <seb_kuzminsky> some of it's hard - nml messages across module interfaces :-(
[15:01:34] <cradek> I don't think any of it's low fruit. all the jogwheel pin names changed. a test can't work both pre- and post-merge.
[15:01:50] <cradek> and yeah surely the nml messages changed
[15:03:32] <cradek> I bet I would make 100x the progress trying to run a machine with it than I would trying to massage tests
[15:03:41] <cradek> but it's possible not everyone is just like me
[15:03:58] <pcw_home> wasn't an include option added to hal file processing?
[15:04:26] <seb_kuzminsky> pcw_home: in 2.6, not 2.5
[15:04:30] <cradek> yes in 2.6
[15:04:44] <pcw_home> OK
[15:05:14] <pcw_home> would that make testing easier
[15:06:18] <cradek> #include docs in ini_config.txt
[15:07:10] <seb_kuzminsky> dgarr did that, it's a nice feature that i've wanted for a long time
[15:08:12] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=716ab02be7
[15:08:45] <pcw_home> Thats very nice
[15:08:47] <pcw_home> I think it would be nice a macro pre-processor for hal files so you could do site
[15:08:48] <pcw_home> specific/generic name mapping so the connection structure can be separated
[15:08:50] <pcw_home> entirely from the names
[15:09:50] <cradek> unfortunately long ago we made the classic mistake of inventing our own scripting language (halcmd) instead of using an existing language
[15:10:05] <cradek> this is a mistake lots of people make
[15:10:55] <seb_kuzminsky> i've often wanted hal configuration done by a python script instead of a halcmd script
[15:11:04] <pcw_home> Yeah
[15:11:43] <seb_kuzminsky> you can do it that way, it's just not very convenient (or documented)
[15:11:44] <pcw_home> The ini file substitutions are partway there...
[15:11:51] <seb_kuzminsky> yeah
[15:12:21] <pcw_home> but no help for signals
[15:13:20] <seb_kuzminsky> and no conditionals
[15:13:28] <cradek> bleh
[15:13:43] <cradek> and no math
[15:14:04] <seb_kuzminsky> i'd love it if you could say 'try to load this component, and if that worked, hook it up to these nets'
[15:14:27] <pcw_home> Yes the no math is painful sometimes
[15:15:07] <cradek> it's all the same problem (we didn't use a programming language)
[15:16:37] <cradek> pre-ken I used to sometimes preprocess gcode with m4
[15:17:40] <seb_kuzminsky> would that make your grey beard tingle?
[15:18:16] <cradek> I was less grey then
[15:21:24] <pcw_home> Hmm less than ~5% non-white beard hairs
[15:21:35] <seb_kuzminsky> heh
[15:21:53] <pcw_home> be counting them pretty soon
[15:21:55] <cradek> I'm probably around 50%
[15:22:23] <cradek> each grey one represents a linuxcnc mailing list flamewar
[15:22:34] <pcw_home> :-)
[15:23:07] <seb_kuzminsky> haha
[15:25:40] <memleak> this is interesting.. i removed all the proc code in linuxcnc and it still loaded RTAPI and all just fine from the looks of it..
[15:25:47] <memleak> kernel 3.10^
[15:26:07] <cradek> heh that's one approach
[15:26:41] <seb_kuzminsky> memleak: do you know about our runtests script?
[15:26:57] <memleak> no i do not
[15:27:13] <memleak> ill check it in a little bit
[15:35:10] <memleak> oh thats cool!
[15:39:40] <cradek> seb_kuzminsky: is-release: yes
[15:48:07] <seb_kuzminsky> and i bet it'll even do the optional 'upload to the release deb archive' steps too
[15:48:20] <seb_kuzminsky> that's the part that was broken last night, that i fixed today for 2.6.0-pre1
[15:48:23] <memleak> seb_kuzminsky, where is the additional details of runtests, if i want to see why a specific test faield?
[15:48:45] <memleak> loadrt failed and that scares me, so do the crazy numbers in latency-test
[15:48:45] <seb_kuzminsky> memleak: you have to cd to the test's directory and look through the rubble there
[15:48:52] <memleak> ok
[15:49:36] <seb_kuzminsky> cradek: yeah, it's doing it correctly now
[15:52:40] <memleak> segfaults within linuxcnc showing up in dmesg
[15:52:48] <memleak> would addresses help?
[15:53:11] <memleak> RTAI itself works wonderfully because im getting great numbers in the testsuite
[15:56:56] <cradek> addresses won't help because they are specific to your build
[15:57:30] <cradek> but by all means, share the whole dmesg
[15:57:58] <memleak> ok, one moment
[15:59:15] <linuxcnc-build> build #169 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/169 blamelist: Chris Radek <chris@timeguy.com>
[16:41:45] <memleak> RTAPI cannot open shared memory, why not?..
[17:33:50] <memleak> also dmesg shows nothing except the segfaults, and thats even with kernel debugging cranked up to the max, even pci debug and such
[17:47:33] <cradek> sounds like you lost the udev rules that set the permissions correctly
[18:09:57] <memleak> cradek, the 99-rtai rules?
[18:10:57] <memleak> or linuxcnc's... udev rules?
[18:16:00] cradek changed topic of
#linuxcnc-devel to: LinuxCNC development --
http://linuxcnc.org/ | Latest release: 2.5.4
[18:35:29] <seb_kuzminsky> !!!
[18:53:16] <andypugh> I am confused by JA4 and gentrivkins. I suggested it as a possible solution to someone on the forum, but it ends up in “free” mode some of the time, despite being an identity kins.
[21:07:09] <memleak> jeeze my github repo i made two days ago is getting slammed with attacks..
[21:07:28] <memleak> both created by people with no prior coding history
[21:12:38] <memleak> https://github.com/NTULINUX/RTAI/issues?page=1&state=closed
[21:12:48] <memleak> who does this crap? honestly.
[21:17:59] <skunkworks_> logger[psha]:
[21:17:59] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-04-18.html
[21:21:09] <memleak> oh you can actually delete the issues section, heh
[21:26:22] <memleak> i mean, it wasn't anyone here was it? are some of you unhappy with the RTAI code?
[21:26:56] <memleak> it is a recent fork and it's not ready yet for production.
[22:02:46] <skunkworks_> heh - I doubt it :)
[22:07:45] <memleak> i guess its just odd because i just opened it. stalkers perhaps.
[22:56:17] <asah> PCW: what is the good latest realtime kernel / branch we should be using? I want to use the ethernet mesa drivers. ubc something?
[23:02:36] <asah> ah ubc-7i80
[23:56:15] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 47ead17 06linuxcnc Merge branch 'hotfix/tort-vel-violation' into circular-blend-arc-rc3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=47ead17