Back
[00:06:06] -!- teepee has quit [Ping timeout: 244 seconds]
[00:08:05] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[00:17:54] -!- jthornton- [jthornton-!~john@198.45.191.246] has joined #linuxcnc-devel
[00:17:54] -!- JT-Shopp [JT-Shopp!~john@198.45.191.246] has joined #linuxcnc-devel
[00:17:55] -!- JT-JA13- [JT-JA13-!~john@198.45.191.246] has joined #linuxcnc-devel
[00:17:55] -!- jthornton has quit [Read error: Connection reset by peer]
[00:17:55] -!- JT-Shop has quit [Read error: Connection reset by peer]
[00:17:56] -!- JT-JA13 has quit [Read error: Connection reset by peer]
[00:18:52] -!- Tom_Lab has quit [Quit: Leaving]
[00:48:25] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:55:44] -!- tobias47n9e__ has quit [Ping timeout: 276 seconds]
[01:14:29] md2 is now known as Guest58005
[01:15:50] -!- zephyr9900 [zephyr9900!~john@cpe-72-128-90-199.wi.res.rr.com] has joined #linuxcnc-devel
[01:16:32] -!- md-2 has quit [Ping timeout: 276 seconds]
[01:27:04] -!- zephyr9900 has quit [Quit: Ex-Chat]
[01:37:41] -!- jthornton- has quit [Read error: Connection reset by peer]
[01:37:41] -!- JT-JA13- has quit [Read error: Connection reset by peer]
[01:37:41] -!- JT-Shopp has quit [Read error: Connection reset by peer]
[01:38:14] -!- JT-JA13- [JT-JA13-!~john@198.45.191.246] has joined #linuxcnc-devel
[01:38:15] -!- jthornton- [jthornton-!~john@198.45.191.246] has joined #linuxcnc-devel
[01:38:15] -!- JT-Shopp [JT-Shopp!~john@198.45.191.246] has joined #linuxcnc-devel
[01:49:36] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[01:55:47] <skunksleep> Rigid tapping works in air... (Using the gear tooth sensors)
[01:57:55] <skunksleep> Ran into the 'too many turns before stopping' issue at 2000rpm... ;)
[01:59:38] <skunksleep> Certainly puts linuxcnc in an odd spot
[02:35:03] -!- noser has quit [Ping timeout: 240 seconds]
[02:35:40] -!- skunksleep has quit [Ping timeout: 252 seconds]
[02:51:00] -!- pandeiro has quit [Remote host closed the connection]
[03:37:32] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has joined #linuxcnc-devel
[03:38:25] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:41:12] -!- ktchk has quit [Read error: Connection reset by peer]
[03:54:04] -!- remstw has quit [Ping timeout: 240 seconds]
[03:59:20] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has joined #linuxcnc-devel
[04:03:18] -!- ktchk has quit [Client Quit]
[04:51:33] -!- beawesomeinstead has quit [Ping timeout: 240 seconds]
[05:27:07] -!- kwallace [kwallace!~kwallace@162.222.30.12] has parted #linuxcnc-devel
[05:38:40] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has joined #linuxcnc-devel
[05:39:36] -!- ktchk has quit [Client Quit]
[05:42:32] -!- Miner_48er has quit [Ping timeout: 265 seconds]
[05:59:08] -!- ve7it has quit [Remote host closed the connection]
[06:28:32] -!- JT-JA13- has quit [Read error: Connection reset by peer]
[06:28:57] -!- JT-JA13- [JT-JA13-!~john@198.45.191.246] has joined #linuxcnc-devel
[06:54:56] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has joined #linuxcnc-devel
[07:24:09] -!- Mathnerd314 has quit [Ping timeout: 268 seconds]
[07:39:26] -!- JT-JA13- has quit [Read error: Connection reset by peer]
[07:40:23] -!- JT-JA13- [JT-JA13-!~john@198.45.191.246] has joined #linuxcnc-devel
[08:00:32] -!- Komzpa has quit [Ping timeout: 250 seconds]
[08:10:05] <pink_vampire> hi
[08:19:25] -!- gaute has quit [Quit: Page closed]
[08:22:03] -!- skunksleep has quit [Ping timeout: 240 seconds]
[08:54:06] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:49:37] -!- skunksleep has quit [Ping timeout: 252 seconds]
[09:58:14] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has parted #linuxcnc-devel
[10:00:07] jthornton- is now known as jthornton
[10:14:39] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[11:03:07] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has joined #linuxcnc-devel
[11:10:21] -!- ktchk [ktchk!~eddie6929@n219079127182.netvigator.com] has parted #linuxcnc-devel
[12:15:40] -!- Komzpa has quit [Quit: Konversation terminated!]
[12:34:28] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:43:16] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:43:18] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[12:43:26] <skunkworks> zlog
[12:43:26] <zlog_> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-05-05.html
[12:44:51] -!- sel has quit [Client Quit]
[13:39:24] <skunkworks> stupid question - when say a thread is looking for an input - how long does it scan? does it scan the whole period?
[13:39:49] <skunkworks> (say the encoder hal componant)
[13:40:32] <seb_kuzminsky> the encoder samples its inputs instantaneously when it runs
[13:40:42] <archivist> scan, methinks a nanosecond peek
[13:40:56] <seb_kuzminsky> yeah
[13:41:17] <seb_kuzminsky> it reads once when the component's function runs, then ignores the input until the next time the function runs
[13:41:17] <skunkworks> ha
[13:41:19] <skunkworks> ah
[13:42:07] <seb_kuzminsky> the comp might access its input pin multiple times during the function's run, each one is a separate sampling of the input
[13:42:16] <archivist> it is what I hate about software polling
[13:42:47] <seb_kuzminsky> yeah that's a drawback for sure
[13:46:20] <pcw_home> doesn't the encoder hal component work on static data? (sampled just once by the parport read function)
[13:53:26] <JT-Shopp> yea gantry homing is working on dgar_home_something based on ja
[13:53:49] JT-Shopp is now known as JT-Shop
[13:55:28] <JT-Shop> now to figure out what I did on this pc so apt-get install could find mesaflash and didn't do on the other pc's
[13:56:14] <JT-Shop> I bet it is deb
http://linuxcnc.org/ precise base 2.7-rtai
[13:56:47] <seb_kuzminsky> JT-Shop: yeah, mesaflash is in the "base" component of each supported dist in our debian archive
[13:57:26] <JT-Shop> thanks
[13:57:51] <seb_kuzminsky> pcw_home: you're right, of course: the parport.N.read samples the pins, then the encoder uses those sampled values until next time the parport comp reads them
[14:02:35] <seb_kuzminsky> hm, our hal_parport component is lacking a manpage
[14:05:41] <seb_kuzminsky> we have asciidocs on the parport comp, just no manpage,
http://linuxcnc.org/docs/2.7/html/hal/parallel-port.html
[14:09:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #58: Add a manpage for the hal_parport component 02
https://github.com/LinuxCNC/linuxcnc/issues/58
[14:10:10] -!- kwallace [kwallace!~kwallace@162.222.30.12] has joined #linuxcnc-devel
[14:14:45] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[14:19:45] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:21:25] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[14:21:50] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:22:25] -!- skunkworks has quit [Ping timeout: 252 seconds]
[14:25:50] -!- teepee has quit [Ping timeout: 244 seconds]
[14:28:16] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[14:45:28] <skunkworks_> jepler, so far so good powering the 7i92 differently. (usb instead of wall wart)
[14:51:55] <skunkworks_> seems to be staying at about 180us over 24 hours (tmax servo period)
[14:52:25] <skunkworks_> (626808/3.4ghz)
[15:34:29] -!- mozmck has quit [Quit: Leaving.]
[15:35:31] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[15:40:04] -!- ktchk [ktchk!~eddie6929@n219079181044.netvigator.com] has joined #linuxcnc-devel
[15:48:50] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[15:56:38] -!- JT-JA13- has quit [Quit: Leaving]
[15:56:56] <seb_kuzminsky> how you set rtapi's msg_level in uspace?
[15:57:35] <skunkworks_> where does the initial messages get put when debian is booting? Like where it says the drive is clean
[15:57:44] <seb_kuzminsky> uspace_rtapi_app doesn't read the ini so it doesnt even know what [EMC]DEBUG is
[15:57:48] <skunkworks_> there is a message after that that I cannot catch
[15:58:35] <seb_kuzminsky> skunkworks_: install bootlogd
[15:59:25] <jepler> seb_kuzminsky: I don't think you can
[15:59:45] <seb_kuzminsky> bummer
[15:59:46] <cradek> I've always just edited the code :-/
[15:59:50] <skunkworks_> Hmm I think I found it. The error was Error not error. Grep'ed it
[16:00:28] <skunkworks_> 'pcspkr' is already registered, aborting.
[16:00:37] * seb_kuzminsky hands skunkworks_ 'grep -i'
[16:01:06] * skunkworks_ takes it and promptly forgets it.
[16:01:24] <skunkworks_> cradek, did you see my rigid tapping comment last night?
[16:01:34] <cradek> nope
[16:01:42] <jepler> 20:55:47 <skunksleep> Rigid tapping works in air... (Using the gear tooth sensors)
[16:01:45] <jepler> 20:57:55 <skunksleep> Ran into the 'too many turns before stopping' issue at 2000rpm... ;)
[16:01:48] <jepler> 20:59:38 <skunksleep> Certainly puts linuxcnc in an odd spot
[16:01:48] <cradek> yay
[16:01:51] <cradek> boo
[16:01:53] <cradek> yeah
[16:02:06] <skunkworks_> it seems you have to exit to set it right
[16:02:23] <skunkworks_> but 69 teeth seems smooth enough
[16:02:46] <skunkworks_> and the index works
[16:02:50] <cradek> eww, exiting is unfortunate
[16:02:59] <cradek> I guess that's a bug
[16:03:34] <skunkworks_> I was thinking I could issue a bug report with sim example (really slow accelleration of the virtual spindle)
[16:04:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #59: make it easier to change uspace rtapi_app 02
https://github.com/LinuxCNC/linuxcnc/issues/59
[16:05:06] <jepler> what's the way to do it with RTAI realtime?
[16:05:13] <cradek> something in /proc
[16:06:03] <seb_kuzminsky> yeah that's not great either
[16:06:09] <jepler> #if defined( CONFIG_PROC_FS ) && LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)
[16:06:12] <jepler> #define RTAPI_USE_PROCFS
[16:06:19] <jepler> and it also doesn't work with kernels from this decade
[16:06:35] <jepler> "Linux 3.10 has been released on Sun, 30 Jun 2013. "
[16:07:06] <seb_kuzminsky> maybe Motion could handle the msg_level of the realtime context, and we could set it via a new nml command
[16:07:19] <seb_kuzminsky> task would initialize it at startup
[16:07:31] <jepler> Committer: Jeff Epler <jepler@unpythonic.net> Sun Aug 24 11:58:49 2014
[16:07:31] <jepler> rtapi: disable /proc for kernel 3.10+
[16:07:46] <jepler> seb_kuzminsky: or if 'halcmd' could do it somehow
[16:08:00] <seb_kuzminsky> like with a pin? that'd work too
[16:08:01] <jepler> is it a bug that there's no way to do it for a non-realtime componet too?
[16:08:18] <seb_kuzminsky> mmmaybe
[16:13:03] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #59: RTAI's realtime logging is controlled through /proc, which is also awkward.... 02
https://github.com/LinuxCNC/linuxcnc/issues/59#issuecomment-217198056
[16:13:15] -!- sel has quit [Quit: Leaving]
[16:16:46] <mozmck> Where is this logging logged?
[16:17:14] <seb_kuzminsky> in uspace it goes to stdout (and maybe stderr)
[16:17:18] <seb_kuzminsky> in rtai it goes to dmesg
[16:17:20] <mozmck> One thing I did here was modify show_errors.tcl to not show dmesg output.
[16:27:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #59: .. and that /proc code is disabled for kernels 3.10 and greater too 02
https://github.com/LinuxCNC/linuxcnc/issues/59#issuecomment-217201593
[16:47:58] -!- ktchk has quit [Read error: Connection reset by peer]
[17:51:24] -!- Komzpa has quit [Ping timeout: 246 seconds]
[18:05:42] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[18:42:45] -!- kwallace [kwallace!~kwallace@162.222.30.12] has parted #linuxcnc-devel
[18:44:28] <seb_kuzminsky> urgh
[18:45:04] <seb_kuzminsky> motion's checkAllHomed() is broken, but if i fix it, it exposes a bug in Axis :-(
[18:45:53] <seb_kuzminsky> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/command.c#L85
[18:46:33] <seb_kuzminsky> at startup, motion knows how many joints there are, but none of them have been set to "active" yet, so the allHomed flag gets set even though none of the joints are homed
[18:46:52] <seb_kuzminsky> the flag only gets cleared on unhome, not on joint activation, so it never gets cleared
[18:48:29] <seb_kuzminsky> then, on EMCMOT_COORD or EMCMOT_TELEOP (
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/command.c#L478), it always looks like checkAllHomed() passed, even when it shouldnt have
[18:49:34] <seb_kuzminsky> Axis sometimes wants the interpreter variables synced, and it uses task mode switch (which causes motion mode switch) to trigger var-file write as a side effect:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/scripts/axis.py#L1097
[18:49:50] <seb_kuzminsky> this happens, for example, when loading the splash-screen gcode, long before any homing has happened
[18:50:27] <seb_kuzminsky> if i fix checkAllHomed(), Motion rightfully complains about Axis switching it to coord/teleop at startup
[18:50:42] <seb_kuzminsky> bugs upon bugs
[18:51:28] <seb_kuzminsky> i guess i'll... add a Task NML command to sync the vars file without any weird side effects, switch Axis to use that, then fix checkAllHomed() (by removing emcmotDebug->allHomed entirely)
[18:51:37] <seb_kuzminsky> unless someone sees a better way
[18:52:23] <seb_kuzminsky> the thing that set me on this goose chase was a 2-line change to motion to switch from Free to Teleop when the last joint finishes homing, fwiw
[18:54:30] -!- teepee has quit [Ping timeout: 244 seconds]
[18:56:06] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[18:56:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing f37f7b5 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/motion_debug.h remove the useless and broken emcmotDebug->allHomed flag * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f37f7b5
[18:56:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing 609d7ff 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c motion: move handling of EMCMOT_TELEOP to a function, for reuse * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=609d7ff
[18:56:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing f0b1089 06linuxcnc 10src/emc/motion/homing.c motion: switch to Teleop mode when the final joint finishes homing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f0b1089
[18:56:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja13-teleop-after-homing 7b79ac7 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py FIXME: add a bug note to Axis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b79ac7
[18:56:43] <seb_kuzminsky> it's based on ja13, but it's the same in master
[19:10:22] -!- kwallace [kwallace!~kwallace@162.222.30.12] has joined #linuxcnc-devel
[19:13:19] -!- mozmck has quit [Ping timeout: 260 seconds]
[19:17:58] <linuxcnc-build> build #4082 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/4082 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:18:45] <linuxcnc-build> build #4084 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/4084 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:37] <linuxcnc-build> build #3293 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/3293 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:38] <linuxcnc-build> build #2242 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/2242 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:51] <linuxcnc-build> build #1753 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/1753 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:22:18] <linuxcnc-build> build #2243 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/2243 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:24:06] <linuxcnc-build> build #2439 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/2439 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:24:23] <linuxcnc-build> build #710 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/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:24:35] <linuxcnc-build> build #710 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/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:24:58] <seb_kuzminsky> well that didnt work
[19:25:10] <linuxcnc-build> build #710 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/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:25:25] <linuxcnc-build> build #710 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/710 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:26:19] <linuxcnc-build> build #1908 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/1908 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:31:08] <linuxcnc-build> build #2276 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/2276 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:31:09] <linuxcnc-build> build #4096 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4096 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:34:00] <JT-Shop> YIKES
[19:38:06] -!- JT-JA13 [JT-JA13!~john@198.45.191.246] has joined #linuxcnc-devel
[19:40:30] <JT-JA13> testing Dewey's homing branch based on JA and if I set my HOME_SEARCH_VEL = 0.1 and my HOME_LATCH_VEL = 0.05 I get Home switch active before start of latch move
[19:41:07] <JT-JA13> I remember Andy saying something once about needing more search velocity for certain homing
[19:41:39] <JT-JA13> So I tried HOME_SEARCH_VEL = 0.5 and HOME_SEARCH_VEL = 0.5 and it worked
[19:47:13] -!- mozmck [mozmck!~moses@67.210.159.94] has joined #linuxcnc-devel
[19:47:15] <seb_kuzminsky> JT-JA13: that sounds like a bug
[19:48:18] <JT-JA13> I also tested in 2.7.4
[19:48:40] <JT-JA13> just to make sure it was in both
[19:49:07] * JT-JA13 goes to fix the tractor I hope
[20:04:19] -!- kingarmadillo has quit [Ping timeout: 265 seconds]
[20:14:02] <seb_kuzminsky> zlog_:
[20:14:03] <zlog_> seb_kuzminsky: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-05-05.html
[20:14:46] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #60: homing bug in 2.7.4 02
https://github.com/LinuxCNC/linuxcnc/issues/60
[20:44:03] -!- noser has quit [Ping timeout: 240 seconds]
[21:16:46] -!- pandeiro has quit [Remote host closed the connection]
[21:35:25] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[21:47:08] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:5cf9:c1b6:3f97:5186] has joined #linuxcnc-devel
[21:52:00] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:5cf9:c1b6:3f97:5186] has parted #linuxcnc-devel
[21:53:44] -!- rob_h [rob_h!~robh@94.0.120.220] has joined #linuxcnc-devel
[22:01:21] -!- Miner_48er has quit [Quit: Leaving]
[22:13:23] -!- chillly has quit []
[22:13:27] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 14d06d8 06linuxcnc 10src/emc/motion/homing.c homing.c provision to sync final move to home JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14d06d8
[22:13:27] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 55b81ce 06linuxcnc 10docs/src/config/ini-config.txt 10docs/src/config/ini-homing.txt 10docs/src/getting-started/updating-linuxcnc.txt docs homing: udate for negative HOME_SEQUENCEs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=55b81ce
[22:13:27] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 d8c891a 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py always joint mode for unhome defs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d8c891a
[22:24:31] <seb_kuzminsky> we should definitely switch to joint mode after unhoming, but i think that should happen in Motion, not in the GUI
[22:36:55] <mozmck> For a gantry, it should never be in joint mode.
[22:40:19] <mozmck> That's one thing I like about gantry.comp - it's not possible to get it into a mode where it moves or jogs one side independently of the other - except when homing. And no gui support needed.
[22:41:33] -!- noser has quit [Ping timeout: 240 seconds]
[22:44:17] <seb_kuzminsky> everyone has to home in joint mode
[22:44:25] <seb_kuzminsky> so if you're not homed, you should be in joint mode
[22:44:25] <seb_kuzminsky> imo
[22:45:06] <seb_kuzminsky> having motion switch to teleop immediately after it finishes homing seems like the best we can do
[22:52:33] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[22:53:51] <PCW> looks like its possible to get < 0.1 mill accuracy at 20 IPS 1/2 G with ~ 1 packet /5 seconds lost
[22:53:53] <PCW> just by PID tuning (eth-packet-loss branch)
[22:53:54] <PCW> Could do better if the PID comp could be taught to "vamp-til-ready"
[22:55:34] <PCW> (freeze output until valid position FB data)
[23:02:43] <mozmck> seb_kuzminsky: if a gantry machine is not homed, jogging should still always move both sides together.
[23:03:14] <seb_kuzminsky> mozmck: interesting!
[23:03:46] <cradek> ... unless you want to move them independently, right?
[23:03:56] <mozmck> So I think there should be a way to make it so motion only switches to joint mode while homing, and back to teleop otherwise.
[23:04:02] <cradek> heh always unless that's not what you want
[23:04:04] <JT-Shop> dgarr got jogging in joint mode to obey the jog slider for those times when you need to jog for maintenance etc.
[23:04:15] <seb_kuzminsky> i've been totally stuck in the current assumption that joint-mode jogging is always in free mode, where each joint is totally independent of all others
[23:04:39] <cradek> can you jog in world before homing?
[23:04:52] <cradek> and, um, regardless of that, should you be able to?
[23:05:15] <mozmck> Well, for any gantry I've seen (and that's about all we deal with), you never jog a side independently. Homing will remove any racking that might happen accidentally.
[23:05:24] <seb_kuzminsky> i think you can't switch non-identity kins to teleop/world mode unless you're homed
[23:05:35] <cradek> seb_kuzminsky: oh right!
[23:05:35] <seb_kuzminsky> i was just nosing around in that code
[23:05:41] <mozmck> What is the difference between world and teleop again?
[23:05:46] <seb_kuzminsky> same thing
[23:05:48] <mozmck> ok
[23:06:15] <seb_kuzminsky> there is no world mode, there is only teleop, but world mode has a more obvious meaning, so we sometimes use that word instead
[23:06:15] <cradek> "teleoperating" is what emc1 called manual jog-like motion in world mode
[23:06:42] <mozmck> A gantry is essentially one joint with two motors - unlike a robot.
[23:06:46] <cradek> it didn't have wheel or incremental motion, and in linuxcnc/ja it's very much now just like jogging
[23:06:58] <andypugh> “teleoperarting” is what I do when I turn on the TV
[23:07:07] <cradek> ... so it's an old term I don't use because I think it's unclear
[23:07:09] -!- teepee has quit [Ping timeout: 244 seconds]
[23:07:24] <seb_kuzminsky> i didn't realize how much i loved incremental jogging until i didn't have it (on our gantry machine)
[23:07:27] <mozmck> ok, world mode does make more sense
[23:08:13] <seb_kuzminsky> i can imagine a gantry that's somehow gotten skewed, and wanting to manually jog one of the joints to square it up a little, manually, before homing to fix it for real
[23:08:53] <andypugh> We should call them joint mode and axis mode :-)
[23:08:56] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[23:09:01] <seb_kuzminsky> andypugh: +1
[23:09:16] <mozmck> Well, if it gets really out of whack - which rarely occurs - we simply power off the motors and it will self adjust mostly, or you can do it by hand.
[23:09:38] <mozmck> yeah, +1 here!
[23:10:03] <andypugh> (Actually, joint mode and cartesian mode might cause less confusion. Except if usig polar coordinates)
[23:10:23] <mozmck> My thought is that it could be an option. Those who want the ability to jog each side could set things that way.
[23:11:41] <mozmck> The problem is that if the machine is ever in a state where you can jog one side, then people will go to jog and can damage the gantry quickly.
[23:12:26] <mozmck> I just got one of these in:
http://vocore.io/wiki/index Now I need to figure out something to do with it!
[23:12:47] <seb_kuzminsky> mozmck: i'm having a hard time thinking about what you're suggesting
[23:13:31] <mozmck> :-) Well, except for the acceleration issue, the gantry component is perfect.
[23:14:02] <seb_kuzminsky> i think you're talking about three manual modes now: free/joint like we have now, teleop/world/axis like we have now, and a new one where you run through kins (to enfore joint relationships) but you're not homed?
[23:14:22] <JT-JA13> this is cool you can set your home offset to different values when the switches are not perfect
[23:14:43] <andypugh> JT-JA13: In what?
[23:14:43] <seb_kuzminsky> JT-JA13: yeah, that's a great software hack :-)
[23:15:09] <JT-JA13> in dgarr_home_final which is from ja13
[23:15:26] <seb_kuzminsky> but it means you can't use the synchronized-homing trick to maintain/improve squareness throughout the homing sequence
[23:15:32] <andypugh> I seem to recall that non-identical index locations and home-to-index was a real bug-bear of the last time we talked about this.
[23:15:38] <JT-JA13> I've tried every homing test I can think of
[23:17:06] <seb_kuzminsky> andypugh: yeah, i think you'd have to make the hardware be tuned to communicate when it's square, using home switches and index pulses and things, in order to make that work as intended
[23:17:21] <JT-JA13> as near as I can tell all it does is not move to the home position until all joints with - are homed
[23:17:46] <mozmck> In my thinking, motion could go into joint mode when it starts homing, and otherwise would be in world mode. I'm not sure how kins plays in with such a case right now.
[23:18:08] <mozmck> bbl
[23:18:35] <seb_kuzminsky> mozmck: non-identity kins won't let you switch to world mode wiuthout homing
[23:18:54] <JT-JA13> all the joints with a home sequence that is -n home at the same time
[23:19:09] <JT-JA13> the first one just waits for the rest to home
[23:19:43] <JT-JA13> so it is as synchronized as you can get until you home all the joints on that axis
[23:19:58] <seb_kuzminsky> JT-JA13: and they wait after latching the home switch, before doing the final traverse to the home location?
[23:20:06] <JT-JA13> yes
[23:20:19] <JT-JA13> so you can have the home location anywhere
[23:20:23] <seb_kuzminsky> right
[23:20:59] <andypugh> I am still curious what the home function in all the kins modules is for.
[23:21:12] <JT-JA13> I had an encoder adapter for a nema 17 but used the encoder on the BP spindle
[23:21:45] <seb_kuzminsky> but if the home switches are in locations that don't indicate "square", then the gantry would have no choice but to rack a bit during any kind of synchronized-home/home-final scheme, right?
[23:21:55] <seb_kuzminsky> andypugh: no clue!
[23:22:24] <JT-JA13> that sounds right
[23:22:41] <andypugh> seb_kuzminsky: I wonder who would know?
[23:22:48] <seb_kuzminsky> i've sometimes daydreamed about letting kins control homing, instead of having motion do it in free mode (optionally with some joints homing simultaneously)
[23:22:57] <seb_kuzminsky> seb_kuzminsky: "git blame"
[23:23:01] <seb_kuzminsky> err, andypugh
[23:23:22] <seb_kuzminsky> a stewart platform, for example, needs kins-aware homing
[23:23:42] <seb_kuzminsky> bbl
[23:23:57] <JT-JA13> time to cook!
[23:24:03] <seb_kuzminsky> yep :-)
[23:24:04] <JT-JA13> bbitm
[23:24:50] -!- rob_h has quit [Ping timeout: 250 seconds]
[23:47:29] <PCW> Lesson of the day, never let the stepgens PID loop output be acceleration limited (by stepgen maxaccel)
[23:47:29] -!- logger[psha] has quit [Ping timeout: 260 seconds]
[23:48:44] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel