Back
[07:28:39] <mhaberler> psha: good morning!
[07:35:16] <psha> hey
[07:35:40] <psha> i've tested signals yesterday and they are working
[07:35:51] <psha> so your issue is somewhere in merge conflicts
[07:35:59] <psha> you'd added theese signals in your code too
[07:50:32] <mhaberler> I dont know what you tested - the gladevcp in your gladevcp-glib2 branch is outdated - look at
http://psha.org.ru/git?p=psha/emc2.git;a=blob;f=src/hal/user_comps/gladevcp.py;h=27b41ccca69c68ceb244588c2891b5bf578c58fa;hb=e94bbec65a52ebe77e4b833510c6a9c3d99ab177
[07:52:40] <psha> maybe i've not picked some fixes that you've done for show
[07:53:03] <psha> glib2 is not tip of gladevcp development - it's just feature branch for signals/glib extensions
[07:54:52] <mhaberler_> mhaberler_ is now known as mhaberler
[07:54:54] <mhaberler> ok, it's Monday morning, Telekom Austria returns to work and starts with a DSL mass-breakage ;-)
[07:55:12] <psha> :)
[07:55:22] <psha> glib2 is not tip of gladevcp development - it's just feature branch for signals/glib extensions
[07:55:42] <mhaberler> thanks for sharing that ;-)
[07:56:16] <psha> i may rebase it over gladevcp
[07:56:24] <psha> and push glib3 one
[07:56:31] <mhaberler> superb idea ;-)
[07:57:11] <psha> but i have to pick all your fixes :)
[07:57:12] <mhaberler> I tried hard to nail the signals type warning, dont get anywhere - looks harmless though since its working
[07:58:24] <mhaberler> I though I could dump my changes, fetch from you and just fix yours;-)
[08:00:04] <psha> is there commit for window.show and halcomp.ready fixes?
[08:00:34] <mhaberler> let me study this hard question for a minute
[08:00:53] <psha> i've looked at log but have not seen them
[08:01:52] <mhaberler> http://git.mah.priv.at/gitweb/emc2-dev.git/blobdiff/5d242007e9b439aa2142521919f917c50f2f258b..fc85c3e5576e6c44a4e789becfa08b02af899428:/src/hal/user_comps/gladevcp.py
[08:01:56] <mhaberler> more to come
[08:02:21] <psha> this will break reparenting
[08:05:42] <psha> i'll commit better fix in a minutes
[08:06:04] <mhaberler> this gladevcp looks clean modulo reparenting:
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/d0c004c8aeaabe3a55d67dd9b33529e11c33274e:/src/hal/user_comps/gladevcp.py
[08:06:33] <mhaberler> if it's a signal from gladevcp or a call to a method, I dont care but some call post-setup needs to work
[08:07:49] <psha> on some setups you have to issue 'show' before reparenting - otherwise you won't get gdk drawable
[08:09:11] <psha> look at gladevcp-fix-show
[08:09:58] <psha> is it ok?
[08:13:44] <psha> compiling/testing
[08:14:33] <psha> realize is handled correctly now
[08:15:19] <psha> for subprocess fix there was commit but i have to found it :)
[08:17:23] <psha> i remember i was commiting it but can not remember where :)
[08:17:35] <psha> i was working on 3 computers last week :)
[08:18:00] <psha> ah! found :)
[08:20:26] <mhaberler> good..
[08:20:51] <mhaberler> optically looks ok, again git eclipse issues here :-/
[08:21:42] <mhaberler> can you rebase and push it in full glory so I can pull a working branch relative to master?
[08:22:25] <psha> yes, wait a bit pls
[08:30:05] <psha> may you take a look into gladevcp-fix-show branch?
[08:30:14] <psha> i'v uploaded opts.halfile fix there
[08:31:13] <psha> glib3 is rebased on top of it
[08:37:53] <mhaberler> that looks ok except for makepins halwidgets/gtkwidgets
[08:38:18] <psha> yes, that's need some more work
[08:38:25] <psha> so let look on it now
[08:38:51] <psha> i really don't like idea of storing gtk widgets in GladePanel
[08:39:13] <mhaberler> then we need an alternative as I laid out in email
[08:39:50] <psha> i'll look in persist branch to find way to workaround this
[08:39:53] <mhaberler> some kind of accesor/selector
[08:39:55] <mhaberler> could be library function in util
[08:40:44] <mhaberler> probably function in util is best but needs a workover of all my examples because of your bad feelings ;-)
[08:40:46] <psha> what's last branch? gladevcp-persist?
[08:40:59] <psha> heh, it's not only my bad feelings...
[08:41:21] <psha> it's breaking rule of 'hold data you need, don't hold what you don't need' :)
[08:41:38] <psha> consider someone else patching makepins
[08:41:55] <psha> he looks on the code and founds that there is useless (at a first glance) dict
[08:42:01] <psha> that's initialized and _never_ used
[08:42:24] <psha> if that person is me - i'll definitely kill that dict on first cleanup :)
[08:42:47] <mhaberler> the makepins from mah-work-gladevcp-glib was the ok for my examples
[08:43:23] <mhaberler> ok, then promise me you wont trample on an accessor function in util which I'm going to replace it with ;-)
[08:44:26] <psha> proper way is to do some wrapping for glade/gtkbuilder so both makepins/gladevcp util and presistence will benefit from it
[08:45:01] <mhaberler> dont talk suaheli to me
[08:45:13] <psha> heh, wait a bit for a POC patch
[08:45:56] <mhaberler> so: I checkout master, merge gladevcp-glib3 and am supposed to have something remotely working ;-?
[08:46:49] <psha> something working - yes :)
[08:46:59] <psha> persistence - not yet :)
[08:48:29] <mhaberler> because of the hakwidgets/gtkwidgets missing attr - that's ok
[08:48:34] <mhaberler> right?
[08:48:36] <psha> yes
[08:48:43] <mhaberler> ok, fair enough
[08:50:24] <psha> do you need some 'strange' functions of glade XML object?
[08:57:07] <mhaberler> what would that be?
[08:57:26] <psha> i don't know :) i've only used get_widget/signal_autoconnect :)
[09:00:43] <psha> take a look on gladevcp-gladebuilder branch
[09:08:01] <mhaberler> ok, that looks useful to me
[09:08:25] <psha> so if you want widgets - call get_objects() and leave only widgets with name (widget_name)
[09:08:41] <psha> this will fit in 2 lines of code :)
[09:08:52] <psha> or in 3 if you want for loop :)
[09:09:16] <mhaberler> get it. good idea.
[09:09:43] <mhaberler> now let me try if that works for me..
[09:12:26] <psha> ok
[09:20:08] <mhaberler> psha: any objections agains a dict accessor for gladebuilder instead or addtional to get_widget?
[09:21:12] <psha> gladebuilder is wrapper around Glade to provide gtk.Builder-like interface
[09:21:18] <psha> gtk.Builder is not wrapped
[09:21:37] <mhaberler> :-/
[09:21:48] <psha> as helper function - ok
[09:22:18] <mhaberler> that's useless, I need a uniform way to access widgets
[09:24:12] <psha> pull gladebuilder again
[09:24:16] <psha> and look on last change
[09:27:46] <mhaberler> how does this help?
[09:27:48] <mhaberler> in code, you'd want to *access* a widget by name in a uniform way, to call for instance set_active() or whatever
[09:28:12] <psha> ah
[09:28:24] <psha> builder.get_object('name').set_active()
[09:29:10] <mhaberler> Traceback (most recent call last):
[09:29:12] <mhaberler> File "./tc_probe.py", line 169, in _query_emc_status
[09:29:13] <mhaberler> self.builder.get_widget('task_mode').set_label("Task mode: " + task_mode)
[09:29:15] <mhaberler> AttributeError: 'gtk.Builder' object has no attribute 'get_widget'
[09:29:22] <mhaberler> see my point?
[09:29:42] <psha> get_object
[09:29:42] <mhaberler> this is NOT a libglade xml file, a gtkbuilder file
[09:30:03] <mhaberler> ok.. will try
[09:30:04] <psha> in gladevcp glade.XML is wrapped with GladeBuilder
[09:30:21] <psha> so you have uniform interface to both glade and builder objects
[09:31:16] <mhaberler> ok, now that works
[09:33:21] <mhaberler> ok.. let me fixup my examples and stuff to use that to get a feel wether that really works
[09:33:23] <mhaberler> wiill take a bit though. looks good for a start, thanks!
[09:34:22] <mhaberler> so the current version pathology is: master->merge gladevcp-glib3->merge gladevcp-gladebuilder, correct?
[09:36:04] <mhaberler> so get_widget object->name, and get_object is name->object independently of ui format, right?
[09:36:41] <mhaberler> sorry, widget_name, not get_widget
[09:36:41] <psha> yes, checkout master, merge glib3 and builder
[09:37:00] <psha> get_object and widget_name works both for glade and gtkbuilder
[09:37:27] <mhaberler> ok, excellent - I'll report that in the wiki ;-)
[09:37:28] <mhaberler> I'm off now, some real life unfortunately interferes
[09:40:41] <psha> ok
[09:41:04] <psha> if you don't need widget_list function i'll maybe revert it
[11:14:59] <archivist_emc> archivist_emc is now known as archivist
[12:38:32] <mhaberler> psha: a question from the 'user front'..
[12:38:33] <mhaberler> interface to hal_glib.GPin() changed
[12:38:35] <mhaberler> I used to:
[12:38:37] <mhaberler> self.example_trigger = hal_glib.GPin(halcomp.newpin('example-trigger', hal.HAL_BIT, hal.HAL_IN))
[12:38:38] <mhaberler> self.example_trigger.connect('value-changed', self._on_example_trigger_change)
[12:38:39] <mhaberler> ..
[12:38:41] <mhaberler> AttributeError: 'GPin' object has no attribute '_item_wrap'
[12:38:42] <mhaberler> what's the proper use these days ;-?
[12:43:30] <psha> if you are using GComponent (which is the case of gladevcp) then it's already GPin
[12:44:00] <mhaberler> found it, I missed the new hal.py
[12:45:54] <mhaberler> I was referring to an explicitly declared hal pin not defined through a hal widget, plius adding a trigger
[12:45:55] <mhaberler> is the above still correct?
[12:46:03] <psha> yes
[12:46:07] <psha> ah
[12:46:07] <mhaberler> thanks
[12:46:07] <psha> no
[12:46:08] <psha> :)
[12:46:19] <psha> i need to recheck :)
[12:47:02] <psha> yes
[12:47:08] <psha> i think it's possible to wrap Pin in GPin
[13:44:10] <psha> mhaberler: you opinion - is something like osciloscope (halscope but more simple) useful or not? :)
[13:45:28] <mhaberler> the scope is *very* useful in the axis context - helps to nail down errors (even in the software, not just setup)
[13:47:29] <psha> i mean as widget :) representing some live data changes
[13:50:18] <SWPadnos> psha, sure, a halscope-like widget would be great :)
[13:50:30] <SWPadnos> (in case you need encouragement)
[13:50:42] <psha> i'm a bit ill now so only capable for doing simple work :)
[13:50:52] <psha> nothing that needs some thinking :)
[13:51:56] <psha> mhaberler: glib stuff is working for you?
[13:52:11] <mhaberler> yes, pretty well so far
[13:52:37] <mhaberler> have you looked at matplotlib?
[13:53:02] <psha> heh, while working on different probles at work i looked at tons of graphics libs :)
[13:53:18] <mhaberler> aja, sorry to ask ;-)
[13:53:32] <psha> but for live plot i have to draw it manually
[13:53:35] <mhaberler> this one's very stylish in output, methinks
[13:53:44] <mhaberler> I see
[13:53:59] <psha> i think for some monitoring RRD writing component will be useful
[13:54:20] <psha> dump pin values to rrd files and then draw them with rrd tool to watch for example voltage stability
[13:54:21] <mhaberler> aja, interesting idea!
[13:54:37] <psha> with pyrrd it's simple...
[13:54:55] <psha> * psha have to bug pyrrd maintainer to wake and accept bugfix...
[13:56:02] <mhaberler> off-topic: I saw a documentary about Rolls-Royce turbine factory - these guys look into every single running engine remotely - he could tell "we have currently 1261 of our turbines flying'
[13:56:26] <mhaberler> control freak heaven ;-)
[13:56:35] <psha> :)
[13:56:50] <psha> and turn them off? :D
[14:00:03] <mhaberler> no, but they have a 'remote detonate' button
[14:03:08] <mhaberler> no, but they have a 'remote detonate' button
[14:03:24] <psha> that's more usefyl
[14:03:28] <psha> ful
[14:04:27] <mhaberler> I think some stock brokers like the concept in association with a bit of short-selling..
[14:04:28] <mhaberler> anyway - the HAL widget change triggers work great, type warning gone, all there
[14:04:31] <mhaberler> great job!
[14:04:55] <psha> nice
[14:46:51] <mhaberler> psha: I'm done with adapting the examples
[14:46:52] <mhaberler> no changes to your code
[14:46:54] <mhaberler> util.py had several changes
[14:46:55] <mhaberler> see gladepvcp-glib3-adapted-examples branch
[14:46:57] <mhaberler> I'm off now - dentist :-/
[14:47:18] <psha_> good luck )
[14:48:03] <mhaberler> master of ruins ;-)
[14:49:18] <psha_> everything is so bad? :))
[15:05:20] <psha_> psha_ is now known as psha
[15:11:42] <psha> it's moving! :)
[15:45:35] <cradek> jepler: how would you feel about the latency-test showing the numbers in green/yellow/red, or having some other method to show whether a machine is working well? We get so many "what's a good number" questions, and afaic, there is an answer to that.
[15:46:24] <SWPadnos> the answer depends on whether the machine will have a base thread or not
[15:46:24] <psha> btw there was good suggestion about auto reporting (with user confirmation) of latency to some central database
[15:47:05] <cradek> SWPadnos: true - how about a max for software step generation (say 25000) and a max for other types of machine (say 50000)?
[15:47:30] <SWPadnos> I would expect servo thread latency to be lower if there is no base thread (depends on where the time check code is, but I think the base thread execution time could be part of the latency for the servo thread)
[15:47:33] <cradek> maybe green <= 25000, yellow 25000-50000, red > 50000
[15:48:00] <SWPadnos> sure, or use the colors for software base thread on the base thread, and for servo-only on the servo thread
[15:48:12] <cradek> maybe we should use words
[15:48:19] <cradek> I am just tired of seeing the questions
[15:48:23] <SWPadnos> (since 100000 may be OK for a servo-only machine)
[15:48:25] <SWPadnos> heh
[15:48:40] <cradek> here's a number: 123456. Now guess whether it's ok or not, new user!
[15:50:29] <SWPadnos> the difficulty is in using few enough words that they'll be read and understood
[15:51:11] <SWPadnos> I don't know how to say "a machine that has special hardware" in a way that people will understand, and without naming any specific hardware
[15:51:21] <SWPadnos> (like "if you have a Mesa card, then 100000 is OK")
[15:51:32] <cradek> well if they're using stepconf we know they need software stepping
[15:52:34] <cradek> heck we could have just one threshold. it'd be fine.
[15:53:05] <SWPadnos> latency-test isn't necessarily run from stepconf, it has its own menu entry
[15:53:59] <psha> SWPadnos:
http://psha.org.ru/tmp/hal_graph.png
[15:54:13] <SWPadnos> heh. cool
[15:55:08] <psha> is there any test component with sinusiodal output? :)
[15:55:23] <skunkworks> siggen
[15:55:35] <SWPadnos> yep. siggen has sin, cos, square, triangle, sawtooth
[15:55:41] <psha> thanks
[15:56:51] <psha> hm, rt...
[15:56:54] <psha> sad :)
[15:57:08] <psha> ah
[15:57:10] <psha> my bad
[16:06:52] <skunkworks> interesting issue. I have xyzb setup. I have axis 0,1,2, and 4 in the ini. the only issue I have run across so far is you cannot save from the machine calibration screen because it show axis 0,1,2,3,4 and cannot find the axis 3 in the ini. I assume I could just add a dummy axis 3 (pid and such) in the ini and it will work?
[16:08:32] <psha> hm, is there any 'start working!' command in halrun? i've loaded trivkins,motmod and siggen but .sine value is always zero...
[16:08:54] <psha> ah! start :)
[16:11:42] <psha> http://psha.org.ru/tmp/hal_graph.png
[16:11:43] <psha> :)
[16:16:09] <psha> caught on redraw :)
[16:16:54] <psha> x11 forwarding is not that fast as direct drawing :)
[16:42:15] <psha> SWPadnos: just curios - is there any need in graph widget or you'd just think it would be nice :)
[16:42:27] <SWPadnos> I just think it would be nice :)
[16:42:33] <psha> heh
[16:42:42] <psha> so it's done :)
[16:42:48] <SWPadnos> might as well be able to put a following error plot in your custom GUI, right?
[16:42:52] <skunkworks> I think it would be cool to have a graph of folloing error
[16:42:56] <skunkworks> heh
[16:43:23] <psha> some minor bugs may appear but in general it's working fine
[16:43:57] <SWPadnos> does it get its data by sampling a pin (in userspace), or does it get a buffer from something else?
[16:44:04] <psha> userspace
[16:44:11] <SWPadnos> ok
[16:44:30] <SWPadnos> well that would be request number one: make it work with the scope_rt module to capture data in realtime :)
[16:44:32] <psha> but if there is some RT way to export sampled data to userspace - then this mech mey be hooked too
[16:44:43] <SWPadnos> (but I still don't have a need for it)
[16:45:05] <psha> hm, any docs about scope_rt?
[16:45:06] <SWPadnos> halsampler/halstreamer also use a similar buffer-passing mechanism
[16:45:22] <SWPadnos> there may be a manpage, but the docs are the source ...
[16:45:30] <SWPadnos> or the source is the docs
[16:45:33] <SWPadnos> or something
[16:46:16] <SWPadnos> halscope is written in gtk, so it might actually be possible to "widgetize" the halscope graph canvas
[16:46:17] <psha> no docs, only source...
[16:46:23] <SWPadnos> source == docs :)
[16:47:17] <SWPadnos> scope_rt is soemwhat tightly coupled to halscope, so there isn't much need for real docs (yet?)
[16:48:19] <psha> yes... i think it possible to hook scope_rt
[16:51:02] <psha> but it's interfaced in some nontrivial way...
[16:51:05] <psha> not via hal pins
[16:51:58] <psha> heh, it's possible but not trivial :)
[16:52:42] <psha> also it's pretty useless for large timespans...
[16:53:24] <SWPadnos> it's not a strip chart recorder
[16:53:50] <SWPadnos> it's a shared memory interface, relatively tightly coupled like I said
[16:54:53] <psha> yes, i've inspected it and now looking around kernel queue interfaces :)
[16:55:48] <SWPadnos> RTAPI has no queues, FYI
[16:55:59] <SWPadnos> I think
[16:57:12] <psha> i think you think right
[16:58:30] <psha> what is shmem size limit?
[16:59:08] <psha> 1kb or megabites?
[16:59:17] <psha> heh, bytes :)
[17:02:48] <psha> with ring buffer it's possible to provide continous capture
[17:03:26] <psha> with possible issues when you reading is too slow and new data is written where you expect old
[17:04:13] <psha> but adding ring buffer in scope_rt is not easier then write new scope_ring_rt :)
[18:02:30] <psha> how are your teeth? :)
[18:12:55] <psha> http://psha.org.ru/tmp/hal_graphs.png
[18:26:13] <mhaberler> better
[18:26:15] <mhaberler> your graphics: great
[18:26:16] <mhaberler> my util.py : ailing - since I found out with the debugg that the method test in util:accessors() fails because eg. led is not a gtk.Range based widget anymore, but now a gtk.DrawingArea ;-)
[18:27:01] <mhaberler> we have to rethink the following:
[18:27:02] <mhaberler> def accessors(w):
[18:27:04] <mhaberler> '''
[18:27:05] <mhaberler> retrieve getter/setter name of an 'interesting' widget
[18:27:07] <mhaberler> '''
[18:27:08] <mhaberler> if isinstance(w, (gtk.Range, gtk.SpinButton,gtk.ComboBox)):
[18:27:10] <mhaberler> return ('get_value','set_value')
[18:27:11] <mhaberler> if isinstance(w, (gtk.CheckButton, gtk.ToggleButton,gtk.RadioButton)):
[18:27:13] <mhaberler> return ('get_active','set_active')
[18:27:14] <mhaberler>
[18:27:16] <mhaberler> raise NoGetterSetterError
[18:35:16] <mhaberler> psha: and with that, the get_value() method evaporated :-/
[18:35:59] <psha> mhaberler: led is controlled by input pin
[18:36:05] <psha> no reason for saving it's state
[18:36:22] <mhaberler> valid point..
[18:36:43] <mhaberler> uh. blush. embarresment..
[18:53:02] <mhaberler> psha: how about dropping the panel parameter to get_handlers() ? dont see much use anymore for it
[19:04:53] <mhaberler> psha: I'll kill it - no extra value and just confusion. Needs documenting though :-/
[19:16:17] <JT-Shop> in 2.5 if you have a debug message in the g code you can not delete the first one that shows up
[19:55:05] <psha> mhaberler: it's ok since code at this point is not used by anyone exept you :)
[19:55:26] <mhaberler> I fear so
[20:00:21] <psha> if you create commit for killing panel argument i'll pick it
[20:06:41] <jepler> JT-Shop: others have mentioned that bhut I haven't seen it myself. if you can make it happen consistently tell me how
[20:08:50] <psha> i've asked already but...
[20:08:58] <psha> what's proper place for gladevcp examples?
[20:09:00] <psha> configs/ ?
[20:13:46] <psha> mhaberler: i'm merging target branches to gladevcp
[20:13:58] <psha> glib3, meter, graph
[20:14:05] <mhaberler> share/gladevcp
[20:14:08] <psha> gladebuilder? or not yet?
[20:15:04] <mhaberler> i have share/gladevcp/{examples,templates}
[20:15:05] <mhaberler> gladebuilder: go ahead, its stable
[20:15:16] <psha> with or without widget_list?
[20:16:20] <mhaberler> I dont need widget_list
[20:16:30] <psha> so without
[20:16:40] <mhaberler> get_object and get_objects() should be fine
[20:30:52] <JT-Shop> jepler: I did this (debug, x is #<namedvariable>)
[20:31:19] <JT-Shop> ctrl spacebar will make it disappear but clicking on the X will not
[21:00:12] <andypugh> Interesting query on the forum from the Volleyball chap. It seems that he can jog two axes at a time in joint mode with either keyboard or USB gamepad/pendant, and in world mode with the keyboard. However the USB gamepad only jogs one axis at a time in World mode. Possibly a quirk of Halui?
[21:15:49] <JT-Shop> andypugh: how was your trip?
[21:20:18] <andypugh> Cold
[21:21:16] <andypugh> As I couldn't even get a taxi to take me to the train station on the day I departed due to snow conditions, that didn't come as a major surprise.
[23:36:30] <ries_> ries_ is now known as ries
