This is the tail end of a long discussion. Some clarification and
stuff that was discussed earlier will appear in parentheses.
<jmkasunich> 3.6.5 Override Control - M48 and M49
<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.
<jmkasunich> are these what we are talking about? I thought they were Gcodes, not Mcodes
<cradek> yes I guess so
<cradek> those are override enable/disable
<cradek> AF enable/disable is g50/g51 iirc
(AF is short for Adaptive Feed)
<jmkasunich> yes, but we made that up on the fly at emc-fest
<cradek> yep
<jmkasunich> I gotta wonder if we shouldn't admit that AF and FO are related
<jmkasunich> maybe M47 should be AF enable/disable
<cradek> maybe
<jmkasunich> oh, I'm all fscked up
<jmkasunich> I was thinking M48 was FO, and M49 was SO
<cradek> no they are both controlled together I guess
<jmkasunich> but M48 is FO _and_ SO enable, and M49 is FO _and_ SO disable
<jmkasunich> you _can't_ disable just one of them
<jmkasunich> what a crock
<cradek> To enable the speed and feed override switches, program M48. To disable both switches, program M49.
<jmkasunich> yeah, I read it, but it didn't sink in
<cradek> I don't really even care about any of that, I just think the canon call should work
<cradek> I think the goofy gcode stuff is a separate problem
<jmkasunich> well, I'm seeing some symmetry here, for SO, FO, and AF
(SO = spindle override)
<cradek> true
<jmkasunich> and I'd like the gcodes, the canon functions, and the RT implementation all to make sense
<jmkasunich> lets start at the top for a moment
<jmkasunich> M48 and M49 do as documented, FO+SO on, and FO+SO off
<jmkasunich> M48.1 FO (only) on, no change to anything else
<jmkasunich> M49.1 FO (only) off
<jmkasunich> M48.2 SO (only) on
<jmkasunich> M49.2 SO (only) off
<jmkasunich> M48.3 AF (only) on
<jmkasunich> M49.3 AF (only) off
<jmkasunich> note that plain M48/49 don't affect AF at all
(since many people won't use or want Adaptive Feed, we should make them explicitly turn it on)
<cradek> I think that's an appealing idea
<jmkasunich> under that you have three canonicals, setFO(on/off), setSO(), and setAF()
<jmkasunich> I bet you even SOdisable should be queued, so it applies to specific moves
<cradek> I'm sure that's true
<jmkasunich> so thats three "immediate" flags, written by the canonicals
<cradek> I'm seeing these are really all the same
<jmkasunich> and queued by SET_LINE and SET_ARC
<jmkasunich> dequeued by the TP, and written into three "current move" flags
<jmkasunich> the folding code uses the current_move flags when in coord mode, and the immediate flags during free mode (and teleop)
(Folding code = the code that looks at the various flags, the GUI feedrate override value from EMCMOT_SCALE commands, and the
adaptive feed value from the HAL pin, and "folds" them all together into an overall scale value, emcmotStatus->overallVscale)
<jmkasunich> feedhold also goes into the folding code.... I dunno whether we'd make it enableable or not
<jmkasunich> could easily add M48/49.4, and another pair of flags
<cradek> that kind of thought makes the bitmap seem smart
<cradek> the bits correspond to those M48/49 bits
<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
<cradek> I think that's an argument for doing all the bitmap processing in TP
<jmkasunich> and the "folding"?
<jmkasunich> who does the folding in free mode?
<cradek> yeah that's what I meant by bitmap processing
<cradek> well first do you agree about being a period behind? I'm not sure
<jmkasunich> I think so
<cradek> I also don't know whether that's important
<jmkasunich> there are two approaches, I'm trying to figure out if either one helps
<jmkasunich> can do the folding before or after calling the tp
<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
<cradek> yes I agree, it's not going to help either way
<cradek> it's an inexact science anyway with the blended transitions
<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
<cradek> maybe it doesn't matter
<jmkasunich> I'm not sure if a millisecond of additional delay will matter
<jmkasunich> with exact stop mode, the bitmap will change on the first period of the new move, right?
<jmkasunich> at that point, the velocity is near zero, so scale will have very little effect
<cradek> yes
<jmkasunich> on the next period, scale will be correct for the segment
<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
<cradek> for that cycle I think there is no motion
<jmkasunich> great
<jmkasunich> so in exact stop mode, you can ensure that the FO either does or does not apply to the desired segment
<jmkasunich> in blended mode, the result is ambiguous, but that is to be expected anyway
<cradek> yeah you slow down or speed up "during the blend sometime"
<cradek> that's as precise a statement as I'm prepared to make
<jmkasunich> if you disable FO in the middle of a long string of blended moves you can't expect perfection anyway
<jmkasunich> I think I'm happy with what we've defined here
<cradek> well it will be fixed in one move no matter what, since we only blend two of them
<jmkasunich> yeah
<cradek> I think it will end up working fine
<jmkasunich> sleep now, review the log tomorrow,and split up the work? I'd be happy to do the folding code, the immediate flags, and queue the immediate values
<jmkasunich> you know the TP, so hopefully you can dequeue and write to the current_move flags
<jmkasunich> I can do the folding code, and add the feedhold pin
<jmkasunich> and we can get alex to work on the canonicals and/or M code stuff
<cradek> yeah, but poor alex :-/
<cradek> I'd like alex to read it before we do anything
<jmkasunich> yes - certainly get alex to review first
<jmkasunich> maybe tomorrow we should have him walk us thru it so we learn?
<cradek> maybe, but I think I actually know how to do it
<cradek> writing down the steps/layers would be nice though.
<jmkasunich> yeah
<cradek> arg, two hours of my life gone
<jmkasunich> but I think we came up with an elagant _and_ implementable design
<cradek> yes