Hi Matt - after having a play, I think you're absolutely right - in a way...
It seems that regarless of whether you're using THC, Mach executes the M3 and THEN executes the G4 dwell. However, IF you're using THC Mach will THEN wait, AFTER the dwell for ArcOK (if it has to). The reason I (and I suspect a lot of others) have never noticed this is that IF the M3 is very quick in turning on your torch AND the ArcOK is very quick and between them the time is MUCH shorter than the dwell, then everything APPEARS to work as it should. BUT - IF the time it takes to turn on the torch and to return the ArcOK signal is pretty close to the G4 dwell time OR worse LONGER than the G4 dwell then there is effectively NO delay. i.e. it's allready done the G4 BEFORE it even got the ArcOK.
This IMHO is clearly wrong and I would regard it as a Mach bug. What Mach SHOULD do of course is execute the M3 and then wait for ArcOK BEFORE it does the G4 dwell.
In reality, the only gcode commands that Mach will not execute if ArcOK is not there (and THC is on) are MOVEMENT commands.
Hope that all makes sense. You can test the above out by doing a "silly" long G4 and you'll see it IS being executed and not skipped.
One make do solution I guess is to add the time it takes the torch to come on + the time it takes it raise ArcOK + the actual pierce delay you need and code G4 for that. Alternatively I guess some suplemental VB in M3 to do a wait for ArcOK - something like:
'untested and crude - i.e. infinite loop if ArcOK never comes.
DoSpinCW
while not isActive(THCON) 'yes annoying isn't it, Mach's signal name for ArcOK is THCON for gawds sake.
wend
Incidentally, a tip: I don't use DoSpinCW - it's slooooooooow, instead I use activateSignal(OUTPUT1) - it's waaaaaay faster to respond.
Ian