Back
[08:12:33] <jepler> I don't think I ever scoped scope.sample.time before now.
[08:12:44] <jepler> you can actually see that its time gets slightly lower once it's triggered
[08:59:59] <cradek> andypugh: have you ridden it yet?
[09:18:32] <skunkworks> cradek,
https://www.youtube.com/watch?v=mpHFVzwwZWs&list=UUexvgsGz_QFvOublovDYoTQ
[09:23:43] <archivist> I was going to comment a few milliseconds after testing the brake, I would have been right
[09:34:07] <jepler> well despite eliminating async this and dma that, I still get 800+us tmax on spidev
[09:36:40] <cradek> skunkworks: oh awesome
[09:37:38] <skunkworks> jepler, so off to write a driver
[09:37:40] <skunkworks> ?
[09:37:42] <skunkworks> ?
[09:38:10] <skunkworks> cradek, I like his little grin at end :)
[09:38:28] <cradek> it sure started easily
[09:38:49] <cradek> does it have a kick start or is he kick-spinning the outside of the flywheel-clutch part?
[09:39:03] <jepler> that rear tire looks severely underinflated
[09:39:23] <jepler> also, the internal combustion engine is a fad
[09:41:23] <jepler> hmm numerous cuts .. we'll assume they're just to keep the video length reasonable
[09:41:51] <cradek> I assume he just cut the parts where he's out of view
[09:45:09] <jepler> skunkworks: I'll stare some more at the driver I have first
[09:45:28] <jepler> skunkworks: there are lots of lines over three source files, maybe something I've overlooked
[09:48:31] <skunkworks> you will figure it out
[09:50:09] <jepler> keep the self-affirmation jpegs coming until I do
[09:50:35] <cradek> http://24.media.tumblr.com/b18e7d58ca603db3f838b3ba7aaaa085/tumblr_mfpua5yDWR1rmwqc0o1_250.gif
[09:51:20] <cradek> I like how andy uses G33 for crazy things
[09:51:42] <cradek> that was really my vision, making it work in any direction for any reason
[10:10:32] <pcw_home> skunkworks: did you get linuxcnc to compile on Ubuntu 14.04?
[10:21:18] <seb_kuzminsky> pcw_home: i've build master (uspace) on trusty, it passed runtests
[10:23:06] <pcw_home> my compile errors out in taskmodule.cc
[10:23:30] <seb_kuzminsky> mm, lemme look again
[10:24:33] <pcw_home> probably something broken on this machine (upgraded? from 12.04)
[10:25:28] <seb_kuzminsky> pastebin the error?
[10:27:59] <pcw_home> lots of gobbledegook:
[10:28:00] <pcw_home> http://pastebin.com/7B2Nz65m
[10:29:06] <seb_kuzminsky> oh yes
[10:30:58] <seb_kuzminsky> if you 'cd debian; ./configure uspace; cd ..; dpkg-checkbuilddeps', you'll get a list (possibly empty) of packages you need to install
[10:31:13] <seb_kuzminsky> install all of them *except* libgnomeprintui-dev, and see if that makes your compile go
[10:36:53] <seb_kuzminsky> yeah, wfm here
[10:37:23] <pcw_home> ok trying that now
[10:37:50] <seb_kuzminsky> this is a fresh install of trusty, not an upgrade, so maybe something is different about the upgrade path
[10:37:53] <seb_kuzminsky> bbl
[11:19:07] <seb_kuzminsky> Runtest: 142 tests run, 142 successful, 0 failed + 0 expected
[11:19:07] <seb_kuzminsky> 0 09:27:10 seb@trusty-i386 /home/seb/linuxcnc-dev/src>
[11:25:55] <jepler> seb_kuzminsky: +1
[11:28:04] <pcw_home> hmm not sure whats different but my compile still fails in the same place
[11:30:37] <jepler> pcw_home: what is "gcc -version"? What is shown when you "dpkg -l libboost*-dev"?
[11:30:48] <jepler> I suspect the version of gcc or of libboost is different from your machine to seb's.
[11:31:01] <jepler> so obviously it would be useful to know the same information for seb's trusty machine
[11:36:28] <seb_kuzminsky> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[11:36:50] <seb_kuzminsky> ii libboost-python-dev 1.54.0.1ubuntu1 i386 Boost.Python Library development files (default version)
[11:36:53] <seb_kuzminsky> ii libboost-python1.54-dev:i386 1.54.0-4ubuntu3 i386 Boost.Python Library development files
[11:36:56] <seb_kuzminsky> ii libboost1.54-dev 1.54.0-4ubuntu3 i386 Boost C++ Libraries development files
[11:49:15] <jepler> http://stackoverflow.com/questions/18900730/boostshared-ptrshared-ptrconst-boostshared-ptr-is-implicitly-declared
[11:49:31] <jepler> it looks like the problem *could be* a too old version of boost
[11:49:50] <jepler> https://svn.boost.org/trac/boost/changeset/73202
[11:51:32] <seb_kuzminsky> i feel a versioned dependency coming on
[11:55:48] <jepler> seb_kuzminsky: debian/configure dependent too
[11:56:25] <jepler> seb_kuzminsky: since whatever boost pcw_home has is probably OK in natty but apparently not in trusty (because of gcc changes)
[12:00:19] <memleak> gcc and boost python issues with linuxcnc? i can help with that! whats the problem? compiling error? got the output?
[12:00:44] <memleak> ah the pastebin, one sec
[12:01:08] <jepler> memleak:
http://pastebin.com/7B2Nz65m which looks like
http://stackoverflow.com/questions/18900730/boostshared-ptrshared-ptrconst-boostshared-ptr-is-implicitly-declared
[12:02:33] <memleak> ive been able to build linuxcnc with 3 or 4 different versions of boost and boost python (gentoo here)
[12:03:14] <memleak> my guess is maybe conflicting boost-python libs, fix might be explicitly set --with-boost-python into configure line
[12:04:26] <memleak> also python2 should be the one symlinked to /usr/bin/python (or ./configure --with-python but you'll get runtime issues later on due to hard codes in linuxcnc)
[12:04:51] <memleak> pcw_home, can you post output of ./configure?
[12:06:18] <memleak> python boost 1.54 works fine here
[12:07:33] <skunkworks> http://www.machsupport.com/forum/index.php/topic,27782.20.html
[12:12:38] <pcw_home> looks like I have 2 versions installed 1.46 and 1.48
[12:12:58] <memleak> eek.
[12:13:01] <jepler> pcw_home: install libboost1.54-dev and remove any libboost*dev package that is not 1.54
[12:13:11] <memleak> 1.4X is too old
[12:13:20] <memleak> i never used 1.4
[12:13:23] <jepler> I think libboost1.54-dev will pull in libboost-python1.54-dev but if not, install it manually
[12:13:45] <memleak> (i think its too old considering gentoo doesnt even go back to 1.4X releases)
[12:14:01] <memleak> earliest is 1.52
[12:14:03] <seb_kuzminsky> boost 1.48 works fine on precise, with gcc 4.6.3
[12:14:23] <memleak> ok so maybe 1.46 is too old and 1.48 and newer is fine
[12:15:01] <jepler> I think that newer gcc tightened the interpretation of c++11, making boost versions that were OK not OK anymore
[12:15:13] <memleak> yes that happened with 48
[12:15:14] <memleak> *4.8
[12:15:35] <seb_kuzminsky> pcw_home: if you remove libboost1.46-dev and keep 1.48-dev, reconfigure & rebuild, does it work?
[12:15:54] <jepler> OK, I didn't read close closely enough to find out which versions had compatibility problwems
[12:16:05] <jepler> but now we know some pairs that are bad and some pairs that are good
[12:16:18] <memleak> speaking of which im going to bump my boost to 1.55
[12:16:27] <memleak> (because I can)
[12:16:52] <memleak> how does linuxcnc use boost anyway>
[12:17:13] <memleak> oh lord the compiling times for boost, forgot about that.. XD
[12:17:31] <jepler> memleak: it is used in code which allows the interpreter to be extended with Python.
[12:20:23] <skunkworks> cough - you have to be a programmer to use mach4...
[12:21:04] <skunkworks> https://www.youtube.com/watch?v=MRyaRQwhYWk&feature=youtu.be
[12:25:30] <memleak> jepler, the rule of thumb with GCC is that with each release, it gets more strict, exposes more bugs in more projects, and errors out at more coding mistakes.
[12:26:30] <memleak> on the upside of performance enhancements if there isnt a compiler / optimization bug which again falls under strictness
[12:29:41] <pcw_home> Thanks! upgrading libboost-dev to 1.54 fixed it (at leas the taskmodule.cc issue)
[12:29:55] <memleak> sweet!
[12:39:28] <pcw_home> and it works...
[12:46:57] <seb_kuzminsky> yay
[12:54:24] <pcw_home> jepler: I fixed the twiddler interface firmware and example code to work with the latest D8 processor so now only the USB code uses the old processor. I also updated it so that the processor runs at its own clock, not the bus interface clock, so for cards like a 5I25, the CPU clock speed can be 100 MHz while the bus speed is 33 MHz
[12:55:48] <seb_kuzminsky> pcw_home: i think something went wrong in yout upgrade to trusty. we build-depend on libboost-python-dev, which in trusty depends on libboost-python1.54-dev, which depends on libboost1.54-dev, which works
[12:56:13] <seb_kuzminsky> did you just use the standard 'do-release-upgrade' thing on your old ubuntu install? which release was that?
[12:57:05] <pcw_home> Yeah i just said yes when it asked to upgrade to 14.04
[12:57:20] <pcw_home> it was 12.04
[12:59:23] <seb_kuzminsky> bummer that it got it wrong :-/
[13:00:25] <pcw_home> I think i had the same issue on another machine upgraded from 12.04 to 14.04
[13:00:27] <pcw_home> of course I may have done the wrong thing twice
[13:01:10] <seb_kuzminsky> on an upgraded machine that doesn't work, i'd be curious to see 'dpkg -s libboost-python-dev'
[13:02:59] <pcw_home> ii libboost-python- 1.48.0.2 i386 Boost.Python Library development files
[13:03:00] <pcw_home> ii libboost-python1 1.46.1-7ubunt i386 Boost.Python Library development files
[13:03:02] <pcw_home> ii libboost1.46-dev 1.46.1-7ubunt i386 Boost C++ Libraries development files
[13:04:14] <seb_kuzminsky> i must be missing something
[13:04:24] <seb_kuzminsky> libboost-python-dev version 1.48.0.2 isn't in trusty
[13:04:37] <seb_kuzminsky> that looks like a partial upgrade
[13:05:03] <seb_kuzminsky> if you run 'sudo apt-get update && sudo apt-get install libboost-python-dev', does it pick up libboost-python-dev 1.54?
[13:06:28] <pcw_home> let me give that a try
[13:07:27] <pcw_home> libboost-python-dev is already the newest version. (since I had installed 1.54)
[13:08:01] <seb_kuzminsky> oh, this is on the machine you just fixed?
[13:08:09] <pcw_home> yes
[13:08:24] <seb_kuzminsky> ah ok
[13:08:27] <seb_kuzminsky> i'll try an upgrade here
[13:08:58] <pcw_home> I reverted the other machine to 12.04 since i had these problems
[13:11:06] <pcw_home> its entirely possible the upgrade was mangled because the 12.04 system was broken in various ways before I started
[13:11:18] <seb_kuzminsky> heh ok
[13:12:48] <pcw_home> I think I gave up at the tcl issues on the other system (that just needed tcl-dev and tk-dev 8.6 installed)
[13:13:01] <seb_kuzminsky> i booted a fairly clean precise machine and after a few minutes it popped up a window asking if i wanted to upgrade to trusty, and i clicked ok and it started doing stuff
[14:43:17] <jepler> can somebody choose a less angry background than that yellow for code boxes on the forum?
[14:43:34] <jepler> the chance I could help anyone with their code is diminished by the automatic headache
[14:50:03] <ssi> lol
[14:57:53] <seb_kuzminsky> jepler: bust out that monochrome monitor of yours
[15:02:19] <cradek> just unplug the red and blue BNCs
[15:02:36] <PCW> Or EL panel, then everything is bright yellow
[15:03:31] <seb_kuzminsky> we're so helpful
[15:05:08] <cradek> it might even have themes you can pick ... somewher
[15:05:08] <cradek> e
[15:32:00] <seb_kuzminsky> my precise->trusty upgraded machine has the same problem that PCW reported
[15:32:14] <seb_kuzminsky> old boost-dev libs around, and it's missing the new one
[15:33:46] <seb_kuzminsky> after the precise->trusty upgrade, running "apt-get update && apt-get dist-upgrade" seems to have fixed the problem
[15:34:10] <seb_kuzminsky> it upgrades libboost-python-dev to the trusty version, which pulls in the 1.54 boost packages
[15:34:19] <PCW> so the upgrade is not really complete
[15:34:27] <seb_kuzminsky> wonder why the precise->trusty upgrade didnt do that?
[15:34:36] <seb_kuzminsky> PCW: yeah, seems that way
[15:36:18] <PCW> Thanks for looking at that (and glad I didn't do anything stupid to fumble the upgrade twice)
[15:53:53] <cradek> aha, in
http://1.bp.blogspot.com/-szYIGh52z1M/U_u04wCCPtI/AAAAAAAAELg/hivSv_6-cI0/s1600/IMG_1472.jpg I see an obvious kickstarter
[15:54:42] <jepler> geez, it took me a minute to figure out you didn't mean "an idea for something to market via kickstarter.com"
[15:57:08] <seb_kuzminsky> heh
[17:00:06] <jepler> what actually happens in a hardware stepgen system when you have an out-of-spec latency in the servo thread?
[17:00:32] <jepler> with software stepgen, a latency probably causes your steppers to stall, and you lose position
[17:00:44] <jepler> but with mesa, your steppers will keep going at an appropriate velocity
[17:00:52] <seb_kuzminsky> right
[17:01:02] <jepler> and when linuxcnc comes back, stepgen (if you've set stepgen accel limits) won't change velocity so quickly that it stalls the motors
[17:01:19] <jepler> you could following error if the motors were stepped too far while linuxcnc napped
[17:03:45] <PCW> if you use a hardware stepgen and a PID loop to mainly correct for long term timing errors cycle/cycle jitter is not too important
[17:05:05] <PCW> that is the loop is tuned to "trust" the stepgen hardware so FF1 = 1.000 P gain= low maxerror= low
[17:05:59] <PCW> so the corrections have a low slew rate/bandwidth
[17:07:03] <jepler> today I'm running a CPU-intensive function on my main thread -- using approximately 50% of one CPU core
[17:07:23] <jepler> it will tell me something useful if that gets big latencies like spi
[17:07:46] <jepler> namely that it's not some unidentified part of spi that is still sleeping, but a latency from some other source
[17:09:09] <jepler> and in fact it did just see a tmax = tavg + ~300us
[17:09:32] <jepler> so there's some significant latency that is not spidev
[17:10:29] <jepler> and the very quick latency-test / latency-histogram tests just get hit by it proportionally less -- enough less that it's not seen in 24 hours of testing, but turns up in 20 minutes of testing with an RT CPU hog
[17:17:12] <jepler> surely the thing I just changed is not *it*
[17:18:05] <jepler> better let it run before making big-mouth pronouncements
[17:19:34] <jepler> nah of course not
[17:20:15] <jepler> it's still *a* thing, maybe: don't run ntp
[17:20:41] <jepler> it can change CLOCK_MONOTONIC by steps
[17:31:42] <jepler> (.. has anyone attempted to operate linuxcnc over a leap second yet?)
[22:08:29] <memleak> "It seems like Alec is—or should be—friends with jepler."
https://osrc.dfm.io/ntulinux/
[22:09:06] <memleak> interesting..
