Back
[05:40:47] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz commented on issue #70: On 0614T1922, Jeff Epler wrote:
[08:42:34] <skunkworks> if you do a sim axis and put the axis 5 inches away fro the soft limit - then create an arc that would go past the soft limit in mdi - it will over shoot
[08:42:37] <skunkworks> http://imgur.com/0jRUK4u
[08:42:57] <skunkworks> that is .39" past the soft limit.
[08:43:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-libdl e7804e8 06linuxcnc 10(6 files in 5 dirs) configure: check whether dlopen needs -ldl * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7804e8
[08:43:49] <jepler> skunkworks: not nice :-/
[08:44:04] <skunkworks> probably not something normal people would do...
[08:45:02] <jepler> do you think that .39" is something like the distance it would take to decelerate?
[08:45:13] <jthornton> PCW_: do you have a copy of your config for 4.1.20-rt23?
[08:46:09] <skunkworks> without doing the math - maybe :)
[08:47:23] <skunkworks> when you do a linear movement - it scolds you when you are going to go past the soft limit. maybe arc needs the same checking
[08:47:27] <jepler> I remember someone once noting that soft limits checking of arcs was insufficient and clearly you've discovered a concrete case of that here
[08:47:45] <jepler> I am guessing that neither endpoint of the arc is outside soft limits, so linuxcnc thinks all is OK
[08:47:51] <skunkworks> I can post a bug report
[08:47:57] <jepler> or something else along those lines
[08:47:58] <skunkworks> right - exactly
[08:48:20] <jepler> skunkworks: if you have a good how to reproduce that can be followed interactively with a sim config, absolutely report it. you do github, right?
[08:49:19] <skunkworks> yes
[08:49:29] <skunkworks> the screenshot was sim - so not a problem
[08:50:41] <pcw_home> jthornton: yes
[08:50:43] <pcw_home> http://freeby.mesanet.com/4120config
[08:50:44] <pcw_home> (32 bit so change that if needed)
[08:51:04] <jthornton> all mine are 32 bit, and thanks
[08:51:13] <jepler> the amount of overshoot is clearly dependent on velocity
[08:51:32] <jepler> g0 x0y0 / g2 f1000 i100j100 x0y0
[08:51:38] <jepler> triggers it real good
[08:51:48] <jepler> at f1000 the overshoot is bigger than at f100
[08:51:59] <jepler> .5" at f1000
[08:53:22] <jepler> so yeah I *bet* that motion comes to a controlled stop when you manage to exceed soft limits
[08:54:43] <jepler> somebody needs to change this implementation to a smart implementation:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctaskmain.cc#L502
[09:30:02] <trasz_> ok, i'm back.
[09:30:03] <trasz_> kind of.
[09:30:43] <trasz_> jepler: do you still want me to check the clock_nanosleep() patches, or just skip it and test the posix timers patch instead?
[09:35:05] <jepler> trasz_: hi
[09:35:15] <jepler> trasz_: why not try posix timers first
[09:35:52] <jepler> .. some linux users need to test that branch too, though, to make sure it's good for RT behavior there too
[09:38:18] <jepler> (I would hope that posix timers would behave at least as well as clock_nanosleep(ABSTIME) everywhere, since in a pinch you can implement timers with pretty much just sleep)
[09:42:57] <jepler> afk
[10:41:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz commented on issue #72: On 0615T0614, Jeff Epler wrote:
[11:45:48] <trasz_> jepler: among things i have no idea how to approach is the insmod/rmmod/lsmod detection in configure.in.
[11:46:04] <trasz_> jepler: obviously we don't need those with uspace.
[11:46:45] <trasz_> jepler: but i don't know how to disable the checks when --with-realtime=uspace.
[11:48:47] <jepler> trasz_: hm, I see
[11:52:00] <jepler> can it be as simple as this?
[11:52:01] <jepler> +if test $RTS != "uspace"
[11:52:01] <jepler> +then
[11:52:01] <jepler> AC_PATH_PROG(INSMOD, insmod, "none", $SPATH)
[11:52:01] <jepler> ...
[11:52:04] <jepler> AC_MSG_ERROR([lsmod not found])
[11:52:05] <jepler> fi
[11:52:07] <jepler> +fi
[11:54:16] <jepler> interesting, insmod/rmmod are probed by configure, but it looks like the value used ends up being e.g., $EMC2_BIN_DIR/linuxcnc_module_helper insert
[11:55:58] <jepler> also interesting, debian kfreebsd supplies programs called insmod/rmmod/lsmod from package kldutils
[11:56:37] <seb_kuzminsky> that's very silly
[11:58:28] <trasz_> jepler: hm, could be; i can test this actually.
[12:02:31] <jepler> being a bit more thorough:
https://emergent.unpythonic.net/files/sandbox/0001-configure-simplify-insmod-rmmod-lsmod-detection.patch
[12:02:58] <jepler> trasz_: I dunno if you read scrollback, but 'optind = 1' actually caused a regression on linux that dgarr reported yesterday. it's fixed now.
[12:03:05] <jepler> glibc is just stupid in this case
[12:03:35] <jepler> you can reset optind=1 and it tries to parse freed memory
[12:09:57] <trasz_> jepler: that explains why it was 0 in the first place.
[12:11:59] <jepler> yup
[12:12:01] <trasz_> jepler: ok, so the change you've written above for insmod seems to work on freebsd.
[12:17:20] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-configure-simplify-insmod-rmmod-lsmod-detection.patch not bad for a 1980 computer
https://youtu.be/vaHQ9Lh_8RY?t=116
[12:17:55] <jepler> er ignore the first url this time
[12:34:16] <trasz_> jepler: tbh i prefer the patch, although i am slightly impressed by the fact that people still do this kind of stuff in XXI century.
[12:40:07] <rushabh> Hi, Currently how can we get file being played if subroutines are used ?
[12:40:50] <rushabh> Neither axis nor gmocapy do give us correct information
[12:43:21] <jepler> rushabh: to the best of my knowledge, this information is not available to UIs right now.
[12:44:14] <rushabh> Is it available anywhere ? I can try fetch them out.
[12:46:45] <jepler> no, it's not written yet
[12:50:41] <rushabh> Can I attempt to put effort on this front ?
[12:52:35] <jepler> of course, you don't need anybody's permission to modify linuxcnc.
[12:54:50] <jepler> anyway, I think rs274 would have to notify task with a new API call that it is switching to a different file at entry/return from a subroutine; task would put this information in the stat buffer; the python interface to the stat buffer would be modified so it can return this information to python; and then individual UI programs could decide what to do with this information, such as possibly switch
[12:54:56] <jepler> the displayed text in a widget
[12:55:54] <rushabh> I've never contributed to this community, I'm with linuxcnx since 3 years but never tried to push anything for everyone else.
[12:56:48] <jepler> make sure you read this then:
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html
[12:57:07] <rushabh> Surely I'll
[12:57:31] <jepler> ok, good luck with your project.
[12:58:26] <rushabh> Thank you.
[13:08:31] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #79: Jepler/for master/pippin88 (06master...06jepler/for-master/pippin88) 02
https://github.com/LinuxCNC/linuxcnc/pull/79
[13:39:55] <trasz_> jepler: ok, two more commits for freebsd :-)
[14:12:19] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15samcoinc opened issue #80: MDI of an arc that passes through the soft limit - overshoots soft limits by de-acceleration amount. 02
https://github.com/LinuxCNC/linuxcnc/issues/80
[14:16:13] <jepler> trasz_: which two -- the branch to add rtapi_clock_nanosleep, and configure-simplify?
[14:17:21] <trasz_> jepler: hm, last two, includes and realtime.in.
[14:17:34] <trasz_> jepler: "my" two, in other words.
[14:18:13] <trasz_> geez, things used to be so much simpler in the cvs/svn days.
[14:22:20] <trasz_> hm.
[14:22:40] <trasz_> there's this thing, in src/hal/drivers/hal_gm.c
[14:23:12] <trasz_> clang gives a warning about ref_vel being uninitialized around line 1790.
[14:23:23] <trasz_> because there's no "else" clause that would initialize it.
[14:23:31] <trasz_> not sure what's the right way to fix it.
[14:26:28] <jepler> trasz_: ah I didn't see them yet
[14:26:38] <jepler> 247 hal_bit_t control_type; //0: position, 1: velocity
[14:26:43] <jepler> control_type is effectively a bool
[14:27:16] <jepler> so down here instead of an if == 1 / else if == 0, it should be if(device->stepgen[channel].control_type) {...} else {...}
[14:27:23] <jepler> so that ref_vel is initialized in either case
[14:27:30] <jepler> 1740 else if(device->stepgen[channel].control_type == 0)
[14:28:19] <jepler> 296 typedef volatile bool hal_bit_t;
[14:28:25] <jepler> (in some other file)
[14:29:14] <jepler> so your compiler is right, even if the range of values control_type can hold is {0,1} we have told the compiler that both comparisons could be false
[14:45:05] <jepler> trasz_: ah apparently our bot doesn't notify on irc when commits are added to a pull request
[14:47:05] <trasz_> jepler: yeah, looks like it doesn't.
[14:47:17] <trasz_> jepler: anyway, tbh i wasn't able to figure out where that variable gets assigned to.
[14:47:42] <trasz_> jepler: did a quick and dirty workaround, but it's not something i'd submit as a fix :-)
[14:48:16] <jepler> trasz_: it's a HAL parameter, so it gets assigned by halcmd setp, and defaults to 0 at allocation time (hal_alloc returns zero-initialized storage)
[14:49:44] <trasz_> jepler: hm, okay. how does setp work?
[14:50:49] <jepler> trasz_: all hal components map the same shared memory area, so by modifying the right bytes in it, you can set the value of any parameter
[14:51:36] <trasz_> jepler: so basically, some structure that can be typecast into module-independent structure halcmd can mess with?
[14:52:32] <jepler> yeah there's a hal_param_t for each parameter
[14:52:45] <jepler> so from that you can learn the byte offset in the shared memory area of a parameter by name
[14:52:52] <trasz_> ok.
[14:53:26] <trasz_> anyway - no idea what to do about that one; the only thing i know is that clang fails to build it :-)
[14:53:30] <jepler> so from the point of view of that code in hal_gm.c, .control_type really is set as if by magic at arbitrary times
[14:54:17] <trasz_> apart from that, the freebsd port is getting quite close to being just a bunch of ifdefs and... out-comments?
[14:54:45] <jepler> I'm trying to sort out exactly which commits in your pull request I haven't taken yet
[14:55:08] <trasz_> jepler: i see mostly those two.
[14:55:53] <trasz_> jepler: don't worry if you miss some of the commits; i'll notice it the next time i'll "loop back" stuff, and i'll submit them again.
[14:57:02] <jepler> I think maybe we should just get rid of use of alloca, it looks easy with C99 VLAs
https://emergent.unpythonic.net/files/sandbox/0001-WIP-get-rid-of-use-of-nonportable-alloca.patch
[14:57:23] <jepler> but it does look like <stdlib.h> has the alloca definition/declaration on linux too, even if our manpage says to use <alloca.h>
[14:57:46] <trasz_> jepler: i guess if it's c99 it should just work with clang.
[14:58:05] <jepler> - if [ -z "$($PIDOF rtapi_app)" ]; then
[14:58:06] <jepler> + if [ `$HALCMD -s show comp | wc -l` -eq 2 ]; then
[14:58:26] <trasz_> jepler: the '2' could mandate some comment, i suppose.
[14:58:32] <jepler> is it that pidof works incompatibly on freebsd?
[14:58:39] <trasz_> jepler: it's 1 for the halcmd doing 'show comp', and 1 for a newline.
[14:59:02] <trasz_> jepler: well, one one hand freebsd doesn't have pidof, it has pgrep, but i have a separate patch for that.
[14:59:18] <trasz_> jepler: this one is for the 'shm segment can linger after rtapi_app has exited' problem.
[14:59:47] <trasz_> jepler: basically, instead of checking whether the rtapi_app is running, we check the shmem state.
[15:00:44] <trasz_> jepler: it's not very pretty, but it does the job; i don't quite understand the failure mode of the existing way of doing this, to be honest.
[15:01:01] <trasz_> jepler: some kind of race condition.
[15:02:02] <jepler> I'd like to understand it better too.
[15:03:47] <trasz_> i _think_ it's a race between removing a process from the list of processes - so that ps(1) no longer shows it exits - and destroying its sysv shared memory segments.
[15:05:00] <trasz_> still, the "show comp" actually seems to me as slightly cleaner, as it's less... "indirect".
[15:05:26] <trasz_> i mean, it makes the script query the state directly instead of trying to figure it out based on the rtapi_app process existence.
[15:06:08] <trasz_> perhaps we could even collapse the uspace and non-uspace cases altogether this way.
[15:06:47] <jepler> I don't think it's equivalent
[15:06:49] <jepler> $ pidof rtapi_app
[15:06:49] <jepler> 26583
[15:06:49] <jepler> $ halcmd -s list comp
[15:06:49] <jepler> halcmd26838
[15:07:14] <trasz_> hm.
[15:07:42] <jepler> (I did this by executing rtapi_app in a terminal on its own; it's true that normally it begins running when you halcmd loadrt something)
[15:08:01] <trasz_> ok, but does it actually make a difference?
[15:08:02] <jepler> (hm in this state, 'halcmd unload all' doesn't make it exit either. I should stop looking for trouble)
[15:08:43] <trasz_> i mean, if it's running, but without loadrt, it should be just fine to use it for the next 'loadrt' or whatever you wanted it to do.
[15:08:48] <jepler> $ pidof rtpai_app
[15:08:49] <jepler> $ halcmd -s list comp
[15:08:49] <jepler> halcmd27899 hal_manualtoolchange
[15:09:15] <trasz_> jepler: typo!
[15:09:26] <jepler> this is also something that can happen -- you can have what we confusingly call "userspace" components without rtapi_app going too
[15:10:23] <jepler> what did I typo?
[15:15:38] <trasz_> jepler: 'rtpai_app'
[15:16:18] <jepler> oh
[15:16:30] <jepler> $ pidof rtapi_app
[15:16:30] <jepler> $ halcmd -s list comp
[15:16:31] <jepler> halcmd31698 hal_manualtoolchange
[15:16:59] <KGB-linuxcnc> 03Jeff Epler 05master e7804e8 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7804e8
[15:17:06] <andypugh> Well, that’s that hard and time-consuming part done. Just the debugging and testing now.
[15:17:12] <andypugh> What’s that you say?
[15:18:38] <jepler> hi andypugh glad you're making progress!
[15:19:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep ca2521c 06linuxcnc 10src/configure.in configure: check if clock_nanosleep is available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca2521c
[15:19:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 7ff5d44 06linuxcnc 10src/rtapi/uspace_common.h rtapi_delay: respect rtapi_delay_max, per documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7ff5d44
[15:19:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep c2c9d7d 06linuxcnc 10src/rtapi/rtai_ulapi.c 10src/rtapi/rtapi.h 10src/rtapi/uspace_common.h rtapi: add rtapi_delay{,_max} to ULAPI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2c9d7d
[15:19:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep e8179c2 06linuxcnc 10src/hal/hal_lib.c hal: Use rtapi_delay in stream wait ops * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8179c2
[15:19:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 4f778f1 06linuxcnc 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc uspace: introduce, use rtapi_clock_nanosleep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f778f1
[15:21:04] <andypugh> jepler:
https://imagebin.ca/v/2lEYVE12FOlU
[15:21:23] <KGB-linuxcnc> 03Jeff Epler 05master 4f778f1 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f778f1
[15:22:30] <KGB-linuxcnc> 03Jeff Epler 05master 4a6fe39 06linuxcnc 10src/emc/motion/stashf.c 10src/emc/motion/stashf_wrap.h 10src/hal/utils/scope_disp.c WIP get rid of use of nonportable alloca * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a6fe39
[15:24:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-uspace-insmod 8c67d5a 06linuxcnc 10src/configure.in configure: simplify insmod/rmmod/lsmod detection * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c67d5a
[15:24:38] <jepler> in a day or so when the buildbot catches up, we'll know if that last patch works on all our platforms..
[15:26:40] <trasz_> :-)
[15:26:44] <trasz_> rebase time, i guess.
[15:27:06] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #70: configure: check whether dlopen needs -ldl (06master...06jepler/master/configure-libdl) 02
https://github.com/LinuxCNC/linuxcnc/pull/70
[15:30:29] <jepler> trasz_: yes, perhaps when we are both here I can help walk you through the steps. If done correctly, a rebase will reduce the number of commits you have from upstream/master to your master, but (possibly by following some advice that git printed for you;) whatever you did when you tried to rebase your master branch got you duplicated commits instead
[15:32:42] <trasz_> jepler: i kind of hope the git stash; git pull upstream, git stash pop; git reset will do most of the job; otherwise i'll try to do interactive rebase and delete the commits that got merged.
[15:34:04] <jepler> I believe you'll need to do an interactive rebase
[15:36:54] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/configure-uspace-insmod 3f77a21 06linuxcnc 10src/emc/kinematics/genserkins.c Fix includes for FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f77a21
[15:37:05] <jepler> oops that's not what I intended :-/
[15:37:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-uspace-insmod 8c67d5a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c67d5a
[15:38:51] <jepler> trasz_: missing signed-off-by in those last two commits on your branch
[15:49:36] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master bb257df 06linuxcnc 10src/emc/kinematics/genserkins.c Fix includes for FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb257df
[15:49:49] <jepler> that one is so trivial I just went ahead and put my own sob on it
[15:54:24] <andypugh> Interesting compiler errors on the other channel
[15:54:49] <jepler> is there a logger? I don't even bother lurking there anymore.
[15:55:34] <archivist> http://pastebin.com/raw/YX0yZVPr
[15:56:10] <pcw_home> his own kernel and RTAI 5.0
[15:56:12] <andypugh> I suspect that the problem is: landau: because I compiled a kernel and I have RTAI 5.0
[15:56:13] <andypugh> [9:27pm] landau: kernel version 3.10.32
[15:56:14] <andypugh> [9:27pm] landau: RTAI is from ShabbyX
[15:56:34] <jepler> 79 #if RTAI > 2
[15:56:34] <jepler> 80 #include <rtai_sem.h>
[15:56:35] <jepler> 81 #endif
[15:56:47] <jepler> We expect RTAI to be defined to some number, but instead it's defined to UNOFFICIAL
[15:58:01] <jepler> so that rtai distribution is either buggy or incompatible with linuxcnc
[16:00:18] <CaptHindsight> it's ShabbyX's tree so no longer compatible with Linuxcnc
[16:02:20] <CaptHindsight> https://github.com/NTULINUX/RTAI we keep this RTAI to support our customers with Linuxcnc, rtai.org and shabbyx are not guaranteed to work with anything
[16:04:58] <CaptHindsight> i guess as the devs here make changes to try and get rtai.org working it will break was does work
[16:06:04] <jepler> I don't think anybody has made a pull request for compatibility with these different RTAI trees
[16:07:09] <jepler> but yes, it would need to be possible to work with the RTAI versions that linuxcnc users already have AND with these other trees
[16:07:45] <jepler> if you are aware of anybody who has worked on this, encourage them to make a github pull-request for it
[16:07:52] <jepler> .. I don't need it, so I don't work on it
[16:12:54] <CaptHindsight> NTULINUX is the only tree that is going to work with Linuxcnc
[16:13:32] <CaptHindsight> you're on your own if you choose to use rtai.org or shabbyx
[16:14:28] <CaptHindsight> he spent a year or two cleaning up the mess that was RTAI
[16:16:54] <CaptHindsight> just to be clear, Paolo doesn't give one flying fuck if RTAI works with Linuxcnc
[16:29:41] <cradek> skunkworks:
https://sourceforge.net/p/emc/bugs/130/
[16:30:23] <jepler> 2008 oh yeah
[16:37:48] <cradek> so hitting the soft limit at speed is possible with certain arcs, and on sam's machine it can't stop before making it to the limit switch when that happens
[16:38:31] <cradek> hopefully sam's machine (every machine) is set up to be able to stop *after* hitting the limit switch
[16:39:09] <cradek> > I don't think this has ever worked.
[16:39:13] <cradek> sam is right :-)
[16:39:23] <jepler> otherwise, what do we do, mandate airbags?
[16:39:41] <cradek> rubber bumpers
[16:40:04] <cradek> orange and white striped barrels full of sand
[16:41:29] <cradek> oops you pushed a WIP
[16:45:05] <jepler> cradek: oops
[16:45:07] <jepler> it'll probably be fine
[16:47:12] <jepler> should put in a WIP filter server-side ;-)
[16:50:30] <pcw_home> do the softlimits parse the gcode or are some limits just waypoint by waypoint?
[16:51:44] <cradek> both
[16:53:01] <pcw_home> so the waypoint way should catch sams issue if you subtract the stopping distance
[16:53:53] <KGB-linuxcnc> 05seb/master/contour-driver 2feb1f7 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2feb1f7
[17:07:40] <cradek> true, but to subtract the stopping distance (from the right constraint(s)) you have to know the direction, and if you're going to figure all of that out, you should fix the original bug and not allow the move to start in the first place
[17:08:22] <cradek> the waypoint check is a poor substitute for the analysis before the move starts
[17:11:03] <pcw_home> Sure, but the waypoint check can catch everything
[17:11:25] <seb_kuzminsky> porque no los dos .gif
[17:12:07] <cradek> that's definitely true (it's why we have it as a last resort)
[17:12:27] <cradek> ideally we'd improve both of the things
[17:12:48] <JT-Shop> when using G92 from the current location a reload that cleared the erroneous error would be nice
[17:19:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ba077f5 06linuxcnc 10(19 files in 8 dirs) rename "shuttlexpress" driver to "shuttle" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba077f5
[17:19:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 149d253 06linuxcnc 10src/hal/user_comps/shuttle.c shuttle: make the driver structure more flexible * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=149d253
[17:19:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 22d853a 06linuxcnc 10src/hal/user_comps/shuttle.c shuttle: more internal refactoring * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22d853a
[17:19:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 074b0b6 06linuxcnc 10(9 files in 7 dirs) shuttle: add support for ShuttlePRO * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=074b0b6
[17:19:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9130e35 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: note shuttle driver rename in "updating your config" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9130e35
[17:32:18] <andypugh> I wonder if JA does bettter in the Arc/limit situation?
[17:34:14] <micges> I don't think so
[17:34:31] <andypugh> It’s a joint-space problem. Panic if v^2 > 2as
[17:34:43] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: Your jepler/master/nicokid-stepconf still that based on gtk2. At least that's what I believe. 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-227023311
[17:47:56] <andypugh> This probably counts as a major bug with my multispindle branch: The axes don’t feed if the spindle is running :-)
[17:48:06] <cradek> ha
[17:48:12] <cradek> probably the at-speed logi
[17:48:13] <cradek> c
[17:49:00] <andypugh> Ah, yes, of course.
[17:49:33] <andypugh> Should there be one per spindle, or one master one?
[17:49:59] <cradek> an excellent question
[17:49:59] <andypugh> I think one-per-spindle, but all must be true to feed?
[17:50:15] <andypugh> Or true for any spindle that is moving.
[17:50:20] <cradek> none of those
[17:50:28] <cradek> I think you have to extend the logic that's there
[17:50:39] <cradek> at-speed is only checked at certain times
[17:51:48] <cradek> (this is one of those times where I know a thing is in the docs but can't find it)
[17:51:48] <andypugh> Time to poke around. This is proving to be rather educational about how the bits of LinuxCNC fit together.
[17:52:22] <andypugh> There seems to be at least one messaging layer too many.
[17:52:40] <cradek> aha
http://linuxcnc.org/docs/html/config/core-components.html#sec:motion-pins
[17:52:59] <cradek> that's the spec for the existing logic
[17:53:25] <andypugh> I don’t plan on changing that logic. The question is how to combine multiple inputs.
[17:53:45] <cradek> so I think if you adjust the S of spindle 7 you'd only wait for spindle 7 to be at-speed in those cases
[17:54:07] <andypugh> But I think it is just that all spindles that have a current speed command must be at-speed
[17:54:23] <cradek> that's not how it currently works
[17:54:48] <cradek> becoming not-at-speed will not stop motion unless those certain things happen
[17:54:52] <andypugh> It is for the situation where “all spindles” is just one spindle.
[17:55:36] <cradek> I'm not sure if we understand each other - I'm going to read what you said a few more times
[17:55:57] <linuxcnc-build> build #1681 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1681 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>, Jeff Epler <jepler@unpythonic.net>, John Thornton <bjt128@gmail.com>
[17:56:10] <cradek> what do you mean by: have a current speed command
[17:57:10] <andypugh> If they are turned on.
[17:57:10] <cradek> (I agree with what you said about messaging layers - I think the interplist could be removed)
[17:58:00] <andypugh> Typically a spindle that is off will be at-speed according to the external logic.
[17:59:14] <cradek> true, but I could imagine one of the spindles taking a long time to spin down, during which it would not be at-speed
[17:59:19] <andypugh> And on reflection, I should perhaps trust that. If you stop one spindle and start another, you probably want the first spindle to actually be stopped before you move on. If you _don’t_ want that then you can use HAL logic.
[17:59:52] <andypugh> Yes, so you would drive at-speed with near OR is-off
[17:59:53] <cradek> hm I wonder what the current logic does while spinning down
[18:00:08] <cradek> pretty sure it would allow rapids
[18:00:27] <cradek> since they're allowed while spinning up! which is an important part of the whole idea...
[18:05:06] <andypugh> I think that this is one of those situations where I let the compiler do the work for me, delete the master at-speed and see what complains :-)
[18:05:29] <cradek> that's a really effective tool
[18:05:41] <cradek> and make -k helps a lot
[18:06:15] <andypugh> I spent most of today chasing a bug caused by _not_ deleting the old struct member, and some code was still looking at it.
[18:06:52] <andypugh> (net_spindle_scale was still there in a struct, and equal to zero)
[18:32:03] <andypugh> cradek: Good call, it was exactly that.
[19:02:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/platform-is-supported 84c4f9c 06linuxcnc 10scripts/platform-is-supported platform-is-supported: detect os in a more portable way * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=84c4f9c
[19:34:37] <skunkworks> cradek, heh - wow. Almost the same example..
[19:35:31] <skunkworks> It hit the over-travel - which puts it into estop. No issue
[20:31:49] <linuxcnc-build> build #4240 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/4240 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[20:34:41] <linuxcnc-build> build #4238 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/4238 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[20:42:27] <jepler> hm that test doesn't look good
[20:42:46] <jepler> /home/buildslave/emc2-buildbot/precise-amd64/precise-amd64-sim/build/scripts/realtime: line 116: syntax error near unexpected token `|'
[20:42:49] <jepler> /home/buildslave/emc2-buildbot/precise-amd64/precise-amd64-sim/build/scripts/realtime: line 116: ` if | awk '{print $1}' | grep -x $MOD >/dev/null ; then'
[20:45:09] <linuxcnc-build> build #3449 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/3449 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[20:57:22] <linuxcnc-build> build #2399 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2399 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:00:51] <KGB-linuxcnc> 05jepler/master/configure-uspace-insmod 8c67d5a 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c67d5a
[21:00:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-uspace-insmod f2bfcf3 06linuxcnc 10src/configure.in configure: simplify insmod/rmmod/lsmod detection * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f2bfcf3
[21:09:50] <linuxcnc-build> build #1909 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1909 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:11:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: @nicokid what do you see that makes you believe my branch is still based on gtk2? I ran my branch and your branch and they look the same, and they look different than our "master" branch. 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-227034668
[21:11:41] <linuxcnc-build> build #2399 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2399 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:14:15] <jepler> i wish it would quit calling me a dummy
[21:15:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: @nicokid what do you see that makes you believe my branch is still based on gtk2? I ran my branch and your branch and they look the same, and they look different than our "master" branch.... 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-227034668
[21:18:52] <linuxcnc-build> build #2598 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2598 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:20:18] <linuxcnc-build> build #2433 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/2433 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:26:01] <linuxcnc-build> build #867 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/867 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:29:20] <linuxcnc-build> build #867 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/867 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:32:16] <linuxcnc-build> build #867 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/867 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:35:52] <linuxcnc-build> build #2065 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/2065 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:37:26] <linuxcnc-build> build #867 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/867 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[21:37:27] <linuxcnc-build> build #4252 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4252 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>, dummy
[22:56:56] <KGB-linuxcnc> 03Andrew Kyrychenko 05joints_axes15 a8baf11 06linuxcnc 10docs/man/man9/kins.9 kins.9 document new pin: genhexkins.tool-offset JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a8baf11
[22:57:40] <linuxcnc-build> build #413 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/413 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:09:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 84c4f9c 06linuxcnc 10scripts/platform-is-supported platform-is-supported: detect os in a more portable way * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=84c4f9c
[23:09:00] <KGB-linuxcnc> 05seb/2.6/platform-is-supported 84c4f9c 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=84c4f9c
[23:36:11] <trasz_> jepler: ok, i've added the signed-offs.
[23:36:35] <trasz_> jepler: is there some option i can set somewhere so that it adds it by default?