Back
[00:10:59] -!- rob_h has quit [Ping timeout: 272 seconds]
[00:26:45] -!- micges has quit [Quit: Ex-Chat]
[00:35:10] -!- zzolo has quit [Quit: zzolo]
[00:39:40] <linuxcnc-build_> build #234 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/234 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:39:43] -!- erve has quit [Ping timeout: 258 seconds]
[00:43:10] -!- theorbtwo has quit [Ping timeout: 258 seconds]
[00:46:50] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[00:48:15] <PCW> All 7i90 configs now have ICAP support
[00:48:56] <PCW> and may even work
[00:51:19] <linuxcnc-build_> build #1622 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1622 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:57:18] -!- almccon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
[01:03:12] -!- anth0ny has quit [Quit: anth0ny]
[01:04:59] <jepler> hmmm it's a feature that modules are removed in reverse order that they're inserted
[01:05:06] <jepler> important when they have dependencies
[01:05:46] <jepler> so in one place or the other it'll have to iterate in the reverse way
[01:06:56] <jepler> I might as well just change 'save' to go in reverse order, then
[01:08:56] <linuxcnc-build_> build #2421 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2421 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:08:57] <linuxcnc-build_> build #2429 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2429 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:11:16] <cradek> mind-readers to the bug tracker, stat
[01:12:49] <jepler> user probably has some physical controls driving feedrate via halui
[01:17:40] -!- syyl_ has quit [Ping timeout: 258 seconds]
[01:17:50] <cradek> I don't know how absolute-positioned controls are supposed to work with halui, but I do know they're a bad idea
[01:18:48] -!- skorasaurus has quit [Remote host closed the connection]
[01:23:41] <jepler> on the other hand, you do know they're commonly seen on panels of "real" machines
[01:24:37] <cradek> yes right next to the tape reader
[01:28:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 dadb984 06linuxcnc 10src/hal/utils/halcmd_commands.c 10tests/save.0/test.hal hal: make 'save comp' order match original 'loadrt' order * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dadb984
[01:28:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 6d51c1e 06linuxcnc 04tests/save.0/test.hal 03tests/save.0/test.sh tests: save.0: use expected result as hal script too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6d51c1e
[01:28:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05jepler/proposed-2.6 c275dc0 06linuxcnc 10scripts/linuxcnc.in DONT PUSH!! debug linuxcnc shutdown * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c275dc0
[01:35:24] -!- now7777 has quit [Ping timeout: 255 seconds]
[01:37:06] -!- mhaberler has quit [Quit: mhaberler]
[01:40:21] -!- erve has quit [Ping timeout: 255 seconds]
[01:42:58] -!- ries has quit [Ping timeout: 250 seconds]
[01:45:07] -!- tchaddad has quit [Remote host closed the connection]
[01:45:59] -!- sylphiae has quit [Ping timeout: 272 seconds]
[01:48:00] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[01:49:13] <linuxcnc-build_> build #235 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/235 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[01:58:31] -!- ries has quit [Quit: ries]
[02:00:26] <linuxcnc-build_> build #1623 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1623 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[02:00:43] -!- rythmnbls has quit [Quit: Leaving]
[02:03:36] <linuxcnc-build_> build #2422 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2422 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[02:03:37] <linuxcnc-build_> build #2430 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2430 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Jeff Epler <jepler@unpythonic.net>
[02:14:00] -!- mozmck has quit [Read error: Connection reset by peer]
[02:14:34] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[02:24:22] -!- AR_ has quit [Ping timeout: 258 seconds]
[02:30:51] -!- mhaberler has quit [Quit: mhaberler]
[02:31:12] -!- skorasaurus has quit [Ping timeout: 255 seconds]
[02:35:21] <jepler> linuxcnc-build_: force build --branch=2.6 0000.checkin
[02:35:22] <linuxcnc-build_> build forced [ETA 1h00m03s]
[02:35:22] <linuxcnc-build_> I'll give a shout when the build finishes
[02:37:17] -!- DaViruz has quit [Ping timeout: 272 seconds]
[02:42:06] -!- erve has quit [Ping timeout: 272 seconds]
[02:45:57] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[02:55:27] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[02:57:18] -!- tchaddad has quit [Ping timeout: 272 seconds]
[03:01:21] -!- HeXiLeD has quit [Ping timeout: 255 seconds]
[03:15:22] -!- revo14 has quit [Remote host closed the connection]
[03:20:55] -!- Connor_iPad has quit [Quit: I'm Gone!]
[03:26:37] -!- revo14 has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
[03:31:50] <linuxcnc-build_> Hey! build 0000.checkin #2431 is complete: Success [3build successful]
[03:31:50] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2431
[03:42:28] -!- erve has quit [Ping timeout: 260 seconds]
[03:47:19] -!- tchaddad has quit [Remote host closed the connection]
[03:56:15] -!- patrickarlt has quit [Remote host closed the connection]
[03:58:22] -!- zzolo has quit [Quit: zzolo]
[04:01:54] -!- patrickarlt has quit [Ping timeout: 272 seconds]
[04:22:11] -!- FinboySlick has quit [Quit: Leaving.]
[04:43:19] -!- erve has quit [Ping timeout: 272 seconds]
[04:58:28] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[05:01:25] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[05:01:57] -!- _Fox_Muldr has quit [Ping timeout: 255 seconds]
[05:07:30] -!- patrickarlt has quit [Quit: Leaving...]
[05:09:06] -!- erictheise has quit [Read error: Connection reset by peer]
[05:12:02] -!- kwallace [kwallace!~kwallace@smb-229.sonnet.com] has parted #linuxcnc-devel
[05:28:57] -!- H3XIL3D has quit [Ping timeout: 255 seconds]
[05:34:52] -!- steves_logging has quit [Ping timeout: 245 seconds]
[05:57:22] -!- ve7it has quit [Remote host closed the connection]
[06:16:40] -!- syyl_ has quit [Ping timeout: 258 seconds]
[06:20:29] -!- anth0ny has quit [Quit: anth0ny]
[06:21:23] -!- f1oat [f1oat!~f1oat@AMontsouris-553-1-63-248.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[06:24:12] -!- balestrino has quit [Ping timeout: 250 seconds]
[06:28:43] -!- ITChap has quit [Quit: Leaving.]
[06:37:48] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[06:49:59] -!- Tecan has quit [Ping timeout: 272 seconds]
[06:51:03] -!- The_Ball has quit [Remote host closed the connection]
[06:52:50] -!- jerryitt_ has quit [Quit: Connection closed for inactivity]
[06:55:17] -!- erictheise has quit [Quit: erictheise]
[07:22:03] -!- rob_h [rob_h!~robh@176.254.105.27] has joined #linuxcnc-devel
[07:31:14] -!- f1oat has quit [Quit: Nettalk6 - www.ntalk.de]
[07:43:45] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[07:58:57] -!- balestrino has quit [Ping timeout: 245 seconds]
[07:59:34] -!- asah has quit [Quit: asah]
[08:01:24] -!- micges [micges!~micges@aeis161.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[08:04:26] -!- Valen has quit [Quit: Leaving.]
[08:12:51] -!- GJdan has quit [Quit: WeeChat 1.0-dev]
[08:14:31] -!- Valen has quit [Remote host closed the connection]
[08:18:08] -!- Valen has quit [Client Quit]
[08:18:09] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[08:26:49] -!- Valen has quit [Client Quit]
[08:45:13] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[08:51:07] -!- phantoxe has quit [Remote host closed the connection]
[08:55:20] -!- micges has quit [Quit: Ex-Chat]
[09:00:20] -!- b_b has quit [Changing host]
[09:05:53] -!- phantoxe has quit [Remote host closed the connection]
[09:14:01] -!- jfrmilner has quit [Quit: bye]
[09:15:41] -!- JLuc69__ has quit [Read error: Connection reset by peer]
[09:22:05] -!- jfrmilner has quit [Quit: bye]
[09:24:55] -!- JLuc69 has quit [Ping timeout: 272 seconds]
[09:26:48] -!- dan2k3k4 has quit [Ping timeout: 258 seconds]
[09:37:03] -!- dan2k3k4 has quit [Ping timeout: 246 seconds]
[09:42:20] -!- toastydeath has quit [Read error: Connection reset by peer]
[09:43:17] -!- dan2k3k4 has quit [Ping timeout: 258 seconds]
[09:44:09] -!- syyl_ws has quit [Quit: Verlassend]
[09:59:10] -!- phantoxe has quit [Remote host closed the connection]
[10:02:34] -!- phantoxe has quit [Remote host closed the connection]
[10:20:48] -!- mhaberler has quit [Quit: mhaberler]
[10:35:37] -!- skunkworks has quit [Ping timeout: 245 seconds]
[10:36:34] -!- zeeshan has quit [Ping timeout: 258 seconds]
[11:31:18] -!- micges [micges!~micges@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:32:39] -!- micges has quit [Client Quit]
[11:33:52] -!- micges-dev [micges-dev!~x@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:39:40] -!- meji3 has quit [Ping timeout: 250 seconds]
[12:00:57] -!- Loetmichel has quit [Ping timeout: 272 seconds]
[12:02:22] -!- TekniQue has quit [Ping timeout: 240 seconds]
[12:08:33] -!- jleh_ has quit [Ping timeout: 272 seconds]
[12:13:30] -!- TekniQue has quit [Changing host]
[12:13:54] -!- mhaberler has quit [Ping timeout: 250 seconds]
[12:14:15] -!- erve has quit []
[12:16:09] -!- the_wench has quit [Ping timeout: 272 seconds]
[12:16:55] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:17:45] -!- archivist has quit [Ping timeout: 260 seconds]
[12:17:47] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[12:18:08] -!- rythmnbls [rythmnbls!~rythmnbls@204.186.88.34] has joined #linuxcnc-devel
[12:18:32] -!- dan2k3k4 has quit [Ping timeout: 258 seconds]
[12:19:32] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[12:20:36] <skunkworks> I have been goofing around with these asus motherboards and finally stuck a newish hd5450 radeon video card in it. It ran overnight with max latency of 16us..
[12:21:09] <skunkworks> Go figure..
[12:22:56] -!- ries has quit [Quit: ries]
[12:24:42] -!- FreezingCold has quit [Ping timeout: 246 seconds]
[12:30:08] -!- basiclaser has quit [Excess Flood]
[12:35:24] -!- syyl has quit [Ping timeout: 260 seconds]
[12:49:42] -!- acdha has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
[12:53:07] -!- BellinganRoy has quit [Ping timeout: 245 seconds]
[12:59:49] <jepler> skunkworks: better if we could do away with the need for a video card at all
[13:00:50] <jepler> it should be feasible to put a color text console in a mesa card, use only ~8 I/Os to hook it to a VGA monitor
[13:01:31] -!- balestrino has quit [Ping timeout: 272 seconds]
[13:09:08] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[13:13:19] <cradek> it's also true that avoiding X is the modern free-thinking thing to do
[13:35:40] Teme2 is now known as Teme
[13:45:26] <seb_kuzminsky> skunkworks: that's great news and an interesting datapoint
[13:51:18] -!- Valen has quit [Remote host closed the connection]
[13:59:52] <pcw_home_> video does seem to be the source of much latency
[13:59:54] <pcw_home_> even with RTAI it looks like interrupts delay hal processes so its not just latency
[13:59:55] <pcw_home_> in starting a thread, theres additional random latency during processing
[13:59:57] <pcw_home_> (halscope something like pid.0.do.pid-calcs.time and note the nice peaks synchronized with axis update rate)
[14:01:29] <micges-dev> with halscope update rate also
[14:01:55] -!- sirdancealot has quit [Ping timeout: 272 seconds]
[14:03:11] -!- phragment has quit [Ping timeout: 272 seconds]
[14:03:39] -!- micges-dev has quit [Quit: Wychodzi]
[14:04:56] <cradek> does that mean rtai isn't working right?
[14:05:25] <pcw_home_> I dont know :-(
[14:16:36] <pcw_home_> http://imagebin.org/319837
[14:16:37] <pcw_home_> for example (the is is preemt-rt but RTAI (at least the 10.04 dist on a D525) looks similar)
[14:17:46] -!- micges-dev [micges-dev!~x@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[14:20:30] -!- kwallace [kwallace!~kwallace@smb-251.sonnet.com] has joined #linuxcnc-devel
[14:29:29] -!- micges-dev has quit [Quit: Wychodzi]
[14:29:40] -!- ted___ has quit [Client Quit]
[14:30:20] -!- t4nk458 has quit [Client Quit]
[14:32:23] -!- micges-dev [micges-dev!~x@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[14:38:24] <jepler> There are lots of shared resources in a modern system
[14:39:38] <jepler> so for example if you are running linuxcnc on a 1 core / 2 thread CPU, the realtime code will execute generally slower when the other thread is also issuing instructions / accessing memory / whatever
[14:40:06] <jepler> though "I changed my video card, and latency went from 200us to 16us" seems like it's in a whole different realm
[14:46:30] <NTU> jepler: i actually traced those latency spikes with video drivers to DDX (xf86-video-*)
[14:46:58] <jepler> so for instance here you see higher times in scope.sample.time while a memory-access-hungry program is running on a different core:
http://pastebin.com/dgBy4Bw4
[14:47:59] <jepler> the program that I ran
http://paste.debian.net/121199/ (exynos 4412 has 1MB L2 cache shared among all cores)
[14:48:18] -!- amiri_ has quit [Ping timeout: 255 seconds]
[14:48:37] <NTU> i figured it out by taking each step of hw accel one by one. KMS only, KMS + DDX + llvmpipe / softpipe, KMS + DDX + mesa hw driver, and KMS + software DDX (xf86-video-modesetting xf86-video-fbdev xf86-video-vesa) + softpipe / llvmpipe
[14:49:02] <jepler> NTU: what is DDX that it can interfere with RTAI meeting its deadlines?
[14:49:44] <pcw_home_> it just means that the latency test only show latency for starting the thread, additional latencies and occur anywhere in the rt code
[14:49:45] <NTU> well xf86-video-ati performs fine for my R9 290 but causes latency spikes with AMD Fusion APUs
[14:49:56] <pcw_home_> can occur
[14:52:28] <NTU> also r9 290 cards have a lot of different code used for them than amd fusion APUs because the hardware design changed dramatically
[14:52:40] <NTU> also r9 290 is external..
[14:52:44] -!- sir_KanguruPT has quit [Quit: Leaving]
[14:52:46] <jepler> NTU: but is DDX something in userspace? if RTAI is operating properly, how can something happening in userspace cause 100us latency?
[14:54:15] <NTU> yes DDX is userspace, its all in /usr/lib/xorg
[14:55:39] <NTU> and the answer to that, seeing how differently latency is with different GPUs but the same driver, is how DDX talks to hardware
[14:56:04] <NTU> if it talks directly to hw then it doesnt matter if its kernel or userspace
[14:57:06] <NTU> from my past Xorg development experience i believe it uses udev to commuicate with GPU (/dev/card/dri)
[14:57:26] <NTU> kernel hands off to DDX
[14:58:55] -!- anarchos2 has quit [Ping timeout: 272 seconds]
[14:59:16] -!- kwallace2 [kwallace2!~kwallace@smb-63.sonnet.com] has joined #linuxcnc-devel
[14:59:57] -!- kwallace has quit [Ping timeout: 272 seconds]
[15:00:16] <NTU> what would be interesting is to have incredibly similar GPUs, both internal and external, and compare latency results between the two
[15:00:59] <NTU> for example radeon 5500m internal vs 5500 external
[15:01:21] <NTU> or whatever GPUs with almost matching model numbers
[15:01:47] <NTU> xf86-video-ati (maybe others) group GPUs to specific sections of driver code
[15:02:19] <NTU> if the numbers are close enough, chances are they will share 100% the same code in DDX
[15:03:03] <NTU> then you can start tracing latency from PCI busses and see where the magic is
[15:03:12] <NTU> (if its even that)
[15:04:17] -!- anth0ny has quit [Quit: anth0ny]
[15:04:44] <NTU> but normally what happens is i work with boards with really slow internal graphics then blow my month's paycheck on the latest GPU that ends up being 1000x faster so its not a really good comparison
[15:08:49] -!- automata has quit [Ping timeout: 272 seconds]
[15:09:24] -!- mle has quit [Ping timeout: 260 seconds]
[15:11:26] -!- steve_stallings [steve_stallings!~Steve@wsip-70-168-134-18.dc.dc.cox.net] has joined #linuxcnc-devel
[15:11:53] steve_stallings is now known as steves_logging
[15:16:02] -!- nofxx has quit [Ping timeout: 245 seconds]
[15:16:39] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[15:25:39] -!- Simooon has quit [Quit: Leaving]
[15:29:22] -!- sirdancealot has quit [Ping timeout: 240 seconds]
[15:42:36] -!- micges-dev has quit [Quit: Wychodzi]
[15:44:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 b215298 06linuxcnc 04tests/save.0/test.hal 03tests/save.0/test.sh tests: save.0: use expected result as hal script too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b215298
[15:44:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05jepler/proposed-2.6 35bd1f4 06linuxcnc 10scripts/linuxcnc.in DONT PUSH!! debug linuxcnc shutdown * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=35bd1f4
[15:44:45] -!- micges [micges!~micges@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:47:17] -!- micges has quit [Client Quit]
[15:48:42] asheppard is now known as sheppard
[15:52:23] -!- micges-dev [micges-dev!~x@aeid247.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[16:07:06] -!- patrickarlt has quit [Ping timeout: 272 seconds]
[16:13:28] <CaptHindsight> http://dri.freedesktop.org/wiki/DDX/
[16:13:58] -!- toner has quit [Ping timeout: 250 seconds]
[16:15:42] <CaptHindsight> my guess was that someone just decided to start writing directly to hardware and figured that nobody would notice
[16:16:24] -!- rob_h has quit [Ping timeout: 246 seconds]
[16:19:22] <jepler> patches for ARM sure make up a substantial fraction of all posts to lkml
[16:26:32] -!- lair82 has quit [Quit: Page closed]
[16:33:17] -!- phantoxe has quit []
[16:34:31] <CaptHindsight> ddx An acronym. aka xf86-video-ati because it makes perfect sense :/
[16:35:22] -!- automata has quit [Ping timeout: 258 seconds]
[16:35:34] <CaptHindsight> I wonder of someone from ubuntu was behind this
[16:35:38] <skunkworks> I even put some older ati rage video and still got the >200 spikes
[16:36:17] <skunkworks> This is the first time I got this motherboard to behave with the wheezy image. (I am booting off the usb live image)
[16:36:26] * skunkworks should look again
[16:36:31] <CaptHindsight> NTU will keep on digging, I'm sure it will eventually get sorted out
[16:36:53] <skunkworks> yep - still 16us
[16:37:38] * skunkworks just orded more of the sapphire video cards.. Approx $30 :)
[16:38:37] -!- automata_ has quit [Ping timeout: 260 seconds]
[16:38:41] -!- automata has quit [Read error: Connection reset by peer]
[16:38:51] <CaptHindsight> skunkworks: is this the mainboard that had the spikes?
http://www.asus.com/Motherboards/M2N68AM_PLUS/specifications/
[16:39:02] <skunkworks> yes
[16:39:13] <skunkworks> The onboard video is really bad..
[16:39:34] -!- automata has quit [Client Quit]
[16:39:40] <CaptHindsight> Nvidia chipset with AMD cpu
[16:41:55] <skunkworks> funny - huh?
[16:42:05] <jepler> there was a time before AMD owned ATI..
[16:42:11] <CaptHindsight> that must have been one of the last ones made
[16:42:13] <skunkworks> rigth
[16:43:02] <skunkworks> I am happy if this solves the problem. We juat have a handful of these boards that we would like to use the up to date wheezy install
[16:43:38] <CaptHindsight> good for a few more years of service
[16:43:51] <skunkworks> sure - they are more than powerful enough
[16:45:26] <skunkworks> CaptHindsight, did you get vison (target aquisition) working with linuxcnc?
[16:45:32] <CaptHindsight> I found a few 15 year old AMD 360Mhz PC's with SiS chipsets with <24 hours on them
[16:45:44] -!- Deejay has quit [Ping timeout: 272 seconds]
[16:45:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 b215298 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b215298
[16:46:08] <jepler> seb_kuzminsky: jepler/proposed-2.6 is ready for your consideration again. this time it even passes the tests.
[16:46:14] <CaptHindsight> skunkworks: yes, and expanding on it now, I have to update the howto
[16:46:55] <CaptHindsight> I want to get it working on wheezy for the howto
[16:47:22] -!- md-2 has quit [Quit: Leaving...]
[16:48:27] <skunkworks> do you actually send the target positions back to linuxcnc?
[16:48:38] <skunkworks> and adjust the 'part' location?
[16:49:32] -!- Tom_L [Tom_L!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[16:49:52] -!- Tom_L has quit [Client Quit]
[16:55:01] -!- Roguish [Roguish!~chatzilla@c-67-188-44-176.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[16:57:46] <seb_kuzminsky> jepler: doesn't that get it wrong if you have any user comps?
[16:59:03] <Roguish> hey all. a quick compile question please. i have done a git pull and want to build the latest version, when i do a dpkg-checkbuilddeps i am missing the mesa files. when i try to install them, they cannot be found "E: Unable to locate package libglul-mesa-dev' what's up? little help please?
[17:00:05] -!- jduhls has quit [Ping timeout: 260 seconds]
[17:00:17] <Roguish> oh, seb_kuziminsky, the tab vs space error is fixed. thank you.
[17:00:26] <Roguish> in the parser.
[17:03:28] <seb_kuzminsky> jepler: elinks
http://highlab.com/~seb/linuxcnc/0001-tests-include-a-user-non-realtime-component-in-the-s.patch
[17:03:38] <seb_kuzminsky> or, you know, without the elinks
[17:04:08] <seb_kuzminsky> funny how things that seem like they should be easy can turn out to be tricky and take days to get right
[17:06:20] -!- Komzzpa has quit [Quit: Konversation terminated!]
[17:06:36] <seb_kuzminsky> Roguish: that's a typo
[17:06:59] <seb_kuzminsky> Roguish: should be libglu1-mesa-dev, with a one
[17:07:30] <seb_kuzminsky> Roguish: thanks for the bug report, and the fixed-report :-)
[17:08:07] <jepler> seb_kuzminsky: I wouldn't expect that version of the test to pass
[17:08:17] <jepler> seb_kuzminsky: since sleep 0.1 is not a hal component
[17:08:29] <seb_kuzminsky> oh
[17:08:34] <jepler> anything that runs a program (via loadusr) just for its side-effect is not going to work with save
[17:08:43] <seb_kuzminsky> i guess i misunderstand what 'halcmd save' is supposed to do
[17:09:18] <jepler> maybe I don't know what 'halcmd save' is supposed to do, but from my understanding of what it does I don't think that it'll do what your patch implies you'd like it to
[17:09:22] <seb_kuzminsky> i only chose sleep after i couldn't find a user component that i thought would work without X (*vcp) and without hardware (vfd drivers)
[17:09:49] * seb_kuzminsky writes a hal user component for the test
[17:09:52] <jepler> halsampler maybe ?
[17:10:34] <jepler> looks like save_comps may only save realtime components anyway
[17:10:46] <jepler> /* only print realtime components */
[17:10:58] <jepler> so there are two reasons it won't work
[17:11:53] <pcw_home_> seb_kuzminsky: looks like there are some leftovers from the watchdog function removal in master:
[17:11:55] <pcw_home_> the time/tmax hal parameters are still there
[17:12:09] <pcw_home_> (and always 0)
[17:12:28] <jepler> pcw_home_: for a transitional period, the watchdog function still exists, and adding it prints a warning
[17:12:36] <jepler> pcw_home_: I think seb_kuzminsky has said he plans to remove it before 2.7.
[17:12:50] -!- jerryitt_ has quit [Quit: Connection closed for inactivity]
[17:13:17] <pcw_home_> ok I see the dummy function has those pins
[17:14:06] <seb_kuzminsky> jepler: ok, new version of the patch with a real comp:
http://highlab.com/~seb/linuxcnc/0001-tests-include-a-user-non-realtime-component-in-the-s.patch
[17:14:26] <seb_kuzminsky> just read back, guess i'm wrong about save, never mind me
[17:14:50] <seb_kuzminsky> pcw_home_: jepler has my intention right
[17:15:05] amnesic_away is now known as amnesic
[17:15:20] <seb_kuzminsky> i wanted to not break configs that use pet_watchdog, at least not right away, and provide a transition period
[17:15:39] <seb_kuzminsky> what good is save if it doesn't save user comps?
[17:15:50] <jepler> seb_kuzminsky: in the halcmd manpage it even says about save that it only generates "loadrt" lines
[17:15:56] * seb_kuzminsky shakes head and backs away
[17:16:02] <jepler> generating "loadusr" lines would be a nice addition, I agree
[17:16:34] <seb_kuzminsky> jepler: i was too lazy to diff the diffs in your proposed-2.6 branches, what finally made the tests pass?
[17:17:52] <Roguish> seb_kuzminsky: thanks, it's compiling now.
[17:18:03] <jepler> seb_kuzminsky: halcmd save
[17:18:03] <jepler> +halcmd unload all
[17:18:03] <jepler> realtime stop
[17:19:38] <seb_kuzminsky> kthx
[17:20:01] <jepler> so when I changed from using halrun to running things by hand, I didn't get all the steps right
[17:20:10] <jepler> and apparently only rtai cares if you unload all before realtime stop
[17:23:40] -!- sumpfralle has quit [Ping timeout: 258 seconds]
[17:26:45] -!- zeeshan|2 has quit [Read error: Connection reset by peer]
[17:26:52] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[17:28:35] -!- SkramX has quit [Read error: Connection reset by peer]
[17:33:47] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[17:37:09] <seb_kuzminsky> ok, my testing here finds nothing wrong with your new branch
[17:37:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 510676c 06linuxcnc 10src/hal/utils/halcmd_commands.c 10tests/save.0/test.hal hal: make 'save comp' order match original 'loadrt' order * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=510676c
[17:37:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 ee76d4e 06linuxcnc 04tests/save.0/test.hal 03tests/save.0/test.sh tests: save.0: use expected result as hal script too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee76d4e
[17:37:31] <jepler> one whitespace nit
[17:42:09] <jepler> seb_kuzminsky: want me to merge to 2.6 then?
[17:45:25] <seb_kuzminsky> go for it
[17:45:57] <KGB-linuxcnc> 03Jeff Epler 052.6 ee76d4e 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee76d4e
[17:47:45] <seb_kuzminsky> jepler: thanks!
[17:50:30] -!- sylphiae has quit [Ping timeout: 258 seconds]
[17:54:27] -!- rob_h [rob_h!~robh@176.254.105.27] has joined #linuxcnc-devel
[17:55:52] -!- HeXiLeD has quit [Ping timeout: 258 seconds]
[17:56:11] -!- zzolo has quit [Quit: zzolo]
[18:02:26] -!- pandeiro has quit [Remote host closed the connection]
[18:03:54] -!- nofxx has quit [Changing host]
[18:15:45] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[18:22:02] asheppard_ is now known as asheppard
[18:22:03] -!- sheppard has quit [Ping timeout: 255 seconds]
[18:22:52] asheppard is now known as sheppard
[18:25:43] -!- _javisantana has quit [Remote host closed the connection]
[18:38:07] -!- rob_h has quit [Ping timeout: 245 seconds]
[18:38:54] -!- rob_h [rob_h!~robh@2.223.235.128] has joined #linuxcnc-devel
[18:47:51] -!- erictheise has quit [Read error: Connection reset by peer]
[18:48:36] -!- Lathe_newbie has quit [Ping timeout: 272 seconds]
[18:48:38] <micges-dev> seb_kuzminsky: can you take a look at this patch?
http://pastebin.com/VxJAfaUw
[18:49:23] <micges-dev> seb_kuzminsky:adding dpll timer number hal parameter when dpll module is available
[18:57:45] Cylly is now known as Loetmichel
[18:59:25] -!- tmcw has quit [Read error: Connection reset by peer]
[19:05:12] <jepler> micges-dev should hm2_stepgen_force_write_dpll_timer update written_dpll_timer_num?
[19:06:02] <PCW> I think some things are missing: timer number shift left and enable bit
[19:06:04] <KGB-linuxcnc> 03John Thornton 052.6 7de8018 06linuxcnc 10docs/src/common/Getting_LinuxCNC.txt Docs: update download information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7de8018
[19:06:36] <seb_kuzminsky> jthornton, JT-Shop: thanks!
[19:08:28] <seb_kuzminsky> micges-dev: i'd prefer if dpll_timer_num lived in the stepgen hal struct with the other hal things, instead of down in the parent stepgen struct
[19:08:46] <PCW> hmm I didn't add the new register to the regmap file...
[19:09:16] <seb_kuzminsky> same with dpll_present
[19:10:09] <jepler> hm, the successor of the U3 keeps the same 1.8V I/O standard for its off-board I/Os, but changes it to a 30-pin, .100" header
[19:10:32] <jepler> (XU3)
[19:13:20] <seb_kuzminsky> i'd be excited about the XU3 if it wasn't nearly 3x the price
[19:13:22] <jepler> SPI on pins 7/9/10/11 (so CLK's neighbor conductors are MISO and CSN), grounds on 2/28/30
[19:13:33] <PCW> dpll_present could be more global (since it will eventually be used for more modules)
[19:14:08] <PCW> as long as its board to board thats OK, flat cable not so good
[19:14:43] <jepler> looks like it's intended to be flat cable, it's one of those shrouded, keyed connectors:
http://dn.odroid.com/homebackup/201407071202252748.jpg
[19:15:21] <seb_kuzminsky> aww, it's a baby mesa connector
[19:16:26] <PCW> its entirely possible to make the SPI slave use a async clock and digital filter the clock input (for crappy cabling accommodation)
[19:18:01] <PCW> .1" connectors can use the crimp pins also so you can cable as you like
[19:18:26] <PCW> (2mm do also but they are too fragile for me)
[19:20:12] <micges-dev> thanks guys, will fix it
[19:20:16] <jepler> I'd be tempted to just make the daughtherboard hang over to the left, over the lan/usb IC
[19:20:25] <jepler> there msut be female .100 headers that would fit into that shrouded header
[19:22:43] <PCW> Stepgen DPLL channel select register. This selects the DPLL timer channel
[19:22:45] <PCW> that all stepgens use for sampling the position
[19:22:45] <jepler> compared to the trouble of customizing a header with crimp pins, ugh
[19:22:46] <PCW> 0x2A00
[19:22:48] <PCW> Bits 12..14 Stepgen position sample timer select (0 through 4)
[19:22:49] <PCW> Bit 15 Stepgen timer sample enable (active high)
[19:23:32] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[19:24:47] <micges-dev> PCW: thanks
[19:26:03] <PCW> Thought sure I had added that to regmap, I seem to imagine I have a lot more done than I actually have
[19:26:06] <KGB-linuxcnc> 03John Thornton 052.6 06655d0 06linuxcnc 10docs/src/common/Getting_LinuxCNC.txt Docs: update install instructions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06655d0
[19:27:22] <micges-dev> PCW: is it ok for -1 to disable bit 15?
[19:27:44] <micges-dev> or another enable hal pin should be added
[19:27:51] <jepler> pcw_home_: are there really 5 timers?
[19:27:58] <PCW> yes
[19:28:24] <PCW> timer 0 is DPLL reference time (no offset)
[19:29:34] <PCW> so I guess there is really only one timer (and 4 offsets from that timer)
[19:29:43] <jepler> I wonder if ntp is really right when it estimates my computer's clock error vs UTC as 23us
[19:31:00] <PCW> on the average it should be right...
[19:33:55] <PCW> does the UTC offset get better over time or is 23 usec average noise?
[19:35:35] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:36:28] <jepler> it updates the estimate every time it talks to the ntp server
[19:36:41] <jepler> but the estimated error seems pretty consistent
[19:36:45] <PCW> female board-board connectors will typically fit in shrouded headers (and may have a bit too much end play so easy to get off by 2)
[19:37:14] <kwallace2> Would there be any issues with including freetype-py (
https://pypi.python.org/pypi/freetype-py ) in LinuxCNC? The license statement includes : "freetype-py is licensed under the terms of the new or revised BSD license..."
[19:37:24] <PCW> (not a problem if you align by mounting holes)
[19:37:45] <jepler> PCW: yeah it looks like the board could go up to the top right mounting hole without obstructing anything too important
[19:38:56] <jepler> kwallace2: it does not appear to be packaged in debian wheezy under an obvious name. it is only easy for us to include packages that are packaged up by the OS version we base our live CD of the day on
[19:39:34] <jepler> in 2011 someone filed an "intent to package" with the debian bug database but there seems to be no further activity.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649623
[19:39:57] <jepler> er, RFP I guess is a request for the package
[19:40:03] <jepler> ITP is intent to package
[19:41:46] <kwallace2> I used it to convert a height entry into a TTT scale, then recalled later that there might be license issues.
[19:43:58] <PCW> micges-dev: probably needs an enable pin (so default is existing behavior)
[19:44:28] <jepler> PCW: I think that's what micges-dev was getting at, by talking about using -1 to mean "set bit 15 / disable PLL"
[19:44:39] <jepler> vs an enable pin and a pin with value 0..4
[19:45:10] <micges-dev> yeah and -1 would be default value
[19:45:19] <PCW> setting bit 15 enables DPLL sampling of the stepgen position registers
[19:45:44] <PCW> 0 should be the default
[19:45:50] <micges-dev> right
[19:46:04] <PCW> (0 gives old behavior)
[19:46:53] <jepler> er, yes, I had it backwards when I said how the value -1 would affect bit 15
[19:46:57] <PCW> (bits 12..14 are dont care if 15 is 0)
[19:47:50] -!- gimps_ has quit [Changing host]
[19:48:18] <jepler> kwallace2: the sticking point is the lack of Debian packaging for freetype-py. at a glance, the license is OK to put on the same piece of media as linuxcnc.
[19:48:33] <jepler> I don't know the license of any software you want to combine freetype-py with so I can't comment on that
[19:48:58] <seb_kuzminsky> since the dpll is a generally usable/useful module independent of stepgen, i guess it should be treated that way by the hostmot2 driver
[19:49:52] <seb_kuzminsky> it'd be similar to how the ioports are treated: initialized first, then manhandled by other modules as they please (sserial.c)
[19:50:19] <seb_kuzminsky> that seems less messy to me than doing all the dpll-handling inside stepgen
[19:51:01] <PCW> Yes Though its not of much use outside of the absolute encoder and stepgen ATM
[19:51:03] <PCW> I expect it can be used by the encoder module, SPI, sserial etc eventually
[19:51:04] <PCW>
[19:51:43] <micges-dev> seb_kuzminsky: but that reg I'm fighting with is part of stepgen not dpll
[19:52:18] <PCW> yeah that reg is owned by the stepgen
[19:53:16] <seb_kuzminsky> i'm looking at the code in hm2_stepgen_parse_md(), last hunk here:
http://pastebin.com/VxJAfaUw
[19:53:27] <PCW> each module that uses the DPLL for timing must at minimum select which timer it wants
[19:53:44] <seb_kuzminsky> maybe i'm being overly sensitive/nitpicky
[19:54:12] <PCW> thats your job :-)
[19:54:47] -!- mozmck has quit [Ping timeout: 245 seconds]
[19:54:48] <seb_kuzminsky> heh
[19:58:58] <PCW> the DPLL mighy be handy for synchronous sampling if an input (say SPI) at some binary multiple of the servo thread rate
[20:01:23] <PCW> say 16x or 32x (as long as the servo thread time to read the accumulated data every servo thread wasn't too long)
[20:06:57] <micges-dev> guys, how about now:
http://pastebin.com/R6AcXy4a
[20:07:55] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:08:16] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[20:08:41] <micges-dev> PCW: should 5i25_7i76x2.bit have dpll ready stepgen?
[20:11:05] <seb_kuzminsky> micges-dev: nice
[20:11:13] <micges-dev> (stepgen, just like encoder is a mess with direct reading or writing single regs)
[20:11:59] -!- patricka_ has quit [Remote host closed the connection]
[20:13:00] <seb_kuzminsky> is there a stepgen module version that should be consulted before the driver tries to work with the dpll_timer_num register? or can we assume that the presence of the DPLL module implies the presence of the dpll_timer_num register in the stepgen?
[20:13:39] <seb_kuzminsky> micges-dev: the intent was that anything that needs to happen on every servo cycle lives in tram, and any config/params-type info get written "by hand" as needed
[20:13:53] <seb_kuzminsky> if there's a cleaner structure that accomplishes this i'm all ears
[20:15:00] -!- phragment has quit [Ping timeout: 255 seconds]
[20:15:21] <jepler> I know: we should take all we've learned from hostmot2 and make hostmot3 which will be the perfect, shining example for all days
[20:15:52] <jepler> that's basically the gist of my suggestion to make it a cleaner structure, and my tongue is firmly in cheek
[20:17:15] -!- patrickarlt has quit [Ping timeout: 255 seconds]
[20:17:20] <seb_kuzminsky> "let's rewrite it all from scratch, but without the bugs"
[20:17:24] <jepler> seb_kuzminsky: yes!
[20:17:27] -!- assanaway has quit []
[20:17:47] <cradek> we'll call it emc4
[20:18:03] <jepler> linux3nc
[20:19:55] <micges-dev> seb_kuzminsky: we assume that stepgen with dpll present have this option
[20:20:13] <seb_kuzminsky> i see
[20:20:21] <seb_kuzminsky> well then, looks good
[20:26:08] -!- zzolo has quit [Quit: zzolo]
[20:26:22] -!- balestrino has quit [Ping timeout: 240 seconds]
[20:26:23] <micges-dev> cool
[20:30:42] -!- rythmnbls has quit [Quit: Leaving]
[20:35:23] <micges-dev> seb_kuzminsky: outstanding commit message?
http://pastebin.com/pZWT3jJZ
[20:37:33] -!- patricka_ has quit [Ping timeout: 260 seconds]
[20:38:40] <seb_kuzminsky> micges-dev: yes, though it reminds me that your patch doesn't update the hostmot2.9 manpage with the new pins/params
[20:39:14] <micges-dev> right
[20:43:41] <PCW> micges-dev: didnt add any DPLLs to the PCI configs, only Ethernet, SPI and serial
[20:44:03] <micges-dev> ah ok, I forgot
[20:44:23] <PCW> I can make one (Ive added a D to the end of all DPLL containing config names)
[20:46:35] <PCW> i beg your pardon, 7I76x2D is there in the zip file
[20:46:57] <PCW> shows how much I know
[20:48:38] <PCW> (5i25.zip file)
[20:49:42] <micges-dev> I see it
[20:50:16] <micges-dev> I'm too tired, will test and commit tomorrow
[20:50:28] <jepler> micges-dev: have a good sleep
[20:51:12] <micges-dev> thanks
[20:51:13] <micges-dev> bbl
[20:51:26] `Nerobro_ is now known as `Nerobro
[20:52:06] -!- FinboySlick has quit [Quit: Leaving.]
[20:59:50] -!- jduhls has quit [Quit: Leaving]
[21:10:40] -!- JT-Shop_ [JT-Shop_!~john@162.72.174.234] has joined #linuxcnc-devel
[21:10:41] -!- jthornton has quit [Read error: Connection reset by peer]
[21:10:42] -!- JT-Shop has quit [Write error: Connection reset by peer]
[21:10:56] -!- jthornton [jthornton!~john@162.72.174.234] has joined #linuxcnc-devel
[21:13:33] -!- rythmnbls [rythmnbls!~rythmnbls@d-24-153-46-7.cpe.metrocast.net] has joined #linuxcnc-devel
[21:15:18] -!- Deejay has quit [Quit: bye]
[21:16:07] -!- bedah has quit [Quit: Ex-Chat]
[21:24:01] gimps is now known as lmpyspaceprncs
[21:31:22] -!- skunkworks has quit [Ping timeout: 240 seconds]
[21:38:25] gimps_ is now known as gimps
[21:39:37] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:44:42] -!- sirdancealot has quit [Ping timeout: 246 seconds]
[21:46:32] -!- skunkworks_ has quit [Ping timeout: 260 seconds]
[21:47:24] -!- sumpfralle has quit [Ping timeout: 258 seconds]
[21:54:03] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:07:22] -!- _1SheYode has quit [Ping timeout: 240 seconds]
[22:16:07] -!- SquirrelCZECH_ has quit [Ping timeout: 245 seconds]
[22:20:05] -!- tinkerer has quit [Remote host closed the connection]
[22:30:29] -!- acdha has quit [Quit: Textual IRC Client: www.textualapp.com]
[22:33:41] <NTU> one way to trace latency spikes in IPIPE is actually using the in-kernel IPIPE tracer
[22:34:04] <NTU> you can debug latency using that and read the latency spike cause in /proc
[22:34:35] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[22:35:03] -!- PetefromTn_andro has quit [Quit: Bye]
[22:35:22] -!- skorasaurus has quit [Ping timeout: 240 seconds]
[22:35:36] <NTU> specifically /proc/ipipe/trace
[22:37:35] <NTU> CONFIG_IPIPE_TRACE_IRQSOFF is required, maybe some others
[22:39:31] <NTU> at the same time, IPIPE tracing enables debugging features which can cause latency spikes within itself
[22:39:57] <NTU> so the logic is, enable the trace, find the cause outside the tracer, fix that, disable tracing, then re-run your RT threads
[22:40:41] <NTU> how much overhead exactly is caused by the tracer i didnt look into very much
[22:52:03] -!- patrickarlt has quit [Remote host closed the connection]
[22:57:33] -!- patrickarlt has quit [Ping timeout: 258 seconds]
[23:13:12] -!- rigid has quit [Ping timeout: 245 seconds]
[23:13:15] -!- Fox_Muldr has quit [Ping timeout: 246 seconds]
[23:15:59] -!- Roguish has quit [Remote host closed the connection]
[23:20:55] -!- kfoltman has quit [Quit: Ex-Chat]
[23:25:44] -!- maximilian_h1 [maximilian_h1!~bonsai@dslb-094-216-227-151.094.216.pools.vodafone-ip.de] has joined #linuxcnc-devel
[23:27:44] -!- maximilian_h has quit [Ping timeout: 250 seconds]
[23:30:52] -!- asdfasd has quit [Ping timeout: 240 seconds]
[23:34:25] -!- phragment has quit [Ping timeout: 260 seconds]
[23:42:52] -!- rob_h has quit [Ping timeout: 240 seconds]
[23:47:08] <KGB-linuxcnc> 03Jeff Epler 05master f9acfb1 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/utils/halcmd_commands.c Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f9acfb1
[23:53:27] -!- skorasaurus has quit [Ping timeout: 272 seconds]
