Back
[07:51:48] <mhaberler_> mhaberler_ is now known as mhaberler
[08:00:50] <mhaberler> psha: bon giorno!
[08:05:12] <psha> good morning
[08:06:10] <mhaberler> I was wondering wether it could make sense to make gladevcp an importable module
[08:06:41] <psha> at some extent it's already importable
[08:06:46] <psha> what exactly you need from ti?
[08:06:48] <psha> it?
[08:07:28] <mhaberler> I was thinking along the lines that it could be used to slide into an existing app like touchy without being a separate process
[08:08:00] <psha> look into camview-emc
[08:08:22] <psha> http://psha.org.ru/cgit/psha/cu-plugins/tree/camview-emc#n178
[08:09:44] <psha> 'gladevcp' program is tiny layer above makepins
[08:09:53] <mhaberler> I see.. you already there..
[08:11:09] <mhaberler> need to play with it to get a feel
[08:15:20] <mhaberler> did you find acceptance for the hal init ordering stuff?
[08:16:44] <psha> yes
[08:16:53] <mhaberler> good
[08:16:57] <psha> but it needs testing
[08:17:22] <psha> test gladevcp-axis-forward2 branch please
[08:17:41] <psha> it has POSTGUI_HALFILE in proper place
[08:18:03] <mhaberler> ok, I'll get around later today because I'm working on something different this morning; will let ypu know how it goes
[08:18:50] <mhaberler> am I supposed to start ordering--dependent tabs with 'halcmd loadusr', right?
[08:19:14] <psha> i'll commit pre version of gladevcp frame at right there too
[08:19:25] <psha> yes, commands you want to wait - with halcmd
[08:19:52] <mhaberler> what about the &, when to use it - if no hal component in this process?
[08:21:05] <psha> & was another option to achieve same
[08:21:13] <mhaberler> so dont use?
[08:21:16] <psha> but halcmd is ued instead of it
[08:21:17] <psha> yes
[08:21:21] <mhaberler> ok
[08:21:34] <mhaberler> well, you convinced me looking at it..
[08:21:42] <psha> difference between & and 'halcmd loadusr' ways is that first marks background processes and last - foreground
[08:21:58] <psha> i think marking processes that we want to wait have to be explicit
[08:22:08] <psha> so that's why i've choosed this way
[08:23:28] <mhaberler> stupid me dont quite get. An EMBED_* command is run in the backhground in the first place, or have you changed that?
[08:28:13] <mhaberler> so test scenario would be: several tabs with halcomponents, no -H arg, all halfiles merged into POSTGUI_HALFILE, and see if things break, right?
[08:29:31] <psha> it's running in background if it's not 'halcmd loadusr' command
[08:29:44] <psha> if it's 'halcmd' -- then it's waited
[08:29:56] <psha> yes
[08:29:56] <mhaberler> so the & is superfluous?
[08:29:58] <psha> yes
[08:30:05] <mhaberler> ok
[08:30:20] <psha> also i've just commited gladevcp frame at right
[08:30:53] <mhaberler> in the last minutes?
[08:31:18] <mhaberler> I see..
[08:31:59] <mhaberler> same story on command line with halcmd usrlaod for GLADEVCP, I assume?
[08:32:08] <psha> no
[08:32:12] <psha> GLADEVCP=file.ui
[08:32:22] <mhaberler> why?
[08:32:34] <psha> simple tasks has to be simple
[08:32:44] <mhaberler> come on, this is useless
[08:32:53] <psha> if user wants just vcp tab - he don't need to know about gladevcp params
[08:33:11] <psha> if he want some extra stuff like userfuncs then
[08:33:30] <psha> GLADEVCP=-u module -H halfile -d ...options... file.ui
[08:33:49] <mhaberler> ok, I'm safe
[08:34:14] <psha> i think i'll also allow interspersed args so this line may look like
[08:34:16] <mhaberler> what does that mean foro POSTGUI_HALFIL
[08:34:26] <psha> GLADEVCP = file.ui -u module.py ...
[08:34:47] <psha> nothing, POSTGUI_HALFILE is executed after waiting
[08:34:58] <psha> and it's executed only when vcp tab is ready
[08:35:30] <mhaberler> I guess mmy question is - do EMBED_TAB and GLADEVCP command lines follow the same syntax and semantics wrt waiting (I suggest they do..)
[08:35:48] <psha> no
[08:35:53] <psha> gladevcp line is always waited
[08:36:08] <mhaberler> ok, confuses me but it sounds safe
[08:36:24] <psha> GLADEVCP parameter is prepended with 'halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -x {XID}'
[08:36:38] <mhaberler> aha..
[08:36:57] <psha> so VCP is _always_: a) waited b) live in 'gladevcp' component
[08:37:16] <mhaberler> get it. That needs proper documenting lateron.
[08:37:19] <psha> still user may give any options he want
[08:37:55] <psha> VCP is a sort of very specific case of dynamic tba
[08:37:56] <psha> tab
[08:38:56] <mhaberler> on a diffferent issue, I was thinking about autoraising a gtk notebook tab in a GLADEVCP component and bury it when done (toolchanger); I would assume this would be strictly within gtk then though
[08:39:12] <mhaberler> *not* an EMBED_TAB tab
[08:42:09] <psha> yes
[08:42:13] <mhaberler> basically what happens is: toolchange request pin comes up->tab raised jog,probe, whatever, press complete-> tab goes down, previous tab comes up
[08:42:14] <mhaberler> but I dont think this touches anything you do
[08:43:36] <psha> yes, i've only done some work for proper embeding
[08:44:08] <mhaberler> it's on the 'seamless integrated' front ;-)
[08:53:42] <psha> bb
[11:11:36] <mhaberler> psha: you have mail
[11:12:01] <psha> maybe :)
[11:13:43] <psha> hm
[11:14:43] <psha> if you leave only ui file as arguments it's working fine?
[11:14:59] <mhaberler> dont think so, let me retry-..
[11:17:11] <mhaberler> right, same thing
[11:17:17] <mhaberler> do you get a window?
[11:20:00] <psha> post .ui file somewhere
[11:20:04] <psha> i'll check
[11:20:26] <mhaberler> shall I try a differnt ui first, something simple?
[11:21:02] <psha> sure
[11:21:48] <mhaberler> this current, not simple
http://static.mah.priv.at/public/tc_probe.ui
[11:24:22] <psha> buildbot is down..
[11:26:51] <mhaberler> oh.. on a slow machine you see well that it's waiting for gladevcp to become ready.. good..
[11:26:53] <mhaberler> Waiting for component 'gladevcp' to become ready...................
[11:26:54] <mhaberler> same thing on
http://static.mah.priv.at/public/simple.ui (window1visible = false - not even empty window)
[11:28:39] <psha> i'll check in ~20-30 minutes...
[11:28:44] <psha> i've to build emc first
[11:28:45] <mhaberler> sure
[11:38:51] <psha> window is there...
[11:38:56] <psha> problem is with size requests
[11:39:15] <mhaberler> do I need to set an explicit size in glade?
[11:39:57] <psha> i'll check now
[11:43:10] <psha> hm, i've found what's wrong...
[11:43:45] <psha> gladevcp widgets don't issue size request
[11:43:59] <psha> but even gtk button is not asking for it...
[11:47:39] <mhaberler> strange, and in EMBED this works?
[11:47:59] <psha> in embed you inherit size from parent
[11:48:05] <psha> here you have to force size
[11:48:06] <mhaberler> ah..
[11:48:08] <psha> that's difference
[11:48:23] <mhaberler> question is where - gladevcp cmd line?
[11:55:52] <psha> no
[12:02:08] <psha> i've fixed it
[12:02:40] <mhaberler> pullable?
[12:03:33] <psha> not yet, cleanup
[12:04:57] <psha> pullable
[12:07:02] <mhaberler> ah, now we're talking!
[12:07:24] <mhaberler> size is natural size of .ui?
[12:07:53] <psha> either force or computed from child widgets
[12:08:02] <psha> but was in incorrect order of reparenting
[12:08:04] <psha> bug
[12:08:24] <psha> now i forst create plug in new place and only then move all child widgets
[12:08:40] <psha> so they got proper set-parent signals
[12:10:18] <mhaberler> ok, the window1 visible attribute has to be false so as not to have a spare empty window hanging around. needs documenting.
[12:12:02] <psha> ?
[12:12:03] <psha> no
[12:12:07] <psha> window1 is destroyed
[12:12:34] <psha> not destoyed but it stay hidden forever
[12:12:44] <psha> it's never mapped, never realized
[12:13:10] <mhaberler> not if I have it visible in glade
[12:13:12] <mhaberler> halcmd sequencing with both EMBED and GLADEVCP seems to work ok for me
[12:13:33] <mhaberler> I go back and set visible again, retest
[12:14:24] <psha> ah, i see now
[12:15:42] <psha> i've added explicit 'destroy'
[12:15:49] <mhaberler> http://static.mah.priv.at/public/shot.png
[12:16:09] <mhaberler> that was with window1 visible=True
[12:17:47] <ries_> ries_ is now known as ries
[12:19:16] <psha> i've amended last patch with window.destroy()
[12:19:19] <psha> now it's ok
[12:19:23] <psha> hm
[12:19:27] <psha> it's not ok
[12:19:38] <mhaberler> hit the wrong window ?-)
[12:19:54] <psha> if you bind some handlers on destroy i'll trigger them in reparent i think...
[12:20:04] <mhaberler> uh
[12:20:13] <mhaberler> *zap*
[12:20:26] <mhaberler> maybe just unmap
[12:22:24] <psha> yes, i'll look around for other solutions now :)
[12:23:54] <psha> working fine
[12:24:03] <mhaberler> what you've done?
[12:24:15] <psha> unmap()
[12:24:27] <psha> gladevcp-axis branch
[12:24:55] <mhaberler> fair enough. needs documenting there may be a unmap event coming in when reparenting, right?
[12:25:43] <psha> yes, maybe some notice will be fine
[12:26:04] <psha> but i guess that you'll get unmap only if you force 'visible' on the window
[12:26:52] <psha> otherwise unmap will be ignored since window is not mapped
[12:30:12] <mhaberler> that looks very good!
[12:32:27] <mhaberler> ok, I guess this will go to the GladeVCPsetup page because that deals with ini issues
[12:32:29] <mhaberler> should I delay until merge time?
[12:35:55] <psha> it's harmelss note so better to put it now or it'll be lost
[12:37:18] <mhaberler> ok, let me search that chat log for 'documenting'...
[12:50:50] <psha> i think i've found generic way to represent different emc actions like estop/poweron/...
[12:51:05] <mhaberler> yes?
[12:51:32] <psha> gtk.Action
[12:52:00] <psha> it's a kind of generic action that may be bound to any button
[12:52:16] <mhaberler> oh, you mean you can paste them in glade.. cool!
[12:52:40] <mhaberler> is that true? actions - are they glade supported?
[12:53:07] <mhaberler> yes, its a Buildable
[12:53:32] <psha> yes
[13:08:06] <mhaberler> the GLADEVCP stuff only applies to Axis, right?
[13:08:12] <psha> yes
[13:12:18] <jthornton> does anyone know if "make install-menus" overwrites the 2.4 menus or adds 2.5 menus?
[13:19:06] <psha> i think it overwrites
[13:19:24] <psha> cp $< $(HOME)/.config/menus/applications-merged
[13:24:40] <mhaberler> psha: please quality-review
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?GladeVcpSetup, sections 'Integrating the example UI into Axis' and 'Axis: linking HAL pins in the example UI'
[13:27:22] <mhaberler> I'll add a note on key handling to the GladeVCPprogramming page, as well as the unmap stuff
[13:27:24] <mhaberler> probably begin a FAQ section there
[13:30:09] <psha> everything is right i think
[13:30:15] <psha> bb
[13:30:26] <mhaberler> super, great job! cu later
[13:36:12] <jthornton> mhaberler: as soon as I finish up with this PLC I'll attempt to follow the instructions on the wiki
[13:36:51] <mhaberler> ok, the GladeVCPSetup page is ready I think, I'm doing last touches on GladeVCPprogramming.
[13:37:23] <jthornton> I have a brand new D510 with nothing on it except the LiveCD in 10.04
[13:55:17] <mhaberler> jthornton: I'm done with GladeVCPprogramming as well (for today, that is ;-)
[13:57:01] <jthornton> ok, I'm adding some links from the main page and a link in the setup page and going through it line by line building a panel
[13:57:25] <mhaberler> so you're actually trying it out? great!
[13:57:45] <mhaberler> heroic ;-)
[13:58:39] <jthornton> yes, it is a fresh computer so it will be a good test bed
[13:58:59] <mhaberler> uh.. I'm standing by.
[13:59:38] <jthornton> it will take me a while for sure... I'll correct any thing I see on the wiki as I go along
[14:08:55] <mhaberler> I noted an omission in GladeVcpSetup, will fix it (Axis: linking HAL pins in the example UI)
[14:13:47] <mhaberler> done
[14:15:37] <mhaberler> jthornton: the GLADEVCP option is subject to an upcoming merge - it is NOT yet in master; as is the 'halcmd loadusr' /POSTGUI_HALFILE stuff.
[14:15:39] <mhaberler> it is a rare case of documentation before code availability ;-)
[14:19:20] <jthornton> mhaberler: so what are you saying?
[14:19:56] <mhaberler> stay with EMBED_TAB_COMMAND only, or wait a day or two
[14:20:19] <jthornton> ok, what does GLADEVCP do
[14:20:34] <mhaberler> giv you a gladevcp panel where PYVCP used to be
[14:20:54] <jthornton> I'm still getting build-dep emc2 LOL so you have time
[14:21:09] <mhaberler> right side of axis, not tab near preview/DRO - always visible
[14:21:21] <mhaberler> ok...
[14:21:25] <jthornton> ok
[14:21:58] <mhaberler> I will replace screenshots eventually
[14:22:02] <jthornton> it says 5h left lol
[14:22:17] <jthornton> ok thanks
[14:22:29] <mhaberler> maybe we can merge in time for that ;-)
[17:20:37] <SWPLinux> anyone around that I can discuss git committing with? (jepler, cradek, bueler)
[17:21:32] <jthornton> ...
[17:21:34] <SWPLinux> I'm trying to make sure I don't bork anything when I (finally) commit changes to genserkins.c
[17:21:55] <SWPLinux> I had originally done the work on master, then jepler suggested doing it on ja3 instead
[17:22:06] <SWPLinux> so I made the changes there as well, plus a typo correction
[17:22:36] <jthornton> I do a git pull --rebase to push my changed to the top as jepler told me to do
[17:22:41] <SWPLinux> I have now done a series of things which might actually have the correct code in both master and ja3 (though the changes may be in master as well, I need to look)
[17:23:04] <jthornton> I think there is a git push --test or something like that
[17:23:08] <SWPLinux> well, there were changes in both my tree and the master repo, and there was some other complication as well (which could have been in my head)
[17:23:13] <SWPLinux> --dry-run
[17:23:21] <jthornton> yea, that one
[17:23:43] <SWPLinux> after finally eliminating the merge conflicts, I think I can now push (--dry-run doesn't give any errors any more at least)
[17:23:44] <jthornton> when I get confused I start with a fresh one then add my changes to it
[17:23:52] <SWPLinux> yeah, I thought about that too :)
[17:24:06] <jthornton> but I get confused easy sometimes
[17:24:18] <SWPLinux> I want to play with gladeVCP while I'm away, so I figured I should fix this up before I leave (in about 30 minutes :) )
[17:24:20] <SWPLinux> yeah, me too
[17:24:49] <jthornton> I tried git --ohshit once but it didn't work and jepler had to fix my mistake
[17:24:50] <SWPLinux> ooooohhhhh, I think I just figured out one of my questions
[17:24:52] <SWPLinux> heh
[17:25:13] <SWPLinux> git status tells me that my branch is ahead by two commits, even though I only did one
[17:25:20] <SWPLinux> but the second is the merge
[17:26:05] <SWPLinux> I guess it's no big deal if the change goes on master as well
[17:33:32] <CIA-2> EMC: 03swpadnos 07joints_axes3 * red4706d6b006 10/src/emc/kinematics/genserkins.c: Add "unrotate" parameter for each joint
[17:33:36] <CIA-2> EMC: 03swpadnos 07joints_axes3 * ra9a0fa032f1b 10/ (89 files in 34 dirs): Merge branch 'joints_axes3' of ssh://git.linuxcnc.org/git/emc2 into joints_axes3
[17:33:45] <SWPLinux> well, it looks like there aren't any changes in master, so it's probably OK
[17:33:57] <SWPLinux> but in case it's not. well, see you later, gotta go catch a plane :)
[17:34:29] <SWPLinux> (sadly, I can't connect to IRC at the airport any more, TMobile screwed something up)
[17:34:44] <SWPLinux> see you layter
[17:34:46] <SWPLinux> or later
[17:35:10] <jthornton> have a safe trip
[17:37:40] <Jymmm> jthornton: He's just going to get the free "cop a feel of my junk" their offering.
[18:33:54] <skunkworks> the logic hal componant is cool - once you figure out the incantation. (I needed a 3 input and gate)
[18:35:47] <skunkworks> how experimantal is it?
[18:40:33] <skunkworks> works!
[19:07:59] <skunkworks> hmmm
[20:00:04] <skunkworks> cradek: I think there is an issue with toolchange at g30 and locked rotories. I got a following error when it tried to rotate the b axis to 0. (like it doesn't lift it)
[20:39:26] <skunkworks> I think it would be nice to have a tool change position that doesn't require all axis to move.
[20:41:58] <skunkworks> (short of manually moving it - which surely is an option.)
[21:16:41] <andypugh> Has anyone noted the problem here? I have always found that single step Just Works.
http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,38/id,6115/lang,english/#6115
[21:29:34] <JT-Shop> andypugh: what happens when you single step something like o100 call?
[21:29:51] <andypugh> Never tried.
[21:30:19] <andypugh> The complaint is that it is funky on the axis splash screen code.
[21:30:24] <JT-Shop> me neither
[21:30:30] <JT-Shop> yea, I read that one
[21:30:46] <JT-Shop> maybe a bad keyboard?
[21:32:11] <andypugh> Possibly, lets see how they are doing it
[22:22:30] <jepler> skunkworks: there's "toolchange at quill up" that only moves Z...
[22:26:12] <skunkworks> jepler: our machine needs the Y axis to be in the right location (horizontal machining center..)
[22:27:56] <jepler> skunkworks: yeah, I figured it wasn't suited to your situation
[22:27:57] <jepler> too bad
[22:28:29] <skunkworks> heh :)
[22:30:50] <andypugh> I think that perhaps a toolchange version of MDI_COMMAND would be jolly useful. A single line of G-code (which might call a subroutine) that is optionally run when M6 is programmed.
[22:31:06] <jepler> something like this (untested, naturally) would move only the linear axes at toolchange:
http://pastebin.ca/2023120
[22:31:55] <andypugh> TOOLCHANGE_COMMAND maybe. Then skunkworks could program TOOLCHANGE_COMMAND G53 Z400 Y50
[22:37:20] <skunkworks> jepler: Thanks - I will try it.
[22:37:49] <skunkworks> (that didn't seem excited enough) Thanks!!
[22:40:53] <jepler> skunkworks: you're welcome .. if that works, then I think you'll be able to make whichever axes you want move, and none of the others..
[22:43:21] <andypugh> Any thoughts on the arbitrary G-code call option? IIRC M6 is a queue-buster anyway?
[22:44:07] <andypugh> rack-type changers then become trivial too.
[22:49:39] <skunkworks> jepler: yes - that points me in the right direction. I could then change any of the lines to canonEndPoint.n; (where a is the axis)?
[22:49:53] <skunkworks> *n is the axis?
[22:50:12] <skunkworks> and they will not move during the tool change call?
[22:50:18] <jepler> I think so
[22:50:21] <skunkworks> neat
[23:20:11] <andypugh> I am getting rather disillusioned here. I can't decide whether you are all too busy to respond to my ideas and code submissions, or whether I am being actively ignored in the hope I will go away.
[23:20:50] <andypugh> IRC/email make it really hard to pick up on that sort of thing.
[23:22:10] <jepler> andypugh: specifically for the 8i20 and three-phase stuff I feel like I'm not the guy to review it
[23:22:45] <jepler> andypugh: I also have not been sure whether you think it's ready for incorporation or not
[23:23:25] <jepler> andypugh: so if you think it is, and the list postings haven't produced criticisms that need to be addressed, I (or some developer) should probably just put the stuff in..
[23:23:58] <jepler> bbl, it's time to make dinner here
[23:26:43] <andypugh> I don't think any of it is completely ready yet (actually the new bldc component probably is ready for release if not signoff as it has been tested by me and mshaver and has worked so far, it needs exposure to more real-world hardware. What is missing is a comprehensive documentation, probably on the wiki, as it will need pictures)
[23:27:52] <JT-Shop> andypugh: get something on wiki and I can add to the manuals when needed
[23:28:03] <andypugh> It's just kind of demoralising when a week of work elicits no response at all.
[23:29:16] <JT-Shop> for the bldc?
[23:29:44] <andypugh> The modified gearchange comp with an arbitrary number of gears seems fairly straightforward to accept.
[23:30:43] <JT-Shop> only thing I can try it on is my tractor but it is not as one but one more glass and the parts will be ordered :)
[23:34:24] <andypugh> seb said he didn't like the 8i20 driver, but didn't really elaborate on how I could make him like it more.
[23:38:04] <JT-Shop> maybe he was not sure why
[23:40:03] <JT-Shop> * JT-Shop gets back to making tractor parts
[23:40:30] <andypugh> Aye, can't you make them from sctratch?
[23:40:47] <andypugh> (And did you try eBay?)
[23:41:41] <JT-Shop> this is some other parts that need replacing the clutch is almost a done deal... the place I get the F40 parts from is the best one I
[23:41:45] <JT-Shop> 've found
[23:42:27] <JT-Shop> the bad parts of the clutch are pressed metal formed parts and special head screws etc...
[23:44:28] <JT-Shop> they all come from China now a days anyway
[23:44:57] <andypugh> Old tractors are popular in the UK, might be worth trying ebay.co.uk
[23:46:12] <andypugh> After looking, maybe not.
[23:46:32] <JT-Shop> this model was only made in 55 and 56 for the US market for the Ferguson dealers to compete with the Massey MF-50 model as Massey had purchased Ferguson so it was Massey Harris Ferguson
[23:47:08] <JT-Shop> http://www.cheapcycleparts.com/model_years/1642-honda-2009-gold-wing-GL1800/assemblies/17917
[23:47:32] <andypugh> Aye, nothing in the UK for the F40. T20, 135, 165 yes
[23:47:38] <JT-Shop> mine is a '56 model slightly newer than me :)
[23:47:57] <JT-Shop> TO.. was US and TE.. was UK
[23:48:16] <JT-Shop> for Ferguson
[23:49:18] <andypugh> I suspect that the parts were common, I wonder if there is an online lookup?
[23:51:20] <andypugh> http://cgi.ebay.co.uk/Massey-Ferguson-Complete-11-Dual-Clutch-/260707163425
[23:59:29] <JT-Shop> yep that is the one
