Error: Calling a remapped M6 toolchange from a remapped cycle

Hello,

I am currently in the process of implementing an automatic tool changer to my setup (3 axis router), hence the need to remap M6. I decided to go for an all python approach:

REMAP=M6 modalgroup=6 python=m6

Toolchanging works fine when called from MDI, however an error "Bug: call stack underrun" is happening when a Txx M6 is called from another remapped cycle, also implemented in python:

REMAP=G81.5 modalgroup=1 python=g815

Would you have any insight about this? Thank you for your time

So I have decided to rewrite the G81.5 cycle, but this time in gcode, and remapped as G81.4, using the default cycle prolog and epilog. Works perfectly except when an M6 is called, this I'm getting an error as per attached image.

Seems like it is looking for an o<m6> subroutine, but frankly I don't know where to put it given that I have remapped M6 entirely in python.

There is, but it is commented behind #, as all comments go! I will try deleting completely but I have little faith this is the issue

The interpreter is very finicky when it comes to remapping in python. First it cannot run three python scripts in a row. When it does its read ahead and tries to run a remap inside another remap how will the interpreter get back? I don't think you can do that. It think Michael will tell you the same thing. Not sure.

What happens if you try and add the remap code in the G81.5 remap. Also try just running Tx in the remap and see if the bug is coming from the Tx or the M6. If it is coming from the M6, then you can run the Tx get the selected tool and hard code the toolchange in the G87

Just a thought.

So what I have done as an interim (possibly permanent) solution is, nest functions rather than remaps.

def m6(self):
if m6func(self) == 1: return INTERP_OK

def m6func(self):
**all m6 code, returning a 1 rather than an INTERP_OK**

Calling m6func(self) directly from the G81.5 remap went well so far. Also I have been reading some of Bevins' threads about his remap. I have not been able to grasp the concept of "yield INTERP_EXECUTE_FINISH", did not notice any difference so far.

Would it be rude if I ask you to have a look at your actual M6 remap python code? as I could not find on the posts.

Thanks a lot for your time!!

terans1085 wrote:

So what I have done as an interim (possibly permanent) solution is, nest functions rather than remaps.

def m6(self):
if m6func(self) == 1: return INTERP_OK

def m6func(self):
**all m6 code, returning a 1 rather than an INTERP_OK**

Calling m6func(self) directly from the G81.5 remap went well so far. Also I have been reading some of Bevins' threads about his remap. I have not been able to grasp the concept of "yield INTERP_EXECUTE_FINISH", did not notice any difference so far.

Would it be rude if I ask you to have a look at your actual M6 remap python code? as I could not find on the posts.

Thanks a lot for your time!!

I posted it in another posr last week i think, but i,ll post it here when i get to the shop tonight.

my remap file. I have an xml class in there, so just blow by that.

I had to change the py extension to .hal so the forum would take it.

I have been going through your code, and noticed you use yield INTERP_EXECUTE_FINISH inside function queuebuster(), but never make any call to that. And when I did call, didn't work in my case.

**Might be moving on to something different here, dunno if I should open a new thread....**

I have finally managed to get my remapped M6 somewhat working, BUT, when a gcode file with multiple toolchanges is run, readahead is setting global variables and parameters (from my epilog) way before the next toolchange happens. So if the program is stopped at any point, the machine thinks that the "next" tool is loaded.

Using yield INTERP_EXECUTE_FINISH directly in my remapped m6() produced erratic results, like having linuxcnc open axis.ngc (default).

Any ideas about a workaround??