Back
[00:00:39] <seb_kuzminsky> each subsequent point in the timeseries from motion should not violate axis position/vel/acc limits
[00:00:42] <rob_ellenberg> Could we spit out a current id # in the recorded data? then do a direct lookup to the appropriate segment
[00:00:51] <seb_kuzminsky> and should stay within G64P of the first programmed move
[00:01:08] <rob_ellenberg> point X is during segment N, so find distance to segment N and N+1
[00:01:16] <seb_kuzminsky> until you come within G64P of the endpoint of the current move, at which point you switch to the next move in the input
[00:01:52] <rob_ellenberg> I think it would be easier to always check against N and N+1, and take the min of the two
[00:02:05] <rob_ellenberg> less susceptible to odd blend conditions
[00:02:32] <seb_kuzminsky> consider a move from (0,0,0) to (1,1,1), followed by a move back to (0,0,0)
[00:03:07] <seb_kuzminsky> not sure that's a useful path for a cnc machine, but it's something we should be able to test
[00:03:31] <seb_kuzminsky> that'd get confused by the min(distance-to-N, distance-to-N+1) test, wouldn't it
[00:04:12] <rob_ellenberg> It would
[00:04:25] <rob_ellenberg> We may need a clearer definition of how the tolerance is spec'd
[00:04:50] <rob_ellenberg> it's not just perpendicular distance from ideal to actual
[00:05:10] <rob_ellenberg> maybe we need a separate endpoint check
[00:05:29] <rob_ellenberg> like, the endpoints of every path segment need to be within G64P of the actual path
[00:05:46] <seb_kuzminsky> that's what the G64 docs say
[00:05:53] <seb_kuzminsky> http://linuxcnc.org/docs/devel/html/gcode/gcode.html#sec:G64
[00:06:42] <seb_kuzminsky> the actual tool path needs to come within P of the programmed end point
[00:08:00] <seb_kuzminsky> i wonder if that means "the actual tool path needs to stay within P of the programmed path"?
[00:08:06] <rob_ellenberg> Ok, I think I'm following
[00:09:00] <rob_ellenberg> During a parabolic blend at least, you could explicitly do a point-to-point distance check at the start and end of each segment
[00:09:30] <rob_ellenberg> with circular arc blending, though, it's harder to define that crossover point
[00:09:55] <seb_kuzminsky> is that arc-to-arc blending?
[00:10:30] <rob_ellenberg> not just that, any pair of segments blended with a spherical arc (the new way), rather than a parabolic blend
[00:10:35] <rob_ellenberg> could be line-line
[00:10:47] <seb_kuzminsky> ah, i get it
[00:11:11] <seb_kuzminsky> can't that be checked the same way?
[00:11:39] <seb_kuzminsky> make sure the motion output comes within P of the end of the first segment, then switch to making sure you're within P of the next segment?
[00:12:18] <seb_kuzminsky> and walk down the lists of motion-output and motion-input, making sure things stay copacetic?
[00:12:30] <rob_ellenberg> That makes sense
[00:12:43] <rob_ellenberg> For each new path point, you'd have 2 checks:
[00:12:59] <rob_ellenberg> 1) distance to segment (to catch gross motion errors)
[00:13:06] <rob_ellenberg> 2) distance to end point
[00:13:35] <rob_ellenberg> if we don't hit the minimum distance in (2) before the blend is done, then the test fails
[00:13:57] <seb_kuzminsky> yeah, 1 verifies the path is sane, 2 tells you to move your pointer into the input list to the next segment (aka emcmot command)
[00:14:07] <seb_kuzminsky> there's three more checks, i think:
[00:14:21] <seb_kuzminsky> 3) the motion-output point is within axis position limits
[00:14:33] <seb_kuzminsky> 4) the derivative of the motion-output does not violate axis vel limits
[00:14:47] <seb_kuzminsky> 5) the second derivative of the motion-output does not violate axis accel limits
[00:15:00] <seb_kuzminsky> (those are all quick &easy to check)
[00:15:25] <rob_ellenberg> And that would catch bad errors like discontinuities or a sudden NaN
[00:15:30] <rob_ellenberg> I like it
[00:15:33] <seb_kuzminsky> :-)
[00:16:45] <seb_kuzminsky> i'll write the sam input/output stuff, do you want to write the checkresults script that verifies all those things, given motion-input & motion-output files?
[00:17:06] <seb_kuzminsky> then we can all start throwing motion-input files at it
[00:17:32] <rob_ellenberg> Sounds good! If we have a known format for the motion input, then it should be easy enough
[00:17:42] <rob_ellenberg> Do you mind if I use something like octave?
[00:17:56] <rob_ellenberg> makes some of the math easier
[00:18:02] <seb_kuzminsky> yeah, i dont have the input format yet but it should solidify quickly when i start writing it
[00:18:17] <seb_kuzminsky> err, i know nothing about octave
[00:18:29] <rob_ellenberg> Are you familiar with MATLAB?
[00:18:34] <seb_kuzminsky> a little bit
[00:18:51] <rob_ellenberg> basically a scripting language to handle linear algebra and similar stuff
[00:18:58] <seb_kuzminsky> if you want to use something that's available as a debian package and can run from a script without guis & stuff, that's probably fine
[00:19:08] <rob_ellenberg> octave is an open source port of it
[00:19:13] <rob_ellenberg> and yeah, it can run without a GUI
[00:19:20] <rob_ellenberg> very similar to python that way
[00:19:32] <rob_ellenberg> run a script and dump some output
[00:19:58] <seb_kuzminsky> i'd imagined doing the checkresults script in python, but only because that's what i'm most familiar & comfortable with
[00:20:17] <seb_kuzminsky> there are numerical computation libraries for python, do you know anything about them? (i don't)
[00:20:30] <rob_ellenberg> yeah, pylab / scipy has a bunch of useful stuff
[00:20:39] <rob_ellenberg> It may end up being easier to just do it in python
[00:21:01] <rob_ellenberg> it's just easier for me to mess around in octave because I spent so many years with MATLAB back in school
[00:21:06] <seb_kuzminsky> i bet more linuxcnc devs are familiar with python vs octave
[00:21:45] <rob_ellenberg> gotcha, I'll do python unless I hit a wall there
[00:22:04] <seb_kuzminsky> thanks, i think that will lower the barrier-to-entry for the rest of us
[00:22:42] <seb_kuzminsky> it seems like pretty straight-forward math in all 5 of those checks, so hopefully python will be up to the task without too much work
[00:23:07] <rob_ellenberg> yeah, a bit of numpy goes a long way
[00:23:14] <rob_ellenberg> there may even be libraries to do that stuff already
[00:23:44] <seb_kuzminsky> i bet there are
[00:23:53] <rob_ellenberg> Do you have a timeline in mind? I think I can have a first cut done in a week or two
[00:24:01] <seb_kuzminsky> heh
[00:24:20] <seb_kuzminsky> i really need to stop doing fun useful things like this and focus on getting the 2.7.0~pre3 pre-release out
[00:24:49] <seb_kuzminsky> i got your spiral-arc branch, thanks for that, that was the second-to-last feature i was waiting for for the release
[00:25:16] <rob_ellenberg> Sweet! What else is in the pipe?
[00:25:31] <seb_kuzminsky> i need to adapt dgarr & arceye's "arc radius tolerance in ini file" adapted to work with your new radius tolerance handling
[00:25:41] <seb_kuzminsky> that's nearly done, another day or two probably
[00:25:53] <seb_kuzminsky> then a few days to get my act together for the release
[00:26:15] <seb_kuzminsky> then i'll try to get that seb/2.7/sam branch mergeable before the next 2.7.0~pre release
[00:26:41] <seb_kuzminsky> it's at that awkward 80% stage currently
[00:26:53] <rob_ellenberg> I'm impressed that you can get all these releases out and still find time to work on this other stuff :)
[00:27:11] <seb_kuzminsky> so maybe in 1 week i'll start working on it, and maybe 2-3 weeks to get it ready for review
[00:27:44] <seb_kuzminsky> i'm really glad to have your help with it :-)
[00:28:33] <seb_kuzminsky> tests of Motion have been lacking from this project since i started in 2007, this will be a huge improvement
[00:29:02] <rob_ellenberg> Definitely, it will really speed up development of the next generation of stuff (limited jerk, spline blends)
[00:29:12] <rob_ellenberg> whatever else
[00:30:00] <skunkworks> I feel like I am out of a job.. ;)
[00:30:12] <skunkworks> Yay!?
[00:30:33] <rob_ellenberg> or, it means you get to test for more interesting errors
[00:30:39] <skunkworks> heh
[00:30:57] <rob_ellenberg> also, who tests the tester?
[00:31:01] <seb_kuzminsky> skunkworks: this thing we're talking about is pretty different from the testing that you've been doing
[00:31:21] <seb_kuzminsky> this will test short sequences of emcmot commands, not big g-code programs
[00:31:40] <seb_kuzminsky> isolation testing of individual blend situations, for examples
[00:32:17] <skunkworks> seb_kuzminsky: are you hoping to get the testing in befor the 2.7 release?
[00:32:36] <seb_kuzminsky> good question
[00:32:55] <seb_kuzminsky> i think it'd be great if we could have the framework in place so that the tests can be written, before the 2.7.0 release
[00:33:17] <seb_kuzminsky> then add tests & fix any bugs they identify in the early 2.7.x days
[00:33:45] <seb_kuzminsky> as i tried to show in that seb/2.7/sam branch, it's not really very invasive to the existing linuxcnc Motion component
[00:34:30] <seb_kuzminsky> i think it's just that first commit that's at all sketchy
[00:34:40] <seb_kuzminsky> and even that one is not that bad imo
[00:34:51] <seb_kuzminsky> (i'd sure like feedback on it)
[00:36:53] <skunkworks> rob was also looking at the JAx branch - maybe that could get merged to master soonish. I need to get back to documenting the issues we had
[00:37:12] <seb_kuzminsky> yeah, that's been on my mind too
[00:37:34] <seb_kuzminsky> i'll have more brain cycles to think about it after 2.7 is out the door
[00:38:00] <seb_kuzminsky> and i'll have more confidence in it after we have some motion tests that tell us if jax breaks anything :-)
[00:39:17] <rob_ellenberg> very true
[00:39:41] <rob_ellenberg> Ok, I think I have my mission for the next week or two
[00:40:03] <rob_ellenberg> Glad we could meet up!
[00:40:42] <rob_ellenberg> I should head to bed soon though (getting late on the east coast :) )
[00:40:53] <kwallace2> Thanks for your work guys.
[00:40:57] <seb_kuzminsky> ok!
[00:41:11] <seb_kuzminsky> it was great to chat, feels like we're on the same page & a clear road ahead
[00:41:29] <seb_kuzminsky> i hope to see you on here more in the future :-)
[00:41:31] <seb_kuzminsky> good night
[00:41:42] <skunkworks> awesome. night everyone.
[00:41:45] <rob_ellenberg> good night, I'll be in touch
[09:35:01] <seb_kuzminsky> i just got email from francis tisserant, the french translations guy, he wants to collaborate on po4a for future translations
[09:35:13] <seb_kuzminsky> yay :-)
[09:36:43] <cradek> that would be great
[09:36:57] <cradek> and I'm excited about the conversation last night about testing
[09:37:20] <cradek> thanks for having it here instead of in a google thingy that we can't all see
[09:43:17] <seb_kuzminsky> yeah that worked out well
[09:44:04] <seb_kuzminsky> cradek: if you have time for it, i'd appreciate another pair of eyeballs on the seb/2.7/sam branch
[09:44:29] <cradek> ok, I'll try to do it tonight
[09:54:43] <seb_kuzminsky> thx
[10:48:28] <pcw_home> nice simple FIR filter tool:
[10:48:29] <pcw_home> http://www.arc.id.au/FilterDesign.html
[10:52:23] <mozmck> seb_kuzminsky: is there a chance to get my shiny LED and Bar patch in 2.7? Does someone need to look at what I did or can I commit the changes?
[10:53:38] <seb_kuzminsky> mozmck: it's very welcome into 2.7
[10:53:57] <seb_kuzminsky> i looked at it a few weeks(?) ago and it looked fine to me then (not that i know what i'm looking at really)
[10:54:19] <seb_kuzminsky> this one adds new shiny widgets, and leaves the old dull ones alone, right?
[10:54:51] <mozmck> yes, the default is the old style, and there are options to enable the shiny look in glade.
[10:55:43] <mozmck> Same widgets, they just get drawn differently if the "shiny" option is set.
[10:56:51] <seb_kuzminsky> perfect
[10:57:23] <seb_kuzminsky> can you push it or do you want to get it into our git repo some other way? (email or pull requests work too)
[10:57:41] <mozmck> I can merge my local branch back to my local 2.7 and push if that's alright with you.
[10:58:11] <seb_kuzminsky> is your local branch based on 2.7 currently?
[10:58:21] <mozmck> yes, just rebased to the latest
[10:58:26] <seb_kuzminsky> ah, perfect
[10:58:33] <seb_kuzminsky> yeah, then i say go for it!
[10:58:49] <mozmck> ok, hope I don't mess something up!
[11:01:04] <seb_kuzminsky> feel free to ask questions if you're uncertain
[11:01:36] <mozmck> thanks. I use git mostly for my own stuff, so I don't merge and rebase much :) I think I've got it though.
[11:03:25] <KGB-linuxcnc> 03Moses McKnight 052.7 34f130b 06linuxcnc 10lib/python/gladevcp/hal_bar.py 10lib/python/gladevcp/led.py Made gladevcp widgets hal_bar and led fancier. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=34f130b
[11:03:39] <cradek> rockin
[11:03:44] <mozmck> KGB is fast!
[11:07:33] <cradek> your commit looks great - nice and clean
[11:07:38] <mozmck> thanks
[11:09:05] <mozmck> how does stuff get merged to master? should I do that?
[11:09:37] <cradek> sure, you can do it if you want, otherwise someone else will do it later and your change will be included in their merge
[11:10:23] <mozmck> ok
[11:11:11] <cradek> if your change will be conflicty for some reason, it's nice if you deal with it yourself right away (but I bet this change isn't). Otherwise, you only have to do it if you want master to have it right away.
[11:11:49] <mozmck> I see. I'll do a merge and see. I doubt there will conflicts with this.
[11:12:40] <cradek> hm, actually there are other conflicty changes
[11:13:06] <mozmck> hmm, two conflicts, scripts/linuxcnc.in, configs/sim/axis/ini_hal_demo.ini
[11:18:03] <cradek> the linuxcnc.in conflict might take a little more analysis than I can handle right this second
[11:19:41] <mozmck> I don't know enough to fix either one right now.
[11:33:10] <mozmck> are debs still built using: "fakeroot debian rules binary" ?
[11:33:35] <cradek> I use debuild -uc -us
[11:33:47] <cradek> I bet there are several equivalent ways :-/
[11:34:36] <mozmck> hmm, ok - never used debuild
[11:34:51] <mozmck> wonder how seb_kuzminsky has the buildbot set up to build them?
[11:35:17] <cradek> I bet you could find it in the logs of a builder
[11:35:28] <cradek> it's pretty good at showing the command lines it runs
[11:36:09] <mozmck> where would those be?
[11:37:40] <dgarr> i didn't know i had created a merge conflict with linuxcnc.in and ini_hal_demo.ini -- i will fix and merge later today
[11:38:29] <cradek> dgarr: awesome, thanks
[11:39:37] <cradek> mozmck: it's kind of hard to find stuff on the buildbot pages. if you click Builders at the top, then click the builder you want (like deb-wheezy-rtai-i386) then the latest build number
[11:39:52] <cradek> then you can see the "stdio" link for the "build deb" step
[11:40:02] <cradek> but there's lots of pbuilder goop in there
[11:40:41] <cradek> looks like it does use 'fakeroot debian/rules binary'
[11:41:00] <mozmck> is that from the waterfall page?
[11:41:03] <cradek> or maybe it's debian/rules build
[11:41:53] <cradek> yeah waterfall has the main links at the top like most of them - I clicked Builders at the top
[11:46:08] <seb_kuzminsky> yay, thanks mozmck!
[11:46:34] <mozmck> you're welcome!
[12:04:01] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/state-tags-2.7-signed b09f730 06linuxcnc 10(6 files in 3 dirs) Revert "statetag: optimize tag size using int16's" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b09f730
[12:04:01] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/state-tags-2.7-signed 8446732 06linuxcnc 10(8 files in 3 dirs) statetag: fixes to prevent potential errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8446732
[12:32:53] <linuxcnc-build> build #1129 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1129 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[12:47:56] <mozmck> is inkscape really a build dependency?
[12:50:27] <mozmck> another question - is pbuilder better or preferrable to setting up a VM?
[12:50:56] <seb_kuzminsky> mozmck: yeah, inkscape proves a program that processes some of the images in our docs
[12:51:26] <mozmck> I see - for the docs
[12:51:42] <seb_kuzminsky> pbuilder is mostly useful for proving package build dependency lists, and doing package builds without contamination from the install on the machine doing the build
[12:52:40] <seb_kuzminsky> mozmck: see commit ab7be5d92c5f61
[12:54:25] <linuxcnc-build> build #2942 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2942 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[12:55:56] <mozmck> seb_kuzminsky: it would seem that you could do that with a VM as well, but also build for a different arch easily.
[12:56:11] <mozmck> How do I search for that commit?
[12:56:22] <linuxcnc-build> build #2941 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2941 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[12:56:25] <seb_kuzminsky> git show <sha>
[12:56:45] <seb_kuzminsky> it's true you could do something similar with a VM
[12:57:00] <linuxcnc-build> build #2943 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2943 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[12:57:14] <seb_kuzminsky> but pbuilder is specifically designed to handle those build issues, and does a good job
[12:57:50] <seb_kuzminsky> it sets up a minimal install of your target distro/arch (which may both be different from the distro/arch of your host) in a chroot, then saves the chroot
[12:58:20] <seb_kuzminsky> when you ask pbuilder to build a source package, it unpacks the saved chroot, tries to satisfy the build dependencies, and builds
[12:58:46] <seb_kuzminsky> when it's done, it *throws away* the chroot, so any changes the build process made (such as installing build dependencies) aren't persistent
[12:58:58] <seb_kuzminsky> next time you build a source packge with that pbuilder, you start clean again
[12:59:11] <seb_kuzminsky> a vm doesn't have that behavior unless you implement it yourself somehow
[13:01:15] <seb_kuzminsky> those test failures look like real issues (discrepancies between the state-tags-2.7-signed branch and the test suite)
[13:03:32] <linuxcnc-build> build #2143 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2143 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:04:38] <linuxcnc-build> build #1099 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1099 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:07:10] <linuxcnc-build> build #1099 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1099 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:07:21] <linuxcnc-build> build #1290 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1290 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:07:33] <KGB-linuxcnc> 03Dewey Garrett 05master d937bc9 06linuxcnc 10configs/sim/axis/ini_hal_demo.ini 10scripts/linuxcnc.in Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d937bc9
[13:09:36] <seb_kuzminsky> yay
[13:09:37] <linuxcnc-build> build #610 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/610 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:14:11] <mozmck> heh, I always read "build blah blah is a complete failure"
[13:14:36] <mozmck> thanks for the info on pbuilder seb
[13:14:50] <linuxcnc-build> build #757 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/757 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:19:03] <linuxcnc-build> build #2942 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2942 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:22:28] <linuxcnc-build> build #2942 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2942 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:22:29] <linuxcnc-build> build #2952 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2952 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[13:59:49] <linuxcnc-build> build #2389 of 3002.dsc-precise is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/3002.dsc-precise/builds/2389 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Moses McKnight <moses@texband.net>, Dewey Garrett <dgarrett@panix.com>
[14:01:10] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/state-tags-2.7-signed 49362d0 06linuxcnc 10src/Makefile Fix for header sanity test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49362d0
[14:01:10] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/state-tags-2.7-signed 9372649 06linuxcnc 10src/emc/sai/saicanon.cc Removed test-breaking text output from saicanon on UPDATE_TAG * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9372649
[14:09:38] <linuxcnc-build> build #2953 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2953 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Moses McKnight <moses@texband.net>, Dewey Garrett <dgarrett@panix.com>
[14:34:25] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[14:34:31] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[15:42:26] <linuxcnc-build> build forced [ETA 1h13m22s]
[15:42:26] <linuxcnc-build> I'll give a shout when the build finishes
[16:16:16] <PCW> mozmck: 7i92 ste/dir sample hal/ini file:
[16:16:18] <PCW> freeby.mesanet.com:7i92step.zip
[16:16:28] <PCW> step/dir
[16:20:07] <Tom_L> PCW the 7i92 uses standard bit files doesn't it?
[16:20:32] <Tom_L> nothing special because it's ethernet?
[16:20:34] <PCW> Yes
[16:21:07] <PCW> well top level file is TopEthernet16HostMot2.vhd
[16:21:16] <Tom_L> right
[16:21:31] <Tom_L> just so you get that right the rest is the same
[16:22:47] <PCW> well normal stuff like the correct .ucf file and chip
[16:23:00] <Tom_L> yeah
[16:23:50] <PCW> pin files can be 5i25 type since its also a dual parallel port type pinout
[16:24:38] <Tom_L> is the .ucf the project file?
[16:25:37] <PCW> no, its the Universal? Constraint File
[16:26:30] <PCW> has the pin /ball number to signal name mapping, various and sundry options, timing contraints etc
[16:26:51] <PCW> take a look at one, they are just text files
[16:28:13] <Tom_L> last time i did that i used their graphical interface for pin mapping :)
[16:28:54] <PCW> Be careful, it has a tendency to break hand made ucf files
[16:29:08] <Tom_L> oh i'm not messin with it on these
[17:19:00] <linuxcnc-build> Hey! build 0000.checkin #2955 is complete: Success [3build successful]
[17:19:00] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2955
[18:51:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 e8dbfbf 06linuxcnc 10debian/control.in 10src/configure.in build system: tclx is a runtime dependency, not a build-dep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8dbfbf
[18:54:30] <linuxcnc-build> build #1103 of 1400.rip-wheezy-i386 is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1103 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:54:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 3f8a80a 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f8a80a
[18:57:00] <linuxcnc-build> build #2947 of 1306.rip-precise-amd64 is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2947 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:29:33] <linuxcnc-build> build #2956 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2956 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:08:04] <micges> PCW: I'll default board_ip to 192.168.1.121
[21:47:25] <kwallace> Can the python linuxcnc module be 'linuxcnc.so' in the .../lib/python directory?
[22:07:23] <kwallace> Yep. I had to play with my $PYTHONPATH to point to the proper directory.
[23:03:38] <seb_kuzminsky> oops, the src/configure in 2.6 doesn't have --disable-check-runtime-deps
[23:10:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 cbf72f2 06linuxcnc 10src/configure.in src/configure: remove the check for tclx * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cbf72f2