Back
[02:07:55] <ries_> ries_ is now known as ries
[03:31:56] <ries_> ries_ is now known as ries
[03:37:55] <ries_> ries_ is now known as ries
[04:08:38] <morfic-> morfic- is now known as morfic
[11:01:24] <mhaberler__> mhaberler__ is now known as mhaberler_
[11:06:38] <mhaberler__> mhaberler__ is now known as mhaberler_
[12:46:22] <CIA-41> EMC: 03jthornton 07master * r89a196034b4a 10/docs/src/ (7 files in 3 dirs): add gladevcp to manuals
[12:46:35] <CIA-41> EMC: 03jthornton 07master * r3060d99877cc 10/docs/src/gui/gladevcp.lyx: markup fix
[13:30:39] <psha> jthornton: is there any place on the web where docs are regulary updated from git?
[13:31:06] <Jymmm> huh?
[13:32:23] <SWPadnos> the docs directory on linuxcnc.org is automatically generated from git
[13:32:45] <psha> but for 2.4?
[13:32:47] <SWPadnos> the development one is at least, I'm not sure about the others
[13:33:08] <psha> ah, found
[13:35:06] <jepler> psha: a cron job runs on my personal system which builds the docs and rsync them to the website
[13:35:30] <jepler> right now this is done for the v2.4_branch and master once per hour
[13:39:24] <psha> nice, thanks
[13:39:54] <psha> i've noticed that JT added gladevcp docs and so was curious where to find them...
[13:40:29] <psha> he was faster then me and mhaberler :)
[13:46:44] <jepler> I'm not sure it's categorized right in the html index
[13:46:53] <jepler> seems like it should go next to the other vcps
[13:47:54] <jepler> (well, I guess the original "halvcp" is gone now)
[13:48:03] <jepler> the code example is busted
[13:49:44] <jepler> I have to confess that I think gtk widgets inside a tk app clash terribly
[13:50:29] <jepler> and anyway I would not include a pyvcp panel in the same screenshot when my goal is to illustrate gladevcp
[13:50:37] <jepler> * jepler is in a complaining mood this morning
[13:51:03] <jepler> bbl, time to go to work
[13:51:21] <jthornton> * jthornton smacks jepler with a mackerel
[13:51:40] <jepler> thanks, I needed that
[13:51:59] <SWPadnos> mmmmm. mackerel
[13:52:05] <jepler> what is the point of a hal table or hal hbox??
[13:52:06] <psha> jepler: next screenshot would be with touchy ;)
[13:52:07] <SWPadnos> now I want sushi
[13:52:14] <jthornton> it was a handy photo till I build one myself
[13:52:17] <psha> jepler: to disable widgets
[13:52:29] <jthornton> then I'll swap them out
[13:52:40] <psha> instead of adding 'disable' pin to each widget - add it to containers
[13:52:51] <jepler> psha: I see
[13:53:11] <jepler> I am only familiar with tk's way of enabling/disabling things, which is only per-widget
[13:53:29] <jthornton> psha:
http://www.linuxcnc.org/docview/devel
[13:53:38] <psha> jthornton: i've found it already, thanks :)
[13:53:48] <jthornton> ok
[13:54:07] <psha> btw there was per-widget doc on the wiki -- collecting info before going lyx
[13:54:16] <psha> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HalWidgets
[13:54:55] <jthornton> psha: the main thing I did this morning was to create the links and framework for the gladevcp lyx and html docs
[13:55:19] <SWPadnos> lyx/documentation question: if I have used apt to install emc2-dev and build deps for emc2 on 10.04, can I edit docs with whatever lyx I end up with?
[13:55:21] <jthornton> I saw that this morning but ran out of time
[13:55:30] <jthornton> SWPadnos: no
[13:55:34] <SWPadnos> ok.
[13:55:37] <jthornton> you have to use 8.04
[13:55:56] <jthornton> I put a virtualbox ose on this computer just for docs
[13:56:04] <jthornton> with 8.04 on it
[13:56:04] <SWPadnos> hmm. actually, the thing I wanted to fix is in a manpage anyway
[13:56:20] <SWPadnos> so nevermind for now :)
[13:56:20] <jthornton> manpage is text so should not be a problem
[13:56:31] <SWPadnos> inscrutable text, but still text
[13:56:37] <psha> jthornton: what versions are of lyx are working?
[13:56:54] <jthornton> only the one that is in 8.04
[13:57:18] <jthornton> Lyx 1.5.3
[13:57:47] <SWPadnos> psha, I think there are two issues. first is the scripts/programs used to generate PDF files from the lyx code. second is that later lyx screws up whitespace or something, making huge diffs between it and the earlier version
[13:58:19] <jthornton> and it makes jepler scream :)
[13:58:36] <SWPadnos> aheh
[13:58:38] <SWPadnos> -a
[13:58:59] <psha> hm, is it possible to include .tex parts? :)
[13:59:30] <jthornton> for man pages that are not automagiclly generated yes
[14:04:02] <jthornton> hi ho, hi ho it's off to the shop I go
[14:13:33] <JT-Shop> SWPadnos: the gs2 man page?
[14:14:07] <psha> debian squeeze has 1.6.7 so is suspect it won't work...
[14:14:45] <SWPadnos> JT-Shop, no, the hostmot2 page
[14:14:52] <JT-Shop> ok
[14:22:16] <skunkworks> I assume have to install glade for touchy to work?
[14:23:45] <cradek> don't think so
[14:24:16] <skunkworks> ok
[14:24:21] <cradek> might need some pythonish packages
[14:26:24] <psha> skunkworks: it's complaining about Glade?
[14:27:39] <skunkworks> http://pastebin.ca/2020344
[14:28:28] <skunkworks> is it because I don't have the home directory correct?
[14:28:39] <cradek> yes
[14:29:42] <skunkworks> that was it :)
[14:39:33] <skunkworks> psha: if I run the gladevcp config - the plot and velocity tabs are blank
[14:42:17] <psha> there are two extra packages needed - python-xlib and python-gtk-glext1
[14:51:27] <skunkworks> python-gtk-glext1? is that correct?
[14:52:10] <psha> sorry, gtkglext1, without dash
[14:52:25] <psha> python-gtkglext1
[14:52:37] <psha> it's mentioned somewhere in docs i hope ;)
[14:53:07] <skunkworks> I will look over the wiki
[14:53:40] <skunkworks> hey - look at that - neat :) nice work!
[14:58:59] <CIA-41> EMC: 03jepler 07master * r6f4626cf93a9 10/src/emc/rs274ngc/ (interp_read.cc rs274ngc_interp.hh rs274ngc_pre.cc): interp: create named_parameters for emc version info
[14:59:00] <CIA-41> EMC: 03jepler 07master * re526d8d7369c 10/debian/control.in: packages required by gladevcp and gremlin
[15:00:09] <skunkworks> nive!
[15:00:13] <skunkworks> nice!
[15:09:39] <psha> jepler: thanks :)
[16:00:26] <jepler> psha: np
[16:18:17] <psha> jepler: it seem that i've found solution for keyboard stealing
[16:19:17] <SWPadnos> lock your doors?
[16:21:40] <psha> heh, if the problem was in stealing my kbd i'd followed your advice... but kbd is stolen from Axis!
[16:31:08] <ries_> ries_ is now known as ries
[16:35:02] <psha> jepler: i think i'm able to pass at least 'esc' and mode switching keys to Axis
[16:38:26] <psha> with long presses (for jogging) there are some issues though...
[16:38:49] <SWPadnos> and what happens if someone has "focus follows mouse" turned on? :)
[16:39:02] <psha> tk and gtk handle them differently so forwarding gtk events to tk leads to bad things...
[16:39:32] <psha> SWPadnos: i'm gathering unhandled key-press events and forwarding them to Axis
[16:43:18] <psha> problem is that if focus is in gtk part tk don't handle keyboard events as i to do for child widgets
[18:51:03] <psha> ah, i've found problem with pg-up/pg-down
[18:51:18] <psha> gtk and tk use different scancodes...
[18:51:45] <psha> for unknown (for me) reason key press is handled correctly but key-release - not :)
[20:33:06] <psha> jepler: have a minute?
[20:36:45] <jepler> psha: what's on your mind?
[20:38:45] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?id=58eb77
[20:39:00] <psha> i think i've solved focus issues with gladevcp in axis
[20:39:23] <psha> not elegant but working for me
[20:39:35] <psha> i've tested with Esc, Ctrl-Home (home all) and other simple keys
[20:41:19] <psha> i've also tried recipe described in xembed specs (create invisible window) but have not succeded
[20:41:47] <psha> also i think this one is better since it's not changing axis at all - except one env var
[20:43:26] <jepler> the code doesn't thrill me
[20:43:39] <jepler> but it probably makes things better more than it creates a maintainance issue
[20:45:39] <psha> it's pretty harmles - first, it catches only key events got after all other widgets in vcp
[20:46:02] <jepler> shouldn't one of the paths return False instead of True? one indicates to gtk that the event is fully handled, right?
[20:46:03] <psha> as a side effect it spams Tk window with many releases - they ususaly are not handled
[20:46:58] <psha> yes, False stops processing, need to check
[20:50:24] <psha> gobject signal documentation don't mention any return values...
[20:51:34] <psha> only with explicit 'stop' method
[20:51:38] <psha> so my return values are useless
[20:52:32] <psha> keypresses consumed by child widgets are not handled by parent one
[20:56:57] <psha> heh, i'm not happy with this workarounds too... but i've not found another way to handle this :(
[20:57:10] <psha> bb in a minute
[21:09:26] <psha> jepler: i think theese 'hacks' have to be separated from gladevcp program and placed into module
[21:11:54] <jepler> do you want to work on it some more before putting it on master, then?
[21:12:37] <psha> i think yes
[21:12:40] <jepler> ok
[21:12:53] <psha> i've just was looking for some reivew
[21:13:05] <psha> s/was//
[21:59:08] <ries_> ries_ is now known as ries
[22:03:49] <ries_> ries_ is now known as ries
[22:17:00] <jepler> least enlightening git tutorial ever?
http://tartley.com/?p=1267
[22:23:37] <mhaberler> one needs to come from a certain 'space' to appreciate it
[22:25:38] <psha> heh, representing DAG's as topology groups is overkill :)
[22:26:43] <mhaberler> there - here's the guy from the 'appreciating space'
[22:27:28] <psha> and obviously not correct...
[22:27:31] <mhaberler> feel lonely out there, Pavel?
[22:28:06] <psha> feel a bit ill ;)
[22:45:59] <andypugh> I wonder how Mach3 copes with G3 commands which are impossible in euclidian space?
[22:51:47] <andypugh> I seem to recall that there is an interface direct to the motion controller from the CL or a script?
[22:52:11] <andypugh> Somebody mentioned using it for atoolchanger (I think) at the EMC2 fest?
[22:58:10] <andypugh> I think it was used to move axis positions from a bash script called with a custom M-code. Of course I might be hallucinating.
[22:58:12] <jepler> andypugh: no, there are only nasty hacks for joint motion during toolchange
[22:59:13] <andypugh> So toolchange mechanisms that require joint movements are a bit of a non-starter?
[23:01:27] <andypugh> The query is partly curiosity and partly because a chap on the forum has a machine that requires a check and possible adjustment of the head orientation (hydraulic, 2 state) before it is safe to go to the tool-change position.
[23:04:11] <JT-Shop> since it is a 2 position head can he do that in CL when he does a tool change?
[23:04:41] <andypugh> I don't know. Can CL move axes?
[23:05:20] <JT-Shop> if it is only 2 positions is it an axes?
[23:06:02] <andypugh> No, but once he has set the head position, he needs to raise the Z to the tool change position (as I understand it)
[23:06:32] <JT-Shop> ah, ok I missed that detail
[23:07:10] <andypugh> And he might also need to raise the head to an intermediate position to perform the tilt (I am not too clear on that either)
[23:07:11] <JT-Shop> he could write a comp based on my THC comp and he could do it
[23:08:28] <JT-Shop> I hijack the Z to maintain the voltage of my plasma then return it to what EMC thinks it should be at the end of the cut
[23:08:48] <JT-Shop> and lie about the actual position to EMC so it won't complaine
[23:09:34] <andypugh> Talking of that, Visteurs has made a kinematics where the THC offset is applied inside the motion controller, and that means that axis limits and following error problems seem to go away. I haven't looked at it or experimented, but it seems like a neat solution.
[23:10:20] <JT-Shop> I thought he still had a problem with it
[23:11:42] <andypugh> It's hard to tell, but I htink he got it working.
[23:12:53] <JT-Shop> ok, the last e-mail to me he still had a few small issues... so maybe he sorted them out
[23:13:44] <andypugh> Hmm, perhaps he shops around so as not to annoy anyone terminally?
[23:15:07] <ries_> ries_ is now known as ries
[23:16:15] <andypugh> Anyway, back to the point. Is it then true that the only way to move an axis in such a way that the motion controller knows where it is is with G-codes?
[23:16:39] <jepler> while in auto/mdi modes, yes.
[23:17:40] <andypugh> Can a toolchange comp or CL drop out of auto and back in again?
[23:18:25] <jepler> sure, but then you lose your place in the program
[23:18:31] <andypugh> I guess for many purposes switching from Auto to MDI would suffice as then G-code sequences could be triggered using the MDI_COMMAND pins?
[23:19:51] <ries_> ries_ is now known as ries
[23:20:29] <andypugh> The impression I am getting is that my hypothetical rack-type toolchanger might be a non-starter.
[23:21:13] <skunkworks> I think it is possible - you just have to disconnect the axis from the motion control and move it yourself through basic hal blocks.
[23:21:32] <skunkworks> I think others have done that.
[23:21:57] <skunkworks> I know it was discussed at the last fest at stuarts - some one showed someone it could be done..
[23:21:59] <skunkworks> ;)
[23:22:19] <jepler> in my view, the solution for kinds of toolchangers not currently accomodated by emc (mostly because they require joint motion interleaved with I/O) will involve modifying task and maybe the gcode interpreter. I am not particularly interested in imagining hacks or workarounds. but neither am I affected by this genre of problem, so I don't care to work on the problem within task either
[23:22:53] <andypugh> Yes, that was the thing I was trying to get a handle on, someone showed a way to move an axis using a bash script, I think. But it was on the IRC channel and I can't find it now
[23:25:47] <andypugh> But if it is possible I am getting the idea that it is a deprecated hack.
[23:29:31] <psha> jepler: i was not right about True/False return values for signal handlers
[23:29:33] <psha> http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#GtkWidget-key-press-event
[23:29:39] <psha> TRUE to stop other handlers from being invoked for the event. FALSE to propagate the event further.
[23:29:56] <psha> so my first feeling was correct, but second - not :)
[23:30:45] <skunkworks> Well - I envision unhooking pins from motion and hooking them into some accel blocks(limit1?) that get fed with the new postion(s) for each pocket
[23:32:16] <skunkworks> then it would return to the original postion - get re-hooked back to motion. (talking big picture)
[23:33:34] <andypugh> Probably very simple with the limit3 component, but I have this mental image of jepler wincing at the concept.
[23:34:09] <skunkworks> I do also ;)
[23:34:31] <skunkworks> well - if emc wasn't so flexable.....
[23:58:56] <skunkworks> hmm - but how do you de-accellerate?