multiple test sub return value

hi,
I would test the return value of a sub return so that if it is 1 the program stops. The problem is that in the main gcode I can not use the if condition as it needs before a number (eg o345 if ....) and the postprocessor can not increment the number each time the sub is run. I'll explain.

main program
.....
.....
123 or <name> call
124 o345 if [<_value> GT 0]
        M30
125 o345 endif
......
......

501 or <name> call
502 o345 if [<_value> GT 0]
        M30
503 o345 endif
....
....
The problem is that o345 if, in the second case generates an error. It should be increased by the postprocessor (Vcarve) but it does not.
Is there a solution?
M2 or M30 in the sub is causing me serious problems.

regards
Ale

It feels like the M30 belongs in the subroutine. What problems do you get with that?

A post-postprocessor could probably fix the IF statements, but that might be a lot of trouble.

At the beginning I had put M30 in the sub but in the sub there is a g38.1 and, by interrupting the sub with M30, the next time it restarts the sub, G38.1 or rather it locks as soon as the probe reads.
Any idea?

regards
Ale

The interpreter won't even see the M30 until the G38.1 has completed, so I am a bit puzzled what problem you are describing.
Maybe there is a parameter used by the subroutine that needs to be re-set before the M30?

If the tool is ok, the program works regularly.
If the tool is not ok this happens:
At the first ctrlut call the tool goes to the touch probe, the error is detected and the message appears (see attached file ctrlut.ngc). The tool changes and resets on the touch probe. With an MDI command, you run the sub "primadiripartiredalinea" and then start the program with "run from here" by selecting the line where it stopped. At the next ctrlut call, the sub ctrlut stops immediately after g38.2, the z axis stops exactly on the probe reading and the program goes out. See attached files.
Linuxcnc version 2.7.3 (Maybe a bug?)

run-from-line has a number of unfortunate limitations. I think that might be part of the problem.

Does the G38.2 exit with "probe already triggered" error?