So, here's some code I've been writing to try to get an exponential curve on a job. It's just a toolpath for now, no feed rates, spindle commands or anything fancy, I tend to do those later in the game.

g40
g0 Z5
#1=0
#2=0
#3=-5.2

G0 x-65 y0
(g41 p7) (this is what buggers it up)
g0 z#3
G01 X-55 y0
G01 X-45 Y0
G01 Z#3
#1=0
#2=0
g01 x0
M98 P2 L10
g01 X 0.86 Y-35.71
G03 X0 Y-35.5 I-0.89 J-43
G01 X-45
G01 X-45 Y0
#3=[#3-5.2]
g40
M30

O2 (Incriments X then recalculates Y, then moves there)
#1=[#1+26.0000]
#2=[[[0.495*[2.718**[0.020*#1]]]+[0.0320*#1]]*-1]
G01 X#1 Y#2
M99
%

Note the G41 offset is commented out - like this it should display a nice sort of boomerang shape, but of course there's no tool diameter offset. With the offset active, it runs O2 once then bails out and shortcuts back to the start of the g03 arc.
The really strange thing is, the blue toolpath line is the right shape - it just doesn't follow it with the offset on. it's as if it will only run O2 once when the offset is active.
Help me out lads, I'm losing my mind here. 

well... Looking at the fossil record of the forum and having tried damn near everything including nesting, un-nesting, changing parameter names and drinking coffee until my eyes ache, it seems that diametric offsets are broken when used in subroutines.

so I've un-nested the subroutine and copied and pasted its contents as many times as needed. feh. Not nice coding but it works. Maybe I should buy Mach4. Is the issue solved in the new version?

I used to program everything using G41, G42 when I programmed by hand and used parametrics on a Fadal VMC. I have also done it on a number of other controls. My suggestion is to apply the G41 and make a very small X or Y move say 0.01” which causes the tool to move to the offset position. Now you can plunge to Z depth and go. Always raise the tool then cancel the offset before any other moves or it will be unpredictable. I get that first little move location simply by adding or subtracting the 0.01 in X or Y from the actaul start point. Of course you don’t want to create an inside corner with point or that will screw you up as well.

I messed around with your code in Mach4, but had to make some changes as not sure what it is.
You do have to put in a diameter in the tool table.
did notice once I added the cutter comp working feature I had to double the loops in the M98
not sure what that's all about, seems like a bug



#1=0
#2=0
#3=-5.2
G21 G90 G40
G0 X-65 Y5 Z5
G1 G41 X-60 Y0 F500
 Z[#3]
 X-55 Y0
 X-45
 X0
M98 P2 L20
 X 0.86 Y-35.71 F500
G3 X0 Y-35.5 I-0.89 J-43
G1 X-60
 Y0
#3=[#3 + 5.2]
G0 Z[#3]
G40 X-65 Y0
M30

O2 (Increments X then recalculates Y, then moves there)
#1=[#1+26.0000]
#2=[[[0.495*[2.718**[0.020*#1]]]+[0.0320*#1]]*-1]
G1 X#1 Y#2 F800
M99
%


^ that's my part alright. My mill's set up on Mach3 although I may well fit Mach4 when I build the new controller.
I tried calling a tool from the tool table in Mach3 but it makes no difference.

Mach3 is a wonderful program, but trying to get it to do complex tool offsetting when you are several SR calls down the stack is not a good move.
I can create and machine 3D super-ellipses with no trouble at all - but I don't use the tool table when doing so.

Cheers
Roger

G01 x#1 y#2 ... it's hardly complicated as offset tool moves go and it makes no difference if it's one sub deep or two. The only thing that breaks it is being in a subroutine at all. outside the sub, it works fine. i just have to repeat myself a lot

I do the tool offset calculations explicitly in the g-code. Parametric programming and all that - with 3, 4 or 5 levels of subroutine calls. No problems.

Cheers
Roger