Back
[00:02:11] <cmorley> to add rapid override properly - one needs to add code to emc_interface.py - I'm sure you will see this when you get there.
[07:09:17] <skunkworks> pcw_home, your .config worked. The latency is a lot better. very usable. just running the latecy-test with both threads I was getting 48us in servo thread. With just the servo thread I am getting <20k so far.
[07:09:55] <skunkworks> the only issue is the onboard wireless probably needs some help. (it wasn't seen but saw a bunch of references to firmware not found when building the kernel)
[07:10:58] <skunkworks> (but is working with a usb wireless dongle right nw.
[07:18:52] <skunkworks> zlog,
[07:24:55] <skunkworks> !later tjtr33 Let me know when you are on...
[07:24:55] <the_wench> will tell tjtr33 when he/she joins next
[07:51:02] <skunkworks> meant that on the other channel
[08:22:50] <pcw_home> skunkworks: the wireless issue may be something that needs to be set to allow proprietary blobs to be included
[09:04:01] <seb_kuzminsky> morning
[09:12:47] <pcw_home> morning
[09:52:14] <mozmck> cmorley: I found that and looks like I have rapid override added and working now.
[13:36:01] <skunkworks> pcw_home,
http://electronicsam.com/images/KandT/testing/7i80ASUS.png
[13:41:26] <skunkworks> 2.5ghz
[13:59:34] <PCW> Maybe similar to my Dell 6420 (2.5 GHz second gen I5)
[13:59:45] <skunkworks> this is a 3rd gen i5
[14:00:37] <PCW> I think mine is on the edge at 3 KHz (running videos etc)
[14:01:21] <PCW> but ran for about a day at 3 KHz and HD fireplace vids
[14:05:06] <skunkworks> This is 2k - i will let it run overnight
[14:05:36] <skunkworks> if I did the math right - that is about 100us read.
[14:06:27] <skunkworks> as with most - it gets more spikey moving the mouse.
[14:06:58] <PCW> Yeah
[14:09:07] <PCW> better stepgen tuning is possible:
[14:09:09] <PCW> http://ibin.co/1ub32KEWlfro
[14:13:22] <PCW> the ~2 uInch jitter at 40 IPS (2400 IPM) represents about 50 ns of sampling jitter
[14:15:56] <PCW> (thats one of those $39 HP DC7800s)
[14:47:35] <skunkworks> unreal
[15:06:29] <cradek> skunkworks: have you tried feature/state-tags-2.7-signed ?
[15:07:45] <cradek> I think the tagging is *great* but I'm nervous about the restore part
[15:08:29] <skunkworks> I don't know what that means...
[15:09:29] <cradek> you know how when running gcode the state display shows the readahead state, not the currently running state? rob made it display the running state
[15:09:51] <skunkworks> oh
[15:09:53] <cradek> AXIS hides this stuff when not in mdi, because historically it was not very useful
[15:10:29] <cradek> I guess "active gcodes" is what we call it
[15:10:39] <cradek> so that's part 1, and it's wonderful
[15:10:45] <skunkworks> ok - the memory is coming back.. He talked about showing current and next line.. in pathpilot or something like that
[15:10:57] <cradek> no this is about active gcodes
[15:11:06] <cradek> I don't know what the line stuff was
[15:11:25] <skunkworks> ah.
[15:11:42] <cradek> part 2 is when you abort it tries to restore the state of the interpreter to what it was back when the (then-running) code was executing
[15:12:10] <cradek> it does this by taking the old "active gcodes" and executing them (approximately) and that makes me nervous
[15:12:27] <cradek> guess I need to play with it
[15:12:34] <skunkworks> No I have not played with it.. :)
[15:12:42] <cradek> I am sure we want part 1
[15:13:25] <cradek> I need a couple weeks off work to work on linuxcnc :-/
[15:13:28] <cradek> that would be awesome
[15:13:50] <skunkworks> I thought you had problems using up your vacation.. :)
[15:15:26] <cradek> but if I took two weeks off and stayed home I'd be building something instead of working on linuxcnc
[15:15:33] <skunkworks> heh
[15:17:49] <cradek> MacGyver disassembles a sink and uses his belt to link the sink drain to a nearby electric outlet. The water flows through the electrical system of the building and shorts out the electric box.
[15:18:43] <cradek> MacGyver uses a TV tube, a battery, and jumper cables to overload the TV tube causing an explosion when it is triggered by opening the door
[15:18:50] <cradek> my this show must've been bad
[15:19:52] <andypugh> cradek: The first one is just about almost plausible if the building is wired with steel conduit.
[15:21:07] <andypugh> It feels like it should be possible to put the glade for an interface _and_ the svg that defines the widget icons in the same XML file.
[15:21:46] <andypugh> If you make such an XML file then Glade opens it OK, but removes the SVG content on save.
[15:22:20] <cradek> yuck
[15:23:49] <cradek> haha: [lots of reasons why it couldn't work] This makes MacGyver's feat all the more impressive.
[15:24:34] <cradek> andypugh: in touchy I used some icons from the system theme, but even that doesn't seem to work reliably. in some situations (?) it just shows the text.
[15:26:31] <andypugh> “Features” has a single SVG with all the icons in it, and pulls them out with a “makeicons” routine.
[15:26:59] <andypugh> It is actually possible to make rsvg render a single “id” from an SVG file, and that seems like a slightly neater way.
[15:27:38] <andypugh> But you stil need an SVG, a Glade file and a Python file for the handler. Which seems inelegant for a “plug-in” tab
[15:30:36] <andypugh> There is some nice GUI work here:
http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=170#56725
[15:38:17] <cradek> wow, so they are resizeable too
[15:38:29] <cradek> that looks really nice
[15:44:21] <andypugh> I am not sure I am interested enough in learning Inkscape to bother :-)
[15:46:19] <kwallace1> I like Inkscape and use it often.
[15:48:58] <andypugh> I use it a bit, and it’s great, but there is quite a learning-curve to make icons like those.
[15:53:34] <kwallace1> Yeah, I don't use masks and other features much and I need to look it up each time I need to use one, but it can do just about anything, and is easy to use for basic stuff.
[17:16:02] <seb_kuzminsky> awesome, Shivam, the GSoC student working on kernel packaging, just sent me his first bug report
[17:44:07] <mozmck> seb_kuzminsky: what are y'all doing on the kernel packaging?
[17:47:56] <PCW> argggh hm2_eth bug #@&
[17:50:00] <seb_kuzminsky> mozmck: taking the build system i made to build our wheezy/precise rtai kernel debs and updating it for newer versions, and maybe (extra credit!) newer versions of preempt-rt
[17:50:44] <mozmck> I see. I haven't had time to look at that yet, but I need to.
[18:03:02] <skunkworks> PCW, what?
[18:05:19] <PCW> looks a conditional read (reading the index enable state) got left out of the enqueuing logic
[18:06:31] <PCW> so if you set index enable true you get an extra read operation (so 5 packets instead of 3)
[18:07:22] <PCW> There was a similar bug with the watchdog early on
[18:12:59] <seb_kuzminsky> that's just during homing and threading/tapping, right?
[18:13:08] <PCW> yes
[18:14:33] <PCW> It probably works but ~doubling the transfer time is not good
[18:17:33] <PCW> I would not have noticed but was looking at the readtimes on halscope and noticed they were higher than expected
[18:17:35] <PCW> and then figured out that it was index enable being set that did it ( tcpdump shows the extra read request/read data )
