- Posts: 29
- Thank you received: 0
Error: Calling a remapped M6 toolchange from a remapped cycle
- terans1085
- Topic Author
- Offline
- Junior Member
-
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
Please Log in to join the conversation.
- terans1085
- Topic Author
- Offline
- Junior Member
-
- Posts: 29
- Thank you received: 0
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.
Please Log in to join the conversation.
Please Log in to join the conversation.
- terans1085
- Topic Author
- Offline
- Junior Member
-
- Posts: 29
- Thank you received: 0
Please Log in to join the conversation.
You might get a better answer from the Machinekit guys, the chap who wrote the remap code hangs out there now.
It might just be that you can't nest remaps, or that the remapped code needs to be on the top level.
(Perhaps you can call the python part of the remap from G-code as a custom M-code?)
Please Log in to join the conversation.
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.
Please Log in to join the conversation.
- terans1085
- Topic Author
- Offline
- Junior Member
-
- Posts: 29
- Thank you received: 0
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!!
Please Log in to join the conversation.
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.
Please Log in to join the conversation.
I had to change the py extension to .hal so the forum would take it.
Please Log in to join the conversation.
- terans1085
- Topic Author
- Offline
- Junior Member
-
- Posts: 29
- Thank you received: 0
**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??
Please Log in to join the conversation.
