#linuxcnc-devel | Logs for 2016-05-10

Back
[00:14:43] <seb_kuzminsky> oh i see, i wasnt considering enough of the nested switch statements in task
[00:15:45] <seb_kuzminsky> EMC_TASK_PLAN_OPEN *is* allowed without Mode=Auto in State={OFF,ESTOP,ESTOP_RESET}, but in State=On it's only allowed if Mode=Auto
[00:16:50] <seb_kuzminsky> which means my 5fb0e817 is buggy, since it doesn't enforce Mode=Auto if State=On
[00:21:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master e15d107 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Revert "axis: call linuxcnc.task_plan_synch() to force a var file write" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e15d107
[00:22:04] <linuxcnc-build> build #3341 of 2000.docs is complete: Failure [4failed rsync-docs-to-www.linuxcnc.org] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/3341 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:43:27] <linuxcnc-build> build #4104 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4104 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:04:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48: https://github.com/LinuxCNC/linuxcnc/pull/48/commits/59847ca427716c23fae63cf331d3040eb82d666a:... 02https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218071247
[06:32:05] <skunkworks__> This laptop runs 73c running rt_preempt.
[06:56:49] <Tom_itx> missed some logs... loss of power
[07:09:19] <jepler> skunksleep: a little toasty!
[07:11:53] <skunkworks_> a little ;)
[07:28:55] <skunkworks_> Inverting the pocket signal fixed the off by 1 tool chain homing
[07:42:11] <skunkworks_> fun things you think about a you're drifting off to sleep
[07:42:22] <skunkworks_> *as
[07:43:17] <skunkworks_> the pocket senor was a prox sensor. when it was hooked into the opto22 board - we didn't know if it was the correct logic
[07:44:24] <skunkworks_> *didn't think about it not being the correct logic
[08:21:51] <als_> cradek, http://pastebin.com/jvuiaqtA probably should have made the changes this way in hind sight ,Sorry!
[08:25:37] <KGB-linuxcnc> 03Al Smart 05master fd36b4b 06linuxcnc 10docs/src/gui/pyvcp.txt 10lib/python/pyvcp_widgets.py standardized a python null pointer & fix a docs error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd36b4b
[08:25:54] <cradek> thanks!
[08:31:05] <als_> thank you
[08:40:18] <KGB-linuxcnc> 03Jeff Epler 052.6 3724b9b 06linuxcnc 10configs/sim/manual-example.ui configs: let it trigger a gladevcp bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3724b9b
[08:40:18] <KGB-linuxcnc> 03Jeff Epler 052.6 409125e 06linuxcnc 10lib/python/gladevcp/hal_actions.py gladevcp: Fix mdi error with tiny values * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=409125e
[08:41:09] <KGB-linuxcnc> 03Jeff Epler 052.7 23aafb0 06linuxcnc 10lib/python/gladevcp/hal_actions.py Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=23aafb0
[08:42:02] <KGB-linuxcnc> 03Jeff Epler 05master 6c0b1f9 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis: use task_plan_synch instead of unneeded change to MODE_MDI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c0b1f9
[09:18:46] <skunkworks__> disabled a few things in the bios like speedstepping and now the temp is 56
[09:18:48] <skunkworks__> c
[09:19:00] <skunkworks__> (spu is now 2.8ghz
[09:20:07] <skunkworks__> (cpu now is at 2.8ghz instead of 3.4)
[09:27:13] <skunkworks__> that is much better.. No thermal melt down.
[09:35:35] <skunkworks__> heh - servo-thread.tmax is 769us...
[09:35:44] <skunkworks__> so far
[09:36:24] <skunkworks__> still running though
[09:36:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #48: I just noticed that the commits on your branch do not follow our policy. You must provide a signed-off-by line in the commit message, to certify that you are submitting your patches under our license, GPLv2+. For more information, http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy... 02https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-21816
[09:41:56] <pcw_home> skunkworks__ servo-thread.tmax is probably determined by hm2_blahblah-read.tmax
[09:43:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48: Yes, I'd like to know if there is an elegant way to add a signed-off-by line to each commit of mine. 02https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218171144
[09:47:41] <pcw_home> if these latency peaks are rare you can choose to just drop the read and try again next cycle
[09:47:42] <pcw_home> by using Jeplers eth-packet-loss branch and setting the read timeout to say 500 usec (50%)
[09:48:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #48: I use something like this:... 02https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218172754
[10:02:46] <skunkworks__> cool - have to try that
[10:04:57] <pcw_home> you do need to set your following errors wide since motion will see stale position data
[10:04:59] <pcw_home> (the actual errors caused by the stale data are not bad and can largely be tuned around)
[10:07:46] <skunkworks__> read timeout is currently set at 80
[10:07:58] <jepler> .. which means 80% of thread period
[10:08:33] <skunkworks__> easy enough
[10:08:49] <jepler> if the value is >100 then it is in ns
[10:08:53] <jepler> I got a little too clever :-/
[10:08:56] <pcw_home> I had it running with about 5% packet loss yesterday, it eventually reached the fatal error trip point after a couple hours
[10:08:57] <pcw_home> where I think this can be useful is systems (like this one ) that may get a error once a day or so at 3 KHz
[10:10:46] <skunkworks__> random thread that made me laugh. http://www.cnczone.com/forums/uccnc-control-software/307124-random-feed.html
[10:15:36] <skunkworks__> latency test runs great for days - linuxcnc runs great for days but when I try to run the 7i92 it will trip a realtime error after 20 minutes
[10:15:46] <skunkworks__> something with the nic maybe
[10:16:58] <pcw_home> check the read tmax
[10:17:01] <skunkworks__> 82579LM
[10:17:29] <pcw_home> you have irq coalesing off?
[10:18:17] <skunkworks__> yes - setup according to the hm docs
[10:19:25] <pcw_home> what do ping times look like?
[10:20:29] <pcw_home> like:
[10:20:31] <pcw_home> sudo chrt 99 ping -i .001 10.10.10.10 > foo
[10:22:10] <skunkworks__> the read.tmax is currently running at 489us
[10:22:30] <skunkworks__> and now a realtime error
[10:22:35] <skunkworks__> let me run the shrt
[10:22:37] <skunkworks__> chrt
[10:22:54] <mozmck> Interesting quote from the thread skunkworks__ just posted, "space industry applications they have started reverting back to rs232 from ethernet because its more reliable."
[10:23:01] <mozmck> Anyone know if that is true?
[10:25:33] <mozmck> It would not really surprise me - rs232/485 is reliable and simple.
[10:26:07] <pcw_home> a lot less software/hardware involved
[10:27:33] <pcw_home> on the other hand ive now had a 7I76E running at work for almost 2 years (and close to one year at 4 KHz) with not a single packet lost
[10:27:43] <skunkworks__> .246ms pings
[10:27:47] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sirop commented on issue #48: Ok, it was `git rebase -i HEAD~3 --exec="git commit --amend -CHEAD -s" PktUART_LinuxCNC` .... 02https://github.com/LinuxCNC/linuxcnc/pull/48#issuecomment-218185417
[10:28:03] <pcw_home> thats fairly terrible
[10:29:23] <pcw_home> PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
[10:29:24] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.085 ms
[10:29:26] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.067 ms
[10:29:27] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.068 ms
[10:29:29] <pcw_home> 64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.067 ms
[10:30:00] <KGB-linuxcnc> 03Jeff Epler 05master 645fef3 06linuxcnc Merge branch 'PktUART_LinuxCNC' of https://github.com/sirop/machinekit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=645fef3
[10:30:26] <skunkworks__> oh well
[10:30:36] <pcw_home> are you sure irq coalescing is off? doesnt look like it
[10:33:37] <skunkworks_> http://pastebin.com/eSxU9Dwp
[10:34:22] <skunkworks__> what was the command line to do it?
[10:35:02] <pcw_home> sudo ethtool -C ethN rx-usecs 0
[10:36:15] <skunkworks__> so.. that worked - <100us
[10:36:35] <skunkworks__> do you need ethtools installed for the line in the interface to work?
[10:36:43] <skunkworks__> I didn't have it installed
[10:36:56] <skunkworks__> let me reboot and see
[10:38:08] <pcw_home> yeah the interfaces file needs to have ethtool installed to do those tweaks
[10:38:36] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #48: PktUART driver for MESA (06master...06PktUART_LinuxCNC) 02https://github.com/LinuxCNC/linuxcnc/pull/48
[10:38:43] <seb_kuzminsky> yay!!
[10:39:26] <skunkworks__> yes - now it has <100us ping times
[10:46:10] <skunkworks_> still get a realtime error
[10:46:23] <skunkworks_> let me run a non-ethernet config just to make sure my memory
[10:57:34] <pcw_home> Heres the stuff that I look at to see where the time goes:
[10:57:35] <pcw_home> http://freeby.mesanet.com/my.halshow
[10:57:37] <pcw_home> (you will have to change the 7i76e's to 7i92's)
[12:05:44] <skunkworks_> cradek, jepler, does this work? http://pastebin.com/qygLPPTK
[12:08:01] <seb_kuzminsky> looks good to me skunkworks_
[12:08:34] <skunkworks_> the html/pdf docs get created from that - correct?
[12:09:06] <seb_kuzminsky> yeah, that's right
[12:09:11] <seb_kuzminsky> do you want me to push that to master?
[12:09:23] <jepler> 2.7 I imagine
[12:09:41] <skunkworks_> I would think 2.7
[12:09:43] <skunkworks_> right
[12:09:50] <seb_kuzminsky> k
[12:11:29] <seb_kuzminsky> skunkworks_: is that output from "git show"?
[12:11:41] <skunkworks_> git gui..
[12:12:21] <seb_kuzminsky> run 'git format-patch HEAD^' and paste the result, it'll be easier to apply correctly
[12:12:47] <skunkworks_> ok
[12:14:33] <seb_kuzminsky> should our uspace debian package Recommend ethtool, so it gets installed by default but can be removed without removing linuxcnc.deb?
[12:15:09] <skunkworks_> http://pastebin.com/uwV2hD7c
[12:15:13] <skunkworks_> is that better?
[12:17:07] <seb_kuzminsky> yeah, that's the right format
[12:17:20] <skunkworks_> ok - I will remember that - thanks
[12:17:46] <seb_kuzminsky> hm, for some reason it dropped the SoB line that you added
[12:18:05] <seb_kuzminsky> maybe because the commit message is otherwise empty?
[12:18:47] <skunkworks_> ? Signed-off-by: Sam Sokolik <samcoinc@gmail.com>
[12:18:49] <seb_kuzminsky> yeah, if i add a non-header-looking line before the SoB it works fine
[12:19:38] <skunkworks_> heh - I was trying to do it without asking questions ;)
[12:19:43] <KGB-linuxcnc> 03Sam Sokolik 052.7 6ceba7a 06linuxcnc 10docs/man/man9/hm2_eth.9 irq-coalesce requires ethtools * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ceba7a
[12:25:40] <skunkworks__> OOOooohhh
[12:28:09] <skunkworks__> running an hour with a non-ethernet config - no issues. 74us tmax servo thread
[12:52:26] <skunkworks__> does motion.servo.overruns not increment in uspace?
[12:53:37] <skunkworks__> or doesn't unexpected realtime delay equal motion.servo overrun?
[13:01:33] <pcw_home> Dont remember if Ive ever seen it increment
[13:03:13] <pcw_home> but if you get a real time error with Ethernet, look at the things in that halshow file
[13:10:20] <jepler> src/emc/motion/motion.c: hal_param_u32_new("motion.servo.overruns", HAL_RW, &(emcmot_hal_data->overruns), mot_comp_id);
[13:10:23] <jepler> src/emc/motion/motion.c: emcmot_hal_data->overruns = 0;
[13:10:28] <jepler> it's only ever assigned 0, in 2.6 branch, regardless of RTOS
[13:10:38] <seb_kuzminsky> lol
[13:10:39] <jepler> er 2.7
[13:10:47] <jepler> after I took out the heuristic overrun detection code
[13:14:33] <jepler> seb_kuzminsky: any reason not to https://emergent.unpythonic.net/files/sandbox/0001-motion-remove-overruns-parameter.patch ?
[13:17:28] <seb_kuzminsky> looks ok, remove it from the struct too
[13:17:35] <jepler> ah yep
[13:17:42] <seb_kuzminsky> if someone has it linked it'll break their hal file :-(
[13:17:46] <jepler> it's a param
[13:17:55] <seb_kuzminsky> oh!
[13:18:10] <seb_kuzminsky> so they'd have to script halcmd to access it
[13:18:16] <seb_kuzminsky> that's probably fine to remove
[13:18:24] <jepler> patch updated https://emergent.unpythonic.net/files/sandbox/0001-motion-remove-overruns-parameter.patch
[13:19:22] <seb_kuzminsky> https://www.youtube.com/watch?v=vCadcBR95oU
[13:22:31] <jepler> should I watch the whole video first?
[13:22:41] <seb_kuzminsky> yes
[13:26:10] <KGB-linuxcnc> 03Jeff Epler 052.7 01e82b2 06linuxcnc 10(5 files in 3 dirs) motion: remove overruns parameter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01e82b2
[13:26:52] <seb_kuzminsky> sharp!
[13:28:34] <skunkworks_> http://imgur.com/5BxlcJV
[13:31:29] <skunkworks_> pcw_home, ^
[13:34:22] <skunkworks__> if I read that right - the read time spikes before the servo thread
[13:36:04] <PCW> so whats the read-time.tmax?
[13:38:14] <skunkworks_> 191688428.. 68ms
[13:38:24] <skunkworks_> :)
[13:39:16] <skunkworks_> maybe the ethernet on this laptop goes through usb ;)
[13:42:35] <PCW> The USB-Ethernet adapter I have works much better than that :-)
[13:43:14] <PCW> it will even run a hour or so at 1 KHz before it gets a 10 ms delay
[13:44:19] <PCW> wonder what triggers that ( Ethernet power management? )
[13:45:26] <PCW> Is this the Laptop?
[13:48:33] <skunkworks__> yes
[13:48:52] <skunkworks__> let me look through the bios
[13:53:42] <skunkworks__> yah - I don't see anything
[13:54:32] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 8ae3058 06linuxcnc 10(54 files in 3 dirs) docs/src/motion/5-axis-kinematics.txt new doc JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8ae3058
[13:55:35] <PCW> As Ive said before the Dell laptop works OK as long as you dont touch the backlight controls
[13:56:10] <skunkworks__> same here. Just don't use the ethernet ;)
[13:57:01] <PCW> I have not tried the latest kernel on the laptop you might try the latest 3.18 kernel
[13:59:04] <PCW> looks like that's 3.18.29-rt30
[14:03:10] <skunkworks__> don't think it is smi - it runs longer than a couple minutes
[14:05:31] <PCW> and its not a lost packet, it eventually gets around to receiving it
[14:06:15] <skunkworks__> something just gets hung up.
[14:06:28] <skunkworks__> I will have to try the 3.18 kernel when I get a chance
[14:07:13] <PCW> make sure the kernel config or kernel command line settings are for performance mode
[14:09:04] <skunkworks__> this time it was only 2.3ms ;)
[14:10:08] <PCW> Yeah those sound like power management, not sure what else can take so long
[14:12:48] <PCW> I'd try a different kernel before giving up, I've found the 4.4 kernels rather flakey
[14:12:49] <PCW> ( though they might be needed to run really new hardware like my N3150 based Zotac mini PC)
[14:13:08] <archivist> any of the motherboards have phone home causing problems?
[14:13:45] <PCW> not that Ive seen
[14:16:34] <PCW> a couple days uptime with Preempt-RT:
[14:16:36] <PCW> http://freeby.mesanet.com/3.18.11-rt7.png
[14:19:21] <skunkworks_> the latency looks really good on this thing too - just the ethernet doesn't play well
[14:21:18] <jepler> if that thing has expresscard you could always try a plug-in adapter http://www.newegg.com/Product/Product.aspx?Item=9SIA3912D67735 though I don't even know the state of expresscard support in linux so word of caution
[14:25:11] <skunkworks_> I had that in the back of my mind..
[14:44:03] <skunkworks__> http://imgur.com/buaT6zQ
[14:46:28] <skunkworks_> heh - the second you ping the mesa card you get a 600us delay
[14:49:50] <jepler> that's no good
[15:04:08] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 4a3801e 06linuxcnc 10(5 files in 3 dirs) EU_Surplus_FastSeal_0_6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a3801e
[17:03:55] <tinkerer> hi mesa experts
[17:05:38] <tinkerer> have someone a simple working example config for the 7i90 and steppers for testing?
[17:09:22] <PCW> you could use a 7i43 sample config and just change a name or 2
[17:10:00] <tinkerer> ok thanks
[18:04:12] <tinkerer> PCW: forward stepping works but backward I get a following error. hmmm...?
[18:19:59] <PCW> thats pretty strange
[18:20:09] <PCW> what hardware?
[18:21:32] <tinkerer> 7i90 over spi and raspberrypi2 :)
[18:22:16] <tinkerer> I've wrote a driver for the raspi
[18:23:55] <tinkerer> now I'm testing it without motors. just logic analyzer
[18:24:07] <PCW> I've seen this before, I think is a ARM issue
[18:24:49] <PCW> something busted with float/integer conversions
[18:25:09] <tinkerer> hmm, which kind? it works with my pluto well
[18:25:14] <tinkerer> ahhhh
[18:25:31] <tinkerer> ok, thanks for the hint
[18:25:55] <tinkerer> maybe rtai_math?
[18:26:32] <PCW> is this linuxcnc or machinekit (and what version)? I think this showed up running hm2_eth on a ARM host
[18:26:47] <tinkerer> machinekit
[18:27:59] <PCW> I thought this was fixed with machinekit but not sure when or how or if they do versions
[18:29:36] <tinkerer> is this a hostmot2 issue?
[18:30:28] <tinkerer> 'cos as I said my pluto driver works well.
[18:31:50] <PCW> Can't remember if its a hostmot2 issue or ARM math issue but the code that trips the bug is in hostmot2
[18:31:52] <PCW> (I dont remember the details but I think a float to 32 integer conversion is broken on ARM, = sign lost)
[18:33:08] <PCW> (in the stepgen and possibly elsewhere)
[18:33:16] <tinkerer> ok, thanks for the hint. will dig in :)
[18:47:41] <PCW> looks like a hostmot2 stepgen bug that happens to work on x86 (its been fixed for a while in linuxcnc)
[18:48:07] <PCW> stepgen.c line 275
[18:48:59] <tinkerer> yes, who else, if not jepler have fixed it :) http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/hal/drivers/mesa-hostmot2/stepgen.c;h=85060ee764b432f2bade32c875c29b0156508c78;hp=a971847d4da6b8978d2171f800a79ac89c4d2f98;hb=8b536f47153db14bf6001c3c1c7b69bcc84b6389;hpb=e082ca2f983a87357081afdd23e15b45ebe017e7
[19:43:32] * jepler bows
[19:43:48] <jepler> PCW: not broken, the conversion is undefined by the C standard
[19:44:48] <PCW> Ahh but just happened to work on x86
[19:45:43] <jepler> yes exactly
[19:46:15] <jepler> tinkerer: is this bitbang spi? the driver in our 2.7 / master branch should work with /dev/spidev on any system
[19:47:09] <jepler> .. but my experience with #platforms=1 is that the kernel spi driver had bad latency until I made some changes (which are in a git somewhere, some generic and some specific to odroid s3 spi hardware)
[19:47:13] <jepler> (u3?)
[19:49:16] <tinkerer> jepler: no not bitbang it's a specific one like in my spi pluto driver. https://github.com/tinkercnc/spi-fpga-driver/tree/master/RaspberryPi
[19:51:00] <tinkerer> avoiding the spidev issues
[20:18:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #61: axis feature request: touch-off should default to the active coordinate system 02https://github.com/LinuxCNC/linuxcnc/issues/61
[20:25:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 693c861 06linuxcnc 10src/hal/drivers/mesa-hostmot2/pktuart.c pktuart: fix a printf format error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=693c861
[20:38:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 27a67cd 06linuxcnc 10src/emc/task/emctaskmain.cc task: allow EMC_TASK_PLAN_OPEN when State=On, Mode=Manual * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=27a67cd
[20:38:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ad06db2 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Axis: don't need to switch to Auto to load a program * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ad06db2
[20:38:26] <seb_kuzminsky> second(?) time's the charm, i hope
[21:32:20] <skunksleep> andypugh: Carousel is working great. Just moved the index
[21:33:17] <andypugh> If you can see any improvements it needs, let me know. it’s hard to make a good job of a tool changer component when you don’t have a tool changer.
[21:35:14] <skunksleep> Heh. Jog inputs, I will play with it some more for sure
[21:36:45] <andypugh> Ah, yes. You could fake it in HAL, bit that would get messy.
[21:36:55] <skunksleep> Are you in Dearborn?
[21:37:24] <skunksleep> Right
[21:42:04] <andypugh> I am not sure if I am technically in Dearborn or Allen Park right now. I think this is Dearborn. Staying here: https://en.wikipedia.org/wiki/The_Dearborn_Inn which is rather nice
[21:46:54] <skunksleep> Just a lake and part of a state between us..
[21:49:53] <linuxcnc-build> build #297 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/297 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:57:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 9762247 06linuxcnc 10src/emc/usr_intf/halui.cc halui: check for errors in a non-crazy way * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9762247
[22:13:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp f384c9f 06linuxcnc 10src/Makefile build: warn about incorrect function overloading * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f384c9f
[22:13:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp e8dd762 06linuxcnc 10src/libnml/buffer/tcpmem.cc 10src/libnml/buffer/tcpmem.hh nml: Fix prototypes in class TCPMEM * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8dd762
[22:13:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 251cc34 06linuxcnc 10src/libnml/buffer/tcpmem.cc nml: tcp: copy serial number back to caller * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=251cc34
[22:13:33] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp c3539ed 06linuxcnc 10src/libnml/buffer/rem_msg.hh 10src/libnml/buffer/tcpmem.cc 10src/libnml/cms/tcp_srv.cc 10src/libnml/nml/nml_srv.cc nml: tcp: arrange to transport write_id back to client * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3539ed
[22:13:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 17f299d 06linuxcnc 10configs/common/linuxcnc.nml 10tests/linuxcncrsh-tcp/tcp.nml configs: must enable "confirm_write" to get serial number return * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17f299d
[22:13:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp c616931 06linuxcnc 10src/libnml/cms/cms.cc nml: trivial typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c616931
[22:13:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp a081b43 06linuxcnc 10src/libnml/cms/cms.cc 10src/libnml/cms/cms.hh 10tests/linuxcncrsh-tcp/tcp.nml nml: add 'serial' flag to do command serial-number stuff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a081b43
[22:13:50] <jepler> (just rebasing the branch; if it passes tests I intend to merge it to master though)
[22:13:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp d5789cc 06linuxcnc 10src/libnml/nml/nml_srv.cc nml: write the serial number into the command as seen by task * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d5789cc
[22:13:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 9c925b8 06linuxcnc 10configs/common/client.nml 10configs/common/linuxcnc.nml 10configs/common/server.nml fix other nmlfiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c925b8
[22:13:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp b3c8922 06linuxcnc 04tests/linuxcncrsh-tcp/skip tests: linuxcncrsh-tcp test now passes for me * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3c8922