M6 remap in pure python lessons learned

I just finished up my M6 remap in pure python on a large multi spindle router with vaccum pods and 3 position rack toolchanger.
It was a taxing adventure but something I learned alot doing. There is very little in documentation on the subject and no code examples. I got very few responses when asking for help for some unknown reason, but thats ok because I had to dig and figure out how to do it, which was fun and daunting, but a great learning experience and I gained a ton of linuxcnc knowledge that I wouldnt have gotten if I was being force fed information.

So I will run down what I have learned in hoping someone can bypass the difficulty I had in getting the information required to get this done.

I will start from the beginning: Tx M6

The line in the ini file that starts this off in my case is:

REMAP=M6 modalgroup=6 prolog=change_prolog python=M6_Remap_BiesseRover346

Standard glue was written to help in passing values and setting up things that were awkward to do in NGC code, or RS274NGC language. With an NGC or o word type remap, you would have the change_prolog being executed which handled the Tx basically and passing on selected tool and selected pocket to the remap. The ngc code would run and do the change and give change_epilog a positive value if everything went ok, then the change_epilog would return an error and/or abort, if it wasnt a positive value, and when it was a positive value it would set some parameters, cause a interpreter sync and return gracefully and carry on with the gcode.

The problem with using stdand glue with pure python is, well .... you cannot execute three python files sequentially within a remap. I dont know why, It just doesnt call the third file. Change_epilog will never run within a pure python remap as of this version 2.8 pre. And it did not before either. this is documented in one line of the source code somewhere. I found it at one point.

So what I did was use the change_epilog1 as a function within the remap file and called it just before exiting the remap. In a pure python remap, you are responsible for setting parameters if you are using them, doing your offsets or whatever you need to do to exit gracefully and carry on with gcode.

So now we have that taken care of, the first thing that needs to be done when you enter a remap is checking which instance of the interpreter you are in. When you startup Linuxcnc and load a file, it loads the preview plot bvy running through the gcode, it is using the preview instance of the interpreter, which does not send any cannon commands or proces any move commands, or check any inputs. It runs through the gcode so it can display the plot. The problem is once it gets to a Tx M6 during loading the file, it detours hence the (remap), and in my instance runs the change_prolog and then the remap code. During the remap you are in the milltask instance which does process commands and inputs and outputs etc.... Same instance as when starting a program. So if you dont check which instance your in and exit out of the remap when loading a file, it will attempt to change a tool and probably fail miserably, with undesired behaviour and possibly breaking things. So the first thing you should do in the remap is check which instance your in like so:



This will exit the remap and finish loading the file.

At this point, you dont know if the remap is working and changing tools. If linuxcnc starts, then the process of remap is correct and working. However you do not know if your code is working, and wont know until you try running a file.

When I started out my journey of remapping, I didnt understand any of this and so when we got the remap process working I was caught by surprise in that when staring up linuxcnc it started trying to change tools and failed. No commands were executing. Now we come to the part that is the most daunting. I will briefly explain what is happening and what a queubuster is in my own words.

The interpreter knows where the machine is at throughout the gcode file. It needs to know where it is after every line because it is reading everything into its buffer and processing commands from within the buffer. If it comes to a function where there could be an outcome the interpreter cannot see re: toolchange fail, probe not working, because it cannot predict it, it cant recover because the machine will be in a different state than what the interpreter thinks it is. The interpreter will continue processing commands, but not all. It ignores commands until it can catch up to where it thinks it should be. This is called a queubuster and needs to be dealt with. What should happen is you need to tell the interpreter to stop read ahead, process everything in the buffer and then continue on.This is the grey area where I cannot find the relevant information to make this happen systematically. I have been able to keep the interpreter happy, but I would really like to know more about this. They have INTERP_EXECUTE_FINISH which is when you yield INTERP_EXECUTE_FINISH, then this is suppose to stop the read ahead, process whats in the buffer and continue on.The trick is where you do this and how many times you need to do it. this you just have to test.

In my head the best thing to do would be upon entering the remap, stop read ahead, flush the buffer, the continue through the remap until done. re sync the interpreter then be on your way. But this is not how it is setup. So you yield where you think it will cause issues with the interpreter and you should be able to get through the remap.

So the last thing in the remap is I call a modified epilog function within the remap, and set the emccanon.change_tool, and set parameters I dont use, but it makes linuxcnc happy so and finally set the toolchange_flag to True.
Then gracefully exit the remap.

A couple things I have to bring up and they are setting motion.digital-out-XX directly does not work reliably from within a pure python remap for some reason. you can check them no problem but I have had zero success setting them directly. With that being said, setting them with M62-M66 is working flawlessly. so I chose to go this route, especially because thats what the interpreter was built to do, and it doesnt it well. see below a function to drop tool.



In closing, I would like to thank the guys in the IRC channel that aided me in where to find info and tips here and there.

I am not 100 % sure everything is accurate, but in my mind it is. I am open for discussion. If anything I said is blatenly incorrect please speak up.

Bob

@Bob,

is it possible to get the complete code?
I am on a similar problem, at actual state I am using a mix of gcode and python and sometimes I get strange behavior on the changer, like dropping the tool without opening the changer

Norbert

newbynobi wrote:

@Bob,

is it possible to get the complete code?
I am on a similar problem, at actual state I am using a mix of gcode and python and sometimes I get strange behavior on the changer, like dropping the tool without opening the changer

Norbert

Hi Norbert,

Sorry, I missed this post. Did you get your changer working? Still need the code?

One thing to take note, don't go more than one sub deep within the remap or the interpreter will ignore you, in most cases.

Also, try to keep your functions that do the actual I/O strickly gcode then yield out. So have a function DropToolx(self)
then list the gcode. This seems to work well.

newbynobi wrote:

@Bob,

is it possible to get the complete code?
I am on a similar problem, at actual state I am using a mix of gcode and python and sometimes I get strange behavior on the changer, like dropping the tool without opening the changer

Norbert

Are you checking to make sure the changer is open before going forward?

Hi, Bob. I'm working on mesa controller based system, using linuxcnc.
Saw your project "BiesseRover346" on Github - great job.

Apperently remap using python is my only way to solve my problem with remaping.
But I can't find any explicit documenatation for interpreter, umccanon modules you used  in your project. It seems like you know where to find documentation.
Help me with documentation, please.

bazhenov4job wrote:

Hi, Bob. I'm working on mesa controller based system, using linuxcnc.
Saw your project "BiesseRover346" on Github - great job.

Apperently remap using python is my only way to solve my problem with remaping.
But I can't find any explicit documenatation for interpreter, umccanon modules you used  in your project. It seems like you know where to find documentation.
Help me with documentation, please.

Which modules are you talking about? I got alot of stuff from the source files with alot of trial and error.
I will take a gander back in this thread to figure out what the actual issue is you are having and see if I can help.
My Biesse 346 remap is using some stuff me and my friends wrote to try and keep settings in one xml file. It works but it turned out to be more of a hassle than a help but it does work. It is a class, so you dont have to do that. if you dont want. What issues are you running into?

Another big one that's not documented is that in a pure python remap it cannot run three python scripts in a row. It just wont do it no matter how hard you try.

So, prolog => toolchange => epilog WILL NOT WORK PERIOD...... you put the prolog and epilog in your remap file like in my code and it processes the commands no problem. The way I got it to work is the prolog function is called within the remap and after the toolchange the epilog is built into the end of the remap. This is the only way I could get it to work properly.

Yeah, I saw the way you call prolog procedure inside the remap function.
Back to the question.
As well as you do I would like to remap M6 command using pure python. U use the interpreter module, emccanon module and linucxnx mudule. For linuxcnc documentation is easy to find and it's pretty good. But for the interpreter module and for emccanon I couldn't find the documentation.
For example, a description of self.params dicirionary is implicit, as well as **words argument.
That is what I hoped you've found and can share with me))