Back
[00:01:52] <CaptHindsight> based on Debian Testing
[00:04:44] <CaptHindsight> gotta love these 10 minute installs
[00:20:58] <seb_kuzminsky> what video card is in use?
[00:29:32] <CaptHindsight> AMD APU integrated
[00:31:00] <CaptHindsight> ok it needs libboost-python1.46.1, the command line says >= but a higher version is already installed
[00:33:02] <CaptHindsight> also wants libgnomeprint and libgnomeprintui
[00:34:56] <CaptHindsight> seb_kuzminsky: this is on a A10 6800K quad core 4.4ghz and 85x chipset (Gigabyte F2A85X-UP4)
[00:35:40] <seb_kuzminsky> yeah, libgnomeprint is an obstacle to supporting trusty....
[00:40:10] <CaptHindsight> I'm trying it with those packages added
[00:40:23] <CaptHindsight> just a few minutes for results
[00:50:30] <CaptHindsight> same behavior in Mint Debian Mate (debian testing) now at 150K when I max a glxgears window
[00:52:13] <CaptHindsight> I'll install ubuntu precise and debian wheezy tomorrow and anything else you'd like to try
[02:45:53] <CaptHindsight> this is odd, I just installed precise with 3.4.55 RTAI2 and master-rt and the latency is just as bad as both versions of Mate
[02:46:44] <CaptHindsight> I usually use v2.5_branch-rt without any problems, maybe master-rt is the problem?
[06:28:42] <micges-dev> logger[mah]: habibi
[06:28:42] <logger[mah]> micges-dev: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-07-11.html
[09:43:18] <cradek> jepler: thanks for doing that analysis. The reasoned results are different from my knee-jerk thoughts.
[09:44:20] <jepler> it's right up my alley
[09:46:30] <jepler> of course, I wish there were an easy way for it to be 100% right
[10:14:45] <ssi> hm... you guys ever seen BeRTOS?
[10:15:12] <ssi> http://dev.bertos.org
[10:15:15] <pcw_home> is that related to ErnieOS?
[10:15:21] <ssi> not legally ;)
[10:32:13] <seb_kuzminsky> cradek: it amazes me how short & simple the multi-tlo branch is, for how much functionality it offers
[10:32:55] <seb_kuzminsky> it's so straight forward once you frame the problem the way you did
[10:33:29] <seb_kuzminsky> it needs docs, then it's ready to merge i think
[10:34:01] <cradek> andy's doing the hard part figuring out the remap...
[10:34:30] <cradek> haha now chris morley says there's such a thing as T010101
[10:34:49] <cradek> but of course you can twiddle the remap to handle that if you want...
[10:35:19] <seb_kuzminsky> we're doing binary tool numbers now??? ;-)
[10:35:41] <skunkworks> that is what the k&t does.. ;)
[10:35:50] <cradek> I thought those are octal
[10:36:05] <skunkworks> originally - but I just used strait binary
[10:36:50] <skunkworks> hmm - maybe it would be easier to call the tool with strait binary.. Then you would not have to convert.. Just 15 1/0...
[10:46:25] <pcw_home> hmm looks like a sserial bug with bit arrays > 64 bits
[10:59:33] <CaptHindsight> have to track down why 3.4.55 RTAI on Gentoo works just fine on a A8 cpu+ a85 chipset yet is poor with Precise and same kernel
[11:00:26] <pcw_home> tons of added crap?
[11:01:08] <pcw_home> video driver different?
[11:01:18] <CaptHindsight> it's odd I changed over to the linuxcnc 2,5 repos from master with Precise and the problem remained
[11:01:48] <CaptHindsight> we'll do some drive swapping over the weekend between working systems
[11:02:20] <pcw_home> find the rat dropping in the capers...
[11:03:18] <CaptHindsight> this is the same cpu and chipset that memleak used for all the RTAI development
[11:03:50] <CaptHindsight> liveCD works just fine
[11:03:51] <pcw_home> does wheezy have the same issue?
[11:04:24] <pcw_home> old 10.04 livecd?
[11:04:38] <CaptHindsight> tried Mint in both Ubuntu and debian flavors plus ubuntu precise last night, all behave the same
[11:06:01] <seb_kuzminsky> CaptHindsight: latency comes from the interaction of the rtai kernel and the hardware - which branch of linuxcnc you use shouldn't matter
[11:06:06] <CaptHindsight> yes, it's been running the 10.04 livecd with the 2.6.32 the past 6 hours with latency <8K
[11:07:05] <CaptHindsight> seb_kuzminsky: ok, I wasn't sure since I was using 2.5 vs master the past few months, and my testing last night was with master
[11:08:27] <CaptHindsight> I'm going to put this drive into memleaks dev system later and see what it does there
[11:09:06] <seb_kuzminsky> it makes me unhappy that the new rtai kernel performs worse than the previous one
[11:10:24] <CaptHindsight> 3.4.55 RTAI has been fine for me on the Asrock E350M1's (embedded APU)
[11:10:40] <skunkworks> depends on the hardware.. I now have seen pcie video cards that worked fine on 10.04 don't work fine on wheezy
[11:11:01] <CaptHindsight> we built a bunch of systems that are just fine
[11:11:16] <pcw_home> I would suspect the video driver next after the kernel
[11:11:52] <skunkworks> (nvidia
[11:11:54] <skunkworks> )
[11:12:16] <pcw_home> eww
[11:12:56] <CaptHindsight> yes, we'll be comparing drivers and BIOS settings etc
[11:40:36] <cradek> seb_kuzminsky: I'm working on the docs. Although I admit it's a new feature, I think this change is both useful and safe enough to consider sneaking it into 2.6.
[11:44:12] <KGB-linuxcnc> 03Chris Radek 05cradek/multi-tlo d79902d 06linuxcnc 10docs/html/gcode.html G43.1 works with all axes, not just XZ now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d79902d
[11:44:12] <KGB-linuxcnc> 03Chris Radek 05cradek/multi-tlo f3f8bb7 06linuxcnc 10docs/html/gcode.html 10docs/src/gcode/gcode.txt Documentation for G43.2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f3f8bb7
[12:16:06] <skunkworks> I don't seem to have any video cards here that support 3 monitors...
[12:16:17] <skunkworks> that was somewhat suprising...
[12:18:00] <pcw_home> There were some really old ones that supported 4 or more (for Bowling alleys etc)
[12:20:39] <skunkworks> ton of cards that have dvi/hdmi/vga - but you can only use 2 of the 3 at once.
[12:21:02] <cradek> can't you just use two cards?
[12:21:18] <cradek> or is that passe?
[12:21:36] <pcw_home> Yeah you should be able to use as many cards as you have slots
[12:21:47] <skunkworks> we tried every combination that we could think of.. No sucess...
[12:21:47] <pcw_home> http://www.matrox.com/graphics/en/products/graphics_cards/m_series/m9188pciex16/?utm_campaign=060710_InfoComm_Graphics_Pulse_link_octal&utm_medium=Newsletter&utm_source=InfoComm&utm_content=octal
[12:22:20] <skunkworks> pci/pci-e, pci/pci - same brand / different brands.. no luck.
[12:22:29] <skunkworks> they did not play well together
[12:22:43] <pcw_home> driver limitation?
[12:23:13] <skunkworks> no clue.. some blue screen - some just didn't boot.
[12:23:39] <pcw_home> probably confused the BIOS
[12:23:51] <skunkworks> picked up a 100 dollar card from best buy that supports 3 (hopefully)
[12:50:51] <pcw_home> I guess I'll make data 3x24 bits instead of 72 bits to work around the sserial driver limitation
[13:57:00] <skunkworks> well - that didn't work. But a 2 head card + old s3 pci card seems to work. go figure
[15:27:41] <cradek_> andypugh: thanks for working on the remap!
[15:27:49] <cradek_> argh my underscores
[15:28:18] <andypugh> I will push the sample config in a few minutes. I want to set a job going on the mill.
[15:28:36] <andypugh> Actually, make that in an hour or so, probably.
[15:28:41] <cradek> cool
[15:28:50] <cradek> I did the docs today
[15:29:31] <cradek> I'd like to convince seb it can go in 2.6, but I don't know what he thinks yet
[15:29:57] <cradek> the (non remap part) changes are very simple
[15:33:29] <andypugh> I would like to see it there. Even I am unlikely to break anything with a sample config.
[15:39:55] <andypugh> There might be an artificial and unnecessary conflation here. The lathe-style remap might still be useful even without compound offsets.
[15:40:34] <andypugh> T0201 could still be parsed as M6 T1 G43 H2 in the current version.
[15:40:39] <cradek> I agree
[15:41:21] <andypugh> Today was the first time I have seen mention of the Okuma T030201 format.
[15:41:26] <cradek> but my larger goal is to make that patch unnecessary by giving a flexible superset of what it does
[15:41:37] <andypugh> (which could extend indefinitely if you wanted to)
[15:41:54] <cradek> yeah me too. and this scheme is plenty flexible enough for it, so yay
[15:42:51] <andypugh> O100 if [#<tool> GT 0] ; Carry on adding offsets as long as you like
[15:43:33] <cradek> I love it
[15:45:09] <andypugh> I might even start using it. But I think I would change around the “encoding” with 01 being tool 1 base, 0100 being tool-wear 1, 010000 being an offset just for fun. :-) The 10001 as wear-1, 10002 as wear-2 scheme seems silly and non-obvious.
[15:59:38] <cradek> I think aram switched from m5i20 to hm2, didn't hook up any of his inputs right, and therefore has decided his cd download was bad
[16:00:10] <andypugh> He’s Stuart’s problem this time.
[16:00:23] <cradek> stuart has tried to help him for years :-/
[16:00:31] <cradek> they used to talk on the phone a lot
[16:01:51] <andypugh> He must be simply a nicer person than me.
[16:02:27] <cradek> you tried harder than most folks have
[16:02:54] <PCW> Ahh that must be the reason fr the limit switches not working (not hooked up in the sample config)
[16:03:04] <cradek> it's only a guess
[16:03:17] <cradek> I do suspect he's trying to change from m5i20 to hm2
[16:03:22] <cradek> ... but he didn't say so
[16:04:29] <cradek> I've made that change and it's actually relatively hard to redo all your ins and outs properly. the m5i20 driver had much more obvious pin names because it supported only one configuration of daughter cards.
[16:04:56] <PCW> yeah
[16:07:10] <andypugh> Clearly Seb is a bad person for not keeping the m5i20 names as aliases for the new pins.
[16:07:38] <andypugh> (actually, punting Aram a hal file of pin aliases probably _would_ fix it for him).
[16:07:42] <cradek> we didn't have aliases at that time, but I think it was one of the reasons we came up with aliases
[16:08:08] <andypugh> If only he hadn’t annoyed me so much I might even have done it for him.
[16:08:27] <cradek> well it's not just that - you have to set ins and outs and pullups and pwm rates and whatever all else, after reading the applicable manuals
[16:09:25] <cradek> it's more flexible now - that's a mixed blessing to users
[16:09:31] <cradek> eh
[16:09:46] <andypugh> Right! To the Workshop!
[16:09:57] <cradek> he has no idea even what the problem is he's facing
[16:12:52] <PCW> Got a working sserial remote as a 7I90 config (changed the I/O to x24 bits instead of 1X 72 because of sserial driver limitations)
[16:14:28] <PCW> the code is quite dreadful but it makes a cheap remote 72 bit IO for 3X Opto22 etc
[16:15:01] <PCW> even has similar blinklights
[16:16:56] <PCW> and uses HostMot2 as I/O so any HostMot2 function can be added (but with difficulty as the process data I/O has to be hand written)
[16:20:46] <micges-dev1> PCW: that's great!
[16:21:56] <micges-dev> PCW: now 7i90DB ;)
[16:23:36] <PCW> Have to finish the 7I92 and 6I24
[16:24:46] <PCW> and its a (terrible but public) example of working ss remote code
[16:25:03] <micges-dev> but it would be sane to have DB sserial remote boards?
[16:25:20] <PCW> not so much
[16:25:32] <PCW> for EPP sure
[16:25:40] <PCW> (or SPI)
[16:26:07] <micges-dev> right
[16:27:14] <PCW> currently is just plain I/O (active low) , theres a limit to what you can do with 96 bits and 2.5 M Baud
[16:28:07] <PCW> its setup for 72 bits in 72 bits out open drain mode (for OPTO 22 etc)
[16:28:53] <jepler> PCW: you think this 64-bit thing is a bug in the linuxcnc driver, or elsewhere in the chain?
[16:28:57] <PCW> only one mode (but since I understand it (unlike the PIC code) I can easily add more)
[16:30:09] <micges-dev> PCW: not much to add becouse as I understand you don;t have such low level access to read voltage levels or such
[16:31:10] <PCW> Its not so much a bug as a limitation (using 64 bit numbers and shifts instead of bit arrays)
[16:31:12] <PCW> I just changed the IO from in 0..71 to P1-In 0..23, P2-In 0..23 P3-In 00.23 etc
[16:31:38] <jepler> at the hal level, we still haven't come up with a good abstraction for an array
[16:32:30] <PCW> This is just internal (unpacking data into bits and vice versa)
[16:33:26] <jepler> ah such as loops like this
[16:33:26] <jepler> for (b = 0 ; b < conf->DataLength ; b++){
[16:33:30] <jepler> buff |= ((u64)(*pin->bit_pins[b] != 0) << b)
[16:33:32] <jepler> ^ ((u64)(pin->invert[b] != 0) << b);
[16:33:35] <jepler> }
[16:34:39] <PCW> Yep set bit 64 and you find that bit 0 and 64 get set
[16:36:36] <PCW> not an important issue ATM
[16:36:38] <PCW> I even think I discussed it with Andy a year or 2 ago and of course said:
[16:36:40] <PCW> why would we ever need more that a 64 bit bit field?
[16:39:22] <jepler> you said something about a limit of 96 bits too, where does that come in?
[16:39:26] <PCW> One good thing is that I learned our manual description of the protocol sucks
[16:39:28] <PCW> so I will add the missing bits I had to root around in the SSLBP source for
[16:40:22] <PCW> 96 is the current hardware limit but the protocol limit is 255 bits
[16:40:47] <PCW> (for data of type "bits")
[16:42:06] <PCW> the 96 is not likely to change until I add autobaud to SSLBP so 10 Mbit/sec remotes are supported
[16:43:09] <PCW> so not for a long time
[17:09:02] <jepler> by now, somebody must have written the header-only "library" to access bit oriented streams
[17:09:17] <jepler> we just need to find it and stick it into the sserial code
[17:24:14] <CaptHindsight> tried that same hard drive in another machine and precise 3.4.55 RTAI and Mint Mate Debian is just fine
[17:28:41] <CaptHindsight> Mint 17 (Trusty repos) also works with just slightly worse times 13K vs 8K
[17:30:18] <CaptHindsight> so Ubuntu Trusty should work as well
[17:31:57] <CaptHindsight> this is on an older Phenom II 3 core 2.8GHz cpu and AMD 780 chipset with integrated graphics
[17:32:50] <CaptHindsight> now to track down why the A10 4-core 4.4GHz APU with A85X chipset doesn't like 3.4.55 RTAI
[20:12:44] <KGB-linuxcnc> 03andy pugh 05cradek/multi-tlo 893390f 06linuxcnc 10(6 files) A demo config combining cradek's compounf offset (G43.2) and mah's * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=893390f
[20:12:44] <KGB-linuxcnc> 03andy pugh 05cradek/multi-tlo a7e5851 06linuxcnc Merge branch 'cradek/multi-tlo' of ssh://git.linuxcnc.org/git/linuxcnc into multi-tlo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7e5851
[20:13:30] <andypugh> Oh damn and blast.
[20:13:45] <andypugh> What is that merge thing?
[20:15:04] <andypugh> Why is it that I can _never_ figure out how to do the most obvious thing in git (ie, push my changes, and only my changes, to the branch I pulled from>)
[20:16:41] <andypugh> The only way I have found that works is to commit, then reset —hard the local branch, cherry-pick the commit, and then push.
[20:17:59] <andypugh> I actually thought after reading
http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/ that I has figured out the magic incantation.
[20:36:49] <CaptHindsight> after a few hours of running Mint Mate Debian (based on Gnome2) works as well as the livecd
[20:38:36] <CaptHindsight> the ubuntu based Mint 17 and Ubuntu 14.04 have more latency spikes when starting apps or playing video
[21:17:27] <KimK> CaptHindsight: I have recently installed Mint 17 Cinnamon 64 on a laptop, and I plan to install some flavor of Mint 17 on an old desktop, is there anything I can do to help?