Back
[02:39:34] <cwildsmith> hi everyone :)
[02:40:50] <fenn> ah - the weaver
[02:46:23] <cwildsmith> yep, that's the one... welder would be more accurate i guess :)
[02:46:59] <cwildsmith> i'm currently trying to integrate some extra functionality into the emc/axis code to allow us to implement weld arc control....
[02:47:34] <cwildsmith> anyone here with a good knowledge on how the bindings work between axis/emc/nml?
[02:48:21] <fenn> you can play around with emcsh to call nml commands directly
[02:49:01] <fenn> adding an extra nml command to axis should be pretty straightforward
[02:49:19] <fenn> i think axis links to libnml when it compiles, but not sure about that
[02:49:43] <SWPadnos> cwildsmith, do you need to use the spindle output for flame control?
[02:50:11] <SWPadnos> or could you run spindle control through your weave component ro create the weave offsets?
[02:50:16] <SWPadnos> s/ro/to/
[02:50:28] <SWPadnos> (or another axis, for that matter)
[02:52:08] <fenn> i think the nml bindings are in axis/lib/emcmodule.cc
[02:52:39] <cwildsmith> SWPadnos, i'm not sure what you mean actually? The weave is on each of the linear axis... we haven't had the requirement for it on the spindle yet...
[02:53:00] <SWPadnos> well - you don't actually use the spindle when welding, right?
[02:53:17] <SWPadnos> (or if you did, that would actually generate a weave pattern)
[03:06:06] <cwildsmith> you're right that we don't use the spindle when weaving.... however, we may well use the spindle when creating a lathe configuration that does hardfacing...
[03:07:25] <SWPadnos> ok
[03:08:04] <SWPadnos> it just seemed like it could be an easy connection into HAL, and it runs independent of the G-Code (ie, keeps at speed through multiple G-code moves)
[03:08:51] <fenn> you could use any axis as the weave amplitude
[03:09:12] <SWPadnos> other axes are coordinated though - you have to repeat the "weave axis" command on every line
[03:09:26] <fenn> you do?
[03:09:39] <fenn> just set W to 1 for "weave on"
[03:09:45] <fenn> G1 X1 W1
[03:09:54] <cwildsmith> here's a description (i'll put this on the wiki once i'm happy with it)...
[03:09:58] <SWPadnos> ah - OK.
[03:10:00] <fenn> that would make a triangular shape i guess
[03:10:23] <cwildsmith> Actually, we use an M-code M101 that sets values on our HAL configuration...
[03:10:30] <fenn> might get funny with coordinate offsets
[03:10:30] <SWPadnos> that would change to W1 over the first move, which may be OK - do a W only move
[03:10:45] <cwildsmith> that allows us to create the weave and turn it on/off from M codes...
[03:11:04] <SWPadnos> yep. there may be synchronization issues with the external M-codes though
[03:11:26] <cwildsmith> the key was getting the weave to appear on the axis front end...
[03:11:31] <SWPadnos> heh
[03:11:59] <SWPadnos> and to not cause the machine position to be different from the feedback position that motion thinks is correct
[03:12:57] <cwildsmith> exactly... we actually made changes to the emc motion controller to do that. Each axis takes into account an optional axis offset that is input from the HAL...
[03:13:07] <cwildsmith> this is where the HAL component comes in...
[03:13:22] <SWPadnos> yep - I saw that description
[03:13:56] <SWPadnos> it's a good solution, as it allows for any kind of necessary HAL-created position changes
[03:14:16] <cwildsmith> yep... hopefully is can be used elsewhere...
[03:14:28] <SWPadnos> threading, anyone?
[03:14:32] <cwildsmith> :)
[03:14:50] <cwildsmith> what is required for threading by the way?
[03:14:53] <SWPadnos> or at least adjustments to the lead-in
[03:15:07] <cwildsmith> We may well look at implementing that at some point...
[03:15:15] <SWPadnos> the main problem is in transitioning from "coordinated motion" to "spindle feedback-based motion"
[03:15:24] <SWPadnos> as I understand it
[03:15:43] <fenn> i dont really see what the problem is
[03:16:04] <cwildsmith> with the threading or weaving?
[03:16:11] <SWPadnos> there is threading code written by paul_c somewhere, but I don't know where
[03:16:18] <fenn> just sync to spindle feedback..
[03:16:28] <fenn> cwildsmith: with the threading
[03:16:37] <SWPadnos> you need to make multiple passes to cut a thread
[03:16:57] <SWPadnos> you also may be threading only a portion of the length of the workpiece
[03:17:08] <fenn> i know.. if the spindle were treated as an axis this would be relatively easy
[03:17:14] <SWPadnos> nope
[03:17:14] <cwildsmith> ok, that makes sense then.... so the spindle has to start in the same position each time....
[03:17:22] <SWPadnos> (yes, in concept, no, in detail)
[03:17:37] <cwildsmith> why can't we treat the spindle as an axis?
[03:17:44] <SWPadnos> that, plus the fact that you do a lead-in move in coordinated motion in X + Z
[03:18:03] <SWPadnos> at some point, you need to transition into feedback-based motion in X and / or Z
[03:18:23] <fenn> cwildsmith: because there's too many different ways of controlling a spindle
[03:18:29] <SWPadnos> because it always goes up - you'd need an infinitely long limit ;)
[03:19:01] <SWPadnos> you'd have an encoder count that just keeps increasing if it's treated as a normal axis
[03:19:19] <fenn> yeah yeah .. why's that such a big deal
[03:19:22] <cwildsmith> what are the ways of controlling a spindle? Speed control, position control...
[03:19:45] <SWPadnos> torque, if it's a servo
[03:19:48] <SWPadnos> as well
[03:20:00] <SWPadnos> (not that it would be common)
[03:20:16] <fenn> i dont think having to do a lead-in move in X is worth worrying about.. how many parts have threads in the middle but not on the ends?
[03:20:39] <SWPadnos> X is along the axis of the part?
[03:20:48] <SWPadnos> (just to be sure we're on the same page)
[03:20:54] <fenn> x is the diameter
[03:21:07] <SWPadnos> how about tapered threads
[03:21:34] <fenn> i dont get it.. what's the problem?
[03:21:49] <SWPadnos> X lead-in + X spindle-controlled
[03:22:02] <SWPadnos> also Z lead-in + Z spindle controlled
[03:22:28] <fenn> ok.. now you cant' satisfy the acceleration requirements of Z lead in and Z spindle sync
[03:22:33] <fenn> due to basic physics
[03:22:46] <SWPadnos> that would be a problem
[03:22:50] <fenn> you have to give yourself some maneuvering room
[03:23:09] <SWPadnos> there's also the "tail-out" (or whatever it's called
[03:23:14] <SWPadnos> )
[03:23:19] <SWPadnos> there will almost always be one of those in X
[03:23:28] <fenn> yeag
[03:23:34] <fenn> blah
[03:23:39] <SWPadnos> so it's the same problem
[03:23:56] <fenn> what's the problem?
[03:24:24] <fenn> finishing a tapered thread?
[03:24:26] <SWPadnos> well, as I understand it, it's that the normal mode of operation has time as the independent axis for motion (built into the motion controller, not in HAL)
[03:24:35] <cwildsmith> sounds like we just need to spec out the requirements as a first step?
[03:24:47] <SWPadnos> in threading, or any other axis gearing application, some feedback channel is the independent axis
[03:25:05] <SWPadnos> and you need to switch between them on the fly, with no glitches
[03:25:14] <SWPadnos> yes - specs would be nice
[03:25:33] <SWPadnos> I'm sure they exist somewhere, if only in somebody's head (or worse, multiple versions in different heads :) )
[03:25:41] <cwildsmith> :)
[03:26:14] <cwildsmith> fenn, you seem to have a reasonable understanding of the axis/emc linkage... any chance I can talk through some code with you?
[03:26:29] <fenn> er.. it's past my bedtime
[03:26:36] <fenn> i may not be very helpful
[03:26:41] <SWPadnos> (see - that's what happens when you talk about NML) :)
[03:26:46] <cwildsmith> :)
[03:27:08] <fenn> * fenn hates nml
[03:27:57] <cwildsmith> basically, I can see where everything links, except: where does the emc variable in axis.py come from? it's not declared anywhere that I can see...
[03:28:24] <SWPadnos> it comes from the emcstatus struct
[03:28:37] <SWPadnos> where they shoehorn that into python, I don't know
[03:28:58] <cwildsmith> hmm ok, because that's where i get stuck....
[03:29:03] <SWPadnos> heh
[03:29:06] <fenn> import emc
[03:29:57] <fenn> somehow that uses the bindings in emcmodule.cc
[03:30:11] <cwildsmith> ok, that's starting to make sense... and emc is a lib of some sort? I know the structs are declared in emc.hh, but i'm trying to work our where the final link is...
[03:30:41] <cwildsmith> for example, it calls "c = emc.command()"
[03:32:27] <SWPadnos> that stuff is in emcmodule.cc
[03:32:34] <cwildsmith> emcmodule.cc: {"command", T_STRING_INPLACE, O(task.command), READONLY},
[03:32:41] <SWPadnos> yep - that array
[03:32:51] <cwildsmith> is that where this command thing is coming from?
[03:32:58] <SWPadnos> I think so
[03:33:02] <SWPadnos> * SWPadnos doesn't know python
[03:33:36] <cwildsmith> that's ok, we're into c now :) (kind of)
[03:33:52] <SWPadnos> yeah - I understand the C, just not what it's meant to do ;)
[03:34:16] <fenn> look further down in the file
[03:34:27] <fenn> PyTypeObject Command_Type = {
[03:36:03] <fenn> ok so i have no idea what that does either
[03:36:08] <SWPadnos> heh
[03:36:44] <SWPadnos> I think the thing to do would be to look into how the C->Python bindings work.
[03:37:33] <SWPadnos> it's obvious that the various structs are providing interface date to the Python interpreter, but it's not obvious what the meaning of the structs is yet
[03:37:59] <cwildsmith> yep... ok, i think i'm getting there... let me just process it for a minute...
[03:38:11] <SWPadnos> have fun - I'm going to bed :)
[03:38:12] <fenn> the structs just create a python class
[03:38:21] <fenn> nite nite
[03:38:22] <SWPadnos> night all
[03:38:27] <SWPadnos> SWPadnos is now known as SWP_Away
[03:41:24] <cwildsmith> night :)
[03:45:01] <fenn> * fenn goes to bed too
[03:46:51] <Jymmm> * Jymmm short sheets fenn's bed.
[06:03:35] <LawrenceG> cradek: that new kernel seems to be running.... I have tried sim and stepper... cpu is swamped at 100% but it still responds
[06:21:44] <LawrenceG> cradek: I would have to say that a 200mhz cpu is NOT adequate for emc2 release
[07:34:29] <Jymmm> LawrenceG I have a 500MHz celeron cpu super cheap =)
[07:40:36] <Jymmm> $5 USD
[11:50:21] <lerman_> lerman_ is now known as lerman
[14:42:47] <CIA-8> 03cradek * 10emc2/tcl/bin/halconfig.tcl: updated error message to give correct instructions for installing bwidget
[14:55:35] <SWP_Away> SWP_Away is now known as SWPadnos
[15:16:48] <CIA-8> 03jepler * 10emc2/src/ (configure.in configure):
[15:16:48] <CIA-8> configure.in: chmod +x the generated items in scripts/
[15:16:48] <CIA-8> configure: regenerate
[15:19:44] <CIA-8> 03jepler * 10emc2/src/ (6 files in 6 dirs):
[15:19:44] <CIA-8> use '$(MAKE) -Cxxx yyy' instead of '(cd xxx; make yyy)'. Using $(MAKE) instead
[15:19:44] <CIA-8> of make has various advantages as described in the 'make' info pages, and using
[15:19:44] <CIA-8> -Cxxx instead of '(cd xxx; ...) means that directories that don't exist will
[15:19:44] <CIA-8> trigger an error instead of a make that eternally re-invokes itself in the same
[15:19:46] <CIA-8> directory.
[15:22:57] <CIA-8> 03jepler * 10emc2/src/configure: regenerate
[15:38:02] <CIA-8> 03swpadnos * 10emc2/tcl/bin/halconfig.tcl: Fix "watch mode" for signals.
[15:50:08] <CIA-8> 03cradek * 10emc2/src/Makefile: hide rm's warning message about these CVS directories.
[16:34:09] <CIA-8> 03jepler * 10emc2/src/Makefile: chmod +x srcipts is now done by config.status
[17:34:43] <alex_joni> jepler: hello
[17:35:00] <alex_joni> seen you moved the chmod +x from the makefile to configure
[17:35:13] <alex_joni> any particular reasons for that?
[17:36:52] <cradek> if I had to guess, it'd be because configure nukes the +x and that's irritating
[17:39:10] <alex_joni> well.. I only left it like that, because after a configure a make should always follow
[17:39:19] <alex_joni> at least for most users
[17:39:48] <cradek> I see
[17:39:56] <cradek> I wouldn't have guessed it was a feature :-)
[17:40:06] <alex_joni> but I agree for us normal developers it's a PITA
[17:40:08] <jepler> cradek's right about why I did it
[17:40:32] <alex_joni> jepler: I guess I know why you did it :)
[17:40:57] <alex_joni> I pondered how to do it .. and in the end decided to do it like that.. but I agree it was a PITA for me too
[17:42:00] <alex_joni> so I guess that it's thanks for fixing it ;-)
[18:09:09] <Jymmm> * Jymmm replaces everyones cnc controller with Folgers Coffee Crystals, Let's see if they notice...
[18:35:24] <fenn> hmmm what's that smell... did the cat pee in the cnc machine again?
[18:35:46] <Jymmm> might as well have =)
[18:45:21] <rayh> rayh is now known as rayh-away
[18:51:07] <rayh-away> rayh-away is now known as rayh
[19:38:28] <CIA-8> 03alex_joni * 10emc2/scripts/emc.in: export HALCMD for scripts that need to find the right one
[19:40:53] <CIA-8> 03alex_joni * 10emc2/tcl/bin/halconfig.tcl: maybe this will make it work better for rip
[19:55:45] <CIA-8> 03cradek * 10emc2/src/Makefile: hide this warning even better
[20:05:37] <CIA-8> 03alex_joni * 10emc2/tcl/bin/halconfig.tcl: given it some more thoughts KISS always works
[20:29:18] <CIA-8> 03rayhenry * 10emc2/tcl/bin/halconfig.tcl: fix kill error and copy var name to modify.
[23:31:24] <TorbaX> TorbaX is now known as TorbaX_at_course
[16:12:13] <cradek> it is; it's the first thing on his PATH
[16:12:21] <cradek> /home/rayh/emcdevelop/emc2/bin
[16:12:38] <SWPadnos> err - duh. I should read before I post :)
[16:13:04] <cradek> rayh: in tcl/tkemc put puts stdout "tkemc: PATH is $env(PATH)"
[16:13:12] <cradek> rayh: in tcl/tkemc put: puts stdout "tkemc: PATH is $env(PATH)"
[16:13:22] <cradek> to see if it's the same, or if it gets reset
[16:13:41] <cradek> (mine is the same)
[16:13:51] <SWPadnos> I see no export PATH ...
[16:14:07] <cradek> SWPadnos: I notice that too
[16:14:29] <cradek> SWPadnos: mine is definitely preserved over the exec
[16:14:32] <rayh> tkemc: PATH is /home/rayh/emcdevelop/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
[16:14:47] <cradek> ok, so that's not it either
[16:14:59] <cradek> so now do the same thing in halconfig.tcl
[16:16:29] <cradek> halconfig: PATH is /home/cradek/emc2/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
[16:16:38] <cradek> mine is the same in halconfig, I bet ray's is not
[16:16:59] <SWPadnos> hey - I've got no games :(
[16:18:49] <SWPadnos> as expected, it's preserved on my machine as well:
[16:18:56] <SWPadnos> tkemc: PATH is /Project/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[16:19:09] <SWPadnos> (should be halconfig, not tkemc)
[16:19:11] <cradek> ok
[16:19:13] <cradek> right
[16:21:38] <SWPadnos> rayh, is this a completely new checkout, or was it an update?
[16:24:12] <rayh> new
[16:24:16] <SWPadnos> ok
[16:24:21] <rayh> phone
[16:24:39] <SWPadnos> I'll bbiab then
[16:24:50] <rayh> Just got a second report of a failed ubuntu.
[16:25:21] <cradek> failed at what stage?
[16:25:28] <rayh> cd burner drive didn't work
[16:25:52] <rayh> Last one was not start after install.
[16:26:13] <cradek> my cd burner doesn't work either, I haven't looked into it
[16:26:27] <cradek> there's probably something at ubuntu.com if it's a common problem.
[16:27:07] <rayh> Okay. I'll look around there a bit.
[16:27:21] <rayh> I went back to bin/halcmd and that works fine.
[16:27:30] <rayh> so I can work.
[16:28:11] <cradek> assuming the problem is only on your machine, that's fine I guess. I'm not sure it is though.
[16:29:23] <rayh> No I suspect that whatever scripts/emc is attempting to do to path doesn't always work.
[16:29:37] <cradek> then we should figure out why
[16:40:36] <SWPadnos> I can burn CDs on my SATA CD/DVD burner, under ubuntu
[16:40:52] <SWPadnos> haven't tried burning a DVD yet, though I have ripped one
[16:41:11] <cradek> SWPadnos: I have two CD drives, so maybe that's my problem
[16:41:20] <SWPadnos> could be
[16:41:25] <cradek> SWPadnos: I tried for only about 10 seconds to fix it
[16:41:29] <SWPadnos> only one is a burner, presumably
[16:41:30] <SWPadnos> heh
[16:41:33] <cradek> yes
[16:42:01] <SWPadnos> I do have problems with either k3b or gnomeburner, though I don't recall which at the moment
[16:42:14] <SWPadnos> or whatever the gnome tool is called
[16:50:52] <rayh> cradek: Thanks for the note on sig in halconfig. Got that watch fixed.
[16:51:15] <SWPadnos> did it need fixing after the fix I did?
[16:53:21] <rayh> It was only changing the led for pin and param
[16:53:49] <SWPadnos> right. I moved a '}' and it worked
[16:54:04] <SWPadnos> you had probably already checked out when I checked that in
[16:55:13] <rayh> Okay. I guess I missed that.
[16:55:25] <rayh> I'm seeing now that modify doesn't work at all.
[16:55:35] <SWPadnos> grape rinds think alike
[16:55:38] <SWPadnos> or something like that
[16:55:38] <rayh> Looks like I lost my last version.
[16:55:54] <rayh> dere ya go eh.
[16:56:31] <SWPadnos> I get something that looks right for modify, but I can't see that it does the actual command
[16:57:41] <SWPadnos> is there an easy way to tell if a clicked node is a leaf (has no child nodes)?
[16:57:46] <rayh> Clciking on entries doesn't work
[16:58:15] <SWPadnos> hmmm - can you walk me through what you're doing?
[16:58:21] <rayh> It looks through the list of nodes and if it finds your click it calls you stupid and suggests clicking again.
[16:58:52] <SWPadnos> oops - I was thinking of tune mode, not modify mode
[16:59:09] <rayh> I didn't see your fix in the commit on #emc
[16:59:28] <SWPadnos> CIA-8swpadnos * emc2/tcl/bin/halconfig.tcl: Fix "watch mode" for signals.
[16:59:33] <SWPadnos> at 10:38 my time (EST)
[17:00:10] <SWPadnos> it's only 4 or 5 lines ago, actually
[17:01:14] <rayh> It's in the code.
[17:01:29] <SWPadnos> ok
[17:02:56] <rayh> I'm kinda up sxxt creek here. I have to edit halcmd to bin/halcmd
[17:03:11] <rayh> but then if I edit and commit you guys are wrong.
[17:04:09] <cradek> let's continue debugging that then.
[17:04:18] <SWPadnos> can you try adding a line like puts stdout [exec which halcmd]
[17:04:47] <cradek> good idea, that shows the path
[17:04:57] <SWPadnos> or nothing
[17:05:22] <SWPadnos> so maybe puts stdout "Halcmd is [exec which halcmd]"
[17:05:35] <SWPadnos> (+/ some appropriate punctuation)
[17:07:15] <rayh> Error in startup script: child process exited abnormally
[17:07:18] <rayh> while executing
[17:07:18] <rayh> "exec which halcmd"
[17:07:51] <SWPadnos> but the path echo still showed emc2/bin, right?
[17:08:00] <cradek> he never did a path echo in halcmd
[17:08:08] <cradek> err halconfig
[17:08:24] <SWPadnos> ah
[17:08:56] <rayh> I don't see what the "which" is attempting to do.
[17:09:09] <cradek> I don't think which is even in your path
[17:09:16] <SWPadnos> tell us what will get executed if you run halcmd
[17:09:31] <SWPadnos> which probably is, but it may return an error (and print nothing) if the program isn't found
[17:09:32] <cradek> stick that same puts (like we put in tkemc) into halconfig please
[17:09:35] <rayh> an error message.
[17:10:08] <rayh> Error in startup script: child process exited abnormally
[17:10:08] <rayh> while executing
[17:10:08] <rayh> "exec which halcmd"
[17:10:13] <SWPadnos> these two lines in halconfig:
[17:10:15] <SWPadnos> puts stdout "halconfig: PATH is $env(PATH)"
[17:10:16] <SWPadnos> puts stdout "halconfig: halcmd is [exec which halcmd]"
[17:10:22] <rayh> I'm a bit lost here now.
[17:10:31] <SWPadnos> give me this output:
[17:10:33] <SWPadnos> halconfig: PATH is /Project/emc2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[17:10:35] <SWPadnos> halconfig: halcmd is /Project/emc2/bin/halcmd
[17:10:43] <rayh> I can not start halconfig
[17:11:05] <cradek> I'm lost too then
[17:11:15] <SWPadnos> is halconfig not found, or does it exit because it can't find halcmd?
[17:11:52] <rayh> How would you like me to attempt to start halconfig?
[17:12:01] <cradek> from the tkemc menu
[17:12:07] <rayh> from tkemc or from a terminal?
[17:12:15] <SWPadnos> ok - that's the problem. you can't run halconfig from the command line
[17:12:21] <cradek> we're trying to figure out what happens to your PATH in the emc->tkemc->halconfig chain
[17:12:33] <SWPadnos> it has to be run with the environment that scripts/emc sets up
[17:12:39] <cradek> you haven't been running it from the menu?
[17:13:10] <rayh> That time it started.
[17:13:10] <SWPadnos> right - I get the same problem when run from the terminal
[17:13:11] <SWPadnos> localhost:/Project/emc2# tcl/bin/halconfig.tcl
[17:13:12] <SWPadnos> halconfig: PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
[17:13:14] <SWPadnos> Error in startup script: child process exited abnormally
[17:13:15] <SWPadnos> while executing
[17:13:17] <SWPadnos> "exec which halcmd"
[17:13:18] <SWPadnos> invoked from within
[17:13:20] <SWPadnos> "puts stdout "halconfig: halcmd is [exec which halcmd]""
[17:13:21] <SWPadnos> (file "tcl/bin/halconfig.tcl" line 25)
[17:13:36] <rayh> Hell no I don't start it from emc. I want to see what it does.
[17:13:58] <SWPadnos> heh - well, I think we know what the problem is now :)
[17:14:01] <rayh> Shit Halconfig is supposed to be much bigger than a tool under a single menu in
[17:14:06] <cradek> oh for fucks sake
[17:14:14] <rayh> It didn't start a bit ago from that same menu
[17:14:36] <SWPadnos> the changes to make it work from the menu fubared it for plain old shell execution
[17:14:48] <rayh> What we are saying is that halconfig now needs something from tkemc
[17:15:09] <SWPadnos> more accurately, from scripts/emc
[17:15:23] <rayh> Could it get that as easily from setupconig.tcl
[17:15:31] <rayh> I could live with starting it from there.
[17:15:49] <SWPadnos> we'll have to add some checks for the env vars, and default to bin/halcmd if not found
[17:16:12] <rayh> But that won't work on an installed system.
[17:16:39] <rayh> Oh and setupconfig also strips all the return info.
[17:17:15] <SWPadnos> would you expect someone to just run halconfig on an installed system, not from within emc?
[17:17:18] <cradek> rayh: just set your PATH if you want to run it from the shell. Alex's change works perfectly.
[17:17:27] <cradek> SWPadnos: I wouldn't.
[17:17:57] <cradek> rayh: env PATH=$PATH:./bin tcl/bin/halconfig.tcl
[17:18:09] <rayh> Not meaning to be a mule here but that doesn't help end users.
[17:18:27] <cradek> end users will run it from the menu.
[17:18:32] <rayh> bs
[17:18:36] <SWPadnos> do you think that end users with installed systems will need to run halconfig from the shell?
[17:18:52] <rayh> not if they are building a HAL the way jmk told elson to do last sunday.
[17:19:12] <rayh> coffee brb
[17:19:16] <cradek> elson is a developer
[17:19:26] <SWPadnos> actually, they might - it seems reasonable to run emc from an icon, then run halconfig from either another icon, or a separate terminal
[17:19:27] <cradek> I thought you were writing halconfig for users to use, so they don't have to do that
[17:19:59] <cradek> more coffee is a good idea (I'll get decaf)
[17:20:15] <SWPadnos> eeewwww - decaf
[17:20:39] <cradek> it's not as good but I don't have to worry about drinking 9 cups of it
[17:20:51] <rayh> hehe
[17:21:00] <SWPadnos> dddrrriinnnkkiinngg ccooffffeeeee
[17:21:10] <cradek> you think I'm pissy now
[17:21:14] <SWPadnos> heh
[17:21:42] <rayh> I guess we do need some additional discussion of how the parts fit together
[17:22:25] <SWPadnos> yep
[17:22:25] <rayh> If halconfig is run from tkemc or mini then I don't need any of the testing stuff at the start.
[17:22:37] <SWPadnos> (or axis hint hint)
[17:22:52] <rayh> and eric would never have gotten the message he reported this morning.
[17:23:14] <SWPadnos> which- the BWidget thing?
[17:23:24] <rayh> I guess bwidget test would be there yet.
[17:23:33] <alex_joni> * alex_joni is back
[17:23:34] <rayh> but no winders
[17:23:42] <rayh> no is rtai up
[17:23:57] <rayh> or is hal running
[17:24:22] <cradek> rayh: if he had used my debian packages, bwidget would already have been installed as a dependency.
[17:24:23] <rayh> That last one got broke with some of the changes to setupconfig recently anyway.
[17:24:42] <rayh> Right but I think he has a fedora or some such hat.
[17:25:51] <rayh> so first question, where does halconfig fit, if it fits.
[17:28:40] <SWPadnos> I don't think it's useful for end users unless there's a running emc/HAL
[17:29:03] <SWPadnos> I think it is useful to be able to run it "manually" - ie, not only from an emc GUI menu
[17:32:34] <alex_joni> SWPadnos: so what's stoping you?
[17:32:43] <rayh> and the easy way to accomplish both is to tell the guy who wants to run it manually to edit his path var.
[17:33:11] <alex_joni> that's automatically done for installed systems, as halcmd is already in /usr/bin
[17:33:23] <alex_joni> or similar (/usr/local/bin)
[17:33:41] <SWPadnos> ok - so it should only be a developer using run-in-place that has any issues
[17:33:49] <alex_joni> for the run-in-place system it's hard to put ./bin permanently to PATH, and that might be problematic
[17:34:03] <alex_joni> SWPadnos: right, if he's not running it from tkemc
[17:34:17] <alex_joni> or for what I care using loadusr from hal
[17:34:34] <alex_joni> just like we run halscope for sim
[17:35:36] <SWPadnos> ok, so the danger is if there's an installed version, and you're doing development - that'll prefer the installed version over the RIP version, when run from the shell
[17:36:12] <alex_joni> yes, but an installed halcmd should work just fine with a run-in-place rest
[17:36:32] <SWPadnos> depends on what's changing
[17:36:35] <alex_joni> except when you do serious redesign on halcmd
[17:36:40] <SWPadnos> but most likely true
[17:37:10] <SWPadnos> actually, a single change to the HAL data would screw up an installed halcmd
[17:37:43] <SWPadnos> s/would/could/
[17:39:09] <rayh> SWPadnos: Could you explain that last a bit?
[17:42:24] <alex_joni> rayh: if you have 2 parts of a software using the same data defines
[17:42:34] <alex_joni> and you have one part linked and installed
[17:42:35] <SWPadnos> well - if the HAL data changes, for instance we add a new variable to the pin struct (like a unique ID), then an installed halcmd wouldn't know about it, and things would get messy
[17:43:09] <alex_joni> and afterwards you change the data definitions (only slightly is enough), and compile the second part of the software, those two will never work 100% ok together
[17:43:17] <rayh> I thought halcmd querried a running hal.
[17:43:27] <alex_joni> yes, using some predefined commands
[17:43:32] <alex_joni> that go through shm
[17:43:49] <SWPadnos> it does, but it looks at the HAL structures directly - the definitions have to match betwen halcmd and the running HAL
[17:44:10] <alex_joni> but if jmk decides he should add another command, and that command shifts half of the existing with 1 step, then querying for pin might get you param
[17:44:14] <SWPadnos> if you have a run-in-place version with different structures, and you end up running an installed halcmd, boom!
[17:44:14] <rayh> But it does not behave the same in the installed version as it does in rip.
[17:44:16] <alex_joni> or something lots worse
[17:44:29] <alex_joni> it's not a matter of behave
[17:44:39] <alex_joni> it's a matter of data consistency
[17:44:57] <SWPadnos> command parsing isn't an issue, unless the meaning of a comand changes (like PIN now means PARAM)
[17:45:03] <rayh> In my rip, I can start demo or realtime and add stuff.
[17:45:28] <rayh> start new modules, delete and change old modules
[17:45:29] <alex_joni> what are demo and realtime?
[17:45:36] <rayh> scripts
[17:45:37] <SWPadnos> I was thinking ahead to the person (possibly a developer) who has an installed version, and is testing a new vbersion of emc2
[17:45:59] <alex_joni> rayh: ok
[17:46:14] <SWPadnos> if they run from a shell instead of a menu, then the installed halcmd will be in the path, so even if you check inside halconfig for a valid hapcmd, you may end up finding the wrong one
[17:46:19] <alex_joni> anything you do in rip, works for the installed system just the same
[17:46:40] <SWPadnos> but anything in the installed system may not work the same in rip, due to path issues
[17:46:49] <alex_joni> SWPadnos: that can be overcome, but testing for a file in path is very messy in tcl
[17:47:06] <alex_joni> SWPadnos: how do you mean that?
[17:47:19] <SWPadnos> actually, I think you want to test for an env var (like EMC2_something), and use bin/halcmd if the var doesn't exist
[17:47:38] <SWPadnos> but that doesn't work for installed systems - darn
[17:47:48] <alex_joni> why not?
[17:47:58] <SWPadnos> installed components are in the path, so will be sulently used, even if yuo
[17:48:07] <alex_joni> that is how the realtime script gets found
[17:48:09] <SWPadnos> installed components are in the path, so will be sulently used, even if you're trying a new version as RIP
[17:48:12] <SWPadnos> silently
[17:48:23] <alex_joni> they shouldn't
[17:48:33] <alex_joni> c'mon this is not that hard..
[17:48:34] <SWPadnos> if you try to run from the shell ...
[17:48:43] <alex_joni> in that case yes
[17:48:57] <alex_joni> but that's only because halconfig.tcl doesn't know how it's run
[17:49:06] <alex_joni> at least doesn't right now
[17:49:07] <SWPadnos> that's the problem - it's pretty reasonable to expect that you can run halconfig from something other than an emc gui
[17:49:23] <alex_joni> the runscript knows where it's run from (rip or install)
[17:49:35] <SWPadnos> and it's necessary if you use azis, since you can't run halconfig from within axis at the moment
[17:49:46] <SWPadnos> axis - not azis
[17:50:09] <alex_joni> ok, so then we go back and have halconfig run ONLY from emc2/ (no other location is valid)
[17:50:19] <alex_joni> if bin/halcmd is there it uses that
[17:50:30] <alex_joni> otherwise it assumes installed version and checks in path
[17:50:32] <SWPadnos> that's what I'm trying to think through - what's reasonable, and how to accomplish it
[17:51:21] <rayh> If we have issues with the editing that halconfig can do to a running HAL, then we should trash halconfig.
[17:51:39] <alex_joni> how do you mean editing ?
[17:52:02] <rayh> halconfig can loadrt unloadrt
[17:52:09] <alex_joni> right
[17:52:13] <SWPadnos> that's necessary
[17:52:20] <alex_joni> but all those are halcmd calls
[17:52:20] <rayh> which means that it can do most any mod to HAL
[17:52:31] <SWPadnos> I don't think we're talking about what halconfig does, just how to make it possible for it to work in all necessary cases
[17:52:33] <alex_joni> I thought that's what it's supposed to do
[17:52:46] <alex_joni> it's just a matter of finding halcmd (the right halcmd)
[17:53:01] <alex_joni> we're not talking about changing any functionality of halconfig nor halcmd
[17:53:12] <rayh> I don't understand finding the right halcmd?
[17:53:32] <SWPadnos> if I run emc using axis, halconfig isn't available from a menu
[17:53:44] <rayh> Okay
[17:53:44] <SWPadnos> so I run a separate shell for halconfig (like you were doing)
[17:53:45] <alex_joni> rayh: if a user someday will have an installed emc AND a run-in-place version, halconfig might be confused and run the installed halcmd (because it's in PATH)
[17:53:59] <SWPadnos> but it can't find halcmd, because it's expecting it to be in the PATH
[17:54:11] <SWPadnos> which it isn't (thankfully, since I have no installed emc2 on this machine)
[17:54:21] <rayh> halconfig works on a "running" hal
[17:54:29] <SWPadnos> exactly
[17:54:37] <rayh> so it matters not where it exists or is run from
[17:54:39] <alex_joni> rayh: sure but to work on a running hal it needs to talk to halcmd
[17:54:59] <alex_joni> if halconfig.tcl can't execute halcmd.. it won't matter if HAL is running or not
[17:55:08] <alex_joni> agreed?
[17:55:39] <rayh> true. but I don't see how a halcmd in /bin or /sbin or wherever makes any difference between halcmd and HAL.
[17:55:40] <SWPadnos> and it has to be the correct one - either "bin/halcmd", or halcmd from the path
[17:55:51] <rayh> only that halconfig doesn't know where to find it.
[17:55:52] <SWPadnos> if you checkout a new version of emc2
[17:55:55] <alex_joni> rayh: let's step back a bit
[17:56:04] <alex_joni> SWPadnos: let me try to exaplain for a while
[17:56:13] <SWPadnos> ok
[17:56:33] <rayh> * rayh falls silent
[17:56:49] <alex_joni> rayh: I'm trying to build a scenario, try to say if you don't follow me
[17:56:59] <alex_joni> 1. user gets ubuntu with emc2 deb packages
[17:57:12] <alex_joni> halcmd is installed in /usr/bin
[17:57:25] <alex_joni> halconfig.tcl is in /usr/share/emc/tcl/halconfig.tcl
[17:57:42] <alex_joni> user starts tkemc -> runs halconfig from the menu (works OK)
[17:57:57] <alex_joni> user start axis -> runs halconfig from the shell (works OK)
[17:58:06] <alex_joni> so far everything is as it should be
[17:58:08] <rayh> ??
[17:58:22] <SWPadnos> installed system, not run in place
[17:58:40] <rayh> but how does a users start halconfig.
[17:58:41] <alex_joni> rayh: something not clear?
[17:59:13] <rayh> terminal and enter sudo /usr/share/emc/tcl/halconfig.tcl
[17:59:16] <rayh> ??
[17:59:22] <alex_joni> without sudo
[17:59:24] <alex_joni> but yes
[17:59:53] <alex_joni> or he might even have an icon on his desktop that's reading halconfig for what he cares
[17:59:55] <rayh> no sudo because halcmd has setuid root
[18:00:01] <alex_joni> exactly
[18:00:42] <alex_joni> is it ok so far? can I move on?
[18:01:01] <rayh> sure
[18:01:30] <alex_joni> ok, now the user hears about a fancy new improvement in emc2 and wants to try it out, before he installs over his runing emc2
[18:01:49] <alex_joni> so he gets emc2 and puts it in /home/aunt_tillie/emc2/
[18:02:26] <alex_joni> now /home/aunt_tillie/emc2/bin/halcmd and /home/aunt_tillie/emc2/tcl/bin/halconfig.tcl are the ones we care about
[18:03:18] <rayh> why should we care.
[18:03:32] <rayh> unless these two files have changed?
[18:03:35] <alex_joni> when the user start emc (the rip one), and runs halconfig from the tkemc menu, the runscript already added /home/aunt_tillie/emc2/bin to PATH so halconfig.tcl will use /home/aunt_tillie/emc2/bin/halcmd
[18:03:45] <alex_joni> exactly that is the case we worry about
[18:04:11] <alex_joni> if the user has emc2.0.0 installed, but tries emc2.3.5 out (say 2 years newer)
[18:04:36] <alex_joni> halcmd & HAL is very likely to have changed in the meantime.. agreed?
[18:04:53] <rayh> okay
[18:05:11] <alex_joni> so if you run in place, it's absolute MUST that you use only run-in-place files
[18:05:35] <alex_joni> it's a bad idea to end up running HAL from rip, and halcmd from the installed (2 years older) emc2
[18:05:37] <rayh> so why not pid in tcl
[18:05:44] <alex_joni> pid?
[18:05:51] <rayh> pwd
[18:06:19] <alex_joni> well.. my main problem is that I know too little tcl to do that properly
[18:06:49] <alex_joni> but running `pwd`/bin/halcmd from tcl is not the answer
[18:07:02] <rayh> In a run in place system, tcl/bin and bin/ are the essential locations?
[18:07:14] <alex_joni> yes
[18:07:26] <rayh> is pwd emc2?
[18:07:30] <alex_joni> somehow, also scripts/realtime is used
[18:07:32] <SWPadnos> the pwd is the config dir
[18:07:32] <rayh> or is it scripts
[18:07:39] <alex_joni> pwd is where you run it from
[18:07:47] <SWPadnos> not in halconfig
[18:07:51] <rayh> In emc pwd was always emc
[18:07:57] <alex_joni> the emc runscript can be run from anywhere it shouldn't matter
[18:08:12] <SWPadnos> adding 'puts stdout "halconfig: Working Directory is [exec pwd]" ' to halconfig
[18:08:25] <SWPadnos> gives this: "halconfig: Working Directory is /Project/emc2/configs/SWP_ppmc"
[18:08:26] <alex_joni> you can run scripts/emc OR cd scripts && ./emc OR cd src && ../scripts/emc , etc
[18:08:41] <SWPadnos> run from tkemc
[18:08:42] <alex_joni> SWPadnos: if you run it from the GUI
[18:08:43] <rayh> And IMO you shouldn't be able to do that.
[18:09:04] <alex_joni> rayh: how do you expect to keep track of the installed version then?
[18:09:26] <rayh> * rayh doesn't want to keep track of installed...
[18:09:29] <alex_joni> there is no emc2/ anymore
[18:09:34] <rayh> excuse me for saying that.
[18:09:42] <alex_joni> yes I know you don't ;) but users want that
[18:09:56] <rayh> users want a machine to start up and work;
[18:10:06] <rayh> but another day for that.
[18:10:07] <alex_joni> rayh: you're forgiven, it's not the most pleasant thing to debug
[18:10:23] <SWPadnos> users want the nifty ubuntu "updates available" icon to tell them when there's a new version of emc2 as well
[18:10:36] <rayh> In a rip. is it possible to make a "run from here" directory.
[18:10:36] <alex_joni> agreed to both of you
[18:10:44] <SWPadnos> and that happens automagically with installed debs
[18:10:53] <alex_joni> rayh: you shouldn't need that
[18:11:03] <alex_joni> you can still go to emc2/ and run from there
[18:11:04] <rayh> Not the two users that ripped me a new one on the phone about ubuntu.
[18:11:12] <alex_joni> ripped?
[18:11:25] <SWPadnos> complained aggressively ;)
[18:11:25] <rayh> That doesn't satsify my need.
[18:11:31] <alex_joni> how so?
[18:12:22] <SWPadnos> what are your needs?
[18:12:26] <rayh> Is it possible to say in a rip, "you will always run from emc2
[18:12:43] <alex_joni> you can say that
[18:12:49] <rayh> so that we always have a known file system relationship.
[18:13:44] <rayh> I take that as a no... not possible.
[18:13:55] <alex_joni> the file system relationship
[18:14:04] <alex_joni> is already well known
[18:14:32] <alex_joni> but when adding install support we changed the default location to run everything from
[18:14:59] <alex_joni> the config dir is now the place where stuff gets run from (because of a lot of reasons)
[18:15:15] <alex_joni> so the runscript goes there first, then does it's thing
[18:15:27] <alex_joni> so it actually doesn't matter where you run it from
[18:15:47] <alex_joni> but the runscript posesses the knowledge you were talking about "the known file system relationship"
[18:16:07] <rayh> It does if I'm trying to find halcmd or trying to figure out where to put the saved version of HAL.
[18:16:26] <alex_joni> where would you put the saved version of HAL?
[18:17:15] <alex_joni> IMO the best place would be in the config dir for the current setup
[18:17:15] <alex_joni> up
[18:18:42] <rayh> I just save without worry about where.
[18:18:53] <alex_joni> say I'm running the univpwm config, if I start halconfig and want to edit soemthing then I expect halconfig to save in configs/univpwm not anywhere else
[18:18:56] <rayh> so my only problem is where is halcmd?
[18:19:24] <alex_joni> rayh: we coudl do it like this: the rip user MUST run from emc2/
[18:19:34] <alex_joni> then halconfig looks for bin/halcmd
[18:19:39] <rayh> small issue with a start from scratch hal but go ahead.
[18:19:56] <alex_joni> if it's not found then it looks in path, and assumes installed version
[18:20:45] <alex_joni> does tcl have a way to know from where halconfig was run?
[18:21:02] <alex_joni> saying you are in /home/ray/emc2 and run tcl/bin/halconfig.tcl
[18:21:17] <rayh> pwd
[18:21:25] <alex_joni> does halconfig have a way to find out /home/ray/emc2/tcl/bin/halconfig.tcl ?
[18:21:30] <rayh> will return the current directory
[18:21:40] <alex_joni> pwd + $0
[18:21:59] <alex_joni> $0 is usually the complete executed name
[18:22:16] <alex_joni> at least that's true for bash scripts, and executables (binaries)
[18:22:38] <SWPadnos> $0 doesn't exist in tcl
[18:22:42] <SWPadnos> (I tried it)
[18:23:01] <alex_joni> in tcl no, but there is a bash that runs before wish gets called
[18:23:04] <alex_joni> we can use that
[18:23:24] <SWPadnos> I thikn $0 in bash is the actual name used to run the command, without the path
[18:23:35] <SWPadnos> unless the full path was typed at the command line
[18:23:36] <alex_joni> it's the whole name
[18:23:39] <rayh> exec /usr/bin/wish "$0" "$@"
[18:23:47] <rayh> Is the default way of starting wish
[18:24:14] <alex_joni> yes I know ray
[18:24:23] <alex_joni> but before that we can do any number of bach lines
[18:24:26] <alex_joni> bash even
[18:24:39] <alex_joni> SWPadnos: this is what I put in emc:
[18:24:42] <alex_joni> # 1.3.1. Determine if we have run-in place or installed system
[18:24:42] <alex_joni> # by looking of where the script was run from
[18:24:42] <alex_joni> SCRIPT=`which $0 | grep $0`
[18:24:42] <alex_joni> echo "SCRIPT=$SCRIPT" >>$PRINT_FILE
[18:24:42] <alex_joni> #get the script name
[18:24:44] <alex_joni> SCRIPTNAME=`echo $SCRIPT | sed s#\^.\*/##`
[18:24:47] <alex_joni> #and the path
[18:24:49] <alex_joni> echo "SCRIPTNAME=$SCRIPTNAME" >>$PRINT_FILE
[18:24:52] <alex_joni> SCRIPTDIR=$(dirname $SCRIPT)
[18:24:55] <alex_joni> SCRIPTDIR=$(cd $SCRIPTDIR ; pwd -P)
[18:24:57] <alex_joni> echo $SCRIPTDIR >>$PRINT_FILE
[18:26:19] <alex_joni> the idea is this: get the bash on top of halconfig.tcl figure out if it's installed or rip, and set an ENV accordingly
[18:26:38] <alex_joni> inside tcl (wish), you can read that ENV and use paths accordingly
[18:27:02] <SWPadnos> ok
[18:27:34] <alex_joni> does that sound ok?
[18:28:01] <SWPadnos> it may - I'm no shell guru)
[18:28:17] <alex_joni> cradek is ;)
[18:28:58] <rayh> * rayh realizes his old ways don't fit in this world.
[18:29:52] <alex_joni> rayh: the problem is we are trying to make it perfect
[18:29:54] <alex_joni> ;-)
[18:30:23] <alex_joni> and that complicates things a bit
[18:31:48] <alex_joni> so it's rather a let's think of all the scenarios that might appear in the future, rather than make it just work and move on, and worry later
[18:32:02] <rayh> okay. I guess I'll just have to wait for a solution that is way beyond my ability.
[18:32:24] <rayh> What I have been doing is starting an emc2
[18:32:28] <alex_joni> you'll see it's not a very complicated one..
[18:33:02] <rayh> then from the same directory pointing to tcl/bin/halconfig or setupconfig and working from a terminal]
[18:33:14] <rayh> That way I can see what errors tcl kicks up.
[18:33:32] <rayh> Now if I try to do this with setupconfig, it doesn't start right
[18:33:53] <rayh> if I start setupconfig from scripts/emc
[18:34:12] <rayh> I don't get any error messages from tickle
[18:34:12] <alex_joni> if you run from tkemc, the errors end up on the same terminal from where you started
[18:34:27] <alex_joni> start a terminal, go to emc2/
[18:34:31] <alex_joni> run scripts/emc
[18:34:54] <alex_joni> select a config with tkemc (stepper for example), then run halconfig from the menu
[18:35:11] <rayh> Nope cause the run scripts strips em all.
[18:35:11] <alex_joni> you'll see halconfig error messages along with normal emc debug
[18:35:21] <rayh> nothing here.
[18:35:40] <alex_joni> what messages do you usually get?
[18:35:49] <rayh> The only thing scripts/emc wants to see is the name of the ini to execute.
[18:36:22] <alex_joni> are we still talking about halconfig?
[18:37:10] <rayh> I think so. It was a few days ago when I found that problem.
[18:37:53] <alex_joni> halconfig != setupconfig
[18:38:59] <rayh> Right but interrelated them a while back.
[18:39:28] <alex_joni> oh ok, I got confused
[18:39:52] <rayh> np. you have not got near the confusion that I have now.
[18:40:08] <alex_joni> it is true that scripts/emc doesn't expect setupconfig to return anything but the config name
[18:41:54] <rayh> I don't see any easy way from within halconfig, to say I'm rip or I'm installed.
[18:42:08] <rayh> Unless there were a standard place from which installed started.
[18:42:35] <alex_joni> well the point of make install is not to make it standard
[18:42:38] <SWPadnos> or a standard place where you can find the version of emc that's running (like /var/emc)
[18:42:47] <alex_joni> because different distro's have different policies
[18:43:00] <alex_joni> what is mandatory on debian is NOT allowed on redhat, and so on
[18:43:02] <SWPadnos> containing something like /usr/emc or /home/rayh/emc2
[18:43:05] <rayh> Right. So I'm completely lost as to how to help.
[18:43:25] <alex_joni> rayh: wait 30 mins, I'll boot my ubuntu up, and you can help with tcl stuff.. ok?
[18:43:58] <rayh> I can try.
[18:44:04] <alex_joni> thx
[18:44:31] <rayh> Thank you.
[18:44:51] <alex_joni> 2 minutes
[18:45:05] <SWPadnos> that was a quick 28 minutes ;)
[18:45:11] <rayh> * rayh must get out of the emc business.
[18:45:21] <rayh> rayh is now known as rayh-away
[18:45:23] <SWPadnos> or get much better pay :)
[18:47:49] <alex_joni> * alex_joni is back on ubuntu
[18:51:06] <rayh-away> rayh-away is now known as rayh
[18:52:11] <alex_joni> ok, started to look at it
[18:52:46] <alex_joni> rayh: can you start thinking about how to handle the 2 variants if you have an ENV saying rip or install?
[18:53:45] <alex_joni> not much different just to run bin/halcmd vs. halcmd
[18:53:47] <rayh> The installed is handled. exec halcmd does that.
[18:54:22] <SWPadnos> can you just make an env var HALCMD, that has either 'bin/halcmd' or 'halcmd'?
[18:54:32] <alex_joni> SWPadnos: or better absolute path
[18:54:38] <SWPadnos> sure
[18:54:39] <alex_joni> yes
[18:54:42] <rayh> if {$rip = "rip"} {exec bin/halcmd}
[18:54:53] <alex_joni> ray: exec $HALCMD
[18:55:01] <SWPadnos> just replace all the exec hal;cmd with exec $HALCMD
[18:55:09] <SWPadnos> what he said
[18:55:26] <SWPadnos> set HALCMD $env(HALCMD)
[18:55:59] <alex_joni> SWPadnos: I can take care of that much tcl
[18:56:03] <SWPadnos> heh
[18:56:09] <alex_joni> rayh: give me a few minutes for testing, and I'll commit
[18:56:40] <rayh> k
[18:57:02] <SWPadnos> ray - do you get the messages like "inifind is depreciated" and the like?
[18:57:18] <rayh> sometimes I do.
[18:57:20] <alex_joni> yeah, that's paul's message
[18:57:34] <alex_joni> there are 2 versions of iniFind
[18:57:58] <alex_joni> one c++ (is ok), one c (linked from halcmd) which supposedly is depreciated
[18:58:01] <SWPadnos> it should be there every time - I was just thinking about you mentioning that you get no messages (from halconfig) in the terminal
[18:58:09] <SWPadnos> deprecated, but anyway ;)
[18:58:18] <alex_joni> but the main problem with it is that it's linked to halcmd :))
[19:01:13] <rayh> I seem to have both tkemc and halconfig twisted up. I'll reinstall.
[19:05:29] <rayh> oops I see a change to make. If I go away it's cause it crashed.
[19:05:43] <alex_joni> rayh: btw, I'm getting errors that killHalConfig doesn't exist
[19:06:29] <rayh> make: [clean] Error 1 (ignored)
[19:09:35] <alex_joni> rayh: that isn't a very usefull message
[19:09:41] <alex_joni> try a few more lines bfore that
[19:10:34] <rayh> Sorry long gone now.
[19:10:49] <rayh> It was in the midst of rm -f
[19:11:07] <rayh> The new does start up okay.
[19:15:11] <rayh> killHalConfig should be about line 259.
[19:15:42] <alex_joni> way after initializeConfig (at line 181)
[19:16:14] <alex_joni> but initializeConfig calls killHalConfig in case user presses Cancel at the question if he wants to start HAL
[19:20:22] <rayh> Shouldnt be a problem because initializeConfig isn't called until very late in the program.
[19:20:41] <alex_joni> it's the first called if I'm reading this correctly
[19:20:43] <rayh> Don't know why your's should raise an error. there.
[19:20:43] <alex_joni> line 181
[19:21:52] <rayh> here 181 is in the midst of comment.
[19:22:11] <alex_joni> #run the init test process
[19:22:17] <alex_joni> initializeConfig
[19:22:19] <alex_joni> #
[19:22:31] <alex_joni> #---------------end of environment tests -------------
[19:22:33] <rayh> I see 151 being a call to killHalConfig
[19:24:08] <rayh> Are you getting the error if the initializeConfig script fails to find a working system?
[19:24:53] <alex_joni> yes
[19:25:01] <alex_joni> I get a window with 3 buttons
[19:25:08] <alex_joni> if I push cancel I get an error
[19:25:38] <alex_joni> HAL is not loaded, Yes, No, Cancel
[19:25:42] <rayh> Okay. Let me move that call to initializeConfig.
[19:26:09] <alex_joni> wait on the commit, I'll be modifyin the whole file
[19:26:46] <rayh> k
[19:27:46] <rayh> phone
[19:36:02] <rayh> back
[19:36:25] <rayh> I'll wait for your commit before I do anything more with it.
[19:45:49] <alex_joni> rayh: I commited, you can change the initConfig stuff now, if you like
[19:45:59] <alex_joni> I'm still pondering if it's the final version though
[19:48:18] <rayh> My submissions never are final, why should we expect your's to be?
[19:52:42] <rayh> got that make clean error message.
[19:52:46] <rayh> make[1]: Leaving directory `/home/rayh/emcdevelop/emc2/src/emc'
[19:52:46] <rayh> find . -name "*~" -exec rm -f {} \;
[19:52:46] <rayh> find . -name "*.bak" -exec rm -f {} \;
[19:52:47] <rayh> find . -name core -exec rm -f {} \;
[19:52:49] <rayh> rm -f ../include/* ../lib/* ../rtlib/* ../bin/* 2>/dev/null
[19:52:51] <rayh> make: [clean] Error 1 (ignored)
[19:52:53] <rayh> rm -f .tmp/* .rt_tmp/*
[19:52:59] <alex_joni> that's OK
[19:53:09] <alex_joni> it's trying to remove the include/CVS dir
[19:53:13] <alex_joni> which is not a file
[19:53:23] <rayh> ah okay.
[19:53:36] <rayh> That shouldn't show up in released source.
[19:53:51] <alex_joni> no, it proabbly won't
[19:57:26] <rayh> Works good. Thanks.
[20:13:46] <alex_joni> rayh: I just ripped it all out.. it was an unnecessary complication :)
[20:18:51] <rayh> Ah that's why. Im getting really confused now.
[20:19:21] <rayh> 1.22 is the latest working version?
[20:19:22] <alex_joni> some foo is still in there :)
[20:19:34] <alex_joni> yes, 1.22
[20:39:19] <alex_joni> rayh: any problems on the latest version?
[20:52:53] <alex_joni> bye guys, I'm off to bed
[20:53:25] <rayh> None that I can see. Thanks
[20:53:31] <rayh> catch you tomorrow.