But the comp in V4 is based on Smid's book, I believe.
Quite possibly, but totally irrelevant. Even though I have not been able to find a single copy of any of Smid's books in any public libary here in Australia (why???), I feel very confident in making two predictions about what Smid has written.
1) The compensation should produce a tool path which gives the required shape, which is pretty obvious to the user.
I think this one is perfectly obvious. How it is done is 'left as an exercise for the reader', but testing the result is very easy.
2) The level of subroutines involved in the program does not affect the required outline or path in any way.
After all, why should it?
To be sure, a practical implementation such as an old Fanuc controller might impose it's own limitations on what sort of program it can execute. That is quite different, and no problems there. But the idea that global variables such as the current position or direction might depend theoretically on the subroutine level -
no way!.
If the gaming industry can write code which lets you fly around WoW or Halo or Second Life in full 3D, then a g-code program should be able to create a tool path for cutter compensation regardless of how many subroutine levels you have in your code.
Looking at the results from my test programs and TP's test programs, I have to say it lokks like an errant SR return or an errant pointer is causing a jump to the code for a spiral or similar (G2, g3 for instance) instead of the correct code. That is a bug. Period.
Cheers
PS: I have frequently been told in other venues that I am far too blunt for American sensibilities. This seems to be a failing common to many Australians. We are blunt. If anyone is offended by my bluntness, my apologies.