Getting stuck on G1 (but not G0) in NGC M6 remap

I'm stumped. 

I have remapped M6 to an NGC file - originally I just had it supporting manual tool changes, and that was working fine, but now I've got it configured for ATC.  It mostly works, except for one persistent issue: the very first time I do a tool change (e.g. T1 M6 in MDI) after launching LinuxCNC (and homing), it gets partway through and just... gets stuck.  The relevant section of code is below - it completes the two G53 G0 moves but then just stops and sits there indefinitely, never executing the G53 G1 (Slot tool into pocket) move.  I don't see any errors or anything noteworthy in the status or machine logs, nor anything in the console window from which I launched linuxcnc.  If I hit "STOP" and punch the tool change (e.g. T1 M6) into the MDI again, it works fine - and continues to work fine on subsequent tries, seeming to only be an issue on the very first try after launch.
Curiously, if I make that problematic Y move a G0 instead of a G1 (as seen in the commented-out line that precedes it) it works just fine even on the first try.  I'm at a loss as to what the difference is; I'd rather not stick with G0 as that's pretty aggressive when slotting tools in and out of the rack.

Just a suggestion, but would any move in G1 be looking to confirm the spindle is in motion before any G1 feeds are performed ?

That crossed my mind, and I found another post where someone was getting stuck on G1 but not G0 and in their case it turned out to be that G95 was active, which ties axis motion to spindle rotation.  That was on a lathe though - I'm on a router, so I'm only ever using G94 (which can be seen as the active feed rate mode in the list of modals in the screenshot).  I did a quick sanity check of the rest of my active modal codes and none of them jumped out at me as an issue.

Aside from the G95 special case, G1 does not generally require spindle rotation - which is further evidenced by the fact that when it gets stuck like this, I can simply hit STOP and then run M6 again and it all works fine, including the G1 moves - and it continues to work on subsequent trials as well.  There's just something different about the very first M6 after launching LinuxCNC and homing.

I think you may have read 'my' post about G0 & G1 on the lathe, as that is the issue I had.
Strangely I found that at first after pressing cycle start, the system would sit and wait at G1.
But then later when I press reset and then cycle start, it would run . I actually turned some parts like this.
All was resolved when I noticed that I had the wrong G17/G18 mode active, and also setting up the spindle synchronisation correctly.
As for the G17 etc, it was switching back to G18 unrequested because of the way I had something set up (can't remember right now)

Just a thought, if your G code routine is a sub-program out side of the main program, I wonder if you may need to add a G94 command inside of the sub prior to the G1 ?
Could you try to swap the G1 to G0 as quick experiment experiment ?

I'll try adding a G94 and see if it makes a difference, and perhaps a G17 for good measure.  As seen in the screenshot it seems to be indicating that G17 and G94 are active, but to your point maybe there's some subtlety about what modal codes apply within the subroutine versus a loaded g-code file or the MDI.

It works fine if I only use G0 everywhere.

I may be wrong, but it seems because of the G1, it's looking for proof of spindle rotation before it can progress?
Do you have the 'spindle at speed' pin set up in the HAL file ?

Alright, after an absurd amount of banging my head against the wall with this, I finally got past it.
I tried the various ideas here, and anything else I could think of, and nothing made a difference.

It turned out to be something more bizarre.  I have an M200 NGC subroutine set up which uses an optical sensor to check the presence of a toolholder in the ATC spindle, since the spindle has no built-in sensor.  I have it run M200 after the built-in homing routine, so it homes and then immediately runs this check.  As part of that M200 routine, I run the spindle at low speed with an S500 M4 command.
By extensive trial and error, I finally found that if I commented out that one line (so M200 doesn't run the spindle) then this issue with G1 vanishes.
I still have no idea why running the spindle in an M200 after homing should have any effect on the ability to do a G1 move (as part of an M6 routine or via MDI) quite a while later...  But spindle rotation isn't critical to my M200 routine so I can live without it as a workaround.

Reviving this from the dead, as I once again ran into this same issue in my tool changer routine.  Clearly, my original "fix" of just not running the spindle in my M6 remap was just a workaround, not an actual solution.  In my tool changer routine, I was (of course) stopping the spindle via M5 prior to changing tools, and this was causing it to wait on the first G1 move.  I'm not willing to change that to a G0 because I don't want the machine slamming tools in and out of their pockets at full speed.

I haven't been able to easily find a crystal clear definition of this in the official docs, but numerous sources have led me to understand that after each commanded spindle speed change (including stop/start), upon encountering the next feed-rate move (e.g. G1, G2, G3 and probably others) the motion controller will wait for spindle at-speed to become true.  This wait will only occur once after each spindle speed change (i.e. subsequent G1/G2/G3's won't wait) and does not apply to rapid moves (G0).

One aspect that made this issue more insidious and appear to be more elusive during troubleshooting is that it doesn't behave the same when commanding things manually via GUI or MDI, versus when running an actual program in Auto mode which contained tool changes.  I'm guessing that whatever internal flag is associated with this one-time wait gets reset each time execution stops after a manual command.

This behavior is logical enough in the context that G1/G2/G3 are meant to be "cutting" moves whereas G0 rapids moves are not.  However in the context of a tool change or probing or similar, a controlled feed rate while NOT cutting is desired, and there is no such thing as a non-cutting controlled-feedrate g-code command in linuxcnc to my knowledge.

Fortunately, I found a way to fake it out:Thankfully, based on my testing, a zero-distance G1 move seems to be interpreted as a no-op but still consumes the one-time wait.

Adding this before the first "real" G1 move in my tool changer routine has eliminated this issue - at long last!

Other thoughts I had on alternative ways to work around this include:
1) add side-channel logic between the motion and spindle controllers that can stop the spindle without actually changing the commanded spindle speed via G-code (M3/M5 or S commands), so the one-time wait doesn't get triggered in the first place.  This could still be sensitive to this issue if the user g-code program happened to trigger the one-time wait just before triggering the remap subroutine(s).
2) add side-channel logic to fake out spindle at-speed (hold it true) for the duration of the subroutine even when the spindle is stopped.
Both of these options seem more risky to me because of the possibility of getting into a bad state in the event of an error in the subroutine and returning to the user program with the normal spindle control still bypassed in some way, but just throwing them out as food for thought...