Back
[00:00:22] <memleak> yes its stable and all!
[00:02:38] <KimK> Hi Seb! I did a new install on a blank drive. I was wondering if you had copied some needed file on some previous occasion, so yours worked fine. I never did that, so, trouble?
[00:02:57] <memleak> that commit works great, every few days to a week i always at least push something to the tree that either cosmetically cleans something up or i remove stale and or dead files. sometimes i update it against the current magma CVS branch
[00:03:11] <memleak> speaking of which it's time to merge magma and vulcano together again.
[00:04:10] <memleak> i'll probably be doing all this tomorrow. big day for RTAI again! :D
[00:05:29] <memleak> kernel IPIPE fixes and rebasing the patches against newer kernels as well.
[00:48:36] <linuxcnc-build> Hey! build checkin #1282 is complete: Success [3build successful]
[00:48:36] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1282
[00:50:45] <KGB-linuxcnc> 03kinsamanka 05ubc2-7i80-rtnet 8a239f9 06linuxcnc 10src/ 10(5 files in 2 dirs) * RPi SPI Driver initial commit
[00:50:46] <KGB-linuxcnc> 03mail17 05ubc2-7i80-rtnet a324838 06linuxcnc * Merge pull request #2 from kinsamanka/hal_spi
[00:50:49] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet eb4f416 06linuxcnc 10src/ 10rtapi/rtapi.h 10rtapi/rtapi_common.c * rtapi: add rtapi_shmem_exists() acessor
[00:50:55] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 4894a2a 06linuxcnc 10src/rtapi/shmdrv/shmdrvapi.c * shmdrv API: correct sign of return value on mmap() failure
[00:51:03] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 9df4259 06linuxcnc 10src/rtapi/shmdrv/shmdrv.c * shmdrv: IOC_SHM_ATTACH return full status of existing segment
[00:51:09] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet ad21610 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem_getptr(): fail with -ENOENT if shm segment not mapped
[00:51:16] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 1f3be77 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem_new_inst: return -EEXIST on mapping a shm segment again
[00:51:23] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 96ac7fd 06linuxcnc 10src/ 10rtapi/rtapi_kdetect.c 10rtapi/rtapi_kdetect.h * kdetect: sync with syndrome used in rtapi_compat.c
[00:51:30] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet c20a32b 06linuxcnc 10src/ 10Makefile.inc.in 10configure.in * configure: add --enable-7i80
[00:51:36] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 20c6122 06linuxcnc 10src/Makefile * Makefile: hm2_eth module build
[00:51:42] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet ed7b307 06linuxcnc 10scripts/linuxcnc.in * scripts/linuxcnc.in: rtnet start/stop
[00:51:48] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 895568f 06linuxcnc 10scripts/ 03start_net.sh 03stop_net.sh * scripts/{start,stop}_rtnet.sh
[00:51:55] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet ef6970b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 03hm2_eth.c 03hm2_eth.h 03lbp16.c 03lbp16.h * hm2_eth: new files hm2_eth.{c,h},lpb16.{c,h}
[00:52:02] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 6512a9c 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h * src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h changes
[00:52:09] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet b4a4202 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c * src/hal/drivers/mesa-hostmot2/hostmot2.c changes
[00:52:16] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet 71614ed 06linuxcnc 10src/hal/drivers/mesa-hostmot2/tram.c * src/hal/drivers/mesa-hostmot2/tram.c changes
[00:52:22] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet f273e6a 06linuxcnc 10src/ 10Makefile.inc.in 10configure.in * configure: add --with-rtnet=<rtnet install dir> option
[00:52:29] <KGB-linuxcnc> 03git 05ubc2-7i80-rtnet ee7645a 06linuxcnc 10src/Makefile * xenomai-user: link hm2_eth.so (hopefully)
[00:52:36] <KGB-linuxcnc> 03TODO: deletor 05ubc2-7i80-rtnet ee7645a 06linuxcnc 04. * branch deleted
[01:01:50] <linuxcnc-build> build #385 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/385 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:01:53] <linuxcnc-build> build #369 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/369 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:02:26] <linuxcnc-build> build #489 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/489 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:03:55] <linuxcnc-build> build #369 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/369 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:05:51] <linuxcnc-build> build #1284 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/1284 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:06:50] <linuxcnc-build> build #1285 of lucid-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1285 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:08:45] <linuxcnc-build> build #395 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/395 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:10:29] <linuxcnc-build> build #1084 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1084 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:13:10] <linuxcnc-build> build #1286 of precise-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1286 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:18:03] <linuxcnc-build> build #1288 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1288 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:25:26] <KimK> Tried to install Gource on 10.04, two problems: (1) couldn't find any libglm-dev, libglm support apparently only available for 12.04 and up? (2) libboost 1.46 or better needed, 10.04 has 1.40 or 1.42. Oh well, maybe 12.04 soon, lol!
[01:27:56] <linuxcnc-build> build #1289 of hardy-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1289 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:31:26] <linuxcnc-build> build #1287 of hardy-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1287 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:32:40] <linuxcnc-build> build #1285 of hardy-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1285 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:35:07] <linuxcnc-build> build #1288 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1288 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:35:38] <linuxcnc-build> build #1288 of lucid-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1288 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[01:35:38] <linuxcnc-build> build #1283 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1283 blamelist: Michael Haberler <mail17@mah.priv.at>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>
[02:37:01] <memleak> KimK, thats why i use gentoo, i get to choose the versions of everything i want :D
[07:14:04] -hitchcock.freenode.net:#linuxcnc-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp
[08:01:55] <jthornton> what section in the ini file does ORIENT_OFFSET go in? For M19 in master
[08:02:47] <jepler> linuxcnc$ git grep ORIENT_OFFSET -- src
[08:02:49] <jepler> src/emc/rs274ngc/rs274ngc_pre.cc: inifile.Find(&_setup.orient_offset, "ORIENT_OFFSET", "RS274NGC");
[08:02:56] <jepler> if this grep is to be believed, it's the [RS274NGC] section
[08:03:00] <jthornton> jepler, thanks
[08:03:26] <jthornton> the -- src means just search that directory?
[08:05:24] <jepler> right
[08:05:39] <jthornton> thanks I'll add that to my cheat sheet
[08:27:32] <mhaberler> jthornton: this is a angular offset to the zero ('oriented' position)
[08:27:49] <mhaberler> oops. misread - sorry
[08:28:11] <jthornton> mhaberler, hi
[08:28:31] <mhaberler> hi John
[08:29:43] <jthornton> rob_h, dug up some info on M19 for the manual so I'm adding it
[08:30:08] <KGB-linuxcnc> 03jthornton 05master 1d06901 06linuxcnc 10docs/src/gcode/m-code.txt * Docs: add info for m19
[08:30:09] <KGB-linuxcnc> 03jthornton 05master 2bb2ce6 06linuxcnc 10docs/man/man9/motion.9 10src/hal/components/orient.comp * Docs: fix typos
[08:30:55] <jthornton> the only thing not clear to me is where you connect the spindle encoder to in hal?
[08:32:43] <mhaberler> there's an example config. hold on
[08:33:58] <mhaberler> hm, that might not have made it from my mill to the config section, let me dig out the working one which I use
[08:37:25] <mhaberler> well I have the spindle encoder on a pid loop; have a look at the HAL USGAGE section in orient.9 , and have a look at my mill config:
[08:37:35] <mhaberler> http://git.mah.priv.at/gitweb?p=emc-mill.git;a=shortlog;h=refs/heads/remapped-toolchange-touchoff-plus-new-M19
[08:38:09] <mhaberler> the last 10 or so commits were about getting the orient loop going
[08:38:34] <mhaberler> thanks for the docs! my bad
[08:39:59] <mhaberler> actually the orient command can work in parallel with say a rapid move (something robh requested because he can squeeze out half a sec or so out of a tc ;)
[08:40:27] <mhaberler> I'll be off but on mail for a while shortly
[08:48:59] <jthornton> ok thanks
[10:10:54] <jepler> jthornton: you might consider if there's a better way to word the documentation for arcs that specify a P number, see the thread staring here:
http://mid.gmane.org/044c01ce9df6%24fb7cd160%24f2767420%24%40franksworkshop.com.au
[10:20:37] <cradek> I wonder what it thinks it's specifying with P4.553186
[10:21:57] <cradek> seems awfully fragile and overspecified if you have to give the endpoint and center and exact fractional number of turns
[10:23:15] <JT-Shop> so this is not correct? "To program an arc that gives more than one full turn, use a P word specifying the number of full or partial turns of arc."
[10:24:06] <cradek> it is correct but apparently not as clear as it might be?
[10:24:29] <cradek> For example, if an arc is programmed with P2, the resulting motion will be more than one full circle and up to two full circles (depending on the programmed endpoint.)
[10:24:43] <JT-Shop> ah I got it now
[10:24:45] <cradek> I think this following sentence clarifies it
[10:25:49] <JT-Shop> yes it is clear to me now that a few more words are needed to be clear about how to program P
[10:26:11] <JT-Shop> I'll get that fixed while eating lunch
[10:26:17] <cradek> it would be awesome if you also knew which words those are :-)
[10:26:35] <cradek> thanks
[10:26:41] <JT-Shop> I can take a good guess at them
[10:27:01] <skunkworks> oh - so you have a start and end point what has to be the right number of rotations+fractional of P
[10:27:01] <JT-Shop> now that I understand how it works
[10:27:29] <skunkworks> I had always done full circles - never thought of that...
[10:27:30] <JT-Shop> so if you program a 1/4 arc with P2 you get 1 1/4 turns
[10:28:22] * JT-Shop goes to see how the Discovery 308 feels about running today
[10:28:26] <cradek> JT-Shop: yes
[10:29:10] <cradek> for each P increment above 1 it adds an extra full circle to your normal arc
[11:03:59] <tjtr33> zultron, (anyone :) if i want to use 0MQ to show hal pins on a web page, would i add server code to halcmd_main.c ? ( in main() )
[11:47:41] <zultron> tjtr33, mhaberler's the zmq guy. Give him a ping.
[11:47:45] <zultron> (when he's online)
[12:04:04] <tjtr33> zultron, thx will do
[13:22:53] <jepler> cradek: I wonder whether there are bad consequences of using ceil() on the P value, so that you could specify 3.5 for 3 and a half turns...
[13:23:20] <jepler> it would change some existing gcode: P1.0000001 would currently specify one turn or less but would specify greater than one turn but less than two turns under my idea
[13:24:03] <andypugh> ceil (P - eps) ?
[13:24:26] <jepler> so that P0.999999 would do between 1 and 2 turns?
[13:24:36] <jepler> (if eps is > .000001)
[13:26:09] <andypugh> Well, as both are currently disallowed I don't think you need to worry about breaking existing code.
[13:26:48] <jepler> numbers close to whole numbers (within .001) are currently allowed
[13:26:49] <jepler> int p_value = round_to_int(block->p_number);
[13:26:49] <jepler> CHKS(((motion == G_2 || motion == G_3 || (block->m_modes[7] == 19)) &&
[13:26:52] <jepler> fabs(p_value - block->p_number) > 0.001),
[13:26:55] <jepler> _("P value not an integer with M19 G2 or G3"));
[13:27:02] <jepler> so right now P1.0001 is accepted and means the same as P1
[13:27:25] <jepler> it's easiest to change nothing, I suppose
[13:27:28] <andypugh> Oh dear.
[13:29:14] <jepler> it's a typical pattern in rs274ngc, because the P-value might come from a calculation
[13:30:19] <jepler> for example if you knew the number of degrees of helix you wanted
[13:31:01] <andypugh> I was going to sugggest that it was unlikely, but actually it would be perfectly reasonable for a spiral milling operation with constrained depthper-pass
[13:31:19] <jepler> that's a good example too
[13:31:46] <jepler> though I think in these cases where you're calculating the value you'd end up using the fup[] function to perform the rounding to an integer in gcode
[13:32:05] <jepler> fup[#<depth>/#<depth_per_pass>]
[13:33:18] <jepler> fup is like ceil but with a stranger name
[13:34:56] <andypugh> A variant of "fix" I would guess.
[13:35:06] <jepler> yes
[13:35:11] <jepler> not short for f--- up
[13:37:03] <cradek> jepler: it would then happily accept overconstrained but inconsistent arcs
[13:37:57] <cradek> e.g. the ceil and endpoint give you 1 1/4 turns, but you've specified 1.53211 turns for some reason
[13:38:38] <jepler> cradek: I can see your point
[13:38:50] <cradek> I don't think it's a good idea to allow new kinds of errors go by unchecked, and I also think it's a bad idea to check them (making it really overconstrained and finicky to use, as well as breaking all existing code)
[13:39:24] <jepler> I think the problem is mostly the wording of the documentation
[13:39:25] <cradek> so my feeling is no, don't mess with it, it's fairly correct as-is
[13:40:10] <cradek> my feeling is the first sentence is poor, but the following few sentences clarify it, and in this case the guy stopped reading after the first sentence could be made to match what he expected to see
[13:40:20] <cradek> a better first sentence would be great
[13:41:28] <jepler> I didn't actually look at the docs but I read the sentence that was quoted in the message :-P
[13:41:56] <cradek> heh
[15:24:59] <andypugh> I wonder if I can put my git repo on my NAS rather than on the actual LinuxCNC machine?
[15:29:32] <cradek> the home directory (and other important directories) on my main machine is nfs and git (and everything else) works fine