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.

cmorley wrote:

I found this email.

I hate that the solution would mean redoing everything in python as that will make adapting it for many users more dificult. the rs274 language is somewhat easy to get the hang of verse learning python coding. I found and read a ton of information on the interpereter and how it is based on very old technology (tape punch type machines with no look ahead) ands that is i gathered where the headaches come from as its been fixed somewhat to do more then it was designed to do and these glitches are results of original nature of the processing flow. very interesting reading in those links in that email you posted! thanks for that! I wonder if the remapped code can be rewritten in such a way as to not upset the interpereter. i supposed i need to keep reading and find if there are any work arounds.

we did discover that if we removed the gcode plotter that the file loaded and ran perfectly fine. we are using VTK as the gcode plotter which is really powerful from what i can tell, but is also fairly new to us still and therefore taking time to figure things out that pop up as we go. do you have any experience with VTK?

Thanks again Chris!

Chris