#emc-devel | Logs for 2007-11-25

[00:25:09] <alex_joni> hi rayh
[00:31:18] <rayh> Hi alex
[00:31:30] <rayh> Our lake froze over this morning.
[00:31:41] <rayh> So winter is good.
[00:32:00] <roltek> are you out ice fishing yet
[00:32:10] <rayh> Saw six otters running and sliding.
[00:32:20] <rayh> Not yet. Give it a day or two.
[00:32:39] <roltek> where some skis
[00:33:07] <rayh> Right.
[00:33:42] <rayh> And there I am standing with all four tips on ice at the edge of a big hole.
[00:33:48] <roltek> is the latest emc 2.2.1 live
[00:34:03] <rayh> Yes. I'm running it here.
[00:34:14] <rayh> On a Sherline 4 axis minimill.
[00:34:23] <roltek> i just down loaded it
[00:34:37] <rayh> Alex put together the CD.
[00:34:56] <alex_joni> well.. I didn't have much to do :D
[00:35:31] <roltek> we will see if i can get it running the 1st time
[00:35:59] <roltek> see you later
[00:36:05] <rayh> How does that path problem with 2.2.1 affect us.
[01:44:19] <roltek> hi ray you in
[03:27:02] <jmkasunich> have I mentioned lately how nice GPL software is?
[03:29:17] <alex_joni> nope, not lately
[03:29:45] <jmkasunich> the blog software I use was doing something I didn't like
[03:29:50] <jmkasunich> now it doesn't ;-)
[13:38:13] <alex_joni> hi all
[16:34:20] <alex_joni> hello... anyone around?
[16:34:52] <jepler> still hiding
[16:35:22] <alex_joni> heh.. I had a thought last night/this morning
[16:35:43] <jepler> uh oh
[16:35:43] <alex_joni> I was thinking of something like (overload,Mxx,file.ngc)
[16:35:55] <alex_joni> or (overload, Gxy, file.ngc)
[16:36:49] <alex_joni> then with given enough hooks inside the interpreter (ability to read vars - OK, ability to read/command IO - OK, etc.) one could easily define custom toolchange commands, or whatever
[16:37:41] <alex_joni> this would probably match the M- or G- code number, read some vars and pass them on to the file (or maybe to an O-word function)
[16:39:30] <alex_joni> I imagine overloading Txx or M6 or the like
[16:40:12] <jepler> you also need to add the ability for gcode to find information about current gcode state (like "what is the T#" for tool load)
[16:40:21] <alex_joni> right
[16:40:31] <alex_joni> so lots of info should be in .var's
[16:40:47] <jepler> storing it on disk may or may not make sense
[16:40:55] <alex_joni> or the ability to read arbitrary HAL pins
[16:40:56] <jepler> but yes I think that access would naturally be through numbered parameters
[16:41:20] <alex_joni> well, I think that's more a implementation issue for later
[16:41:30] <alex_joni> so far I'm concearned about the sanity of the whole idea
[16:42:13] <jepler> I don't think it makes sense for every gcode file to have to specify where the implementation of toolchange is through an (overload) comment
[16:42:34] <alex_joni> I agree.. maybe we could also have some machine-specific stuff
[16:42:50] <alex_joni> similar to RS274NGC_STARTUP_FOO in the ini
[16:44:02] <jepler> instead I imagine having a convention, such as Mnn being mapped to O sub 10000 + nn, and Gnn.n being mapped to O sub 20000 + nnn. there's already support for invoking O subs that come from files
[16:44:42] <alex_joni> ok, so if O sub 10020 exists it will call that instead of M20 ?
[16:45:01] <jepler> yes
[16:45:10] <alex_joni> O sub 10020 means either O sub 10020 in the current file, or 10020.ngc with O sub 10020 inside
[16:45:18] <alex_joni> hmm.. that's also a way to do it
[16:45:34] <alex_joni> saves some defining..
[16:46:10] <jepler> you have to figure out how to pass the "other words" along to the sub, including whether the word is used on that line at all
[16:46:50] <jepler> e.g., #1 gets the A word if it is present. Bit 1 in #27 is set if the A word is specified (except there aren't bitwise operators in ngc)
[16:47:06] <alex_joni> I see what you mean
[16:47:39] <alex_joni> that would also be valuable separately from this
[16:47:57] <alex_joni> on each line interpreted to have the A,B,C,etc words in #1..#27?
[16:48:12] <alex_joni> and the presence in #101..#127 (or whatever numbers)
[16:48:45] <jepler> well I chose #1 and so on because those are numbers reserved for subroutine parameters
[16:49:03] <alex_joni> maybe something that doesn't collide with existing stuff
[16:51:19] <jepler> also a facility like this might be used to implement tool change (which shouldn't be displayed or even executed for preview) or canned cycles (which should)
[16:51:56] <jepler> so you also have to have some way to know which is which
[16:52:34] <alex_joni> right
[16:53:45] <jepler> (or rather, the integrator should have a way to specify, and if he gets it wrong your preview will be useless)
[17:09:01] <roltek> hi alex what are you talking about
[17:11:27] <alex_joni> roltek: allowing integrators to "overload/redefine" G and M codes
[17:11:43] <alex_joni> if you want for your machine M6 to work completely different..
[17:12:10] <roltek> g and m codes should be standard should't they
[17:12:24] <alex_joni> sure
[17:12:40] <alex_joni> but say you have a tool-change defined by T1M6
[17:13:07] <roltek> tool #1 change tool m6
[17:13:14] <alex_joni> the g-code T1 M6 is standard for change to tool #1 (actually prepare T1, then change current tool to 1)
[17:13:36] <alex_joni> right.. but what the machine actually does to perform that depends on the machine
[17:13:59] <alex_joni> (like move to TOOL_CHANGE_POSITION, wait 2 seconds for carusel to stop spinning, etc)
[17:14:14] <roltek> macro
[17:14:25] <alex_joni> micro
[17:14:30] <roltek> hooked to plc
[17:14:44] <alex_joni> still.. how about a machine with a rack-toolchanger?
[17:14:56] <alex_joni> where the machine puts the tools down in different XY locations?
[17:15:04] <roltek> pick and place still macro
[17:15:13] <alex_joni> right.. that's what we're talking about
[17:15:41] <alex_joni> when M6 comes, a certain procedure (call it macro if you like) will get called
[17:15:55] <alex_joni> and the integrator writes the operations in there
[17:16:07] <alex_joni> like G1 X.. Y.., G4 P.. etc
[17:16:16] <alex_joni> brb
[17:18:24] <roltek> x,y,z location for each tool
[17:18:55] <roltek> g00