* qq- builded debian 2.6.32-i386-rtai
JT-Work_ is now known as JT-Work
SteveStallings is now known as steves_logging
jepler: any reason not to put this in AXIS? http://wiki.linuxcnc.org/uploads/axisrc-dynamic-tabs
have you tested it as well?
maybe F4 should be changed to cycle preview -> dro -> user tabs -> preview
commented out code, debug print, and unused 'colors' can be removed
but in general, I think it's OK for master
no, I haven't tried it
OK, I've got it cleaned up and improved a bit
(less tk.call, for instance)
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
JT-Work: the "v" key
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
my version of the axis user tabs is at http://git.unpythonic.net/emc2-jepler.git
that fetch is taking a LONG time...
hm, resize sure doesn't work
eek, I don't like how the embedded program can swipe the keyboard focus
is that not the case in touchy, or you just wouldn't have any way to notice it?
if I have the pointer over the tabs and poke F4 I get stuck there
yes, I noticed that too
couldn't find the pattern for awhile
xterm gets the focus because F1 does nothing and C-c exits watch
resize works in touchy - I'll test keyboard
in touchy the xterm does not get the kb focus
(not sure what, if anything, has it)
should the sim config have limits big enough to run all the sample programs?
without having to touch off and do fancy things?
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)
it's not a matter of size
like a real machine, sim/axis has Z=0 at the top of travel
like a real machine, it makes no sense to run gcode without proper offsets
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.
the former is an interesting argument too - I'm not saying it's wrong.
I know what your saying it could be either way
could the splash program move Z down then set the offset then go off and move the cone around?
yes but then I'm afraid it's a bad example of how to write gcode
think of the folks who like to cut it as their first test program
(in fact it would make it pretty unusable for that)
even putting instructions in the file don't help :/
yeah I noticed that :-)
7I43 on its way!
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 184.108.40.206 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
you have to monkey with udev to fix that
and - I did hear peter's voice on the phone - so he may be a real person after all. ;)
oh no.. I don't have much experience in that field
I thought it was a PAM issue..
our rtai debian package has this file installed in /etc/udev: http://emergent.unpy.net/files/sandbox/99-rtai.rules
skunkworks: He might still not be real, did he sound at all like Stephen Hawking? :-)
it makes the rtai shared memory device and rtai fifo device world-writable.
jepler is faster than me
andypugh: he sounded smart...
sweet it worked! time to update the package again..
NTU, from where you get 'latest RTAI from magma' ?
cvs: cvs -d:pserver:email@example.com:/cvs/rtai co magma
no problem :) latency is very low
8000ms on my 785 board
USER latency ?
servo thread (jitter) in latency-test
6000 on base thread
hopefully you meant ns, not ms ;)
right ns :)
8 seconds would be pretty bad for anything short of a bounce off the moon :)
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)
I think the best you can do is print to dmesg
if it's a realtime module anywa
if it's user, just use printf
This is just the config stage, so not "realtime" yet.
so I guess printf is probably correct (doh!)
maybe not: "error: implicit declaration of function ‘printf"
maybe something like printk?
[20:03:18] <psha> http://www.linuxchix.org/content/courses/kernel_hacking/lesson5
printf is from libc/glibc
rtapi_print(RTAPI_MSG_ERR, "whatever %d", 42);
but that uses the same buffer as HM2_ERR so it probably won't help you
I think HM2_ERR is #defined to be exactly that?
if it's in the initialization section of a realtime component and you're not in sim, you can call printk directly
but you can't call printk from a realtime function
Ah well, time to be more parsimonious with me telltales.
what's current state of gremlin?
psha: hasn't been touched in ages, probably bitrotted, never particularly useful
and before rotting, was it working or not?
afair it had a working preview plot, backplot, and mouse navigation (pan/zoom/rotate)
i've fixed some missing functions (is_lathe, get_show_offset) and it shows me coordinates and strange blue circles
and i'm wondering is that all or not :)
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
something like: emc axis.ini & sleep 3; python ../../src/emc/usr_intf/gremlin/gremlin.py
[20:21:14] <jepler> http://emergent.unpy.net/files/sandbox/0001-gremlin-fix-some-of-the-bit-rot.patch
that makes gremlin work as well as I remember it ever working
hm, even with this i only have bare axes with strange blue circles (sphere)
maybe inconsistent axis/gremlin versions...
one from 2.4.4 other from master
what is rs274ngc startup code?
it's sent to the interpreter when it starts
also "" by default :)
yeah that's the best one to use I bet
psha: huh, it works here. http://emergent.unpy.net/files/sandbox/axis+gremlin.png
both from master?
or 2.4 branch?
master. 376a676 + 3 commits to put user tabs in axis + 0001-gremlin-fix*.patch
gremlin's not in v2_4_branch at all, is it?
in your version of the axis user tabs patch, did xterm steal keyboard focus from axis if you pointed the mouse inside it?
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..
but that touchy doesn't
so I figure it could be my own changes, or a gtk vs tk difference..
touchy uses GtkSocket which is a bit more aware about XEMBED
i'll test with axis
click on user tab -> put pointer inside user tab -> press F1 to toggle estop
result: estop not toggled
F1 is eaten by my WM :)
pick any other keystroke normally handled by axis, then
yes, it's eating keyboard
OK, thanks for testing
do you care to look at my version of user tabs before I push it to master?
or maybe in master :)
as you wish )
[20:48:24] <jepler> http://git.unpythonic.net/emc2-jepler.git
I'm curious, what are you working on with gremlin? putting a preview in touchy, perhaps?
looking at :)
cradek was complaining about long delay when loading file in axis
with separate process for rendering preview it's not problem
for some reasons updating your remote branch is very slow...
interesting idea, but due to the keyboard problems in axis I think xembed is not going to be a great solution
hm, I may not have it set up properly :(
it took forever for me too, but eventually finished
jepler: mplayer is not eating focus
oh, yes, it's my fault.
maybe it's terminal 'bug'?
if embeded window is not interested in some keys then events a sent to master app
for example mplayer is not responding to any key presses
I gave you a http://
URL but I've never made the httpd changes to use the smart git-httpd-backend
you can try with a git:// url and it'll probably be faster
it will be a lot faster :)
I think just http://
-> git:// is right for my system, give it a try
the http would have been fast if only I'd properly configured my httpd
http without git-backend tries to traverse though packs
and it's very slow
yep, you're entirely correct
F4 cycling among tabs is nice
as for keyboard focus some testing is needed with typical apps like gladevcp
since it behaves so badly, it seems like the xterm example is a bad one to ship as in sim/axis.ini
I think I'll rebase that out, and push the rest to master
EMC: 03jepler 07master * r76a36c8e65f8 10/src/emc/usr_intf/gremlin/gremlin.py: gremlin: fix some of the bit rot
EMC: 03jepler 07master * r1e4c68581a67 10/src/emc/usr_intf/axis/scripts/axis.py: axis: make F4 cycle among all right-side tabs
EMC: 03jepler 07master * r4c0474e7ee4a 10/src/emc/usr_intf/axis/scripts/axis.py: axis: embed external programs in tabs
Gtk handles focus stealing
and is not passing keypresses to underlaying xterm
and now passing...
it seem to be related to WM
when I switch to another workspace and back xterm begin to steal focus
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
pretty strange solution :)
I'm glad one of us understands the xembed spec in detail.
I wonder if Marcelo ever had any success making Tk follow XEMBED. http://code.activestate.com/lists/tcl-core/8317/