Back
[09:45:13] <psha> mhaberler: if you are willing to test glib branch then i may merge it :)
[09:45:51] <mhaberler> ah, I just had proof of concept (pin-change signal) myself..
[09:45:53] <mhaberler> yes will do!
[09:47:38] <mhaberler> which glib branch?
[09:47:38] <psha> i've read tom3p mail and i'm lost in it...
[09:47:43] <psha> gladevcp-glib
[09:47:59] <mhaberler> I suggest push..
[09:48:14] <mhaberler> oh, sorry..
[09:49:06] <psha> not all widgets are converted to GPin now
[09:49:49] <mhaberler> ah, I see. will,uh,try to merge ;-)
[09:50:04] <psha> wait a bit
[09:50:10] <psha> i'll convert bar to GPin too
[09:50:40] <mhaberler> btw it seems to me LED blinking is broken
[09:50:54] <psha> with gpin?
[09:51:04] <mhaberler> no, vanilla
[09:52:33] <psha> hm, i checked it yesterday and it seem working...
[09:52:42] <psha> pull gladevcp-glib
[09:52:52] <mhaberler> just did
[09:53:06] <mhaberler> merge ok...
[09:53:17] <mhaberler> so, and now?
[09:53:19] <psha> cad96579db3d24d84779acb1eeab3a728b3539ff gladevcp: Convert HAL Bar to GPin interface
[09:53:46] <mhaberler> aha, value-change.. I see.
[09:54:15] <psha> so if glib pins are working fine then i convert all widgets to GPin's
[09:54:27] <psha> and you may hook into value-changed signal of widgets
[09:54:53] <mhaberler> perfect.
[09:54:55] <mhaberler> what would be really cool if we could connect that in glade
[09:55:20] <psha> hm
[09:55:25] <psha> it's possible i think
[09:55:39] <psha> export 'hal-value-changed' signal on HAL Widgets
[09:55:53] <psha> glade will see it and provide user with ability to hook on it
[09:56:04] <mhaberler> right, that would be orthogonal to other signals
[09:56:48] <psha> is it sensible to export this signal on widgets like button?
[09:57:01] <psha> or only for 'output' widgets like labels, bars, etc?
[09:57:54] <mhaberler> stop making sense ;-)
[09:57:55] <mhaberler> yes, for the others you have the gtk pressed, toggled and friends
[09:58:15] <psha> good point
[09:59:04] <mhaberler> re led blink: blink rate box ticked, value 200, glade message: (glade:24412): GLib-GObject-WARNING **: value "0" of type `gint' is invalid or out of range for property `led-blink-rate' of type `gint'
[10:00:00] <psha> i've no glade installed here...
[10:00:22] <psha> i'll check it on sunday
[10:01:20] <mhaberler> but me. fine.
[10:01:21] <mhaberler> I'll have a look myself
[10:01:23] <mhaberler> just reading :
http://www.pygtk.org/articles/subclassing-gobject/sub-classing-gobject-in-python.htm
[10:02:28] <mhaberler> I guess its like so:
[10:02:29] <mhaberler> 7 __gsignals__ = {
[10:02:31] <mhaberler> 8 'paste_clipboard' : 'override' 1
[10:02:32] <mhaberler> 9 }
[10:02:41] <psha> look into hal_glib,py
[10:02:50] <mhaberler> aja
[10:02:55] <psha> ah, this way is better :)
[10:03:15] <psha> i've just used low-level api call to install signal like in C
[10:03:49] <mhaberler> you mean the signal-new?
[10:04:09] <psha> yes
[10:04:20] <psha> __gsignals__ are better way to do this
[10:06:13] <mhaberler> this is how to do it I guess
[10:06:15] <mhaberler> 12 __gsignals__ = { 1
[10:06:16] <mhaberler> 13 'engine-started' : (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE,
[10:06:18] <mhaberler> 14 (gobject.TYPE_FLOAT,))
[10:06:19] <mhaberler> 15 }
[10:06:59] <mhaberler> shall I or will you? I have glade..
[10:08:35] <psha> i'll have my hands on it only on sunday but
[10:08:46] <psha> but i've to do some refactoring of whole glib stuff
[10:09:02] <mhaberler> then leave it alon for now and I will giv it a stab
[10:09:23] <psha> current state of gpins is 'proof of concept' wrappers
[10:09:48] <mhaberler> useful proof though
[10:09:55] <psha> if it's working fine for you i'd create full flegded GComponent wrapper which provides you with GPins without extra mocking
[10:10:26] <psha> so i think if you have no immidiate need in 'hal-value-changed' event on widgets it's better to leave it after glib rework
[10:10:39] <psha> so it won't need to be repaired again :)
[10:10:59] <psha> and i try to understand Thomas's letter now :)
[10:12:22] <mhaberler> I think it's great that way. lets do this:
[10:12:24] <mhaberler> rename event to 'hal-pin-changed' because that's what it really is
[10:12:25] <mhaberler> make visible in glade signals, I try that
[10:12:27] <mhaberler> so I have it semi-working for me until you get around to do it properly
[10:13:42] <psha> ok
[10:14:03] <mhaberler> good. will let you know how it turns out.
[10:14:19] <psha> in hal_init you need to add something like 'hal_pin.connect('value-changed', lambda s: self.emit('hal-pin-changed'))
[10:14:44] <psha> or self.emit('hal-pin-changed', float(p.value)) if you have signal with float value attached
[10:15:27] <mhaberler> aja, so far I just passed the widget itself but the pin makes more sense
[10:27:50] <mhaberler> great view from my office - demotivates for coding ;-)
http://webcam.stiwoll.mah.priv.at/view/index.shtml
[10:30:44] <psha> i'm on gprs now :)
[10:33:24] <mhaberler> uh
[10:33:25] <mhaberler> cant see value-changed in glade
[10:33:27] <mhaberler> looks like we need to let glade know about the __gsignals__, some import or xml magic?
[10:34:22] <psha> dunno :) i've only tried gprops in glade, not gsignals :)
[10:34:47] <mhaberler> ok, will look into it
[10:36:46] <mhaberler> hah:
http://library.gnome.org/devel/gladeui/stable/widgetclasses.html
[10:37:47] <psha> i thought that it's related more to some packing magick...
[10:38:04] <psha> hm, signals are also there
[10:38:38] <psha> also moving gtk.show from place before reparenting will break it i think
[10:40:52] <mhaberler> hm, doesnt show up
[10:40:54] <mhaberler> I think we neeed to somhow export the GPin Object so glade inspects it
[10:42:57] <psha> gpin to glade!?
[10:42:58] <psha> what for
[10:43:21] <psha> you want to pass gpin _object_ with signal?
[10:43:22] <psha> not only value?
[10:43:42] <mhaberler> I am just exploring..
[10:56:32] <psha> bb in the evening
[10:56:43] <mhaberler> ok, cu!
[14:09:35] <mhaberler> psha: hi!
[14:09:36] <mhaberler> and the next thing I'm going to do when I get bored: generate the handler skeleton from the glade file and the signals in it ;-)
[14:09:37] <skunkworks> tgif@
[14:09:39] <skunkworks> !
[14:11:53] <JT-Shop> YEA! Concrete Day
[14:14:50] <psha> mhaberler: %)
[14:15:00] <psha> you'd better look for existing tools
[14:15:06] <psha> i bet there are some
[14:15:33] <psha> you'd better look into some way to graphicaly represent HAL schematics :)
[14:18:59] <mhaberler> psha: good point. and: great page ;-)
http://www.rootninja.com/generate-python-code-from-glade-xml-files/
[14:23:44] <psha> good choice of illustrations :)
[14:25:17] <psha> there was link from awallin(?) about his work on temp pid regulation
[14:27:16] <psha> http://www.anderswallin.net/2010/11/temperature-pid-control/
[14:27:19] <psha> look at the scheme
[14:40:25] <psha> provider hates him...
[14:43:06] <archivist> wifi breakage probably
[14:56:47] <psha> probably...
[18:58:30] <psha> mhaberler: have you got link to picture of HAL connections before your provider disconnect you? :)
[18:59:27] <mhaberler> psha: I dont understand - which picture?
[18:59:43] <psha> http://www.anderswallin.net/2010/11/temperature-pid-control/
[19:00:58] <mhaberler> ah, cool
[19:01:13] <psha> awallin: you drawn that by hand?
[19:02:28] <awallin> psha: yes :) would be nice to have something that draws HAL schematics automatically...
[19:03:03] <psha> with what tool?
[19:03:31] <awallin> that was with inkscape or coreldraw, can't remember which one right now...
[19:04:34] <psha> it's not hard to create graphviz file from hal but it's hard to create it in such what that it will look nice :)
[19:06:17] <psha> also it's not hard to build list of hal pins of gladevcp panel
[19:06:58] <psha> btw you provided link to wiki page about geda for hal
[19:07:25] <psha> you used it or just mentioned as an option?
[19:07:31] <awallin> I guess a graphical tool which would allow positioning the hal-components and signal-wires would be nice
[19:07:54] <awallin> I haven't used the geda tools. that's based on converting the hal file to a netlist (as in electronics) I think
[19:10:43] <cradek> sounds like a match - the hal file is a netlist already
[19:14:00] <ries__> ries__ is now known as ries
[19:19:22] <psha> bb
[20:32:27] <ries__> ries__ is now known as ries
[20:50:10] <Guest666> Guest666 is now known as micges
[20:50:21] <micges> hello
[20:51:04] <micges> how can we define fully operative secondary spindle in gcode?
[20:51:46] <micges> gcodes like S are singleton
[20:51:49] <SWPadnos> darned good question
[20:52:14] <SWPadnos> you could use an analog output, like M64(?)
[20:52:35] <micges> it can be done with m64/65 and M67/m68
[20:52:37] <SWPadnos> and some digitals as well, if you want FWD and REV
[20:52:56] <micges> but it isn't disabled at m2, abort and such
[20:53:01] <SWPadnos> right
[20:53:26] <SWPadnos> if I were going to change the language, I'd add an optional P or Q (or some integer) to the S code
[20:53:32] <SWPadnos> to select which spindle
[20:53:44] <SWPadnos> same for M3/4/5
[20:54:11] <micges> could be I J K
[20:54:24] <micges> to add ability to use 3 at once
[20:54:27] <SWPadnos> maybe
[20:54:32] <micges> for the future :)
[20:54:54] <SWPadnos> well, since I'm already changing the language, I'd also make it so you could use multiple words from the same group on one line :)
[20:55:08] <SWPadnos> M3 S1000 P1 M3 S2000 P2
[20:55:31] <micges> good idea
[20:55:37] <micges> but bigger change
[20:55:39] <SWPadnos> the question is whether M5 should stop all the spindles or not
[20:55:40] <SWPadnos> yeah
[20:56:13] <SWPadnos> I have seen a control where I was used for something non-geometric, but in EMC I think it's always "offset from X" (wherever it's legal)
[21:18:35] <micges> SWPadnos: I'll try adding secondary support on a branch without any interp changes, will see if 3 spindles are possible in sane amount of time
[21:18:46] <SWPadnos> cool
[21:19:19] <micges> will add some m23-m25 and m33-m35
[21:19:42] <SWPadnos> hmmm. yeah, too bad we don't have Mxx.x available
[21:20:10] <SWPadnos> (at least not in the table of M code groups)
[21:22:00] <micges> best would be to define spindles=[IO]SPINDLES at loadrt motmod
[21:22:13] <SWPadnos> or numspindles
[21:22:33] <SWPadnos> yes, I agree that a user-definable quantity is good, with 1 being the default
[21:23:32] <micges> it would broke all configs but it's acceptable on main number switch 2.4 -> 2.5
[21:23:42] <micges> or higher
[21:24:11] <SWPadnos> no, since a sane default is to provide 1 spindle I/O set unless a different number is specified
[21:25:06] <micges> yes but how will you name secondary spindle pins?
[21:25:57] <SWPadnos> I think if nothing is specified, use spindle-speed/at-speed etc as they are now
[21:26:21] <SWPadnos> if specified, then start with spindle.N for all the pin names
[21:27:56] <micges> imo it should be named spindle.# regardless of number of defined spindles
[21:28:27] <SWPadnos> maybe
[21:28:41] <SWPadnos> well, sure, you're writing the code, so do it your way :)
[21:29:43] <micges> heh
[21:30:44] <micges> imo if pins must be renamed to gain more logic/clear/whatever it should be done on main number release
[21:31:07] <micges> it was done at each main release
[21:31:19] <SWPadnos> yep, makes sense
[21:46:21] <Jymmm> Jymmm is now known as Red70sShow
[21:46:25] <Red70sShow> Red70sShow is now known as Jymmm
[22:29:59] <mhaberler_> mhaberler_ is now known as mhaberler
[22:42:54] <JT-Shop_> JT-Shop_ is now known as JT-Shop