Back
[00:01:55] <Roguish> tom_itx: hey, are there any problems with Linux and the ASRock Q1900B ?
[00:02:36] <Tom_itx> i booted linux with it but have been configuring a hdd with windows
[00:02:53] <Tom_itx> haven't had a chance yet to try it with the mill
[00:03:24] <Roguish> but to your experience, it runs linux OK, like Wheezy?
[00:03:25] <Tom_itx> part of the stuff was a week late arriving due to the bad weather
[00:04:01] <Tom_itx> i was running 10.04 but iirc i booted wheezy with it but didn't do much with it
[00:04:38] <Tom_itx> if windows update ever gives it back to me i plan to try a few things
[00:05:13] <Tom_itx> been doing updates since early afternoon...
[00:08:03] <Roguish> that's ok, you'll get windows 10 for free.......
[00:10:43] -!- tjb11 has quit [Quit: Leaving]
[00:13:02] -!- skunkworks has quit [Ping timeout: 246 seconds]
[00:18:17] -!- dgarr has quit [Ping timeout: 246 seconds]
[00:32:00] -!- mozmck has quit [Quit: Leaving.]
[00:32:01] -!- dgarr [dgarr!~dgarrett@174-26-249-224.phnx.qwest.net] has joined #linuxcnc-devel
[00:32:55] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[00:40:22] -!- nerdfiles has quit [Ping timeout: 256 seconds]
[00:42:20] <andypugh> Well, that is one rather interesting quirk of my decision to keep all my git archives local to my keyboard and chair…. OSX is case insensitive, and some linux kernel folders have files distinguished only by case, so I lose one…
[00:42:53] <andypugh> How, err, fascinating.
[00:43:58] <mozmck> I'm surprised by that - is BSD case insensitive?
[00:45:36] <andypugh> _you_ Are surpised? I am astonished. And annoyed
[00:46:18] <mozmck> I don't know much about macs, but heard they are based on BSD these days.
[00:46:35] <andypugh> Yes, that is why I am very susprised by this quirk
[00:46:53] <andypugh> Typically OSX and Linux feel very much the same
[00:50:26] -!- anth0ny_ has quit [Quit: anth0ny_]
[01:00:16] -!- skunkworks [skunkworks!~chatzilla@69.4.98.27] has joined #linuxcnc-devel
[01:03:36] <skunksleep> pcw_home: the rt is up patch 5
[01:04:34] <skunksleep> I was applying it to the Asus 1900 but ran out of time
[01:11:00] <PCW> Yeah I noticed but have not tried yet either
[01:11:54] -!- per_sonne has quit [Ping timeout: 245 seconds]
[01:12:44] <PCW> I did find that I can run the 7I92 from the laptops USB power so I have a pretty portable linuxcnc setup (+ ISE so I can now make bitfilles at home)
[01:14:13] -!- asdfasd has quit [Ping timeout: 264 seconds]
[01:15:25] -!- rob_h has quit [Ping timeout: 264 seconds]
[01:16:23] -!- nerdfiles has quit [Ping timeout: 246 seconds]
[01:17:39] <PCW> Arghh I feel bad the Marius's problem was old firmware and I didn't know there was any issue with Ethernet firmware versions
[01:18:33] <PCW> Driver needa to warn to update firmware
[01:18:37] <PCW> needs
[01:19:22] <PCW> or muddle through without hanging
[01:19:43] <PCW> BBL Dinner!
[01:29:13] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[01:47:18] -!- Roguish has quit [Quit: ChatZilla 0.9.91.1 [Firefox 36.0.1/20150305021524]]
[02:00:11] -!- ASRock_pc [ASRock_pc!~Tom@ip68-102-196-57.ks.ok.cox.net] has joined #linuxcnc-devel
[02:01:04] -!- ASRock_pc has quit [Changing host]
[02:01:04] -!- ASRock_pc [ASRock_pc!~Tom@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[02:05:45] <cradek> bsd is absolutely not case-insensitive unless someone does something very strange to it
[02:05:58] <cradek> andypugh: glad you figured it out, anyway
[02:09:12] <andypugh> Well, I figured _something_ out, no guarantees that is all that is wrong.
[02:10:20] <andypugh> And as is traditional when building kernels, it is now 2am and I just started again.
[02:10:30] -!- anth0ny_ has quit [Quit: anth0ny_]
[02:10:31] -!- andypugh has quit [Quit: andypugh]
[02:11:17] <cradek> :-P
[02:14:35] -!- ASRock_pc has quit [Quit: Leaving]
[02:14:57] -!- ASRock_pc [ASRock_pc!~Tom@ip68-102-196-57.ks.ok.cox.net] has joined #linuxcnc-devel
[02:28:50] -!- fablab has quit [Ping timeout: 265 seconds]
[02:42:26] -!- micges has quit [Quit: Ex-Chat]
[02:45:59] -!- AR_ has quit [Ping timeout: 246 seconds]
[02:46:12] -!- anth0ny_ has quit [Quit: anth0ny_]
[03:00:54] -!- per_sonne has quit [Ping timeout: 256 seconds]
[03:06:25] <memfrob> the changes to rtdm / proc and lxrt inlining still get me nowhere. :/
[03:07:13] <memfrob> its definitely magic deep within rtai. also another thing that's weird is that there are more warnings during the build, but in my tree, the warnings aren't there, so certain CFLAGS must be changing.
[03:07:36] <memfrob> ^between magma and my dev branc
[03:07:40] <memfrob> h
[03:35:24] -!- nerdfiles has quit [Ping timeout: 272 seconds]
[03:38:32] -!- ASRock_pc has quit [Quit: Leaving]
[03:53:50] <KGB-linuxcnc> 03Dewey Garrett 052.7 58de619 06linuxcnc 10src/hal/components/latencybins.comp latencybins.comp fix ref to using script name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58de619
[03:53:50] <KGB-linuxcnc> 03Dewey Garrett 052.7 bc20bf9 06linuxcnc 10scripts/hal-histogram hal-histogram: minor display improvements * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc20bf9
[04:17:58] -!- koo6 has quit [Ping timeout: 255 seconds]
[04:20:28] -!- dgarr has quit [Quit: Leaving.]
[04:22:49] <linuxcnc-build> build #1256 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1256 blamelist: Dewey Garrett <dgarrett@panix.com>
[04:25:28] -!- FinboySlick has quit [Quit: Leaving.]
[04:26:50] -!- JT-Shop has quit [Read error: Connection reset by peer]
[04:27:16] -!- jthornton has quit [Read error: Connection reset by peer]
[04:31:21] <linuxcnc-build> build #3079 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3079 blamelist: Dewey Garrett <dgarrett@panix.com>
[04:49:32] -!- per_sonne has quit [Ping timeout: 246 seconds]
[05:18:41] -!- maximilian_h1 [maximilian_h1!~bonsai@dslb-188-098-049-032.188.098.pools.vodafone-ip.de] has joined #linuxcnc-devel
[05:20:44] -!- maximilian_h has quit [Ping timeout: 246 seconds]
[05:22:51] -!- kwallace2 [kwallace2!~kwallace@smb-225.sonnet.com] has parted #linuxcnc-devel
[05:34:37] -!- amiri has quit [Ping timeout: 256 seconds]
[05:57:27] -!- sumpfralle has quit [Quit: Leaving.]
[05:59:32] -!- furrywolf has quit [Read error: No route to host]
[06:02:00] -!- ve7it has quit [Remote host closed the connection]
[06:38:29] -!- per_sonne has quit [Ping timeout: 252 seconds]
[06:40:35] -!- veek has quit [Ping timeout: 272 seconds]
[06:46:05] -!- karavanjo has quit [Ping timeout: 246 seconds]
[07:12:50] -!- erve has quit [Remote host closed the connection]
[07:24:28] -!- tjb1 has quit [Ping timeout: 252 seconds]
[07:38:24] -!- Miner_48er has quit [Quit: Leaving]
[07:51:16] -!- karavanjo has quit [Ping timeout: 255 seconds]
[07:53:04] -!- FreezingCold has quit [Ping timeout: 252 seconds]
[08:06:07] -!- karavanjo has quit [Ping timeout: 252 seconds]
[08:27:51] -!- JT-Shop [JT-Shop!~john@184.21.239.59] has joined #linuxcnc-devel
[08:28:00] -!- per_sonne has quit [Ping timeout: 272 seconds]
[08:28:06] -!- jthornton [jthornton!~john@184.21.239.59] has joined #linuxcnc-devel
[08:32:33] -!- b_b has quit [Changing host]
[08:34:30] -!- veek has quit [Quit: Leaving]
[08:36:39] -!- syyl_ has quit [Ping timeout: 265 seconds]
[08:42:47] -!- karavanjo1 has quit [Ping timeout: 252 seconds]
[08:46:05] -!- karavanjo2 has quit [Ping timeout: 252 seconds]
[08:52:20] -!- beawesomeinstead has quit [Quit: Connection closed for inactivity]
[09:00:34] -!- rob_h [rob_h!~robh@90.212.252.1] has joined #linuxcnc-devel
[09:05:09] amnesic_away is now known as amnesic
[09:28:37] -!- per_sonne has quit [Ping timeout: 250 seconds]
[09:52:22] -!- grummund has quit [Ping timeout: 240 seconds]
[09:57:18] amnesic is now known as amnesic_away
[09:58:17] -!- grummund has quit [Remote host closed the connection]
[10:02:19] -!- jthornton has quit [Remote host closed the connection]
[10:04:31] -!- jthornton [jthornton!~john@184.21.239.59] has joined #linuxcnc-devel
[10:23:37] -!- skunkworks has quit [Ping timeout: 244 seconds]
[10:29:51] -!- per_sonne has quit [Ping timeout: 256 seconds]
[10:30:25] -!- micges [micges!~micges@dgs195.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[10:31:23] -!- Brunetty has quit [Quit: Follow me]
[10:31:30] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[10:32:49] -!- arekm has quit [Ping timeout: 264 seconds]
[10:48:27] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[10:56:04] -!- pandeiro has quit [Read error: Connection reset by peer]
[11:21:43] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:27:30] -!- skunkworks_ has quit [Ping timeout: 256 seconds]
[11:35:04] -!- md-2 has quit [Quit: Leaving...]
[11:40:48] -!- tom_o_t has quit [Ping timeout: 265 seconds]
[11:41:07] -!- moorbo has quit [Remote host closed the connection]
[11:41:40] -!- karavanjo1 has quit [Ping timeout: 255 seconds]
[11:53:09] -!- tom_o_t has quit [Changing host]
[12:02:49] -!- karavanjo has quit [Ping timeout: 244 seconds]
[12:03:20] -!- veek has quit [Client Quit]
[12:04:56] -!- Brunetty has quit [Quit: Follow me]
[12:07:30] -!- erve has quit [Read error: Connection reset by peer]
[12:14:49] -!- erve has quit [Ping timeout: 245 seconds]
[12:20:22] -!- karavanjo has quit [Ping timeout: 255 seconds]
[12:25:17] -!- Mr_Sheesh has quit [Ping timeout: 245 seconds]
[12:28:06] -!- quiqua has quit [Quit: quiqua]
[12:36:56] -!- erve has quit [Remote host closed the connection]
[12:48:30] -!- veek has quit [Changing host]
[13:03:34] -!- karavanjo has quit [Ping timeout: 255 seconds]
[13:18:21] -!- andypugh [andypugh!~andy2@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[13:24:45] <skunkworks> andypugh, kinda early?
[13:25:17] <andypugh> I popped home from work to do some soldering.
[13:26:05] <andypugh> I needed some instrumentation for a “what happens if we drain all the coolant from this engine and floor it down the motorway, does the plastic oil sump actually melt? test.
[13:27:02] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[13:28:26] <CaptHindsight> what's the Tg of the polymer used for the sump?
[13:29:13] <andypugh> About 200C
[13:36:48] -!- per_sonne has quit [Quit: Lingo: www.lingoirc.com]
[13:39:24] -!- Brunetty has quit [Read error: Connection reset by peer]
[13:40:44] <archivist> or does a rod fly through the side first
[13:42:20] <archivist> from experience though, an engine gets tight/seizes
[13:45:35] <mozmck> plastic oil sump?
[13:47:13] <mozmck> maybe another test should be "what happens when you hit a bump and the oil sump breaks open draining the oil while you floor it down the motorway" :)
[13:48:22] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[13:48:59] <archivist> over here we have speed bumps, therefore a regular occurrence
[13:49:42] <mozmck> they have them here in parking lots in front of the stores, so it probably happens a bit here too.
[13:50:38] <mozmck> my brother-in-law did that and it threw a rod out the side of the crankcase. that was an '82 mercedes diesel
[13:52:40] -!- erve has quit [Read error: Connection reset by peer]
[13:53:05] <archivist> I learned about bits falling of about 1970, a fan blade fell off, so I bent the other one off to put it back in balance. entire water pump came of a few days later going through the radiator, ran total loss for a month or so until I found a donor car for parts
[13:53:15] -!- md-2 has quit [Remote host closed the connection]
[14:00:00] -!- dr0w has quit [Quit: Leaving]
[14:27:11] <mozmck> I'm building a gscreen skin - based on the gaxis skin. Gremlin seems to not want to display many of the sample gcode files or other that I have.
[14:32:23] <CaptHindsight> should interesting since the engine will be 100C over the designed operating temp
[14:33:57] <CaptHindsight> is there enough conduction and convection cooling from the car driving to keep it under 200C? Will it seize up or will the plastic melt first?
[14:35:49] -!- kwallace [kwallace!~kwallace@smb-83.sonnet.com] has joined #linuxcnc-devel
[14:38:05] -!- MacGalempsy has quit [Quit: Bye]
[14:45:09] <mozmck> Ok, looks like if the tool table does not have a tool called for in the gcode gremlin will not display it.
[14:45:43] -!- erve has quit [Ping timeout: 255 seconds]
[14:49:10] -!- sheppard has quit [Quit: Ex-Chat]
[14:57:43] -!- kwallace2 [kwallace2!~kwallace@smb-97.sonnet.com] has joined #linuxcnc-devel
[14:59:40] -!- kwallace has quit [Ping timeout: 255 seconds]
[15:03:43] -!- erve_ has quit [Remote host closed the connection]
[15:05:43] -!- eFuchs has quit [Ping timeout: 264 seconds]
[15:14:29] -!- quiqua has quit [Read error: Connection reset by peer]
[15:30:46] -!- quiqua has quit [Quit: quiqua]
[15:34:17] -!- nerdfiles has quit [Ping timeout: 246 seconds]
[15:46:52] <cradek> my parport card came yesterday, so I'll update the lathe this weekend, yay
[15:47:05] <cradek> I should also put 2.7 on it
[15:58:19] <mozmck> I should update my router table from 2.3 sometime...
[15:59:57] <archivist> iI think my mill is still on 3.3 as well :)
[16:00:01] <archivist> 2.3
[16:02:42] -!- skunkworks has quit [Read error: Connection reset by peer]
[16:03:25] -!- a_morale_ has quit [Ping timeout: 264 seconds]
[16:06:01] <archivist> any pics yet of the lathe
[16:10:43] <cradek> you mean me? it's an old sherline with servos stuck on it and running touchy
[16:11:56] <cradek> the worst part of it is that I can either have the spindle encoder mounted OR use the drawbar (for WW collets etc), not both
[16:12:11] <cradek> and it's finicky to go from one to the other
[16:13:26] <archivist> make a disk encoder so you can use both
[16:14:16] <cradek> yeah I could surely fix it, but it's such a nice encoder...
[16:15:13] <cradek> actually it would probably be easier to elongerize the drawbar
[16:16:01] <archivist> I just found your encoder pic
http://timeguy.com/cradek-files/cnc/lathe/DSCN6300.JPG
[16:16:13] <cradek> that's the one
[16:17:13] <archivist> hehe and the drive :)
[16:17:21] <cradek> ?
[16:17:22] <seb_kuzminsky> we just un-mothballed a 5'x10' shopbot at the local hackspace, it's running 2.5.0, i'm excited to upgrade it to 2.7 soonish
[16:17:30] <cradek> sweet
[16:17:34] <archivist> http://timeguy.com/cradek-files/cnc/lathe/DSCN6299.JPG
[16:17:37] <seb_kuzminsky> err, 5' x 9'
[16:18:26] <cradek> archivist: lovely isn't it?
[16:19:33] <archivist> I approve considering how many clamps hold my "tool grinder" together
[16:20:12] <cradek> and this makes me laugh, but it sure does work:
http://timeguy.com/cradek-files/cnc/lathe/DSCN6292.JPG
[16:21:14] <archivist> my 5axis has stacked parts and ratsnest wiring too
[16:21:57] <archivist> time I did a similar mod to the starturn motor speed control
[16:22:08] <seb_kuzminsky> cradek: artisanal circuitry
[16:25:20] <cradek> exactly
[16:26:58] -!- adb has quit [Remote host closed the connection]
[16:27:10] <cradek> the problem with linuxcnc is you have to be an EE to use it
[16:29:45] <archivist> it certainly helps to know electronics
[16:30:52] <archivist> but that goes for any control system implementation from scratch without paying through the nose for magic boxes
[16:31:36] <kwallace2> The problem with machining is you have to be a machinist to do it.
[16:32:07] -!- quiqua has quit [Quit: quiqua]
[16:33:23] <mozmck> What does DTG in the DROs stand for?
[16:33:30] <jepler> distance to go
[16:33:39] <mozmck> to what?
[16:33:56] <cradek> how far 'til the end of the move
[16:34:27] -!- lnr has quit [Ping timeout: 245 seconds]
[16:34:29] <mozmck> So it is only valid or shows during a move
[16:34:44] <cradek> yes if not moving it should show zero
[16:34:47] <jepler> not sure if it's changed with the new tp, but "end of the move" would include all motions merged by the naive cam detector
[16:34:57] <Tom_itx> what does it show if it's a non linear move?
[16:35:03] <Tom_itx> or multi axis move?
[16:35:36] <jepler> it's the path distance, so for an arc it shows arc length
[16:35:41] <cradek> Tom_itx: it depends. there's one that's one number, and that would show the arc length remaining. the multi-axis dtg shows a separate number for each axis, which can be negative
[16:35:57] <jepler> cradek: oh am I mistaken?
[16:36:02] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[16:36:04] <cradek> well we do it both ways
[16:36:23] <cradek> you're right for the "total" dtg readout
[16:36:30] <cradek> but there are separate ones also
[16:36:37] <Tom_itx> that's what i was wondering
[16:36:56] -!- unfy has quit [Read error: Connection reset by peer]
[16:37:27] <cradek> so for something like a semicircle, one of the numbers would go up (away from zero) and then back to zero
[16:38:07] <Tom_itx> it really shouldn't ever be negative
[16:38:13] -!- lnr has quit [Max SendQ exceeded]
[16:38:13] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[16:38:15] <Tom_itx> considering its 'distance to go'
[16:38:18] <cradek> for g0x1y0 g3x-1y0i-1j0, Y would go up to 1 and then back to 0
[16:38:34] -!- lnr has quit [Max SendQ exceeded]
[16:38:53] <cradek> Tom_itx: the dictionary agrees with you but machinists don't
[16:38:54] <Tom_itx> it should be unsigned int in any case that i can think of
[16:39:11] -!- lnr has quit [Max SendQ exceeded]
[16:39:14] <Tom_itx> what do they know?
[16:39:15] <Tom_itx> :)
[16:39:33] -!- lnr has quit [Max SendQ exceeded]
[16:39:52] -!- lnr has quit [Max SendQ exceeded]
[16:39:53] <cradek> the single-number dtg, which was written by a programmer and not a machinist, always shows a positive number
[16:40:12] -!- lnr has quit [Max SendQ exceeded]
[16:40:32] -!- lnr has quit [Max SendQ exceeded]
[16:40:50] -!- lnr has quit [Max SendQ exceeded]
[16:40:55] -!- nerdfiles has quit [Ping timeout: 252 seconds]
[16:41:07] -!- lnr has quit [Max SendQ exceeded]
[16:41:28] -!- lnr has quit [Max SendQ exceeded]
[17:05:19] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[17:13:17] -!- md-2 has quit [Quit: Leaving...]
[17:19:19] -!- tocka has quit [Quit: tocka]
[17:19:32] -!- rob_h has quit [Ping timeout: 244 seconds]
[17:40:39] <archivist> hmm we need the mill version of this image visible too
http://linuxcnc.org/docs/html/config/images/pncconf-diagram-lathe.png
[17:41:19] <andypugh> cradek: I can’t help feeling that there is something slighlty crazy in having an encder that is wider than your spindle motor.
[17:41:29] <archivist> or something similar on our pages to
http://www.cnc-toolkit.com/support.html
[17:42:22] <archivist> I must be crazy too because the starturn encoder is wider :)
[17:43:05] <andypugh> I went through a number of iterations but finally ended up with a commercial encoder geared 1:1 and mounted inside the headstock.
[17:43:31] <andypugh> Whereas the Mill has a resolver geared 1:1 because resolbvers are cooler.
[17:43:43] -!- theorbtwo has quit [Read error: No route to host]
[17:44:28] <archivist> the starturn has an original fitment disk which is a lot larger diameter but does leave the drawbar hole free
[17:53:40] -!- dr0w has quit [Ping timeout: 252 seconds]
[18:03:05] -!- per_sonne has quit [Quit: Be back later ...]
[18:07:40] <mozmck> heh! everyone should quit using the antiquated IRC:
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support/reply/57036
[18:10:20] <mozmck> On a similar note, a guy on the kicad channel who also dislikes forums in general, said that this one was actually really nice:
http://www.discourse.org/ here is a forum that uses it
https://forum.kicad.info/
[18:10:58] <mozmck> I believe he said you can use it like a mailing list.
[18:14:56] <archivist> odd forum error The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
[18:15:33] <archivist> This problem can sometimes be caused by disabling or refusing to accept cookies., never none that on this box
[18:16:54] <mozmck> interesting, it works for me.
[18:17:21] <mozmck> I wouldn't have a problem with a forum if I can just use it from email and don't have to get on the forum :)
[18:18:06] <mozmck> I'm on one mailing list that uses google groups I think, and it works like that. Just looks like a mailing list to me, but it has a web interface as well.
[18:20:21] -!- skunkworks [skunkworks!~chatzilla@69.4.98.27] has joined #linuxcnc-devel
[18:20:39] <archivist> you seem to have extended the correct url
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support is all I need
[18:21:52] <mozmck> Oh, for our forum link, I thought about a reply but decided not to :)
[18:23:01] <mozmck> It's the FLTK mailing list I'm on that is at googlegroups.
http://www.fltk.org/newsgroups.php You can subscribe by mail without having a google account (which I don't), and then it works just like a mailing list.
[18:28:55] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[18:38:47] -!- SkramX_ has quit [Ping timeout: 252 seconds]
[18:39:09] -!- meryan00 has quit [Read error: Connection reset by peer]
[18:39:53] -!- Jeebiss has quit [Ping timeout: 252 seconds]
[18:42:57] -!- DGMurdockIII has quit [Read error: Connection reset by peer]
[18:48:07] <mozmck> I'm wanting to use a button to trigger an action in a custom HAL component. A HAL_Button is momentary, so if it is not pressed long enough the component will miss the signal. Is there an easy way to do this?
[18:48:34] <archivist> a latch
[18:50:24] <cradek> sounds like the whole button strategy is wrong
[18:50:40] <cradek> what you really want to know is if there's been a rising edge since you read the "button" last
[18:51:15] <cradek> yeah the button latches on, and when you read it the latch is cleared?
[18:51:21] <mozmck> rising edge? this is not a physical button...
[18:51:29] <mozmck> is there a latch component?
[18:51:55] -!- nerdfiles has quit [Ping timeout: 264 seconds]
[18:51:57] <archivist> in software one sets a flag
[18:52:09] <cradek> probably, but it seems like it should be part of the button
[18:53:00] <andypugh> mozmck: There is a latch, and you could run it in the base thread, but just how short is this button press?
[18:54:12] <mozmck> Hmm, maybe I can do it in python in the button handler. Set an IO type HAL pin, so it can be unset by the other component.
[18:54:54] <andypugh> If I built uspace on a normal kernel because (hypothetically speaking) am an an imbecile. Would I need to re-make on a PREEMPT-RT kernel to get it to work in an actual realtime config?
[18:55:37] <andypugh> mozmck: By the time the button handler has seen it, it would seem that the “consumer” of the pin would have seen it.
[18:56:17] <mozmck> It's a button on the screen - I don't know how long it takes for the HAL pin behind it to update. The consumer is another userspace HAL component that reads it's pins about every 20ms
[19:02:00] <cradek> interestingly, hal I/O pins would be perfect for this
[19:02:14] <cradek> you set the pin true by poking the button, it sticks in
[19:02:30] <cradek> when the component reads it and finds a true, it sets it back to false, and the button pops out to show you it's been read
[19:03:20] <cradek> I bet a suitably smart person could add that kind of HAL_Button
[19:04:30] <cradek> you have the extra benefit of seeing how fast your component is consuming the buttonpokes (if it's reading once a second you won't be able to poke twice in a second and then be confused by your frobnicator only dispensing one widget)
[19:05:25] <andypugh> I am actually meddling with HAL buttons at the moment. The bit I am having most enjoyment from is pulling different button graphics from a common SVG file.
[19:05:38] <cradek> neat
[19:05:43] <andypugh> rsvg makes that pretty easy.
[19:06:34] <andypugh> http://pastebin.com/4t2Y8PfM in case it sounds useful.
[19:07:04] <andypugh> And I just noticed “make_shape”. That’s dead code (jim)
[19:08:29] -!- per_sonne has quit [Ping timeout: 246 seconds]
[19:09:10] <mozmck> cradek: thanks, that is what I was thinking.
[19:09:25] <mozmck> maybe I'll make a HAL_IO_Button or something
[19:09:37] <cradek> mozmck: it sure sounds like a good thing, doesn't it
[19:10:01] <mozmck> Does to me!
[19:12:42] <mozmck> I wonder if there would be any interest in Qt binding for linuxcnc at some point. gtk-2.0 is not supported any more I believe, gtk-3.0 is mess, and many projects are going over to qt nowadays.
[19:13:14] <cradek> oh probably
[19:13:43] <cradek> it makes me sad to accumulate even more dependencies, but the writing might be on the wall
[19:13:45] <mozmck> I've never used qt, but I think *everyone* I have read or talked to that have used it says it is great overall - especially if they have also used gtk :)
[19:14:24] <cradek> yes seems like it's the one that's currently in style
[19:14:26] <mozmck> true
[19:15:35] <cradek> long ago, one day when he was bored, I think jepler rewrote AXIS in qt, or maybe it was gtk
[19:15:43] <mozmck> I have never been fond of gtk myself. It's a real pain compared to other toolkits I've used (win32, fltk, wxwidgets)
[19:16:08] <cradek> heh wxwidgets, the one that's never been in style
[19:16:33] <mozmck> Someone wrote a Qt interface for machinekit, but I think it uses a lot of the new stuff in that.
[19:16:51] <mozmck> if you've ever written MFC code, wxwidgets is easy to learn.
[19:17:01] <cradek> nope not me
[19:17:02] <mozmck> Kicad uses wxwidgets.
[19:19:30] <mozmck> for small utilities I really like FLTK. you can statically link to it and it add about 400K to your binary. cross-platform, simple, and fast.
[19:21:20] <andypugh> What does “Note: Using POSIX realtime” indicate?
[19:25:14] -!- rob_h [rob_h!~robh@90.212.252.1] has joined #linuxcnc-devel
[19:25:35] <andypugh> I am wondering if ./configure is failing to spot the real-time-ness of my kernel
[19:26:00] <mozmck> I think it means linuxcnc is using uspace realtime
[19:26:14] <andypugh> Yes, but which one?
[19:27:12] <mozmck> Not quite sure how it works, but I think linuxcnc just has to set it's priority to get realtime if the kernel is preempt-rt, and if it is not then it doesn't work as well.
[19:27:42] <andypugh> Does 125,000 latency sound right for prempt-rt? I was hoping for better.
[19:28:48] <mozmck> I guess that depends on the hardware.
[19:29:03] <andypugh> Opening a web-browser just gave me 6,871,000 latency.
[19:29:05] <mozmck> PCW was saying that 50,000 was not too good.
[19:29:13] <mozmck> is that the rpi2?
[19:29:16] <andypugh> Yes
[19:29:16] <cradek> andypugh: that sounds pretty unusable
[19:29:20] <cradek> :-(
[19:29:39] <mozmck> I wonder if there are kernel settings that might help that.
[19:29:40] <cradek> did you do the make setuid?
[19:29:54] <andypugh> No, I didn’t do the setuid
[19:29:57] <mozmck> Oh, yes, that did make a difference in my testing last night.
[19:29:59] <cradek> I think it needs that to become realtimeish
[19:30:08] <andypugh> I thought that was only run-in-place?
[19:30:13] <cradek> oh right
[19:30:16] <cradek> what are you running?
[19:30:42] <memfrob> i'm getting 5ms in RTAI right now but with uexplained kernel locks
[19:30:44] <mozmck> did you do a 'make install' ?
[19:30:52] <mozmck> 5ms?
[19:30:55] -!- mhaberler has quit [Read error: Connection reset by peer]
[19:31:11] <memfrob> indeed. lowest numbers i've seen yet
[19:31:17] <memfrob> (on my board)
[19:31:18] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[19:31:22] <cradek> you must mean a different unit
[19:31:28] <memfrob> us?
[19:31:34] <cradek> you tell us :-)
[19:31:55] <andypugh> cradek: I used —prefix=usr to get an installed version. Was that wrong?
[19:31:57] <memfrob> the unit latency-test uses
[19:32:05] <cradek> probably us (5,000 ns)
[19:32:15] <memfrob> yes that
[19:32:20] <cradek> andypugh: not so much wrong as untested and hard to uninstall
[19:32:46] <cradek> andypugh: pretty much we test rip, and packaged into a deb
[19:32:54] <andypugh> But rip is such a pain, you have to open a terminal every time
[19:33:29] <andypugh> Is there any clue in the configure output that the system has detected a realtime kernel?
[19:33:40] <memfrob> andypugh: /home/<your user>/.bashrc
[19:33:48] <cradek> I thought "create desktop shortcut" still worked if rip
[19:34:21] <cradek> and: my rip says 'Note: Using POSIX non-realtime'
[19:34:25] <cradek> andypugh: ^
[19:34:37] -!- karavanjo1 has quit [Ping timeout: 255 seconds]
[19:34:40] <andypugh> I thought (probably wrongly) that rip-environment only had any context at all inside a shell
[19:34:43] <cradek> a plain kernel, not setuid
[19:34:53] -!- f1oat3 [f1oat3!~f1oat@AMontsouris-553-1-24-149.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[19:34:59] <andypugh> Ah. Well, that’s a shame then
[19:35:32] <cradek> it does seem like it all worked right if yours is saying that
[19:35:33] <andypugh> I don’t think 6mS latency with prreempt-rt was worth the time invested
[19:36:24] <cradek> that's a better result than this guy, who got freezes:
http://article.gmane.org/gmane.linux.rt.user/13057
[19:36:49] <mozmck> andypugh: you might try running from rip and run do make setuid
[19:37:07] <mozmck> in case the setuid did not get done right by make install
[19:37:33] <cradek> can't hurt, but I bet the message saying it works is right
[19:38:00] <mozmck> I think I got that message even before I ran make setuid
[19:38:06] <mozmck> but latency was much worse
[19:38:14] <cradek> hmm!
[19:38:33] <mozmck> can test it right now because I'd have to reboot
[19:39:04] <cradek> andypugh: perhaps try
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Benchmarking
[19:41:14] -!- nerdfiles has quit [Ping timeout: 272 seconds]
[19:41:17] <andypugh> If I _do_ create a run-in-place where does the code end up?
[19:41:26] <andypugh> In the git directory?
[19:41:38] <mozmck> I tried compiling that cyclictest, but it failed to find numa.h
[19:42:00] <cradek> yes it's all written inside the source tree itself
[19:42:06] <mozmck> in linuxcnc-dev/bin share, etc
[19:42:26] <andypugh> Which in this case is physically on a diferent machine and nfs-mounted
[19:42:53] <andypugh> (Not that is has to be)
[19:43:11] <andypugh> Bear with me, I may be gitting for some time
[19:44:08] <cradek> if hurting for space or time, git clone --depth 1
[19:48:57] <andypugh> mozmck: The bottom of the cyclictest page says what to o about numa.h
[19:55:45] -!- mhaberler has quit [Ping timeout: 246 seconds]
[19:57:54] <mozmck> ooh, I didn't see that.
[20:00:04] <cradek> andypugh: I guess my usual git clones are all on nfs too, but I never think about it
[20:00:28] <cradek> andypugh: my desktop has nfs home directory because zfs
[20:04:39] <andypugh> Are they pysically-remote nfs though?
[20:04:56] <cradek> well the basement
[20:05:23] <cradek> it's gigabit
[20:06:11] -!- b_b has quit [Remote host closed the connection]
[20:07:34] <mozmck> So is there a way to make gremlin show the toolpath even if all the tools are not found, and notify the user of the problem?
[20:07:58] <mozmck> What about doing a manual toolchange, do you need a tooltable for that?
[20:08:39] <cradek> if a tool is not found, that's an error, and running the gcode stops
[20:08:53] <cradek> whether manual or not, doesn't matter
[20:09:02] <jepler> t1 is an error if there's no entry in the tool table?
[20:09:08] <cradek> yes
[20:09:15] <jepler> it's been awhile since I have used linuxcnc, I didn't even know that
[20:09:42] <cradek> t789 => Requested tool 789 not found in the tool table
[20:15:40] <mozmck> So I need to figure out a way to let the user know that - other than just not displaying the toolpath
[20:17:37] <mozmck> If you are not using cutter compensation, why should it be an error if there is not an entry or wrong entries for the tools?
[20:26:45] -!- erve has quit []
[20:28:24] -!- per_sonne has quit [Ping timeout: 252 seconds]
[20:30:38] <cradek> mozmck: there's an error, right? that's how you let them know, isn't it? there are lots of ways a program can fail
[20:30:43] <cradek> they should all give errors
[20:30:54] <cradek> maybe I don't understand something here
[20:32:11] <mozmck> It's probably me that doesn't understand a lot :)
[20:32:33] <mozmck> I don't know if there is an actual error when loading the gcode.
[20:32:48] <cradek> in AXIS there is
[20:32:53] <cradek> and the preview stops
[20:33:24] <andypugh> RPi channel discussion suggests that the Pi GPU can interrupt the ARM processor. Which is not a recipe for great latency.
[20:33:25] <cradek> because if you run it, it'll stop there and error - so that's a perfectly correct preview!
[20:38:54] <mozmck> ok, so axis does that, but gscreen-gaxis does not and gives no indication of the error other than in the terminal I started it from.
[20:39:19] <cradek> that feels a lot like a bug
[20:39:45] <mozmck> gscreen seems to need a bit of TLC
[20:41:54] -!- per_sonne has quit [Ping timeout: 245 seconds]
[20:43:59] <andypugh> A compiler warning, probably of no relevance:
[20:44:01] <andypugh> Compiling emc/task/taskmodule.cc
[20:44:25] <andypugh> tmp/ccKMWBKw.s: Assembler messages:
[20:44:26] <andypugh> tmp/ccKMWBKw.s:17468: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
[20:44:56] <andypugh> I guess that ARMv-anything is not really a core LinuxCNC concern?
[20:44:59] <cradek> andypugh: I think that means there's a bug in your toolchain, not your code
[20:45:25] <jepler> if linuxcnc contains an __asm__ which directly specifes a swp{b} instruction, then it's a linuxcnc bug. otherwise, it's a toolchain bug.
[20:45:25] <cradek> unless you've got arm assembler hardcoded in taskmodule.cc which I bet you don't
[20:45:33] <jepler> http://stackoverflow.com/questions/13584091/arm-warning-swpb-use-is-deprecated-for-this-architecture
[20:46:06] <cradek> > I fixed the problem by upgrading to a newer version of GCC.
[20:46:08] <cradek> sigh
[20:46:13] <andypugh> I try to keep out of anything ending .cc :-)
[20:47:50] <andypugh> This gcc was installed at the weekend, so probably isn’t very old…
[20:48:35] <cradek> maybe 6 days is pretty old in the arm world
[20:50:51] <andypugh> I could hate Arm if it wasn’t the only bit of computer industry the UK has left.
[20:51:42] <cradek> I bet in 10 years they'll just work, like i386/amd64 systems do today
[20:51:45] <cradek> that will be nice
[20:52:12] <jepler> andypugh: I suspect that the cause is this:
https://svn.boost.org/trac/boost/ticket/5331
[20:52:38] <jepler> if raspbian is like debian wheezy, it has boost 1.49. emcmodule.cc does indirectly use boost smart_ptr
[20:54:05] <jepler> from my googling, when the swp instruction is encountered, it'll enter the kernel and be emulated
[20:54:21] <jepler> so it'll be slower but that's not important in taskmodule
[20:55:23] <andypugh> It seems unlikely that the Pi will be usable anyway.
[20:55:42] <jepler> I got linuxcnc non-realtime running on it. it didn't perform very well.
[20:55:47] <jepler> the odroid u3 is still far faster than the pi2
[20:56:18] <andypugh> I have the Pi2 running Preempt-RT. It still appears to be awful.
[20:56:29] <jepler> preempt-rt isn't going to make it perform better, that's for sure
[20:56:33] <jepler> build times are abysmal
[20:56:48] <jepler> there's too little RAM to take advantage of the multiple cores when building linuxcnc, so that's incredibly painful
[20:57:21] <andypugh> I was rather hoping that Preempt-rt would give better alatency than Posix, though.
[20:58:39] <jepler> yeah
[20:58:46] <jepler> I hear you
[20:59:24] <andypugh> I might see what the Udoo does with PREEMPT now that I am on a roll :-)
[20:59:40] <andypugh> That doesn’t have the wierd “GPU as Master” configuration.
[21:00:02] <andypugh> (THough that configuration might be why the graphics performace is good, and that of the BBB is awful)
[21:00:31] <andypugh> Maybe the Dream-Team is a BBB + PRU for Realtime and a remote Pi for the GUI…
[21:00:52] <andypugh> Or you could just use a cheap Atom board nad get on with making parts.
[21:00:55] <cradek> or an effing pc
[21:01:56] <andypugh> Hmm, maye use an aArduino to bridge the data from the BBB PRU to a Mesa FPGA card :-)
[21:02:17] <cradek> I got a great one for $20 from goodwill (dual core, including 3GB ram) but had to spend $25 to get a parallel port from newegg to run my pluto
[21:02:23] <jepler> andypugh: once you fix the latency problems in bbb's kernel spi driver, you could spi to a mesa fpga
[21:02:26] <jepler> no prus needed
[21:02:46] <andypugh> Does hm2_spi work by the way?
[21:03:05] <andypugh> I have seen the file in the directory but heard nothing of it.
[21:03:15] <jepler> hm2_spi works for me on the odroid u3 with preempt-rt, but I had to mdoify the kernel-side SPI code before it had good latency.
[21:03:25] <jepler> I worked on that nearly a year ago now
[21:03:32] <seb_kuzminsky> did the rt-preempt folks accept your spi-driver patch?
[21:03:40] <jepler> as far as I know, I'm the only one who's ever used, it, but so many things are like that
[21:03:50] <jepler> seb_kuzminsky: no, I didn't try very hard either
[21:06:21] -!- johtso has quit [Quit: Connection closed for inactivity]
[21:07:24] <micges> jepler: your kernel spi driver modifications are on github?
[21:08:32] <jepler> micges: yes, they're the top few commits at
https://github.com/jepler/odroid-linux/commits/odroid-3.8.13-rt
[21:09:00] <jepler> I have been meaning to try with 3.18. I think that 3.18 has a devicetree for the u3 and of course it now has an rt patch
[21:09:21] <andypugh> Would it be totally stupid to consider a bit-banged EPP interface usinf RPi GPIO?
[21:09:21] -!- FinboySlick has quit [Quit: Leaving.]
[21:09:51] <andypugh> 3.18.9 + rt-5 seems pretty smooth to patch and make.
[21:11:32] <andypugh> After my trials and tribulations with Udoo and Xenomai it came as a huge surprise to just watch the patch take with no messing about.
[21:12:13] <andypugh> (It makes me wonder why it is a patch at all, and not just a compile flag)
[21:12:52] <jepler> andypugh:
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ suggests that C can toggle I/O pins at 22MHz, probably around the same on pi2
[21:13:25] <jepler> so it's not implausible to manage single-digit MB/s in software EPP
[21:14:23] <andypugh> Which is probably all you need for 7i43 and friends.
[21:14:57] <andypugh> But after compiling run-in-place and sudo make setuid I _still_ have 7.5mS latency, so that seems like “experiment over” to me.
[21:15:21] -!- gonzo_nb has quit [Remote host closed the connection]
[21:15:23] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[21:15:24] <jepler> :-/
[21:15:27] <jepler> opposite of fun times
[21:17:25] -!- fablab has quit [Ping timeout: 265 seconds]
[21:18:40] <andypugh> Pi2 is Arm7. RTAI supports Arm7.
[21:18:49] <jepler> andypugh: if it says 'Note: Using POSIX realtime' then you're not going to get real-er time without changing the kernel.
[21:18:55] <andypugh> But I doubt that RTAI would be any better really.
[21:19:23] <andypugh> jepler: I already changed the kernel. You mean changing it some more?
[21:19:25] <jepler> were the m------k-- people promoting xenomai for pi? I forget.
[21:19:47] -!- asdfasd has quit [Read error: Connection reset by peer]
[21:19:47] <jepler> andypugh: yeah, finding whatever is bad and fixing it. not something to undertake on a friday night
[21:20:20] <andypugh> I think the bad thing is that the GPU preempts the Arm whenever it wants to access memory.
[21:20:22] <jepler> .. looks like, based on this probably-stale page
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild
[21:21:01] <jepler> (those images of course could not work on pi2)
[21:22:06] -!- DGMurdockIII has quit [Quit: Leaving]
[21:27:01] <jepler> see you guys
[21:27:14] -!- eeFuchs has quit [Remote host closed the connection]
[21:27:20] <andypugh> Goodnight
[21:27:53] <andypugh> memfrob: Any thoughts on RTAI on Pi?
[21:28:44] <andypugh> (Actually, not worth considering as that doesn’t support hm2_eth)
[21:28:58] <memfrob> rtai barely supports arm
[21:29:46] <memfrob> and rtai has to be made for each arm board, specifically the timer
[21:30:25] <memfrob> rtai is fail for anything non-x86
[21:30:54] -!- microniko has quit [Remote host closed the connection]
[21:36:26] <memfrob> that's why i dropped anything non-x86 in rtai
[21:43:03] -!- per_sonne has quit [Ping timeout: 256 seconds]
[21:47:40] -!- theorbtwo has quit [Read error: No route to host]
[21:55:31] -!- unfy has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
[21:58:12] -!- jvrousseau has quit [Quit: Textual IRC Client: www.textualapp.com]
[22:05:26] <memfrob> builing xenomai for arm boards though is really easy, toughest part is getting the kernel to boot.
[22:05:56] <memfrob> strip down as much as possible for low latency, add performance hacks and such, adjust power management yada yada and hope it loads
[22:06:11] <andypugh> But then LInuxCNC won’t run on it...
[22:07:31] <memfrob> true but linuxcnc could use some rtapi work.
[22:08:12] <memfrob> it could really use a direct ipipe handler, no need for xenomai or rtai.
[22:08:43] <mozmck> guess I stepped in it now :)
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support
[22:09:01] <memfrob> that should be the long term fix because right now i'm the only dev for rtai for linuxcnc, linuxcnc doesnt support xenomai without using mhaberler's stupid branches, and preempt-rt has bad performance
[22:09:51] <memfrob> and i'm not always going to be able to re-write all of paolo's stuff but i've been pacing myself carefully but i dont think i can fix the issues i'm having with the new magma branch.
[22:10:16] <memfrob> so rtai may just need to be dropped if i can't fix it and nobody else will. *checks thread*
[22:11:13] <mozmck> what is it about paolo's stuff that needs fixing/re-writing for linuxcnc?
[22:11:30] <memfrob> pretty much everything.
[22:12:03] <memfrob> i'm lucky if i can ever get upstream magma to compile.
[22:12:28] <mozmck> hmm, I haven't tried in quite a while
[22:12:55] <memfrob> the only good working branch that works with linuxcnc right now is my master branch at github.com/ntulinux/rtai
[22:13:23] <memfrob> dev branch i'm still working on but i dont know for how much longer considering i've hit a dead end
[22:14:51] <memfrob> i'm diffing it one more time (4th try) in an effort to try and notice any changes to explain my kernel crases, if not, that's it.
[22:15:09] <memfrob> every time i diff the trees i see nothing that stands out.
[22:15:59] <memfrob> math support, scheduler, kernel patches, inlining and compiler flags are the main things that need to be changed
[22:18:21] <memfrob> the rest is all code clean-up so it's easier for me to re-write the tree and get a better understanding of what's going on.
[22:18:47] <memfrob> bbl
[22:24:59] -!- f1oat3 has quit [Ping timeout: 256 seconds]
[22:29:13] -!- skorasaurus has quit [Ping timeout: 255 seconds]
[22:35:17] -!- chillly has quit [Quit: Ex-Chat]
[22:47:28] <PCW> decent RTAI latency:
[22:47:29] <PCW> http://ibin.co/1vWM6bCQvh3l
[22:48:30] -!- nofxx has quit [Changing host]
[22:52:27] -!- Deejay has quit [Quit: bye]
[22:55:17] <skunksleep> Someone gave us a i3 computer that seems to have awesome latency
[22:55:27] <skunksleep> Levino
[22:57:42] <PCW> I suspect (but am to cheap to find out) that say a H81 or H97 based MB and almost any Pentiium/I3/I5/I7 would be very good
[22:58:28] <jepler> give it a few more years and we won't be able to put linux on PCs anyway.
http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/
[22:58:36] <jepler> we can all just go home at that point
[22:58:38] <jepler> yay
[23:00:53] <PCW> I suspect that would backfire at this late date
[23:07:29] <mozmck> I hope so. Seems like Microsoft is up to old tricks.
[23:07:53] <jepler> we can meet back here in two years and see whether one of dell, hp, or lenovo has shipped a Windows 10 PC with Secure Boot mandatory...
[23:08:52] <mozmck> dell seems to have a pretty active linux group, and you can get a dell laptop with linux pre-loaded.
[23:10:20] <PCW> everything just worked on used dell I got to test preemt-rt/hm2_eth
[23:11:50] <jepler> jon e has long favored used dells iirc
[23:12:49] <mozmck> I made a HALIO_Button. I used a togglebutton because I don't think you can set a regular GtkButton active like that?
http://pastebin.com/0JnxaZyp
[23:13:09] -!- FreezingAlt has quit [Ping timeout: 256 seconds]
[23:13:13] <mozmck> ignore the configure and config.in changes :-/
[23:14:03] <PCW> This was a latitude E6420 $190 4G 320G HD Win7 Pro 2.5 GHz second gen I5
[23:14:50] <PCW> decent preemt_rt performance unless you pull the charger
[23:16:08] <mozmck> So is that 4us max latency shown?
[23:17:05] <PCW> Thats not a laptop :-)
[23:17:51] <mozmck> ok, but I'm not sure if I'm reading the histogram correctly.
[23:18:32] <PCW> Thats a cheap but recent desktop motherboard (Asrock H97) and a Pentium G3258 (cheap Haswell type dual core)
[23:18:44] -!- lnr has quit [Ping timeout: 265 seconds]
[23:19:10] <mozmck> not bad.
[23:19:52] <PCW> I cant remember the laptops numbers for RTAI but they were about 40 usec after running hd videos all day in preemt-RT
[23:20:18] <PCW> (so fine for hm2_eth)
[23:27:09] <mozmck> PCW: are you using isolcpus or set_affinity for preemt-rt?
[23:27:23] <PCW> no
[23:28:02] <mozmck> ok
[23:28:58] -!- micges has quit [Quit: Ex-Chat]
[23:32:08] -!- per_sonne has quit [Ping timeout: 264 seconds]
[23:32:16] -!- tom_o_t has quit [Ping timeout: 256 seconds]
[23:36:03] <PCW> when I started i fussed with IRQ affinities some but never got noticeable improvement in latency
[23:36:05] <PCW> (but I could have made some mistake and you really need some kind of automated long term testing to see real differences)
[23:38:24] -!- Mr_Sheesh has quit []
[23:39:45] -!- mhaberler has quit [Quit: mhaberler]
[23:40:54] -!- adb has quit [Ping timeout: 252 seconds]
[23:44:31] <memfrob> has anyone here actually tried windows 10 tech preview?
[23:45:13] <memfrob> im waiting for the first D3d12 game and i was going to give it a whirl in my r9 290 gpu
[23:54:03] -!- acdha has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
[23:54:47] -!- acdha has quit [Client Quit]
[23:58:23] <mozmck> I stay away from windows as much as I can. When I have to run it I'm on XP still
