Back
[01:05:28] <qq-> * qq- builded debian 2.6.32-i386-rtai
[02:20:49] <JT-Work_> JT-Work_ is now known as JT-Work
[13:57:21] <SteveStallings> SteveStallings is now known as steves_logging
[15:35:07] <cradek> jepler: any reason not to put this in AXIS?
http://wiki.linuxcnc.org/uploads/axisrc-dynamic-tabs
[15:37:49] <jepler> have you tested it as well?
[15:39:51] <jepler> maybe F4 should be changed to cycle preview -> dro -> user tabs -> preview
[15:40:08] <jepler> commented out code, debug print, and unused 'colors' can be removed
[15:40:22] <jepler> but in general, I think it's OK for master
[15:40:49] <cradek> no, I haven't tried it
[15:54:04] <jepler> OK, I've got it cleaned up and improved a bit
[15:54:12] <jepler> (less tk.call, for instance)
[15:54:26] <JT-Work> when your in lathe mode in Axis is there any way to zoom the window to center over the part path? like when you change views in regular Axis
[15:55:05] <jepler> JT-Work: the "v" key
[15:55:38] <JT-Work> thanks
[15:56:18] <JT-Work> I should have opened up the help window and looked there but for some reason didn't think it was there... that's what I get for thinking
[16:17:43] <jepler> my version of the axis user tabs is at
http://git.unpythonic.net/emc2-jepler.git axis-embed-tabs
[16:35:17] <cradek> that fetch is taking a LONG time...
[16:38:59] <cradek> hm, resize sure doesn't work
[16:39:37] <cradek> eek, I don't like how the embedded program can swipe the keyboard focus
[16:39:50] <jepler> is that not the case in touchy, or you just wouldn't have any way to notice it?
[16:39:53] <cradek> if I have the pointer over the tabs and poke F4 I get stuck there
[16:39:58] <jepler> yes, I noticed that too
[16:40:02] <jepler> couldn't find the pattern for awhile
[16:40:12] <cradek> xterm gets the focus because F1 does nothing and C-c exits watch
[16:40:16] <jepler> yeah
[16:40:25] <cradek> resize works in touchy - I'll test keyboard
[16:41:12] <cradek> in touchy the xterm does not get the kb focus
[16:41:25] <cradek> (not sure what, if anything, has it)
[17:53:31] <JT-Work> should the sim config have limits big enough to run all the sample programs?
[17:54:12] <JT-Work> without having to touch off and do fancy things?
[18:10:03] <andypugh> I would have thought so, but have noticed that is not so in al cases (some won't even run the EMC2 AXIS splash screen)
[18:19:43] <cradek> it's not a matter of size
[18:19:52] <cradek> like a real machine, sim/axis has Z=0 at the top of travel
[18:20:26] <cradek> like a real machine, it makes no sense to run gcode without proper offsets
[18:21:31] <cradek> so I guess it depends whether you think sim is a way to naively run programs and watch the cone move, or a tool to learn how to control a real machine. If the latter, I'd say it's set up correctly.
[18:21:59] <cradek> the former is an interesting argument too - I'm not saying it's wrong.
[18:22:23] <JT-Work> I know what your saying it could be either way
[18:23:25] <JT-Work> could the splash program move Z down then set the offset then go off and move the cone around?
[18:23:53] <cradek> yes but then I'm afraid it's a bad example of how to write gcode
[18:24:03] <cradek> think of the folks who like to cut it as their first test program
[18:24:17] <cradek> (in fact it would make it pretty unusable for that)
[18:25:46] <JT-Work> even putting instructions in the file don't help :/
[18:25:56] <cradek> yeah I noticed that :-)
[18:46:59] <skunkworks> 7I43 on its way!
[18:47:40] <skunkworks> * 7I48
[18:47:42] <skunkworks> heh
[18:53:21] <NTU> Hello. I am not sure if this is kernel related or not but when I try launching EMC or latency-test, I get Can't write to /dev/rtai_shm - aborting however, when running it as root, latency test and emc work fine. kernel is 2.6.35.7 patched with latest RTAI from magma on 4 core SMP system, emc 2.4.4, and in limits.conf I have set *hardmemlock20480 and *softmemlock20480
[18:53:50] <cradek> you have to monkey with udev to fix that
[18:54:07] <skunkworks> and - I did hear peter's voice on the phone - so he may be a real person after all. ;)
[18:54:21] <NTU> oh no.. I don't have much experience in that field
[18:54:37] <NTU> I thought it was a PAM issue..
[18:55:08] <jepler> our rtai debian package has this file installed in /etc/udev:
http://emergent.unpy.net/files/sandbox/99-rtai.rules
[18:55:27] <andypugh> skunkworks: He might still not be real, did he sound at all like Stephen Hawking? :-)
[18:55:29] <jepler> it makes the rtai shared memory device and rtai fifo device world-writable.
[18:55:32] <cradek> jepler is faster than me
[18:56:42] <NTU> thanks jepler
[18:56:56] <skunkworks> andypugh: he sounded smart...
[18:56:58] <skunkworks> :)
[18:59:10] <NTU> brb rebooting
[19:01:33] <NTU> sweet it worked! time to update the package again..
[19:25:27] <qq-> NTU, from where you get 'latest RTAI from magma' ?
[19:26:13] <NTU> cvs: cvs -d:pserver:anonymous@cvs.gna.org:/cvs/rtai co magma
[19:26:34] <qq-> NTU, thanks
[19:26:53] <NTU> no problem :) latency is very low
[19:32:03] <NTU> 8000ms on my 785 board
[19:35:14] <qq-> USER latency ?
[19:36:20] <NTU> servo thread (jitter) in latency-test
[19:37:06] <NTU> 6000 on base thread
[19:41:13] <SWPadnos> hopefully you meant ns, not ms ;)
[19:41:27] <NTU> right ns :)
[19:41:41] <SWPadnos> 8 seconds would be pretty bad for anything short of a bounce off the moon :)
[19:58:11] <andypugh> What's the neatest way to get output to stdio from inside a HAL module? HM2_ERR runs out of buffer, HM2_DBG is showing nothing (I assume I need to set the reporting level higher, somewhere)
[20:00:26] <cradek> I think the best you can do is print to dmesg
[20:00:36] <cradek> if it's a realtime module anywa
[20:00:43] <cradek> if it's user, just use printf
[20:00:55] <andypugh> This is just the config stage, so not "realtime" yet.
[20:01:19] <andypugh> so I guess printf is probably correct (doh!)
[20:02:36] <andypugh> maybe not: "error: implicit declaration of function ‘printf"
[20:03:16] <psha> maybe something like printk?
[20:03:18] <psha> http://www.linuxchix.org/content/courses/kernel_hacking/lesson5
[20:03:58] <psha> printf is from libc/glibc
[20:04:43] <jepler> rtapi_print(RTAPI_MSG_ERR, "whatever %d", 42);
[20:05:09] <jepler> but that uses the same buffer as HM2_ERR so it probably won't help you
[20:05:38] <andypugh> I think HM2_ERR is #defined to be exactly that?
[20:05:45] <jepler> if it's in the initialization section of a realtime component and you're not in sim, you can call printk directly
[20:05:57] <jepler> but you can't call printk from a realtime function
[20:07:44] <andypugh> Ah well, time to be more parsimonious with me telltales.
[20:10:59] <psha> what's current state of gremlin?
[20:11:14] <jepler> psha: hasn't been touched in ages, probably bitrotted, never particularly useful
[20:11:23] <psha> :)
[20:11:35] <psha> and before rotting, was it working or not?
[20:12:20] <jepler> afair it had a working preview plot, backplot, and mouse navigation (pan/zoom/rotate)
[20:13:25] <psha> i've fixed some missing functions (is_lathe, get_show_offset) and it shows me coordinates and strange blue circles
[20:13:46] <psha> and i'm wondering is that all or not :)
[20:20:02] <jepler> are you using it as your DISPLAY? I always have started it after starting axis, so it gets the axis splash screen in the preview
[20:20:22] <jepler> something like: emc axis.ini & sleep 3; python ../../src/emc/usr_intf/gremlin/gremlin.py
[20:20:32] <psha> i'll try
[20:21:14] <jepler> http://emergent.unpy.net/files/sandbox/0001-gremlin-fix-some-of-the-bit-rot.patch
[20:21:49] <jepler> that makes gremlin work as well as I remember it ever working
[20:24:23] <psha> hm, even with this i only have bare axes with strange blue circles (sphere)
[20:26:08] <psha> maybe inconsistent axis/gremlin versions...
[20:26:15] <psha> one from 2.4.4 other from master
[20:36:28] <psha> what is rs274ngc startup code?
[20:36:46] <cradek> it's sent to the interpreter when it starts
[20:36:59] <cradek> (pretty useless)
[20:37:38] <psha> also "" by default :)
[20:38:47] <cradek> yeah that's the best one to use I bet
[20:40:41] <jepler> psha: huh, it works here.
http://emergent.unpy.net/files/sandbox/axis+gremlin.png
[20:41:17] <psha> fine :)
[20:41:23] <psha> both from master?
[20:41:33] <psha> or 2.4 branch?
[20:41:53] <jepler> master. 376a676 + 3 commits to put user tabs in axis + 0001-gremlin-fix*.patch
[20:42:27] <jepler> gremlin's not in v2_4_branch at all, is it?
[20:42:33] <psha> dunno
[20:43:11] <jepler> in your version of the axis user tabs patch, did xterm steal keyboard focus from axis if you pointed the mouse inside it?
[20:43:51] <psha> it's there
[20:43:58] <jepler> I reworked it some (including putting a frame with -container 1, which is supposed to be the right thing to do) and chris says it has this keyboard problem..
[20:44:04] <jepler> but that touchy doesn't
[20:44:12] <jepler> so I figure it could be my own changes, or a gtk vs tk difference..
[20:44:24] <psha> touchy uses GtkSocket which is a bit more aware about XEMBED
[20:44:38] <psha> i'll test with axis
[20:44:56] <jepler> click on user tab -> put pointer inside user tab -> press F1 to toggle estop
[20:45:01] <jepler> result: estop not toggled
[20:45:45] <psha> F1 is eaten by my WM :)
[20:46:18] <jepler> pick any other keystroke normally handled by axis, then
[20:46:55] <psha> yes, it's eating keyboard
[20:47:07] <jepler> OK, thanks for testing
[20:47:58] <jepler> do you care to look at my version of user tabs before I push it to master?
[20:48:09] <psha> sure
[20:48:17] <psha> or maybe in master :)
[20:48:20] <psha> as you wish )
[20:48:24] <jepler> http://git.unpythonic.net/emc2-jepler.git branch axis-embed-tabs
[20:49:28] <jepler> I'm curious, what are you working on with gremlin? putting a preview in touchy, perhaps?
[20:49:41] <psha> looking at :)
[20:50:51] <psha> cradek was complaining about long delay when loading file in axis
[20:51:01] <psha> with separate process for rendering preview it's not problem
[20:53:21] <psha> for some reasons updating your remote branch is very slow...
[20:53:23] <jepler> interesting idea, but due to the keyboard problems in axis I think xembed is not going to be a great solution
[20:53:59] <jepler> hm, I may not have it set up properly :(
[20:54:27] <psha> probably
[20:55:03] <cradek> it took forever for me too, but eventually finished
[20:55:49] <psha> jepler: mplayer is not eating focus
[20:55:52] <jepler> oh, yes, it's my fault.
[20:56:00] <psha> maybe it's terminal 'bug'?
[20:56:20] <psha> if embeded window is not interested in some keys then events a sent to master app
[20:56:45] <psha> for example mplayer is not responding to any key presses
[20:56:53] <jepler> I gave you a
http:// URL but I've never made the httpd changes to use the smart git-httpd-backend
[20:57:10] <jepler> you can try with a git:// url and it'll probably be faster
[20:57:21] <psha> it will be a lot faster :)
[20:57:51] <jepler> I think just
http:// -> git:// is right for my system, give it a try
[20:57:54] <psha> done
[20:58:14] <jepler> the http would have been fast if only I'd properly configured my httpd
[20:58:15] <psha> http without git-backend tries to traverse though packs
[20:58:19] <psha> and it's very slow
[20:58:34] <jepler> yep, you're entirely correct
[20:59:59] <psha> F4 cycling among tabs is nice
[21:00:34] <psha> as for keyboard focus some testing is needed with typical apps like gladevcp
[21:04:00] <jepler> since it behaves so badly, it seems like the xterm example is a bad one to ship as in sim/axis.ini
[21:04:22] <jepler> I think I'll rebase that out, and push the rest to master
[21:07:44] <CIA-2> EMC: 03jepler 07master * r76a36c8e65f8 10/src/emc/usr_intf/gremlin/gremlin.py: gremlin: fix some of the bit rot
[21:07:53] <CIA-2> EMC: 03jepler 07master * r1e4c68581a67 10/src/emc/usr_intf/axis/scripts/axis.py: axis: make F4 cycle among all right-side tabs
[21:07:54] <CIA-2> EMC: 03jepler 07master * r4c0474e7ee4a 10/src/emc/usr_intf/axis/scripts/axis.py: axis: embed external programs in tabs
[21:09:39] <psha> Gtk handles focus stealing
[21:11:03] <psha> and is not passing keypresses to underlaying xterm
[21:11:35] <psha> and now passing...
[21:13:06] <psha> it seem to be related to WM
[21:13:31] <psha> when I switch to another workspace and back xterm begin to steal focus
[21:15:59] <jepler> yuck!
[21:19:06] <psha> In detail, the topmost embedder creates a not-visible X Window to hold the focus, the focus proxy. (It might be a 1x1 child window of toplevel located at -1,-1.) Since the focus proxy isn't an ancestor of the client window, the X focus can never move into the client window because of the mouse pointer location. In other words, whenever the outer window is activated (receives the X input focus), it has to put the X focus on the FocusProxy by calling XSetInputF
[21:19:12] <psha> pretty strange solution :)
[21:20:17] <jepler> I'm glad one of us understands the xembed spec in detail.
[21:21:38] <jepler> I wonder if Marcelo ever had any success making Tk follow XEMBED.
http://code.activestate.com/lists/tcl-core/8317/
[21:24:40] <jepler> bbl
