Python M6 remap not doing any self.execute()'s

Hello,
I have setup a remap of M6 using a single python file and can't get any of the self.execute(...) statements to work.  When I try to add 'yield ' in front of 'INTERP_EXECUTE_FINISH', I get an error...
SyntaxError: 'return' with argument inside generator (remap.py, line 70)

The code prints out all of the print(...) statements like it is working, but, no motion happens and no bits are flipped.
My ini and python file are attached.

When using the yield statement you are using a python generator.
Python doesn't allow returns with an argument from generators.
use:
yield INTERP_ERROR
yield INTERP_OK

Thank you for responding.
My real issue is the fact I can't get any response from the self.execute(...) statements. From other posts and documentation, I have assumed it may be due to a queuebuster issue and I have seen code with and without 'yield' preceeding 'INTERP_EXECUTE_FINISH'. Section 9.4 under the 'Remap Extending G code' documentation states that it must be used this way in python remap code. I'm totally confused about it. I have 'return INTERP_OK' at the end of the remap function. Anytime I try to add a 'yield <anything>, the software chokes and won't load giving me the...
SyntaxError: 'return' with argument inside generator... error.

Is it the queuebuster that where my issue with the self.execute(...) non-functionality lies or am I barking up the wrong tree?

Another anomaly I noticed is the fact that when I assert an M6 T<n> mdi command, the interpreter runs through the M6 remap code printing all of my print(...) statements down to the last one, then, just hangs in a 'Reading' state but no commands are in the queue.

'yield INTERP_EXECUTE_FINISH' is needed with code that must make derisions based on external events. It makes the interpreter wait until the code before it is finished before continuing. If you don't use yield in code that needs it, then the function is processed well ahead of the event and would seem to be ignored.

after using yield, it makes the python function a generator - then you can't return arguments.

You can make remaps as pure functions or generator functions depending on what you are doing.

For python only, toolchange remaps you surely want to use the generator style - but you must follow the requirements to do so.

maybe I didn't make my self clear.

use
yield INTERP_OK
yield INTERP_ERROR

instead of
return
return ReturnERROR()

Thanks for the clarification on yield vs return. I'll look into that further once I can get past this main issue with the interpreter hanging up.

I have done some more investigation. I made an ngc subroutine with no prolog or epilog to replace the python remap. The results are similar. When I execute an 'M6 T2', for instance, the subroutine runs up until it encounters an G or M code that the interpreter needs to process then it stops and just hangs in a 'Reading' state.  In this case, it comes to a 'G53 G0 Z0' and nothing else happens.  Any ideas what could be causing this?

have you connected the HAL pins properly?

That did it. Well, with a caveat. I had to add...
'net tool-prep-loop iocontrol.0.tool-prepare iocontrol.0.tool-prepared'
even though I'm only remapping M6 and not T. Haven't quite got my head wrapped around all of this just yet, which makes me a little uneasy, but it seems to work now and the halui.tool.number changes upon completion of the M6 T<n> command and doesn't change if I abort the procedure in the middle of it.

Thanks for your help.

Excellent.
T cause tool prep, m6 tool change.
So both set of HAL pins are involved, unless you remap them and specifically remove them.