Back
[00:26:53] <rayh> I talked with roltek. His fanuc handles tool change with macros.
[00:27:22] <rayh> He has it on his lathe so that a txx calls the macro which does the entire tool change
[00:27:44] <rayh> including dropping the old tool length and diameter offsets and sets the new to match the new tool number.
[00:28:08] <rayh> The macro allows different users to treat the same commands in different ways.
[00:48:06] <rayh> Gotta spend some time with the family. Back tomorrow.
[18:44:22] <rayh> cradek It looks like halshow is broken in head.
[18:44:30] <rayh> at least it doesn't come up here.
[18:54:22] <cradek> I agree
[18:54:39] <cradek> it is running, and it spawns a halcmd, but no window comes up
[18:56:44] <rayh> It looks to me like we can no longer run these stand alone.
[18:57:07] <rayh> I also can not run tkemc as the main display and a second version for testing.
[18:57:08] <cradek> HALCMD=/home/chris/emc2.head/bin/halcmd /home/chris/emc2.head/bin/emcsh /home/chris/emc2.head/tcl/bin/halshow.tcl -- -ini /home/chris/emc2.head/configs/stepper-xyza/inch.ini
[18:57:23] <cradek> when I run it at the shell like this, I do not get an error, but still no window comes up
[18:57:34] <rayh> Right.
[18:58:00] <cradek> how does one go about figuring out where a tcl script is stuck?
[18:58:01] <rayh> I tried the pre floh version
[18:58:10] <rayh> same thing.
[18:58:24] <rayh> Normally I start an EMC
[18:58:33] <rayh> then start the script I want stand alone.
[18:58:58] <rayh> The picconfig traps returns so you can not see them in the terminal it runs from.
[18:59:19] <rayh> A stand alone system will report issues to it's terminal.
[18:59:38] <cradek> I'm with you so far, but I don't get any errors reported
[18:59:45] <rayh> Let me try starting emc using an ini reference.
[19:00:23] <cradek> I have a suspicion it's related to the halcmd/readline changes, but no proof of that yet
[19:00:51] <rayh> Okay. That might explain why nothing comes back.
[19:01:00] <rayh> It's waiting for the readline to end.
[19:01:09] <rayh> What did that change do?
[19:01:46] <rayh> funny though, the emccalib.tcl will run from tkemc.
[19:02:00] <cradek> do they both use halcmd the same way?
[19:02:30] <cradek> calibration does run for me too (I used it on the lathe)
[19:04:28] <rayh> Okay. That limits things a bit.
[19:04:56] <rayh> Let me look for changes in emcsh.
[19:08:50] <jepler> another thing I suspected was a change in halcmd, but I reverted to a pre-readline version of halcmd and it gave the same behavior.
[19:09:20] <rayh> Okay.
[19:09:26] <rayh> phone brb
[19:09:39] <cradek> I put debugging prints in, and openHALCMD starts but does not finish
[19:11:53] <jepler> argh, 'vim halshow.tcl' is killed when scripts/emc finishes
[19:42:19] <jepler> rayh: after applying this patch, which invokes 'halcmd' each time something is needed, instead of keeping a halcmd process around all the time, 'halshow' works for me again:
http://emergent.unpy.net/index.cgi-files/sandbox/halshow.patch
[19:44:29] <jepler> the last chunk, which changes makeNodeSig, is needed because otherwise I get an error like this at startup: node "sig+XYZvel" already exists
[19:44:39] <jepler> it appears to be trying to add this signal twice
[19:44:39] <jepler> writeNode {0 sig+X sig+XYZvel XYZvel 0}
[19:44:43] <jepler> writeNode {0 sig+Y sig+XYZvel XYZvel 0}
[19:52:09] <rayh> Okay.
[19:52:21] <rayh> That is really going to slow down the watch part.
[19:52:46] <rayh> But if we can't use the chanel then that will have to be it.
[19:53:00] <rayh> Thanks Jeff.
[19:53:05] <jepler> I would like to figure out why it broke and see if it can be fixed
[19:53:22] <jepler> but if you want to actually use halshow then this patch is good for you
[19:53:42] <rayh> There was some rather fragile stuff in there that swp worked out with me.
[19:54:05] <rayh> davee will need halshow sometime this afternoon.
[19:55:14] <rayh> You want to apply that patch to cvs?
[19:57:20] <cradek> rayh: are you helping dave-e do something fun to his mazak?
[19:57:42] <jepler> hm .. actually I just found the problem, and it was in my readline changes to halcmd
[19:57:56] <jepler> I wonder what I screwed up when I thought I tested that it wasn't those changes
[19:59:10] <rayh> I see that it is not possible to start two gui's now.
[19:59:26] <rayh> That must be some sort of other problem because they don't use halcmd.
[20:01:49] <jepler> EMC2_TCL_DIR=../../tcl HALCMD=../../bin/halcmd ../../bin/emcsh ../../tcl/tkemc.tcl -- -ini axis.ini
[20:02:04] <jepler> it works for me but I have to specify several environment variables to tkemc
[20:02:16] <jepler> (the HALCMD one is probably not necessary...)
[20:02:42] <jepler> now I have 3 'axis' and 2 'tkemc' running
[20:04:01] <rayh> Okay I can try that.
[20:09:53] <rayh> cms_config: can't open 'emc.nml
[20:10:00] <rayh> It's trying anyway.
[20:10:24] <cradek> I think you have to be in the directory with the ini you are running
[20:12:05] <rayh> okay.
[20:13:39] <rayh> no complaint but no display either.
[20:15:07] <cradek> which config are you using?
[20:15:51] <rayh> stepper_inch
[20:17:25] <cradek> I can get two tkemcs if I run stepper_inch like normal, then use jepler's command with the ini file changed to match: EMC2_TCL_DIR=../../tcl HALCMD=../../bin/halcmd ../../bin/emcsh ../../tcl/tkemc.tcl -- -ini stepper_inch.ini
[20:17:59] <rayh> I'll try in a minute, phone again.
[20:19:00] <rayh> works. I must have done something dumb.
[20:19:16] <rayh> thanks
[20:19:25] <cradek> welcome
[20:21:33] <rayh> why does it have to refer to ../../bin/emcsh?
[20:21:55] <rayh> but not assign that location to a variable?
[20:22:11] <jepler> ../../bin/emcsh is the program used to execute the tcl script
[20:22:27] <jepler> if you just write "emcsh" you might get the wrong one, for instance the one installed by the emc2-2.0.1 deb
[20:22:30] <rayh> But that should be called from the head of the script itself.
[20:22:57] <rayh> Or that is the way the tickle folk tend to do it.
[20:23:20] <jepler> it's possible I don't know the simplest or most correct way to do it
[20:24:31] <rayh> #!/bin/sh
[20:24:31] <rayh> # the next line restarts using iosh \
[20:24:31] <rayh> exec plat/UNKNOWN_PLAT/bin/iosh "$0" "$@"
[20:24:47] <rayh> Is the way that emc did it
[20:25:17] <rayh> for an ordinary wish it would be exec wish $0 $@
[20:26:45] <rayh> I'm guessing that that the line "exec $EMC2_EMCSH "$0" "$@""
[20:26:59] <rayh> is broke because EMC@_EMCSH is not set.
[20:27:17] <rayh> oops EMC2_EMCSH
[20:27:43] <rayh> I can handle that. Thanks for all the help you guys.
[20:28:17] <jepler> always welcome
[20:30:02] <rayh> Okay I can see the error messages from tcl now.
[21:30:15] <jmkasunich> hi guys
[21:34:22] <cradek> hi john
[21:34:54] <cradek> I rewired the lathe to use the new parport mode, it works on both my machines
[21:35:04] <jmkasunich> cool
[21:35:09] <cradek> it's great because I have pins for spindle control now
[21:35:34] <jmkasunich> running the data port in output mode, and the spindle sigs in thru the regular inputs + control port?
[21:35:58] <cradek> yes the data port is output (8 bits) everything else is input (9 bits)
[21:36:21] <cradek> so encoders are 3+2+2 inputs, leaving one for home switches and one for estop
[21:36:49] <cradek> home switch actually - I'll probably just have one on X
[21:38:51] <jmkasunich> Z gets tricky
[21:38:55] <jmkasunich> hard to know what is save
[21:38:58] <jmkasunich> safe
[21:39:19] <cradek> yeah I suppose Z should have a real limit switch at least on the tailstock
[21:39:53] <cradek> but keeping the tool out of the chuck is easy - jog up next to it and call that home
[21:40:44] <jmkasunich> yeah
[21:40:57] <cradek> that's why I won't bother to put a switch there
[21:41:22] <jmkasunich> saw you and ray discussing toolchange
[21:41:35] <cradek> yes a bit
[21:41:49] <cradek> he says maybe it should cancel length offset
[21:42:07] <jmkasunich> not entirely unreasonable
[21:42:21] <cradek> also he's happy with leaving the tool at the change location after the change, which I'm liking more and more for its safety
[21:42:42] <cradek> at least for now I think it's good enough
[21:42:50] <jmkasunich> did you notice the part where he said somebody
[21:42:54] <jmkasunich> somebody
[21:42:56] <jmkasunich> dammit
[21:42:59] <cradek> ''''
[21:43:04] <cradek> ^^ take some of mine
[21:43:19] <jmkasunich> somebody's control uses macros for the entire toolchange process
[21:43:23] <cradek> yes
[21:43:43] <cradek> that's something we should try to figure out how to do
[21:44:03] <jmkasunich> yeah - you already know my thoughts on the existing thing (TOOL_CHANGE_POSITION, etc)
[21:44:14] <cradek> having macros loaded all the time might be nice
[21:44:19] <cradek> like my hole and slot routines
[21:44:55] <jmkasunich> when we discussed toolchanging at NIST a year ago, macros came up
[21:45:12] <jmkasunich> one problem is preserving the interpreter state during a macro (or not)
[21:45:51] <jmkasunich> (the assumption being that the macro language is G-code)
[21:45:57] <cradek> yeah there are LOTS of gotchas
[21:46:56] <cradek> maybe we want something like postscript's gsave/grestore
[21:48:35] <jmkasunich> not familiar with that
[21:48:55] <cradek> a stack where you can push and pop "the state"
[21:49:05] <cradek> gsave / do some crap that screws it all up / grestore
[21:49:20] <jmkasunich> nice
[21:49:42] <jmkasunich> next step is to decide what exactly constutites the machine/interp state
[21:49:47] <cradek> gsave / g20 g18 g91 g10l2p1x99 ... / grestore
[21:50:02] <cradek> that's the hard part.
[21:50:53] <cradek> I'll be back in about an hour, hungry
[21:50:58] <jmkasunich> ok
[22:31:45] <cradek> back
[22:35:33] <jepler> cradek: you should let the list know of your success with the new parport mode, and/or write some documentation for it
[22:35:45] <jepler> cradek: I also wonder if any ports can use input mode and control-port inputs
[22:35:54] <jepler> but that's a question for another day
[22:36:17] <cradek> yeah I wonder, that's a lot of inputs and might be handy
[22:36:37] <cradek> although 13 (that we already have) is a lot too
[22:36:51] <cradek> I think this 8/9 mix is by far the important thing we get
[22:37:02] <jepler> for CNC probably
[22:37:14] <jepler> for data acquisition you might not turn down 17 bits
[22:38:01] <cradek> true
[22:38:18] <jepler> * jepler disappears again
[22:38:41] <cradek> bye
[23:27:43] <jmkasunich> * jmkasunich is back
[23:41:03] <cradek> hi
[23:41:09] <cradek> I'm working on a home switch now
[23:46:16] <cradek> hmm, I know I have a box of 2-56 screws ... somewhere
[23:46:26] <jmkasunich> heh
[23:55:55] <cradek> ok, forget it, I'm not working on a home switch tonight
[23:56:02] <cradek> sigh.