program load error when a tool is used twice, machine uses ATC with M6 Remap

Hey All,

I'm having a strange issue loading programs with a tool used twice and having an ATC with a remap m6 setup, hoping someone in here can help identify the cause and help with a fix!

when a program is loaded that has a tool used twice not in succession ie, T6 is called then T10 and then T6 again, i get an error saying the tool is not in the carousel but if the interpreter ran through the remap entirely it would have been returned to the carousel and should be found. this is a pretty frustrating issue as sometimes i use tools at different stages of a file such as a facemill to cut the surface to height and then some rough machining that reveals a larger flat area that i will use the facemill on again to leave a nice finish while avoid an island boss.

I am not sure where exactly the problem stems from considering the atc itself will work fine and tracks the tools flawlessly and everything is working great except this load program issue. it is forcing me to make separate posts to achieve using the same tool twice.

any help or ideas on what i could do to resolve this issue is greatly appreciated!!

Thanks in advance and best regards,
Chris

posting the remap code would be helpful.

Chris

cmorley wrote: posting the remap code would be helpful.

Chris

Chris, here are the remap files, these are the ones from the probe basic atc sim, which work fine ..

here is the last one and main toolchange.ngc

i remember a long time ago having some trouble with a user's remap for tool changes.
I think it was related to fanuc style tooloffsets but may be mistaken.
I don't specifically remember the problem even.

But talking to the author of remap, he suggested making tool remaps using python not NGC code. I believe there was some possible race conditions in NGC code.

Anyways for that particular problem - python was the cure.
I'm not sure that would be the case here but if no one else gives you a good suggestion - I'd try it.

Chris

My gut feeling is: this is due to the self.execute() recursive calls of the interpreter. This is a feature which I never got working stable due to the obtuse control flow of in task/interp. It fails on border cases, especially if queue busters are involved. It would be trivial to bullet-proof IF there is a drive to fix the control flow so the interpreter is master of its inner read-eval-print loop but then there was never any interest beyond patching around in the status. So there you are.

With mk it's at least an issue in the tracker.. Read up here first: github.com/machinekit/machinekit/issues/106 to get a grip on the problem, also this reference: github.com/mhaberler/asciidoc-sandbox/wi...ntrol-flow-explained .

your remap:

# index tool immediately to tool number
# immediately add tool offset
self.execute("m6 T%d"% tool)
self.execute("g43 h%d"% tool)

# if the wear offset is specified, immediately add it's offset
if wear>10000:
self.execute("g43.2 h%d"% wear)

I'd recommend to avoid self.execute() and see if you can replace those sequences by directly emitting equivalent canon commands. You might want to trace a m6/g43/g43.2 sequence with DEBUG=0xffffffff so you see what canon commands are emitted, also read up on the pertinent code in the interpreter so you can replicate exactly.

This should avoid the recursion, and hence the error.

I am fairly sure the issue is the self.execute("m6.."), this is a queue buster and likely triggers the issue. Likely you can leave the g43 in place, but generally avoid self.execute if you can.

I cc: Kirk Wallace who had a related problem recently, used canon directly from Python, and seems to have had good success with it.


- Michael

I found this email.