Back
[00:00:02] -!- vladimirek has quit [Remote host closed the connection]
[00:00:57] -!- Nick001-shop has quit [Remote host closed the connection]
[00:13:15] -!- tmcw has quit [Ping timeout: 248 seconds]
[00:13:52] -!- thomaslindstr_m has quit [Remote host closed the connection]
[00:18:58] -!- PCW has quit [Remote host closed the connection]
[00:30:29] -!- rob_h has quit [Ping timeout: 248 seconds]
[00:35:20] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.20/20130803195701]]
[00:39:19] -!- joebog has quit [Quit: Page closed]
[00:41:16] -!- andypugh has quit [Quit: andypugh]
[00:46:45] -!- geografa has quit [Quit: Computer has gone to sleep.]
[00:48:59] -!- skunkworks has quit [Ping timeout: 248 seconds]
[00:53:58] -!- gabewillen [gabewillen!~gabewille@24-216-213-91.dhcp.stls.mo.charter.com] has joined #linuxcnc-devel
[00:55:48] -!- adb has quit [Ping timeout: 252 seconds]
[00:56:38] -!- toastyde1th has quit [Ping timeout: 264 seconds]
[01:02:39] <memleak> gabewillen, hello!
[01:06:35] -!- tmcw has quit [Remote host closed the connection]
[01:20:38] -!- c-bob has quit [Ping timeout: 240 seconds]
[01:24:21] -!- syyl-- has quit [Read error: Connection reset by peer]
[01:31:41] -!- jfire has quit [Ping timeout: 245 seconds]
[01:42:03] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[01:42:06] -!- kanzure has quit [Ping timeout: 245 seconds]
[02:10:03] -!- AR__ has quit [Ping timeout: 252 seconds]
[02:12:53] -!- The_Ball has quit [Ping timeout: 248 seconds]
[02:16:18] -!- zzolo has quit [Quit: zzolo]
[02:41:48] -!- Laremere has quit [Ping timeout: 240 seconds]
[02:42:20] <kwallace1> It looks like a work offset table lives in interp_convert (or something similar) and there is a work offset table in emc.var. When LinuxCNC loads emc.var gets loaded into the interp table. Then I could change the interp table with MDI or run a G-code file, or I could edit emc.var. So it seems the two tables can be the same or different at different times.
[02:44:30] -!- tlab has quit [Read error: Connection reset by peer]
[02:45:16] <cradek> yes if you edit emc.var yourself, you're going to get bitten.
[02:45:37] <kwallace1> I have always just used the touch off feature and looked at emc.var to verify my changes, so I haven't had too much trouble with work offsets, but using G10 seems to be able to put a wrench in the works.
[02:45:42] <cradek> the purpose of emc.var is to preserve interpreter state from one run to another, nothing else
[02:45:56] <cradek> touch off calls exactly G10
[02:46:48] <kwallace1> So I should pretend that emc.var doesn't exist?
[02:47:23] <cradek> as a user, postively yes you should ignore it
[02:47:31] -!- The__Ball has quit [Ping timeout: 260 seconds]
[02:49:15] <cradek> ALSO as a gui author
[02:49:36] <cradek> only if you are working inside the interpreter guts should you be interested in it
[02:52:38] <kwallace1> I'm still trying to figure out what a work offset utility should look like.
[02:53:29] <cradek> I think it would be very hard to make a gui that does everything that G10 lets you do
[02:54:27] <cradek> I mean intuitively - obviously you can make a gui that lets/helps the user make G10 commands, which is what touchy's set offset/set tool buttons do
[02:55:11] <kwallace1> My next pass might be to have an empty table that allows the user to enter values, then have a load button for each entry.
[02:55:16] <cradek> to me, a table full of numbers is a solution looking for a problem, and is not a task-driven approach
[02:55:51] <cradek> what problem are you solving? what is your user doing when you think this is a useful tool?
[02:57:00] <cradek> if your coordinate system is rotated, g10 lets you set pairs of numbers in ways that would be difficult to calculate and enter as raw numbers in the varfile-like table
[02:57:21] <kwallace1> Part of the problem is figuring out what the problem is.
[02:57:45] <cradek> haha, as jwz famously said, "now you have two problems"
[02:59:24] <cradek> I'm puzzled if you've decided on a UI but don't yet know the task someone wants to accomplish by using it
[02:59:37] <kwallace1> It started out easily enough, "Let's put a work offset table next to the tool table", "Yah, that should be easy."
[03:00:43] <cradek> in most situations g10 is the best way to "edit" the tool table as well [the only exception is adding a new tool, where I think g10 can't do it]
[03:01:32] <cradek> rotate your coordinate system 13 degrees and try to set meaningful tool offsets without using g10 or touch off, and you'll see what I mean
[03:01:45] <kwallace1> But using G10 from the command line requires some abstract thinking.
[03:02:10] <cradek> yes, something like touch off can usefully hide some of that
[03:02:30] -!- MacGalempsy has quit [Remote host closed the connection]
[03:02:51] <cradek> you work too late for me, I'm off to bed again, cheers
[03:03:24] <kwallace1> Thank you again,
[03:13:31] -!- JT_Shop_ [JT_Shop_!~john@172.243.172.9] has joined #linuxcnc-devel
[03:16:25] -!- jepler_ [jepler_!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[03:20:25] -!- micges has quit [Quit: Leaving]
[03:21:52] -!- mal``` [mal```!~mal``@li125-242.members.linode.com] has joined #linuxcnc-devel
[03:22:30] -!- KGB-linuxcnc_ [KGB-linuxcnc_!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[03:22:33] -!- The__Ball has quit [*.net *.split]
[03:22:34] -!- roycroft has quit [*.net *.split]
[03:22:34] -!- JT_Shop has quit [*.net *.split]
[03:22:35] -!- KGB-linuxcnc has quit [*.net *.split]
[03:22:35] -!- Jymmm has quit [*.net *.split]
[03:22:35] -!- jepler has quit [*.net *.split]
[03:22:36] -!- TekniQue has quit [*.net *.split]
[03:22:37] -!- toxx has quit [*.net *.split]
[03:22:37] -!- mal`` has quit [*.net *.split]
[03:22:37] -!- KimK_1 has quit [*.net *.split]
[03:22:37] -!- Patang has quit [*.net *.split]
[03:22:47] KGB-linuxcnc_ is now known as KGB-linuxcnc
[03:24:15] -!- KimK_1 [KimK_1!~kkirwan@ip68-102-65-151.ks.ok.cox.net] has joined #linuxcnc-devel
[03:55:10] -!- mhaberler [mhaberler!~mhaberler@extern-177.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[04:03:08] -!- somenewguy has quit []
[04:08:55] -!- geografa has quit [Quit: Computer has gone to sleep.]
[04:10:46] -!- mhaberler has quit [Ping timeout: 265 seconds]
[04:14:26] -!- flippyhead has quit [Quit: flippyhead]
[04:50:51] -!- gommo has quit [Remote host closed the connection]
[05:01:28] -!- Fox_Muldr has quit [Ping timeout: 246 seconds]
[05:18:46] -!- flippyhead has quit [Quit: flippyhead]
[05:22:22] -!- mhaberler [mhaberler!~mhaberler@extern-177.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:25:59] -!- MacGalempsy has quit [Remote host closed the connection]
[05:34:05] -!- i_tarzan has quit [Ping timeout: 240 seconds]
[05:39:49] <mhaberler> well sure. the source to overview.eps wasnt lost, it was a .dia file sitting right in the paper directory. Duh.
[05:40:45] -!- skorasaurus has quit [Ping timeout: 240 seconds]
[05:45:38] <mhaberler> jepler: I am all for merging jepler/c99, since it's flags cleanup season ;) btw I think BITOPS_DEFINE isnt used in the code anymore
[05:55:50] -!- kwallace1 [kwallace1!~kwallace@smb-167.sonnet.com] has parted #linuxcnc-devel
[06:08:03] -!- geografa has quit [Quit: Computer has gone to sleep.]
[06:12:58] -!- phillipadsmith has quit [Ping timeout: 240 seconds]
[06:12:58] phillipadsmith_ is now known as phillipadsmith
[06:17:15] -!- zlog_ [zlog_!~zlog@ip68-102-199-165.ks.ok.cox.net] has joined #linuxcnc-devel
[06:17:56] -!- zorg has quit [Ping timeout: 240 seconds]
[06:17:56] -!- zlog has quit [Ping timeout: 240 seconds]
[06:19:08] -!- KimK has quit [Ping timeout: 240 seconds]
[06:19:35] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[06:22:41] -!- ve7it has quit [Remote host closed the connection]
[06:25:25] -!- gimps has quit [Ping timeout: 240 seconds]
[06:25:54] -!- archivist_herron has quit [Ping timeout: 264 seconds]
[06:26:36] -!- jazzy has quit [Ping timeout: 240 seconds]
[06:26:36] -!- kanzure has quit [Ping timeout: 240 seconds]
[06:34:10] -!- Tom_garage [Tom_garage!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[06:34:18] -!- Aero-Tec has quit [Ping timeout: 245 seconds]
[06:35:22] -!- Tom_itx has quit [Ping timeout: 277 seconds]
[06:35:22] -!- SadMan has quit [Ping timeout: 257 seconds]
[06:36:14] -!- mozmck1 [mozmck1!~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[06:36:39] -!- Aero-Tec2 has quit [Ping timeout: 260 seconds]
[06:36:59] -!- mozmck has quit [Ping timeout: 240 seconds]
[06:38:21] -!- SadMan [SadMan!sadman@sadman.net] has joined #linuxcnc-devel
[06:49:36] -!- mhaberler has quit [Ping timeout: 248 seconds]
[06:54:08] -!- mhaberler [mhaberler!~mhaberler@extern-177.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:13:03] -!- somenewguy has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130911164256]]
[07:20:51] -!- tjb1 has quit [Read error: Connection reset by peer]
[07:21:18] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[07:32:25] -!- geografa has quit [Quit: Computer has gone to sleep.]
[07:34:31] -!- mle has quit [Ping timeout: 260 seconds]
[07:34:57] -!- rob_h [rob_h!~rob_h@94.2.145.93] has joined #linuxcnc-devel
[07:40:56] -!- gimps__ has quit [Read error: Connection reset by peer]
[07:49:13] Jymmmm is now known as Jymmm
[07:52:59] -!- NickParker has quit [Ping timeout: 248 seconds]
[08:11:18] -!- adb_ [adb_!~IonMoldom@2a02:1205:501a:f300:baac:6fff:fe67:305f] has joined #linuxcnc-devel
[08:14:39] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[08:28:06] -!- grandixximo has quit [Ping timeout: 268 seconds]
[08:35:36] -!- adb_ has quit [Ping timeout: 252 seconds]
[08:46:33] -!- b_b has quit [Changing host]
[08:54:09] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[09:02:27] -!- md-2 has quit [Remote host closed the connection]
[09:03:06] -!- md-2 has quit [Remote host closed the connection]
[09:06:55] -!- NickParker|2 has quit [Ping timeout: 260 seconds]
[09:14:35] -!- kanzure has quit [Ping timeout: 248 seconds]
[09:30:09] -!- stsydow has quit [Quit: Leaving]
[09:36:50] -!- i_tarzan has quit [Ping timeout: 264 seconds]
[10:09:04] -!- asdfasd has quit [Ping timeout: 248 seconds]
[10:19:18] -!- NickParker has quit [Read error: Connection reset by peer]
[10:46:01] TekniQue_ is now known as TekniQue
[10:46:09] -!- TekniQue has quit [Changing host]
[11:00:53] -!- jlrodriguez has quit [Ping timeout: 248 seconds]
[11:02:56] -!- jlrodriguez_ has quit [Ping timeout: 245 seconds]
[11:11:56] -!- mhaberler has quit [Quit: mhaberler]
[11:24:38] -!- jlrodriguez_ has quit [Quit: Saliendo]
[11:29:09] -!- jlrodriguez_ has quit [Client Quit]
[11:50:55] -!- mle has quit [Remote host closed the connection]
[11:53:17] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:53:31] -!- gabewillen has quit [Ping timeout: 248 seconds]
[11:55:14] -!- Simooon has quit [Quit: Leaving]
[11:56:35] -!- archivist_herron has quit [Read error: Operation timed out]
[11:58:52] -!- md-2 has quit [Remote host closed the connection]
[12:03:28] -!- md-2 has quit [Ping timeout: 240 seconds]
[12:04:56] -!- asdfasd1 has quit [Ping timeout: 241 seconds]
[12:06:02] -!- mle has quit [Remote host closed the connection]
[12:29:41] -!- MacGalempsy has quit [Remote host closed the connection]
[12:31:10] Tom_garage is now known as Tom_itx
[12:38:24] -!- md-2 has quit [Ping timeout: 248 seconds]
[12:51:38] -!- zzolo has quit [Quit: zzolo]
[12:58:21] -!- Blorb has quit [Read error: Connection reset by peer]
[13:09:00] -!- zzolo has quit [Quit: zzolo]
[13:22:26] -!- Loetmichel has quit [Ping timeout: 264 seconds]
[13:25:56] <KGB-linuxcnc> 03jepler 05master 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[13:25:56] <KGB-linuxcnc> 03jepler 05master 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[13:29:38] -!- mle has quit [Remote host closed the connection]
[13:29:54] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[13:58:04] <mhaberler> hi jepler! around?
[13:58:48] <mhaberler> jepler/c99 would be great to get merged; BITOPS_DEFINE is unused now btw
[14:12:24] -!- kwallace [kwallace!~kwallace@smb-43.sonnet.com] has joined #linuxcnc-devel
[14:16:16] -!- gabewillen [gabewillen!~gabewille@99.144.115.187] has joined #linuxcnc-devel
[14:23:46] JT_Shop_ is now known as JT_Shop
[14:32:27] -!- krusty_ar has quit [Ping timeout: 248 seconds]
[14:44:42] -!- zzolo has quit [Quit: zzolo]
[15:03:28] -!- mhaberler has quit [Quit: mhaberler]
[15:11:22] -!- thomaslindstr_m has quit [Remote host closed the connection]
[15:18:11] -!- micges [micges!~micges@exd122.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:20:55] -!- ChristianS has quit [Excess Flood]
[15:23:57] -!- littlefinger has quit [Ping timeout: 250 seconds]
[15:31:25] -!- gabewillen has quit [Quit: Leaving]
[15:41:01] -!- mackerski has quit [Quit: mackerski]
[15:45:01] -!- arekm has quit [Ping timeout: 245 seconds]
[15:45:43] -!- Laremere has quit [Ping timeout: 240 seconds]
[15:50:24] <jepler_> mhaberler: that branch led to weird link errors that I don't understand at all, so it's not suitable for pushing to master.
[15:50:28] <jepler_> http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1373/steps/compile/logs/stdio
[15:50:34] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_attr_setstacksize'
[15:50:37] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_create'
[15:50:39] <jepler_> ../lib/liblinuxcnchal.so.0: undefined reference to `pthread_join'
[15:50:42] <jepler_> collect2: ld returned 1 exit status
[15:50:44] <jepler_> ^^^ e.g.,
[15:51:31] <jepler_> there was another build error on hardy, but at least I understand what that one was about (makefile quoting that was ok for CC=gcc but wrong for CC=gcc -std=c99)
[15:51:31] -!- kiw has quit [Ping timeout: 260 seconds]
[15:53:48] <jepler_> this is master branch targeting rtai, so I don't have the slightest idea why liblinuxcnchal would end up referring to pthread functions
[15:58:20] <kwallace> cradek: It looks like we had a patch that got the work offsets out of interp-convert, which will likely get dusted off again. Apparently, Mach has a table with editable real time offsets, so it must be possible.
[16:05:52] <jepler_> yes, enabling -std=c99 causes objects/rtapi/rtai_ulapi.o to refer to pthread identifiers when it didn't before
[16:07:38] <jepler_> .. because it changes the semantics of "extern inline", and rtai_lxrt.h has extern inlines that refer to pthread_create et al
[16:07:55] jepler_ is now known as jepler
[16:14:51] <KGB-linuxcnc> 03jepler 05jepler/c99 459a20b 06linuxcnc 10src/ 10Makefile 10configure.in * build: Require C99, and no longer forbid declaration-after-statement
[16:16:57] -!- linuxcnc-build_ has quit [Excess Flood]
[16:17:18] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-187-26.hlrn.qwest.net] has joined #linuxcnc-devel
[16:22:43] <linuxcnc-build> build #586 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/586 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:25:05] <linuxcnc-build> build #1385 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1385 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:26:18] -!- gonzo_ has quit [Read error: Connection reset by peer]
[16:26:41] -!- stsydow has quit [Ping timeout: 245 seconds]
[16:27:02] <jepler> well that didn't work out
[16:27:11] -!- md-2 has quit [Remote host closed the connection]
[16:27:29] -!- thomaslindstr_m has quit [Read error: Connection reset by peer]
[16:28:40] <linuxcnc-build> build #1381 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1381 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:30:39] -!- b_b has quit [Changing host]
[16:32:05] -!- md-2 has quit [Ping timeout: 248 seconds]
[16:52:25] -!- md-2 has quit [Remote host closed the connection]
[16:53:44] <linuxcnc-build> build #1381 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1381 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:53:52] <linuxcnc-build> build #1379 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1379 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[16:54:31] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:54:36] -!- tmcw has quit [Remote host closed the connection]
[16:55:30] -!- tmcw has quit [Read error: Connection reset by peer]
[17:02:02] -!- flippyhead has quit [Quit: flippyhead]
[17:07:30] -!- tmcw has quit []
[17:08:30] <cradek> dummy
[17:08:54] DJ9DJ is now known as _DJ_
[17:11:52] -!- micges has quit [Quit: Leaving]
[17:12:50] <kwallace> dummy?
[17:14:13] -!- computer2000 has quit [Remote host closed the connection]
[17:16:08] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[17:16:30] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:17:04] <kwallace> Oh I see, dummy is on the blame list... dummy.
[17:19:03] <mhaberler> yeah, some RTAI headers are a tarpit
[17:22:08] <mhaberler> possibly inlined but not static math funcs? I had do the full exercise for xeno_math (xenomai-kernel) to remove and userland math.h refs, that was a similar moving target
[17:24:55] _DJ_ is now known as _DJ__
[17:25:20] _DJ__ is now known as _DJ_
[17:27:12] seb_kuzm1nsky is now known as seb_kuzminsky
[17:31:26] -!- flippyhead has quit [Ping timeout: 264 seconds]
[17:32:13] -!- gonzo_ has quit [Read error: Connection reset by peer]
[17:33:46] <jepler> I think I have a combo that works on lucid/rtai, just rebasing it on master now..
[17:36:21] -!- voxadam has quit [Read error: Connection reset by peer]
[17:43:55] -!- ChristianS has quit [Excess Flood]
[17:45:09] -!- ChristianS has quit [Excess Flood]
[17:47:01] <mhaberler> re jwp/axis.py: while I got your patch to apply, it is based on master, and axis.py in ja3 already differs a bit, which produced a merge conflict; not sure if I resolved this one properly (the incr jog does work, but the axis selection and jog incr dropdown are grayed out, so likely no); it does emit jog_incrs though - if I can ask you a favor, would you merge that patch onto ja3 or a temp branch?
[17:49:17] -!- syyl_ws has quit [Quit: Verlassend]
[17:56:55] -!- prasadramdas has quit [Ping timeout: 250 seconds]
[17:58:18] <KGB-linuxcnc> 03git 05jepler/c99 8f615e9 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh 10rs274ngc/rs274ngc_pre.cc * interp: no more static _setup
[17:58:18] <KGB-linuxcnc> 03git 05jepler/c99 68476fd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc * interp: adapt exposure of _setup members
[17:58:22] <KGB-linuxcnc> 03git 05jepler/c99 c113e5b 06linuxcnc 10tests/remap/ 10introspect/expected 10introspect/oword.py * tests/interp: adapt remap/introspect
[17:58:29] <KGB-linuxcnc> 03git 05jepler/c99 726527c 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp/setup_struct: add ctor, dtor declaration
[17:58:36] <KGB-linuxcnc> 03git 05jepler/c99 c8ea07d 06linuxcnc 03src/emc/rs274ngc/interp_setup.cc * interp/setup_struct: constructor definition
[17:58:42] <KGB-linuxcnc> 03git 05jepler/c99 87434c2 06linuxcnc 10src/emc/rs274ngc/Submakefile * interp/Submakefile: add interp_setup.cc
[17:58:49] <KGB-linuxcnc> 03git 05jepler/c99 7e8ae44 06linuxcnc 10src/ 10Makefile 10Makefile.inc.in 10configure.in 03m4/ax_cxx_compile_stdcxx_11.m4 * build: add C++11 standard detection, CXXFLAGS autoconf support
[17:58:56] <KGB-linuxcnc> 03jepler 05jepler/c99 bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[17:59:03] <KGB-linuxcnc> 03jepler 05jepler/c99 aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[17:59:09] <KGB-linuxcnc> 03jepler 05jepler/c99 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[17:59:16] <KGB-linuxcnc> 03jepler 05jepler/c99 d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[17:59:23] <KGB-linuxcnc> 03jepler 05jepler/c99 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[17:59:29] <KGB-linuxcnc> 03jepler 05jepler/c99 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[17:59:36] <KGB-linuxcnc> 03jepler 05jepler/c99 d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[17:59:42] <KGB-linuxcnc> 03jepler 05jepler/c99 47ad5cd 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[18:00:08] <mhaberler> super, thanks
[18:01:10] <jepler> mhaberler: hopefully this time it is golden
[18:01:24] <mhaberler> you got hardy to put up with the change?
[18:02:05] <jepler> It's lucid I've been coddling. Have to find out about hardy from the buildbot
[18:07:33] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[18:08:52] -!- Laremere has quit [Ping timeout: 264 seconds]
[18:11:23] -!- adb_ [adb_!~IonMoldom@2a02:1205:501a:f300:baac:6fff:fe67:305f] has joined #linuxcnc-devel
[18:14:03] <mhaberler> finding the cause for a runtests failure in bb output is an art form
[18:16:15] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:20:45] -!- cyborg has quit [Ping timeout: 250 seconds]
[18:42:54] <linuxcnc-build> build #1054 of deb-precise-sim-binary-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1054 blamelist: dummy, Michael Haberler <git@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>
[18:43:00] <linuxcnc-build> build #1053 of deb-precise-sim-binary-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1053 blamelist: dummy, Michael Haberler <git@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>
[18:50:04] -!- zzolo has quit [Quit: zzolo]
[18:57:09] -!- vladimirek has quit [Remote host closed the connection]
[19:00:45] <KGB-linuxcnc> 03jepler 05master d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[19:00:46] <KGB-linuxcnc> 03jepler 05master 89407af 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[19:09:12] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[19:10:45] <mhaberler> well I guess I'll merge this into a ubc3-based tmp branch and see what the arm etc builds say to this, usually they are harmless
[19:13:36] <mhaberler> wtf:: -fgnu89-inline ;)
[19:19:39] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[19:21:14] -!- skorasaurus has quit [Ping timeout: 264 seconds]
[19:22:53] <cradek> I am against any automatic motion upon pausing, especially if it reintroduces a different kind of jogging/motion based on motion hal pins
[19:23:52] <cradek> IMO it is a solution looking for a problem
[19:24:35] <cradek> I think the simple straight-line-to-resume-point is the only automatic motion we want, since it can't be avoided
[19:30:17] <mhaberler> the automatic motion-on-pause happens only if the pause-offset is non-zero
[19:30:28] <mhaberler> btw not my idea - that was requested on the list;)
[19:30:45] <cradek> well if you read closer he said mach does it but he doesn't use it because it's safer not to
[19:30:46] <mhaberler> I tend to separate those two moves by different offsets, too
[19:30:51] <cradek> that's a pretty weak request
[19:31:11] -!- micges [micges!~micges@exd122.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:31:11] -!- sumpfralle has quit [Read error: Connection reset by peer]
[19:31:11] -!- Connor has quit [Read error: Connection reset by peer]
[19:31:13] <cradek> I think we shouldn't copy misfeatures for the sake of having them
[19:31:32] <cradek> it'll be hard enough already when we want to add changing offsets :-/
[19:32:21] <mhaberler> the issue with straight line to resume point was that some want that aligned to an axis to the resume point, even if they arent currently
[19:32:34] <mhaberler> that sounded reasonable eg for mills, resume along z
[19:33:05] <cradek> yes I saw that request
[19:33:20] <cradek> but that's totally different from automatic motion upon pausing
[19:33:21] <mhaberler> how would you say reenter a bore exactly if kbd jogged around?
[19:34:03] <mhaberler> say pause in bore, jog out along z, then jog random x,y
[19:34:12] <mhaberler> how you're going to hit original x y
[19:34:25] <mhaberler> before plunging
[19:34:25] <cradek> I was talking about automatic motion upon pausing
[19:34:31] <mhaberler> oh ok
[19:34:51] <cradek> as far as I can tell, it was never requested
[19:34:59] <cradek> (the other thing you are talking about WAS requested)
[19:35:11] <mhaberler> so the reentry from offset is the one you agree with
[19:35:55] <mhaberler> well fine, its at least one state less, and 11 states is a tad much for my taste anyway
[19:36:04] -!- aitalmac has quit [Read error: Connection reset by peer]
[19:36:57] <cradek> brb
[19:37:00] <mhaberler> sure
[19:38:09] -!- dway has quit [Quit: dway]
[19:40:17] <jepler> $ time git clone --reference linuxcnc git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-clone-of-the-minute
[19:40:20] <jepler> Initialized empty Git repository in /usr/local/jepler/src/linuxcnc-clone-of-the-minute/.git/
[19:40:23] <jepler> real 0m0.986s
[19:40:26] <jepler> wow that's really quite fast
[19:41:58] -!- sumpfralle has quit [Read error: No route to host]
[19:43:45] <cradek> sorry, darn work gets in the way
[19:44:00] <mhaberler> actually I use a script which references several local repos, so I dont have several object trees - reduces disk usage a lot
[19:44:28] <cradek> I'd still rather have simple straight line reentry
[19:44:48] <mhaberler> how would you handle that bore example?
[19:45:15] <cradek> well I'd never jog away from over it, or if I did, I'd jog back
[19:45:16] <mhaberler> (I think that be a rather common situation)
[19:45:53] <mhaberler> how go back, write down position?
[19:45:55] <cradek> moving straight up would be fine for the common situations as I understand them, such as stringer removal
[19:46:10] <mhaberler> right
[19:46:17] <cradek> well it depends why you left the position in the first place. you could use incremental jog to leave it, then also to come back
[19:46:33] <cradek> why would you jog sideways if you needed to reenter from above? can you give me an example?
[19:46:40] <mhaberler> now by accident Joe Chipcutter jogs x instead of z once out of the bore, and there is no way to get back
[19:46:54] <mhaberler> he didnt write down the initial pause x y
[19:47:04] <cradek> meh
[19:47:22] <cradek> abort and restart, I don't care about fixing accidents that clumsy operators make
[19:47:39] <mhaberler> that's the whole point I think; assure its aligned along an axis no matter what happens
[19:47:39] <cradek> your clumsy guy is not going to pull up halcmd and set some pins
[19:48:09] <jepler> the direction of boring or drilling might not be along any axis letter on a 5-axis machine
[19:48:22] <cradek> sure or even on a boring 2 axis lathe
[19:48:26] <cradek> haha "boring"
[19:48:38] <cradek> I'm accidentally punny
[19:48:40] <mhaberler> my route would be to give them a rope to hang themself on if it adds usabiliy in common situations
[19:49:40] <cradek> I think the use case is questionable, and the idea of having a pose offset in hal pins is a poor approach to solving it
[19:49:59] <mhaberler> got a better one?
[19:51:06] <cradek> if you think the use case is important, and I don't, a better solution would be to have an ini? gui? configuration that says which axis to move last and alone, and make the reentry two predictable moves (all but last axis coordinated, then last axis only)
[19:51:53] <mhaberler> I see, interesting idea
[19:52:05] <cradek> an offset is going to be crashy if your hole is deep, and is going to sometimes be invalid depending on how close your workpiece is to the axis limit
[19:52:15] <mhaberler> you basically reserve an axis for the reentry move
[19:52:24] <cradek> yes
[19:52:34] -!- bedah has quit [Quit: Ex-Chat]
[19:52:37] <mhaberler> that sounds a lot cooler
[19:52:41] <cradek> but it'll still be wrong half the time on a lathe, and you really almost always want a diagonal move
[19:52:54] <cradek> otherwise you rub your cutter on something you didn't want to
[19:53:08] <mhaberler> does an axis set address the issue?
[19:53:21] <cradek> axis set?
[19:53:38] <jepler> A set of axis letters like {X,Y,U,V} ?
[19:53:44] <mhaberler> right
[19:54:02] <mhaberler> that would cover diagonal I think
[19:54:14] <cradek> I don't see how that would work
[19:55:12] <mhaberler> well you give a set like {X,Y,U,V} and the first move will be to {X,Y,U,V} of the initial pause positon, the other axes unchanged
[19:55:22] <mhaberler> the reentry move moves the remaining axes
[19:55:23] <cradek> I've seen talk of "save points"
[19:55:50] <cradek> or why not record the jogs and replay them backwards
[19:56:22] <mhaberler> hm, that was exactly what was possible by a HAL usercomp with my original HAL-pin based approach
[19:56:24] <cradek> it comes down to what problem are we trying to solve, and I don't know that
[19:57:12] <mhaberler> basically that approach at pause handed over control to HAL pins, and there you can play any sort of games
[19:57:22] <mhaberler> including recording
[19:57:33] <cradek> I think you should do straight line resume, not make it more complicated, then start working on mdi/touchoff/offset changes because that's the very important use case
[19:58:30] <mhaberler> well I dont mind; I just would ask you to suggest that on the list, I'll confirm that be too ambitious for a first round, done
[19:58:44] <cradek> hm you really could record the jog messages...
[19:58:59] <mhaberler> caveat, we're coming full circle here
[19:59:10] <cradek> it's still a solution looking for a problem, but what a cool solution, haha
[19:59:21] <jepler> the full circle we don't want to come back to is the car with two steering wheels
[19:59:28] <mhaberler> right
[19:59:35] <cradek> oh forget it - it'd be hard or impossible to record wheel jogs
[20:00:17] <mhaberler> you know, I dont think so. the model needs a bit of thinking but it's not out of reach
[20:00:17] -!- skunkworks has quit [Quit: Leaving]
[20:00:24] <mhaberler> but not for this round
[20:00:35] <mhaberler> and I want to go back to my noNML djihad
[20:01:31] <mhaberler> before, I would like to talk through (not make coding plans yet) how to adress step 1, namely moving offset application to motion
[20:02:16] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[20:02:40] <mhaberler> the reason why: it could be (I think we were there already) we'll have to limit certain language features, programs modifying offsets on the fly
[20:03:06] <mhaberler> it could help to start with implementing a warning in the interp that a change here is pending, and watch the fallout
[20:03:08] <cradek> nahhh, we just need a design that works with gcode as she is spoke
[20:03:30] <cradek> it's utterly normal for programs to change offsets
[20:04:25] <mhaberler> well fine: if step one is moving offset and rotation application to motion, then lets talk possible fallout
[20:04:47] <mhaberler> would you agree offset application to be the first goal?
[20:04:57] <mhaberler> dia is second IMO
[20:04:58] <cradek> an offset change is always applied during a move, so you never get a step change
[20:05:27] <cradek> dia change in post-processing is a zillion times harder and also unnecessary
[20:06:10] <mhaberler> right, its an easier first step to move offset forward
[20:06:11] <cradek> again, I think the answer to that is to not queue past, and reread the tool table, at every g41/g42
[20:06:32] <cradek> anything else leads to doom
[20:06:43] <mhaberler> new queue busters, hm
[20:06:50] <mhaberler> well why not
[20:07:28] <cradek> andy's work might make the reread step easy/different
[20:07:44] <mhaberler> what is going on there?
[20:07:47] <cradek> just saying I don't think this is a thing we have to worry about for jwp+offsets
[20:08:00] <cradek> I have no idea but he's doing some tool table stuff
[20:08:09] <mhaberler> ok, I'll ask him
[20:08:11] <cradek> arg, work again, brb
[20:08:37] <mhaberler> anyway, can/must offset + rotation applied in one go, meaning both move to motion (I assume yes)?
[20:08:43] <jepler> he wants the tool table to be backed by an arbitrary datastore, possibly via Python and by with a default implementation using a sql database
[20:09:05] <jepler> (by with?)
[20:09:13] -!- jfire has quit [Quit: Leaving.]
[20:09:18] <mhaberler> oh
[20:09:45] <mhaberler> that was just a design method, it was thinking about what the API would require
[20:10:24] <mhaberler> I did talk with him about that, and I suggested the relational model for design, without suggesting this be a requirement for a toolstore
[20:10:38] <mhaberler> nb right now the 'table' is -3th normal form ;)
[20:10:45] <mhaberler> -3rd
[20:11:31] <cradek> mhaberler: can I suggest you experiment in mdi with changing offsets and rotation (use touch off or g10) intermingled with g1 moves? especially g1 moves of not-all-the-axes. it is fairly intricate because ONLY changing an offset or rotation causes no motion, it only affects future motions according to what axis words are given
[20:11:55] <mhaberler> ok
[20:12:27] <cradek> for instance, consider G10 R... then G91 G1 X1. it moves in a direction parallel to the new X axis
[20:13:01] <cradek> if you move offset+rotation you must still have this kind of behavior, and it's not clear to me how to do it
[20:13:30] <mhaberler> because canon needs to know too?
[20:13:35] -!- zlog_ has quit [Read error: Connection reset by peer]
[20:13:47] <cradek> well I don't know
[20:14:06] -!- Tom_itx has quit [Ping timeout: 252 seconds]
[20:14:17] <cradek> when you do G10 R..., your current coordinate changes, but there is no motion, and future motions are according to the new axis directions
[20:14:20] <cradek> brb again
[20:15:05] <mhaberler> I assume rotate_and_offset would have to wander too
[20:16:20] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[20:16:58] -!- zlog [zlog!~zlog@ip68-102-199-165.ks.ok.cox.net] has joined #linuxcnc-devel
[20:18:07] <mhaberler> not sure what this means for feedback into canon if required
[20:29:36] -!- sumpfralle has quit [Ping timeout: 268 seconds]
[20:39:21] <mhaberler> well lets take a step back for a minute; I see two strategies
[20:39:42] <mhaberler> one being: moving bits from canon piecemeal to motion.command-handler
[20:40:27] <mhaberler> second: bite the bullet, make motion.command-handler a userland process, dumb down emccanon.cc completely and move it to that user process
[20:41:38] <mhaberler> it depends on timeframe; 2) is some upfront effort, in particular there is a nasty synchronisation issue I dont have a solution for, but it would make the warp forward and any features thereon a lot easier
[20:42:08] <mhaberler> as a minor bonus, rs274ngc output will match what motion sees
[20:43:46] <cradek> do you think you understand the problem? have you done the experimenting I suggested?
[20:44:23] <mhaberler> I think I did understand the problem
[20:45:19] <mhaberler> once you start moving piecemeal, you have two places where state is kept - canon and motion upper half, and that is an - if not the - issue
[20:45:45] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:46:44] <mhaberler> assume for a minute all bells and whistles of emccanon.cc are in a user process which encompasses motion.command-handler - do you see how this gets around that state syncing problem?
[20:48:11] <cradek> no, not at all
[20:48:21] <cradek> the main offset handling is in the interpreter
[20:48:43] <mhaberler> well first, offset application is where we need it so it can be changed on the fly if needed
[20:48:54] <mhaberler> second, crc is where it can be redone if needed
[20:49:02] <mhaberler> no 'backing up the queue'
[20:49:19] <cradek> I'm not taking those leaps of faith with you
[20:49:44] <mhaberler> I know, we are talking 'in principle'
[20:49:52] <cradek> offset application isn't some atomic thing you can just move around, it's a part of gcode, and I don't think you understand it yet
[20:51:42] <cradek> it's throughout the interpreter, not just at the canon level, because the interp has to know the current position
[20:51:57] <mhaberler> well that is what I mean by possibly restricting language features - I dont think you will get the full flexibility of current rs274ngc while making parts of it runtime changeable
[20:52:42] <cradek> I refuse to start with the assumption that we'll break ngc
[20:53:10] <cradek> sorry, I'm getting fighty, I'm going to take a break
[20:53:22] <mhaberler> I fear the conclusion is that certain decision are to be considered frozen at readahead time
[20:53:29] <mhaberler> sure
[20:53:37] <mhaberler> I know that feeling ;)
[20:55:10] -!- stsydow has quit [Read error: Connection reset by peer]
[20:56:19] <mhaberler> it's a tradeoff - language flexibility versus ability to change certain state at runtime; you can take any position in this continuum
[20:57:03] <cradek> I don't think we know yet that there is this tradeoff to be made
[20:58:23] <mhaberler> well simple example - disable modification of offsets and rotation at program start; bang, much easier change during pause
[20:58:57] <cradek> sure, but you don't have a control that runs ngc programs anymore
[20:59:19] <cradek> I know there is a design that runs ngc programs and also lets you change offsets during pause
[20:59:30] <cradek> more than one even, I bet :-)
[20:59:40] -!- c60 has quit [Quit: Lost terminal]
[20:59:42] <mhaberler> maybe opinions vary on that, why do you think this is a must-have-at-all-cost feature?
[20:59:55] <mhaberler> which design are you referring to?
[21:00:36] -!- Eevon has quit [Read error: Connection reset by peer]
[21:00:53] <mhaberler> btw I will replicate your 'I'm getting fighty, I'll take a break' method, it seems to work ;)
[21:00:54] <cradek> ok, imagine the interpreter is moved into realtime and run just-in-time, one gcode line at a time. that's one design that would let you change offsets (or run any mdi commands) during pause
[21:01:04] <mhaberler> right
[21:01:08] <mhaberler> no readahead
[21:01:09] -!- skorasaurus has quit [Quit: Elvis has left the building.]
[21:01:21] <mhaberler> so no state syncing issue
[21:01:32] <mhaberler> aka sledgehammer method ;)
[21:01:38] <cradek> so we agree there's at least one working design, haha
[21:01:42] <mhaberler> yes
[21:02:06] <mhaberler> certainly - it is a state syncing issue caused by readahead - kill readahead, issue closed
[21:02:46] <mhaberler> no if you retain readahead, we're talking assumptions on which readahead takes place, and thats where language features come in
[21:03:07] <mhaberler> no/now
[21:03:11] <cradek> (with sadness I realize that design was utterly possible before we had seeking...)
[21:03:32] <mhaberler> yes, big trauma
[21:03:52] <mhaberler> the turing machine is a bitch
[21:05:05] <cradek> sometimes I've been tempted to make the sai into "g2g" that unrolls and simplifies a program (like the STRAIGHT_FEED call would print a simple G1, etc)
[21:05:25] -!- zzolo has quit [Quit: zzolo]
[21:05:41] <mhaberler> yes, but that that wont be equivalent because of conditionals based on queue busters
[21:05:53] <mhaberler> probe, read pin etc
[21:05:54] <cradek> that idea combined with your idea of allowing an axis word to be NULL is interesting
[21:06:19] <mhaberler> which idea, jwp axis sets? this is the same thing, yes
[21:06:20] <cradek> yeah you're right, but you could g2g each between-queuebuster segment?
[21:06:48] <jepler> (incidentally I'm lurking over here and after re-thinking what cradek said about non-specified axis words finally makes me see why offsets are not "just" a transformation matrix in which we enforce some of the elements to always be zero)
[21:07:01] <mhaberler> as long as you can assume position prediction in that segment works
[21:07:55] <cradek> you mean the G10 R ... G1 [with not all words] situation?
[21:08:08] <cradek> (which is not peculiar to R; offsets work the same way)
[21:08:08] <mhaberler> (me?)
[21:08:14] <cradek> jepler: ^
[21:08:18] <jepler> cradek: yes
[21:09:11] -!- chillly has quit [Quit: Leaving]
[21:09:12] <cradek> jepler: I think understanding that is really the key to understanding the hard part here
[21:10:04] <mhaberler> jepler: merged master into ubc3, bb, rtai/i386/10.04, rt-preempt/amd64/wheezy builds and runtests fine, much less warnings
[21:10:05] <cradek> perhaps the interpreter being able to issue NULL words in its moves can allow piecemeal application of a new offset, but even that doesn't seem like the full solution
[21:10:35] <cradek> like g1 y1 => STRAIGHT_FEED(NULL, 1, NULL)
[21:11:18] <mhaberler> how does that differ from STRAIGHT_FEED(<currentvalue>, 1, <currentvalue>)
[21:11:44] <cradek> you'd have two offsets then -- the one currently applied to each axis, and the 'candidate' that will be applied as soon as an axis is issued non-NULL
[21:12:37] <cradek> mhaberler: it's different if the offsets change between the previous STRAIGHT_FEED and this one
[21:13:43] <jepler> mhaberler: good
[21:13:59] <mhaberler> yes, very much so, I'll make the merge permanent now
[21:14:24] -!- _DJ_ has quit [Quit: bye]
[21:15:01] <mhaberler> great job btw, I mean even considering -fgnu89-inline is a serious leap for me
[21:16:31] -!- stsydow has quit [Read error: Connection reset by peer]
[21:17:04] <mhaberler> I need to sleep over this NULL thing so I get a chance to understand how this changes the playing field
[21:18:39] -!- afiber__ has quit [Quit: Konversation terminated!]
[21:18:58] <mhaberler> any example sequence sequence how this brings us forward?
[21:40:34] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 ccbef9c 06linuxcnc 10debian/configure * fix tcl/tk version for debian 7.x
[21:40:34] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 00307a5 06linuxcnc 10debian/configure * remove debugging print accidentally committed earlier
[21:40:36] <KGB-linuxcnc> 03git 05unified-build-candidate-3 8f615e9 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh 10rs274ngc/rs274ngc_pre.cc * interp: no more static _setup
[21:40:44] <KGB-linuxcnc> 03git 05unified-build-candidate-3 68476fd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc * interp: adapt exposure of _setup members
[21:40:51] <KGB-linuxcnc> 03git 05unified-build-candidate-3 c113e5b 06linuxcnc 10tests/remap/ 10introspect/expected 10introspect/oword.py * tests/interp: adapt remap/introspect
[21:40:58] <KGB-linuxcnc> 03git 05unified-build-candidate-3 726527c 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp/setup_struct: add ctor, dtor declaration
[21:41:05] <KGB-linuxcnc> 03git 05unified-build-candidate-3 c8ea07d 06linuxcnc 03src/emc/rs274ngc/interp_setup.cc * interp/setup_struct: constructor definition
[21:41:12] <KGB-linuxcnc> 03git 05unified-build-candidate-3 87434c2 06linuxcnc 10src/emc/rs274ngc/Submakefile * interp/Submakefile: add interp_setup.cc
[21:41:16] -!- Laremere has quit [Ping timeout: 264 seconds]
[21:41:18] <KGB-linuxcnc> 03git 05unified-build-candidate-3 7e8ae44 06linuxcnc 10src/ 10Makefile 10Makefile.inc.in 10configure.in 03m4/ax_cxx_compile_stdcxx_11.m4 * build: add C++11 standard detection, CXXFLAGS autoconf support
[21:41:26] <KGB-linuxcnc> 03git 05unified-build-candidate-3 5c51a0b 06linuxcnc 10(5 files in 3 dirs) * Merge remote-tracking branch 'origin/master' into unified-build-candidate-3
[21:41:31] -!- odogono has quit [Ping timeout: 260 seconds]
[21:41:34] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 bbf90da 06linuxcnc 10src/rtapi/sim_rtapi_app.cc * interp: fix interpretation of ambiguous "bind"
[21:41:42] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 aa08fad 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * Avoid use of C++11 feature to initialize arrays and aggregates
[21:41:47] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 787f893 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh * interp: provide a constructor for block_struct
[21:41:54] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 d4d4b07 06linuxcnc 10src/emc/rs274ngc/interp_setup.cc * interp: rely on zero-arg constructor of setup_struct::blocks
[21:42:01] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 92ce7f7 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c * axis: Don't directly use trp->result
[21:42:07] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 37c70c2 06linuxcnc 10src/emc/usr_intf/emcsh.cc * emcsh: don't directly write to interp->result
[21:42:15] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 d410e61 06linuxcnc 10src/Makefile * remove unused BITOPS_DEFINE
[21:42:21] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 89407af 06linuxcnc 10src/Makefile * build: Enable C99, and no longer forbid declaration-after-statement
[21:42:27] <KGB-linuxcnc> 03git 05unified-build-candidate-3 b1fa6b4 06linuxcnc 10src/Makefile * Merge remote-tracking branch 'origin/master' into unified-build-candidate-3
[21:42:34] <KGB-linuxcnc> 03git 05unified-build-candidate-3 901f806 06linuxcnc 10src/rtapi/rtapi_app.cc * rtapi_app: disambiguate bind()
[21:50:17] <andypugh> Reading back: If you _did_ want to record the jog-out move, then would it suffice to record the locus of points where the velocity was zero?
[21:51:46] <linuxcnc-build> build #1389 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1389 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[21:51:49] -!- Brandonian has quit [Quit: Brandonian]
[21:51:55] <linuxcnc-build> build #1384 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1384 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[21:52:02] <linuxcnc-build> build #1387 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1387 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[21:52:59] <andypugh> Secondly, perhaps line-at-atime G-code s something you can fall back to? Much of the time is it hardly any penalty at all. I think what I am saying is that being willing to dump the queue and start again at the slightest provocation might not be the end of the word. Possibly even feed-override can be a queue-recalc.
[21:56:14] <mhaberler> re recording moves: it boils down to 'who records' - some halcomp or the UI, but certainly possible; UI's would need to clue up what to do during a pause - replaying should be possible with incremental jogs if this is what you want
[21:56:52] <mhaberler> that would be quite convenient I'd think
[21:57:14] <mhaberler> it reduces the job within motion which is a plus
[21:57:16] <andypugh> Having said that, if there is a well-documented "final dive to IPP" behaviour, then folk can learn to live with it, I am sure.
[21:58:01] <andypugh> It may be a feature where we need an imperfect implementation to allow people to work out what they need of the perfect implementation.
[21:58:51] <andypugh> With reference to the issue of there not being a straight-line move back into the IPP. If that is the case, then how did they jog out in the first place?
[21:58:55] -!- FinboySlick has quit [Quit: Leaving.]
[21:58:57] <mhaberler> actually position recording and UI-based replay is potentially much more flexible than any motion based method
[21:59:06] <mhaberler> right
[22:00:46] <mhaberler> actually record/replay need not even be in the base UI like axis, this could well be say in a gladevcp tab, suit to fit (maybe even the EDM folk)
[22:01:17] <mhaberler> I didnt like the feature accretion in motion anyway
[22:01:36] <mhaberler> because it is always going to be limited and a compromise
[22:03:15] <andypugh> I am not crazy about the move-on-pause thing. (though given that it can be set to zero as the default, and may be something that people think they want, I am OK with it, I think). But if I press "Pause" I expect motion to stop, not something odd to happen.
[22:03:42] <mhaberler> that motion was optional anyway
[22:04:00] <mhaberler> is it safe to assume linear moves between stopped points? I dont see how any other way
[22:04:05] <andypugh> But I just thought of a use-case. I am pretty sure you want to retract the wheel on a grinder if you press pause. You do _not_ want the wheel rolling against the work as it stops.
[22:04:39] <andypugh> It's pretty hard to do curved jogs. I am not saying it is impossible, but it's unusual.
[22:05:07] <mhaberler> actually even if somebody just died to have a retract move on pause, she even could do that because the pause state is exposed in the linuxcnc module
[22:05:19] <andypugh> If you have multiple jog-wheels you can do it. But otherwise you can't
[22:06:10] <mhaberler> I am not sure wheel jogging in motion is a great idea except for low delay
[22:06:34] <mhaberler> its this 'steering with multiple wheels' thing jepler referred to
[22:07:32] <mhaberler> well even if somebody came up with curved jogs - nobody keeps a UI writer from recording samples
[22:07:49] <Tom_itx> put a mixer on it like a model helicopter has for the pitch
[22:07:52] <andypugh> I wonder how much of linuxCNC is in the realtime layers because realtime is the LinuxCNC "Special thing"
[22:07:56] <Tom_itx> then you need a single one
[22:08:39] -!- ink has quit [Disconnected by services]
[22:08:42] <mhaberler> whats so special except being a pretty retarded programming environment ;-?
[22:09:15] <mhaberler> I think we should try wheel jog via nml
[22:09:42] <mhaberler> it might be too slow, this is the only downside I can think of
[22:10:13] <mhaberler> but we have a single driving path, and not having that creates issues
[22:10:25] <andypugh> I actually thought it was a a joke. :-)
[22:10:34] <mhaberler> no it isnt
[22:10:48] <mhaberler> a jog wheel is a UI component
[22:10:55] <mhaberler> soft or hard
[22:11:37] <andypugh> It ought to work. If a destination gets delayed, so what? The danger-scenario is getting a destination too far, but that can't happen.
[22:13:34] <mhaberler> yes, I think so too. Now if that comes in time for 2.6 is a different question, but I think it settles the question what is need in motion, which isnt much beyond what is in my jwp branch right now
[22:13:48] -!- kiw has quit [Ping timeout: 240 seconds]
[22:14:30] <mhaberler> the motion mods certainly can be in time; but the rest can be hinted at by say a gladevcp demo config showing how recording, replay and wheel jog can be done
[22:14:49] <mhaberler> which is fine for a release I think
[22:14:55] <andypugh> loadusr hal_jogwheel. net hal_jogwheel.0.axis-sel multiswitch.0.out
[22:15:49] <andypugh> back in a bit
[22:16:00] <mhaberler> that was a very good idea
[22:31:16] <linuxcnc-build> build #1382 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1382 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>
[22:37:00] -!- einar has quit [Quit: Leaving]
[22:46:54] -!- stsydow has quit [Read error: Connection reset by peer]
[22:49:44] -!- tmcw has quit [Remote host closed the connection]
[22:52:26] -!- asdfasd has quit [Ping timeout: 264 seconds]
[22:52:41] -!- mhaberler has quit [Quit: mhaberler]
[23:00:50] -!- hm2-buildmaster_ has quit [Remote host closed the connection]
[23:00:53] -!- linuxcnc-build has quit [Remote host closed the connection]
[23:01:09] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@75-166-187-26.hlrn.qwest.net] has joined #linuxcnc-devel
[23:01:12] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-187-26.hlrn.qwest.net] has joined #linuxcnc-devel
[23:01:23] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[23:01:23] <linuxcnc-build> build #1064 forced
[23:01:24] <linuxcnc-build> I'll give a shout when the build finishes
[23:15:36] -!- adb_ has quit [Ping timeout: 252 seconds]
[23:16:15] <linuxcnc-build> Hey! build docs #1064 is complete: Warnings [8warnings compile]
[23:16:15] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1064
[23:18:23] -!- hm2-buildmaster has quit [Remote host closed the connection]
[23:18:24] -!- linuxcnc-build has quit [Remote host closed the connection]
[23:18:39] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@75-166-187-26.hlrn.qwest.net] has joined #linuxcnc-devel
[23:18:44] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-187-26.hlrn.qwest.net] has joined #linuxcnc-devel
[23:18:47] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[23:18:47] <linuxcnc-build> build #1065 forced
[23:18:47] <linuxcnc-build> I'll give a shout when the build finishes
[23:20:29] <andypugh> This is intersting.
[23:23:19] <andypugh> I have a problem with the SSI driver crashing the system if config goes wrong and it aborts from an unusual state. It's problem with the cleanup code, I guess. The curious thing is that if I insert "FIXME: quitting without cleanup"; return; then it prints the message and quits cleanly. If I have, instead "FIXME: I bet this will crash; (and no return) then it doesn't print the message. But it does crash. Which seem
[23:23:19] <andypugh> tad peculiar.
[23:29:24] <andypugh> I think I have found the problem, but I am puzzled as to why I don't see the printk in the second case.
[23:32:29] <linuxcnc-build> build #1065 of docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1065
[23:46:42] -!- mackerski has quit [Quit: mackerski]
[23:50:59] -!- thomaslindstr_m has quit [Remote host closed the connection]