Back
[00:00:26] <seb_kuzminsky> i see that hm2_eth does not re-enable ipv6 when it cleans up its iptables rule at the end, but that's probably pretty harmless
[00:00:46] <seb_kuzminsky> and it was that way before your simplification too, so...
[00:00:50] * seb_kuzminsky shrugs
[00:01:20] <seb_kuzminsky> looks good to me man
[00:01:26] <seb_kuzminsky> https://www.youtube.com/watch?v=vCadcBR95oU
[00:36:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 69eb876 06linuxcnc 10docs/src/hal/components.txt docs: rebrand the launcher program in hal/components.txt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=69eb876
[00:36:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 20b05da 06linuxcnc 10docs/man/man9/encoder.9 docs: update encoder.9 manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20b05da
[00:36:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6aebfc8 06linuxcnc 10docs/src/remap/structure.txt docs: un-fancify "the argspec parameter" anchor name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6aebfc8
[00:36:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 8163316 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/gui/gladevcp.txt 10docs/src/hal/components.txt 10docs/src/remap/structure.txt Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8163316
[07:02:08] <skunkworks> U2 concert was pretty awesome..
[07:04:46] <skunkworks> wow
[07:04:47] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148139
[07:07:17] <jepler> seb_kuzminsky: the point about adding a dependency is a good one.
[07:09:00] <jthornton> seb_kuzminsky, does this only apply within a single document page?
http://www.methods.co.nz/asciidoc/userguide.html#_section_ids
[07:16:02] <archivist> skunkworks, so many misunderstand error terms with both systems including that poster by the look of it :)
[07:18:03] <jepler> jthornton: the renumbering of IDs is going to be per HTML document
[07:18:04] <jepler> >
[07:18:04] <jepler> A numbered suffix (_2, _3 …) is added if a same named auto-generated section ID exists.
[07:23:49] <jthornton> What I meant to ask was can you use the synthesised chapter ID in a link from another chapter?
[07:24:19] <jthornton> if not then we still need the [[cha:name]] anchors
[07:26:20] <jthornton> be back in an hour, bicycle time...
[07:30:24] <jepler> > the missing section IDs are generated dynamically by the JavaScript TOC generator after the page is loaded. If you link to a dynamically generated TOC address the page will load but the browser will ignore the (as yet ungenerated) section ID.
[07:30:46] <jepler> it sounds like if the link is autogenerated, you can't go to it from another page
[07:30:53] <jepler> which is pretty much useless
[07:31:01] <jepler> should be easy enough to test
[09:17:04] <Tom_itx> JT-Shop,
http://linuxcnc.org/docs/2.7/html/getting-started/Updating-LinuxCNC.html
[09:17:06] <Tom_itx> is 404
[09:23:06] <mozmck> you're not allowed to update anymore...
[09:27:51] <mozmck> For any who is interested, here's a screenshot of our custom GUI as it currently is. Not finished yet but getting closer.
http://pasteboard.co/1BSphh90.png
[09:29:01] <skunkworks> mozmck, cool. How is your boss liking linuxcnc?
[09:29:23] <mozmck> The colorful buttons are a new HAL_LightButton gladevcp widget I'm working on. The light is controlled independently of the button - either with a hal pin or in code.
[09:29:28] <Tom_itx> looks nice
[09:29:48] <skunkworks> That is neet
[09:30:05] <mozmck> He's liking it so far, but we have not done a lot of using it yet.
[09:31:46] <mozmck> The light buttons can also have 2 button hal pins, and be used as a togglebutton for halui stuff that has a separate start and stop pin such as the flood, mist, and spindle controls.
[10:09:35] <seb_kuzminsky> Tom_itx: oops, thanks for the bug report
[10:10:16] <seb_kuzminsky> Tom_itx: jthornton recently reorganized the 2.7 docs, maybe something moved around or got dropped accidentally?
[10:10:43] <Tom_itx> probably accident. that's one i think we want
[10:11:39] <seb_kuzminsky> oh yes, that's an important document
[10:12:56] <seb_kuzminsky> if there's an emergency before he gets back from his bike ride, you can always go to the source, it's not as pretty as the rendered html but still very readable:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=docs/src/getting-started/Updating_LinuxCNC.txt;h=114667342670d3b302889605138292766abc3dbd;hb=refs/heads/2.7
[10:13:35] <jepler> whee, my 64-bit arm board should be here in time for the three-day weekend. (dragonboard 410c) I'm sure I'll be the first on my block to have one...
[10:14:04] <skunkworks> can you hook your spi interface to it?
[10:14:46] <jepler> skunkworks: it does have an SPI interface on a 40-pin 2mm header. if earlier steps like getting a RT kernel running on it work, that's sure in the plans
[10:14:55] <seb_kuzminsky> cool
[10:15:22] <seb_kuzminsky> is it the one from 96boards?
[10:15:46] <pcw_home> I like the fact that there a standard for the header position and pinout
[10:15:59] <seb_kuzminsky> bummer, they forgot like 3/4 of the ram
[10:16:03] <jepler> seb_kuzminsky: yeah
[10:16:13] <Tom_itx> http://www.arrow.com/campaigns-na/qualcomm/dragonboard-410c/
[10:16:14] <seb_kuzminsky> </snark>
[10:16:21] <jepler> seb_kuzminsky: 96boards own board, the hikey, is persistently not shipping. this one is from qualcomm but in the 96boards form factor
[10:16:41] <jepler> so there are all sorts of binary blob problems but that plagues virtually any arm board these days
[10:16:54] <seb_kuzminsky> no ethernet
[10:17:44] <jepler> the CPU is A53 which is the "power efficient" design, so it'll also be slow
[10:19:17] <seb_kuzminsky> there's a guy at the local hackspace from nvidia, he keeps trying to give people jetson boards to do projects with
[10:19:45] <seb_kuzminsky> the jetson is almost all GPU though, so i'm really pressed to think of something to do with it
[10:20:10] <jepler> some reports that AMD will come out with something in a larger form factor (enterprise is a superset of 96boards consumer form factor) that has SO-DIMMs for RAM
[10:20:12] <seb_kuzminsky> maybe we could run fancy nontrivkins simulations in the gpu to improve path planning for robot arms and such
[10:20:31] <seb_kuzminsky> jepler: the opteron a1100
[10:20:54] <seb_kuzminsky> i've been eyeing it as a possible hypervisor for an array of arm VMs for the buildbot
[10:21:14] <jepler> how many arm buildslaves do you need though?
[10:21:20] <seb_kuzminsky> currently 0
[10:23:28] <seb_kuzminsky> we currently build rip & runtests on armhf, an odroid u3 running wheezy
[10:23:32] <seb_kuzminsky> (uspace)
[10:24:55] <seb_kuzminsky> 0 09:02:21 seb@wheezy-armhf-u3 /home/seb> uptime 09:02:23 up 258 days, 18:22, 1 user, load average: 0.00, 0.01, 0.05
[10:25:07] <seb_kuzminsky> i'm impressed
[10:25:36] <jepler> hm this source puts A9 (odroid u3) and A53 at a similar relative performance
[10:26:07] <jepler> my odroid's uptime is small because it's on an outlet with a light switch that visitors to my house flip accidentally
[10:26:13] <jepler> bbl
[10:26:21] <seb_kuzminsky> hah
[10:29:46] <pcw_home> hm2_eth seems to run fine through a switch (my cheap Dlink GigE switch adds about 30 usec delay to each packet)
[10:29:48] <pcw_home> been running for about 5 days at 3 KHz
[10:30:31] <seb_kuzminsky> pcw_home: is that tip-of-2.7? or one of jepler's branches?
[10:30:46] <pcw_home> 2.7
[10:30:51] <seb_kuzminsky> nice
[10:31:11] <seb_kuzminsky> i wonder what rob's status is
[10:31:26] <seb_kuzminsky> maybe one of us should fix that last bug
[10:31:46] <pcw_home> Yeah it would be nice to fix that TP bug
[10:32:44] <seb_kuzminsky> jepler did the hm2 encoder dpll feature you wanted, right?
[10:33:01] <pcw_home> Yes and I tested it
[10:33:41] <seb_kuzminsky> great
[10:36:56] <pcw_home> I'd like to make the hm2_eth cards more discoverable by making them respond to broadcast UDP packets
[10:36:57] <pcw_home> but i will not be able to get the firmware part of that that for a while
[10:37:14] <pcw_home> - extra that
[10:38:46] <skunkworks> I have not heard back from rob. I emailed him this weekend.
[10:39:24] <seb_kuzminsky> my i recommend mdns/sd for that? it's a standard protocol that does exactly what you want, and is supposedly easy to implement on small embedded systems
[10:40:06] <seb_kuzminsky> try "avahi-browse -a" to see that machines on your local network support it, and add "-r" to resolve them to IPs
[10:40:33] <seb_kuzminsky> (it's in avahi-utils, probably installed already)
[10:40:47] <seb_kuzminsky> skunkworks: he must be busy
[10:41:05] <seb_kuzminsky> i guess he had a contract job with tormach and it ended?
[10:43:07] <skunkworks> seb_kuzminsky, he is. (started a new job - new fiance...)
[10:43:21] <skunkworks> I don't know the whole story with tormach.
[10:43:57] <CaptHindsight> jepler: how much was the 410c board? the 810 (or something) is ~$500
[10:44:05] <seb_kuzminsky> i wonder if they know about the problem
[10:44:33] <CaptHindsight> never minds found the link
http://parts.arrow.com/item/detail/arrow-development-tools/dragonboard410c#cnp2 $75
[10:44:39] <seb_kuzminsky> i guess it only shows up on high-accel machines, and the ones they sell are below the threshold so they haven't run in to it maybe?
[10:45:38] <skunkworks> I don't think it is high acceleration..
[10:46:04] <skunkworks> like - if the accelleration is set higher - the it doesn't violate.
[10:46:25] <seb_kuzminsky> hmm
[10:46:59] <skunkworks> I think pcw saw the same thing
[10:47:07] <seb_kuzminsky> you said on the forum that you had to set accel to 600 mm/s^2
[10:47:20] <seb_kuzminsky> i just emailed dan rogge at tormach asking if they've seen it
[10:48:58] <skunkworks> right - that is 23.6 in/s^2. My 30in/s^2 didn't see it.
[10:49:15] <skunkworks> (although I could double check...)
[10:49:21] <seb_kuzminsky> aha, i misunderstood that part
[10:53:49] <cradek> it reproduces with sam's gcode and settings of 211 and 600
[10:55:17] <seb_kuzminsky> in 2.7?
[10:56:09] <cradek> yeah
[10:56:15] <seb_kuzminsky> cool, thanks
[10:57:54] <seb_kuzminsky> drogge reports that their machines accelerate at 15 in/s^2 = 381 mm/s^2
[10:58:53] <cradek> it's near the .1ish mm long arc
[11:00:01] <seb_kuzminsky> i would not be surprisd if 0.1mm arcs are not widely tested
[11:01:57] <cradek> doesn't look like garbage-in (the task issue looks plausible)
[11:02:52] <cradek> the three arcs on lines 5/6/7 have exactly the same center point
[11:03:01] <cradek> and no Z component
[11:04:18] <cradek> so they are tangent
[11:04:45] <cradek> I'm surprised they get slightly different inimaxvels (the vel you can FO up to)
[11:04:47] * skunkworks gets some popcorn...
[11:14:44] <skunkworks> Hmm - I am running master and the first run of my gcode is faster than the second..
[11:15:08] <skunkworks> and I don't get the error the first run
[11:15:22] <skunkworks> I do set the feedrate at the top.
[11:15:25] <jepler> CaptHindsight: yes that's the one
[11:15:51] <cradek> I get different errors on the first and second runs
[11:17:36] <cradek> term2 and term3 change, which I guess means maxaccel changes
[11:19:29] <PCW> Sebastian, I'm afraid implementing mDNS would more than quadruple the code size
[11:21:28] <skunkworks> for me - when you first run the program it goes to the G1 postion (x54.834y-52.151) at shuttle instead of F1200. The second run - the move from 0,0 is at the expected 1200mm/m
[11:23:36] <skunkworks> I moved the Fword down to the G1 line and it is fine. I think it is confused as to what it should do first - G21 or F1200. I think the first time it runs it runs 1200in/s^2
[11:23:51] <skunkworks> (I am running an english config)
[11:24:12] <cradek> iirc by ngc spec, f1200 runs before the g21
[11:24:19] <cradek> weird but not a bug
[11:24:22] <skunkworks> well - that makes sense.
[11:24:32] <skunkworks> so - never mind. :)
[11:24:47] <cradek> http://www.linuxcnc.org/docs/html/gcode/overview.html#sec:Order-of-Execution
[11:27:21] <cradek> ah this little move is a "split cycle"
[11:27:37] <cradek> something about it taking less than a servo cycle to run at speed, so [something magic happens]
[11:27:42] <cradek> this might be above my pay grade
[11:29:24] <cradek> er maybe not, it's .000682 long which is way more than TP_POS_EPSILON
[11:29:56] <skunkworks> I do get it with 15in/s^2
[11:31:28] <skunkworks> hmm - I get it all the time now. I don't think it is acc dependant. Don
[11:31:41] <skunkworks> Don't know what I was doing before. I got it at 30in/s^2
[11:32:04] <skunkworks> but if my program wasn't running 'correctly' the first time - I might not have seen it.
[11:32:55] <skunkworks> cradek, I know he as fixed similar errors before - maybe git history?
[11:58:19] <cradek> well I'm not understanding the split cycle stuff, but I think this bug points right at that
[11:58:25] <cradek> maybe after lunch it'll make more sense
[12:30:24] <seb_kuzminsky> hi rogge
[12:36:44] <rogge> hi seb!
[12:36:55] <rogge> I'll be in and out..
[12:37:38] <seb_kuzminsky> sure, me too
[12:38:15] <skunkworks> rogge, - the first time you run the gcode program in an english config (I know pathpilot might be a little different) it runs the first segment at 1200ipm (because the G21 and F1200 are on the same line) and I don't get the error. The second time you run it - it is in metric units and runs the first segment at 1200mm/m and I do get the error.
[12:38:18] <rogge> Did some digging and looks like your tp.c is newer than ours, but the section that does vel calcs for trap profiles (from which the error comes) looks identical
[12:38:37] <rogge> ooohh - I'll try that.
[12:40:07] <skunkworks> (it would be better to put f1200 on the G1 line.. :) )
[12:40:18] <rogge> Sam - no dice - I'm in G21 as soon as I start up, because I shut down in g21 last time
[12:40:24] <rogge> Still not seeing it.
[12:40:35] <skunkworks> hmm - odd.
[12:40:59] <skunkworks> hold on. I wonder if it is your velocity cap - tormachs run at 120ipm max per axis?
[12:41:46] <rogge> I changed my sim config to 23 IPS based on your 600mm/s
[12:41:59] <skunkworks> oh. crap
[12:42:36] <rogge> behaves differently after I use a G64 command. Tryin to go back to g61 and it's still OK.
[12:42:54] <skunkworks> just do strait G64
[12:43:03] <skunkworks> (no p or q)
[12:44:40] <rogge> yeah - no issue after G64 (no p)
[12:46:17] <skunkworks> rogge, do you know if path pilot defaults to some P or Q? (difference from linuxcnc prime?)
[12:46:40] <rogge> That slowdown I reported over email was a red herring - it's just that there's a corrdinated Z move on that line that takes a while to complete.
[12:47:27] <rogge> So ignore that 'behaves differently' report - it pretty much just works for me
[12:48:19] <rogge> There is a default P for G64 in PP - I think it's .005 or .001. But there's no G64 in the code or in my startup code in the sim ini file.
[12:50:35] <skunkworks> can you turn it off? or is it hard coded. I wonder if that is why your not seeing it.
[12:52:24] <rogge> G61 turns G64 off, but then there's no blending, and no calcs to yeild the error.
[12:53:18] <skunkworks> right
[12:54:01] <rogge> I'll build 2.7 and try it under axis sim just to make sure I can see it at all...
[12:55:55] <rogge> Seb - did Rob ever talk to you about state tags?
[12:57:51] <cradek> rogge:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/bug424
[12:58:12] <cradek> rogge: you can pull branch bug424 to get my config changes etc
[13:03:01] <skunkworks> my trouble shooting is getting bad. Right now I can only get it to happen on the first run. not the second and subsiquent
[13:03:09] <skunkworks> I don't know what I changed
[13:03:31] <rogge> which config do I run?
[13:04:16] <rogge> Sam - the first run includes a Z move (out of plane blend). Subsequent ones do not. Can you move to that Z level immediately on startup, then run the code?
[13:05:02] <skunkworks> I tried that - but let me try it again..
[13:05:31] <rogge> cradek: nevermind - I see it's sim axis mm
[13:08:28] <rogge> Sam: I just tried my suggestion to you on cradek's test branch and it didn't change anything.
[13:08:39] <rogge> Only get the error the first time through
[13:08:42] <skunkworks> your seeing the error?
[13:09:40] <skunkworks> I will pull chris's branch so we are on the same page
[13:13:26] <cradek> I get different negative value on first vs subsequent runs
[13:14:21] <skunkworks> ok. then if my config isn't the same as yours - I might not get it on the second run.
[13:14:30] <skunkworks> seems odd they would be different though
[13:15:28] <rogge> Yes - I see the error on Chris' branch. If I G0X0Y0Z0 after running the code I can get it to happen every time.
[13:15:36] <cradek> http://i1.kym-cdn.com/photos/images/newsfeed/000/234/765/b7e.jpg
[13:16:21] <skunkworks> cradek, but you wrote a trajectory planner! ;)
[13:31:40] <rogge> shorter snippet of code that reproduces the problem is here:
http://codetidy.com/6723/
[13:32:35] <cradek> thanks, I pushed it to bug424 branch
[13:33:30] <cradek> interestingly, now I get the same error each run
[13:38:20] <cradek> http://timeguy.com/cradek-files/emc/bug424-accelviolation.png
[13:38:39] <cradek> I do also see the accel violation, for a couple servo cycles
[13:40:47] <cradek> image updated to show that it's the blend between lines 5 and 6
[13:49:57] <skunkworks> it is no worse than what I see with mach... ;)
[13:50:28] <cradek> heh, well we could just disable the error message then and call it good
[13:51:00] <skunkworks> actually it is much better - you said a couple servo cycles - Mach is 60+ servo cycles..
[14:15:12] <jthornton> Tom_itx, typo in the link, it's fixed but here is the correct url
http://linuxcnc.org/docs/2.7/html/getting-started/Updating_LinuxCNC.html
[14:15:52] <Tom_itx> jthornton, someone was just looking to update to 2.7 this am and i linked it to them but it failed. no biggie
[14:16:14] <jthornton> thanks for the report
[14:16:49] <jthornton> the file names are a mix match of humpy and file-name.txt and file_name.txt
[14:28:33] <Roguish> Tom_itx: hey I was on yesterday (different handle) asking about the -16 vs. -25 of the mesa 7i80. I spoke with PWC on the phone and he said the -16 will do whatever is need in regards to Linuxcnc.
[14:29:48] <Roguish> anyway, the -16 was the one. thanks for the help yesterday.
[14:31:24] <Tom_itx> i figured it would
[14:32:10] <Roguish> going to help a friend setup a 2 spindle wood router.
[14:33:08] <Tom_itx> i've got a 7i90 with a -16 and have had no configuration issues but i'm not using servos
[14:34:17] <PCW> the 7I90 is -9 (XC6SLX9) still big for a lot of things
[14:34:44] <Tom_itx> PCW, happen to ship mine yet?
[14:34:52] <Tom_itx> anxious to get it back up n runnin
[14:35:10] <PCW> 7I47S?
[14:35:14] <Tom_itx> yeah
[14:36:16] <PCW> Not yet I'm making critical kits now, will fulfill orders tomorrow
[14:36:33] <Tom_itx> np
[14:39:17] <Tom_itx> it probably wouldn't be worth replacing the chips on the other one
[14:40:09] <PCW> not if you value your time or are a very fast re-worker
[14:40:44] <PCW> unless you are a fast re-worker mean
[14:40:47] <Tom_itx> i usually do those things while sitting here chatting
[14:41:46] <Tom_itx> if you wanna send what you think may have gone out i'll gladly reimburse you for them
[14:41:53] <Tom_itx> if not, it's no biggie
[14:44:13] <PCW> the 422 receivers are probably OK (3.3V local reg) so probably just the ACT04 and the RS-422 drivers
[14:44:18] <Tom_itx> i haven't had a chance to look at it
[14:45:19] <Tom_itx> what about the 3.3v reg?
[14:45:32] <Tom_itx> or does it get power from something else
[14:45:40] <PCW> I had forgotten that there was a local 3.3V regulator for the RS-422 RX
[14:45:54] <PCW> so maybe only 3 chips killed
[14:46:07] <Tom_itx> you think the adc is ok?
[14:46:15] <Tom_itx> err analog switch
[14:46:40] <Tom_itx> it was on a separate 10v supply
[14:47:16] <PCW> Yeah its probably OK
[14:47:56] <PCW> (though the ACT04 the drives the OPTOs for PWM/DIR/ENA is probably toast)
[14:48:24] <Tom_itx> yeah i was getting no pwm
[14:52:22] <cmorley> mozmck: That looks very good. Are you using a custom GTK theme? I like the light buttons.
[14:53:17] <mozmck> cmorley: hi, and thanks! Yes, we customized the Blue-Joy theme
[14:53:54] <mozmck> I think I have the light buttons to a useable state now I wonder if they might could go in 2.7?
[14:54:01] <cmorley> yes i find it eye pleasing color. i also like the icon button from gremlin display
[14:54:51] <cmorley> Ii would think it's possible but ask Seb...
[14:55:00] <mozmck> oh, on the side? I have some hidden for our plasma setup, but there are more.
[14:55:40] <mozmck> This is based on Gscreen but I've modified it a bit in the handler file to do some things like we wanted.
[14:55:59] <cmorley> I had thought about LEDs with text in them - I bet your light buttons work similar
[14:56:26] <mozmck> Yes, basically. They are a new widget though.
[14:57:00] <cmorley> Yes i saw gscreen on the window title. - Your screen is an example of what i hoped Gscreen would be useful for.
[14:58:12] <cmorley> I have slowly been working on a new lathe screen that uses gobject signals more so that it uses cpu less but not sure when I'll finish it.
[14:59:00] <mozmck> That sounds interesting - what are the signals replacing?
[14:59:31] <cmorley> i found trying to figure out GTK themes difficult well frustrating
[14:59:45] <mozmck> I would like to remove the "Gscreen" and "for linuxcnc" from the title bar though, and just have the profile name - is there a way to do that?
[15:00:04] <cmorley> yes - hold on i'll find the command
[15:00:09] <mozmck> yes, one problem with themes is that there are many ways to do things.
[15:00:29] <mozmck> But I figured out quite a bit.
[15:01:21] <cmorley> self.widgets.window1.set_title("%s for linuxcnc"% title)
[15:01:39] <cmorley> add something like that to your handler file
[15:02:16] <cmorley> yes themes are not documented very well and there are alot of different ones
[15:04:14] <mozmck> Thanks
[15:04:14] <cmorley> the gobject work is alot about sending messages to the gui about modes rather then having the gui poll modes all the time.
[15:04:21] <cmorley> you bet
[15:04:51] <mozmck> The good thing is that there are a lot of themes :) Plenty to look at and figure out how to change things.
[15:05:16] <mozmck> I see.
[15:05:26] <cmorley> gscreen polls linuxcnc and stores it in data. ultimately I would like to not do that.
[15:05:54] <mozmck> Yes, have linuxcnc send events or signals makes sense.
[15:06:05] <cmorley> it works very well
[15:06:41] <mozmck> So are you adding gobject signal to linuxcnc, or is it all in the gui?
[15:07:56] <cmorley> I add the signals to hal_glib.py and use gladevcp's status to connect to them
[15:08:22] <mozmck> I see.
[15:08:55] <mozmck> The more I use gtk the less I like it :( python eases the pain some though
[15:09:03] <cmorley> for instance all the overrides are checked and a message is sent out if they change so the gui can update the screen
[15:09:54] <cmorley> GTK is all i know - i dabbled with QT in python it was good too just different
[15:11:37] <mozmck> I haven't used QT yet but I'd like to play with it. I really like C++ for UI work compared to C. I've used some wxWidgets and MSVC gui stuff.
[15:12:06] <mozmck> FLTK is what I use for most smaller projects.
[15:12:13] <cmorley> working with guis and compiling does sound fun
[15:12:20] <cmorley> does not
[15:13:06] <cmorley> fltk 'll have to look at that
[15:13:30] <mozmck> It's c++ too, but fairly basic, and really small and fast.
[15:13:36] <cmorley> easy to use but not as pretty?
[15:14:17] <mozmck> Probably not as pretty, but you can change the look and make it look pretty nice.
[15:15:05] <cmorley> I see.
[15:15:19] <cmorley> k i gotta go - nice job there!
[15:15:39] <mozmck> thanks! nice job on Gscreen!
[15:15:58] <cmorley> glad it's working for you - it was alot of work :)
[15:16:07] <mozmck> I can tell
[15:56:50] <skunksleep> zlog
[16:33:19] <JT-Shop> I like python but gtk is getting buggy
[16:47:21] <jthornton> just trying to use internal links as shown here
http://www.methods.co.nz/asciidoc/userguide.html#_section_ids
[16:48:06] <jthornton> If you have both an external link and a link in the same page they conflict and depending on where you put the anchor you might get one or the other to work
[17:47:47] <KGB-linuxcnc> 03Jeff Epler 052.7 6df518d 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: do iptables and sysctl configuration automatically * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6df518d
[17:47:47] <KGB-linuxcnc> 03Jeff Epler 052.7 75c8519 06linuxcnc 10debian/configure deb: depend on iptables for hm2_eth * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75c8519
[17:48:22] <seb_kuzminsky> yay!
[17:48:38] <jepler> yay
[18:43:15] <skunkworks> wow - cool
[18:57:07] <PCW> its great to automate the iptables part of the setup
[19:04:14] <jepler> hopefully I got it right :)
[19:28:36] <PCW> I guess I could delete my rules file and test it, is it merged into 2.7?
[20:37:05] <jepler> PCW: yes, it's merged into 2.7 now.
[20:43:57] <PCW> I guess my test system at work has been running hm2_eth for a while:
[20:43:59] <PCW> eth11 Link encap:Ethernet HWaddr d0:50:99:66:03:80
[20:44:01] <PCW> inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0
[20:44:02] <PCW> inet6 addr: fe80::d250:99ff:fe66:380/64 Scope:Link
[20:44:04] <PCW> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[20:44:06] <PCW> RX packets:19450696631 errors:0 dropped:0 overruns:0 frame:0
[20:44:07] <PCW> TX packets:38895736569 errors:0 dropped:0 overruns:0 carrier:0
[20:44:09] <PCW> collisions:0 txqueuelen:1000
[20:44:10] <PCW> RX bytes:2268330503024 (2.0 TiB) TX bytes:3900668857119 (3.5 TiB)
[20:44:12] <PCW> Interrupt:20 Memory:efd00000-efd20000
[20:45:20] <jepler> wow
[20:45:36] <jepler> ~75 days at 3kHz?
[20:45:56] <PCW> something like that
[20:47:10] <PCW> probably more at 4 KHz but i;m running through a switch now
