Back
[06:18:53] <psha> logger_dev: bookmark
[06:18:53] <psha> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-12-27.txt
[06:27:07] <mhaberler> psha: good morning
[06:27:09] <mhaberler> what would EMC Stat pins describing state have an advantage over halui?
[06:28:00] <psha> no advantage
[06:28:12] <mhaberler> I see
[06:28:21] <psha> same things
[06:28:24] <psha> but local to interface
[06:28:55] <psha> good morning :)
[06:30:12] <mhaberler> on a different issue, I think I remember the hal py module doesnt support access of foreign component pins as does the underlying c code, I asked this once and was recommended to use halcmd :-/
[06:30:39] <psha> yes, that's why it's not available in Action :)
[06:30:45] <mhaberler> I worked on this but never merged it; I'll se wether I can pull the code
[06:30:58] <psha> i've added global pins and signals to pyhal month ago, needs some cleanup
[06:31:23] <mhaberler> ah good
[08:50:46] <mhaberler> psha: is the pyhal stuff online? just curious
[09:27:45] <psha> pyhal-signal
[09:28:21] <psha> hm, no
[09:28:34] <psha> it's stashed, not commited to branch
[10:01:12] <mhaberler> psha: attentive?
[10:11:33] <psha> 12:28 < psha> hm, no
[10:11:33] <psha> 12:28 < psha> it's stashed, not commited to branch
[10:11:56] <psha> i'll push it in the evening
[10:16:41] <mhaberler> question: re cmd/status channels. I though instead if doing my own I could just access those from _EMCStaticHolder - do you think that makes sense?
[10:16:43] <mhaberler> if so, I'm unsure how I would access those at handler startup
[10:17:25] <mhaberler> reason: it is a simplification in pre/pos mdi handlers if I can access existing channels
[10:21:56] <psha> yes, you may use static holder to get stat/cmd instead of creating new
[10:22:30] <psha> but i think there is no difference (in ideal world) is it existing channel or newly created
[10:31:05] <mhaberler> I know - the point is: in pre/post mdi I can get at readymade channels so user wont have to set it up
[10:31:46] <psha> in pre/post mdi you may grab channels from emmiting widget
[10:37:19] <mhaberler> right, that works. So my question was: how do I do it at program startup?
[10:47:07] <psha> in 'realize' signal?
[10:52:37] <psha> in 'realize' signal?
[11:12:21] <mhaberler> for instance, yes - which widget do I access there so I can get at both command and stat?
[11:18:15] <mhaberler> psha: bug report - the mdi-command-start handler executes *after* the MDI command has been passed on :-/
[11:20:13] <mhaberler> that one I can fix myself: swap lines 356 and 357 to start with
[11:23:13] <mhaberler> confirmed, works now
[11:57:44] <mhaberler> psha: I fixed the mdi-command-start handler executes *after* the MDI command has been passed on :-/
[11:57:45] <mhaberler> swap lines 356 and 357 in hal_actions
[12:09:49] <psha[work]> i thought it's not critical :)
[15:36:36] <JT-Shop_> JT-Shop_ is now known as JT-Shop
[16:13:57] <mhaberler> JT-Shop: I found a solution to the absolute position problem
[16:13:58] <mhaberler> G28.1 stores the current absolute position into parameters 5161-5166.
[16:20:32] <JT-Shop> mhaberler: cool
[16:27:13] <skunkworks> monday!
[16:28:39] <jepler> I didn't see the problem statement, but it's probably not a full solution.
[16:29:06] <jepler> .. because those coordinates are in the machine units, not the active units for gcode
[16:29:17] <jepler> so you have no way to determine whether they're in or mm values
[16:29:26] <jepler> even if you think you know which of G20 or G21 is active
[16:29:33] <jepler> so what use do the values have?
[16:30:01] <mhaberler> to move back to the starting position of a probe run, both on success or failure
[16:31:08] <cradek> why not just remember where you started (because you moved there in the first place)
[16:31:18] <mhaberler> doing a G28,1
[16:31:20] <mhaberler> the a G53 G0 <axis>#516x would do different things depending on G20 or G21?
[16:31:43] <cradek> I can't imagine why you'd probe without moving to a starting position first - what am I missing?
[16:32:15] <cradek> (answer to your question is yes)
[16:33:08] <mhaberler> ok, this is a ngc file called via MDI o-word, which now works
[16:33:10] <mhaberler> either I figure the starting position in Python and pass it in, or I figure it in G-code
[16:33:11] <mhaberler> either way is fine
[16:33:52] <mhaberler> I wanted to avoid getting the position from Python because then I'cant test the ngc file interactively
[16:34:59] <jepler> if you store the location using G28.1 then you can at least go back to it with G30..
[16:35:02] <jepler> er, with G28
[16:35:14] <cradek> yes - that will always work
[16:35:16] <mhaberler> that's good enough
[16:35:31] <jepler> of course, some users will be grumpy that you changed the G28 location..
[16:35:57] <mhaberler> that 'll be me only
[16:36:01] <psha> jepler: good evening
[16:36:10] <jepler> psha: what's up?
[16:36:37] <psha> nothing yet :) but hope for todays merge
[16:36:48] <psha> in 3-4 hours
[16:37:50] <mhaberler> cradek, jepler: G28.1 / g28 does it for me - thanks
[16:38:39] <jepler> psha: OK, I'll try to make time to look at it
[16:40:09] <psha> ok, i'll bug you when it's ready
[17:10:32] <jepler> mhaberler: I tried mhaberler/check-abort-during-toolchange-and-prepare but it doesn't fix aborting a toolchange here
[17:10:55] <jepler> mhaberler: run sim/axis. F1 F2 ctrl-home F5 t1m6. focus back to axis window. ESC.
[17:11:10] <mhaberler> let me try that.
[17:11:32] <mhaberler> you're using Esc to abort?
[17:11:53] <jepler> yes
[17:12:13] <jepler> and I'm looking for the tool change window to disappear (it does with F1 to estop)
[17:12:45] <mhaberler> I first need to reproduce your setup, it will take a bit
[17:13:50] <jepler> also, the first time AXIS is unresponsive for only a short time. The second time I do t1m6 ESC it's unresponsive for a long time
[17:14:13] <mhaberler> ok
[17:14:56] <jepler> (I don't ever click the toolchange popup away)
[17:15:19] <mhaberler> re emc: you worked off current master and pulled check-abort-during-toolchange-and-prepare, right ?
[17:16:34] <jepler> yes. I have the following commits since origin/master:
[17:16:34] <jepler> 92fe293 task: abort early during tool prepare as well, not just tool prepare
[17:16:34] <jepler> e6d3ba5 task: immediately abort a pending tool change if an abort was issued
[17:17:05] <mhaberler> ok.
[17:31:11] <psha> jepler: question to native english speaker: how to name object for accessing global HAL pins?: )
[17:31:43] <mhaberler> gal
[17:35:48] <SWPLinux> psha: what
[17:35:50] <SWPLinux> err
[17:36:12] <SWPLinux> what's a "global HAL pin" (vs other HAL pins or something else ... ?)
[17:37:58] <psha> SWPLinux: that!
[17:38:05] <SWPLinux> ?
[17:38:12] <psha> currently it's only possible to access pins you've created inside your component
[17:38:26] <psha> i'm adding method to get value of arbitrary hal pin
[17:40:17] <SWPLinux> ah, ok
[17:40:57] <SWPLinux> so there's a HAL module that will traverse the HAL metadata, so it can look things up by name?
[17:41:36] <SWPLinux> (that's the only way you can "legally" do it for data that's not contained within your own program or linked to a pin that was created by your program)
[17:41:39] <psha> currently it only implements 'getp' function
[17:41:42] <SWPLinux> ok
[17:42:47] <jepler> psha: that's a bad idea. unless there are new arguments in favor of adding such a thing, any patch to add it will be rejected
[17:43:26] <jepler> you never set another component's pins. you set your own output pins values; if there's a signal connecting it to some other component's input, then that value will also appear on the input
[17:43:32] <SWPLinux> yeah, it seems that a component shouldn't need to do that - if it needs a value, it should have a pin to connect it to
[17:43:53] <SWPLinux> unless you want to be able to write halscope in python/gladeVCP ...
[17:44:22] <psha> jepler: not 'setp', but 'getp'
[17:44:46] <jepler> psha: same difference. Transport data from one pin to another by using signals.
[17:44:51] <SWPLinux> psha: conceptually, there's no difference
[17:44:55] <SWPLinux> exactly
[17:45:15] <psha> use case is to allow user to write simple MDI commands
[17:45:19] <SWPLinux> unless you're trying to make it possible to write halscope in python/gladeVCP :)
[17:45:35] <jepler> mdi !?
[17:45:45] <SWPLinux> add input pins and reference those somehow
[17:46:02] <jepler> you've totally lost me here
[17:46:28] <psha> jepler: we have MDI Action now -- gtk action running custom MDI command
[17:46:29] <mhaberler> see here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ActionWidgets
[17:46:48] <psha> it's like halui.mdi-command-... but in more user friendly way and tihtly bound in interface
[17:46:57] <SWPLinux> I'm just assuming that the idea is to be able to programmatically create MDI commands based on some HAL state
[17:47:17] <mhaberler> to fetch HAL pins and pass them as parameters to MDI
[17:47:45] <psha> SWPLinux: not exact, consider action dependant on some dynamic values
[17:48:06] <SWPLinux> psha: sure, if <X is too far to the left> then move X first ...
[17:48:22] <psha> you may connect pins to motion.digital/analog-XX pins
[17:48:26] <psha> and then read them with M66
[17:48:48] <psha> or you may just say run 'G0 X${pin-name}'
[17:49:00] <SWPLinux> I was suggesting that the person using gladeVCP should add input pins to their component, similar to the motion input pins, and use those values
[17:49:12] <SWPLinux> instead of a generic lookup on other component pins
[17:49:31] <SWPLinux> (or pins owned by another component)
[17:49:49] <SWPLinux> as jepler said, the way you move data from one HAL component to another is to connect pins using a signal
[17:49:59] <mhaberler> that's an example of a MDI widget property, which calls an O-word sub:
[17:49:59] <psha> yes, current state is 'local only' pins
[17:50:00] <mhaberler> O<oword> call [${spin-f}] [${check}] [${toggle}] [${scale}]
[17:50:02] <mhaberler> check, spin-f etc are gladevcp HAL pins
[17:50:03] <mhaberler> with global HAL pins, this would be [${component.pin}]
[17:50:05] <mhaberler> and no endless halcmds and extra pins just to read a vlaue
[17:50:34] <SWPLinux> that's counter to the design of HAL ...
[17:52:00] <psha> so let it leave off board
[17:52:06] <mhaberler> Well, I dont see a better method of parameter passing between various parts of EMC
[17:52:08] <mhaberler> we're not talking 'setting up circuits', we're accesing values and passing them to G-code
[17:53:00] <psha> at least it will solve issues with different set of loaded components and fragmented hal config
[17:54:27] <mhaberler> AFAIC HAL represents global state, some of which can be useful in G-code as parameters - I dont see the value of linking these parameters to an extra component (gladevcp) just to pass them on from there
[17:56:06] <psha> mhaberler: consider (theoretical) case of distributed HAL setup
[17:56:07] <jepler> if you've got a "crash tool" mdi button it would have a "how-deep" pin (gladevcp.crash-tool.how-deep) and the MDI would be something like "G53 G0 Z[-1*${how-deep}]"
[17:56:16] <psha> you won't have access to foreign components
[17:56:24] <mhaberler> sort of, yes
[17:56:36] <jepler> if the same value you want for how-deep is also the value you want for your spindle command, that's up to you when you use 'net' comands to connect hal pins together
[17:57:36] <mhaberler> you guys are of course right that it can be always done with the extra pin and link it with halcmd
[17:57:38] <mhaberler> I just find it's a pathetic way to read a parameter value
[17:57:52] <mhaberler> jepler: I could reproduce what you've seen
[17:58:07] <mhaberler> but lets sort this out first
[17:58:16] <mhaberler> or any order, actually ;-)
[18:00:45] <psha> jepler: so let it live on the shelf until i'll find time to polish 'net' command :)
[18:01:20] <jepler> it's lunchtime here, so let these ideas rest for an hour or so
[18:01:49] <mhaberler> jepler: the difference came from my homebrew toolchanger which sends an abort and acks the iocontrol.0.tool-changed pin - the latter makes all the difference (to get iocontro back in idle state)
[18:01:50] <mhaberler> the wait loop is always aborted immediately, but iocontrol doesnt give up just yet in your case
[18:02:03] <mhaberler> sorry about that - I see the issue
[18:02:38] <mhaberler> I'm unsure how to nail iocontrol to give up on the tool change
[18:02:50] <mhaberler> that would take care of it
[18:03:38] <mhaberler> I'll look into it - probably a EMC_TOOL_ABORT does it
[19:47:57] <cradek> jepler: if we had introspection for current position, what should happen when cutter comp is active and you read it?
[19:48:12] <jepler> cradek: mu!
[19:48:38] <jepler> what happens when you issue G28.1 with cutter comp active?
[19:49:01] <cradek> emc/task/emctask.cc 356: interp_error: Cannot set reference point with cutter compensation in effect
[19:52:00] <cradek> as I see it, the alternatives are - give an error - give nominal positon - give compensated position
[19:52:32] <cradek> but the moves are queued, so there may be several 'relevant' positions
[19:52:44] <cradek> leaning towards an error...
[19:54:54] <jepler> yes, if you can make an error do that
[19:57:38] <cradek> http://timeguy.com/cradek-files/emc/0001-introspection-current-position.patch
[19:58:05] <mhaberler> aaaaa...
[19:58:35] <cradek> except for how it sucks (cutter comp case) it's pretty obvious and simple
[19:58:47] <cradek> so what am I missing? :-P
[19:58:56] <mhaberler> that would be great
[19:58:58] <mhaberler> well, detecting cutter comp is easy
[19:59:11] <cradek> detecting is not the problem
[19:59:20] <cradek> saying what the 'current' position is, meanwhile, is the problem
[19:59:28] <mhaberler> I mean from py.. btw can I do that in g-code?
[19:59:38] <cradek> huh? do what?
[19:59:45] <mhaberler> detect cutter comp
[20:00:13] <mhaberler> in py i do stat.gcodes and search for the g43 code
[20:00:15] <cradek> I don't understand -- cutter comp is on if you have previously turned it on
[20:01:00] <mhaberler> yes, but my context is an isolated O-word sub called from a button press
[20:01:02] <mhaberler> 'it' doesnt know wether cutter comp is on
[20:01:46] <cradek> it is unlikely that you ever want cutter comp on when doing mdi stuff
[20:02:25] <mhaberler> not that I care: the pre- and post mdi handlers in the link I posted above give me the chance to save it before, turn it off in the oword sub, and restore it to what it was in the post-mdi handler
[20:04:31] <cradek> I have not been keeping up with what you are doing, so I don't understand what you just said
[20:05:17] <tom3p> mhaberler, ?? this link >> <mhaberler> see here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ActionWidget
[20:05:25] <mhaberler> yes
[20:05:57] <cradek> I think you really want push/pop interpreter state instead
[20:07:09] <mhaberler> and MDI command is now a UI element which can be associated with an event in glade (button, menu, whatever)
[20:07:11] <mhaberler> we need to feed it parameters (from other widgets, or from HAL pins as discussed before)
[20:07:12] <mhaberler> and we need to make sure we dont trample on global or interpreter state
[20:07:33] <mhaberler> that's why there are handlers to establish pre-and postconditoons
[20:09:32] <mhaberler> if needed, that is
[20:16:39] <mhaberler> jepler: ok to discuss toolchange hang?
[20:22:08] <cradek> git_buildbot: ERROR: Could not connect to emc2-buildbot.colorado.edu:51332: User timeout caused connection failure.
[20:22:14] <cradek> (upon push)
[20:22:26] <CIA-60> EMC: 03cradek 07master * r070bae39ea32 10/src/emc/rs274ngc/ (4 files): introspection: current position
[20:24:03] <cradek> I disabled the buildbot poke for now
[20:24:53] <jepler> mhaberler: what have you learned?
[20:25:08] <mhaberler> I admit my patch was bogus since it solved only half of the problem
[20:25:10] <mhaberler> the issue with the hang is: I need to get the TOOL_ABORT message to iocontrol so it gives up and deasserts the tool-change pin immediately,
[20:25:11] <mhaberler> not just terminate the busy wait loop early
[20:25:13] <mhaberler> in effect I need an out-of-band notification to iocontol
[20:25:56] <mhaberler> one way would be to queue a TOOL_ABORT message to iocontrol and have iocontrol peek into the queue so it can give up
[20:26:32] <jepler> how does estop work? Is it such an out-of-band notification?
[20:26:53] <mhaberler> iocontol checks a pin, I think.. hold on
[20:28:14] <mhaberler> yes, there's an enable pin linked to estop
[20:28:51] <mhaberler> but it should work without rsorting to that - I just understand how NML queues work well enough
[20:29:47] <mhaberler> milltask hangs for the TC to be acked by waiting for RCS_DONE and the serial number acked
[20:29:48] <mhaberler> it is unclear to me wether I can queue another msg in this state
[20:30:26] <mhaberler> I did another branch with an tool-change-abort iocontol pin and that worked fine
[20:30:42] <mhaberler> however it didnt fix the hang problem when going through python or halui.abort
[20:32:13] <mhaberler> is there a limit on number of messages in a given queue as per nml file? I just see size restriction here, but I assume thats buffer size, not number of mssgs
[20:32:33] <jepler> to be honest it sounds like you understand nml better than me
[20:32:39] <mhaberler> duh
[20:32:42] <jepler> I am not at all an expert
[20:33:50] <mhaberler> I am fairly sure if a) the queue permits it b) one just queued the TOOL_ABORT c) had iocontrol peek a message ahead it would work out
[20:34:24] <mhaberler> any experts on nml and queues I could ask? swp?
[20:36:43] <mhaberler> ok, I'll sleep over it, formulate the problem concisely in an email, maybe I get a hint
[20:36:45] <mhaberler> for now - just disregard this patch please.
[20:38:16] <dgarr> i posted an update to this patch earlier but i'm not sure it was noticed:
http://www.panix.com/~dgarrett/stuff/0001-interp-allow-comments-on-line-with-EXISTS-function.patch
[20:38:39] <jepler> dgarr: I'm also taking a stab at it
[20:39:03] <jepler> my patch takes a somewhat different approach.
http://emergent.unpy.net/files/sandbox/exists.patches.mbox
[20:39:18] <dgarr> i'm sure it's better (without even looking)
[20:39:53] <jepler> I've still got one bit of behavior I'm unsure of
[20:42:10] <jepler> ah chris points out privately that my test didn't say what I thought it said
[20:42:21] <cradek> ha
[20:42:55] <cradek> dgarr: I added a bit of introspection based on your RO parameters - it was supremely easy with that groundwork done
[20:45:54] <dgarr> another item for consideration:
http://www.panix.com/~dgarrett/stuff/0001-axis-support-embedding-tk-applications.patch
[20:47:36] <jepler> have to revise my patch a bit more. this gives the wrong error: G0 X EXISTS[#<foo]
[20:47:41] <jepler> the error given is Expected ] reading bracketed parameter
[20:47:46] <jepler> but it should be something about a missing >
[20:48:19] <cradek> bbl
[20:48:23] <psha> dgarr: _dynamic_tabs were tweaked a week ago
[20:48:38] <jepler> dgarr: I think psha is the guy to talk to about this
[20:50:21] <jepler> I think that there may be a better way to write inifindall, let me do a bit of research..
[20:54:35] <jepler> dgarr: I think you can write inifindall as
[20:54:47] <jepler> def inifindall(section, item): return tuple(inifile.findall(section, item))
[20:55:15] <dgarr> i don't know enough python to do that, any help is appreciated
[20:55:20] <jepler> when returning a Python tuple to tcl, it gets converted to a tcl list with the proper structure
[20:56:20] <psha> jepler: take a look on 'gladevcp' branch of my repo when you have a minute
[20:56:25] <jepler> also I think there's a trivial typo in the commit message. In one place TKPKG is not shown in all caps.
[20:56:28] <jepler> TKPkg Thepkg 1.0 (version 1.0 or later)
[20:57:23] <jepler> psha: can you tell dgarr what is needed to work with the latest changes to _dynamic_tabs?
[20:57:28] <psha> sure
[20:57:34] <jepler> psha: I'll take a look after I finish with EXISTS
[20:57:35] <psha> i'm working on it now :)
[20:57:39] <psha> ok
[21:07:50] <psha> dgarr: as i may see everything is ok with dynamic tabs
[21:09:47] <psha> only thing is that order of execution changed in master
[21:15:03] <CIA-60> EMC: 03jepler 07master * r11ad03a72df1 10/tests/interp/ (11 files in 2 dirs): interp: test EXISTS
[21:15:06] <CIA-60> EMC: 03jepler 07master * r7ff3f92c965c 10/tests/interp/bad/test: tests/interp/bad: run subtests in a defined order
[21:15:07] <CIA-60> EMC: 03jepler 07master * ra41de87092d1 10/tests/interp/bad/test: tests/interp/bad: no need to bail out early
[21:15:11] <CIA-60> EMC: 03jepler 07master * r4ff964ae3fe3 10/src/emc/rs274ngc/ (interp_execute.cc interp_read.cc rs274ngc_interp.hh): interp: revise EXISTS
[21:17:16] <psha> jepler: it seem that you've done with EXISTS? :)
[21:17:26] <jepler> psha: until someone discovers a problem with it
[21:17:29] <psha> sorry for being abusive but it's already night here :)
[21:17:45] <jepler> you wait for darkness to be abusive? I start as soon as I wake up.
[21:18:14] <psha> i'm busy at work now - need to write lot of pointless text
[21:18:45] <psha> so if you have a minute let me describe what's there on 'gladevcp' branch today
[21:19:45] <psha> i've added extra parameter to emc.command.wait_complete
http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp&id=1ca119d683be28d89e99c5a29819891c68f8edaf
[21:20:18] <psha> it always waiting for fixed time which makes it a bit useless in GLib based programs
[21:20:22] <jepler> psha: that's the only patch from the series I am pretty sure I understand :-P
[21:20:42] <jepler> so with wait_complete(0) it polls?
[21:20:45] <jepler> no sleep
[21:20:45] <psha> yes
[21:20:46] <mhaberler> it wont hurt a bit;-)
[21:20:50] <psha> return immidiate
[21:21:02] <jepler> that part seems fine, and the rest is your (and mhaberler's) baby
[21:21:13] <jepler> so you feel it's ready for merge?
[21:21:16] <psha> yes
[21:21:25] <mhaberler> I accept parenthood and bugtracker entries
[21:21:38] <psha> consider it as a work towards fully modular gui :)
[21:21:41] <jepler> d92fc5f Merge remote branch 'psha/gladevcp'
[21:21:41] <jepler> 41ae60a Merge branch 'gladevcp-actions4', remote branch 'mah/gladevcp-combofix' into gladevcp
[21:21:50] <jepler> ok, this commit 41ae is the right one?
[21:21:57] <psha> yes
[21:22:11] <psha> at least it's same here :)
[21:22:14] <jepler> thanks guys
[21:22:15] <CIA-60> EMC: 03jepler 07master * r1de8d54e1134 10/lib/python/gladevcp/persistence.py: persistence: fix ComboBox save/restore, cleanup
[21:22:17] <CIA-60> EMC: 03jepler 07master * r1ca119d683be 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: emcmodule: Add timeout argument to wait_complete function
[21:22:20] <CIA-60> EMC: 03jepler 07master * r6c071480b2fe 10/lib/python/hal_glib.py: hal_glib: Add GLib wrapper for emc.stat
[21:22:21] <CIA-60> EMC: 03jepler 07master * r47b9257c4152 10/lib/python/gladevcp/ (hal_actions.py hal_python.xml hal_pythonplugin.py): gladevcp: Add EMC GtkActions
[21:22:21] <CIA-60> EMC: 03jepler 07master * r41ae60a89212 10/lib/python/gladevcp/persistence.py: Merge branch 'gladevcp-actions4', remote branch 'mah/gladevcp-combofix' into gladevcp
[21:22:26] <mhaberler> appreciated!
[21:22:33] <CIA-60> EMC: 03jepler 07master * rd92fc5f5500a 10/ (6 files in 3 dirs): Merge remote branch 'psha/gladevcp'
[21:22:50] <psha> now it's possible to write simple 'axis like' stub entirely in glade :)
[21:23:38] <psha> thanks
[21:23:43] <psha> good night to all
[21:23:48] <psha> or day? :)
[21:39:20] <alex_joni> mhaberler: I think you are correct
[21:39:29] <alex_joni> you can send more than one message to the queue
[21:39:45] <alex_joni> and iocontrol can use nml->peak or whatever it's called
[21:40:25] <mhaberler> Thats how I understand queues work. I need to adapt sendCommand to do the right thing
[21:40:25] <alex_joni> but jumping from there (you can do it) to "you should do it like that" is the part I'm not so sure about
[21:40:47] <mhaberler> ;-)
[21:41:46] <mhaberler> sendCommand just backs off when it sees its serial number unacked
[21:41:48] <mhaberler> it probably just send the ioABort msg, but I'm lacking the mechanics on that
[21:42:22] <mhaberler> you worked on iocontrol, did you?
[21:44:18] <alex_joni> yup
[21:44:23] <alex_joni> a long time ago :D
[21:45:23] <mhaberler> I see
[21:45:24] <mhaberler> well I will drill this a bit and see wether I can understand how this queuing is supposed to be done
[21:45:26] <mhaberler> I mght bug you with a question
[21:45:49] <alex_joni> one thing you should check if the channel is configured as a queue or not
[21:45:51] <alex_joni> in emc.nml
[21:46:03] <alex_joni> I think I remember changing one from queue to not-queue
[21:46:10] <alex_joni> but it might have been cmd
[21:46:19] <mhaberler> ah.
[21:46:39] <alex_joni> there were some advantages, but big operability issues with doing that
[21:46:49] <mhaberler> ok,
[21:46:50] <mhaberler> otoh: where to look for .nml file semantics - source?
[21:47:15] <alex_joni> there are some docs at isd.nist.gov iirc
[21:47:22] <alex_joni> just google for rcslib
[21:47:35] <alex_joni> the RCS Handbook helps too
[21:47:37] <mhaberler> whoa, that goes back a long time
[21:47:44] <mhaberler> ok
[21:47:53] <alex_joni> I have a hard copy around somewhere
[21:47:59] <alex_joni> and SWPadnos had one iirc
[21:48:25] <mhaberler> does it exist only on paper?
[21:48:36] <alex_joni> I'm not aware of an electronic version
[21:48:49] <alex_joni> it's a book actually
[21:48:52] <mhaberler> howy cow. that needs to be scanned and published
[21:49:12] <alex_joni> http://www.amazon.com/RCS-Handbook-Control-Software-Development/dp/0471435651
[21:50:15] <mhaberler> I'll order one
[21:50:17] <mhaberler> at 100 bux, ny wsted time is more expensive
[21:51:56] <alex_joni> mhaberler:
http://www.isd.mel.nist.gov/projects/rcslib/NMLcpp.html
[21:52:03] <alex_joni> I think I got mine for 20$ or less
[21:52:07] <alex_joni> check ebay :)
[21:52:12] <mhaberler> I see
[21:52:18] <alex_joni> that link should be good to read
[21:52:31] <mhaberler> current?
[21:53:08] <mhaberler> ah. That was a document I lacked. lloks it might help
[21:54:47] <mhaberler> whoa, there's a lot on
http://www.isd.mel.nist.gov/projects/rcslib/
[21:55:20] <alex_joni> mhaberler: yup
[21:55:25] <alex_joni> they keep developing it
[21:56:12] <mhaberler> oh really
[21:56:14] <mhaberler> I had the impression that already had faded in the mists of history
[21:57:43] <mhaberler> I'll add these links to the wiki
[21:57:45] <alex_joni> mhaberler: bug me if you need to ask something, or if you want to bounce an idea off me
[21:57:58] <mhaberler> thanks, I appreciate it
[21:58:15] <alex_joni> can't promise it'll help you ;)
[21:58:47] <mhaberler> well, I have some toilet reading..
[21:59:38] <mhaberler> printer's busy..
[21:59:46] <jepler> I assume that's different than reading tea leaves
[22:00:32] <mhaberler> that I dont get, but it sounds potentially funny
[22:01:04] <mhaberler> Writing NML Configuration Files.: all there..
[22:03:39] <mhaberler> ok, that's my reading installment for the day - cu, folks
[22:04:44] <jepler> see you
[22:05:04] <alex_joni> have fun
[22:07:36] <KimK> Could one of you gurus offer a little off-topic (non-EMC) help? If I do (in terminal) "cd /home/username/long/path/name" and then "./foo" it works fine. So what do I put into the Ubuntu "Main Menu" item edit string (launcher icon) to have a menu item to do this? I've been trying variations of "/home/username/long/path/name/ source foo", and so forth, but I haven't hit the solution yet. Do I need to use quotes? Tics? Backtics? A mini-l
[22:07:36] <KimK> aunch-script? Any advice?
[22:07:41] <KimK> Oops
[22:12:36] <mhaberler> what about /home/username/long/path/name/foo
[22:15:48] <KimK> Yes, that one is interesting. The splash screen appears but the application never starts. I don't know what that's about.
[22:16:04] <mhaberler> then search the logifle.
[22:16:13] <mhaberler> logfile.
[22:19:13] <alex_joni> hmm.. depends on the file
[22:19:14] <jepler> bash -c 'cd /usr/lib/xscreensaver; ./antspotlight'
[22:19:21] <alex_joni> maybe it needs to be in that folder
[22:19:28] <alex_joni> then do what jepler just said :D
[22:19:30] <jepler> (if the program really requires the current directory to be the program's directory)
[22:19:46] <jepler> (but if it didn't then what mhaberler said would have been correct)
[22:20:59] <dgarr> jepler: i've tried to rebase and update this:
http://www.panix.com/~dgarrett/stuff/0001-axis-support-embedding-tk-applications.patch
[22:21:19] <jepler> dgarr: did my proposed inifindall work OK when you tested it?
[22:21:54] <dgarr> it causes some problems with non-replicated ini items so i had to change some things with my applications
[22:22:43] <jepler> because even a single item is now returned as a tcl list
[22:22:45] <dgarr> a singleton like Helvetica -10 bold gets returnes as {Helvetica -10 bold}
[22:22:47] <dgarr> yes
[22:23:19] <jepler> I guess I think that's the preferable behavior; otherwise, you can't tell the difference between a single item with spaces and multiple items
[22:23:47] <dgarr> i think the problem only occurs with embedded spaces, i'm ok with this
[22:28:35] <jepler> dgarr: a basic TKAPP seems to work for me
[22:28:49] <jepler> set tab [dynamic_tab embed "Embed"]
[22:28:49] <jepler> label $tab.label -text "I am embedded"
[22:28:49] <jepler> pack $tab.label -fill both -expand 1 -anchor c
[22:29:34] <jepler> thanks for the patch
[22:29:39] <dgarr> ok
[22:29:45] <CIA-60> EMC: 03jepler 07master * raf6ae9907e1c 10/src/emc/usr_intf/axis/scripts/axis.py: axis: support embedding tk applications
[22:30:35] <jepler> bbl
[22:30:39] <KimK> mhaberler: /var/log/messages has a segfault report from that app when started that way. I don't know why. jepler: Thanks, starting that way worked!
[22:30:59] <jepler> KimK: you might report the problem to the application author
[22:31:12] <jepler> more messages might be shown if you ran /home/username/long/path/name in the terminal
[22:31:33] <KimK> jepler: OK, will do
[22:31:34] <mhaberler> I dont know your 'app'
[22:31:36] <mhaberler> But I have a few segfaulters over here, want to diagnose?
[22:32:01] <dgarr> jepler: thanks and thanks for fixing EXISTS
[22:32:23] <jepler> dgarr: I was glad to
[22:45:01] <KimK> mhaberler: Thanks, but I doubt I'm enough of a developer to fix a segfault (especially in this app). BTW, thanks to you and psha for all your hard work on gladevcp and related.