Back
[02:09:50] <jmkasunich> hi guys
[02:10:07] <jepler> hi
[02:11:41] <jepler> I realized that my only microcontroller with level shifting circuit doesn't have any control lines, so I can't test this serial protocol without building something
[02:11:56] <jmkasunich> level shifting?
[02:12:00] <jepler> yeah, from rs232 to ttl
[02:12:03] <jmkasunich> you mean rs-232 to ttl
[02:12:29] <jmkasunich> resistors?
[02:12:54] <jmkasunich> for PC to uC you just need to scale it down and prevent negative (resistors and a diode I guess)
[02:13:14] <jmkasunich> not sure if the PC will accept ttl direcly, for the uC to PC link
[02:13:36] <jepler> I guess that would be enough -- it has TX and RX done properly, just needs the control signal
[02:13:42] <jepler> and that's PC to uC only
[02:14:57] <jepler> think resistor only and trusting the internal protection diodes is too terrible an idea?
[02:15:12] <jmkasunich> hard to say
[02:15:26] <jmkasunich> depends on the signal swing and the resistor
[02:15:39] <jmkasunich> this isn't a general purpose design, just a one-off
[02:16:10] <jmkasunich> does the PC you intend to run it with have full RS-232 levels, or something a little lower?
[02:16:25] <cradek> hi jmk
[02:16:32] <jepler> hi cradek
[02:16:36] <jepler> jmkasunich: i measured a good 10V
[02:16:41] <jepler> 20V swing
[02:17:08] <jmkasunich> if you can keep the current under a mA the diodes can probably handle it (maybe check the uC datasheet to be sure)
[02:17:41] <jmkasunich> so the question is, does a 10K resistor times whatever stray C is present slow the signal down too much
[02:17:47] <jmkasunich> I think the answer is probalby no
[02:18:16] <jmkasunich> assume 20pF, times 10K is 200nS
[02:18:21] <jepler> the other thing I considered was to look back TX to RX .. the system will just recive its own signal and ignore the control line
[02:18:26] <jmkasunich> you could probalby use 50K
[02:19:03] <jmkasunich> hi cradek
[02:19:34] <cradek> jepler: any reason not to just use a laptop for testing?
[02:19:48] <jepler> cradek: my laptop doesn't have a true serial port
[02:19:51] <jepler> or true realtime
[02:20:01] <jepler> it's basically a false laptop
[02:20:24] <cradek> ah
[02:20:35] <cradek> I would have happily loaned you mine, I had it along tonight
[02:31:13] <cradek> yuck
[02:31:43] <cradek> so when in 'disable feed override' mode, do we still want to honor adaptive feed?
[02:32:14] <cradek> I thought I'd jump right in and fix this, but of course it's messier than I thought
[02:32:28] <cradek> we combine adaptive feed and FO before they get to TP
[02:32:47] <cradek> so I can't honor one and not the other without a big restructuring
[02:33:19] <jmkasunich> I think adaptive feed during threading is just as nasty as FO
[02:33:48] <cradek> that's true, but I'm thinking about the more general case of Gxx/Gxx (whatever they are) that enable/disable FO
[02:34:01] <jmkasunich> but you're not talking about threading, are you? that disables FO regardless of the gcode
[02:34:02] <cradek> i.e. the DISABLE_FEED_OVERRIDE canon call
[02:34:07] <jmkasunich> right
[02:34:29] <cradek> I have no idea what those should do to adaptive feed
[02:34:41] <cradek> I see from the code that alex thought they should not affect adaptive feed
[02:35:07] <cradek> but I can see an argument for them meaning "do exactly what the F word says"
[02:35:16] <jmkasunich> yeah
[02:35:28] <jmkasunich> the problem is that adaptive feed can be used in several ways
[02:35:44] <jmkasunich> if you use it to connect a hal knob as a feedrate override, then you want to disable it
[02:35:59] <jmkasunich> if you use it to do true spindle load adaptive feed, maybe you don't
[02:36:41] <jmkasunich> is the DISABLE/ENABLE FO going to become an attribute of the queued move?
[02:36:59] <cradek> yes I think it has to
[02:37:04] <jmkasunich> I agree
[02:37:12] <jmkasunich> just making sure I was on the right page
[02:37:46] <cradek> but aside from the queue there's this realtime changing overall vscale
[02:38:27] <cradek> and through some small miracle we honor that as much as the machine constraints allow
[02:38:40] <jmkasunich> so, lets list all the sources of feedrate info
[02:38:57] <jmkasunich> for G1/2/3 moves, there is a queued feedrate request, from the F word
[02:39:11] <cradek> FO slider
[02:39:13] <cradek> adaptive feed
[02:39:14] <jmkasunich> for G0 moves, does task just queue a max-rate?
[02:39:30] <cradek> umm yes
[02:39:44] <cradek> it knows the machine constraints
[02:39:50] <jmkasunich> so by the time moves get down to the TP, it doesn't really know the difference between a G0 and a G1
[02:39:55] <cradek> right
[02:40:08] <jmkasunich> they're both lines, its just that one has a higher velocity request
[02:40:21] <cradek> well TP barely does know that, but it's not used except for reporting to the gui
[02:40:37] <cradek> 'motion type' used for AXIS backplot color
[02:41:09] <jmkasunich> ok, so we have queued vel request, queued "FO override" flag, unqueued FO from task, and realtime AF from HAL
[02:41:46] <cradek> yes
[02:42:12] <jmkasunich> I can think of cases where someone will want FO override to override AF, and cases where they won't
[02:42:22] <jmkasunich> so we're going to piss off somebody regardless
[02:42:30] <cradek> so I should do the easier one?
[02:42:41] <jmkasunich> the logical one
[02:42:59] <jmkasunich> I see no reason to distinguish AF from FO, override should affect both
[02:43:09] <jmkasunich> (which just happens to be the easier one I think)
[02:43:14] <jmkasunich> damn
[02:43:14] <cradek> for this threading usage (withdrawal) the choice is clear
[02:43:29] <jmkasunich> well, threading is a special case
[02:43:43] <jmkasunich> in fact, that could be considered yet another source of feed info
[02:43:49] <cradek> having the canon call mean "do exactly what the F word says" has a nice simplicity to it
[02:43:54] <jmkasunich> a queued "this move is synced" flag
[02:44:21] <cradek> yeah synced is easy - it ignores all these inputs.
[02:44:49] <jmkasunich> we're proposing that FO disable should do exactly the same
[02:45:16] <cradek> yes all except the F word (or max speed in the traverse case)
[02:45:39] <jmkasunich> doesn't synced use the F word?
[02:45:49] <cradek> no
[02:45:50] <jmkasunich> (as feed per rev, not feed per sec)
[02:45:59] <cradek> different word (K or P)
[02:46:08] <jmkasunich> ok, I spoke poorly
[02:46:12] <cradek> so F is saved for when you unsync
[02:46:53] <jmkasunich> but in the queue entry for a synced move, is the feed per rev stored in a different field? or does it occupy the same field as the F word feed of a regular move?
[02:47:16] <cradek> tc->uu_per_rev
[02:47:23] <cradek> different field
[02:47:26] <jmkasunich> ok
[02:47:38] <jmkasunich> where I was going with this was...
[02:47:42] <cradek> heh
[02:47:58] <jmkasunich> have two flag fields: sync, and FOdisable
[02:48:09] <cradek> right I did that
[02:48:12] <jmkasunich> if sync is true, set FOdisable as well
[02:48:31] <jmkasunich> so there is no "sync specific" code for feedrates
[02:48:46] <jmkasunich> it just uses the same code that disables FO for non-sync moves
[02:48:47] <cradek> I can handle those details, I just want to talk about the spec
[02:48:52] <jmkasunich> heh, ok
[02:49:11] <jmkasunich> I'm in agreement that "FO disable" should also disable AF, BUT...
[02:49:27] <cradek> agreement? I don't remember saying that :-)
[02:49:29] <jmkasunich> I think we should add another HAL pin (yes, _another_ feed control pin)
[02:49:50] <jmkasunich> you said "FO disable means use the F word exactly as coded"
[02:50:08] <cradek> ok I admit I'm leaning that way too
[02:50:13] <cradek> sorry go on
[02:50:16] <jmkasunich> ok
[02:50:28] <jmkasunich> the new pin: a hal_bit, called "feed-hold"
[02:50:49] <cradek> yeah we've needed that for a while
[02:50:51] <jmkasunich> during threading it too would be ignored
[02:51:01] <cradek> using adaptive feed for that is a perversion of adaptive feed
[02:51:02] <jmkasunich> but for Gxx FOdisable, it would NOT be ignored
[02:51:14] <jmkasunich> so even with FO disabled, you can still have a feedhold control
[02:52:06] <jmkasunich> (and it avoids perversion...)
[02:52:17] <cradek> yeah I think I agree
[02:52:29] <jmkasunich> but that gets us away from the easy implementation
[02:52:43] <jmkasunich> because now FOdisable needs to ignore FO and AF but not FH
[02:52:57] <jmkasunich> that shouldn't be too terrible though
[02:53:11] <jmkasunich> all three go into the "scale" variable
[02:53:14] <cradek> no because FH is separate from FO and AF (which are combined)
[02:53:32] <jmkasunich> if FH is separate, how are you gonna implemnet it?
[02:53:35] <cradek> we'll have to get FH into emcmotStatus
[02:53:41] <cradek> just like pause
[02:53:50] <jmkasunich> not like pause
[02:54:08] <cradek> sure at the TP level it's like pause I think
[02:54:09] <jmkasunich> does pause stop immediately, in the middle of a move?
[02:54:12] <cradek> yes
[02:54:14] <jmkasunich> does pause stop a rapid?
[02:54:22] <cradek> yes
[02:54:23] <jmkasunich> does pause stop a homing sequence? a jog?
[02:54:36] <cradek> no
[02:54:43] <cradek> but that's your problem
[02:54:44] <jmkasunich> FO and AF modify _everything_, and I think FH should too
[02:55:00] <cradek> are you sure AF modifies jog and homing?
[02:55:02] <jmkasunich> so I think FH should be implemented by folding it into scale
[02:55:11] <jmkasunich> I think so
[02:55:14] <jmkasunich> lemme test
[02:55:22] <cradek> no, then it's impossible for me to honor some of them, that's the whole problem I started with
[02:55:38] <jmkasunich> not true....
[02:55:58] <cradek> you're talking about emcmotStatus->overallVscale right?
[02:56:00] <jmkasunich> the code that does the "folding" needs to know if we are in FOdisable or not
[02:56:03] <jmkasunich> right
[02:56:16] <cradek> then it needs to be moved out of motion into TP
[02:56:25] <jmkasunich> if in FOdisable, scale = 1.0 or 0.0, depending on FH
[02:56:49] <jmkasunich> if not in FOdisable, scale = FO * AF * (1 or 0 depending on FH)
[02:57:13] <cradek> ok but remember FOdisable is queued but overallVscale isn't, so you have to move all of overallVscale "folding" after the queue
[02:57:26] <jmkasunich> it already is
[02:57:44] <jmkasunich> FO and AF and FH are not queued, and changes to scale take effect immediately
[02:58:09] <jmkasunich> the TP simply has to provide a flag that says "the current move has FOdisable turned on"
[02:58:10] <cradek> but the flag to ignore 2/3 of those things IS queued
[02:58:42] <jmkasunich> right - the TP dequeues the current value of the flag, and makes it available
[03:00:37] <jmkasunich> is there a canonical to turn sync on and off, or is it an attribute of the "line" canonical?
[03:00:51] <cradek> it's a separate canon
[03:01:03] <cradek> just like DISABLE_FO
[03:01:17] <jmkasunich> does it result in a separate command to motion (emcmot_command)?
[03:01:24] <cradek> what did you find about overallVscale and the free mode planner?
[03:01:30] <cradek> yes it does
[03:01:38] <jmkasunich> too much talking, not enough testing... stand by
[03:02:53] <jmkasunich> FO definitely affects jogs
[03:03:17] <cradek> ok I guess I knew that
[03:03:22] <cradek> not sure about AF though
[03:03:45] <cradek> that's tied into g48/g49 or whatever they are, it would be a bit odd
[03:03:49] <jmkasunich> FO and AF already get folded into vScale, so whatever FO does, AF does
[03:03:53] <cradek> g50/g51 iirc
[03:04:08] <jmkasunich> yeah, AF can be turned on or off with G50/51
[03:04:10] <cradek> what tests the g50 flag? the folding code?
[03:04:13] <jmkasunich> yes
[03:04:24] <cradek> so this is in homing too?
[03:04:26] <jmkasunich> lemme take a look at the code
[03:04:46] <cradek> (I think it's a bug that ANY of this affects homing)
[03:04:58] <jmkasunich> that would be a debate
[03:05:10] <jmkasunich> in EMC(1), FO affected _everything_
[03:05:19] <cradek> you could set someone's feed override to 900% and end the debate quickly
[03:05:32] <jmkasunich> whether that is right or not, thats what people are used to
[03:05:57] <cradek> true
[03:06:18] <cradek> but that doesn't make it cease being a bug in my eyes... those homing velocities are important.
[03:06:27] <jmkasunich> you have a point with the 900%, but I'd want to get some buy-in from Ray and other long time users before changing anything
[03:07:23] <jmkasunich> sometime in the last few months, I recall lots of discussion where people wanted separate FO's for normal moves and rapids
[03:07:27] <cradek> yeah I'd like to hear what ray thinks
[03:07:44] <jmkasunich> there are probalby a lot of different opinions about how FO should work
[03:08:02] <jmkasunich> a spec, followed by some debate, is probalby in order
[03:08:14] <jmkasunich> once the shooting stops and the spec is frozen, then we code it
[03:08:37] <jepler> I just want to ask that we put feed override disable disable disable in the spec
[03:08:53] <cradek> but someone will say "make it all configurable in the ini" and then jepler will kill him
[03:09:17] <cradek> I guess that would solve the immediate problem though, so I'm not going to say jepler would be in the wrong
[03:09:28] <jmkasunich> exactly
[03:09:40] <cradek> oh hi jepler
[03:09:52] <jmkasunich> now, what was I looking up in the code again?
[03:09:58] <cradek> AF/homing
[03:10:02] <cradek> I think
[03:10:10] <cradek> g50/homing?
[03:10:12] <cradek> I forget too
[03:10:29] <cradek> (I'm now officially sorry I decided to work on this)
[03:10:46] <jmkasunich> oh, now I see alex's code\
[03:10:55] <jmkasunich> he made FOdisable turn off FO, but not AF
[03:10:58] <cradek> yes
[03:11:05] <cradek> that was clearly his intent
[03:11:46] <jmkasunich> ok, you've already looked at the folding code then...
[03:11:52] <jmkasunich> why are you asking me about it? ;-)
[03:12:05] <cradek> um, it was yesterday
[03:12:09] <jmkasunich> heh
[03:13:18] <jmkasunich> ok, I know what you can do without having to wait for this debate to be over
[03:13:51] <cradek> my thought is: have the canon call disable AF & FO, worry about FH later
[03:14:02] <jmkasunich> right now, when EMCMOT_FEED_OVERRIDE is received by the RT, it sets emcmotStatus->fo_mode immediately
[03:14:12] <jmkasunich> that needs to be queued instead
[03:14:14] <cradek> which is clearly bogus
[03:14:15] <cradek> right
[03:14:29] <jmkasunich> and then emcmotStatus->fo_mode needs to be written with the dequeued value in the TP
[03:14:37] <cradek> right
[03:14:41] <cradek> that part is done
[03:15:15] <jmkasunich> so alex's folding code (which reads fo_mode) will work just like he intended, but without the time skew from the queue
[03:16:17] <jmkasunich> its trivial to change the FO code so that it either does or does not also disable AF
[03:16:38] <jmkasunich> s/FO/folding/
[03:16:56] <cradek> well fo_mode is no use in emcmotStatus
[03:17:01] <jmkasunich> likewise, its trivial to add the FH pin, and merge it into the folding code
[03:17:05] <jmkasunich> why not?
[03:17:12] <cradek> EMCMOT_FEED_OVERRIDE needs to call tpHonorFeedOverrideOrNot
[03:17:38] <cradek> that's how you save state for tpAddSomeLinesNow calls that are upcoming
[03:18:01] <jmkasunich> thats the part I thought you just said was finished already?
[03:18:23] <cradek> well more or less yes
[03:18:31] <cradek> but why is it in emcmotStatus?
[03:18:44] <jmkasunich> well, you could just make it a global ;-)
[03:19:07] <cradek> no I'm saying it makes a function call in TP, there's no need to save it anywhere else
[03:19:10] <jmkasunich> but status describes the status of the motion controller, and "currently executing a move with FO disabled" is certainly status
[03:19:28] <jmkasunich> argh
[03:19:29] <cradek> ok but you have to *write* it from TP then
[03:19:33] <jmkasunich> exactly!
[03:19:47] <jmkasunich> <jmkasunich> and then emcmotStatus->fo_mode needs to be written with the dequeued value in the TP
[03:19:47] <jmkasunich> <cradek> right
[03:19:47] <jmkasunich> <cradek> that part is done
[03:20:25] <cradek> I must not have read that right, sorry
[03:20:30] <jmkasunich> no prob
[03:21:22] <cradek> actually I was answering "that needs to be queued instead" from a couple lines up when I said "that part is done"
[03:21:27] <jmkasunich> ok
[03:21:36] <jmkasunich> I thought you were answering to both parts
[03:22:01] <cradek> ok what have we decided?
[03:22:09] <jmkasunich> command.c need to queue instead of writing Status->fo_mode (done if I understand you correctly)
[03:22:33] <jmkasunich> TP needs to dequeue and write Status->fo_mode (not done, you can do that since you know the TP)
[03:22:34] <cradek> yes except for the function call it's done
[03:23:11] <jmkasunich> and the folding code needs to use Status->fo_mode and "do the right thing" to compute overallVscale
[03:23:19] <jmkasunich> which I'd be happy to code
[03:23:48] <jmkasunich> (and change later, after we finally decide what "the right thing" is, wrt to FO, AF, and FH
[03:24:15] <cradek> ok let's do it and see what happens
[03:24:22] <jmkasunich> of course there is an additional complication
[03:24:35] <jmkasunich> what about when we're not using the TP?
[03:25:24] <cradek> how does g50/g51 get handled and saved? maybe we would use the same way
[03:25:45] <jmkasunich> maybe
[03:25:57] <cradek> it seems like exactly the same problem
[03:26:11] <jmkasunich> but I just had a sinking feeling that its not done correctly either
[03:26:29] <jmkasunich> its not
[03:26:31] <cradek> well I guess it's not the same at all because it doesn't have to queue
[03:26:33] <cradek> howso?
[03:26:36] <jmkasunich> EMCMOT_ADAPTIVE_FEED is not queued
[03:26:55] <cradek> oh..... ouch
[03:26:56] <jmkasunich> but I can certainly envision a situation where you turn adaptive feed on only for certain moves
[03:27:13] <cradek> sure
[03:27:20] <cradek> like g1 but not g0 in edm
[03:27:49] <jmkasunich> I think you were right when you said we can use the same code
[03:28:04] <jmkasunich> because they should both work the same wya
[03:28:17] <jmkasunich> but we can't use the _existing_ code
[03:28:31] <cradek> no, it's all broken isn't it
[03:28:45] <jmkasunich> I think we need _two_ status vars for each mode
[03:29:09] <jmkasunich> EMCMOT_ADAPTIVE_FEED(on/off) would set one var immediately
[03:29:32] <jmkasunich> EMCMOT_LINE and EMCMOT_ARC would read that var when enqueuing a move, and set the move's flags accordingly
[03:29:39] <cradek> wonder if we should give TP an arbitrary bitmap that it makes available in emcmotStatus during that move
[03:29:45] <jmkasunich> TP would dequeue the move, and set the second flag
[03:30:08] <cradek> then any of this kind of stuff can be handled in motion...?
[03:30:08] <jmkasunich> the folding code would use the first flag in free mode (jogs, etc), and the second flag in coord mode (where moves are coming from the TP)
[03:30:22] <jmkasunich> yes!
[03:30:26] <cradek> yes and I'm thinking all these flags are bits
[03:30:40] <jmkasunich> so instead of my two flags, there are two bitmaps
[03:31:31] <cradek> whose bits do you see during a blend?
[03:32:02] <jmkasunich> who is "you" in that question? the TP? the folding code?
[03:32:23] <cradek> during a blend, which set of bits gets put in emcmotStatus for motion to see?
[03:32:42] <cradek> (each of the joined moves has a different set of bits)
[03:32:52] <jmkasunich> oh
[03:33:43] <jmkasunich> for the generic bitmap, that is a tough question
[03:33:53] <jmkasunich> for specific bits, you might use the OR of the two
[03:34:01] <cradek> there's already some of this stuff and my answer was "depends which part of the blend you're on"
[03:34:31] <cradek> well since we only blend adjacent moves, we could make them both available, but yuck
[03:34:49] <jmkasunich> the TP handles FO strictly by using emcmotStatus->overallVscale?
[03:35:05] <jmkasunich> (I mean right now)
[03:35:16] <cradek> yes, it uses only that number, or 1, or 0
[03:35:34] <jmkasunich> 0 for pause, 1 for synced moves?
[03:35:38] <cradek> yes
[03:37:45] <jmkasunich> the free mode planner and the backlash comp velocity/accel limitation code also use overallVscale
[03:38:02] <jmkasunich> and since the free mode planner is used for homing moves....
[03:38:15] <jmkasunich> every motion obeys overallVscale
[03:38:28] <jmkasunich> thats the good news
[03:39:06] <jmkasunich> the problem is now figuring out the correct value for overallVscale given FO, AF, FH, FOdisable, sync, blending, etc, etc
[03:39:50] <cradek> we can ignore sync
[03:40:16] <cradek> maybe we can even ignore blending
[03:40:19] <jmkasunich> right, the TP handles that, and you never have "sync" in free mode
[03:41:03] <jmkasunich> for blending, when does the TP "think" it has moved on to the next segment? half way thru the blend?
[03:41:25] <jmkasunich> if so, I think that would be a fine time to set the bitmap to the value that was queued with the next segment
[03:41:36] <cradek> the current algorithm is 'whichever motion is contributing more velocity' which I think is the same thing you said
[03:42:03] <cradek> (it may not quite be the same if the velocities are different)
[03:42:09] <jmkasunich> close enough
[03:42:13] <cradek> yes
[03:42:35] <cradek> this is sooooo complicated
[03:42:48] <jmkasunich> whatever the TP is reporting as the current move in emcmotStatus should be the move who's bitmap is being used.
[03:44:07] <jmkasunich> is jepler's g-code reference page linked from linxucnc.org anywhere?
[03:44:10] <jmkasunich> can't seem to find it
[03:44:27] <cradek> I think so, maybe the documentation tab?
[03:44:45] <jmkasunich> thats where I looked forst
[03:44:47] <jmkasunich> first
[03:45:33] <cradek> currently execId is not changed in the center of the blend but I think it's harmless to change that
[03:45:39] <jmkasunich> its linked from the wiki frontpage
[03:46:19] <jmkasunich> hmm, G50 isn't listed
[03:47:07] <cradek> a doc bug
[03:47:15] <jmkasunich> 3.6.5 Override Control - M48 and M49
[03:47:15] <jmkasunich> To enable the speed and feed override switches, program M48. To disable both switches, program M49. See Section 2.2.1 for more details. It is OK to enable or disable the switches when they are already enabled or disabled.
[03:47:35] <jmkasunich> are these what we are talking about? I thought they were Gcodes, not Mcodes
[03:47:49] <cradek> yes I guess so
[03:48:07] <cradek> those are override enable/disable
[03:48:16] <cradek> AF enable/disable is g50/g51 iirc
[03:48:29] <jmkasunich> yes, but we made that up on the fly at emc-fest
[03:48:34] <cradek> yep
[03:49:11] <jmkasunich> I gotta wonder if we shouldn't admit that AF and FO are related
[03:49:24] <jmkasunich> maybe M47 should be AF enable/disable
[03:49:36] <cradek> maybe
[03:49:47] <jmkasunich> oh, I'm all fscked up
[03:50:01] <jmkasunich> I was thinking M48 was FO, and M49 was SO
[03:50:17] <cradek> no they are both controlled together I guess
[03:50:24] <jmkasunich> but M48 is FO _and_ SO enable, and M49 is FO _and_ SO disable
[03:50:38] <jmkasunich> you _can't_ disable just one of them
[03:50:44] <jmkasunich> what a crock
[03:50:51] <cradek> To enable the speed and feed override switches, program M48. To disable both switches, program M49.
[03:51:16] <jmkasunich> yeah, I read it, but it didn't sink in
[03:51:45] <cradek> I don't really even care about any of that, I just thing the canon call should work
[03:52:22] <cradek> I think the goofy gcode stuff is a separate problem
[03:52:27] <jmkasunich> well, I'm seeing some symmetry here, for SO, FO, and AF
[03:52:46] <cradek> true
[03:52:48] <jmkasunich> and I'd like the gcodes, the canon functions, and the RT implementation all to make sense
[03:53:10] <jmkasunich> lets start at the top for a moment
[03:53:25] <jmkasunich> M48 and M49 do as documented, FO+SO on, and FO+SO off
[03:53:40] <jmkasunich> M48.1 FO (only) on, no change to anything else
[03:53:46] <jmkasunich> M49.1 FO (only) off
[03:53:52] <jmkasunich> M48.2 SO on
[03:53:56] <jmkasunich> M49.2 SO off
[03:54:06] <jmkasunich> M48.3 AF on
[03:54:11] <jmkasunich> M49.3 AF off
[03:54:26] <jmkasunich> note that plain M48/49 don't affect AF at all
[03:54:52] <cradek> I think that's an appealing idea
[03:55:15] <jmkasunich> under that you have three canonicals, setFO(on/off), setSO(), and setAF()
[03:55:49] <jmkasunich> I bet you even SOdisable should be queued, so it applies to specific moves
[03:56:02] <cradek> I'm sure that's true
[03:56:13] <cradek> I'm seeing these are really all the same
[03:56:14] <jmkasunich> so thats three "immediate" flags, written by the canonicals
[03:56:22] <jmkasunich> and queued by SET_LINE and SET_ARC
[03:56:33] <jmkasunich> dequeued by the TP, and written into three "current move" flags
[03:56:56] <jmkasunich> the folding code uses the current_move flags when in coord mode, and the immediate flags during free mode (and teleop)
[03:57:53] <jmkasunich> feedhold also goes into the folding code.... I dunno whether we'd make it enableable or not
[03:58:08] <jmkasunich> could easily add M48/49.4, and another pair of flags
[03:58:42] <cradek> that kind of thought makes the bitmap seem smart
[03:58:57] <cradek> the bits correspond to those M48/49 bits
[04:00:09] <cradek> if TP makes the current bits available in status, and motion figures the scale for Tp to read, it will always be one TP period behind
[04:00:39] <cradek> I think that's an argument for doing all the bitmap processing in TP
[04:00:55] <jmkasunich> and the "folding"?
[04:01:20] <jmkasunich> who does the folding in free mode?
[04:01:21] <cradek> yeah that's what I meant by bitmap processing
[04:01:53] <cradek> well first do you agree about being a period behind? I'm not sure
[04:02:03] <jmkasunich> I think so
[04:02:19] <cradek> I also don't know whether that's important
[04:02:19] <jmkasunich> there are two approaches, I'm trying to figure out if either one helps
[04:02:32] <jmkasunich> can do the folding before or after calling the tp
[04:03:12] <jmkasunich> but I don't think it matters - the overallVscale will be one sample late when you change from a segment with FO (or something) enabled to one with it disabled
[04:03:35] <cradek> yes I agree, it's not going to help either way
[04:04:14] <cradek> it's an inexact science anyway with the blended transitions
[04:04:16] <jmkasunich> if FO isn't set to 100%, its gonna take a finite time to ramp from whatever the FO was (when enabled) to 100% (when disabled) or vice versa
[04:04:18] <cradek> maybe it doesn't matter
[04:04:26] <jmkasunich> I'm not sure if a millisecond of additional delay will matter
[04:05:06] <jmkasunich> with exact stop mode, the bitmap will change on the first period of the new move, right?
[04:05:26] <jmkasunich> at that point, the velocity is near zero, so scale will have very little effect
[04:05:30] <cradek> yes
[04:05:38] <jmkasunich> on the next period, scale will be correct for the segment
[04:06:18] <cradek> in exact mode, tp gets the new segment on the same cycle as the old one finished, and it would set the bitmap then
[04:06:37] <cradek> for that cycle I think there is no motion
[04:06:43] <jmkasunich> great
[04:07:04] <jmkasunich> so in exact stop mode, you can ensure that the FO either does or does not apply to the desired segment
[04:07:17] <jmkasunich> in blended mode, the result is ambiguous, but that is to be expected anyway
[04:07:39] <cradek> yeah you slow down or speed up "during the blend sometime"
[04:07:53] <cradek> that's as precise a statement as I'm prepared to make
[04:07:54] <jmkasunich> if you disable FO in the middle of a long string of blended moves you can't expect perfection anyway
[04:08:25] <jmkasunich> I think I'm happy with what we've defined here
[04:08:41] <cradek> well it will be fixed in one move no matter what, since we only blend two of them
[04:08:48] <jmkasunich> yeah
[04:08:53] <cradek> I think it will end up working fine
[04:09:00] <jmkasunich> now, while we're on the subject of overrides...
[04:09:12] <jmkasunich> should we think about G0 vs G1/2/3 having separate overrides?
[04:09:13] <cradek> ok now let's go to bed and let alex write it when he gets up :-)
[04:10:09] <cradek> if we do that, it can be handled in the same bitmap I think
[04:10:19] <jmkasunich> yeah, just a little differently
[04:10:34] <jmkasunich> a flag called "move_is_rapid"
[04:10:54] <jmkasunich> the "immediate" flag would never be set, because in free mode all moves are treated the same
[04:11:14] <jmkasunich> the "current_move" flag would be set by the TP based on G0 vs G1/2/3
[04:11:32] <cradek> can you explain more precisely what you mean by < jmkasunic> should we think about G0 vs G1/2/3 having separate overrides?
[04:11:40] <jmkasunich> and the folding code would calculate overallVscale using either FOmain or FOrapid, depending on the flag
[04:11:48] <cradek> do you mean feed override override, like M48.1?
[04:12:04] <jmkasunich> remember the people who wanted one FO knob for rapids and another for cutting?
[04:12:32] <cradek> yes (I still think they were bordering on crazy)
[04:12:49] <jmkasunich> here is one application:
[04:13:13] <jmkasunich> proofing a program, cutting the first part. all the actual cuts need to be made at the normal (relatively slow) cutting speed
[04:13:34] <jmkasunich> but the rapids should be made slower, so you have time to hit the "oh shit" switch before you ram into the vise
[04:13:48] <cradek> then I think you want a "maximum velocity no matter what" slider, not two various percentages
[04:14:01] <jmkasunich> so you turn the "rapid override" knob down to 10%, and leave the FO knob at 100%
[04:14:29] <cradek> that's what I kept saying to those guys and I'm still sure I'm right
[04:14:54] <cradek> their scheme lets your accidental G1 X99 F999 still smash into something, mine doesn't
[04:15:03] <jmkasunich> ok, opposite case: you are proofing a program, no metal to cut
[04:15:41] <jmkasunich> so you want to speed the cutting parts up from 10ipm to 30, but leave the rapids alone (or maybe slow them down from 100ipm to 50)
[04:16:26] <cradek> then set the "max velocity no matter what" to 50, and the FO to 300%
[04:16:45] <jmkasunich> ok, you still have two sliders
[04:17:15] <cradek> yes
[04:17:16] <jmkasunich> lets not argue about what the two are called, but as long as there are two, the implementation has to decide how to merge them
[04:17:29] <cradek> one works like it always has (FO)
[04:17:36] <cradek> one is a vel limit which tops out at your machine limit
[04:18:03] <cradek> there's really no merging
[04:18:25] <jmkasunich> and how is the second one applied? passed into the TP, and it does V = min(Fword*overallScale, maxslider) ?
[04:18:48] <cradek> min(Fword*overallScale, maxslider, machineconstraints)
[04:18:55] <jmkasunich> right
[04:19:19] <jmkasunich> I guess a similar min() can be added to the free mode planner
[04:19:35] <jmkasunich> and the maxslider has no effect on overallVscale
[04:19:40] <cradek> right
[04:19:45] <jmkasunich> so lets leave that whole concept for another day
[04:19:47] <jmkasunich> ;-)
[04:19:48] <cradek> at least that's what I want
[04:20:13] <cradek> a couple of those guys definitely wanted rapid-only FO, but I think that's totally bogus and I don't care if other controllers do it
[04:20:40] <jmkasunich> ok, leaving that behind...
[04:20:48] <cradek> and you don't need any of that stuff if you look at the preview in AXIS :-)
[04:21:42] <jmkasunich> sleep now, review the log tomorrow,and split up the work? I'd be happy to do the folding code, the immediate bitmaps, and queue the immediate values
[04:22:03] <cradek> yes that's a good idea
[04:22:03] <jmkasunich> you know the TP, so hopefully you can dequeue and write to the current_move flags
[04:22:11] <cradek> I'd like alex to read it before we do anything
[04:22:12] <jmkasunich> I can do the folding code, and add the feedhold pin
[04:22:29] <jmkasunich> and we can get alex to work on the canonicals and/or M code stuff
[04:22:38] <jmkasunich> yes - certainly get alex to review first
[04:22:41] <cradek> yeah, but poor alex :-/
[04:23:03] <jmkasunich> maybe tomorrow we should have him walk us thru it so we learn?
[04:23:27] <cradek> maybe, but I think I actually know how to do it
[04:23:42] <cradek> writing down the steps/layers would be nice though.
[04:23:47] <jmkasunich> yeah
[04:24:18] <jmkasunich> logger_dev: bookmark
[04:24:18] <jmkasunich> I'm feeling lazy .. but here's the log anyways:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-04#T04-24-18
[04:24:36] <jmkasunich> 404?
[04:24:41] <cradek> arg, two hours of my life gone
[04:24:54] <cradek> uh-oh
[04:25:09] <jmkasunich> but I think we came up with an elagant _and_ implementable design
[04:25:17] <cradek> yes
[04:25:58] <jmkasunich> I just saved my IRC log... I'll edit and put on the wiki or something
[04:26:27] <cradek> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-04.txt#T04-24-18
[04:27:00] <cradek> not sure what's going on with the logger there, but you can get to the txt
[04:27:35] <jmkasunich> good
[04:32:50] <cradek> ok I'm going to have dinner and go to bed!
[04:32:58] <jmkasunich> I already had dinner
[04:33:01] <jmkasunich> bed soon
[04:33:02] <cradek> I have a full weekend so I don't know exactly when I'll be around, but I'll try to watch as usual
[04:33:07] <jmkasunich> ok
[04:33:46] <cradek> goodnight then, thanks for helping hash this out
[04:34:05] <jmkasunich> you're welcome
[04:41:59] <jmkasunich> I condensed the discussion a little and posted it at
http://pastebin.ca/236912
[04:42:31] <jmkasunich> alex_joni: take a look (and/or read back, but the discussion was quite long)
[07:56:05] <alex_joni> jmkasunich: now you tell me you already condensed it.. and I read the whole thing back ;)
[07:56:16] <SWPadnos> heh
[07:57:13] <alex_joni> jmkasunich, cradek: I can certainly do the 'upper' part (interp and cannon) if we decide on what you have there (btw. it looks good to me)
[14:24:02] <jepler> weird
[14:24:16] <alex_joni> what is?
[14:24:51] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/move-after-g76.png
[14:25:23] <jepler> the highlighted move is "g0x.5" but the move in the preview plot and in the backplot had motion in z as well
[14:25:59] <jepler> it looks like the Z component of the move went back to where the g76 started, not where it ended
[14:26:08] <jepler> cradek: maybe this bears looking into? ^^^
[14:26:20] <alex_joni> weird indeed
[14:26:40] <alex_joni> he'll say it's a feature :D
[14:33:26] <Lerneaen_Hydra> is this possibly a canned threading cycle I see? :D
[14:33:58] <jepler> Lerneaen_Hydra: yes
[14:34:15] <alex_joni> G76 it is
[14:34:41] <jepler> lathe_pawn.ngc doesn't work for me
[14:34:53] <Lerneaen_Hydra> what errors out?
[14:34:55] <jepler> Radius from end of arc differs from radius to start
[14:35:06] <Lerneaen_Hydra> is your lathe set to radius in X?
[14:35:06] <alex_joni> Lerneaen_Hydra: thought you sent me the same one?
[14:35:12] <jepler> the error is repoted on line 94
[14:35:22] <Lerneaen_Hydra> alex_joni: I thought I did too
[14:35:44] <alex_joni> hang on .. I have the one I ran to make the screenshot (somewhere on the laptop)
[14:35:57] <Lerneaen_Hydra> I had issues with this too, it was becuase of the "is X measured in diameteral or radial mode"
[14:36:37] <Lerneaen_Hydra> I opted to go with radial mode, as it's IMO less confusing (but not the most common, at least WRT commercial lathes)
[14:37:00] <Lerneaen_Hydra> come to think of it, this may be a good thing to have as a G-code (like the g20/g21 code)
[14:37:25] <Lerneaen_Hydra> as there will no doubt be camps that think their choice is correct
[14:38:05] <Lerneaen_Hydra> ...and with that I scared all the devs off of #emc-devel :D
[14:38:17] <jepler> it seems like lots of problems will creep in if you try to do diameter. for instance, a "circular arc" isn't circular anymore
[14:38:29] <alex_joni> jepler: did you remove core_axis.hal ?
[14:39:03] <Lerneaen_Hydra> yeah, exactly, you get stuff with IJK being defined radially, but the start/endpoint defined diameterially, and so on
[14:39:06] <Lerneaen_Hydra> really, really nasty
[14:39:12] <Lerneaen_Hydra> so I go with radial
[14:39:25] <Lerneaen_Hydra> as it stands though the norm is to use diamter mode.
[14:39:27] <Lerneaen_Hydra> * Lerneaen_Hydra shrugs
[14:39:42] <jepler> alex_joni: I don't know what's up with core_axis.hal
[14:39:44] <alex_joni> jepler: it's referenced in the nist-lathe config..
[14:40:08] <alex_joni> but I can't seem to find it
[14:40:21] <jepler> I see that too
[14:40:58] <alex_joni> odd.. I remember running that config
[14:41:20] <jepler> I think that line should just be removed
[14:41:29] <jepler> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/configs/common/Attic/core_axis.hal
[14:42:00] <jepler> there's now a sim/lathe configuration as well
[14:45:28] <alex_joni> this is odd..
[14:45:39] <alex_joni> I just found the older ngc I used to make the screenshot
[14:45:43] <Lerneaen_Hydra> does anyone have any thoughts wrt radius/diamter mode?
[14:45:44] <alex_joni> and it gives the same error..
[14:45:49] <Lerneaen_Hydra> O.o
[14:45:53] <Lerneaen_Hydra> that's fishy
[14:45:56] <alex_joni> Lerneaen_Hydra: yeah.. better accuracy
[14:45:56] <Lerneaen_Hydra> same config?
[14:46:14] <Lerneaen_Hydra> alex_joni: what is better accuracy?
[14:46:24] <alex_joni> more decimals after the .
[14:46:34] <alex_joni> on the CAM
[14:46:44] <Lerneaen_Hydra> oh, you mean the file had too few decimals?
[14:46:48] <alex_joni> I think so
[14:46:49] <Lerneaen_Hydra> should I generate a new one?
[14:47:01] <Lerneaen_Hydra> how many can the interpreter read, at most?
[14:47:15] <alex_joni> I think 4 should be ok
[14:47:19] <Lerneaen_Hydra> I might as well set the cam app as that +1
[14:47:28] <Lerneaen_Hydra> metric or inch?
[14:47:34] <Lerneaen_Hydra> err, nevermind that
[14:47:37] <Lerneaen_Hydra> silly me
[14:47:57] <alex_joni> actually I'm puzzled.. I remembered 4 for inch, 3 for mm
[14:48:09] <Lerneaen_Hydra> 3 is what I see in axis
[14:48:15] <Lerneaen_Hydra> like 12.345mm
[14:48:39] <Lerneaen_Hydra> that gets you to µm level. hmm. that's almost a bit coarse
[14:48:56] <Lerneaen_Hydra> the commercial lathes go to 0.1µm levels
[14:52:05] <jepler> yes, the documentation suggests 3 decimals for mm
[14:52:15] <alex_joni> it has 3 already
[14:52:49] <jepler> #define TOLERANCE_MM 0.005
[14:53:02] <Lerneaen_Hydra> wtf, my CAM app is fighting me
[14:53:25] <Lerneaen_Hydra> it doesn't want to give more than 3 decimals, just a second
[14:56:32] <jepler> CURRENT:-14.2040 5.6850
[14:56:32] <jepler> END:-16.4820 5.0580
[14:56:32] <jepler> IJ:-2.4280 0.0000
[14:56:32] <jepler> CTR:-16.6320 5.6850
[14:56:32] <jepler> RAD:2.4280 0.6447
[14:56:35] <jepler> TOL:0.0050
[14:57:02] <jepler> unless this debugging information is incorrect, it's more than a difference in decimal places
[14:57:20] <alex_joni> the IJ you mean?
[14:58:40] <jepler> it thinks the endpoint is only .64 away from the start
[14:59:17] <alex_joni> shouldn't it be more like 2.2 mm ?
[14:59:33] <jepler> ignore that it says IJ, the function convert_arc2 always refers to arcs as though they are XY arcs
[14:59:43] <Lerneaen_Hydra> I've got a file with 10 decimals, does anyone want/need it, or are you already onto what may be the problem?
[14:59:58] <alex_joni> Lerneaen_Hydra: 10 is too much
[15:00:07] <Lerneaen_Hydra> what's the maximum?
[15:00:29] <alex_joni> I think the interpreter will accept it, but it's hard to follow
[15:00:47] <Lerneaen_Hydra> ok, so 5 decimals?
[15:01:10] <alex_joni> if you can
[15:01:42] <Lerneaen_Hydra> do both of you want it?
[15:01:45] <Lerneaen_Hydra> or just jepler?
[15:01:49] <alex_joni> I'll commit it
[15:01:55] <jepler> make sure it actually works first
[15:01:59] <alex_joni> jepler: sure
[15:02:08] <Lerneaen_Hydra> alex_joni: have you got an emc machine near you?
[15:02:13] <alex_joni> jepler: I didn't check because this worked before
[15:02:19] <alex_joni> Lerneaen_Hydra: axis sim is running
[15:02:24] <Lerneaen_Hydra> so why isn't it working now?
[15:02:38] <alex_joni> * alex_joni mumbles something about data corruption
[15:02:46] <jepler> this arc is plainly bogus, it's wildly wrong
[15:02:52] <jepler> it's not just about what's in the 4th or 5th decimal place
[15:03:02] <Lerneaen_Hydra> then how could it load in the first place?
[15:03:32] <Lerneaen_Hydra> either the interpreter didn't find the error (very unlikely) or maybe some corruption?
[15:03:38] <Lerneaen_Hydra> or maybe the wrong file?
[15:03:50] <alex_joni> more likely
[15:05:56] <Lerneaen_Hydra> sent
[15:06:50] <alex_joni> Lerneaen_Hydra: it's not the same file
[15:06:59] <alex_joni> I just checked the screenshots I made earlier
[15:07:04] <alex_joni> and the numbers are not the same
[15:07:07] <Lerneaen_Hydra> oh
[15:07:12] <Lerneaen_Hydra> wth was that file?
[15:07:18] <Lerneaen_Hydra> * Lerneaen_Hydra goes and looks in the logs
[15:07:43] <alex_joni> it was the same piece
[15:07:53] <Lerneaen_Hydra> but?
[15:07:56] <alex_joni> called lathe_test.ngc on my machien
[15:08:01] <alex_joni> slightly different numbers
[15:08:08] <alex_joni> maybe you used a different tool in the CAM
[15:08:10] <Lerneaen_Hydra> * Lerneaen_Hydra cringes
[15:08:12] <Lerneaen_Hydra> slightly?
[15:08:19] <Lerneaen_Hydra> hmm
[15:08:30] <Lerneaen_Hydra> maybe nose radius comp on/off
[15:08:43] <alex_joni> http://wiki.linuxcnc.org/uploads/axis-lathe-mm.png
[15:09:00] <Lerneaen_Hydra> that should be the part I just sent
[15:09:24] <alex_joni> I get the same error
[15:09:42] <Lerneaen_Hydra> with the file I just sent?
[15:09:48] <alex_joni> the part you sent is straight in the lower part of it
[15:09:57] <alex_joni> the one in the snapshot has a model there
[15:10:56] <alex_joni> might be because it aborts interpreting it
[15:11:34] <Lerneaen_Hydra> http://img255.imageshack.us/my.php?image=temp1mr1.jpg
[15:11:37] <Lerneaen_Hydra> that should be the file I just sent
[15:13:01] <Lerneaen_Hydra> * Lerneaen_Hydra is getting confused with indirect references
[15:13:26] <Lerneaen_Hydra> that screenshot is the entire file
[15:13:58] <Lerneaen_Hydra> by that screenshot I mean both the screenshot I posted a link to and the one you had
[15:14:04] <jepler> Lerneaen_Hydra: in the AXIS preview, the file alex added to CVS earlier looks like it is "straight in the lower part of it", because it aborts without fully loading the file.
[15:14:07] <Lerneaen_Hydra> all the moves seem to be accounted for
[15:14:23] <Lerneaen_Hydra> oh, ok
[15:14:30] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lathe-pawn-bad.png
[15:14:48] <Lerneaen_Hydra> oh, ok. now I get it
[15:14:52] <alex_joni> right.. that's what I get too
[15:14:53] <Lerneaen_Hydra> that is very, very strange
[15:15:07] <Lerneaen_Hydra> becuase some arcs were sucesfully done
[15:15:54] <Lerneaen_Hydra> what about the file I just send alex?
[15:15:58] <alex_joni> same
[15:15:59] <jepler> if I chanve the arc on line 95 to a G1 move I get another error on line 122
[15:16:25] <jepler> It's another arc with no I-word
[15:17:00] <Lerneaen_Hydra> there hasn't been a recent change to the interpreter has there?
[15:17:32] <jepler> not in the interpretation of arcs
[15:18:55] <Lerneaen_Hydra> alex_joni: could you test the file I just sent?
[15:19:03] <alex_joni> same problem
[15:19:07] <Lerneaen_Hydra> I compiled that with a known-working codegen
[15:19:11] <Lerneaen_Hydra> I sent one just a second ago
[15:19:17] <alex_joni> oh.. hang on
[15:20:07] <alex_joni> get the error on line 122
[15:20:11] <alex_joni> same line same error
[15:20:41] <alex_joni> sorry.. 112
[15:20:47] <Lerneaen_Hydra> wtf!?
[15:20:53] <alex_joni> it's actually 113
[15:21:00] <alex_joni> the error says around 112
[15:21:30] <alex_joni> N113 G02 X5.058 Z-16.482 K-2.428
[15:21:52] <alex_joni> that used to be 95 before (without the comments at the top)
[15:22:52] <Lerneaen_Hydra> 95 instead of?
[15:22:53] <Lerneaen_Hydra> oh, error lin
[15:23:03] <Lerneaen_Hydra> new mail sent :/
[15:23:37] <Lerneaen_Hydra> if this doesn't work then something is seriouly fscked with my CAM, as this is with an older version of that file with an old compiler
[15:23:48] <Lerneaen_Hydra> (or I'm sending the same file all the time ;) )
[15:24:06] <jepler> a little experimentation using R- instead if I-K- shows that the radius of the arc should be around 4 or 5 to look right
[15:25:38] <alex_joni> Lerneaen_Hydra: same problem
[15:25:55] <alex_joni> jepler: IK are coordinates of the center.. right?
[15:26:04] <Lerneaen_Hydra> alex_joni: ok, for now I'll have to let this rest, I'll test this more myself later
[15:26:36] <alex_joni> ok, nm
[15:26:44] <alex_joni> jepler: stop chasing this.. I'll sort it out
[15:26:54] <alex_joni> don't waste your time with it ;-)
[15:26:57] <jepler> alex_joni: Add I to the prior X to get the center
[15:27:05] <Lerneaen_Hydra> I don't want a borken codegen ;)
[15:27:11] <alex_joni> jepler: thanks
[15:27:31] <alex_joni> jepler: short feature request?
[15:27:49] <alex_joni> I looked a bit at open_file in axis.tcl then in axis.py
[15:27:53] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/debug_arc.patch
[15:27:57] <alex_joni> it called tk_openfile or similar
[15:28:03] <Lerneaen_Hydra> jepler: so IJK is relative to previous XYZ coord?
[15:28:09] <alex_joni> Lerneaen_Hydra: yes
[15:28:11] <Lerneaen_Hydra> ok
[15:28:13] <alex_joni> always has been
[15:28:13] <Lerneaen_Hydra> good
[15:28:21] <jepler> alex_joni: yes, that's how it works
[15:28:23] <Lerneaen_Hydra> yeah, just (in)sanity check
[15:28:44] <alex_joni> jepler: I know that.. but I don't know how to alter it to stop displaying folders and files starting with .
[15:29:08] <alex_joni> it's probably somewhere in the tk docs
[15:29:20] <jepler> alex_joni: it would be in 'man tk_getOpenFile', except that there is no such option
[15:29:28] <alex_joni> darn ;/
[15:29:37] <jepler> alex_joni: like the rest of Tk, tk_getOpenFile is a halfway-done pile of turds
[15:29:48] <alex_joni> ok, forget I asked
[15:30:07] <alex_joni> rm -rf .* :D
[15:30:36] <alex_joni> jepler: any reason not to commit that patch?
[15:31:00] <alex_joni> except that it will print some 0's once in a while?
[15:31:00] <jepler> alex_joni: debug_arc.patch? Yes, because spewing lots of debugging information to stderr is a bad idea.
[15:33:40] <jepler> hm actually there may be an undocumented way to make it stop showing .-files
[15:34:41] <alex_joni> hmm.. I thought you only added K to the existing IJ, seems I was wrong
[15:34:53] <alex_joni> maybe a check for def DEBUG or something like that
[15:35:13] <alex_joni> * alex_joni goes back to geometrics 101
[15:35:33] <jepler> center = oldX+I, oldY+J, oldZ+K
[15:35:39] <jepler> but the bug is in lh's post, not in emc
[15:35:49] <alex_joni> yeah, that's what I'm trying to fix
[15:36:18] <Lerneaen_Hydra> hmm, very strange, I've never had issues with arcs in the post
[15:36:32] <Lerneaen_Hydra> at least not after I set it to radial mode
[15:38:58] <alex_joni> jepler: I4.37075 was missing from line 95
[15:39:26] <alex_joni> my math foo is a bit rusty :)
[15:39:40] <jepler> how do you know that's the missing value?
[15:39:46] <alex_joni> I calculated it
[15:39:49] <alex_joni> by hand
[15:40:10] <alex_joni> using AXIS to understand the part
[15:40:59] <Lerneaen_Hydra> alex, I'm going to fix the post, don't bother doing that
[15:41:32] <alex_joni> I'm done
[15:41:38] <alex_joni> the I was missing from that line
[15:42:19] <Lerneaen_Hydra> and all the other lines were ok+
[15:42:22] <Lerneaen_Hydra> ?
[15:42:23] <alex_joni> yes
[15:42:26] <alex_joni> only those 2
[15:42:33] <jepler> there were 2 -- both missing "I"
[15:43:14] <alex_joni> bad spelling :(
[15:43:17] <Lerneaen_Hydra> very fishy
[15:43:48] <alex_joni> jepler: the two arcs had the same arc center
[15:43:56] <Lerneaen_Hydra> alex_joni: were the line-endings bad?
[15:44:10] <alex_joni> only different IK's because of the different initial positions
[15:44:16] <alex_joni> Lerneaen_Hydra: not perfect either
[15:44:38] <alex_joni> Lerneaen_Hydra: they don't matter much to the interp, but they annoy anyone opening the file in an editor
[15:44:48] <Lerneaen_Hydra> oh, ok
[15:45:11] <Lerneaen_Hydra> what do you mean by different initial positions?
[15:46:06] <alex_joni> Lerneaen_Hydra: the IK are always relative to the start of the G02/G03
[15:46:17] <Lerneaen_Hydra> oh, yeah
[15:47:08] <alex_joni> there are 2 arcs next to each other (one going from 5.685, -14.204 to 5.058, -16.482 and the other from 5.058, -16.482 to 5.685, -18.76
[15:47:10] <jepler> see you guys later
[15:47:20] <alex_joni> jepler: does it run ok now?
[15:47:28] <jepler> OK I'll check before I go
[15:47:35] <alex_joni> thanks.. only if it opens
[15:47:40] <jepler> yes
[15:47:48] <alex_joni> ok. thanks for pointing it out
[15:48:02] <alex_joni> see you
[16:26:23] <cradek> jepler: about your X move: it ends up at z.2 x.5 which is what you get from lines 20 and 22 - I agree it's a little surprising, maybe it should have another move back to z.2 at the end of the cycle
[16:27:37] <cradek> I can also imagine having it end at x.2 z-.5, since that's the end of the "safe move" specified in the g76
[16:29:19] <alex_joni> cradek: how about just moving x ?
[16:30:13] <cradek> the question at the root of the problem is where should the tool end up at the end of the cycle
[16:31:34] <alex_joni> I see
[16:31:41] <alex_joni> G76 is a threading cycle?
[16:31:49] <cradek> yes
[16:32:03] <alex_joni> I suspect the end move is where it ends
[16:32:30] <cradek> the idea is that you specify a "safe move" outside the material, then some depths and angles so it cuts offset from the safe move in various ways
[16:33:15] <cradek> the safe move in this program is from .2,.2 to .2,-.5
[16:33:22] <alex_joni> http://emergent.unpy.net/index.cgi-files/sandbox/move-after-g76.png
[16:33:26] <alex_joni> I'm looking at that
[16:33:41] <alex_joni> shouldn't the moves get shorter? or do they stay constant in length?
[16:33:42] <cradek> that's just a little bug
[16:34:06] <cradek> they stay constant length but get offset in Z because of the q29 infeed angle
[16:34:25] <alex_joni> is that ok regarding material cut at the end of the thread?
[16:34:27] <cradek> so at the end it stops offset by the infeed angle's distance
[16:34:47] <cradek> yes the axis only moves to z-.5 at the last cuts
[16:35:30] <cradek> earlier ones stop a little short like they should
[16:35:53] <alex_joni> obviously I know very little about threading ;)
[16:36:00] <cradek> because you're "sliding" the tool along the "right" side of the thread cut, cutting mostly on the "left"
[16:36:24] <alex_joni> ok, I can understand now
[16:36:41] <alex_joni> had a bit of problems picturing that the part is actually turning :)
[16:37:00] <alex_joni> * alex_joni can't express himself today for what it's worth :(
[16:37:36] <cradek> seems fine to me
[16:37:44] <alex_joni> seems awfull to me :(
[16:37:55] <alex_joni> anyways.. care to talk about overrides?
[16:37:55] <cradek> what do you think about the feed override override scheme stuff we came up with?
[16:38:04] <alex_joni> I think it's mostly ok
[16:38:51] <cradek> what part do you not like?
[16:38:57] <alex_joni> I can work on M48.1, M48.2 and M48.3 right now
[16:39:05] <alex_joni> the parts I don't fully understand
[16:39:08] <alex_joni> ;-)
[16:39:22] <alex_joni> * alex_joni is having issues concentrating today
[16:39:52] <alex_joni> too much distraction around me
[16:40:06] <cradek> maybe tomorrow then
[16:40:17] <alex_joni> no, I can get my things together ;)
[16:40:27] <alex_joni> reading the
http://pastebin.ca/236912 again
[16:41:12] <alex_joni> I'll add M[48,49].[1,2,3]
[16:41:14] <cradek> I like jmk's idea of getting rid of g50/g51 and using extended m codes
[16:41:35] <alex_joni> ok, and delete G50/G51 in the process
[16:42:09] <cradek> great, thank you
[16:42:29] <alex_joni> I'll probably finish it sometimes in the next hour or so
[16:42:51] <alex_joni> what happens afterwards? can you & jmk look at the motion & tp parts of it?
[16:42:59] <alex_joni> I think I read you had some of it done already
[16:43:00] <cradek> yes definitely
[16:43:17] <cradek> well most of it is wrong but it wasn't much :-)
[16:43:26] <alex_joni> heh.. ok ;)
[16:43:50] <alex_joni> seen that lathe page I put up? (I sure can use better wording)
[16:44:19] <alex_joni> http://www.linuxcnc.org/index.php?option=com_content&task=view&id=28&Itemid=13
[16:44:35] <cradek> so there will be separate canon calls for [ENABLE,DISABLE]_[FEED,SPINDLE]_OVERRIDE and [ENABLE,DISABLE]_ADAPTIVE_FEED ?
[16:44:45] <alex_joni> yes
[16:44:51] <alex_joni> most should already be there I think
[16:45:19] <cradek> cool!
[16:45:29] <cradek> some of the photos are not there yet?
[16:45:36] <alex_joni> ENABLE,DISABLE_FEED_OVERRIDE
[16:45:50] <alex_joni> cradek: should be (linked from the wiki).. any missing?
[16:46:06] <cradek> yes I see only the gui
[16:46:10] <alex_joni> maybe your browser doesn't do flash to display the movie player?
[16:46:12] <alex_joni> that's odd
[16:46:16] <cradek> oh it's adblock
[16:46:31] <alex_joni> different page it thinks
[16:46:40] <alex_joni> wiki.linuxcnc.org vs. www.linuxcnc.org
[16:46:49] <cradek> the matching pattern is ads/
[16:47:11] <cradek> the matching pattern is ads/*.jpg
[16:47:17] <alex_joni> ads??
[16:47:23] <cradek> uploads
[16:47:23] <alex_joni> ahh.. from uploads
[16:47:29] <cradek> but that's my problem :-P
[16:48:02] <cradek> wonder if that's a rule that came with adblock, or one I wrote
[16:48:57] <cradek> there I fixed adblock
[16:49:20] <alex_joni> any good?
[16:49:52] <cradek> very nice
[16:50:08] <alex_joni> LH did all the hard work :)
[16:50:21] <alex_joni> and you and jepler (on axis)
[16:50:30] <Lerneaen_Hydra> huh? what did I do?
[16:50:57] <Lerneaen_Hydra> oh, I would say that alex did the work but oh well :P
[16:51:09] <Lerneaen_Hydra> I just did the retrofit and took a few images
[16:59:25] <jepler> nice job on that page
[17:00:25] <alex_joni> jepler: parts from your manual again ;)
[17:01:05] <alex_joni> jepler: I set up that section for various Technical Articles
[17:01:18] <alex_joni> jepler: if you have any ideas regarding that I'd love to hear it
[17:10:44] <alex_joni> hmm.. there's no way to specify M48.1 unless I change the whole way M's are treated in the interp
[17:46:52] <SWPadnos> hi folks
[17:47:05] <alex_joni> hi SWPadnos
[17:47:14] <alex_joni> or should I say morning SWPadnos ;)
[17:47:32] <SWPadnos> I was just writing a response to Ken Lerman's response to Ray's mail
[17:47:43] <SWPadnos> afternoon, actually ;)
[17:47:48] <SWPadnos> (barely)
[17:48:42] <alex_joni> nice
[17:49:26] <SWPadnos> more or less what I'm saying is that we can move the lists, but there are issues
[17:49:34] <alex_joni> I know..
[17:49:38] <SWPadnos> 1) there may be more administration
[17:49:43] <SWPadnos> 2) the archives
[17:49:46] <alex_joni> I wrote an response to ray directly
[17:50:02] <alex_joni> I thik he used an email addy that wasn't subscribed
[17:50:07] <SWPadnos> 3) moving subscriber lists (and associated things the subscribers may have to do to filters, etc)
[17:50:07] <alex_joni> and then the email bounced
[17:50:10] <SWPadnos> ok
[17:50:21] <alex_joni> but I might have misread his mail
[17:50:21] <alex_joni> :)
[17:50:36] <SWPadnos> I think he used a new address, because his real one bounced
[17:51:07] <alex_joni> as list admin I only got an bounce notify on his new addy
[17:51:38] <SWPadnos> right - if spamcop has decided that his old address is crap, you won't even see anything
[17:51:52] <alex_joni> might be so :)
[17:53:04] <SWPadnos> well, you don't see messages about bounces from luv2luvU@hongkongcathouse.co.hk, do you? ;)
[17:53:25] <alex_joni> I'd luv2luv2see
[17:53:29] <SWPadnos> heh
[17:53:39] <alex_joni> :-P
[17:57:02] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[18:21:20] <jepler> looks like up.net is passing spam at the moment.
http://groups.google.com/group/news.admin.net-abuse.sightings/browse_thread/thread/d8fa5d0b8359f4d4/e304d67a69a4d5a0 http://www.senderbase.com/?searchBy=ipaddress&sb=1&searchString=205.242.56.58
[18:21:45] <alex_joni> jepler: mind if I switch building docs by default off?
[18:22:41] <alex_joni> although I'd wait for jmk before doing that.. I know he has some compile_farm scripts that invoke configure --disable-build-documentation
[18:23:19] <jepler> alex_joni: go right ahead
[18:23:25] <jepler> shouldn't disturb the farm should it?
[18:23:46] <alex_joni> I think it should
[18:24:04] <alex_joni> I changed the --disable-build to --enable-build
[18:24:10] <alex_joni> maybe I should leave both
[18:26:19] <jepler> configure should make both work automatically
[18:27:02] <alex_joni> hmm.. it does ;(
[18:27:03] <alex_joni> ;)
[18:41:59] <alex_joni> jepler: didn't you add an icon for optional stop?
[18:42:14] <alex_joni> I see the setting is on the menu now (which is fine too imo)
[18:55:13] <jepler> alex_joni: I put the icon in cvs but then decided to only add a menu item for now
[18:58:45] <alex_joni> ok, sounds sane
[19:16:01] <jepler> just made sure my automatic doc rebuilding still works .. seems to after I spell --enable-build-documentation correctly
[19:21:00] <alex_joni> phew.. that means I spelled it correctly too :)
[19:27:14] <alex_joni> http://pastebin.ca/237821
[19:31:44] <jepler> you probably know by now what to change in axis ..
[19:31:56] <jepler> if you like, I can do the documentation
[19:32:41] <alex_joni> I'd like it approved by chris & jmk first
[19:33:03] <alex_joni> jmk said initially to use M48/M49
[19:33:10] <alex_joni> and M48.1 M48.2 M48.3
[19:33:19] <alex_joni> but that only works for G-codes
[19:33:35] <alex_joni> I ended up using M48..55
[19:33:46] <jepler> yuck, that's a lot of codes
[19:33:49] <SWPadnos> how about M48/M49 P{1,2,3}
[19:34:01] <SWPadnos> no P means all, 1,2,3 are FO, SO, AO
[19:34:23] <alex_joni> I think jmk meant AF to be separate
[19:34:45] <SWPadnos> right - by default AF shouldn't be affected
[19:34:46] <alex_joni> M48/49 (no P all, P1 FO, P2 SO), M50/M51 for AF ?
[19:35:11] <SWPadnos> I'd take a look at a list of M codes first
[19:35:17] <alex_joni> it's quite short
[19:35:37] <SWPadnos> "standard" M codes - like from Machinery's handbook
[19:35:59] <alex_joni> group 4 = {m0,m1,m2,m30,m60} - stopping
[19:35:59] <alex_joni> group 5 = {m62,m63,m64,m65} - turn I/O point on/off
[19:35:59] <alex_joni> group 6 = {m6} - tool change
[19:35:59] <alex_joni> group 7 = {m3,m4,m5} - spindle turning
[19:35:59] <alex_joni> group 8 = {m7,m8,m9} - coolant
[19:36:02] <alex_joni> group 9 = {m48,m49, - feed and speed override switch bypass
[19:36:04] <alex_joni> m50,m51, - feed override switch bypass
[19:36:07] <alex_joni> m52,m53, - spindle speed override switch bypass
[19:36:10] <alex_joni> m54,m55} - adaptive feed override switch bypass
[19:36:12] <alex_joni> group 10 = {m100..m199} - user-defined
[20:54:59] <jmkasunich> hi guys
[20:55:07] <alex_joni> hi jmk
[20:55:09] <jmkasunich> had lots of stuff to do this morming
[20:55:13] <alex_joni> np
[20:55:19] <LH_school> woo, jmk
[20:55:19] <jmkasunich> the inability to do M48.x is dissapointing
[20:55:23] <alex_joni> wanted to talk to you about M4x
[20:55:36] <alex_joni> jmkasunich: currently only integer numbers of Mxx are allowed
[20:55:45] <jmkasunich> right, I read back and saw that
[20:55:48] <alex_joni> but there are about 200 allowed, and about 20 used by default
[20:55:57] <jmkasunich> I don't like the idea of having a bunch of them though
[20:56:10] <jmkasunich> all the various overrides and such are similar, and should be handled similarly
[20:56:14] <alex_joni> then what SWP suggested?
[20:56:20] <alex_joni> M48/49 Px
[20:56:26] <alex_joni> if P missing, all on or off
[20:56:27] <jmkasunich> yeah
[20:56:30] <jmkasunich> not all
[20:56:32] <alex_joni> P1 - FO, P2 -SO
[20:56:39] <alex_joni> yeah, FO & SO
[20:56:41] <jmkasunich> if P is missing, FO and SO only are affected
[20:56:50] <alex_joni> right
[20:56:57] <jmkasunich> with P, 1 = SO, 2 = FO, 3 = AF, and maybe 4 = FH (feedhold)
[20:57:32] <alex_joni> ok..
[20:58:33] <alex_joni> * alex_joni gets dirty
[20:58:39] <jmkasunich> I'll start working on the RT stuff in a few mins
[21:00:33] <alex_joni> jmkasunich: question though
[21:00:45] <alex_joni> with different m-codes there's a way to display it in the GUI
[21:00:57] <alex_joni> with only M48/M49 there's no way to show what is active or not
[21:01:13] <jmkasunich> crap
[21:01:31] <jmkasunich> thats a good point
[21:01:50] <jmkasunich> it just sucks that you have to remember 10 M codes now
[21:01:54] <alex_joni> would it be that bad to have 24 mcodes instead of 18 ?
[21:02:07] <alex_joni> * alex_joni doesn't remember any
[21:02:09] <jmkasunich> (the original 2, and 8 more for the single function commands)
[21:02:12] <alex_joni> I look them up anyways
[21:02:15] <jmkasunich> heh
[21:02:49] <jmkasunich> so M50 thru 57?
[21:02:59] <alex_joni> 55 right now
[21:03:06] <alex_joni> 56/57 would be for feedhold
[21:03:10] <jmkasunich> yeah
[21:03:19] <alex_joni> m48..m57
[21:03:35] <jmkasunich> right, but I wasn't counting the new ones
[21:03:48] <jmkasunich> old ones
[21:04:12] <alex_joni> right
[21:04:24] <alex_joni> how about I add one for each?
[21:04:31] <alex_joni> M50 P1/P0
[21:04:47] <alex_joni> for FO
[21:05:03] <alex_joni> M51 for SO, M52 for AF, M53 for FH
[21:05:12] <jmkasunich> P0 = disable, P1 = enable?
[21:05:16] <alex_joni> yeah
[21:05:27] <jmkasunich> M51 alone would also mean enable I think
[21:05:37] <alex_joni> right, and be the default
[21:05:44] <alex_joni> except for AF
[21:05:57] <alex_joni> maybe FH too? don't know about that
[21:06:05] <jmkasunich> that way when you display the current state, you just show M51 to say "its enabled" and nothing to show its disabled
[21:06:13] <alex_joni> right
[21:06:28] <alex_joni> not sure that works though ;)
[21:06:32] <alex_joni> * alex_joni tries
[21:10:27] <alex_joni> that works
[21:17:31] <alex_joni_> logger_dev: bookmark
[21:17:31] <alex_joni_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-04.txt
[21:21:30] <alex_joni_> jmkasunich: so it's ok like that? M50, 51, 52 & 53 ?
[21:22:35] <jmkasunich> yes
[21:22:46] <alex_joni_> * alex_joni_ gets busy
[21:29:06] <alex_joni_> alex_joni_ is now known as alex_joni
[21:32:31] <alex_joni> should feed hold be enabled by default?
[21:33:52] <jmkasunich> I think so
[21:34:14] <jmkasunich> the integrator can always re-arrange things with "initial g-codes" in the inifile
[21:35:15] <alex_joni> right
[21:35:22] <alex_joni> * alex_joni did it that way
[21:55:39] <alex_joni> jmkasunich: about done
[21:55:43] <alex_joni> need to test still
[21:57:33] <jmkasunich> I'm not even started yet, so no hurry
[22:05:39] <alex_joni> mind if I show M48 if both FO and SO are on
[22:05:44] <alex_joni> and M49 if both are off?
[22:06:04] <alex_joni> if only one then M50 or M51
[22:10:59] <alex_joni> * alex_joni loves changing config.h.in :D
[22:11:41] <alex_joni> it's sweet to watch everything getting rebuilt
[22:20:29] <alex_joni> jmkasunich:
http://pastebin.ca/238241
[22:39:33] <alex_joni> * alex_joni wonders about commiting :D
[22:40:28] <jmkasunich> case EMCMOT_FEED_HOLD_OVERRIDE:
[22:40:41] <jmkasunich> how about FEED_HOLE_ENABLE (or DISABLE)?
[22:40:47] <alex_joni> it's both
[22:41:00] <jmkasunich> because FEED_OVERRIDE_OVERRIDE is just too strange
[22:41:02] <alex_joni> * alex_joni couldn't decide on a better name :(
[22:41:30] <jmkasunich> the way I see it, FEED_OVERRIDE is the ability to set a scale factor other than 1
[22:41:36] <alex_joni> feed_override is overriding the scale
[22:41:38] <alex_joni> right
[22:41:45] <jmkasunich> FEED_OVERRIDE_ENABLE (on/off) is enables or disables FEED_OVERRIDE
[22:41:59] <alex_joni> ok, ENABLE it is then
[22:42:08] <alex_joni> but ENABLE off is twisted :D
[22:42:41] <alex_joni> hi chris
[22:42:52] <jmkasunich> FEED_OVERRIDE_ENABLE(off) isn't that twisted ;-)
[22:43:15] <alex_joni> * alex_joni disables himself
[22:43:30] <alex_joni> forgot HOLD there
[22:43:48] <alex_joni> FEED_OVERRIDE_HOLD_ENABLE(off - 1)
[22:44:03] <jmkasunich> huh?
[22:44:14] <jmkasunich> FEED_OVERRIDE is one thing, FEED_HOLD is another
[22:44:26] <alex_joni> you weren't joking?
[22:44:28] <alex_joni> I was..
[22:44:55] <alex_joni> I'll just make it FEED_HOLD_ENABLE all over
[22:44:57] <jmkasunich> I was....
[22:44:59] <jmkasunich> confused
[22:46:30] <jmkasunich> there are four things: feed_override, spindle_override, adaptive_feed, and feed_hole
[22:46:38] <jmkasunich> each of them can be enabled or disabled individually
[22:46:41] <alex_joni> yes
[22:47:04] <jmkasunich> two of them can also be enabled or disabled together (M48/49) but that can be handled by calling both canonicals
[22:47:15] <alex_joni> right, that's how it's done
[22:47:37] <jmkasunich> feed and spindle override also need canonicals to set the values
[22:47:53] <jmkasunich> AF and FH do not, those "values" come in thru HAL in realtime
[22:47:53] <alex_joni> that's a different issue
[22:48:08] <alex_joni> different messages different canonicals
[22:48:13] <alex_joni> no connection
[22:48:22] <jmkasunich> maybe I misunderstood your original comment (or the pastebin)
[22:48:42] <jmkasunich> + EMCMOT_FEED_HOLD_OVERRIDE, /* enable/disable feed_hold */
[22:49:09] <jmkasunich> you are using the word override, but the thing you are enabling/disabling is not feed override, its feedhold
[22:49:10] <alex_joni> yes, and you just said (and I agreed) I'll make that EMCMOT_FEED_HOLD_ENABLE
[22:49:15] <jmkasunich> ok
[22:49:33] <alex_joni> I used OVERRIDE for the ability of the user to turn it on/off
[22:49:37] <alex_joni> not the best wording
[22:49:57] <alex_joni> cradek's toggling
[22:50:11] <jmkasunich> ;-)
[22:50:15] <jmkasunich> hi chris
[22:50:20] <cradek> sorry
[22:50:28] <alex_joni> * alex_joni ties chris'es R input HIGH
[22:50:30] <cradek> working on a new server
[22:50:48] <alex_joni> cradek: no problem.. mine died too
[22:50:57] <alex_joni> actually I suspect a switch between it and the internet
[22:50:58] <alex_joni> :(
[22:51:16] <jmkasunich> alex_joni: in the pastebin, you have ENABLE_<whatever> and DISABLE_<whatever>, starting at line 77
[22:51:20] <jmkasunich> that seems just fine to me
[22:51:32] <jmkasunich> but what is line 52 all about?
[22:52:08] <alex_joni> 77 are canonicals
[22:52:13] <alex_joni> 52 is from motion.h
[22:52:51] <jmkasunich> since in this case the canonicals map directly to motion commands, why don't we use the same names (with EMCMOT_ infront)
[22:53:04] <jmkasunich> the line 77 names are perfect IMHO
[22:53:09] <alex_joni> I'm ok with that.. but there's only one EMCMOT_ function
[22:53:18] <jmkasunich> huh?
[22:53:19] <alex_joni> unless you want both.. which would be bad imo
[22:53:27] <alex_joni> no ENABLE_FOO & DISABLE_FOO
[22:53:50] <jmkasunich> oh, you mean only four, not eight
[22:53:53] <alex_joni> yes
[22:54:03] <jmkasunich> I thought you really meant only one
[22:54:13] <alex_joni> talking about FO for example
[22:54:15] <jmkasunich> agreed, eight doesn't make sense
[22:54:26] <alex_joni> if you come up with naming I can change
[22:54:33] <alex_joni> same for the NML command
[22:55:19] <jmkasunich> I have a question about groups
[22:55:25] <jmkasunich> * jmkasunich changes the subject ;-)
[22:55:28] <alex_joni> shoot
[22:55:42] <jmkasunich> is there a rule that only one code in a group can be active? or am I thinking of something else?
[22:55:49] <alex_joni> yes there is
[22:55:55] <jmkasunich> then we have a problem
[22:56:03] <alex_joni> why?
[22:56:09] <jmkasunich> M50-53 are not mutually exclusive
[22:56:14] <alex_joni> active in one block
[22:56:18] <jmkasunich> each one sets a single thing on or off
[22:56:18] <alex_joni> as in on the same line
[22:56:26] <jmkasunich> oh
[22:56:28] <alex_joni> M48 M51 is not allowed
[22:56:30] <alex_joni> but M48
[22:56:32] <alex_joni> M51 is
[22:56:52] <alex_joni> they can be active at the same time, just not instantiated at the same time
[22:56:53] <jmkasunich> ok, that's just peculiar
[22:57:04] <jmkasunich> but I should know better than to think about g-code
[22:57:05] <alex_joni> it's a g-code thingie
[22:57:13] <alex_joni> but I agree it's best like that
[22:57:22] <alex_joni> e..g what would you do on M49 M50
[22:57:31] <jmkasunich> yeah
[22:57:38] <alex_joni> or M51 M52 P1
[22:58:01] <jmkasunich> ok, you convinced me
[22:58:19] <jmkasunich> what a peculiar language
[22:58:38] <alex_joni> indeed :)
[22:59:50] <jmkasunich> ok, so we need to decide on names for the four EMCMOT commands
[23:00:43] <alex_joni> EMCMOT_FEED_OVERRIDE_ENABLE is a bit long
[23:01:07] <jmkasunich> EMCMOT_FO_ENABLE?
[23:01:14] <jmkasunich> and SO, AF, FH versions?
[23:01:17] <jmkasunich> or is that to vague
[23:01:18] <alex_joni> I can live with that
[23:01:22] <alex_joni> but AF might be vague
[23:01:30] <alex_joni> I'll put lots of comments :)
[23:02:26] <jmkasunich> you already have a partly modified motion.h
[23:02:35] <jmkasunich> you even modified command.c I see
[23:02:49] <jmkasunich> (I was gonna do that, but I guess you needed it to test)
[23:03:04] <alex_joni> give me 5 minutes to clean up
[23:03:06] <alex_joni> and close :D
[23:15:10] <alex_joni> * alex_joni changes a bazillion places
[23:26:01] <alex_joni> whoa.. it's working ;)
[23:26:19] <jmkasunich> cool
[23:26:25] <alex_joni> I mean still working ;)
[23:26:29] <jmkasunich> want to commit so I can start on the emcmot stuff?
[23:26:34] <alex_joni> jas
[23:26:54] <alex_joni> * alex_joni pastebins it for double checking :D
[23:27:08] <alex_joni> http://pastebin.ca/238375
[23:28:43] <jmkasunich> the command.c and motion.h stuff looks good to me
[23:28:49] <jmkasunich> the rest I really can't follow
[23:29:12] <jmkasunich> but I trust you
[23:29:23] <jmkasunich> and it looks like the debug messages in command.c let you test it
[23:29:30] <alex_joni> found some problem
[23:29:34] <alex_joni> I think
[23:29:42] <alex_joni> line #952
[23:30:28] <alex_joni> nope.. just numbering that changed, and diff interpreted it wrong :)
[23:30:42] <alex_joni> * alex_joni started to wonder how it worked if I had those typos
[23:30:48] <jmkasunich> ;-)
[23:31:04] <alex_joni> ok.. here it goes
[23:40:37] <jmkasunich> dinner now, but I'll work on it right afterwards
[23:40:50] <alex_joni> the commits made it through though
[23:41:04] <alex_joni> can you quickly check if it still runs?
[23:41:14] <alex_joni> * alex_joni would rather know that before going to bed :)
[23:54:01] <alex_joni_> alex_joni_ is now known as alex_joni
