Back
[00:09:21] <seb_kuzminsky> found a bug in dblatex in wheezy (& maybe others) that's affecting our pdf docs builds
[00:09:47] <seb_kuzminsky> it shells out to inkscape to convert svg to pdf, but it fails to Depend on inkscape
[00:22:24] <seb_kuzminsky> huh, we never included any svg files in our docs before the homing state diagrams in 2.7
[00:22:36] <seb_kuzminsky> that's kind of funny, since we have a ton of .svg files in docs/src
[00:23:07] <seb_kuzminsky> i guess someone always converted them to png by hand and included that instead? and that's why we have a ton of manually-updated duplicates
[00:35:00] <seb_kuzminsky> ugh, 2.6 doesnt merge cleanly into 2.7 because of gmoccapy :-(
[00:35:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 ab7be5d 06linuxcnc 10debian/control.in build-depend on inkscape * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab7be5d
[00:40:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 1403f96 06linuxcnc 10debian/changelog 10scripts/githelper.sh Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1403f96
[00:40:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ec5f64e 06linuxcnc 10VERSION 10debian/changelog LinuxCNC 2.8.0~pre1 pre-release * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ec5f64e
[00:40:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 9e7a014 06linuxcnc 03v2.8.0-pre1 LinuxCNC v2.8.0-pre1 (tagged commit: ec5f64e) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e7a014
[00:42:08] <seb_kuzminsky> that 2.8.0~pre1 release is just to get a release tag into the master branch signed with the correct key
[00:43:55] <seb_kuzminsky> which is 741499B0, owned by "LinuxCNC Release Manager <emc-developers@lists.sourceforge.net>"
[00:44:39] <seb_kuzminsky> with the pubkey also in the git repo, in gnupg/pubring.pgp, so the buildbot (and everyone else, but i bet no one else cares) can check the signatures easier
[00:44:55] <seb_kuzminsky> except for the gmoccapy collision, i'm happy with the state of the 2.6, 2.7, and master branches now
[02:21:24] <archivist> as andy has left his client up
[02:22:20] <archivist> andypugh, I think it needs differentials like a real machine in hal too so the feed can be separated from the angle for helicals
[10:02:21] <KGB-linuxcnc> 03Dewey Garrett 052.6 f318076 06linuxcnc 10lib/python/popupkeyboard.py popupkeyboard.py: support standalone demonstration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f318076
[12:06:20] <PCW> Torque mode servos will typically need a higher servo thread rate than velocity mode servos
[12:06:52] <PCW> (for equivalent dynamic stiffness)
[12:11:55] <PCW> oops wrong window
[12:55:19] <skunkworks> traveling between planets is really easy when you get the worm hole setup correctly. The critical variable is really only the plane. (you don't want to end up on the planet upside down...)
[12:55:29] <skunkworks> oops wrong window..
[13:29:10] <seb_kuzminsky> heh
[13:29:29] <cradek> that's much less embarrassing than some
[13:36:16] <andypugh> Normally I log out when away...
[13:37:46] <andypugh> archivist: I intend to add helix angle at some point. Making pairs of helicals sounds hard, as you need to cut at complementary angles (or you get skew gears instead) and that means _really_ accurate angle setup.
[13:37:59] <andypugh> cradek: Bad news about JA. :-(
[13:38:19] <cradek> which?
[13:38:35] <andypugh> I will try a buld of the current version and if the problem is there I will document it in more detail.
[13:38:50] <cradek> oh the nonconsecutive axis trouble?
[13:39:00] <andypugh> Though, this machine is XYZA and not a lathe.
[13:39:13] <cradek> well that figures
[13:39:34] <andypugh> Hmm?
[13:40:05] <cradek> I think it might work fine on an xyza machine
[13:40:18] <andypugh> My report was that it didn’t..
[13:40:22] <Connor> I never understood why lathes have a Z and not a Y.
[13:40:38] <andypugh> Z is the spindle rotation axis, always.
[13:41:31] <Connor> That's why?
[13:41:50] <cradek> even outside the machining world, Z is along the cylinder:
https://en.wikipedia.org/wiki/Cylindrical_coordinate_system
[13:42:13] <andypugh> cradek: Can you make the spindle not turn on your mill? What I did was G95 F0.01 G1 X100 with the spindle on, but out of gear. What happened was that the X axis moved very slowly (about right) with the spindle stationary, but moved _extremely_ rapidly when I moved the spindle by hand.
[13:42:20] <cradek> x for radius or diameter is the mysterious one
[13:42:58] <andypugh> Should be Z, R (and theta for the compound slide angle :-)
[13:43:36] <cradek> andypugh: sim/lathe has a fully-featured simulated spindle encoder
[13:43:46] <cradek> er it's probably sim/axis/lathe nowadays
[13:45:28] <andypugh> I doubt it is such a good simulation that I can wiggle the spindle by hand though :-)
[13:46:32] <cradek> are you turning it backward to freak it out?
[13:46:54] <andypugh> Interestingly, the feed is in the same direction regardless of rotation direction.
[13:47:08] <cradek> sure, it only ever goes forward
[13:47:19] <cradek> so yes you are turning it in the unexpected direction?
[13:47:33] <cradek> I can see where that would be ... untested
[13:47:37] <andypugh> So there is apparently an implicit “abs” on the spindle velocity input.
[13:48:04] <andypugh> The behaviour is the same in both directions.
[13:48:27] <cradek> did you try 2.6 or master?
[13:48:32] <andypugh> Not yet.
[13:48:40] <andypugh> That’s the plan for tonight.
[13:49:04] <andypugh> No, wait, it isn;t the plan at all. I don’t want to re-convert all my configs away from JA
[13:49:38] <andypugh> I will try a newer JA, if the problem persists I will give up on feed-per rev and make the parts.
[13:50:39] <andypugh> I stopped the spindle in order to do a test to see if the axis moved 0.1mm or 6mm for a single rev of the spindle. But it actually moved about 100mm.
[13:51:10] <Connor> what is JA /
[13:51:11] <Connor> ?
[13:51:27] <andypugh> Joints-Axes branch.
[13:51:34] <cradek> in 2.6, at s100m3, g95f.01g1z1 moves at 1.0 unit/min
[13:52:09] <Connor> andypugh: And What does that mean? What does that give us that we don't currently have ?
[13:52:24] <andypugh> It seems to add lots of interesting bugs :-)
[13:52:30] <seb_kuzminsky> heh
[13:52:36] <Connor> I'm getting that...
[13:52:42] <seb_kuzminsky> it's supposed to add better internal separation between joints and axes
[13:52:49] <andypugh> But mainly it means that joints an axes are completely separate concepts.
[13:53:12] <seb_kuzminsky> they're different kinds of things (at least on non-trivkins machines), but linuxcnc doesn't really graps that concept very well at the moment
[13:53:41] <Connor> Anyone look into that bug with REMAP and stopping a active program ? LinuxCNC executes what ever is left in the queue...
[13:53:45] <Connor> could be very bad.
[13:53:47] <andypugh> So Joint 0 can drive the Z axis if you want. You wouldn’t want to, but things like robots end up very untidy when Joint0 is tangled up in Axis X.
[13:53:57] <seb_kuzminsky> Connor: yeah, that's super sketchy
[13:54:20] <Connor> seb_kuzminsky: Sketchy as in bad bug? or hard to fix ?
[13:54:29] <seb_kuzminsky> both
[13:54:35] <andypugh> Ah, that Gmoccpy-related thing isn’t Gmocapy? That was also a remap config?
[13:54:37] <Connor> Lovely...
[13:54:51] <seb_kuzminsky> andypugh: there were *two* surprise-move bugs recently
[13:55:16] <andypugh> Hey, soon we can really compete with Mach3 :-)
[13:55:17] <Connor> Someone confirmed the supposedly gmocapy isn't the same remap bug ?
[13:55:22] <seb_kuzminsky> one was in gmoccapy and was fixed by norbert
[13:55:52] <seb_kuzminsky> the other is in remap, but only shows up when you have a very long gcode program and abort un the middle of a remapped gcode (i think)
[13:56:33] <Connor> I don't remember if it happen outside of the remap or not.
[13:56:35] <seb_kuzminsky> the bug is #394, after som eprodding the OP produces full repro instructions including the gcode program that he was running
[13:57:29] <Connor> and I confirmed the bug using master running in the simulator.. running both custom remap code and the provided wine rack tool change code
[13:58:03] <Connor> LinuxCNC needs to understand when we say stop.. we mean STOP. :)
[13:58:24] <seb_kuzminsky> Connor: that's good information that it still happens in master, could you add that to the bug tracker please?
[13:58:50] <andypugh> Just to check, can you confirm that this isn’t a _third_ bug?
http://www.linuxcnc.org/index.php/english/forum/41-guis/26314-gmoccapy-a-new-screen-for-linuxcnc?start=920#52342
[13:59:16] <Connor> Yea, I'll update my sim code later tonight and double another check on bug 394
[14:00:04] <andypugh> Sorry, I meant
http://www.linuxcnc.org/index.php/english/forum/41-guis/26314-gmoccapy-a-new-screen-for-linuxcnc?start=920#52363
[14:00:12] <andypugh> (Same guy has more than one problem)
[14:00:23] <seb_kuzminsky> andypugh: wow, a bug report hidden on page... 93 of the gmoccapy announcement thread?
[14:00:34] <seb_kuzminsky> oh, i'll look at the other
[14:01:02] <Connor> andypugh: That sounds like the remap bug. anyone asked him if he's using remap ?
[14:03:13] <seb_kuzminsky> i dont know if message #52363 is the same problem as the recent gmoccapy bug that got fixed recently
[14:03:16] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=60689e3e79d587fa3092189487181c6db42ae9ba
[14:03:28] <Connor> I just asked him if he was using remap
[14:03:58] <seb_kuzminsky> i'm curious if upgrading to v2.6.3-68-g60689e3 or newer fixes the problem
[14:04:25] <seb_kuzminsky> (also: wow, 68 commits since 2.6.3, including a fix for at least one surprise-move bug in gmoccapy, clearly it's time for 2.6.4)
[14:10:37] <Connor> upgrading to 2.7.0~pre0.616.gcd4180d_amd64.deb
[14:10:41] <Connor> will check and see.
[14:12:38] <seb_kuzminsky> Connor: that version is too old
[14:12:49] <seb_kuzminsky> it does not have the recent gmoccapy fix
[14:13:21] <Connor> wait.. let me double check.
[14:13:57] <Connor> Why would that have been the latest version I pulled ?
[14:14:40] <Connor> Get:1
http://buildbot.linuxcnc.org/ precise/master-sim linuxcnc-sim-dev amd64 1:2.7.0~pre0.616.gcd4180d [611 kB]
[14:14:40] <Connor> Get:2
http://buildbot.linuxcnc.org/ precise/master-sim linuxcnc-sim amd64 1:2.7.0~pre0.616.gcd4180d [5,039 kB]
[14:15:16] <seb_kuzminsky> hmm, good question!
[14:15:49] <seb_kuzminsky> maybe you forgot to run 'sudo apt-get update'?
[14:16:50] <Connor> did that.. and re ran sudo apt-get install linuxcnc-sim
[14:16:56] <Connor> linuxcnc-sim is already the newest version.
[14:17:21] <seb_kuzminsky> hm, or maybe it's because in master we're in the middle of a transition away from "linuxcnc-sim" to "linuxcnc-uspace"... and the buildbot is kinda broken?
[14:17:32] <Connor> Possible.
[14:18:03] <Connor> Why moving away from -sim to -uspace ?
[14:19:01] <seb_kuzminsky> the thing that used to be called "sim" has been replaced with a new thing called "uspace", which does everything sim did but can *also* run real machines if you run it under a special kernel
[14:19:03] <Connor> Well.. anyway.. bug still in that version
[14:19:35] <andypugh> JA4 is pretty stale isn’t it?
[14:19:56] <seb_kuzminsky> try installing linuxcnc-uspace, you should get version 2.8.0~pre1, which has the gmoccapy pause surprise-move bug fixed, according to nobert
[14:20:02] <seb_kuzminsky> andypugh: we're up to ja6 now ;-)
[14:20:13] <seb_kuzminsky> bbl, work
[14:21:20] <andypugh> Ah, OK. seems that I need to refresh something git branch -r wasn;t showing that
[14:22:27] <Connor> still moves on 2.8.0~pre1
[14:22:36] <Connor> in Axis - No gmoccapy
[14:34:44] <jepler> seb_kuzminsky: you asked for it ..
http://www.cafepress.com/cp/customize/product2.aspx?from=CustomDesigner&number=1419860221
[14:39:12] <cradek> that font...
[14:39:27] <jepler> it was the least-bad fixed width lowercase font they had
[14:49:12] <seb_kuzminsky> Connor: just to be clear, are you reporting that 2.8.0~pre1, using the Axis gui, has the "surprise move on remap abort" bug that's recorded in #394?
[14:49:25] <seb_kuzminsky> and if so, you you add that valuable datapoint to the bug tracker?
[14:49:43] <seb_kuzminsky> jepler: that's quite a tshirt :-)
[14:49:50] <seb_kuzminsky> bbl work
[14:49:52] <Connor> seb_kuzminsky: Correct
[14:50:11] <Connor> It doesn't stop dead on the spot.. it jumps a few more moves ahead.
[14:50:26] <Connor> I thought it was the GUI lagging.. but.. it's not.
[17:09:14] <andypugh> I don’t seem to be able to compile JA6 without effort.
[17:09:22] <andypugh> I get “/home/andypugh/linuxcnc-dev/src/emc/motion/command.c:275: error: implicit declaration of function ‘isfinite’”
[17:10:33] <andypugh> Maybe my OS is too ancient? ( Linux mill 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010 i686 GNU/Linux )
[17:10:40] <cradek> hm, did I screw it up? that's something I futzed with
[17:11:58] <cradek> let me try it here
[17:12:12] <andypugh> I was hoping you would say that :-)
[17:13:13] <andypugh> (I am actually mainly messing about with Glade)
[17:13:41] <cradek> well crap, it worked fine for me, simulator/uspace build on wheezy
[17:14:08] <andypugh> Don;t suppose you have an RTAI build on 10.04?
[17:14:23] <cradek> at the shop, but not here
[17:14:55] <cradek> git grep isfinite shows only three uses, no definition or prototype
[17:15:03] <andypugh> Maybe I need to bit the bullet and convert back from JA to normal, so that I can run a released version? :-(
[17:15:07] <cradek> manpage says it comes from math.h
[17:16:56] <cradek> I bet isfinite was removed from master because nothing called it
[17:17:02] <cradek> but ja does use it
[17:17:46] <andypugh> isn’t math.h a linux lib?
[17:17:54] <andypugh> or do you mean rtapi_math.h?
[17:19:57] <cradek> I suspect (but didn't verify) that my uspace build works because it just uses math.h and -lm
[17:20:13] <cradek> I think you are right that it's rtapi_math.h that needs to be right for your setup
[17:20:47] <cradek> what gcc is yours?
[17:22:08] <andypugh> Hmm, well, I have it in /usr/include/linuxcnc/rtapi_math.h but not in linuxcnc-dev/src/rtapi/rtapi_math.h or linuxcnc-dev/include/rtapi_math.h
[17:22:24] <cradek> yeah your old JA sure might have it
[17:22:30] <cradek> what's gcc -v say?
[17:22:58] <andypugh> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)
[17:23:16] <cradek> try
http://pastie.org/pastes/9679587/text
[17:26:00] <andypugh> I already did a much less subtle thing and copied the /usr/include version over the linuxcnc-dev versions
[17:26:27] <cradek> well I'd rather you try this, because I'll commit it if it works
[17:26:35] <andypugh> Which was a partial success..
[17:26:41] <cradek> heh
[17:26:44] <andypugh> I now get “/home/andypugh/linuxcnc-dev/src/emc/tp/tc.c:411: error: implicit declaration of function ‘fmin’"
[17:27:29] <cradek> 'round here we call that whack-a-mole
[17:29:13] <cradek> still builds and runs for me with that little change
[17:30:35] <andypugh> How do I apply that patch?
[17:30:44] <andypugh> Save as a file then patch -p1?
[17:31:05] <cradek> git am the-saved-file
[17:31:38] <andypugh> Ooh! It didn’t complain
[17:31:47] <andypugh> (I haven’t coded for about 6 months)
[17:37:39] <cradek> I wish you could've come to the houston hackspace. what a cool place.
[17:42:33] <jepler> #if defined(_KERNEL__) ... #define isfinite __builtin_isfinite
[17:42:56] <jepler> isfinite and fmin are both documented as having built-in implementations in gcc
[17:44:10] <jepler> though it looks like there is a definition of fmin supplied #ifdef __KERNEL__ so I'm not sure why that one's a problem
[17:53:23] <andypugh> Well, it compiled this time.
[17:53:41] <andypugh> That’s with the patch after a fresh pull
[17:54:09] <andypugh> So, perhaps the version of rtapi_math.h I over-wrote with had isfinite but not fmin?
[17:55:18] <andypugh> I will pop out to the garage and see whether it is different after i have eaten
[18:10:09] <seb_kuzminsky> cradek: didn't ja6 build on the buildbot, including lucid-rtai-i386? or did it fail? it's all a blur
[18:21:37] <andypugh> It all seems OK now.
[18:21:57] <andypugh> ja6 does not have the wild feed-per-rev behaviour of ja3
[18:23:04] <andypugh> My spindle speed is reading out in rpm, so I get 6mm rather than 0.1mm per rev, but that is my thing to fix.
[18:23:40] <andypugh> (resolver.03.velocity-scale = -60)
[18:24:10] <andypugh> I need to see where else that velocity is used, though.
[18:24:40] <andypugh> It is part of my spindle gear detection.
[18:39:29] <skunkworks_> cool
[18:46:35] <skunkworks_> there was an issue a while back with muxed encoders where the velocity pin was incorrect..
[18:47:40] <skunkworks_> but that was fixed
[18:49:39] <skunkworks_> (I had to scale it to get fpr to work correclty)
[20:55:14] <cradek> andypugh: oh yay, that's good to know
[20:55:37] <cradek> so I should push that?
[20:55:59] <cradek> seb_kuzminsky: I don't remember if it built. If it didn't, I guess I didn't notice. I couldn't get buildbot to show me that much history.
[20:56:28] <andypugh> cradek: It might be useful to test that it really was necessary, and not a cock-up in my config
[21:01:02] <cradek> linuxcnc-build_: force build --branch=joints_axes6 0000.checkin
[21:01:03] <linuxcnc-build_> build forced [ETA 1h12m27s]
[21:01:03] <linuxcnc-build_> I'll give a shout when the build finishes
[21:01:13] <cradek> andypugh: this oughta tell us, I think
[21:03:28] <andypugh> That buildbot is a cool tool
[21:03:58] <cradek> yeah it sure is
[21:04:43] <cradek> hm, two columns in the grid -- not sure if I did the right thing
[21:04:50] <cradek> guess it'll sort out either way
[21:08:03] <jepler> wow that's some eye-crossingly intricate code
http://lxr.free-electrons.com/source/arch/arm/include/asm/div64.h#L73
[21:08:20] <jepler> I hope someday I get to write a sweet macro like that
[21:10:56] <cradek> what's above wizard-level?
[21:11:09] <linuxcnc-build_> build #1784 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1784
[21:11:37] <linuxcnc-build_> build #397 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/397
[21:11:43] <cradek> /home/buildslave/emc2-buildbot/precise-rtai-x86/precise-i386-realtime-rip/build/src/emc/motion/command.c:275:2: error: implicit declaration of function ‘isfinite’ [-Werror=implicit-function-declaration]
[21:11:48] <cradek> so yeah
[21:12:14] <cradek> linuxcnc-build_: ok yeah you can stop now
[21:12:15] <linuxcnc-build_> build #2583 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2583
[21:13:05] <andypugh> Not just me then
[21:13:59] <linuxcnc-build_> build #2582 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2582
[21:14:24] <KGB-linuxcnc> 03Chris Radek 05joints_axes6 3e2c8c6 06linuxcnc 10src/rtapi/rtapi_math.h re-add isfinite, needed for rtai on lucid * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3e2c8c6
[21:15:00] <cradek> git rebase sure lets you futz things up in ways that are untrackable and undecipherable later
[21:28:01] <seb_kuzminsky> http://paste.ubuntu.com/8712924/
[21:28:12] <seb_kuzminsky> 2.7~pre debs on www.linuxcnc.org ^^^
[21:28:24] <seb_kuzminsky> i'll send an announcement later tonight
[21:32:03] <cradek> cool!
[21:37:13] <linuxcnc-build_> build #2593 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2593
[22:16:52] <linuxcnc-build_> build #2086 of 2000.docs is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2086 blamelist: Chris Radek <chris@timeguy.com>
[22:27:00] <linuxcnc-build_> build #2594 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2594 blamelist: Chris Radek <chris@timeguy.com>