Back
[00:00:15] <skunkworks> seems like it gets harry at that point.
[00:00:34] <andypugh> I think that a limit3 on _position_ will "Just Work"
[00:00:43] <skunkworks> oh - cool
[00:00:47] <andypugh> Not tried it though
[00:10:43] <andypugh> I just tried it. Works as hoped.
[00:13:25] <skunkworks> there you go... Seems like a easy solution for rack tool changers.. or I could even use it for pallet changes within gcode. (without actully using gcode) :)
[00:21:30] <skunkworks> * skunkworks wait for jepler to wince
[00:58:29] <SWPadnos> skunkworks, you can even run the output of the motion controller through the limit3 if you like - limit3 has a "load" pin, which will pass the input straight to the output
[00:59:18] <SWPadnos> so then you use a bit to switch a mux - one input from the motion controller and the other from the tool changer, and the same bit goes to the limit3 load input
[00:59:39] <SWPadnos> (which may have other issues, but hey, it's your problem :) )
[01:00:16] <cradek> no sir, I don't like it.
[01:00:39] <SWPadnos> well, you also have to turn off feedback in some way, and it's icky no matter how you slice it
[01:00:57] <SWPadnos> (but is more or less exactly what I suggested for Scott in Wichita :) )
[01:05:48] <skunkworks> heh
[01:06:14] <skunkworks> why don't you like it? other than it is a kluge?
[01:07:03] <SWPadnos> it takes motion away from the motion controller, for one thing
[01:07:10] <skunkworks> well - yes
[01:07:25] <skunkworks> only when motion shouldn't be doing anything..
[01:08:17] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[01:09:34] <skunkworks> I guess if you don't go exactly back to the same position... (you proably never will...) your going to get an accumulative error after doing it for a while... maybe. switching back and forth between motion and hal.
[01:10:47] <skunkworks> or would you? because the encoder will have the exact position... you would be then hooking that back in to motion - you might get a bump as it tries to fix any error.
[01:11:20] <SWPadnos> well, using the mux approach, the command to the limit3 would be the position commanded by emc
[01:12:01] <SWPadnos> you would then need a wcomp or similar to only hand control back to emc once feedback says the joints are in position (within MIN_FERROR of the command)
[01:12:19] <SWPadnos> I wrote a simple comp to do all this for one axis (IIRC)
[01:12:50] <skunkworks> makes sense
[01:13:09] <SWPadnos> it takes tool-prepare as input, does all the feedback and pocket offset shenanigans, and asserts "tool-prepared" once everything is back where EMC thinks it should be
[01:13:27] <skunkworks> that is the big picture I was thinking.
[01:14:04] <SWPadnos> I can probably find the comp, but you would use it at your own risk ;)
[01:14:38] <skunkworks> that is ok - I don't need it for tool changing... (and unless I really want to do pallet changes in auto - I don't really need it at all)
[01:14:54] <SWPadnos> oh, right. this is pallet changing
[01:15:23] <SWPadnos> the concept is the same - input says to start, move around without emc knowing about it, assert output when done :)
[01:15:32] <skunkworks> and there are other ways to do that - like you mentioned - doing a subroutine.
[01:16:18] <skunkworks> 0<palletchange>
[01:16:28] <SWPadnos> yep
[01:16:37] <skunkworks> 0<palletchange.ngc>
[01:16:40] <skunkworks> right
[01:16:42] <SWPadnos> only use a capital o, not a zero :)
[01:16:48] <skunkworks> right!
[01:16:54] <skunkworks> ;)
[01:30:35] <skunkworks> mach list is self destructing again. Summary: someone has made a screenset that they want to sell like a subscription service. So you would have to be hooked to the internet. OMG you do not want to have a mach computer hooked to the internet! it is unstable! no it isn't! yes it is! maybe if the mach company goes under they will opensource it. (I am paraphrasing)
[01:31:52] <skunkworks> oh - and maybe there should be an ubuntu port of it.\
[02:36:14] <cradek> I kind of can't believe you take the time to follow it...
[02:53:15] <jepler> I bet he's in there all the time asking about how to configure his K&T
[02:53:38] <jepler> and turning down the advice to buy something expensive like a second parport and opto-isolated breakout board
[02:57:58] <SWPadnos> and wire
[04:00:27] <morfic> * morfic rubs eyes
[06:46:37] <LawrenceG> bing.... very quiet today!
[07:43:39] <CIA-41> EMC: 03cmorley 07v2.4_branch * r19a96247ce8c 10/src/emc/usr_intf/stepconf/stepconf.py: Fix stepconf to change spaces in configuration names to underscores
[07:43:40] <CIA-41> EMC: 03cmorley 07v2.4_branch * rbfd1bdc1f950 10/src/emc/usr_intf/pncconf/pncconf.py: fix failure to load config: nameless 'addf' command in HAL file
[07:43:41] <CIA-41> EMC: 03cmorley 07v2.4_branch * rc23470a9387f 10/src/emc/usr_intf/pncconf/pncconf.py: Have pncconf immediately change spaces to underscore in path text
[08:05:25] <psha> mhaberler: here?
[08:05:41] <mhaberler> yes,sir!
[08:06:10] <mhaberler> sorry for the email hosing-down
[08:06:57] <psha> np
[08:07:07] <psha> key releases are not obvious...
[08:07:24] <psha> for example some widgets consume key-press but not key-release
[08:07:38] <psha> so maybe better solution will be to get key-press and emit pair press/release
[08:08:36] <mhaberler> could be it, yes
[08:09:09] <mhaberler> generally, I think it would be better to forward too much than too few
[08:11:40] <mhaberler> and probably with connect(), not connect_after() so you can be sure you got it regardless what the default handler does
[08:15:19] <psha> point is not to forward local handled events
[08:15:26] <psha> consider text entry
[08:15:46] <psha> you type something and run/stop/change localview of the machine...
[08:16:30] <mhaberler> good question: what should happen with escape here? one way is a cmd line option to drive forward behaviour
[08:17:44] <mhaberler> options I see is: a) uncoditional forward, b) forward if not consumed by widget (any way to find out at runtime wether a widget does that?)
[08:18:34] <mhaberler> I think it would be best to give a user the option how she wants it - hard to tell now how this pans out
[08:19:13] <psha> don't think so...
[08:19:31] <psha> it's best to give user some seamless integrated solution :)
[08:19:45] <psha> and not some strange and hacky options ;)
[08:20:05] <mhaberler> for the Shramov definition of 'seamless', that is ;-)
[08:20:56] <mhaberler> 'seamless integrated solution' - anybody playing bullshit bingo in this room ?-)
[08:21:23] <psha> :)
[08:21:39] <mhaberler> either way, it's pretty close
[08:21:39] <psha> tk don't respect 'state' modifiers in X KeyPress events...
[08:22:02] <mhaberler> and this means-..?
[08:22:06] <psha> so sending press/release on key-press-event is not solution...
[08:22:38] <mhaberler> argh..
[08:24:25] <psha> but if it's possible to filter meta keys - then it's possible to forward them
[08:25:50] <mhaberler> bbl
[08:26:27] <psha> ok
[08:44:07] <psha> i think i've another version...
[08:45:01] <mhaberler> ok, will try it
[08:46:17] <psha> as you suggested i've moved release from last to first handleres
[08:46:47] <mhaberler> ok, and now it always gets it I guess
[08:46:57] <psha> merge
[08:47:11] <psha> i've tested with different keys
[08:47:28] <psha> and added emergency 'first' check for Escape :)
[08:47:30] <psha> for sure :)
[08:49:12] <psha> but maybe it's excessive...
[08:49:56] <mhaberler> better safe than broken machine
[08:50:29] <psha> heh, if we want to forward F1 we'll get it double-triggered :)
[08:51:05] <mhaberler> hm, maybe the double handlers are a bit overkill
[08:52:58] <mhaberler> cant try just yet, sill pulling vm images from my laptop
[08:53:47] <mhaberler> II'll try out all our code with an 8.04 machine lateron, py2.5 compat check
[08:59:15] <psha> btw i've no gladevcp in place of pyvcp
[09:01:03] <mhaberler> just add GLADEVCP?command line in DISPLAY section
[09:01:17] <mhaberler> GLADEVCP=gladevcp foo.ui
[09:01:19] <psha> it's started
[09:01:30] <psha> if i omit '-x{XID}' part
[09:01:35] <psha> i may see it...
[09:01:52] <mhaberler> aja, forhot the XID
[09:09:52] <psha> heh, incorrect fill parameters kill ion3 :)
[09:20:57] <psha> mhaberler: issue is that gtk is not able to force size of tk frame
[09:21:25] <mhaberler> ???
[09:21:44] <mhaberler> you mean on GLADEVCP right window
[09:21:50] <psha> yes
[09:21:54] <psha> at least for me
[09:23:19] <psha> neither in ion nor in xfce
[09:24:07] <psha> i think there is something bad in gtid parameters
[09:28:26] <psha> ah, found
[09:28:40] <psha> still width has to be given explicitly...
[09:29:09] <psha> or somehow derived from glade
[09:29:35] <mhaberler> can one read it from the ui file?
[09:30:11] <mhaberler> kinda kludgy, axis peeking into ui, but better than explicit size
[09:32:11] <psha> ah
[09:32:13] <psha> all right
[09:32:17] <psha> my fault
[09:32:21] <psha> it's displaying fine
[09:34:00] <mhaberler> so tk gets size right?
[09:36:39] <psha> yes
[09:36:46] <psha> there was issue in hal_meter
[09:38:01] <psha> still your sticky='nw' is not correct
[09:38:07] <psha> it has to be 'nsew'
[09:38:11] <mhaberler> duh..
[09:41:42] <psha> heh, but it's displayed _over_ error messages :)
[09:41:55] <mhaberler> hihi
[09:43:06] <psha> so it's not easy to click on X to close them...
[09:43:37] <mhaberler> esc handling looks ok
[09:46:32] <mhaberler> is it stacking order?
[09:47:04] <mhaberler> maybe axis needs to use the right window to display errrors in this case
[09:51:34] <psha> heh, what's 'right' window? :)
[09:51:56] <mhaberler> GLADEVCP
[09:53:37] <psha> :)))
[09:54:28] <psha> i've tried to move notification frame initialization later but without any effect
[09:54:59] <mhaberler> well, why does it work with PYVCP and not with GLADEVCP? strange.
[09:55:06] <psha> nothing strange
[09:55:12] <psha> pyvcp is native tk
[09:55:29] <psha> so tk knows about all widgets and undestand how to pack/overlay them
[09:55:42] <psha> gtk is foreign window displayed inside frame
[09:55:45] <mhaberler> I see
[10:04:01] <psha> i've played a bit with it but without any success...
[10:08:22] <mhaberler> you mean popup errors?
[10:10:16] <psha> yes
[10:11:49] <mhaberler> what happens - msgs dont appear? buried?
[10:14:52] <psha> appear under gladevcp window
[10:16:05] <mhaberler> how can that happen? I though there's a single window created by Tk which is just used by gladevcp; or does it maybe create a 1:1 overlapping window?
[10:17:41] <psha> notifications appears in child frame of main windowtoo
[10:17:42] <psha> too
[10:18:59] <mhaberler> well, I guess my question is: are gladevcp and the messages operate on the same or different X Window ID's?
[10:20:33] <mhaberler> taking a step back, I'm not very happy the way msgs are done in the firrst place, but I am unsure wether changing that is agreeable
[10:21:14] <psha> heh, if you want gladevcp in place of pyvcp changes to axis have to be minimal :)
[10:21:30] <psha> otherwise it will be definitly rejected :)
[10:21:34] <mhaberler> I see that
[10:25:41] <mhaberler> just push your status so I can take a peek
[10:27:27] <psha> second
[10:29:55] <psha> pushed
[10:32:47] <mhaberler> ok, see problem
[10:35:49] <mhaberler> hm, notifications work on root window
[10:36:10] <mhaberler> and that part is covered by gtk window, tight?
[10:36:15] <mhaberler> right?
[10:36:53] <psha> yes
[10:37:36] <psha> but this problem occures with pyvcp i think
[10:38:08] <mhaberler> no, dont think so, using this since long time and I havent seen that, would have noticed
[10:40:08] <psha> yes, i've checked and it's ok
[10:40:29] <psha> but for me it's also occurs when i create simple padding tk frame...
[10:41:29] <mhaberler> does this ring a bell? tried to hook Notifications(gladevcp_frame), get following error:
[10:41:31] <psha> oh, stupid me...
[10:41:31] <mhaberler> _tkinter.TclError: can't create window: its parent has -container = yes
[10:41:58] <psha> fixed it
[10:42:04] <mhaberler> ;-)
[10:50:21] <mhaberler> a looooong fix
[10:50:25] <mhaberler> curious!
[10:51:44] <psha> commiting (not nice though)
[10:51:53] <mhaberler> whatever
[10:52:59] <psha> also i've changed format of GLADEVCP var
[10:53:30] <psha> simple case is just 'file.ui'
[10:53:37] <psha> no {XID}, -x, gladevcp etc
[10:53:45] <psha> but you may place any flags you want
[10:53:51] <mhaberler> fair enough
[10:54:10] <psha> also it's compname is explicitly set to 'gladevcp'
[10:54:42] <psha> so user don't need to guess what's comp name
[10:55:28] <mhaberler> good
[10:55:30] <mhaberler> how does fix work?
[10:56:34] <psha> it moves frame initialization before notifications
[10:56:42] <mhaberler> YES
[10:56:48] <mhaberler> super!
[10:57:00] <psha> i need some consulting with Jeff though...
[10:57:08] <mhaberler> and key handling ok too!
[10:57:39] <mhaberler> sure. This isnt a simple fix
[10:57:41] <mhaberler> great job! I can start replacing my pyvcp panel!
[10:57:55] <psha> i think something like POSTGUI_HALFILE is also needed
[10:58:17] <psha> but for gvcp
[10:58:43] <mhaberler> maybe initialisation sequence can be shuffled such that a POSTGUIHALFILE can cover both gladevcp and pyvcp, that would be least confusing
[11:00:12] <mhaberler> we might look into shutdown sequence for gladevcp, in particular Keyboard Interrupt handler
[11:00:13] <mhaberler> I get this during exit:
[11:00:15] <mhaberler> /home/mah/emc2-dev/bin/gladevcp:320: GtkWarning: GdkWindow 0x4a00003 unexpectedly destroyed
[11:00:15] <psha> i fear it may a) break setups with postgui but without pyvcp b) make it impossible to use both pyvcp and gladevcp (for transition)
[11:00:17] <mhaberler> gtk.main()
[11:00:18] <mhaberler> The program 'gladevcp' received an X Window System error.
[11:00:19] <mhaberler> This probably reflects a bug in the program.
[11:00:21] <mhaberler> The error was 'BadWindow (invalid Window parameter)'.
[11:00:31] <mhaberler> better play safe
[11:01:14] <mhaberler> maybe no on_destroy handler in program
[11:01:37] <psha> there is no on_destroy signal in program :)
[11:02:04] <psha> parent frame is simply destroyed without any notification
[11:02:34] <mhaberler> uh, that's a bit harsh
[11:02:35] <mhaberler> how we get it to save state then?
[11:03:29] <psha> i think there is still destroy signal but only after this message
[11:03:39] <mhaberler> checking...
[11:04:38] <psha> yes, it's handled
[11:05:40] <psha> but when window is killed already
[11:05:49] <psha> Gtk handles this more graceful
[11:06:17] <mhaberler> the program seems dead before on_destroy can be called
[11:08:10] <mhaberler> if emc is killed from console window by ^C, dead in the water - need except KeyboardInterrupt: somewhere
[11:09:18] <mhaberler> one way would be to have except Keb... in gladevcp and del the handlerobjects explicitely, so they can clean uo in __del__
[11:10:04] <mhaberler> adn release HAL component by halcomp.exit() too
[11:10:52] <psha> you may do what you want in destroy handler
[11:11:03] <psha> when window is killed you get -INT signal
[11:11:37] <psha> so either block it while you are saving or do something similar
[11:11:55] <mhaberler> well, who - the Keyboardinteerupt exception handler must be in gladevcp main
[11:12:23] <mhaberler> I dont reach on-destroy currently!
[11:14:14] <psha> i think something like window.destroy has to be added in gladevcp
[11:14:24] <mhaberler> uh, KB int handler is in place
[11:14:46] <mhaberler> what about the __del__ method?
[11:15:07] <mhaberler> run through list of handler objects and del(obj)
[11:15:13] <psha> __del__ is bad
[11:15:26] <psha> del(obj) won't delete object if there are references to it
[11:15:44] <mhaberler> add 'shutdown'?
[11:16:08] <psha> try adding gtk.main_quit() in KeyboardInterrupt handler in gladevcp
[11:17:26] <psha> not solution...
[11:17:35] <psha> i'll be back in the evening
[11:17:54] <mhaberler> yes, just noticed
[11:17:56] <mhaberler> sure.
[11:17:57] <mhaberler> we need to look at exceptions for X window system errors as well
[13:03:22] <jepler> as for POSTGUI_HALFILE I would like to avoid proliferating them. It's bad enough that the existing UIs that have HAL components must be started in the way they are and require a POSTGUI_HALFILE for the ones that create hal items .. but to have one for each gladevcp tab in addition, that's much worse
[13:05:04] <jepler> first I'd concentrate on getting touchy into a happy state of affairs. there, it seems like there's some hope of running the main program and the gladevcps as a single process, and then just running the POSTGUI_HALFILE at the right moment
[13:05:29] <jepler> alternately, instead of using Popen to run them asynchronously, use os.system(
[13:05:34] <jepler> "halcmd loadusr -W...")
[13:05:51] <mhaberler> I'd be happy to get rid of the -H <halfile> flag and move that to a single post-setup halfile
[13:05:53] <mhaberler> the issue was that POSTGUI_HALFILE was run too early to be useful for gladevcp
[13:06:01] <jepler> so that the GUI can at least know when they initialize as a HAL component
[13:06:36] <jepler> since they're fully asynch now there's no place late enough! If it was just a matter of moving the likne that runs the POSTGUI_HALFILE I'd ask you why you hadn't done it yet...
[13:07:39] <psha[work]> it was not moved since gladevcp was changing fast so to minimize noise in axis everything was done on gladevcp's side
[13:08:23] <psha[work]> now when keyboard issues are solved it may be reasonable to move posgui later
[13:08:45] <jepler> but moving it physically after the line '_dynamic_tabs(inifile)' isn't enough, that's what I'm saying
[13:09:03] <psha[work]> yes, that's second reason why it has not moved yet :)
[13:09:40] <psha[work]> with loadusr there is another issue
[13:09:45] <jepler> tell me what it is.
[13:10:10] <psha[work]> if you want to add non-HAL part - how to determine that don't need to wait for it?
[13:10:23] <psha[work]> or require that all tabs have to be components
[13:11:17] <skunkworks> cradek: jepler: I think it is my reality tv show.
[13:11:18] <jepler> option 1. run tab commands all synchronously with os.system. force user to write 'halcmd loadusr -W...' or 'non-hal-command &' in inifile
[13:11:37] <jepler> option 2. I don't know what option 2 is
[13:11:46] <jepler> I thought I had one in mind, but it's gone now
[13:11:48] <psha[work]> option 2. wait for commands started with halcmd?
[13:12:00] <psha[work]> and don't wait for others?
[13:12:47] <jepler> option 86. if there are too many things wrong with embedding gladevcp in axis, drop the feature before it is put in a stable release
[13:13:05] <psha[work]> sad but true :)
[13:13:29] <psha[work]> besides gladevcp there are utils like camview - they behave just like gladevcp panels
[13:13:43] <psha[work]> with same issues and shortcomings
[13:14:43] <psha[work]> another way is to create extra config section with lot of vars describing how it has to be loaded - but i don't think that's right way to go
[13:15:50] <jepler> for me the shell command describes perfectly how the program is loaded
[13:16:16] <jepler> and I hate our users so much I think they should learn unix before using the software
[13:17:43] <psha[work]> :)
[13:18:49] <psha[work]> so i see two ways: mimic shell with '&' at the end for background processes or try to guess 'halcmd loadusr' in the begining
[13:19:11] <psha[work]> if it's halcmd - wait for it, otherwise - fork
[13:19:32] <jepler> oh, ugh. I was conveniently ignoring the need to make the non-hal processes exit :(
[13:20:49] <psha[work]> heh, i've added this feature for non-HAL camera util :) gladevcp comes later :)
[13:22:04] <psha[work]> & is ok for me too - needs some alarm window for users who forget to add it :)
[13:24:29] <psha[work]> btw good morning :)
[13:33:49] <jepler> hi
[13:33:58] <jepler> off to the office for me. the streets are icy here today.
[13:35:34] <Jymmm> jepler: Dont forget your emc2 controlled road de-icer
[13:42:59] <dimas__> :)
[14:36:38] <skunkworks> logger_dev: bookmark
[14:36:38] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-12-16.txt
[14:46:01] <skunkworks> and I don't troll on there. I just read and snicker. STOP JUDGING ME! ;)
[15:08:34] <alex_joni> skunkworks: haha
[15:08:55] <skunkworks> Hi alex!
[15:22:40] <alex_joni> hi
[15:40:09] <ries_> ries_ is now known as ries
[16:33:11] <jepler> anyone know what I need to do in my buildslave configuration?
[16:33:17] <jepler> .. with the change to buildbot.linuxcnc.org, that is
[16:44:27] <psha> jepler: what is target python version for emc scripts? 2.5?
[16:45:08] <jepler> psha: yes. we still wish to build master on ubuntu 8.04 which has python 2.5.2.
[16:45:32] <psha> ok
[16:45:42] <psha> i'm asking since 2.4 has no try/except/finaly
[16:45:47] <psha> but 2.5 alread has
[16:59:03] <mhaberler> jthornton: thansk for starting the gladevcp manual!
[17:00:12] <psha> jepler: is it safe to call halcomp.exit() before halcomp.ready()?
[17:00:14] <psha> or not needed?
[17:03:39] <jepler> you mean in the case that initialization of the component failed? If so, you can .exit() or just let the process exit. Either will make halcmd loadusr -W show something like '<program> exited without becoming ready'
[17:04:14] <jepler> if you .ready() and then .exit() immediately, it's indeterminate whether halrun will think the component initialized or not, because it is polling the shared memory area to find out
[17:06:18] <psha> no, i was talking about exit without ready
[17:06:37] <psha> if it's harmless i'd better delay 'ready' till late stages of initialization
[17:07:23] <jepler> for instance in the case of a hardware driver you shouldn't call .ready() until you've determined that the hardware is present and working..
[17:07:24] <psha> this will add some delays but ensures that no broken parts of components lay around
[17:07:39] <psha> i see
[17:07:41] <psha> thanks
[17:30:38] <JT-Shop> mhaberler: np, I'll try and get the rest added from the wiki this weekend
[17:46:07] <mhaberler> oh really! I was about to embark on lyx learning curve.. thats a great headstart!
[17:47:20] <JT-Shop> just to edit any lyx docs you have to use 8.04's version of lyx
[17:48:02] <JT-Shop> to add a lyx file you have to modify several other files to make sure it shows up properly in the HTML docs
[17:49:03] <mhaberler> yes, I figured that already. will get me a 8.04 VM for doing that
[17:50:48] <JT-Shop> I set up a VirtualBox OSE for that in my 10.04 computer and it works nice
[17:51:04] <psha> heh, why not to create 8.04 chroot?
[17:51:06] <psha> it's much easier
[17:51:21] <JT-Shop> easy only if you know how :)
[17:55:29] <mhaberler> psha: good idea..
[17:55:35] <mhaberler> less booting
[17:57:08] <psha> JT-Shop: debootstrap is easy to use :) if you don't scared by command line :)
[18:00:53] <mhaberler> psha: what about posting a command line how to install a 8.04 chroot tree on a 10.04? I'd switch, less pain
[18:03:24] <psha> i think something like 'debootstrap hardy /chroot/path
http://mirror.yandex.ru/ubuntu'
[18:03:30] <psha> replace mirror URL with closes one to you
[18:03:53] <psha> this will create base system, then 'chroot /chroot/path; apt-get install lyx'
[18:04:03] <mhaberler> cool
[18:04:08] <JT-Shop> so can you have both 8.04 and 10.04 running at the same time on the same monitor?
[18:04:50] <psha> JT-Shop: not exactly
[18:05:04] <psha> you'll have 10.04 running with some applications from 8.04
[18:05:15] <mhaberler> the way I understand it: desktop environment stays at 10.04 but when you changeroot into the 8.04 the binaries there are all 8.04
[18:05:22] <psha> yes
[18:05:33] <JT-Shop> it's more convenient for me to have 8.04 in a window
[18:08:28] <psha> heh, if you have Intel-VT or AMD-V - that's better solution :)
[18:08:37] <psha> without hw virtualization support it will be slow...
[18:27:55] <JT-Shop> plenty fast for LyX that is for sure
[18:49:45] <psha> heh, when waiting for child processes there is chicken and egg problem...
[18:52:27] <JT-Shop> I don't have any problems with chickens or eggs I like both :)
[19:01:41] <skunkworks> I run xp in a virtual machine on my laptop.. I think it is the fasted install I have :)
[19:03:17] <skunkworks> (on lucid)
[19:17:19] <psha> skunkworks: try to run virtual machine on older processor without vt extensions :)
[19:23:39] <skunkworks> heh
[19:49:23] <psha> jepler: heh, i've got working postgui_halfile i think...
[19:49:36] <jepler> by magic?
[19:49:42] <psha> but i fear that you'd like that one even less then forwarding keyboard :(
[19:49:43] <psha> yes :(
[19:50:11] <psha> if i wait on child process (p.wait, os.system, time.sleep, ...) UI is blocked and not handling any X events
[19:50:40] <psha> but if i use root_window.after (rescheduling) everything is ok
[19:50:56] <psha> besides fact that postgui_halfile will be loaded in undetermined time
[19:51:09] <jepler> if this is only at startup, I think having a nonresponsive window might be the lesser of evils
[19:51:20] <jepler> heck, we could leave the whole window withdrawn until postgui_halfile is done
[19:51:51] <SWPadnos> <HACK>you could add a HAL pin that the HAL file can twiddle at the end</HACK>
[19:52:25] <psha> nonresponsive window = nobody can embed in it
[19:52:29] <SWPadnos> oops, wrong keyword. should have been UGLYHACK
[19:53:05] <psha> SWPadnos: heh, compared to keyboard forward and other xembed stuff it's not HACK even but hack
[19:53:13] <SWPadnos> heh
[19:53:23] <jepler> psha: oh, there's some kind of X request that the embedder has to satisfy before the embedding is completed?
[19:53:43] <psha> yes, otherwise BadWindow X error is raised...
[19:53:59] <psha> and child either die in pain or just live in separate window...
[19:54:54] <psha> with async posgui_halfile loading i thin some block may be held on interface to signal that it's not yet ready
[19:55:05] <jepler> if you withdraw the root window before doing this, and deiconify it after, does the embedding succeed?
[19:55:15] <jepler> handling events as you do at the moment
[19:55:32] <psha> i think it's possible... need to consult docs about withdraw
[19:56:28] <psha> i see problem in unresponsiveness of tk... with gtk it's possible to run parts of main loop but in tk you eithr run it forever or get nothing
[20:02:01] <jepler> tk has a distinction between "update" and "update idletasks", but that's about it.
[20:02:47] <jepler> there's really no way to say "keep repainting the UI but don't let the user perform any interactions"
[20:03:00] <psha_> i think i've lost something
[20:03:05] <jepler> tk has a distinction between "update" and "update idletasks", but that's about it.
[20:03:11] <jepler> ^^ that's the only other thing I said in the meantime
[20:03:11] <psha_> psha_ is now known as psha
[20:03:58] <psha> thing like gtk's 'set_sensitive(False)' would be better but iconfiy also does it job
[20:06:38] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?id=9effc7
[20:13:13] <psha> it's not working for ion and other tiling wm's but i think it's serious issue compared to maintainance burden...
[20:15:05] <jepler> one small note: the strip is not needed here: + cmd = map(str.strip, cmd.split())
[20:17:02] <psha> ok, and and there was one debug print left
[20:17:11] <jepler> I think I'd also make the polling time smaller than 500 -- that's a half second
[20:17:15] <psha> that's bad habbit already - always run 'strip' :)
[20:18:40] <jepler> somewhere there's a line that dismisses the splash screen
[20:18:58] <jepler> maybe move that line until after root_window.deiconify()
[20:19:38] <psha> amended patch
http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis-forward2&id=06730f7d0eb358cbeff8b966bb3759dd890ba518
[20:19:49] <psha> i'll look at splash after cup of tea :)
[20:20:06] <jepler> and how do you drink your tea over there?
[20:28:36] <alex_joni> jepler: frozen solid
[20:39:38] <SWPadnos> that's t-t-t-t-t-t-tea
[20:42:52] <JT-Shop> teasickle
[20:45:19] <psha> frozen... my friend was in Tomks several years ago and there was national disaster: in the evening before 'old new year' when ~50% of people hang alcoghol out of windows (it's common practice too keep it cold) temperature goes really low and most of bottles freeze and break... he said that there were battles at alco shops for left supplies :)
[20:45:27] <psha> s/Tomks/Tomsk/
[20:45:55] <psha> jepler: flash is drawn by emc script out-of-the process
[20:45:58] <psha> with popimage program
[20:46:54] <jepler> psha: that's right
[20:46:55] <jepler> 3087 try:
[20:46:55] <jepler> 3088 root_window.tk.call("send", "-async", "popimage", "destroy .")
[20:46:55] <jepler> 3089 except Tkinter.TclError:
[20:46:55] <jepler> 3090 pass
[20:47:00] <jepler> there's where axis gets rid of it ^^^
[20:47:08] <psha> ah, thanks
[20:47:21] <jepler> I forget, however, that "send" is broken in ubuntu 10.04's tk
[20:47:39] <jepler> so that code is probably not benefitting our users at the moment :(
[20:48:09] <psha> on debian too
[20:50:26] <jepler> working or not at the moment, that's the code that I think should be moved to where axis is actually deiconified
[20:50:51] <jepler> I write for/else so seldom that I was initially confused about the logic in check_dynamic_tabs
[20:53:44] <psha> after i've used it several times i feel that it's pretty useful...
[20:54:55] <jepler> I agree, I don't have a quarrel with its use.
[20:56:48] <psha> tk.send('popimage', 'destroy', '.')
[20:56:55] <psha> this one kills window i think
[20:57:00] <psha> tk == root_window
[21:02:58] <psha> hm, previos version is working too...
[21:03:12] <mshaver> andypugh: Check your e-mail! Plots enclosed + latest status.
[21:03:15] <psha> it's not working only when running inside Xephyr
[21:05:30] <jepler> on ubuntu 10.04 systems it's because 3 non-xauth SI:* type clients are allowed
[21:05:40] <jepler> tk8.5 has a special case for SI: but it's not quite special enough
[21:07:06] <psha> ah, in xephyr it's also caused by xauth
[21:07:08] <jepler> the problems surrounding SI: have been known since at least 2007
https://bugzilla.redhat.com/show_bug.cgi?id=349071
[21:07:20] <psha> i'm running it with '-ac' to be able to inject child processes there
[21:09:43] <psha> i suspect send won't be fixed...
[21:10:30] <jepler> I think they incorporated a second SI:-related fix .. at least they marked my patch in their tracker as "fixed".
http://sourceforge.net/tracker/?func=detail&aid=2917663&group_id=12997&atid=312997
[21:11:45] <andypugh> mshaver: Does index-enable change state?
[21:12:36] <jepler> here's the patch actually included in tk8.5.9:
http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/unix/tkUnixSend.c?r1=1.20.2.1&r2=1.20.2.2&view=patch
[21:13:37] <psha> great :)
[21:13:58] <jepler> I don't think I got around to testing whether it actually fixed the problem, and it won't fix -ac
[21:14:30] <psha> patch for -ac will be definitely rejected :)
[21:14:35] <psha> since it breaks security
[21:14:52] <jepler> I somewhat think that tk should drop the policy from send and allow applications a way to set the policy
[21:16:01] <jepler> xhost +i.accept.the.risk
[21:19:14] <mshaver> andypugh: let me check...
[21:19:43] <andypugh> Might be interesting to watch the in_type parameter too.
[21:19:53] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-axis-forward2&id=2ce59e
[21:20:04] <mshaver> looking to see what that is...
[21:22:13] <mshaver> in-type is 1, out-type is 0. what do these mean?
[21:22:41] <andypugh> They are the state-machines that keep track of what the component is trying to do.
[21:23:58] <andypugh> in-type of 1 means that is is only _trying_ to do trapezoidal commutation, it seems to not be picking up on the index.
[21:24:50] <andypugh> "ih" should be 0xD (or 13 if you have ten fingers)
[21:25:14] <mshaver> give me a few minutes to add this stuff to my "control panel"...
[21:26:10] <andypugh> case 0x09:
[21:26:10] <andypugh> rtapi_print_msg(RTAPI_MSG_ERR, "The use of an encoder Index with "
[21:26:11] <andypugh> "Hall sensors is not supported. Defaulting to "
[21:26:11] <andypugh> "trapezoidal commutation\n");
[21:26:55] <andypugh> logic failure on my part.
[21:27:15] <andypugh> You should find that "qih" works.
[21:28:20] <andypugh> "ih" suggests you have only hall sensors and an index, and that is no good. "hqi" suggests that you have an encoder and an index, and want to use the index.
[21:29:22] <andypugh> Hmm, exactly what the documentation says in fact.
[21:35:19] <andypugh> <accuses mshaver of not reading his dmesg output>
[21:35:27] <mshaver> ah! just got back and saw what you wrote! trying that...
[21:36:04] <mshaver> I should have a terminal open with 'tail -f /var/log/messages' running constantly :)
[21:36:06] <andypugh> ONly any good if you know the number of encoder counts between motor zero and the index too, you realise?
[21:38:08] <mshaver> I don't fully understand what the index does - do I need to know the offset? or does it measure it? I mean, home to the hall sensor edge, then seek the index.
[21:41:01] <andypugh> No, it ignores the hall signal edges and runs in trapezoidal mode until it sees an index, then uses the offset from the encoder-offset parameter. You need to have found motor zero and then determined the encoder counts between there and the index. It is the absolute most accurate way to do it, but the most work too.
[21:42:10] <andypugh> If you are setting up motors you can make is easier by attaching the encoders accurately aligned (the motors I have are all set up that way)
[21:43:03] <andypugh> Actually, now I think, they aren't. its 330 counts for the last one.
[21:43:23] <mshaver> If we have hall sensors, can't we count on them being aligned perfectly?
[21:43:51] <mshaver> I guess my issue is that I want to be able to orient the spindle (someday).
[21:44:26] <andypugh> The trick is possibly to home it magnetically (in "n" mode) with no attached load, then manually set index-enable, slowly turn it till the encoder resets, then turn it back to see what the encoder count it.
[21:45:03] <andypugh> Hall sensors are only approximate, they don't have especially well-defined edges.
[21:45:32] <andypugh> But you don't need to home the motor driver to the index in order to use the index to align the motor for toolchanges etc.
[21:46:26] <andypugh> It's two slightly different concepts
[21:58:09] <mshaver> about the pins/param thing, or the rollover? :)
[21:58:38] <andypugh> Those variables are only variables for debug, they will disappear in the final version.
[21:58:54] <andypugh> Rollover is a more interesting question
[22:00:25] <andypugh> But might be a long wait, at 4000rpm you need to wait 4 hours
[22:00:32] <mshaver> If they're going away it doesn't matter. If they were going to stick around they are easier to display as pins.
[22:00:59] <mshaver> I can go ~1800, so 8+ for me
[22:01:23] <mshaver> It will be an issue though, for spindles anyway
[22:01:41] <andypugh> Yes.
[22:01:57] <andypugh> It will inherit whatever the encoder counter itself does.
[22:01:57] <mshaver> We could make a 1000 bit counter component :)
[22:02:00] <psha> test1
[22:02:03] <psha_> test2
[22:02:05] <psha> :)
[22:02:11] <psha> irssi cloned connections
[22:21:09] <andypugh> Any suggestions how best to handle encoder rollover?
[22:22:32] <andypugh> I guess simplest is to use a long long internally, and add delta rawcounts to it.
[22:23:33] <andypugh> That should be good for 100,000 years at 4000 rpm.
[22:30:06] <mshaver> Suggestions from me you mean? Basically what you said - a wide counter internally.
[22:31:40] <andypugh> I was hoping for comments from folk who have already done it
[22:32:21] <andypugh> It would be possible to detect a rollover and tweak the "offset" parameter accordingly. That might be less computationally expensiv
[23:12:35] <dgarr> wondering why the axis commands estop_clicked and onoff_clicked don't issue return "break" since it is tested (to limit further bindings' execution) when these commands are bound to keys F1 and F2 ?
[23:14:58] <dgarr> as in <Key-F1> if {"[32798752estop_clicked %# %b ...]" == "break"} break
[23:18:18] <andypugh> I am paying attention, but don't even understand the question :-)
[23:18:40] <dgarr> jepler will know
[23:22:31] <andypugh> Is that Python?
[23:23:07] <dgarr> python commands bound tcl/tk widgets
[23:23:19] <dgarr> s/bound/bound to/
[23:23:56] <andypugh> Can't we all just use C (or VBA?)
[23:25:58] <skunkworks> hey - I like vba
[23:26:36] <andypugh> I like VBA, it's a perfectly good language and rather a pleasant development environment too.
[23:27:25] <skunkworks> you would not believe the in-house applications we have made in msaccess
[23:29:37] <andypugh> Oh, I would. We run all our dynamometers using an application I wrote in Excel VBA. It's only vaguely recognisable as Excel any more, as none of the menus, keyboard shortcuts or right-clicks do the same thing as they used to, even file-save and Ctrl-S actually export our own XML files.
[23:30:38] <skunkworks> swee
[23:30:40] <skunkworks> sweet
[23:31:30] <andypugh> I have written a few "spreadsheets" that immediately hide Excel, open a big dialog box and act as a standalone application. The only Excel thing about them is the icon and file extension (and the fact I can pass them around freely without anyone suspecting what they are)
[23:33:20] <andypugh> Talking of subsuming underlying software: Dgarr, your ngcgui tabs and conversational programming, (which I have seen on youtube). Is that empbeddd pyvcp tabs, or galcevcp?
[23:33:57] <dgarr> embedded natviely, eg, tcl/tk
[23:34:19] <andypugh> Ah.
[23:37:06] <andypugh> It does look very clever, even if I haven't much idea what is going on.
[23:40:36] <dgarr> it just makes a gui for a subroutine that conforms to a few rules, and allows the user to make a gcode file combining features described by one or more of these subroutines. embedding several is a convenient extension of the idea. there is also one that acts as a frontend to truetype-tracer
[23:42:11] <andypugh> You use this for ornamental turning, if I recall correctly?
[23:43:57] <dgarr> i do ornamental turning but I dont use ngcgui for it (or not much anyway)
[23:45:02] <andypugh> I got distracted by your website, you do make some lovely things.
[23:46:21] <dgarr> thanks -- i've been turning for a lonnnnnng time
[23:48:09] <andypugh> I have done very little woodturning.
[23:49:13] <andypugh> Just a couple of acorn finials in oak.
[23:49:32] <andypugh> (10" diameter)
[23:50:38] <andypugh> When I think about it, me and my dad probably spent more time making the lathe than we did using it. (it is dismantled again now, job done)
[23:52:52] <andypugh> The point is, I can easily see how you could get hooked on woodturning.
[23:54:08] <andypugh> was
http://www.panix.com/~dgarrett/phpv1/index.php?img=%2Fuserdirs%2Fdgarrett%2Fphpv1%2F05-Palm%2Fscan_23.jpg turned, and if so, how?
[23:54:17] <dgarr> it can be addictive -- and the wood is often free
[23:55:09] <andypugh> I am thinking perhaps you could have frozen it in a block of ice for support during machining?
[23:55:29] <dgarr> turned, then wire-brushed afterwards -- palm is composed of long fibers and soft pith, no rings
[23:56:26] <andypugh> Ah, so it comes with its own support matrix?
[23:57:11] <dgarr> yes -- palm is a monocot -- like grasses, woods are dicots (if i remember correctly)
[23:58:01] <andypugh> I knew what cotyledons were once...
[23:58:40] <dgarr> yeah -- something about embryonic leafs
