Back
[00:00:11] <pcw_home> possibly
[00:00:39] <pcw_home> (of course there are speed steps at the servo thread rate also)
[00:01:15] <jepler> maybe you should modify hostmot2 to add 20-40us jitter to step times and see how pronounced a negative effect it can have
[00:06:58] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[00:09:20] <andypugh> Fascintaing:
https://www.youtube.com/watch?v=0hlvhQZIOQw
[00:09:52] <andypugh> If I suddenly became wealthy, I can actually imagine deciding to do a maths degree.
[00:12:00] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:12:04] <pcw_home> hostmot2 can do that already
[00:12:37] -!- mikeh00 has quit [Read error: Connection reset by peer]
[00:12:45] <pcw_home> just set the base frequency down to 50 or 25 KHz
[00:13:24] <pcw_home> (not sure the driver knows how to do this and keep the scaling right)
[00:14:15] -!- pozzoni has quit [Ping timeout: 258 seconds]
[00:20:15] -!- pozzoni has quit [Ping timeout: 264 seconds]
[00:29:15] -!- pozzoni has quit [Ping timeout: 264 seconds]
[00:29:49] <linuxcnc-build> build #406 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/406 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:33:03] -!- andypugh has quit [Quit: andypugh]
[00:33:25] -!- Loetmichel has quit [Ping timeout: 258 seconds]
[00:41:39] -!- taloot has quit [Ping timeout: 260 seconds]
[00:43:46] -!- pozzoni has quit [Ping timeout: 258 seconds]
[00:46:05] -!- yasnak has quit [Read error: Connection reset by peer]
[00:54:15] amnesic is now known as amnesic_away
[00:55:45] -!- oc2k1 has quit [Ping timeout: 246 seconds]
[00:58:39] -!- pozzoni has quit [Ping timeout: 264 seconds]
[00:59:33] -!- Almis90 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[01:05:00] Cromaglious_ is now known as Crom
[01:06:15] -!- pozzoni has quit [Ping timeout: 260 seconds]
[01:09:29] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[01:21:23] -!- pozzoni has quit [Ping timeout: 250 seconds]
[01:28:25] -!- pozzoni has quit [Ping timeout: 260 seconds]
[01:31:52] -!- Servos4ever has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
[01:40:34] -!- pozzoni has quit [Ping timeout: 260 seconds]
[01:47:40] -!- pozzoni has quit [Ping timeout: 250 seconds]
[01:58:39] -!- pozzoni has quit [Ping timeout: 264 seconds]
[02:05:00] -!- asdfasd has quit [Ping timeout: 250 seconds]
[02:10:12] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[02:13:55] -!- pozzoni has quit [Ping timeout: 260 seconds]
[02:26:32] <skunkworks> I managed to mdi a circle - went past the soft limit and hit the over travel switch..
[02:26:43] <skunkworks> I am going to see if I can get it to do it in sim.
[02:26:59] -!- steve_stallings has quit [Ping timeout: 244 seconds]
[02:27:13] <skunkworks> (errored that soft limit was exceeded - but also hit the over travel limit.
[02:27:41] -!- pozzoni has quit [Ping timeout: 250 seconds]
[02:39:29] -!- pozzoni has quit [Ping timeout: 260 seconds]
[02:55:15] -!- pozzoni has quit [Ping timeout: 258 seconds]
[03:08:22] -!- pozzoni has quit [Ping timeout: 272 seconds]
[03:11:12] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[03:12:36] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pippin88 opened pull request #78: Gmoccapy tooltips (06master...06gmoccapy-tooltips) 02
https://github.com/LinuxCNC/linuxcnc/pull/78
[03:17:14] -!- pozzoni has quit [Ping timeout: 272 seconds]
[03:31:23] -!- pozzoni has quit [Ping timeout: 250 seconds]
[03:36:55] -!- dgarr has quit [Quit: Leaving.]
[03:40:52] -!- roycroft has quit [Ping timeout: 258 seconds]
[03:42:27] -!- pozzoni has quit [Ping timeout: 264 seconds]
[03:56:46] -!- KimK [KimK!~Kim__@2600:8803:7a87:9700:4a5b:39ff:fe0b:57d2] has joined #linuxcnc-devel
[03:59:40] -!- pozzoni has quit [Ping timeout: 272 seconds]
[04:00:23] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[04:01:42] -!- justanotheruser has quit [Read error: Connection reset by peer]
[04:02:12] -!- teepee has quit [Ping timeout: 272 seconds]
[04:02:12] teepee_ is now known as teepee
[04:11:42] -!- pozzoni has quit [Ping timeout: 272 seconds]
[04:12:20] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[04:29:44] -!- pozzoni has quit [Ping timeout: 260 seconds]
[04:47:57] -!- pozzoni has quit [Ping timeout: 258 seconds]
[05:12:52] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[05:14:02] -!- Crom has quit [Remote host closed the connection]
[05:14:57] -!- Ralith has quit [Remote host closed the connection]
[05:17:03] -!- CaptHindsight has quit [Quit: Leaving]
[05:24:31] -!- joem_ has quit [Read error: Connection reset by peer]
[05:28:23] -!- toastydeath has quit [Ping timeout: 250 seconds]
[06:07:52] -!- FloppyDisk has quit [Ping timeout: 252 seconds]
[06:13:03] -!- Mathnerd314 has quit [Ping timeout: 264 seconds]
[06:13:51] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[06:22:59] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[06:24:31] -!- sel has quit [Client Quit]
[06:42:16] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[06:49:10] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[07:05:42] -!- skunkworks has quit [Ping timeout: 260 seconds]
[07:14:15] -!- kingarmadillo has quit [Ping timeout: 264 seconds]
[07:15:19] -!- yasnak has quit [Read error: Connection reset by peer]
[07:45:12] -!- Miner_48er has quit [Quit: Leaving]
[07:47:18] -!- mikeh00 has quit [Read error: Connection reset by peer]
[08:15:07] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[08:55:02] -!- yasnak has quit [Read error: Connection reset by peer]
[09:15:31] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[10:14:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz commented on issue #70: On 0614T1922, Jeff Epler wrote:
[10:16:33] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[10:47:52] -!- morbo has quit [Read error: Connection reset by peer]
[11:04:48] -!- morbo has quit [Remote host closed the connection]
[11:09:04] -!- almostworking has quit [Quit: Textual IRC Client: www.textualapp.com]
[11:16:55] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[11:32:25] -!- jefrite has quit [Ping timeout: 244 seconds]
[11:49:34] -!- root-x has quit [Ping timeout: 260 seconds]
[11:50:15] -!- Almis90 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[12:07:06] amnesic_away is now known as amnesic
[12:18:01] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[12:21:23] Guest86 is now known as Loetmichel
[12:31:02] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:34:15] -!- skunkworks has quit [Read error: Connection timed out]
[12:34:40] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:35:22] -!- MrSunshine has quit [Remote host closed the connection]
[12:53:44] -!- Crom has quit [Ping timeout: 260 seconds]
[13:02:54] -!- morbo has quit [Remote host closed the connection]
[13:15:47] <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
[13:15:50] <skunkworks> http://imgur.com/0jRUK4u
[13:16:10] <skunkworks> that is .39" past the soft limit.
[13:16:50] <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
[13:17:02] <jepler> skunkworks: not nice :-/
[13:17:17] <skunkworks> probably not something normal people would do...
[13:18:15] <jepler> do you think that .39" is something like the distance it would take to decelerate?
[13:18:26] <jthornton> PCW_: do you have a copy of your config for 4.1.20-rt23?
[13:18:55] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[13:19:22] <skunkworks> without doing the math - maybe :)
[13:20:36] <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
[13:20:41] <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
[13:20:59] <jepler> I am guessing that neither endpoint of the arc is outside soft limits, so linuxcnc thinks all is OK
[13:21:05] <skunkworks> I can post a bug report
[13:21:11] <jepler> or something else along those lines
[13:21:11] <skunkworks> right - exactly
[13:21:33] <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?
[13:22:32] <skunkworks> yes
[13:22:42] <skunkworks> the screenshot was sim - so not a problem
[13:23:54] <pcw_home> jthornton: yes
[13:23:56] <pcw_home> http://freeby.mesanet.com/4120config
[13:23:58] <pcw_home> (32 bit so change that if needed)
[13:24:17] <jthornton> all mine are 32 bit, and thanks
[13:24:26] <jepler> the amount of overshoot is clearly dependent on velocity
[13:24:45] <jepler> g0 x0y0 / g2 f1000 i100j100 x0y0
[13:24:51] <jepler> triggers it real good
[13:25:01] <jepler> at f1000 the overshoot is bigger than at f100
[13:25:12] <jepler> .5" at f1000
[13:26:36] <jepler> so yeah I *bet* that motion comes to a controlled stop when you manage to exceed soft limits
[13:27:56] <jepler> somebody needs to change this implementation to a smart implementation:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emctaskmain.cc#L502
[13:54:54] Jymmm is now known as Jymmmmmmm
[13:55:06] Jymmmmmmm is now known as Jymmm
[14:03:15] <trasz_> ok, i'm back.
[14:03:17] <trasz_> kind of.
[14:03:56] <trasz_> jepler: do you still want me to check the clock_nanosleep() patches, or just skip it and test the posix timers patch instead?
[14:08:18] <jepler> trasz_: hi
[14:08:28] <jepler> trasz_: why not try posix timers first
[14:09:05] <jepler> .. some linux users need to test that branch too, though, to make sure it's good for RT behavior there too
[14:11:31] <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)
[14:15:01] -!- robin_sz has quit [Quit: Leaving]
[14:16:10] <jepler> afk
[14:20:03] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[14:24:28] -!- [cube] has quit [Ping timeout: 244 seconds]
[14:26:29] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[14:38:21] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[14:45:42] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[14:46:50] -!- teepee has quit [Ping timeout: 244 seconds]
[14:46:51] teepee_ is now known as teepee
[15:15:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz commented on issue #72: On 0615T0614, Jeff Epler wrote:
[15:21:59] -!- ravenlock has quit [Remote host closed the connection]
[15:36:36] Cromaglious_ is now known as Crom
[15:51:56] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[16:16:04] -!- chopper79 has quit [Ping timeout: 244 seconds]
[16:19:01] <trasz_> jepler: among things i have no idea how to approach is the insmod/rmmod/lsmod detection in configure.in.
[16:19:18] <trasz_> jepler: obviously we don't need those with uspace.
[16:19:58] <trasz_> jepler: but i don't know how to disable the checks when --with-realtime=uspace.
[16:21:30] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[16:21:37] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[16:22:00] <jepler> trasz_: hm, I see
[16:25:13] <jepler> can it be as simple as this?
[16:25:14] <jepler> +if test $RTS != "uspace"
[16:25:14] <jepler> +then
[16:25:14] <jepler> AC_PATH_PROG(INSMOD, insmod, "none", $SPATH)
[16:25:15] <jepler> ...
[16:25:18] <jepler> AC_MSG_ERROR([lsmod not found])
[16:25:18] <jepler> fi
[16:25:20] <jepler> +fi
[16:27:29] <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
[16:29:11] <jepler> also interesting, debian kfreebsd supplies programs called insmod/rmmod/lsmod from package kldutils
[16:29:50] <seb_kuzminsky> that's very silly
[16:31:41] <trasz_> jepler: hm, could be; i can test this actually.
[16:35:44] <jepler> being a bit more thorough:
https://emergent.unpythonic.net/files/sandbox/0001-configure-simplify-insmod-rmmod-lsmod-detection.patch
[16:36:11] <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.
[16:36:18] <jepler> glibc is just stupid in this case
[16:36:48] <jepler> you can reset optind=1 and it tries to parse freed memory
[16:41:23] -!- shaun413 has quit [Quit: Connection closed for inactivity]
[16:43:10] <trasz_> jepler: that explains why it was 0 in the first place.
[16:45:12] <jepler> yup
[16:45:15] <trasz_> jepler: ok, so the change you've written above for insmod seems to work on freebsd.
[16:50:33] <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
[16:51:08] <jepler> er ignore the first url this time
[16:53:00] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[17:00:35] -!- Almis90 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[17:06:41] -!- motioncontrol has quit [Quit: Sto andando via]
[17:07:29] <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.
[17:09:39] -!- rushabh [rushabh!~androirc@182.58.213.146] has joined #linuxcnc-devel
[17:10:44] -!- morbo has quit [Remote host closed the connection]
[17:13:20] <rushabh> Hi, Currently how can we get file being played if subroutines are used ?
[17:14:03] <rushabh> Neither axis nor gmocapy do give us correct information
[17:16:34] <jepler> rushabh: to the best of my knowledge, this information is not available to UIs right now.
[17:17:27] <rushabh> Is it available anywhere ? I can try fetch them out.
[17:19:58] <jepler> no, it's not written yet
[17:20:24] amnesic is now known as amnesic_away
[17:23:54] <rushabh> Can I attempt to put effort on this front ?
[17:25:48] <jepler> of course, you don't need anybody's permission to modify linuxcnc.
[17:28:03] <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
[17:28:09] <jepler> the displayed text in a widget
[17:29:08] <rushabh> I've never contributed to this community, I'm with linuxcnx since 3 years but never tried to push anything for everyone else.
[17:30:01] <jepler> make sure you read this then:
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html
[17:30:20] <rushabh> Surely I'll
[17:30:44] <jepler> ok, good luck with your project.
[17:31:39] <rushabh> Thank you.
[17:31:43] -!- micges [micges!~micges@dbv250.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[17:41:44] -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
[17:53:51] -!- kingarmadillo has quit [Ping timeout: 264 seconds]
[18:13:08] <trasz_> jepler: ok, two more commits for freebsd :-)
[18:19:07] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[18:20:49] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[18:21:00] -!- teepee has quit [Ping timeout: 272 seconds]
[18:21:29] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[18:34:26] -!- rushabh has quit [Remote host closed the connection]
[18:42:28] -!- miss0r has quit [Quit: Page closed]
[18:43:49] -!- awallin [awallin!awallin@lakka.kapsi.fi] has joined #linuxcnc-devel
[18:43:51] -!- Gaston|Home1 [Gaston|Home1!~quassel@rosie.office.tw.ly] has joined #linuxcnc-devel
[18:45:21] -!- Khetzal_ [Khetzal_!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[18:45:33] -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
[18:49:26] <jepler> trasz_: which two -- the branch to add rtapi_clock_nanosleep, and configure-simplify?
[18:50:07] -!- humble_sea_bass has quit [*.net *.split]
[18:50:07] -!- MacGalempsy has quit [*.net *.split]
[18:50:07] -!- Ralith has quit [*.net *.split]
[18:50:07] -!- Jymmm has quit [*.net *.split]
[18:50:07] -!- membiblio has quit [*.net *.split]
[18:50:07] -!- wtsmer has quit [*.net *.split]
[18:50:07] -!- Lasper has quit [*.net *.split]
[18:50:07] -!- DaViruz has quit [*.net *.split]
[18:50:07] -!- radish has quit [*.net *.split]
[18:50:07] -!- arekm has quit [*.net *.split]
[18:50:07] -!- mozmck has quit [*.net *.split]
[18:50:07] -!- Reventlov has quit [*.net *.split]
[18:50:07] -!- Gaston|Home has quit [*.net *.split]
[18:50:07] -!- awallin__ has quit [*.net *.split]
[18:50:07] -!- ybon has quit [*.net *.split]
[18:50:07] -!- Khetzal has quit [*.net *.split]
[18:50:07] -!- _methods has quit [*.net *.split]
[18:50:17] radish_ is now known as radish
[18:50:32] -!- radish has quit [Changing host]
[18:50:34] <trasz_> jepler: hm, last two, includes and realtime.in.
[18:50:36] roh_ is now known as roh
[18:50:47] <trasz_> jepler: "my" two, in other words.
[18:51:26] <trasz_> geez, things used to be so much simpler in the cvs/svn days.
[18:54:03] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[18:55:33] <trasz_> hm.
[18:55:53] <trasz_> there's this thing, in src/hal/drivers/hal_gm.c
[18:56:25] <trasz_> clang gives a warning about ref_vel being uninitialized around line 1790.
[18:56:36] <trasz_> because there's no "else" clause that would initialize it.
[18:56:44] <trasz_> not sure what's the right way to fix it.
[18:59:00] -!- mozmck [mozmck!~moses@67.210.159.94] has joined #linuxcnc-devel
[18:59:41] <jepler> trasz_: ah I didn't see them yet
[18:59:51] <jepler> 247 hal_bit_t control_type; //0: position, 1: velocity
[18:59:56] <jepler> control_type is effectively a bool
[19:00:29] <jepler> so down here instead of an if == 1 / else if == 0, it should be if(device->stepgen[channel].control_type) {...} else {...}
[19:00:36] <jepler> so that ref_vel is initialized in either case
[19:00:43] <jepler> 1740 else if(device->stepgen[channel].control_type == 0)
[19:01:32] <jepler> 296 typedef volatile bool hal_bit_t;
[19:01:38] <jepler> (in some other file)
[19:02:27] <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
[19:05:49] amnesic_away is now known as amnesic
[19:17:12] -!- nofxx has quit [Ping timeout: 246 seconds]
[19:18:18] <jepler> trasz_: ah apparently our bot doesn't notify on irc when commits are added to a pull request
[19:20:18] <trasz_> jepler: yeah, looks like it doesn't.
[19:20:30] <trasz_> jepler: anyway, tbh i wasn't able to figure out where that variable gets assigned to.
[19:20:55] <trasz_> jepler: did a quick and dirty workaround, but it's not something i'd submit as a fix :-)
[19:21:29] <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)
[19:22:57] <trasz_> jepler: hm, okay. how does setp work?
[19:24:02] <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
[19:24:50] <trasz_> jepler: so basically, some structure that can be typecast into module-independent structure halcmd can mess with?
[19:25:45] <jepler> yeah there's a hal_param_t for each parameter
[19:25:59] <jepler> so from that you can learn the byte offset in the shared memory area of a parameter by name
[19:26:05] <trasz_> ok.
[19:26:39] <trasz_> anyway - no idea what to do about that one; the only thing i know is that clang fails to build it :-)
[19:26:43] <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
[19:27:30] <trasz_> apart from that, the freebsd port is getting quite close to being just a bunch of ifdefs and... out-comments?
[19:27:58] <jepler> I'm trying to sort out exactly which commits in your pull request I haven't taken yet
[19:28:21] <trasz_> jepler: i see mostly those two.
[19:29:06] <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.
[19:30:15] <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
[19:30:36] <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>
[19:30:59] <trasz_> jepler: i guess if it's c99 it should just work with clang.
[19:31:18] <jepler> - if [ -z "$($PIDOF rtapi_app)" ]; then
[19:31:19] <jepler> + if [ `$HALCMD -s show comp | wc -l` -eq 2 ]; then
[19:31:40] <trasz_> jepler: the '2' could mandate some comment, i suppose.
[19:31:45] <jepler> is it that pidof works incompatibly on freebsd?
[19:31:52] <trasz_> jepler: it's 1 for the halcmd doing 'show comp', and 1 for a newline.
[19:32:15] <trasz_> jepler: well, one one hand freebsd doesn't have pidof, it has pgrep, but i have a separate patch for that.
[19:32:32] <trasz_> jepler: this one is for the 'shm segment can linger after rtapi_app has exited' problem.
[19:32:36] -!- BeachBumPete has quit [Quit: I'm Outta here!!]
[19:33:00] <trasz_> jepler: basically, instead of checking whether the rtapi_app is running, we check the shmem state.
[19:33:57] <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.
[19:34:14] <trasz_> jepler: some kind of race condition.
[19:35:15] <jepler> I'd like to understand it better too.
[19:37:00] <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.
[19:38:14] <trasz_> still, the "show comp" actually seems to me as slightly cleaner, as it's less... "indirect".
[19:38:39] <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.
[19:39:21] <trasz_> perhaps we could even collapse the uspace and non-uspace cases altogether this way.
[19:40:00] <jepler> I don't think it's equivalent
[19:40:02] <jepler> $ pidof rtapi_app
[19:40:02] <jepler> 26583
[19:40:02] <jepler> $ halcmd -s list comp
[19:40:02] <jepler> halcmd26838
[19:40:27] <trasz_> hm.
[19:40:56] <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)
[19:41:14] <trasz_> ok, but does it actually make a difference?
[19:41:16] <jepler> (hm in this state, 'halcmd unload all' doesn't make it exit either. I should stop looking for trouble)
[19:41:57] <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.
[19:42:01] <jepler> $ pidof rtpai_app
[19:42:02] <jepler> $ halcmd -s list comp
[19:42:02] <jepler> halcmd27899 hal_manualtoolchange
[19:42:28] <trasz_> jepler: typo!
[19:42:39] <jepler> this is also something that can happen -- you can have what we confusingly call "userspace" components without rtapi_app going too
[19:43:15] -!- KGB-wlo has quit [Ping timeout: 244 seconds]
[19:43:36] <jepler> what did I typo?
[19:47:41] -!- KGB-wlo [KGB-wlo!~kgb-wlo@174-29-175-163.hlrn.qwest.net] has joined #linuxcnc-devel
[19:48:51] <trasz_> jepler: 'rtpai_app'
[19:49:31] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[19:49:31] <jepler> oh
[19:49:40] -!- newcnc22 has quit [Ping timeout: 272 seconds]
[19:49:43] <jepler> $ pidof rtapi_app
[19:49:43] <jepler> $ halcmd -s list comp
[19:49:43] <jepler> halcmd31698 hal_manualtoolchange
[19:50:12] <KGB-linuxcnc> 03Jeff Epler 05master e7804e8 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7804e8
[19:50:19] <andypugh> Well, that’s that hard and time-consuming part done. Just the debugging and testing now.
[19:50:25] <andypugh> What’s that you say?
[19:50:39] -!- Frank_11 has quit [Ping timeout: 244 seconds]
[19:51:50] -!- gregcnc has quit [Read error: Connection reset by peer]
[19:51:51] <jepler> hi andypugh glad you're making progress!
[19:52:45] <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
[19:52:45] <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
[19:52:45] <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
[19:52:48] <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
[19:52:52] <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
[19:54:17] <andypugh> jepler:
https://imagebin.ca/v/2lEYVE12FOlU
[19:54:36] <KGB-linuxcnc> 03Jeff Epler 05master 4f778f1 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f778f1
[19:55:02] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[19:55:43] <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
[19:57:16] <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
[19:57:51] <jepler> in a day or so when the buildbot catches up, we'll know if that last patch works on all our platforms..
[19:59:53] <trasz_> :-)
[19:59:57] <trasz_> rebase time, i guess.
[20:00:19] -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
[20:03:06] -!- motioncontrol has quit [Quit: Sto andando via]
[20:03:42] <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
[20:05:55] <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.
[20:07:17] <jepler> I believe you'll need to do an interactive rebase
[20:07:37] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[20:10:07] <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
[20:10:18] <jepler> oops that's not what I intended :-/
[20:10:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-uspace-insmod 8c67d5a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c67d5a
[20:12:04] <jepler> trasz_: missing signed-off-by in those last two commits on your branch
[20:22:49] <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
[20:23:02] <jepler> that one is so trivial I just went ahead and put my own sob on it
[20:27:37] <andypugh> Interesting compiler errors on the other channel
[20:28:02] <jepler> is there a logger? I don't even bother lurking there anymore.
[20:28:47] <archivist> http://pastebin.com/raw/YX0yZVPr
[20:29:23] <pcw_home> his own kernel and RTAI 5.0
[20:29:25] <andypugh> I suspect that the problem is: landau: because I compiled a kernel and I have RTAI 5.0
[20:29:26] <andypugh> [9:27pm] landau: kernel version 3.10.32
[20:29:27] <andypugh> [9:27pm] landau: RTAI is from ShabbyX
[20:29:29] amnesic is now known as amnesic_away
[20:29:47] <jepler> 79 #if RTAI > 2
[20:29:47] <jepler> 80 #include <rtai_sem.h>
[20:29:48] <jepler> 81 #endif
[20:30:00] <jepler> We expect RTAI to be defined to some number, but instead it's defined to UNOFFICIAL
[20:31:14] <jepler> so that rtai distribution is either buggy or incompatible with linuxcnc
[20:33:31] <CaptHindsight> it's ShabbyX's tree so no longer compatible with Linuxcnc
[20:34:50] -!- gregcnc has quit [Read error: Connection reset by peer]
[20:35:33] <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
[20:38:11] <CaptHindsight> i guess as the devs here make changes to try and get rtai.org working it will break was does work
[20:39:17] <jepler> I don't think anybody has made a pull request for compatibility with these different RTAI trees
[20:40:22] <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
[20:40:58] <jepler> if you are aware of anybody who has worked on this, encourage them to make a github pull-request for it
[20:41:05] <jepler> .. I don't need it, so I don't work on it
[20:41:49] -!- [cube] has quit [Ping timeout: 252 seconds]
[20:42:42] -!- chupacabra has quit [Ping timeout: 250 seconds]
[20:42:57] -!- [cubert] has quit [Ping timeout: 246 seconds]
[20:46:07] <CaptHindsight> NTULINUX is the only tree that is going to work with Linuxcnc
[20:46:45] <CaptHindsight> you're on your own if you choose to use rtai.org or shabbyx
[20:47:41] <CaptHindsight> he spent a year or two cleaning up the mess that was RTAI
[20:50:07] <CaptHindsight> just to be clear, Paolo doesn't give one flying fuck if RTAI works with Linuxcnc
[20:55:44] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[20:59:58] -!- [cube] has quit [Ping timeout: 272 seconds]
[21:00:05] -!- [cubert] has quit [Ping timeout: 258 seconds]
[21:01:45] -!- PCW__ [PCW__!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[21:02:55] <cradek> skunkworks:
https://sourceforge.net/p/emc/bugs/130/
[21:03:16] -!- PCW_ has quit [Ping timeout: 252 seconds]
[21:03:36] <jepler> 2008 oh yeah
[21:10:20] -!- Deejay has quit [Quit: bye]
[21:11:01] <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
[21:11:44] <cradek> hopefully sam's machine (every machine) is set up to be able to stop *after* hitting the limit switch
[21:12:22] <cradek> > I don't think this has ever worked.
[21:12:26] <cradek> sam is right :-)
[21:12:36] <jepler> otherwise, what do we do, mandate airbags?
[21:12:54] <cradek> rubber bumpers
[21:13:17] <cradek> orange and white striped barrels full of sand
[21:14:42] <cradek> oops you pushed a WIP
[21:16:23] -!- landau has quit [Quit: Page closed]
[21:17:00] -!- motioncontrol has quit [Quit: Sto andando via]
[21:18:18] <jepler> cradek: oops
[21:18:20] <jepler> it'll probably be fine
[21:20:25] <jepler> should put in a WIP filter server-side ;-)
[21:20:49] -!- swarfer has quit [Client Quit]
[21:23:43] <pcw_home> do the softlimits parse the gcode or are some limits just waypoint by waypoint?
[21:24:57] <cradek> both
[21:26:14] <pcw_home> so the waypoint way should catch sams issue if you subtract the stopping distance
[21:27:06] <KGB-linuxcnc> 05seb/master/contour-driver 2feb1f7 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2feb1f7
[21:33:17] Ralith_ is now known as Ralith
[21:40:53] <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
[21:41:35] <cradek> the waypoint check is a poor substitute for the analysis before the move starts
[21:44:16] <pcw_home> Sure, but the waypoint check can catch everything
[21:44:38] <seb_kuzminsky> porque no los dos .gif
[21:45:20] <cradek> that's definitely true (it's why we have it as a last resort)
[21:45:40] <cradek> ideally we'd improve both of the things
[21:46:01] <JT-Shop> when using G92 from the current location a reload that cleared the erroneous error would be nice
[21:52:46] <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
[21:52:47] <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
[21:52:47] <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
[21:52:48] <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
[21:52:52] <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
[21:56:37] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[21:58:31] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[21:59:04] -!- Miner_48er has quit [Quit: Leaving]
[22:00:50] -!- teepee has quit [Ping timeout: 244 seconds]
[22:01:16] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[22:04:10] -!- anth0ny_ has quit [Client Quit]
[22:04:43] -!- wtsmer has quit [Quit: quit]
[22:05:31] <andypugh> I wonder if JA does bettter in the Arc/limit situation?
[22:07:27] <micges> I don't think so
[22:07:44] <andypugh> It’s a joint-space problem. Panic if v^2 > 2as
[22:07:56] -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
[22:21:09] <andypugh> This probably counts as a major bug with my multispindle branch: The axes don’t feed if the spindle is running :-)
[22:21:19] <cradek> ha
[22:21:25] <cradek> probably the at-speed logi
[22:21:26] <cradek> c
[22:22:13] <andypugh> Ah, yes, of course.
[22:22:47] <andypugh> Should there be one per spindle, or one master one?
[22:23:12] <cradek> an excellent question
[22:23:12] <andypugh> I think one-per-spindle, but all must be true to feed?
[22:23:28] <andypugh> Or true for any spindle that is moving.
[22:23:33] <cradek> none of those
[22:23:41] <cradek> I think you have to extend the logic that's there
[22:23:52] <cradek> at-speed is only checked at certain times
[22:25:01] <cradek> (this is one of those times where I know a thing is in the docs but can't find it)
[22:25:01] <andypugh> Time to poke around. This is proving to be rather educational about how the bits of LinuxCNC fit together.
[22:25:35] <andypugh> There seems to be at least one messaging layer too many.
[22:25:53] <cradek> aha
http://linuxcnc.org/docs/html/config/core-components.html#sec:motion-pins
[22:26:12] <cradek> that's the spec for the existing logic
[22:26:38] <andypugh> I don’t plan on changing that logic. The question is how to combine multiple inputs.
[22:26:58] <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
[22:27:20] <andypugh> But I think it is just that all spindles that have a current speed command must be at-speed
[22:27:36] <cradek> that's not how it currently works
[22:28:01] <cradek> becoming not-at-speed will not stop motion unless those certain things happen
[22:28:05] <andypugh> It is for the situation where “all spindles” is just one spindle.
[22:28:49] <cradek> I'm not sure if we understand each other - I'm going to read what you said a few more times
[22:29:10] <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>
[22:29:23] <cradek> what do you mean by: have a current speed command
[22:30:23] <andypugh> If they are turned on.
[22:30:23] <cradek> (I agree with what you said about messaging layers - I think the interplist could be removed)
[22:31:13] <andypugh> Typically a spindle that is off will be at-speed according to the external logic.
[22:32:27] <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
[22:32:32] <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.
[22:33:05] <andypugh> Yes, so you would drive at-speed with near OR is-off
[22:33:06] <cradek> hm I wonder what the current logic does while spinning down
[22:33:21] <cradek> pretty sure it would allow rapids
[22:33:40] <cradek> since they're allowed while spinning up! which is an important part of the whole idea...
[22:38:19] <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 :-)
[22:38:42] <cradek> that's a really effective tool
[22:38:54] <cradek> and make -k helps a lot
[22:39:28] <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.
[22:40:04] <andypugh> (net_spindle_scale was still there in a struct, and equal to zero)
[22:57:28] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[23:01:20] orangey_ is now known as orangey
[23:05:16] <andypugh> cradek: Good call, it was exactly that.
[23:30:27] amnesic_away is now known as amnesic
[23:35:25] <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
[23:52:56] -!- Komzzpa has quit [Ping timeout: 250 seconds]
[23:58:15] -!- andypugh has quit [Quit: andypugh]
[23:58:20] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[23:59:34] -!- eeriegeek has quit [Read error: Connection reset by peer]