Back
[01:29:20] <seb_kuzminsky> wow, the first comment on the 2.7 branch announcement was positive, that's nice
[01:32:36] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 352840e 06linuxcnc 10docs/src/code/Contributing-to-LinuxCNC.txt docs: describe our git workflow briefly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=352840e
[01:46:45] <seb_kuzminsky> rtai panicked on one of the buildslave vms:
http://highlab.com/~seb/linuxcnc/rtai-crash.2014-10-29.png
[01:47:00] <seb_kuzminsky> i powercycled it and it seems fine
[02:01:23] <seb_kuzminsky> i added 2.7 docs to the wlo/docs front page:
http://www.linuxcnc.org/docs/
[02:04:13] <seb_kuzminsky> hm, for 2.6 we have install/update docs both on the wiki (
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingTo2.6) and in git (
http://www.linuxcnc.org/docs/2.6/html/common/Updating_LinuxCNC.html)
[02:04:44] <seb_kuzminsky> i think for 2.7 we should try to modernize the git version of the docs and not use the wiki docs
[02:04:53] <seb_kuzminsky> but that's a project for another night!
[02:05:31] <seb_kuzminsky> lol, the 2.6 docs say: This documentation refers to LinuxCNC version 2.6.3-856-gf2ec59a.
[02:06:06] <seb_kuzminsky> i guess that's a build of the version of 2.6 that accidentally had master merged into it
[02:06:38] <seb_kuzminsky> the buildbot stalled when the wheezy-rtai-i386 slave crashed, once it catches up it'll replace those docs with the ones jepler fixed
[02:50:21] <linuxcnc-build_> build #2389 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2389 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:45:42] <linuxcnc-build_> build #2602 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2602 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:05:37] <poly> Hi
[06:06:48] <poly> I have an issue with manual "Continuous" movement with AXIS. When i Press "+" or "-" my stteper only process some mm. (I keep the button pressed ..)
[06:31:52] <skunkworks_> what happens if you press the arrow keys on the keyboard?
[06:33:46] <poly> same
[06:33:57] <poly> move is around 8mm
[06:34:10] <poly> it's annoying
[06:51:04] <archivist> poly did you set sensible numbers for your axis travels
[06:53:38] <poly> explain
[06:53:49] <poly> archivist: doesnt ring a bell for me
[06:54:11] <archivist> how did you setup
[06:54:46] <poly> wizard and manually
[06:54:57] <poly> it's a 5 axis CNC with mesa board
[06:55:17] <poly> i have custom stepper driver /128
[06:55:41] <poly> motor moves fine if i send command
[06:55:57] <poly> but never move continuously on "conitnuous" and press down
[06:56:11] <archivist> I am just wondering if a soft limit is kicking in
[06:56:16] <poly> i think i need so correct something somewhere in INI but dont know what
[06:56:23] <poly> Manual doesnt speak about it
[06:56:31] <poly> perhpase
[06:56:41] <poly> but im still in working zone
[06:56:54] <poly> pehase it's due to no-homing
[06:57:01] <poly> dunno
[06:57:03] <poly> need tips
[06:57:06] <poly> brb and thx a lot
[06:58:21] <archivist> poly,
http://www.linuxcnc.org/docs/html/config/ini_config.html#sub:AXIS-section
[06:59:46] <archivist> set your limits to sensible figures for your machine
[07:14:17] <poly> that's it
[07:14:40] <poly> max_limit at 8 ;)
[07:14:43] <poly> thx you archivist
[08:05:59] <skunkworks> hmm - actually - how do the debs work with different realtimes?
[08:06:30] <skunkworks> I totally skipped that part in the email.. (for me it is building the rip for rt_preempt)
[08:06:43] <skunkworks> I guess 1 cup of coffee isn't enough
[08:49:32] <jepler> skunkworks: "uspace" package will run anywhere but only gives RT performance with a PREEMPT-RT kernel running. old package runs only with specific rtai kernel.
[08:50:54] <skunkworks> ah
[09:02:03] <pcw_home> so the uspace version of linuxcnc will be a package for 2.7?
[09:11:35] <seb_kuzminsky> huh, that build failure is unexpected
[09:13:14] <seb_kuzminsky> pcw_home: yep! :-)
[09:14:31] <seb_kuzminsky> pcw_home: you can apt-get install 2.7.0~pre2 linuxcnc-uspace on lucid, precise, and wheezy right now. It works in all the places the old 2.6 -sim package worked, plus on rt-preempt
[09:14:48] <seb_kuzminsky> which we only support on wheezy, because we're too lazy to build rt-preempt kernels for anything else
[09:15:13] <seb_kuzminsky> though if someone wanted it.... it'd be pretty easy to get it building and running on ubuntu precise, i bet
[09:15:51] <pcw_home> Preemt-rt kernels are easy to build
[09:16:05] <seb_kuzminsky> ding ding, we have a volunteer! ;-)
[09:17:00] <pcw_home> pcw@pcw-G41M-Combo:~/linuxcnc-dev$ uname -a
[09:17:02] <pcw_home> Linux pcw-G41M-Combo 3.14.12-rt9 #1 SMP PREEMPT RT Mon Jul 14 22:21:51 PDT 2014
[09:17:05] <seb_kuzminsky> i installed the linuxcnc-uspace debs from linuxcnc.org on my devel laptop:
http://pastie.org/9683175
[09:17:42] <seb_kuzminsky> pcw_home: cool. is that kernel from a deb or hand-built and hand-installed from source?
[09:18:11] <pcw_home> Hand built
[09:19:12] <pcw_home> probably something that can be scripted easily (I just used menuconfig or whatever its called)
[09:20:10] <seb_kuzminsky> the tricky part is making a config that works on as many computers as possible, and building the kernel in a repeatable way
[09:20:52] <pcw_home> Yeah, that why I appreciate the wheezy preemt-rt kernel
[09:21:04] <seb_kuzminsky> the second part is handled by the kernel builder scripts here:
https://github.com/SebKuzminsky/linux-rtai-build
[09:21:18] <seb_kuzminsky> the rt-preempt kernel in wheezy is soooo wonderful
[09:24:46] <pcw_home> I guess for preemt-rt on a dist that has no standard preemt-rt kernel you could start with the stock kernel config for the dist
[09:24:47] <pcw_home> and patch + add the preemt-rt switches
[09:25:19] <pcw_home> (there are only a couple)
[09:27:24] <seb_kuzminsky> that's an option, or you could snag the kernel config from debian's rt-preempt kernel
[09:28:12] <pcw_home> yeah it seems to get along with most anything
[09:32:16] <seb_kuzminsky> the debian folks are good that way :-)
[09:32:35] <seb_kuzminsky> just don't read their mailing lists, *they* dont get along with anyone :-)
[09:33:16] <seb_kuzminsky> linuxcnc-build_: force build --branch=2.6 0000.checkin
[09:33:16] <linuxcnc-build_> build forced [ETA 3h45m11s]
[09:33:17] <linuxcnc-build_> I'll give a shout when the build finishes
[09:33:35] <seb_kuzminsky> hrm, the builder that failed was the precise-amd64 clang builder
[09:33:58] <seb_kuzminsky> it just stopped in the middle of a build, nothing funny on the console or dmesg, i could log in to it, it seemed fine
[09:34:05] <seb_kuzminsky> it was not out of disk
[09:34:48] <jepler> seb_kuzminsky: yuck
[09:34:57] <seb_kuzminsky> pcw_home: i forget, did you test brian morel's new usb rtai kernel?
[09:35:23] <seb_kuzminsky> i looked at his changes and they seem good
[09:35:37] <seb_kuzminsky> i think we can build a new kernel with the same abi number, so the upgrade will be smooth
[09:35:47] <cradek> that would be great
[09:35:52] <cradek> do it do it do it
[09:35:53] <pcw_home> No, I forgot I can try today
[09:36:05] <seb_kuzminsky> didn't someone try it? was it skunkworks?
[09:36:07] <jepler> just to create work for cradek, that might be an important enough change to spin a new live cd too
[09:36:16] <seb_kuzminsky> yeah
[09:36:17] <cradek> I'd absolutely do that
[09:36:23] <seb_kuzminsky> thanks :-)
[09:36:26] <jepler> woo
[09:36:36] <jepler> should push out a 2.6.x too, just to make sure we change *everything*
[09:36:37] <seb_kuzminsky> ok bbl! work! woooo! oh wait, awwww
[09:37:16] <seb_kuzminsky> yeah 2.6 needs a new release now that the gmoccapy surprise-move bug is fixed
[09:37:37] <cradek> is there still a separate remap surprise-move bug?
[09:37:54] <seb_kuzminsky> cradek: yes
[09:38:02] <cradek> ouch
[09:38:04] <cradek> someone should do something
[09:42:42] <skunkworks> run away! RUN AWAY!
[09:42:57] <seb_kuzminsky> cradek: do you have some axis-ui metric/imperial jog fixes brewing somewhere?
[09:42:59] <skunkworks> yes - I tested the usb rtai version and it worked on my hardware that didn't before..
[09:43:13] <seb_kuzminsky> ooooh, nice
[09:43:15] <cradek> seb_kuzminsky: crap, I forgot about that mess
[09:44:10] <cradek> I will try to work on it today
[09:44:13] <seb_kuzminsky> as rm, i take my crap-foisting seriously
[09:45:09] <cradek> I notice that FO still affects jogs, and shift-jog doesn't override it. I was surprised.
[09:45:50] <jepler> seb_kuzminsky: As RM for 2.7 I would like your ruling about the nml sequence number fix that we know breaks nml-over-tcp...
[09:46:02] <jepler> personally I think we should take the fix
[09:51:15] <cradek> seb_kuzminsky: for 2.6?:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/cradek/m19-without-r-defaults
[09:51:26] <cradek> (now I'm finding halfbaked 2.6 fixes everywhere I look)
[09:52:29] <cradek> I think it's pretty clear that a bare M19 doing nothing at all is a bug
[09:53:38] <cradek> I still dislike the timeout stuff, but I think it's as-designed
[09:55:01] <jepler> argh why am I shopping for oscilloscopes? I need one so rarely and the one I have is mostly adequate.
[09:57:26] <skunkworks> heh
[09:58:07] <skunkworks> at the witchita fest - I got to play with a couple digital scopes.. I do really want one but probably use it less than you..
[09:58:29] <archivist> more than one scope is the answer :)
[09:58:58] <archivist> I admit some are hardly if ever used these days
[09:59:21] <cradek> I love my tek that has a crt with full analog mode, but also can do (limited) digital storage
[09:59:37] <cradek> I find full digital scopes very annoying
[10:00:35] <cradek> I think it's a 2232
[10:00:49] <cradek> if it was 4-channel it would be perfection
[10:00:54] <skunkworks> I was annoyed by the delay - but that is fixed by buying expeniver scopes..
[10:00:57] <archivist> I use an old 20meg analogue as the one to be dragged about
[10:01:15] <cradek> skunkworks: or cheaper, paradoxically
[10:01:37] <archivist> got an 8 chan digital for complex
[10:02:54] <cradek> I also have a 466 (analog storage) which I like quite a bit for some things, like very slow signals (you can use the slowly-fading screen in cool ways)
[10:03:10] <cradek> its problem of course is you can't see what happened before the trigger
[10:04:06] * skunkworks hugs halscope...
[10:04:10] <seb_kuzminsky> heh
[10:04:22] <jepler> my scope's a full digital one, dunno the make/model offhand. whatever rigol they were using at TXRX was way better in terms of display and responsiveness..
[10:04:32] <archivist> my sampler frame is a 661 has a 3(iirc) gig plugin
[10:07:05] <jepler> ah, this one
http://www.eevblog.com/forum/reviews/hp-54502a-nearly-vintage-digitizing-scope/
[10:07:10] <pcw_home> I have a 3 gig sampling plugin for my old TEK 11403 I use occasionally for SI issues
[10:07:15] <seb_kuzminsky> i hardly ever us an oscilloscope, and when i do it's for basic stuff, and i'm super happy with my little tek tds something
[10:08:03] <seb_kuzminsky> i got a crazy bro-deal from a previous employer
[10:09:25] <pcw_home> sampling plugins are nice because they tend to have much better signal fidelity (lower overshoot etc that realtime)
[10:10:43] <archivist> I did have a real rare tek a 1ghz realtime analogue from 1960 but the heater went in the crt
[10:11:10] <jepler> hm now I'm worried my scope will break
[10:11:21] <jepler> due to this battery-backed NVRAM
[10:11:47] <pcw_home> 1018 or something? one of those had 4cx250s driving the verticals
[10:12:18] <seb_kuzminsky> cradek: in your branch, the docs for m19 still say R is required (it's not in square brackets)
[10:12:52] <cradek> oops
[10:13:01] <archivist> PCW, 4cx250 yes but the model is 519
[10:13:01] <cradek> and now I forget what even happens if you don't specify Q
[10:13:14] <cradek> maybe it's too half-baked
[10:13:25] <archivist> transmission line deflection plates
[10:13:29] <pcw_home> Thats right 519
[10:14:48] <archivist> so how did they adjust the crt
http://www.collection.archivist.info/archive/DJCPD/PD/2010/2010_11_24_Tektronix_519/IMG_0901.JPG
[10:16:25] <cradek> that's quite a crt
[10:17:41] <seb_kuzminsky> cradek: wow, interp used to require P *or* R for M19? and then do nothing if P was unspecified? that's silly, your change is a good one
[10:17:56] <seb_kuzminsky> also, it looks like Q is optional in interp, but marked as required in the docs
[10:18:17] <cradek> but I think it maybe doesn't wait at all (so always fails) without a Q
[10:19:03] <archivist> there was no vertical amp in the scope, the signal went via a trigger take off then a delay line then straight onto the crt, then to a dummy load so signal was in a matched line
[10:20:32] <cradek> seb_kuzminsky: probably we should figure out how it should work, and then make sure it does that.
[10:20:50] <cradek> seb_kuzminsky: I'm going to work on AXIS first, though
[10:21:13] <seb_kuzminsky> that makes sense
[10:21:45] <seb_kuzminsky> i'll open a ticket to clean up m19 later
[10:22:14] <cradek> thanks
[10:22:21] <seb_kuzminsky> logger[psha]: link pls
[10:22:21] <logger[psha]> seb_kuzminsky: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-10-29.html
[10:29:49] <linuxcnc-build_> Hey! build 0000.checkin #2603 is complete: Success [3build successful]
[10:29:49] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2603
[10:36:26] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/398/
[10:36:39] <seb_kuzminsky> i wish we had a robot that would post links to bugtracker changes here in irc
[10:37:15] <seb_kuzminsky> wow, i sure do like seeing "(patch included)" in the subject line of a bug report :-)
[11:08:41] <jepler> CaptHindsight: did you ever try hm2_eth on your cubie yet?
[11:10:55] <CaptHindsight> jepler: no, we have been sidetracked by other adventures
[11:11:08] <CaptHindsight> maybe next month
[11:11:38] <jepler> CaptHindsight: heh no worries
[11:12:15] <CaptHindsight> it's still the plan, we just need time
[11:28:45] <cradek> whoah, in a fit of blurry nostalgia, I typed C-x v = and it did what I wanted
[11:28:50] <cradek> I didn't know that was still a thing
[11:29:26] <cradek> C-x v u worked too
[11:29:39] <jepler> I guess vc-mode learned about git
[11:47:25] <skunkworks> http://xkcd.com/378/
[11:48:17] <cradek> it's so surprising when, after much churn, something works as well as it did ten years ago
[12:06:29] <kwallace> I searched C-x u and found it undoes and more...
[12:06:29] <kwallace> http://www.gnu.org/software/emacs/tour/
[12:06:29] <kwallace> Being unproductive with Emacs
[12:06:29] <kwallace> Emacs even comes with diversions:
[12:06:29] <kwallace> M-x tetris Tetris
[12:06:29] <kwallace> M-x hanoi Towers of Hanoi game
[12:06:29] <kwallace> M-x doctor Emacs psychotherapist
[12:13:16] <kwallace> Oops, I meant C-x v.
[12:46:01] <skunkworks> Now that dad is doing 'production' we are finding that Y axis moves with spindle temp also...'
[12:47:06] <skunkworks> if we could get the scales working atleast on Y - that would solve the problem I think. (or add some scales)
[13:19:48] <cradek> jepler: would you please review the two commits at
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/v2.5_branch
[13:20:43] <cradek> I tested inch and mm xyzabcuvw configs, each displaying in native and other-units mode, and in all 4 cases jog and shift-jog seemed right
[13:21:20] <cradek> there's still the problem of Vel: readout during abc jogs being weird (it scales), but that's a visual bug only
[13:21:38] <cradek> I should also try jogging rotaries in all 4 cases
[13:22:56] <jepler> cradek: seems sane. looks like an 'is_linear_axis(n)' predicate would be useful
[13:26:32] <cradek> I sort of think shift-jog should act as if feed override is 100%, but it's not so clear that's a *bug*
[13:27:01] <cradek> further, in 2.6 probably RO and not FO should affect jogs
[13:30:40] <cradek> heh asciidoc markup and merge conflict markers look about the same
[13:32:56] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch a62d976 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Fix UVW jogs being too fast by 25.4x, on inch configs displaying mm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a62d976
[13:32:56] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch 28ebd43 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Fix shift-jog speed being too slow on inch configs displaying mm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=28ebd43
[13:32:56] <KGB-linuxcnc> 03Chris Radek 052.6 280d3e2 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Merge branch 'v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=280d3e2
[13:32:58] <KGB-linuxcnc> 03Chris Radek 052.7 5f26871 06linuxcnc 10docs/src/code/Contributing-to-LinuxCNC.txt 10src/emc/usr_intf/axis/scripts/axis.py Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f26871
[13:33:02] <KGB-linuxcnc> 03Chris Radek 05master 2f3138b 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f3138b
[13:42:33] <jepler> cradek: thank you
[13:43:28] <cradek> welcome
[13:43:34] <cradek> now I just wonder whether to close #397
[13:57:09] <Connor> cradek: You fix it ?
[14:00:29] <cradek> #397 reports two things, one of which I can't reproduce, the other of which I fixed, and also I fixed a related but unreported problem.
[14:00:51] <cradek> there is a fourth problem, which is both unreported and unfixed
[14:00:59] <skunkworks> cradek, also with the recent changes with separating fo with rapids - feed hold doesn't work with rapids anymore.. I don't know if there is a work around...
[14:01:24] <cradek> which kind of feed hold?
[14:09:57] <norbert__> I just pulled 2.7 on a new computer, than I did autogen / configure make / make setuid so far all OK. I open git gu and got a new file src/config.h.in~
[14:10:05] <norbert__> IMHO it should be igniored
[14:10:39] <norbert__> or should not even exist
[14:14:25] <jepler> is it possible that your text editor created that file as a backup file?
[14:14:55] <jepler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Git#Use_a_global_ignore_file_for_editor_backups
[14:15:03] <norbert__> I did not use any text editor, I just pulled and compiled and there was the file
[14:15:23] <norbert__> I just tested on my old computer with new repo and there it is the same
[14:15:40] <norbert__> One is debian wheesy the other ubuntu 10.04
[14:16:09] <norbert__> bbl
[14:16:19] <mk0> gedit always makes backups
[14:18:53] <jepler> if it's true that the file is created by building linuxcnc (including autogen/configure steps) then it should be ignored.
[14:19:08] <jepler> it's not created here (wheezy) by building
[14:19:46] <jepler> wheezy amd64 uspace
[14:31:43] <seb_kuzminsky> cradek: that's great, thanks!!
[14:36:40] <cradek> that was a fun mergeup
[14:39:36] <seb_kuzminsky> http://giphy.com/gifs/TzSsE5GIx8MJa
[15:25:56] <norbert__> I will try again later, but I did not make anythink else than git clone, and compile and got the file. I can delete it every time I push, but how can I find out why or from what it si created?
[15:27:31] <cradek> you could check after each step to see which step creates it
[15:32:09] <cradek> I also do not get that file, even if I autogen.sh twice
[16:01:31] <Connor> cradek:bug fix for #397, Was it merged into 2.8.0~pre1.13.gfd255ae ?
[16:01:36] <Connor> If so, it's still present.
[16:01:44] <Connor> the bug that is.
[16:01:50] <Connor> I just updated and can still recreate it.
[16:03:20] <cradek> no, you'll have to wait for 2f3138b
[16:03:40] <cradek> are you the reporter?
[16:03:40] <Connor> ok.
[16:04:07] <Connor> No. I just someone who could verify it. I was online when the guy reported it and recreated it.
[16:04:22] <cradek> thanks for testing, that's great
[16:04:35] <cradek> which half of the bug report did you reproduce?
[16:04:48] <Connor> let me go re-read his report.
[16:06:39] <Connor> basically, you start running a g-code program with several lines of code.. and hit the STOP button.. you'll get movement after the fact.
[16:07:12] <cradek> umm, that has nothing to do with #397
[16:07:26] <Connor> CRAP
[16:07:33] <Connor> Never freaking mind.
[16:07:37] <cradek> or do I have the wrong number?
[16:07:41] <Connor> I'm looking at 394
[16:07:48] <cradek> ah!
[16:08:02] <cradek> I don't think anyone has tried to fix that yet :-/
[16:09:59] <Connor> cradek: Okay, Question: How can you setup Axis so that when it first comes up, it's in Imperial vs Metric (even though everything is configured metric in the ini and hal).
[16:10:21] <cradek> I don't know an easy way to do that
[16:10:30] <cradek> it's an unusual thing to want
[16:10:47] <Connor> I did it HALF way with something in the .axisrc file or some file like that..
[16:10:54] <Connor> but.. it doesn't fully take effect.
[16:10:57] <cradek> you could make it save that, like it saves some of the other view preferences
[16:11:08] <cradek> hm, well maybe it's harder than that, then
[16:11:35] <Connor> Must be more than one variable that toggles metric vs imperial.
[16:12:21] <cradek> https://www.youtube.com/watch?v=9ARjpL44IfE
[16:12:25] <Connor> The REASON is.. Me (and PetefromTN) and lord knows who else use imperial units.. but, these days, the ballscrews come in metric.. and it's just easier / cleaner to configure the ini and hal in all metric
[16:12:51] <seb_kuzminsky> i've set up a couple of machine with metric screws but imperial native machine units in linuxcnc
[16:13:14] <seb_kuzminsky> cradek: that R15 in world mode is really cool
[16:13:21] <cradek> yeah, pretty sure my vmc has a scale of 25400 - who cares
[16:14:12] <cradek> but I'd happily review a patch that makes that AXIS option save
[16:14:16] <Connor> cradek: What do you mean by that ?
[16:14:32] <cradek> the machine is natively micron resolution
[16:14:41] <cradek> so the inch scale is 25400/inch
[16:14:53] <cradek> instead of 10000 or some other inchy scale
[16:14:56] <cradek> it doesn't matter to me
[16:15:15] <seb_kuzminsky> a shopbot i configured a few years ago has this:
[16:15:24] <seb_kuzminsky> # 11,700 steps/rev * 1/30 rev/teeth * 2.5 teeth/cm * 2.54 cm/inch
[16:15:24] <seb_kuzminsky> OUTPUT_SCALE = -2476.5
[16:15:36] <Connor> So, what exactly determines with it's metric out imperial in axis on start ?
[16:16:04] <cradek> I don't know without looking at the code
[16:16:49] <Connor> [TRAJ] has LINEAR_UNITS
[16:17:04] <Connor> which affects the what values you put into the AXIS_# right ?
[16:28:43] <skunkworks_> pcw, remember the accupins? easy to make a firmware for your resolver boards?
[16:28:48] <skunkworks_> :)
[16:30:54] <Connor> skunkworks_: Whats accupins ?
[16:31:37] <skunkworks_> http://electronicsam.com/images/KandT/conversion/accpinset.jpg
[16:32:02] <skunkworks_> http://electronicsam.com/images/KandT/conversion/accpinset1.jpg
[16:32:11] <Connor> okay. What am I looking at?
[16:32:14] <seb_kuzminsky> http://33.media.tumblr.com/67af3ca04c25d74b5c098b2c0c639657/tumblr_ndvps8t63O1skla5oo1_500.jpg
[16:32:49] <Connor> That some sort of linear resolver ?
[16:32:54] <skunkworks_> seb_kuzminsky: heh - funny. I just got back from there..
[16:33:24] <skunkworks_> Connor: sort of.. but 2 coils center-tapped
[16:34:49] <skunkworks_> we got them sort of working with an arduino at the Wichita fest.. using an arduino.
[16:34:58] <PCW> I'd have to recall how it works
[16:35:08] <Connor> What are they exactly for ?
[16:36:46] <skunkworks_> pcw: so would I..
[16:36:58] <skunkworks_> I think I have the arduino code around here somewhere
[16:37:45] <Connor> http://electronicsam.com/images/KandT/conversion/accu.pdf
[16:40:17] <skunkworks_> http://electronicsam.com/images/KandT/Fest2013/DSC_3909.JPG
[16:40:52] <Connor> Who is that ?
http://electronicsam.com/images/KandT/Fest2013/DSC_3808.JPG
[16:40:53] <skunkworks_> heh
[16:41:04] <skunkworks_> http://electronicsam.com/images/KandT/Fest2013/DSC_3915.JPG cradek and I working on it..
[16:41:18] <skunkworks_> steve stallings
[16:41:35] * seb_kuzminsky has suspender envy
[16:42:47] <skunkworks_> heh -
http://electronicsam.com/images/KandT/Fest2013/DSC_3931.JPG
[16:43:35] <skunkworks_> the other issue is - I think it needs to be excited at 250hz..
[16:45:41] <skunkworks_> ah - the circuit.
http://electronicsam.com/images/KandT/Fest2013/DSC_3944.JPG
[16:49:37] <Connor> wow. skunkworks_ what was you using that on, or what is it for exactly..
[16:50:15] <Connor> and why is the bar with pins inserted with paper between it...
[16:53:40] <skunkworks_> for spacer... it would normally be mounted on a machine..
[17:14:35] <skunkworks_> Connor: it is what the K&T used for position...
[17:34:56] <Connor> USED? :)
[17:36:27] <seb_kuzminsky> kdbus reminds me of something... can't quite put my finger on it...
https://lkml.org/lkml/2014/10/29/854
[18:15:59] <cpresser> hi, I just tried to install a wheezy-backports kernel: " 3.14-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 3.14.15-2~bpo70+1"
[18:16:38] <cpresser> however, there is an issue when loading hm2_pci. I get a permission-denied error:
[18:16:42] <cpresser> "Failed to open "/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:00.0/enable" (Permission denied)"
[18:16:46] <cpresser> any hints?
[18:25:06] <seb_kuzminsky> hi cpresser
[18:25:26] <seb_kuzminsky> as far as i know, no one has tried that kernel
[18:25:32] <seb_kuzminsky> are you using a uspace build?
[18:26:12] <cpresser> yes, uspace
[18:27:05] <seb_kuzminsky> you ran the 'sudo make setuid' step after building?
[18:27:27] <cpresser> nope, i use the buildbot.binary package
[18:27:51] <seb_kuzminsky> ah
[18:28:03] <seb_kuzminsky> well that should work :-/
[18:28:42] <seb_kuzminsky> can you try it with the 3.2 rt-preempt kernel in the regular wheezy repo instead of the backportes one? or does your computer need a newer kernel for some reason?
[18:29:19] <seb_kuzminsky> also: what version of the linuxcnc-uspace deb are you using?
[18:29:20] <cpresser> ill reboot the machine later
[18:29:27] <cpresser> it did work with the 3.2
[18:29:38] <seb_kuzminsky> aha! that's good info
[18:30:00] <seb_kuzminsky> so something changed between the 3.2 kernel (works) and the 3.14 kernel (doesn't work)
[18:30:37] <seb_kuzminsky> what does "ls -l" of the problematic sysfs file say on those two kernels?
[18:34:04] <cpresser> i need to do one other thing first, ill come back with more info in ~30min
[18:52:28] <jepler> also take a look at the output of ls -l /usr/bin/rtapi_app
[18:52:37] <jepler> just to double-check it's setuid root as expected
[18:53:31] <jepler> I don't think I've actually run uspace from a deb
[18:56:30] <PCW> preemt-rt ruins very well on the G3258 (26 usec latency is worst case I ever saw but rarely above 6 or so)
[18:56:56] <PCW> runs
[18:58:57] <seb_kuzminsky> installing linuxcnc-uspace.deb on wheezy autpomatically pulls in the rt-preempt kernel, that's all kinds of cool
[18:59:27] <PCW> plots of read time are almost flat (vs ~4 to 1 range of baseline vs peaks on a Atom)
[18:59:36] <jepler> seb_kuzminsky: buildbot front page should probably call out the paths for 2.7
[18:59:46] <seb_kuzminsky> err, yes
[19:00:00] <seb_kuzminsky> i'm gonna move things around a bit for 2.7
[19:00:21] <seb_kuzminsky> like i did on wlo already: 2.7-rtai and 2.7-uspace, compared to 2.6 (for rtai) and 2.6-sim
[19:01:53] <jepler> hmmm some people won't want an rt-preempt kernel just because they install linuxcnc
[19:01:58] <seb_kuzminsky> "apt-get install linuxcnc-uspace" works and pulls in the -rt kernel, and linuxcnc runs sim/axis/axis just fine (which is not the error cpresser reported)
[19:02:44] <seb_kuzminsky> then i reboot to the -rt kernel and linuxcnc still runs sim fine
[19:02:47] <seb_kuzminsky> that's kinda neat
[19:03:13] <PCW> does it do the grub futzing?
[19:03:19] <seb_kuzminsky> but it doesn't address cpresser's issue of permission problems on linux 3.14-rt
[19:03:27] <PCW> thats odd
[19:03:31] <seb_kuzminsky> PCW: yes, the -rt kernel shows up in the grub menu
[19:03:42] <seb_kuzminsky> bbl, bus stop
[19:03:52] <jepler> 1:2.7.0~pre2.17.g5f26871 installs rtapi_app with the expected permissions
[19:04:22] <jepler> and loads hm2_pci with the 3.2.0-4-rt-amd64 kernel
[19:04:36] <seb_kuzminsky> that agrees with cpresser's report
[19:04:39] <cpresser> it does have setuid here.. i am going to reboot the machine now.
[19:04:45] <jepler> now trying to find 3.14.15...bpo
[19:04:50] <seb_kuzminsky> the problem seems limited to the 3.14-rt kernel he got from backports
[19:05:10] <cpresser> jepler:
https://packages.debian.org/wheezy-backports/linux-image-3.14-0.bpo.2-rt-amd64
[19:05:23] <cpresser> you also need to get initramfs-tools from packports
[19:05:50] <jepler> hmm I enabled backports but the only bpo kernels I see are linux-image-3.16-0.bpo.2-amd64 and friends (no -rt since there's no 3.16 -rt)
[19:06:02] <jepler> deb
http://ftp.debian.org/debian wheezy-backports main
[19:08:34] <cpresser> here is one difference:
http://nopaste.info/59ced4ebf3.html
[19:09:13] <jepler> "enable" vs "enabled" ?
[19:09:29] <andypugh> Is there an elegant way to subtract pose tuples in python? I was rather hoping that (s.actual_position - s.g5x_offset) would “just work”
[19:09:39] <andypugh> (It would in Matlab :-)
[19:10:27] <jepler> andypugh: map(operator.__sub__, pos1, pos2)
[19:10:54] <cpresser> jepler: i only spottet the permissions, but yes, the filename also differs
[19:11:44] <jepler> if the linux people broke the userspace api of /sys then phooey on them
[19:12:20] <cpresser> hmm.. i should check if its even the same device.. bus numbering might differ between kernels.
[19:12:43] <jepler> "enable" is in the documentatation at
https://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt so if that's gone and replaced by "enabled" then somebody will have to figure out what the deal is and modify linuxcnc
[19:13:52] <jepler> in 3.16-2-amd64 I also have no "enable", just "enabled"
[19:15:55] <andypugh> jepler: Hmm, that is certainly elegant, though I suspect I would have no idea what it did next time I looked at it. :-)
[19:21:03] <cpresser> thats the commit which change the sysfs-api:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/pci-sysfs.c?id=5136b2da770d53f026ab091f0423729ebf37a6b5
[19:22:11] <cpresser> ill try 3.14-rt again with a symlink from enabled to enable
[19:23:44] <jepler> I doubt you can create a symlink there
[19:23:55] <jepler> you could try with the source modified to spell "enable" as "enabled"
[19:24:14] <cpresser> yeps, but i dont want to recompile yet :)
[19:24:58] <cpresser> damm.. you are right. read-only-fs :/
[19:26:09] <cpresser> could you give me a hint where to change this in linuxcnc?
[19:47:42] <jepler> cpresser: src/rtapi/rtapi_pci.c
[19:47:42] <jepler> - snprintf(path, sizeof(path), "%s/enable", dev->sys_path);
[19:47:49] <jepler> try with "enable" changed to "enabled"
[19:49:07] <cpresser> thx
[19:49:52] <jepler> cpresser: yes I found the same commit after some searching. looks like the semantics of "enabled" will be the same as "enable"
[19:51:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-pci-sysfs-enabled e889b79 06linuxcnc 10src/rtapi/rtapi_pci.cc uspace: compensate for kernel API breakage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e889b79
[19:52:25] <jepler> this branch, which I think will be available from buildbot's "scratch" repo in 1.5 hours or so, is an attempt at fixing it "portably". It still works on my kernel, and should fall back to using the "enabled" file on a system like yours
[19:53:08] <jepler> I didn't test it very hard though
[19:54:46] <jepler> in fact maybe I didn't test it at all
[19:55:06] <jepler> seb_kuzminsky:
[19:55:06] <jepler> hm2/hm2_5i20.0: The hm2 pet_watchdog function is no longer needed.
[19:55:06] <jepler> hm2/hm2_5i20.0: It will be removed before LinuxCNC 2.7.
[19:55:09] <jepler> seb_kuzminsky: is it time?
[20:04:29] <jepler> cpresser: it seems like 3.14 is no longer directly available via apt-get even with wheezy-backports enabled, though the url you gave me does work. rebooting with 3.14-rt to check my own hm2-pci hardware still works
[20:04:33] <jepler> cpresser: thanks for the bug report btw
[20:04:41] <jepler> even if I didn't want to believe it initially
[20:05:52] <jepler> ok, the fix is only a half-fix
[20:09:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/uspace-pci-sysfs-enabled 52bfb20 06linuxcnc 10src/rtapi/rtapi_pci.cc uspace: compensate for kernel API breakage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=52bfb20
[20:09:55] <jepler> I think this one's right
[20:10:01] <jepler> bbl
[20:26:34] <cpresser> jepler: thx for the fast fix
[20:26:56] <cpresser> ill test it tomorrow. its already 2am in germany. need to go to bed.
[20:28:37] <cpresser> btw, I did post a patch for pncconf to the ML earlier.
[20:37:04] <jepler> cpresser: word fom Greg Kroah-Hartman already that yes, it's a bug; he'll produce a patch for stable kernels
[20:37:26] <jepler> http://thread.gmane.org/gmane.linux.kernel/1817337/focus=36499
[21:00:25] <andypugh> That was quick, wasn’t it?
[21:21:49] <cpresser> jepler: so that means that i discovered a kernel bug? thats a first for me :)
[21:28:57] <cpresser> regarding pncconf, I will try to deliver a complete patchset tomorrow (i found 3 issues)
[21:32:03] <seb_kuzminsky> jepler: i'll remove pet_watchdog after i write a note in the Updating to 2.7 document about removing it
[21:32:19] <seb_kuzminsky> i'm planning to put that kind of info in our git docs this time around, instead of on the wiki
[21:44:19] <jepler> andypugh, cpresser: yes and yes
[22:41:53] <skunkworks_> why is it that I think 3.2 should be newer than 3.16?
[22:43:03] <skunkworks_> I don't I can get past it looking like a decimal..
[22:53:11] <Tom_itx> it should :D
